4 ms·

And more usually, you'll use the tool the tool that your most familiar with or can become most familiar [quickest]. You say so yourself, HBase is relatively har

And more usually, you'll use the tool the tool that your most familiar with or can become most familiar [quickest]. You say so yourself, HBase is relatively hard to quickly come to terms. We can observe the same when viewing the "SQL camp" with MySQL and PostgreSQL (and MSSQL). It is also true of the Facebook HBase install! Completely unnecessary jab; the use of HBase was politically driven -- what the architects wanted to use. What are the proofs that it was the "right tool?" Well, it works, but you won't find it behind Google's Gmail / Talk, so who knows!?

linuxhansl 14y ago
Hmm... Where to start. First, kindly point at an Cassandra installation, which supports the size that HBase supports in this setting. Can I assume you have first hand information about this decision from someone at Facebook? I was stating a fact... not a jab. Re: Google. Nothing at Google is driven by an eventually consistent store. They got that part right from beginning. It's too hard to manage from the an application point of view (unless you store immutable data, in which eventual consistency is pretty awesome). Checkout BigTable, Megastore, Percolator, Spanner. Except for the latter these are all based on BigTable. Note that BigTable is always consistent like HBase (and unlike Cassandra). Are you saying the MySQL is better than PostgreSQL (or vice versa?) because one is easier to setup than the other. That is a terrible way to pick a technology. Out of the box functioning is nice, easy to get started, makes the product look good in benchmarks, etc, but it just hides the complexity until you deploy into a production setting. Lastly, I agree that if you store the odd few TB here or there, you certainly do not need to bother with the complexity of HBase.
- jeromatron 14y ago
  Re: Facebook, as jbellis mentions in this comment thread, Facebook shards HBase, so it's not able to support what they need without some major additional complexity. Re: eventual consistency. It's tunable to the need of the user. It's a trade-off. Tunable consistency becomes nice when you want a system to be always available. See the Amazon Dynamo paper, on which Cassandra is partially based. I think many underestimate how many are using Cassandra in production. Spotify, eBay, Walmart, Netflix, Ooyala, NASA and others - one list is found here: http://www.datastax.com/cassandrausers http://www.datastax.com/cassandrausers.

linuxhansl 14y ago

Hmm... Where to start. First, kindly point at an Cassandra installation, which supports the size that HBase supports in this setting. Can I assume you have first hand information about this decision from someone at Facebook? I was stating a fact... not a jab. Re: Google. Nothing at Google is driven by an eventually consistent store. They got that part right from beginning. It's too hard to manage from the an application point of view (unless you store immutable data, in which eventual consistency is pretty awesome). Checkout BigTable, Megastore, Percolator, Spanner. Except for the latter these are all based on BigTable. Note that BigTable is always consistent like HBase (and unlike Cassandra). Are you saying the MySQL is better than PostgreSQL (or vice versa?) because one is easier to setup than the other. That is a terrible way to pick a technology. Out of the box functioning is nice, easy to get started, makes the product look good in benchmarks, etc, but it just hides the complexity until you deploy into a production setting. Lastly, I agree that if you store the odd few TB here or there, you certainly do not need to bother with the complexity of HBase.

jeromatron 14y ago
Re: Facebook, as jbellis mentions in this comment thread, Facebook shards HBase, so it's not able to support what they need without some major additional complexity. Re: eventual consistency. It's tunable to the need of the user. It's a trade-off. Tunable consistency becomes nice when you want a system to be always available. See the Amazon Dynamo paper, on which Cassandra is partially based. I think many underestimate how many are using Cassandra in production. Spotify, eBay, Walmart, Netflix, Ooyala, NASA and others - one list is found here: http://www.datastax.com/cassandrausers http://www.datastax.com/cassandrausers.