转载

从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

原文  http://www.infoq.com/cn/news/2016/04/CockroachDB-worth-learning
正文到此结束
Loading...