Scaling Data Services with Pivotal GemFire

Chapter 5. Designing Data Objects in GemFire

Mike Stolz

Three NoSQL developers walked into a bar. They left when they couldn’t find a table.

NoSQL data design is different.

To make good use of any data tool, you need to know a bit about best practices for using it. GemFire is no different, especially if you’re used to thinking in a relational database manner. This chapter outlines the principles of good data design in GemFire’s in-memory data grid (IMDG).

The Importance of Keys

GemFire is primarily a key–value store. The strong implication you can and should derive from that statement is that the primary key for objects stored in GemFire is very important indeed.

The construct that GemFire exposes for data storage is called a Region. A Region is similar to a database table but it is an implementation of ConcurrentMap. So, you can think of it as just a hashmap. In a hashmap, the two primary API’s are put(key,value) and object=get(key).

The first requirement is that keys in GemFire Regions must be unique. In fact, this is a requirement of ConcurrentMap itself.

The second important characteristic is that the keys must be efficient. Although it is possible to use complex objects as keys, their implementation of hashcode and equals needs to be very fast. For beginners, it is recommended that simple String keys are the easiest to manage.

In fact, there are many use cases for which the strings used as keys might even be user friendly and easily remembered. For instance, in the financial ...