【巨杉数据库SequoiaDB】【演讲实录】分布式数据库海量数据存储和实时查询实现与应用

节选自OSC深圳源创会 演讲速记

分享嘉宾：巨杉数据库技术总监 乔国治
巨杉数据库，核心产品是SequoiaDB巨杉数据库。是我们的团队完全从零开始研发的。巨杉数据库是商业数据库，同时我们本身也将产品开源，我们是中国第一款商业开源数据库产品。

我们连续两年，获得美国硅谷的商业杂志《红鲱鱼》评选的全球创新企业100强，绝大多数是硅谷的企业，只有少数中国企业，这是对我们创新能力的认可。

这是2016年的硅谷大数据全景图，本图囊括当今世界上所有的科技企业，很多是大家耳熟能详的企业。在图中可以看到巨杉数据库，在本图中巨杉数据库是唯一一家中国企业。
这是我们的主要客户，可以看到以银行、政府企业为主，主要是大型商业企业，也有互联网企业。

1. 海量数据存储

1）分布式架构

这是我们巨杉数据库分布式数据库的架构。
谈到分布式数据库以及分布式的其他产品，必然会提到节点，无论你给这个节点起什么名字，在分布式系统里节点通常分为三大类：

第一类主要功能是为了接受应用发过来的请求，把请求分发到集群节点处理，这称之为协调节点，这基本上是无状态节点；第二类主要是保存原数据、关键信息等，并不负责保存真正的数据，在巨杉数据库内称之为编目节点；第三类是真正保存数据节点，在数据节点中，我们可以采取多副本机制，默认三副本，本身多副本之间有负载均衡、高可用的特征，如果某一个编目节点挂掉，保证其他节点可以快速接管服务。这是巨杉数据库的总体架构，在数据节点每一个节点都实施三副本，一主两从的方式，从节点保证数据冗余，保证数据不会丢失。平时写请求主要是由主数据节点完成，我们要保证两个从数据节点快速启动，使应用不受影响。我们在主数据节点发生故障，从数据节点会自动接管服务，不需要用户干预。

2）分区：

巨杉数据库的关键技术——分区概念，我们支持两种分区，一种是水平分区，另一种是垂直分区。当然还有混合分区，结合两种机制。

水平分区：

这里提到两个概念，一是集合空间（CS），二是集合（CL），我们基本数据存储单元是集合，可以等同于传统关系型数据库里的表，水平分区的概念是在集合里，可以选定一个字段或者多个字段作为水平分区的键（key）。

巨杉数据库会根据你选定的键或者键值，把数据对应到集合对应的所有分区。水平分区最大的好处是可以把多个节点组成复制组，你可以把数据均匀的分布到多个数据节点或者多个复制组，避免单一存储或者单一节点带来的瓶颈，对于分布式数据库来讲是必不可少的特性。

垂直分区：

垂直分区更多的跟业务逻辑相关，常见信息是流水表，如果你想保存银行过去10年甚至20年的交易流水表，这是海量天文数字的数据。因此，我们可以将庞大的数据从逻辑意义上区分开，按时间戳作为分隔的字段。
多维分区：

多维分区机制，把水平分区和垂直分区两种方式结合在一起使用。这跟垂直分区的图类似，在每一个子集合内部可以用水平分区，均匀打散到多个不同的物理存储上
2. 加速实时查询

1） 主、子集合

主子集合，分区等等的机制对数据查询能够起到什么作用和好处。通过分区方式，热点数据保存在单独的节点和单独的存储上。

好处是由于数据平台的访问和其他的数据不相关，有限的热点数据很容易被直接装在你的内存里，他被交换出去的概率非常小。针对热点数据的查询会有很大可能走缓存，而不是实际的物联，这对性能提升是非常关键的。
2）索引

针对查询的第二个基础手段，我们提供高性能索引，传统关系型数据库一直在用的。巨杉数据库用的单字段索引，也支持多字段索引，每一个索引都可以自己定制。

另外，针对索引我推荐用户把索引数据单独创建在指定的高性能存储上，比如SSD。在SSD上，它的性能会好很多。

3）读写分离

此外针对高并发查询的特性，我们有读写分离的策略，可以自定制数据的分布式策略。我们的数据节点默认三副本（一主两从），主节点是用来写的，从节点跟主节点之间通过最终一致性实现数据的一致。这时候如果有一个主请求刚好落在复制组上，巨杉数据库会把它自动分布到两个从节点中的一个，过程中完全不需要用户干预，这是我们内部自动实现的。
4）域

巨杉数据库有域的概念，可以把一部分节点定义成域，将来的结合建设在指定的域上。

