4 ms·
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 fi
by 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 agoRe: 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.