kudu存储引擎

大象从不倒下 2017-02-13

Kudu最初由Cloudera开发,但现在已经开始作为Apache的项目孵化。

定位是OLAP数据库,说白了就是可以随机读但主要是针对顺序读做优化。所以在小米也是计算组搞而非存储组。数据的模型个人觉得很像Cassandra的伪SQL——结构化的数据、SQL类似的语法但本质上还是NoSQL,可以设定是Hash还是range或者两者结合来做partition分配到若干个tablet,每个tablet用raft协议写在多个节点上。之前扫了眼论文似乎是没写如何做tablet的split/merge,也许现在还不支持也许我看漏了。


从数据库的角度讲,比较重要的两个点是C++和raft。
C++的性能比较有保障,还没有gc的停顿导致的.99响应时间不可控等问题,raft的心跳也因为没有gc可以设的敏感一些,可用性更好,而这些都是HBase的痛点。当然这是题外话,毕竟Kudu不是用来代替HBase的。
用raft协议搞replication意味着不需要比较蛋疼的HDFS了,表面上似乎还在说Kudu属于“Hadoop生态系统”,但我觉得他们的心思肯定不止于此。而且Raft的一致性也比较自由,追求性能可以最终一致性地读。


此外可以看下Apache Kudu as a More Flexible And Reliable Kafka-style Queue ,这篇文章说,因为他顺序读吞吐比较好,并且raft协议自身提供了递增id,所以可以用来代替kafka搞消息队列,简单测试性能差不多( “in the same realm”),还没GC。而且因为是数据库,可以随机写,相当于可以修改队列,灵活很多。

相关推荐