脑洞大开之给地狱设计数据系统(上)

今天阎罗王提了一个需求，那就是他不想再用手写记录死亡记录了，它需要一个数据系统来简化管理。于是手下的小鬼火急火燎的找上了地狱最大的三家数据系统提供商HBAT(Hell BAT)，让他们给阎罗王搞出一套数据系统，死命令，搞不好的话，统统滚去奈何桥，可怜的程序员们为了不提早来找阎罗王报道，不得不抛去成见，苦逼的开始干活了。

（以下是不负责任的脑洞大开，请勿模仿）

在开始开发之前，产品经理集合在一起分析阎罗王的需求。首先打开Helldu，查查每天的死亡率有多高，发现每天的写入量应该在几百亿，甚至更多，毕竟万物皆有灵，不过好在一旦写入了，这个数据就不会变更了（除非孙猴子再世），查询速度必须要强大，否则玉帝老爷，如来这些大佬异想天开想看看某个人的数据，要是等的太久，估计阎罗王自己就要记在Hell Data System(HDS)上了。在HDS里，所有生灵的死亡必须立即记录在案，也就意味着这必须是一个准实时的处理系统。小鬼们可没有那么多文化，说不定手贱记错数据了，那么必须要可以回滚。灾备也是必须的，要不亲爱的现世就要充满死而复生的人了。

最后，没最后了。。。。。感觉程序员再磨叽就要统统先上生死簿了。

那么，有了需求，我们就需要开始选择数据模型了，传统的行列模式就不适合了，要是为了查个数据还要关联那么多表，这么高的数据量下。。。好了，阎罗王的声音回响在耳侧。。。。文档模型就是你了，你就是天选之人。那么文档肯定要有主键吧，主键该如何选择呢？每天那么多的数据，名字肯定就不能用了，要不就把那个人的生平全部求hash生成一个特别特别大的数字吧，暂时就先定为128位吧，一定还要设计一个备用的生成方法，让它可以成倍数扩展位数。

选定了模型之后，那么存储文件的格式该如何选择。这个就简单了，为了节省存储空间，牺牲一点点查询效率，选一个带Schema的二进制格式吧。

好了，既然选择了文档的数据模型，又要查询数据速度足够快，那么就选择append-only的存储结构，LSM树吧。所有的数据均记录在log之上，要是删除数据了，就在给那个记录打个标记(HellStone)，在每天夜里合并数据时，把数据干掉，那么那个人就死而复生了。