Working on one of very few Google products that's backed by MySQL (yes, King of Scalability uses MySQL as well), I can understand NoSQL very well. During the lifespan of a large system, new features constantly pose requirements for schema/index change, and this is where rigorous schema cause a lot of pains. At the time the data schema grows complex enough, schema change becomes bottleneck of productivity in launching new features. At the same time, real world large scale relational database are sharded onto distributed nodes. Benefits of relational database like referential integrity and join-queries do not apply to such environment.
It seems FrindFeed first did a bit of homework on off-the-shelf schema-less storage solutions(e.g. CouchDB). But lack of real word large scale success story gave them little confidence. So they decided to cheat by disguising our old friend MySQL into a cooler NoSQL storage. The idea is simple: separate index from data. To do this data is modeled as structure-agnostic entities (e.g. feed, user), stored in a single Entity table indexed by entity ids. To index by attributes of entities (e.g. owner of feed, name of user), each index is implemented by separate EntityIndex table. Since EntityIndex and Entity are sharded differently, entities and corresponding indexes may reside in different physical shards. Inconsistency between indexes and entities caused by cross shard update/insert/delete are solved by two rudimentary rules - entity data is canonical; query result are double checked by client using same matching criteria. Well they got what they wanted, a schema-less DB and reduced latency.
And here comes my 2 cents. UUID as index of entity table is a waste. Entity table may want to use more meaningful keys to as index. Clustering and space efficiency are a few benefits to do it. For example, feed entity may have a clustered/primary key of $publisher_id+$publish_time. Having a cluster key enables database store all feeds belong to same publisher as part of the index, making certain queries (range, sequential) much more efficient. On top of that it saves at least on index table per entity types.
Given everything else the same, the simpler the better. But what aboutcompound keys? There're situations where compound keys are necessary e.g. feeds of all fans published last month. They can either use single index and filter result in memory; or implement composite keys by adding multiple columns to index tables. None of the two seems pleasant.
UPDATE: Just learned from a blog post Mike Shroepfer on Engineering at Scale at Facebook, Facebook uses a similar approach to convert MySQL to pseudo schema-less DB. Seeing them going through so much trouble and creating so many (clever) hacks to scale up their systems, I feel lucky to work at Google , where scalability is planned in first minute of design, with all the mature and evolving components available, almost everything seems to scale naturally.
Posts
