Let’s first clarify what a key/value store and an object store are. Using the traditional block storage interface, one has a series of fixed size blocks which are numbered starting at 0. Data must be that exact fixed size and can be stored in a particular block which is identified by its logical block number (LBN). Later, one can retrieve that block of data by specifying its unique LBN.

With a key/value store, data is identified by a key rather than a LBN. A key might be cat or olive or 42. It can be an arbitrary sequence of bytes of arbitrary length. Data (called a value in this parlance) does not need to be a fixed size and also can be an arbitrary sequence of bytes of arbitrary length. One stores data by presenting the key and data (value) to the data store and can later retrieve the data by presenting the key. You’ve seen this concept before in programming languages. Python calls them dictionaries, Perl calls them hashes, Java and C++ call them maps, etc. Several data stores also implement key/value stores such as Memcached, Redis and CouchDB.

Object stores are similar to key/value stores except that the key must be a positive integer like a LBN. However, unlike a LBN, the key can be any positive integer; it does not have to map to an existing logical block number. In practice, it is usually limited to 64 bits. More like a key/value store than the traditional block storage interface, data is not limited to a fixed size block but may be an arbitrary size. Object stores also allow one to associate a limited set of attributes with each piece of data. The key, value and set of attributes is referred to as an object. To add more confusion, sometimes key/value stores are loosely referred to as object stores but technically there is a difference.

Applications tend to work with data of different sizes and work hard to fit it into the traditional block storage paradigm. In the process, their data becomes fragmented and they need to perform garbage collection. Due to the nature of Flash, it also needs to perform garbage collection. By coordinating both garbage collection efforts, key/value and object stores can reduce the amount of data that is copied thus increasing performance and reducing wear on the Flash. Key/value and object stores are an ideal match for Flash.

GigaSpaces XAP uses an underlying key/value API to manage its data in RAM. A traditional integration with external data sources has to go through costly mapping layer and often requires additional serialization/deserialization. The fact that SanDisk’s ZetaScale exposes a key/value interface eliminates impedance miss-match that exists with traditional external data sources. This results in a 100 times faster data swapping between RAM and flash.
Read More here http://docs.gigaspaces.com/xap100adm/blobstore-cache-policy.html

Were Flash, Key/Value and Object Stores Made for Each Other? – Guest Post by Johann George, SanDisk
Team GigaSpaces IMC on FacebookTeam GigaSpaces IMC on GoogleTeam GigaSpaces IMC on InstagramTeam GigaSpaces IMC on LinkedinTeam GigaSpaces IMC on TwitterTeam GigaSpaces IMC on Youtube
Team GigaSpaces IMC
We bring you the hottest updates and news on XAP, our in-memory computing platform for high performance transaction processing leveraging in-memory and flash/SSD storage technologies to address agility, web-scale and high-availability challenges for mission critical systems. Contact us to learn more!