这里建立了三个域，每个都有不同的节点和数据组，可以根据你的特征分布在不同的域上。有冷热数据的分离，通过主子结合的方式，你也可以通过这种方式实现冷热数据分离。这个域里针对冷数据，是相对低端的硬件、配置，另一个是热数据，可以用相对性能好一点的硬件。有些业务是强一致性的需求，有些业务是弱一致性的需求。有些是并发查询比较多，有些批量分析比较多，如果把两个放在一起，可以分别建在不同的域里，形成互不影响的效果。

5）压缩

巨杉数据库支持两种压缩模式，用户可以自己指定。大家说压缩更多的可能跟磁盘容量相关，为什么跟查询也相关。在IO吞吐量非常高的场景下，比如复杂的聚合查询，经常看见系统CPU非常高，意味着你的CPU很大一部分时间在等你IO的返回，一个查询下去要有100G甚至500G的吞吐量，如果采用压缩，数据吞吐量会减少，查询性能会有非常大的提升。

6）SQL

巨杉数据库引擎特点，我们面对更多的是企业用户，对企业用户来说，SQL是所有企业用户必不可少的需求，针对这种需求，我们提供了两种不同的SQL引擎，一种针对查询，另一种针对分析。针对查询，它几乎提供所有的SQL功能。如何实现巨杉数据库和Spark SQL之间的关联，只要部署连接企就可以在这里访问。在我们官网上都有介绍。

7）性能对比

这是实际性能对比，这是多伦多大学的数据库实验室，针对分布式数据库做了评测，橘色是巨杉数据库，绿色是MongoDB，蓝色是Cassandra。这个测试，他们搭建、写测试，整个过程没有原厂商的参与。结果在我们巨杉的官网上也有，这个链接有关于搭建过程的建模、数据测试过程。我们在个别领域跟其他两种相差无几，有得功能甚至领先很多，这是我们完全自己写的数据库，这是让我们非常自豪的性能。
3.应用案例

1）金融高并发查询

这个系统要保留中国有股市以来，所有股民和股票的历史交易记录。最终目标是让所有股民在任何时刻通过自助的方式（网页或者APP）的方式查询数据，这是天文级数据存储平台。一旦上线，它未来的目标所面临的并发查询量是很恐怖的数据。在中国，像我这样完全不炒股非常少，大家总会偶尔看一下股票。下面有数据量级，都是非常恐怖的。

我们以及MySQL的方案一起做评测，这是真实数据，我们基本上是MySQL的10倍左右，带数据的录入以及查询。我不记得具体的数据，在很多场景下，基本在并发查询方面，应该是5-10万笔的数量级，包括比较混合的产品，读写、更新全有；

2）银行历史数据管理

对于历史数据，我们举个例子可能会有直观的体会。如果你想拿一张卡或者存折，你去柜台查询过去5-10年的查询记录，大家没有关注过，但的确有这种需求。银行在线系统通常可以查3个月的数据，多的可以查1年的数据，更久之前的很难查到。

原来银行用的在线系统是昂贵的商业数据库的架构，比如小型机加DB2或者Oracle，这些数据库非常贵，扩容也非常贵。即使有这个钱，当数据达到一定量的时候，查询性能会有直线下降的表现。在线系统不会存那么多东西的，没有存的数据放在备份库，更久一点的数据可能放在磁带机上，作为冷数据保存。尽管数据没有丢，但也不能用，这让银行很苦恼。

我们用数据的分布式存储以及在分布式存储的情况下有很好查询性能的特点，帮助他们搭建历史数据平台，他可以把过去10年甚至20年的历史数据全部放在巨杉数据库的平台上，实现原来不能访问的冷数据激活了，不仅放在库里，而且变得可以用了。这是对巨杉数据库真实的检验，并且得到很好的效果。

3）政府数据湖

这是广州市政府政务中心的案例，他希望把过去市民各个部门要重复提交的数据，比如身份证照片、证件扫描件，放在统一的平台里，既方便市民不用去各个部门分别提交，也方便政府各个部门，因为他可以共享同一个数据。面临的问题是数据量比较大，它有1000多万的市民。不仅存储结构数据，也要存储非结构数据。我们还有另一种数据引擎是快存储引擎，非常类似传统数据库的二进制对象的存储，这两种引擎无缝衔接在同一个数据库里，使用起来非常方便。

4）交通大数据管理

这是结构化和非结构化联合使用的案例，数据量非常大，本身具有结构化数据，特别耗时间。也有非结构化数据，车流量拍摄下来的照片等等。这个数据量比想象的要大很多，大家平常不会关注这个。它本身是典型的海量存储的应用场景，而且是非结构化数据和结构化数据结合，它还有很多应用，有关部门要通过这些数据做很多查询、检索功能。巨杉数据库在数据量非常大的城市的交通系统，已经运行了大概一年多，目前效果非常好。

5）互联网行业

除了传统行业用户，在互联网也有成功的案例。资源系统以及套餐推荐，本身数据量非常大，后台使用的是巨杉数据库，使用了好几年，目前运行效果良好。

