顾事务和性能，并通过连接器实现复杂的SQL，NoSQL数据库SequoiaDB有着很多让人眼前一亮的特性。同时，SequoiaDB还能替代HDFS，作为MapReduce任务的数据存储源。

多样性、大容量给数据的存储和处理带来了巨大的挑战，当传统关系型数据库无法应对应用程序的快速迭代时，天生具备弱数据结构模式、易扩展等特性的NoSQL数据库得以飞速发展，在众多网络及新型应用程序中得以部署。然而，基于其分布式的特性，事务成为了大部分NoSQL数据库系统的致命弱项，也造就了NoSQL与任务关键性场景绝缘的这个现状。时至今日，着眼NoSQL领域，如何才能在高性能下兼顾事务以及更多功能已成为当务之急。为此，笔者近日与SequoiaDB创始人兼CTO王涛取得联系，就NoSQL打造进行了简要采访。同时，值得高兴的是，通过王涛得知，SequoiaDB即将开源。

以下为采访实录：

SequoiaDB创始人兼CTO 王涛

CSDN：请介绍你个人和SequoiaDB。

王涛：大家好，我叫王涛，现在是SequoiaDB的创始人兼CTO。之前我一直在IBM的北美数据库实验室做DB2数据库引擎。我们SequoiaDB是2012年正式成立的，每一行代码都是我们从零打造，并没有基于其他的开源数据库引擎。还记得当初我回国之前，大概用了半年的时间和几个IBM出来的兄弟在北美那边一行行地扣代码，最后整个引擎跑通了并且感觉性能不错，才回国成立的公司。我们SequoiaDB的核心产品就是一款文档类NoSQL数据库，从体系结构与应用场景上看和 MongoDB有些类似，因此很多时候我们会被拿出来和MongoDB作比较。

CSDN：你经历多年RDBMS与NoSQL的开发，是否可以从你的角度谈谈NoSQL运动？

王涛：我认为，NoSQL运动是现在应用程序互联网化和移动化的一个产物。过去，关系型数据库做点什么东西都需要进行复杂的数据模型设计和调整，但是在互联网时代这种玩法已经跟不上节奏了。所以，以互联网的标准数据格式JSON进行对象型数据存储成为一种需求，而这种需求同时也弱化了应用程序对关系模型的依赖。

当然，这并不是说NoSQL会在近期完全取代关系型数据库，而是这两者会有一个长期的共存，分别适用于不同的应用领域。现在我们已经看到，很多传统的企业也都开始慢慢接受互联网的思想，包括其业务模式以及后台所采用的技术，包括NoSQL数据库。

CSDN: 能否谈一下SequoiaDB当下都有哪些重量级的用户？数据库的规模达到什么级别？

王涛：我们现在在企业和互联网领域都有不少的成功案例。传统企业中包括像民生银行、海南航空、电信移动企业等；而互联网行业里面也有像蓝汛、蓝港在线这类企业。我们部署在一些客户的系统还是挺大的，比如有一家客户的日志分析集群系统总量超过PB，每天会产生近10TB的数据，都要近实时入库并且做到同时批处理分析和实时检索。这类集群都是百台节点的规模。

CSDN：同为文档类型NoSQL，对比全球排名第五的MongoDB，SequoiaDB的优势/特点是什么？

王涛：从架构上来讲，MongoDB和我们都是使用分片Sharding机制，每个分片里面做数据的复制和同步。而在具体实现中我们则有很大差异。譬如说我们的日志使用的是日志序列号LSN机制，而MongoDB则是一个capped collection，所以我们可以做到很多MongoDB根本不可能做到的事情，例如事务这类操作。除了这些功能点以外呢，我们的性能可以说是一大亮点。过去人们通过MongoDB和CouchDB可能都认为文档类NoSQL的性能比较差，至少和Cassandra这类的宽表库比起来差。但是现在在我们的测评中，很多原本HBase和Cassandra最突出的导入操作都被我们甩在了后面。

