今天阎罗王提了一个需求,那就是他不想再用手写记录死亡记录了,它需要一个数据系统来简化管理。于是手下的小鬼火急火燎的找上了地狱最大的三家数据系统提供商HBAT(Hell BAT),让他们给阎罗王搞出一套数据系统,死命令,搞不好的话,统统滚去奈何桥,可怜的程序员们为了不提早来找阎罗王报道,不得不抛去成见,苦逼的开始干活了。
(以下是不负责任的脑洞大开,请勿模仿)
在开始开发之前,产品经理集合在一起分析阎罗王的需求。首先打开Helldu,查查每天的死亡率有多高,发现每天的写入量应该在几百亿,甚至更多,毕竟万物皆有灵,不过好在一旦写入了,这个数据就不会变更了(除非孙猴子再世),查询速度必须要强大,否则玉帝老爷,如来这些大佬异想天开想看看某个人的数据,要是等的太久,估计阎罗王自己就要记在Hell Data System(HDS)上了。在HDS里,所有生灵的死亡必须立即记录在案,也就意味着这必须是一个准实时的处理系统。小鬼们可没有那么多文化,说不定手贱记错数据了,那么必须要可以回滚。灾备也是必须的,要不亲爱的现世就要充满死而复生的人了。
最后,没最后了。。。。。感觉程序员再磨叽就要统统先上生死簿了。
那么,有了需求,我们就需要开始选择数据模型了,传统的行列模式就不适合了,要是为了查个数据还要关联那么多表,这么高的数据量下。。。好了,阎罗王的声音回响在耳侧。。。。文档模型就是你了,你就是天选之人。那么文档肯定要有主键吧,主键该如何选择呢?每天那么多的数据,名字肯定就不能用了,要不就把那个人的生平全部求hash生成一个特别特别大的数字吧,暂时就先定为128位吧,一定还要设计一个备用的生成方法,让它可以成倍数扩展位数。
选定了模型之后,那么存储文件的格式该如何选择。这个就简单了,为了节省存储空间,牺牲一点点查询效率,选一个带Schema的二进制格式吧。
好了,既然选择了文档的数据模型,又要查询数据速度足够快,那么就选择append-only的存储结构,LSM树吧。所有的数据均记录在log之上,要是删除数据了,就在给那个记录打个标记(HellStone),在每天夜里合并数据时,把数据干掉,那么那个人就死而复生了。