Hi Corbin,
Great question! We frequently get asked about the differences between Druid and other popular storage systems such as Cassandra. While Druid does share architectural similarities with other column-oriented distributed data stores, it is designed with some particular use cases in mind. We typically describe Druid as having 3 key differentiators in the data store space. It is highly optimized for scans and aggregations, it supports arbitrarily deep drill downs into data sets without the need to pre-compute, and it can ingest event streams in real-time and allow users to query events as they come in. At Metamarkets, we actually experimented with HBase as our core data store platform but it failed to achieve the speed and scale we desired. We found that in order to get the query latencies we wanted with HBase and to be able to arbitrarily drill into the data, we had to pre-compute permutations of dimension values of data sets. If schema of a particular data set changed, we had to recompute everything for that data set. The problem became computationally intractable. We actually wrote up a blog post on the subject if you want some more information:
http://metamarkets.com/2011/druid-part-i-real-time-analytics-at-a-billion-rows-per-second/#more-189. Don't get me wrong, HBase and Cassandra are great systems for certain use cases, but we found query latencies were too slow to power an interactive dashboard.
Interested in the technical differences between Druid and Cassandra/HBase? Read on!
Cassandra and HBase are extensible record stores that are partially modeled after Google's BigTable. Cassandra, similar to Amazon's Dynamo, has an eventually consistent data model. Writes are always supported but updates to data may take some time before all replicas synch up. Data reconciliation is done at read time. This model sacrifices consistency for availability and scalability. Druid, on the other hand, is fully read-consistent. Druid breaks down a data set into immutable chunks known as sgements. All replicants always present the exact same view for the piece of data they are holding and we don't have to worry about data synchronization. The tradeoff is that Druid has limited semantics for write and update operations. Although we support ingestion of events in real-time, updating an ingested event will require rebuilding the immutable block of data that houses the event. The cool thing is that we get read consistency in Druid without any sacrifices to availability and consistency.
There are some differences between Druid and Cassandra in terms of general cluster management, although I am not entirely sure which model, if any, is operationally simpler. Cassandra, as far as I am aware, follows the same P2P-like setup that Dynamo uses. All nodes in a cluster know about each other, and there is a membership protocol and data shuffling process for new nodes to announce themselves to the cluster. Nodes themselves are also in charge of failure detection. Druid has a shared-nothing architecture. Nodes are self-contained and self sufficient. They come online and announce their presence. Druid has a central coordination piece that is responsible for loading balancing, replication, and detecting failures. Druid nodes are for the most part, very simple. They do one thing really well: scan and aggregate data, and aren't really concerned with anything else. Really, it is just a difference between distributed vs centralized coordination and arguments and been made for both.
At the end of the day, Cassandra and HBase are really just key-value stores. If you want to put the key-value store model onto Druid, you can do that; the key would be the segment identifier, and the value would be a 1GB+ segment. Druid has all of its processing logic local to the storage layer. I am not sure if Cassandra supports 1GB+ values, but if it does, and if Cassandra provided the ability to push computation down the storage layer, you could probably re-implement Druid on top of Cassandra. But this goes back to the use case; I don't think Cassandra was really designed for that.
Hopefully this gives you an overview of the two systems.
Thanks!
FJ