用NOSQL数据库完成事务处理

个人简介 王涛曾经是DB2领域的专家，作为IBM DB2全球最高技术专家小组的成员，参与了IBM下一代大数据平台的架构规划，精通数据库内核及体系结构。在IBM多伦多实验室工作了八年后，王涛选择了回国创业，目前担任巨杉软件公司CTO及总架构师，成功研发了自主产权的NoSQL数据库——SequoiaDB(巨杉数据库)。

全球架构师峰会（International Architect Summit，下简称ArchSummit）是由InfoQ中文站主办的一次全球性架构师峰会。ArchSummit专门针对架构师人群，讲述与架构和架构师相关的各方面趋势、技术和案例。这也是继QCon之后，InfoQ中文站主办的又一次高端技术盛会。

   

1. 大家好，欢迎来到全球架构师峰会2014北京采访现场，坐在我面前的是来自巨杉数据库的王涛，王涛跟大家打声招呼。

王涛：我叫王涛，来自巨杉数据库SequoiaDB。我之前在IBM的多伦多实验室做DB2关系型数据库。现在我们在做NoSQL的数据库，是文档类的数据库。与关系型数据库比起来，它是一个可分布的、高性能，同时可用文档类数据模型取代传统关系型数据模型。今天我们很有幸来到InfoQ现场，正式宣布开源，希望能够和所有朋友一起把社区做好做大。

   

2. 现在在国内做数据库，或者国内基础软件领域，开源并不是主流。你们是出于什么原因和情形下最后选择开源呢？

王涛：开源本身就是未来数据库和基础软件的发展趋势，像Oracle、DB2出售license的这种模式已经越来越不被用户所接受了。用户的系统种类繁多，系统越来越复杂，按照CPU按照核来收费这种模式非常痛苦。一方面，开源可以使企业对软件更有控制力，更好的把控软件底层；另一方面它也可为企业节约成本，比如企业可以把最核心的生产系统，用Subscription等订阅方式来购买企业级服务，然后对于一些测试或者沙盒系统采用开源的东西就可以搞定了——这种方式可以为很多企业节省一些成本。

   

3. 从你们自身来讲，选择开源会不会产生一些不好的影响？比如说大家用了你们的东西，改了以后也不回馈社区，你们是怎么评估我们所说的这些潜在的风险？

王涛：实际上这是一个开源协议的选择问题。我们选择的是AGPL协议，这种协议相对来讲比较严格：如果用户可以随意在自己的系统里使用开源产品，但如果用户基于这个产品做了定制或大量修改，想把它包装成另一个产品的话，我们希望他可以回馈社区，让大家一起看到他的成果，一起来分享。

   

4. 作为一个NoSQL的数据库来讲，很少有NoSQL数据库宣称自己还可以处理事务，因为大家传统上认为这个是跟关系型数据库的一个分界点，当初你们为什么会选择实现事务这样的关键功能？

王涛：我觉得NoSQL和SQL并不是完全对立的。最初由于关系型数据库解决不了一些公司遇到的问题，才有NoSQL，适用于只做分析不需要做事务的应用场景，如Cassandra、Facebook诞生的时候。但在有些场景里，事务的功能并不能完全被舍弃，如一些互联网企业里——旅游类企业——它有一些产品包，每个产品都会有剩余票的数量，在用户购买打包旅游方案时，程序要对每个不同的产品做加减，涉及到多个元素的操作，假如某一个元素的票卖完了，它需要做一个回退把其他票再退回去。现在大家可能用MongoDB来处理这种情况，但用起来有点麻烦，因为他们需要自己在应用里去维护这套东西。

   

5. 就是他们自己要做一个两步提交或者类似的机制，去保证这种连续性。

王涛：没错，但在应用里去做这种东西是极为复杂的。如果一个简单的提交和一个确认，这个不是很复杂，但如果想把它做到和传统数据库很精确的强一致，基本上在应用层面是非常难以实现的。

   

6. 所以说数据库才能卖那么多钱。

