By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.