CSDN：确实，一般人都认为文档类数据库由于结构复杂，相比起宽表和KV类型的NoSQL来说性能不佳。为什么SequoiaDB在能够提供丰富的数据库操作功能以外还达到这么高的性能呢？

王涛：这个问题就要深入到代码的实现中去了。我想这都要归功于我们代码的精细化设计，尤其是对并发性和锁的这一部分。

在一个并行处理的数据库里面，如果锁控制得不好，会造成很多线程都堵在一个地方。如果大家有兴趣看看mongodb的代码可能会发现，它做了很多非常好的模块化封装，但是相反地对于一些锁的处理则比较粗糙，所以在高并发高压力的情况下总体的吞吐量根本上不去。而我们在设计SequoiaDB的时候，很多代码尽量做到无锁。程序的设计永远秉承一个理念，就是在正常流程下尽可能无锁，异常流程可以使用额外的代码或锁机制保证逻辑正确。所以即使在一个16核、32核的这种大机器下起高压力并发我们也可以把CPU打满，不会在某些代码上造成性能瓶颈。

另一方面，MongoDB实际上很多设计并非最优。譬如说它的日志机制使用了capped collection。可能咋一听起来很新潮很酷，但是实际上会对整体性能有着重大的损害。而我们使用的虽然是比较经典的日志LSN机制，但是正因为这种机制被所有关系型数据库使用了几十年，才从性能和功能上都被完善到了极致。

剩下的还有很多优化细节，譬如说我们在性能敏感的代码里面完全不允许使用string这种STL库，就是避免这种封装得比较深的库会做额外的譬如分配释放内存的操作，造成不必要的损耗。

CSDN：我们知道，分布式数据库和传统的单点数据库相比有很大不同。从技术上能不能简单介绍一下，分布式数据库的难点在什么地方？你们是怎样解决的？

王涛：传统的关系型数据库主要都是单点架构，有数的几个像Greenplum和DB2这种MPP 数据库才能够做到分布式架构。当然，我们说Oracle的RAC算是假的分布式，在存储层还是大统一。所以，我们这里说的分布式是Share Nothing的MPP架构。

在分布式系统里面，有几点是需要注意的。第一，就是数据是否可以做到弹性扩张。这个可能算是所有MPP分布式关系型数据库最大的弱点之一。比如DB2，想要添加个节点，需要做redistribution，遇到一个几十TB的数据库估计要好几天才能搞完。而NoSQL明显不能这么玩，所以我们用的是一致性哈希技术，把数据散列后映射到哈希环上根据范围划分节点，可以做到在增减节点时移动最少的数据。

第二，节点的可用性。现在讲究的大集群基本都是围绕着PC服务器说的，PC服务器的特点众所周知，就是容易坏。那么如果我一个集群里面有1000个节点，三天两头都有可能有机器出故障。如果用关系型数据库那种MPP架构就完蛋了，一个节点坏了可能整个表都挂了。所以，我们要用多数据副本的方式保证即使机器挂了，数据也可以在其他的节点中找到。

第三，就是事务操作。我想事务操作是现在很多NoSQL都不具备的功能。并不是说NoSQL的架构和事务有冲突，而是想要实现事务机制需要太多模块的配合。譬如说日志机制，对于MongoDB的capped collection机制就很难实现事务的提交和回滚功能。我们用的是基于传统的事务日志的机制才能够做到这一点。当然，别忘了还有记录锁、表锁这些机制，还要考虑多副本之间数据根据日志的分发同步，节点失效重新选举后日志的同步等一系列机制。

CSDN：事务一直是分布式数据库实现的难点，就算很多其他世界知名的NoSQL也没有很好地实现。可否详细介绍一下其中存在的挑战，以及SequoiaDB事务的实现途径。

王涛：事务本身其实原理并不难，就是做任何操作都要先写日志，然后把每个会话的日志都有一个链能够往回一条条找到本事务起始的位置，能够对每一个操作做redo和undo就可以了。这个是单点传统数据库的玩法。当然，锁这些机制是另一个故事了，这里先不提。