王涛：因为我是DB2出身，对于事务还算有些了解。我们觉得，如果一个NoSQL想要通用化，事务是不能舍弃的。我们现在看到很多其他的NoSQL数据库也开始支持事务了，有一些甚至可以跟SQL对接，这块也是我刚开始说的， SQL和NoSQL不是永远对立的事情。我认为NoSQL诞生要解决的主要问题就是做一个分布式的数据库存储，但是这个分布式的数据库存储跟上层用什么接口并没有直接关系。比如传统的MPP数据库用SQL做起来的话，在性能上、大规模的关联上是有性能瓶颈的，所以大家就不用关联了，开始采用NoSQL API的方式。但我认为随着时间的推移，当分布式的系统越来越成熟，接口上一定会变为多接口，包括API的类型，包括SQL的类型，还有可能会出现其他如REST这种类型，最后会形成一个统一的分布式数据平台，所以我不认为SQL和NoSQL两个是截然不同的阵营，我认为他们未来会融合。

   

7. 从技术这个角度来说，做transaction必然有一致性的问题，像NoSQL基本上是一个分布式的系统。分布式系统的一致性是件非常难的事情，你们解决这个问题有什么亮点吗？

王涛：分布式系统的一致性，首先ACID里面的C是一种一致性，CAP里面的C又是另一层面的一致性。CAP里面的C，一般是在一个多份数据写入的场景下，比如我读写入的这个副本，和我读另外一个副本，中间可能有延迟，这可以用WRN的方式来解决：N包括要写几个节点，W就是写几个成功，R就是读几个成功，一般来说，只要W+R>N，那就是一个强一致了。所以只要我们能够控制读的成功份数和写的成功份数，我们就可以来操控CAP里的C到底是不是一个强一致，还是最终一致。另外ACID的C指的就是我的数据，不合法的数据不能被写入，这一块需要数据库的引擎内部有完善的机制，比如像唯一键的索引这种限制：你要确定，凡是违背这个限制的数据是不能被写进去的。另外在分布式里面可能还涉及到二段提交、三段提交，这些问题我们现在用的是二段提交机制，这些肯定我们都会慢慢把它完善支持。

   

8. 说起巨杉，大家容易联想到MongoDB。业界对MongoDB有一些公认明确的缺点，但是也有很多人对这些缺点进行了有效的改进，比如TokuMX，它也宣称它支持很多的特性，如说支持事务、支持数据压缩、改善了存储引擎，巨杉又具体做了哪些有亮点的工作呢？

王涛：我觉得Toku确实是一个挺优秀的引擎，它相当于把MongoDB的壳拿过来，把自己的存储嵌进去。我们跟它不太一样的地方是，我们在最开始开发的时候就没有利用这种开源的数据库的壳，我们所有东西都是自己开发出来的。这一点对我们来讲一个最大的优势是，我们能够非常有效的控制自己代码的发展方向，比如对于TokuMX，有可能今天MongoDB底层的核是这个样子，可能过一段时间这个核就变化了，它需要做大量的适配，有可能滞后的话，而某种特性又不符合它原来的特性。

   

9. 像Toku最核心的技术是分形树索引，那巨杉比较有特色的最核心技术有哪些，方便说吗？

王涛：比如说像事务的机制，对数据一致性的保障，应该是我们和其他NoSQL不太一样的地方。很多NoSQL都是针对性能做了无数的优化，但是性能优化再多，可能跟很多数据库比起来并不是一个本质的变革。我们认为对于一个永久性的存储而言，数据的一致性是最关键的。很多数据库只支持最终一致性，可能会有数据崩溃，可能会机器崩溃丢数据，这在很多场景下是完全不可接受的。我们巨杉在数据一致性的保护上做得比较有特色，我们能够确保数据不管怎么样崩来崩去，在各个节点上数据一定是一致的，不会产生任何的区别。

   

10. 你做的这种transaction，是不是更倾向于传统上ORTP的应用呢？

王涛：Transaction是一个可开启的功能，为了性能起见，我们默认上是把它关掉的。我们并不只是为支持传统LTP而做的transaction功能，而是希望给用户一个额外的选择。如果用户有需要就开启，并且我们的开启不是针对整个集群，要开全开要关全关，我们是可以针对节点。

   

11. 开启这个功能需要重启吗？

王涛：目前是需要重启的。这个功能大家也不会经常开关，在配置的时候，可以提前设计好几台机器做跟交易相关的，其他是做日志相关。

   

12. 我们能不能理解，你设计的巨杉数据库，既适用于TP的场景，也适用于AP的场景？

