Memcached is a distributed cache, implemented initially by LiveJournal. It is interacted with over TCP sockets, providing a set of sixteen commands - mostly variants of read/write operations, including some asynchronous write operations, which can be tangibly faster.
Memcached is an excellent example of a simple, cross-language read-mostly cache; it doesn’t support write-behind in and of itself, nor does it support event handling as a standard. This makes the typical memcached implementation unsuitable as a system of record and limits it to cache-only - which means that your initial read is limited by your actual data source, and introduces extra complexity to reads. In other words, it’s read-scalable – but not write-scalable, which is what many applications today need.
The typical read operation process looks something like this:
- Try to read the item of interest from the cache, by a generated or natural key - one book suggests using the full SQL query used to find the object, which sounds like SQL injection waiting to happen (See “Using memcached,” J. Finsel, p. 36)
- If the cache read fails (i.e., the key is not in the cache), read the item from a system of record
- Store the item into the cache by key
A write operation would be fairly similar, except you’d not check to see if the item was in the cache already - you’d write the item to the database and then to the cache, ensuring that the cache was current. Memcached provides a very primitive versioning capability via a secondary generated identifier for each cache entry.
With memcached, the client library is responsible for distribution. A typical client uses a list of hostname/port combinations, and determines at write/read time which actual memcached instance to use (usually based on the key, although it’s not formally defined.) Therefore, a given client library in one application could potentially distribute data across multiple memcached servers differently than another client library.
With GigaSpaces XAP 7.1.1, a space – a data and processing container, analogous to a Java EE server with an embedded database - can be deployed with the “memcached” schema, which means that the memcached protocol is supported for that space. A memcached client can then connect to that server with absolutely no code changes.
The benefits, though, are very noticeable: XAP can provide easy write-behind and initial load semantics for memcached, which means memcached is also write-scalable, provided that your read/write scenarios are nontransactional, as many are. The standard XAP interfaces provide transactions, of course, so you can mix and match transactions with nontransactional operations – something other memcached implementations do not support.
The typical XAP applications also benefit from memcached in that our implementation of the protocol – not supporting transactions – becomes very fast for simple write operations.
For example, an application might use the memcached protocol to write new events into a space: stock updates, for example, or RSS entries, neither of which needs a more complex usage than pass/fail. A transaction would work for these, but the transaction is slower (due to the nature of how transactions are implemented in Java) and the result is the same without the transaction: did this operation succeed or not?
The application can then use GigaSpaces’ event listeners to execute a workflow on the object, whether translating to a native GigaSpaces entry, or handling the event in some other fashion. It’s also possible for other GigaSpaces processes to create a cache entry without using a memcached write operation.
Our support for the memcached protocol also means that XAP is more easily accessible by even more languages. XAP has had C++, .NET, and Java support for quite some time, but memcached means that the native implementations of Python, Ruby, and PHP (for example) all have the ability to use a distributed, scalable, secure, and reliable storage mechanism for memcached.
With GigaSpaces XAP 7.1.1, GigaSpaces Technologies has shown its commitment to a wide range of protocols and use cases, and providing faster access to more clients. We hope you find the new features useful, especially considering the addition of system-of-record capabilities given to memcached, and we’re always interested in seeing how people use the technology in new and fascinating ways.