录信全栈数据库的核心实现原理之将索引创建在hdfs之上

信数据库设计目标是必须能够支撑巨大规模的数据。要想实现这一目标要求其底层存储必须基于分布式文件系统，而绝对不能基于本地文件。Hadoop作为大数据时代的一个标志产物，能否基于HDFS之上创建索引，数据是存储在本地硬盘还是存储在分布式文件系统，对于一个数据库系统有着划时代的意义，是一个区分传统数据库与大数据数据库的一个关键的标致。

录信将索引创建在hdfs之上。

1.使用本地文件系统的各种弊端。

在传统数据库领域，如mysql、oracle、postgresql他们的一个共同特点就是将数据存储在本地，然后通过分库分表的方式来支撑更大规模的数据，在大数据出现之前，绝大部分底层数据库产品都这样管理数据。随着数据规模的增大，数据的管理、迁移、容错、快照、分裂、扩容、缩容等维护问题会变得越来越复杂，一台只有3~10个节点的数据库管理起来是很容易的，如果是节点数达到100台、1000台、10000台呢，这么多硬盘如何管控，他们出问题的概率越来越多，迁移维护变得很复杂。因此大家会看到在传统数据库领域数据存储在本地盘上的这种方式一般没有规模特别大的集群，常规也就三五台，一些业界顶尖的公司他的节点个数也就只能达到三五百台，但要借助昂贵的高可用的硬件，来减少硬件出错的概率。

从另一个角度大家可能会注意到某一天hadoop的到来，阿里腾讯作为先驱者，才意味着真正的大数据时代的来临，我们可以观察基于hadoop集群的节点规模能有多大？上千节点的集群我们可能都认为是一个小的集群，上万个节点的集群也随处可见吧，阿里、腾讯、移动的大云、百度等这些上万规模节点的集群也都不是什么新鲜事，hadoop在设计之初就是为了上万个节点而准备,而目前真正意义上能够有上万节点的集群非hadoop或类hadoop架构莫属，除此之外别的方案上千个节点的应该都没有几个。

2.感受下数据爆炸增长后使用本地文件系统的痛。

在腾讯我当时做的项目名称叫Hermes，Hermes一开始承接的是腾讯广告系统与微信的支付数据，最开始微信支付还是一个不起眼的项目，每天只有1~2亿的数据条数，但任何人都没有想到，就在短短不到半年的时间里，这个数据达到了500亿条/天。这在业界已经是一个相当大规模的系统了，我以为这可能是我职业生涯见过的最大的数据规模。没想到Hermes的下一个KPI就是承接腾讯50万台设备所有的消息与日志，1000亿、2000亿、3000亿、7200亿、到今天的破万亿，而这万亿并不是一个库里总的数据量，而是每天的数据量。谁也预测不到明天的数据量还会增加到多少，总之非常疯狂。我在腾讯hermes的这份工作经历给我积累的非常多的在大数据数据库领域的实际经验，也有特别多的教训。这其中最大的教训就是初期我们采用本地文件系统保存索引。

一开始在hermes项目初期的数据确实也像那些mpp数据库那样，数据是存储在本地的。但之后数据的爆炸式的增长，让我一度的处于崩溃的边缘，大量的索引需要管理，每天都要应对设备的扩容，硬盘的损坏