王涛：现在很多所谓的大数据框架，实际上是把计算和存储分成两层：计算层在上面，有Hadoop、Spark、Impala之类的，底下的存储层有HDFS、HPACE或者各种NoSQL。我们把框架分成OLTP和OLAP。我觉得更主要的是计算层，尤其是OLAP，上面可能有很多分析函数，以前大家把它搁在上面Spark层，比如说（14：20），对接东西相对来比较透明。但OLTP要求底层存储响应速度非常快，如果只是使用HDFS这种机制，底下没有具体数据结构能快速定位到某一条记录就有问题了。数据库自身针对的还是对高性能的访问，所以要做这种分析类的话，我们在上层对接了一个专门的分析引擎、计算引擎，这样才能把它做到最完美。

   

13. 现在支持SQL的引擎很多是比较国际性的，你们的这个引擎支不支持中文？

王涛：这个一定是要支持的，现在我们在支持SQL。我们走的这条路可能是比较取巧： PostgreSQL的FDW在9.3.4之后支持外部表增删改查，我们跟它做了一个对接。我们使用了它的FDW接口，相当于我们在PG里定义了一个外部表，指定数据源在我的SequoiaDB上。然后对这个PG提供一个我的驱动，就是一个连接器，它可以通过这个连接器，直接把请求下压到我的数据库，从里面读数据做关联。这样的好处是，我可以通过PG和任意不同的数据源甚至它自身的数据源进行关联。

   

14. 如果我们上面用了PG倒好理解，但从SQL的标准来说，它是一个非常完整的支持吗？

王涛：对，对于PG来讲它是标准SQL。我们数据库实际上是不需要任何SQL关联的，所有的解析全是在PG里面做好，然后把对单表的请求下压到数据库就行了。

   

15. 实际上你们做的是存储那部分的事情。简单来说，这种取巧的方法是不是不那么NoSQL呢？

王涛：倒也不是，像我们刚才讲的，NoSQL跟SQL不是一个对立的东西，不是说我有了SQL我就不叫NoSQL了。NoSQL最关键的是能用一个分布式的机制，很高性能的方法和方式，把数据有效的存解出来。

   

16. 既然谈到分布式，对于传统分布式的NoSQL而言，怎样把数据更均衡的分布到节点上是比较难做到的。Cassandra宣称它有跨数据中心方案，但这种方案对它自身的设计有非常的大挑战，如在数据进行节点恢复当中，会有rebalancing的问题，怎么能更加平衡呢？然后最后又会导致一些数据的风暴，你这方面的设计上是怎么一个参考和考量呢？

王涛：我觉得这个问题应该分为两部分，一部分是怎么样做数据的均衡，一部分是怎么样做跨数据中心的DR。

   

17. 先简单地说，有没有考虑跨数据中心的问题？

王涛：当然有，这是必须的。均衡的问题，我们实际上用的是一致性散列。当一个表需要做分片的时候，它制定一个或者几个字段做分片字段，对这个分片做一个（18：26），将哈希出来的一个值影射到一个范围上。比如说0到100万、1000万，我们会对这个数字取多个段，并分别放到分片上。当数据节点增加后，其中已有的一些段的部分数据会被分过来，这样可以避免你刚才说的数据风暴。而传统的做法用DB2，每要新增节点，都要做一个重新分布。

   

18. 重新分布的话，会有大量的数据迁移。

王涛：这是非常恐怖的事情。实际上除了我们，Cassandra也在用同样的机制，这个叫做一致性哈希。这种机制能够确保有新的节点进入时，只用移动最少量的数据。你该移动的数据移到这个节点，其他节点的数据完全可以不用动。

   

19. 但Cassandra还有像虚拟节点的这种东西，Cassandra解决一开始并没有那么好，后来才解决的那么好，你现在这方面已经有跨数据中心的应用了吗？

王涛：你说的跨数据中心主要是DR的问题，跟数据中心没有直接关系。添加节点一般是在同一个数据中心里做。而跨数据中心主要解决异地灾备问题，比如说像银行里的两地三中心，或者像北京、上海双机房，使用的是数据分片复制机制，把一个数据库打成十个数据分片、分区，每个分区分别指定复制分区，放置到异地。跨数据中心很大的需求是数据中心之间的带宽非常宝贵，所以数据中心之间的复制数据一定要经过压缩，并且只能有一份。我们现在这种机制能够确保两个分片之间数据通道只有一份，并且经过压缩，在数据中心内部的话，它里面去做HA都可用。它是自动完成模式，这套机制我们已经开发完了，会在春节的一个版本里正式发布。

   

