Redis driver for n-orm.
Redis is « an open source, advanced key-value store ». n-orm can use Redis for storing persisting objects.
Javadoc is available here
A sample project is available at n-orm.sample. Check the POM for redis, and the store.properties examples.
The Redis backend uses Jedis, one of the reference Java client for Redis.
It currently supports Redis in a single-master server mode.
SimpleStore interface
The Redis backend implements the SimpleStore interface.
This means that it will be wrapped by SimpleStoreWrapper to serve as a data store.
Unlike HBase, Redis is not column-oriented, though it can store only different forms of data. A key (a string) refers to a value, which can be :
- A String
- hashes
- lists,
- sets,
- and sorted sets.
Because of these limitations, a n-orm persisting object is stored in Redis across multiple keys and values.
In n-orm, each object is defined by :
- its table : the class of the object
- its id : a unique identifier in n-orm
- its families : a second level data of table
- its keys : the names of the columns
- its data : the data store in each column, which can be an increment or arbitrary data (stored in base64)
key | Redis Type | Data |
---|---|---|
table | Sorted Set | The list of the id_s in this table |
table:families | Set | The list of families in this table |
table:id:families:family:keys | Sorted Set | The list of the keys on this row |
table:id:families:family:vals | Hash | The values associated with the keys in this family |
table:id:families:family:increments | Hash | The increments associated with the keys in this family |
The data is stored in Base64 for the values, and in plain number for the increments. The Base64 has been selected for preventing errors in saving bytes array from java (the conversion to/from Base64 is made in the RedisStore). However, Redis supports natively an increment command, so the data is stored in plain number for this type of data.
Search with Constraints
n-orm use the Constraint class for searching elements or keys. A Constraint is build with a startKey and a stopKey , which can be null, and can impose a limit of number of results.
Redis does not support search in a Sorted Set, but can return position for an element of the SortedSet. For implementing the constrained search, RedisStore proceeds as follows: for the start key
- If the key is null, we return as first element of the search the first key in the Sorted Set
- Else, if the key exists, 2.a. RedisStore get its position 2.b. Else, RedisStore inserts the key, get its position, and remove it within a transaction.
Result for the searc is a collection starting from the found position, ending only when a key above the end key is found from Redis
n-orm can be configured with store.properties files. This is an example for such a file with RedisStore :
# store.properties
class=com.googlecode.n_orm.redis.RedisStore
static-accessor=getStore
1=localhost #the Redis server host name
A second parameter can be added to state the server port.
Jedis is thread safe, but it has to use the JedisPool mecanism. However, Jedis asks to return the Jedis instance got from the JedisPool. In order to not pollute the backend with in its get from pool / return to pool code, an Aspect catches every call to Jedis, get a new Jedis instance from the pool and return it after the execution of the Redis command.
Moreover, if a command fails, the Aspect returns the Jedis instance to the Jedis garbage collector and relaunches the command.