从CockroachDB 看事务型数据库开发

CockroachDB继2015年5月融到第一笔$6.25M的A轮之后，今年3月底又融到$20M。对事务型数据库的开发者们，这是个好消息。 

有哪些东西值得思考呢？ 

首先CockroachDB也是个很棒的团队，位于纽约，去年A轮时只有6个人，到现在也就20来号人。小而精；和在大数据里站山头创业里大多数妖魔鬼怪一样，创始人有三个工程师，包括CEO Kimball，都来自大数据老巢-Google；第一位投资者：Benchmark的Peter Fenton。Benchmark投资过大名鼎鼎的Hortonworks和New Relic。 自然而然地，A1轮Google Venture，Hortonworks CEO Rob Bearden 和Cloudera创始人Jeff Hammerbacher也进来了。所以，找对投资人很重要，根正苗红的大数据投资者，带来的不仅是$$。 

这种数据库一开始就是为互联网定制的--线性扩展、确保事务完整性，全局的数据一致、和极端情况下的生存能力，即使内存、磁盘、节点、集群甚至是数据中心崩溃。而最对口的客户之一，无疑是服务于世界500强的SAAS公司—5分钟的事务型服务中断，可能影响到重要的ERP、CRM等核心业务系统，而对于SAAS服务提供商而言，那就是自砸招牌。因此，强哥很聪明地选了SAAS作为重点用户场景之一，而不仅靠互联网公司。

开始的时候，他们几个纯粹是按开发者的路子，本来打算2015年夏天推出的Beta版，目标是Transactional Key-Value Store.，所以最后还是决定把SQL加上去，这大概增加了2个季度的开发时间。不过，这样的定位更清晰，不会半生不熟地做了个NoSQL, 让用户自己琢磨到底是自己做索引，还是等等看。等等，索引自己做？ 别忘了他们是从Google来的，Spanner和Web Index可是CockroachDB的童子功啊。加上SQL对于用户来讲更加方便。

他们放弃的东西，也值得大家思考：他们放弃了Join，放弃了并行执行分布式查询。有意思吧？ 实际上是放弃掉“关系型”。在浓浓的Redis里，加了SQL这个大料，就成了Fusion food了。6个人，两个月完成，真不错。 

互联网公司对一致性的要求并不高，数据模型这种东西基本上不放在眼里，也确实用不上。Redis当年连Int的类型都没有，只有string，哪管你营收、销售、现金流报表是否对得上？ 这也让他们获得了很多东西，比如响应时间和并发。Twitter当年开始的那种场景，就算用自己用Hash Table建索引，也没啥不可能的，一张表满了，就写下一张。MySQL拿来当Raid 0用，复制到20台节点上就行，Partition信息交给根节点，用Ruby On Rails写个搜索，搜个三天的内容也挺好。 

对今后的发展而言，要和大量的NoSQL竞争对手区别开，跨数据中心的数据一致性是个很棒的卖点，随着FinTech的蓬勃发展，连花旗、大摩、德银、Visa的舵手都加盟互联网金融，CockRoachDB也把这个作为路线图里的重点项目。 

随着Lucene的发展，和Java Future把大家从以Service为节点的DAG拓扑带到以Future为节点的同、异步统一的网络编程等等，助力了Twitter从2010年开始开发的的real-time indexing，2010年开始给大家带来很多想象空间，原来可以自己根据内外不同的数据来源（不仅是用户帖子，而且用户资料，排名，第三方数据、地址等等）加好多东西到索引里。  

也为了方便互联网公司业务的发展—哪家的表结构能保证不变啊？ 通过多版本和分阶段授权等方式，Cockroach在Beta版本里加了一个Online Schema Change System，在服务不中断和不锁表的情况下，增加列，修改Index。你想想，像Stack overflow那样的公司，一个五六千万行的表，做Alter table操作，起码要五六个小时吧？如果用Amazon RDS服务，能否在Slave上做好再Promote到主服务器上，还另说。 

这功能也挺有意思：改变表结构schema不是一蹴而就的事，毕竟有那么多节点，都有各自的cache和TTL。要保证所有节点最终都用到正确的schema版本，需要一定“收敛时间”。像PrestaDB、Trafodion这一类成熟的数据库引擎一样，它也用了广播和租约相结合的方式。 在DML之后，节点会收到一个“读”的租约，在分钟级别的租约内可以用这个schema，而一旦出现Alter Table，将广播给集群里所有节点，让他们放弃当前租约，准备用新的，这样来达到更快的收敛时间。

他们下一步开发还是会去支持JOIN和并行Query执行。这是个很大挑战。像Apache Trafodion这种引擎当年能在Nonstop大型数据库上用，支持银行电信高并发的OLTP，其核心竞争力之一就在于并行处理，大致的做法包括多个机制上的并行，比如并行处理Partition或更小粒度的Division、执行器里一个个SQL operator连起来的管道并行和SQL Operator本身的同步/异步计算并行。 但是，这里面的难度很大，比如，为了确定到底用几个worker线程参与并行，需要考虑Key的数据分散情况，相关Query可能涉及到的行数范围，在架构各层插入统计信息的柄，如何下推，周到的Update Statistics之类以便优化，进行检测执行树每层的数据倾斜情况等等。

作者介绍：杨旸，就职于上海易鲸捷，兴趣在于分布式事务、SQL优化、Hadoop开源生态圈。 [email protected]