从 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 开源生态圈。 yang.yang@esgyn.cn