提问环节

Q1.系统最大支持多少TB的数据，设计上支持多少节点？

没有节点限制，我们在逻辑上没有限制，数据量也没有限制，只要你有资源、磁盘、机器都可以支持。实际中，在银行里现在做到历史数据平台达到2PB以上了。

Q2.跟MPP和Hadoop之间是怎样的？

它不是某一种产品，而是某一种技术。至于跟Hadoop，Hadoop本身是桥梁数据存储非常好的平台，它有很高的数据吞吐量，用在数据检索方面很困难。你可以用Hbase来做检索，但是它不支持多索引，你可以通过其他方式支持，使用起来不太方便。在并发性能上，我们可以很自信的说我们绝对比Hbase好很多。

Q3.MPP有网络风暴的问题？

对，这并不是哪家技术限制的问题，而是大家都会面临的问题，因为数据之间有复制、网络之间的交换，肯定会面对网络问题。我们建议用户在实际使用中至少使用千兆之上的网卡，最好能使用万兆网卡，这样网络就不是问题。

Q4.之间关于水平和垂直划分，能否理解为时分和子分，在地方和地址上。

时间划分是最典型的分析案例，可以这么理解，但是垂直分区并不是只有时间可以，你有全国几百个城市的数据，如果城市数据是均匀的，你可以用代码做分区。你可以这样理解，可以帮助你很好的利用。水平分区，它的本质是哈希值的均匀分布。关于查询索引，有没有什么更好的方法，当用户输入的数据不够用，并不是用户自己想的。

Q5.在你们开发过程中只展示了优点，我想知道缺点有什么？

缺点大家都有的。我觉得这个问题更多的是一种担心，每个厂商、产品都有自己的特别和不足，相对我们来讲，我觉得很多人的疑问，我们跟很多用户交流，我们本身是从头到尾自己开发的数据库产品，都是中国团队自己做的，这有一定的难度，意味着产品的成熟和完善需要时间，过程中一定会遇到大家的质疑。

很多人认为“中国人不可能自己做数据库，你才做了几年就可以用了。”我们研发数据库确实有挑战，这肯定是需要时间完善的，我们产品从开始做到最终向传统商业数据库似的成熟完善，肯定需要时间，目前还没到这个阶段，我们肯定会越做越好，我们的目标是达到传统成熟商业数据库的使用水平，过程中肯定会面对很多困难，希望得到大家对国产数据库的支持，谢谢！

Q6.我很早之前了解这个数据库，对于中国人来说，这个数据库绝对是比较先进的。包括阿里的，感觉这个数据库在技术上比较优秀。你的数据库底层有三部分存储，包括读写分离、冷热分离，如何保证在数据的一致性和性能，为了保证一致性，某种程度会牺牲性能。

感谢您对我们产品的认可，你谈到非常典型的CAP的问题，在P发生的时候，你是取C还是取A？这个理论被证实，不可能二者兼得。你保证了一致性，可用性就会降低，你提到多副本，三副本的情况下，我们是一组两从，在这种情况下有最终一致性，不是强一致。你可以理解为更偏向A，在C上有某种程度的降低，在一些非常极端的情况下。这只是默认的模式。本身我们的产品也提供针对C的技术手段，我们还是以三副本为例，我们可以支持写操作、写一副本，我们也可以支持写两副本、三副本，这可以自定义。每次写操作都是三副本，三个都写完再返回，这是一致，任何一个节点挂了都没有关系，除非三个都挂了。在这种情况下付出的代价是什么？A会有很大的下降，每次写入的性能会有很大的降低。你指定三副本，你的网络断掉，其中一个节点不能连通，这个写可能永远都不能完成，为了保证C，可能永远失去A，没有人可以C和A兼得。如果你想在某一方面达到这家，必然牺牲另一方面。

Q7.简单谈谈你在哪些方面做的优化？

对于HBase我理解它为一个列存数据库，所以作为行存数据库里有很大天然的问题，一旦与查询相关，它会比较差，这是列存数据库天然的弱势。我们公司研发团队都有企业级产品的基因，写代码的时候会把性能和企业级的性能放在第一位，这是固化在他脑袋里的东西，所以他每写一行代码，自主不自主的会考虑这个问题。关于MongoDB，我觉得Mongo做得比较好的是他对使用者的应用型很好，但是性能一开始不会那么好，但他们在不断改进，不断推新版本，性能在逐渐改进，但有一些天然的差距。也许未来某一天会改变，我们跟Mongo相比不相上下，我觉得这是好事，大家互相竞争，共同成长。

更多演讲实录

【视频】分布式数据库如何存储管理非结构化数据

【演讲实录】企业级NewSQL加速企业大数据落地

SequoiaDB巨杉数据库王涛：使用JSON模型优化数据拉链表

巨杉数据库王涛：SaaS生态与大数据