Facebook: Why our 'next-gen' comms ditched MySQL | Hacker News Reader

Facebook: Why our 'next-gen' comms ditched MySQL

channelregister.co.uk

68 pointsyarapavan16 comments

Open articleView on HN

It doesn't sound like MySQL was ever in the running.

Why would it be? It's just not designed for this sort of job.

Right; it was more a comment on the headline than the content.

The one good thing to take out of this is that Facebook made a measured decision, and ran with the best technology.

So easily (as many companies do) they could have taken a 'not invented here' decision and run with Cassandra.

Why does this article contain the word "interwebs"?

This website is a derivative of "The Inquirer", which is known for its annoying jargon.

Actually the Inquirer "derived" in a sense from The Register, in that they were started serially by Mike Magee. I discover from Wikipedia that Magee has now gone on to found a third web magazine ...

https://secure.wikimedia.org/wikipedia/en/wiki/The_Register#...

It's cool that Facebook uses HBase. But Looking at the HBase documentation at http://hbase.apache.org/docs/current/api/org/apache/hadoop/h... all the calls to Put, Get, Result, Scan, etc. have repeated calls to Byte.toBytes() to convert a string to bytes. Is there some peculiar reason why the API doesn't also have methods which take a string and do the byte conversion internally?

Many users of HBase (including ourselves) use different, more efficient encoding of values into byte arrays than converting them to String's first, then byte arrays. For example, it's common to use protobuf to encode an object into a byte array for storage in HBase.

Rather than have 2 copies of all the api methods (one for people storing just Strings, and one for arbitrary byte arrays), it's simpler to have a single call and let the caller use the Bytes.toBytes method if they want to store a String.

That makes sense for the values, but the names of rows and columns are also passed as bytes. Wouldn't a convenience function that accepts strings, performs the Bytes.toBytes() conversion and calls the original method reduce code clutter?

The same thing applies to rows and columns. We don't use any simple strings for our row or column indexes. They are serialized objects.

Earlier versions of the API actually did have String based versions, and were changed to just byte arrays to reduce clutter.

Interesting, that makes sense then.

It looks like HBase developers were working hard to design the most verbose API possible ;)

I like that they prototyped and measured. Also: for messaging FB needed consistency; for some applications Cassandra would make more sense.

It's a huge vote of confidence for HBase that the creators of Cassandra would choose it and its simple strong consistency model.

already submitted http://news.ycombinator.com/item?id=2018656

http://www.theregister.co.uk/2010/12/17/facebook_messages_te...

Reply on news.ycombinator.com