« Stuff The Internet Says On Scalability For January 28, 2011 | Main | Google Pro Tip: Use Back-of-the-envelope-calculations to Choose the Best Design »

Comet - An Example of the New Key-Code Databases

Comet is an active distributed key-value store built at the University of Washington. The paper describing Comet is Comet: An active distributed key-value store, there are also slides, and a MP3 of a presentation given at OSDI '10. Here's a succinct overview of Comet:

Today's cloud storage services, such as Amazon S3 or peer-to-peer DHTs, are highly inflexible and impose a variety of constraints on their clients: specific replication and consistency schemes, fixed data timeouts, limited logging, etc. We witnessed such inflexibility first-hand as part of our Vanish work, where we used a DHT to store encryption keys temporarily. To address this issue, we built Comet, an extensible storage service that allows clients to inject snippets of code that control their data's behavior inside the storage service.

I found this paper quite interesting because it takes the initial steps of collocating code with a key-value store, which turns it into what might called a key-code store. This is something I've been exploring as a way of moving behavior to data in order to overcome network limitations in the cloud and provide other benefits. An innovator in this area is the Alchemy Database, which has already combined Redis and Lua. A good platform for this sort of thing might be Node.js integrated with V8. This would allow complex Javascript programs to run in an efficient evented container. There are a lot of implications of this sort of architecture, more about that later, but the Comet paper describes a very interesting start.

From the abstract and conclusion:

This paper described Comet, an active distributed key value store. Comet enables clients to customize a distributed storage system in application-specific ways using Comet’s active storage objects. By supporting ASOs, Comet allows multiple applications with diverse requirements to share a common storage system. We implemented Comet on the Vuze DHT using a severely restricted Lua language sandbox for handler programming. Our measurements and experience demonstrate that a broad range of behaviors and customizations are possible in a safe, but active, storage environment.
Distributed key-value storage systems are widely used incorporations and across the Internet. Our research seeks to greatly expand the application space for key-value storage systems through application-specific customization. We designed and implemented Comet, an extensible, distributed key-value store. Each Comet node stores a collection of active storage objects (ASOs) that consist of a key, a value, and a set of handlers. Comet handlers run as a result of timers or storage operations, such as get or put, allowing an ASO to take dynamic, application-specific actions to customize its behavior. Handlers are written in a simple sandboxed extension language, providing properties of safety and isolation.

We implemented a Comet prototype for the Vuze DHT, deployed Comet nodes on Vuze from PlanetLab, and built and evaluated over a dozen Comet applications. Our experience demonstrates that simple, safe, and restricted extensibility can significantly increase the power and range of applications that can run on distributed active storage systems. This approach facilitates the sharing of a single storage system by applications with diverse needs, allowing them to reap the consolidation benefits inherent in today’s massive clouds. 

Related Articles 

References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments (4)

Did you note that both Comet and Alchemy Database use Lua as the embedded code language? hardly a coincidence...

January 27, 2011 | Unregistered CommenterJavier

Yep, Russell is a very big fan of Lua, so I think he'll get a kick out of this.

January 27, 2011 | Registered CommenterTodd Hoff

That's an interesting idea, however I don't quite see how it addresses the one store - n apps issues. If you add one application, then you have to upgrade all your objects' code? How do you know you're not overwriting some critical rule inside one particular object's get/put handlers? What about fixing bugs in the handlers?

Good old database triggers are deemed dangerous because of their hard-to-debug side effects, but at least they're defined per-table and not per-object instance...

NB : I've only read the slides, not the paper

January 31, 2011 | Unregistered CommenterThomas

Sadly, the term 'comet' is already a very popular term in the tech world, referring to 'server-push' type communication over HTTP.

I wonder if the author was aware of this or not. If not, I'm surprised since it's mentioned a lot in multiple tech blogs and appears multiple times on page 1 Google when searching for 'comet'.

February 7, 2011 | Unregistered CommenterRobert Schultz

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>