但是在分布式环境中，这个简单的东西就开始变复杂了。第一，如何确保在可配置的强一致与最终一致性中，事务在复制过程中的完整性。譬如说，主节点A挂了，备节点还没有同步到这个主节点最后的日志，这个时候事务怎么处理？对于我们来说，当然在最终一致性的配置中只能牺牲数据的完整性了，不过在强一致性开启的情况下则是必须要保证这一点。

另外，多个分片之间数据完整性的问题也存在。我们利用很多MPP数据库使用的二段提交（2PC）来玩，可以满足大部分提交回滚的需求。但是如果在二段提交过程中的小窗口处发生问题同样还会造成indoubt transaction，这一块处理也是难点。

还有很多网络问题的检测也和事务息息相关。比如说如果协调节点挂掉了，需要让数据节点能够立刻感知到这个事件，并且确保这个协调节点所属的事务全部进行回滚操作。而如果某一个数据节点掉了，协调节点则必须感知然后通知其他数据节点回滚这个操作。

CSDN：我们看到SequoiaDB提供不少与第三方产品的连接器，能不能介绍一下这些连接器的作用？

王涛：做一个数据库不像搞一个游戏或者应用软件，自己和自己玩就行了。数据库是软件项目基础架构的一部分，需要对接很多第三方的应用和产品，要把生态圈建立起来嘛。所以我们在和其他产品对接这一块也花了不少力气。主要是两个大方向，一个是和Hadoop这块一起玩，一个是和使用关系型数据库的应用这块一起玩。和Hadoop对接相对比较简单，就是Java里串行化的几个函数嘛，对接了以后自然和Spark的对接也有了。另外对于Hadoop生态圈里面其他的Hive和Storm我们也都做了连接器，可以直接利用Hive和Storm从数据库读写数据。

而和使用关系型数据库的应用对接就有点麻烦了。我们想了个方法，先和PostgreSQL对接。PG不是提供一个FDW的机制么，我们就直接写了个库能够串到FDW上，让PG能够定义基于SequoiaDB的外部表，里面定义各个字段和类型。每次查询的时候相关的请求会通过FDW转换成我们认识的东西发送的数据库上，然后返回的记录在格式化成PG需要的格式，在PG里面进行关联啊聚集之类的。

总地来说，我们会不断增强连接器的种类和功能，争取今后和多数主流的产品与第三方应用都能够较轻易地对接。

CSDN：SequoiaDB曾宣布提供开源版本，是否取得了一定的进展，对比商业版，开源版本会弱化哪些方面？

王涛：开源现在是万事俱备，就差最后临门一脚了。我们已经在Github和CSDN CODE平台上都建立好了repository，所有的代码审查和协议注释也都已经完成了。我们将很快在近期就会正式对外开源。

商业版和社区版相比，主要是在企业级服务这块增加了一些内容。譬如说24x7的技术支持啦，定期巡检啦，安全机制啦，还有一些额外的监控机制和工具软件之类的。而从数据库内核的代码上来看企业版和社区版基本区别不大，也并不存在集群规模限制等问题。

CSDN：作为数据库打造的行家，有什么使用经验可以分享给读者的？

王涛：太多经验也谈不上，现在我看到不少程序员和DBA兄弟依然围绕着关系型数据库吃饭，我想大家可以开始适当关注大数据和NoSQL这个领域。因为我觉得今后关系型数据库会成为一个存量市场，就像几十年前的大型机一样不会消亡，但是也不会近期迎来大规模的增长。相反，非关系型数据库与大数据技术正在开始起步，虽然市场上还是一片混战局势未明，但这也正是切入这个领域开始学习的好机会。如果局势都明朗了，基本该占的坑都被占完了，晚来的弟兄们也没啥汤好喝。

CSDN：你有什么需要对读者补充的么？

王涛：作为咱们国内不多的基础数据库软件，我们有信心在开源后和国外的产品进行功能与性能方面的正面抗衡。也希望国内的技术人员圈子多多给我们鼓励，最好能试用一下提出各自的宝贵意见。