[ot]

> This makes the decision of Facebook to go with HBase for their new messaging platform back in 2010 all the more strange.

Speed isn't everything to a database. AFAIK they chose HBase over Cassandra because of consistency guarantees: eventual consistency is a bad choice for a messaging platform.

[erichocean]

eventual consistency is a bad choice for a messaging platform

Strange you would mention that in the context of Cassandra, since it allows for per-read/write configuration of consistency, from "eventual" to "strong". You get exactly what you ask for with Cassandra, whether its availability or consistency.

AFAIK, HBase only supports strong consistency.

[dialtone]

This is not the main reason people would choose HBase. For time series data HBase is much better at load balancing the data and at storing the same data in sequential blocks so that in a single operation you can fetch all of the data points that are interesting. Cassandra supports range queries but the last time I saw it wasn't super awesome at load balancing data across nodes when using the OrderedPartitioner. Do I remember wrong?

[jbellis]

Time series works very well on Cassandra. If anything, avoiding global-ordering hot spots is a Good Thing.

http://rubyscale.com/blog/2011/03/06/basic-time-series-with-...

http://www.datastax.com/dev/blog/advanced-time-series-with-c...

http://www.youtube.com/watch?v=F-fYqPu2ciQ&feature=youtu...

[dialtone]

Does Cassandra support Range queries with the RandomPartitioner now?

[jbellis]

Within a partition, yes.

[linuxhansl]

I won't put too many words into the mouths of the Facebook fellows, but I meet with them every now and then, and they very much care about "speed" (latency and throughput, best and worst case).

This paper does not reflect what I have seen in production setups.

Disclaimer: HBase developer here.