20. 大部分做数据库的人都在国外，你为什么跑回来了呢？你做这种底层数据库在中国好招人吗？

王涛：很多做数据库的人在国外，这是一个真命题。但我们现在和五年前的状况不一样了，五年前在国内完全没有数据库人才，但是现在我们有很多互联网团队，都在研究各种开源的技术，包括PostgreSQL、MySQL，还有阿里巴巴自己做的OceanBase，以及华为的很多团队自研了很多内部用的一些数据库。我觉得现在有越来越多的人开始接触底层的数据库软件，我们也发现在中国找数据库专家，至少比两年前要多不少，我觉得是很有意思的一个事情。

   

21. 你是不是觉得中国的DBA比外国的要多一些？

王涛：DBA我不知道，因为我们主要招的人都是开发级的人员。

   

22. 因为整个数据库的基础还是国外实力比较强一些，国外有些非常学院派的人，如VLDB这种，都是在国外。在国内做这种基础研究方面的人相对少一些，所以你们会不会有招聘人才的问题？毕竟数据库对技术含量要求还是非常高，你要引入很多非常底层的这些人才，可能需要他在学术上有很强的背景，你是怎么考虑的？

王涛：招聘人才肯定是每个公司都面临的最大的问题。传统的关系型数据库，往往是先有非常完善的学术理论，数学模型建立之后再研发出来的，如PostgreSQL。NoSQL完全是从互联网实战出发，先解决用户亟需解决的问题，然后做理论扩张和完善，丰富产品功能，逐步向传统的数据库靠拢。我觉得我们NoSQL应该走的是这条路，以解决用户的问题和困难为导向——先解决问题，再来汇总归纳，自成一套体系——而不是先要实现某一个学术理论。

   

23. 我们回头来说NoSQL，在NoSQL这个领域，MongoDB无疑是商业上最成功的，如果我们抛开它的技术从其他方面来讨论，你认为商业数据库还有哪些地方要直面MongoDB？

王涛： MongoDB的市场做得非常好，从某种意义上来说，我们所有做NoSQL的兄弟都应该感谢它，因为它教育了全球的用户，让全世界都知道NoSQL这个产品。包括国内用户，不管是互联网还是传统行业，只要是对数据库NoSQL稍微有了解的，至少都知道MongoDB。我们跟MongoDB比起来，最重要的是本地的技术研发支持力量不同。国外的产品不会以中国为一个核心大本营，用户在用MongoDB需要购买技术支持时，它在国内根本没有这种团队；即使能购买到技术支持，也是跨国支持，会有语言、时区障碍。但是我们不同，我们本身base在中国，所有的开发团队都在国内，比较大型的项目，我们可以直接把开发人员派驻到客户现场。我觉得这种技术支持能力、及时交流文档的能力，应该是MongoDB在中国这片土壤上可能还不具备的。

   

24. Martin Fowler讲现代企业家要设计的时候，认为不同的应用要用不同的数据库，甚至因为不同的应用场景，一个应用要用很多种数据库。你能列举一个巨杉数据库最适合的典型场景吗？

王涛：实际上大部分场景都适合MySQL。我们当初选择做文档类数据库的原因之一，就是我们不想做一个小众的产品，我们希望能做一个比较通用的产品，满足广大用户的需求。但同时我们会在底层采用一些机制，如说可插拔的数据库引擎之，来满足一些特定需求用户场景。

   

25. 另一个我们比较关心的是知识产权的问题。数据库领域已经是被大佬长期占据的一个领域，有着大量的技术专利掌握在大佬手里，巨杉会不会面临着潜在的专利风险？

王涛：应该是不会的。我们做的毕竟不是一个关系型数据库，如果我们今天要做另外的一个MySQL或PostgreSQL，可能需要担心你所说的问题。但我们所做的分布式系统，本身在全球来讲都是一个刚起步阶段的领域，而且大部分国外公司都是开源的，所以我不认为在这一块会有太多的专利竞争。况且我们的产品也是开源的，并且跟国外的同类公司基本同一个时间起步，我觉得应该不会有你说的这种问题的。