Achieving Scalability With Key-Value Databases in Java

NoSQL databases are becoming more and more popular around the world, with new success cases becoming more and more frequent. While there are several kinds of NoSQL databases, this post will cover one in particular: key-value.

The key-value database is the simplest one; it has a structure that is key-based that looks like either a Dictionary or a Map in the Java world.

Compared to relational database technology, the key-value database has a plain structure. It has a bucket that looks like a database name, then a key-value combination. The way to store this information is the same as other NoSQL providers, such as text or Java object. Key-value database providers include:

• Redis
• Riak
• Hazelcast

Luckily, these databases are supported by JNoSQL.

Cache vs. Key-Value Database

Both have a similar skeleton; however, they have different goals. Key-value databases store the data in more substantial time than cache. It has a mechanism such as a snapshot or commit-log that ensures the information is still there, even when the database has gone down for a short time.

The key-value database might have particular key-based structures such as list, counter, etc. Just as an example, consider a product list whose database is a cache and then add a new element.

public class ProductCacheSample {


    public static void main(String[] args) {

        CacheManager manager = Caching.getCachingProvider().getCacheManager();
        MutableConfiguration<Integer, List<String>> configuration = new MutableConfiguration<>();

        configuration.setExpiryPolicyFactory(AccessedExpiryPolicy.factoryOf(Duration.ETERNAL));

        Cache<Integer, List<String>> productCache = manager.createCache("productYear", configuration);

        List<String> products = productCache.get(2018);

        if(products == null) {
            products = new ArrayList<>();
        }
        products.add("new Product");

        productCache.put(2018, products);
        System.out.println(productCache.get(2018));
    }

    private ProductCacheSample() {
    }
}

We are using the standard to cache in Java — JCache, in this example. The code has some issues, given a scenario with one thousand produces in this list. The step will give one thousand elements, serialize, add a new item, deserialize it, and finally, go across to the network, now with 1,001 items. Beyond the overdo of processing of serializing/deserializing and the net chain, there is race condition controversy.

The key-value database has structures such as List, Set, Map, and Key based on the Java world, so we're using the JNoSQL API for the same problem.

public class ProductJNoSQLSample {

    public static void main(String[] args) {
        KeyValueConfiguration<?> configuration = //a key-value provider;
        BucketManagerFactory bucketManagerFactory = configuration.get();
        List<String> productYear = bucketManagerFactory.getList("product_2018", String.class);
        productYear.add("new Product");
        System.out.println(productYear);
    }

    private ProductJNoSQLSample() {
    }
}

So, it's necessary to send a new element to the bucket, and the database will handle the list.

Modeling Within the Key-Value Database

Key-value databases are more scalable. However, they are less complex to read and write because read/write operations use a Key as the main engagement. There are exceptions such as Hazelcast, which has a query, but that might be slow, and it does not do a complex query.

Unfortunately, there isn't clear rule to modeling, such as normalization. Modeling goes either from the application perspective or the volumetry. For example, given an application that stores movies in a key-value database:

public class Movie {

  private String name;

  private Integer year;

  private String description;

}

If the movie name is unique and the information is trivially searched from this field, the name field might be a key. Nonetheless, with the same Movie entity in a different scenario where the application needs to retrieve the Academy Award for Best Picture, once there is one winner each year, the field year is the best Key in this scenario. Also, duplicity and denormalization is your friend, so there's a scenario that a Java developer could choose to storage from both Key and Year.

Demo Code

This simple application will just be a user who will retrieve and write from the nickname. Also, to avoid the installation process, I will use Hazelcast; the minimum requirement will be CDI, Java 8, and Maven.

The first step is to set the dependency beyond the CDI and to set the JNoSQL with a mapping and communication layer.

       <dependency>
            <groupId>org.jnosql.artemis</groupId>
            <artifactId>artemis-core</artifactId>
            <version>${project.version}</version>
        </dependency>
        <dependency>
            <groupId>org.jnosql.diana</groupId>
            <artifactId>hazelcast-driver</artifactId>
            <version>${project.version}</version>
        </dependency>

So, the User model required just two annotations: the Entity to define the user (managed by JNoSQL) and the ID annotation to set the key.

@Entity
public class User implements Serializable {


    @Id
    private String userName;

    private String name;

    private List<String> phones;

}

Now, it is ready to be used in any CDI application. There are two ways for the Java developer to access it.

The first is from the KeyValueTemplate class, which has conventional operations in a key-value NoSQL database.

public class App {

    private static final User USER = User.builder().
            withPhones(Arrays.asList("234", "432"))
            .withUsername("username")
            .withName("Name")
            .build();

    public static void main(String[] args) {

        try (SeContainer container = SeContainerInitializer.newInstance().initialize()) {
            KeyValueTemplate keyValueTemplate = container.select(KeyValueTemplate.class).get();
            User userSaved = keyValueTemplate.put(USER);
            System.out.println("User saved: " + userSaved);
            Optional<User> user = keyValueTemplate.get("username", User.class);
            System.out.println("Entity found: " + user);
        }
    }

    private App() {
    }
}

The second one is with Repository heritage. Just create a UserRepository interface and it is ready to use. As the key-value does not support complex query, it does not support query methods by default.

public interface UserRepository extends Repository<User, String> {
}

public class App2 {

    private static final User USER = User.builder().
            withPhones(Arrays.asList("234", "432"))
            .withUsername("username")
            .withName("Name")
            .build();

    public static void main(String[] args) {

        try (SeContainer container = SeContainerInitializer.newInstance().initialize()) {

            UserRepository repository = container.select(UserRepository.class, DatabaseQualifier.ofKeyValue()).get();
            repository.save(USER);
            Optional<User> user = repository.findById("username");
            System.out.println("User found: " + user);
            System.out.println("The user found: " + repository.existsById("username"));
        }
    }

    private App2() {
    }
}

There is also the Key-based structure supported by the API. By default, it supports List, Set, Map, and Queue, and it is accessible to extend the API to get a particular behavior.

public class App3 {

    public static void main(String[] args) {

        KeyValueConfiguration<?> configuration = new HazelCastKeyValueConfiguration();
        BucketManagerFactory<?> managerFactory = configuration.get();
        List<String> list = managerFactory.getList("list", String.class);
        Set<String> set = managerFactory.getSet("set", String.class);
        Queue<String> queue = managerFactory.getQueue("queue", String.class);
        Map<String, String> map = managerFactory.getMap("map", String.class, String.class);
    }

    private App3() {
    }
}

This post covered key-value NoSQL databases, models, and structures. There was example code with JNoSQL with Hazelcast. Once that uses an API, it can replace any JNoSQL key-value implementation.

References

• The code sample
• JNoSQL website
• Hazelcast website