从 CockroachDB 看事务型数据库开发

  • 杨旸

2016 年 4 月 14 日

话题:数据库大数据语言 & 开发架构文化 & 方法AI

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

数据库大数据语言 & 开发架构文化 & 方法AI