一些存储引擎的对比

Kylin

• 离线/准实时/实时OLAP，兼容一部分明细类的查询。

• 对于超大规模数据量olap（广告，曝光），目前没有对手。

• hbase作为存储引擎，通过m/r， spark根据维度的笛卡尔积组合计算聚合的结果。

• 准实时/实时，3.0版本实时olap对标druid，未来极有可能超越。

• 因为主要存储计算结果数据，90%查询结果直接可以通过rowkey获取，查询效率极高(可达ms级别)。

• 维度和指标可以通过bitmap, hll, 数据字典存储，存储占用很小。

• 支持JDBC

• 页面用户体验性好，社区活跃。

Druid

• 主要做实时的OLAP。和Kylin实现的方式不太一样(druid不做预计算，维度指标存储数据字典，保留原始数据)。
• 在实时的OLAP方面有一些优势，目前没有比它好的方案。
• 架构复杂，稳定性待观察。
• 社区最不活跃，一直处于孵化阶段，未来极有可能被其他替代。

Hbase

• 列存储
• 基本功能根据rowkey查询明细。时间戳分版本，支持简单事务。
• 如果性能稳定(公司使用的hbase有fgc，大合并问题)，查询可以作为kv来使用,因为是分布式的，qps可以达到很高，可以服务线上用户。
• 只能根据rowkey查询，不支持二级索引，不支持jdbc(可通过第三方插件phenix实现)
• 社区活跃。使用场景主要还在大数据方面。

Es

• 主要用做搜索引擎，做全文检索，分词类的搜索，目前没有替代方案。

• 通过倒排索引实现。统计数量可以达到ms级别。

• 目前貌似6.0版本以后才支持jdbc。6.0之前的版本智能用dsl。

Mysql

• OLTP事务型的存储引擎。B+树的存储结构。
• 稳定性极高。使用最广泛。
• 支持JDBC。社区最活跃。
• 单表一般1000kw+以后查询效率骤降。
• 支持丰富的索引(唯一索引，二级索引，联合索引)。
• 支持单机事务。

Tidb

• 解决mysqll 分库分表的问题，不需要分库分表就可以实现上亿规模数据OLTP的CRUD操作。
• 使用列存储。
• 支持jdbc。所以操作和mysql很相似。使用门槛很低。
• 支持分布式事务
• 官方版本更新的很快，社区也比较活跃。未来是往OLAP,还是OLTP方向走，是一个问题。目前来看OLTP是个方向。

redis

• k-v存储，主要服务线上业务。基于内存做储存，存储可以达到亿级别，qps可以达到数W级别。
• 存储结构除了k-v, 还支持hash. list等。
• 因为主要存储内存，比较烧钱，非核心应用还是建议hbase比较合适。
• 需要手工才能实现时间戳版本。
• 单个操作支持事务，多个操作需要借助第三方脚本(lua)实现。
• 社区比较活跃。

clickhouse

• 列存储，可以动态增加字段。
• 支持离线/实时大宽表的导入(自定义flink/kafka数据源，事务性比较弱，端到端的一致性保证，比较困难。)
• 支持数据量少的维表字段(支持mysql等)
• 支持物化视图
• 单机查询性能比较高，但是整体并发能力比较弱。适合并发比较弱的第三方应用查询以及各种即系查询。
• 横向扩展比较麻烦，动态增加节点，以及均衡数据需要第三方软件支持。
• 表之间的join比较弱。
• 社区较为活跃，目前各家云厂商都有对应的解决方案。

doris

• 列存储，可以动态增加字段。
• 支持离线/实时大宽表的导入(自定义flink/kafka数据源，事务性比较弱，端到端的一致性保证，比较困难。)
• 支持表join，方式是通过分区分桶表，再依赖单机性能和向量化计算。
• 支持预计算和物化视图。
• 扩容相对方便。
• 并发能力上比clickhouse要强。
• 百度的孵化产品，目前属于比较新的产品，社区不是很活跃。