各类数据库使用场景比较

clickhouse

列式数据库，其具有以下特点：
易用性高：适合OLAP(on line analytical process)场景，兼容大部分的SQL，使用灵活;
性能好单表查询能力性能超过其他类型OLAP数据库；
适合批量写入，写入粒度过细会生成太多小文件，影响查询性能；
缺陷：
对比较大的表，主键列（即排序列，LSM 合并排序文件时数据排序所依赖的列）的选择需要业务方的介入，选择不恰当，很影响查询效率；
没有完整的事务支持;
修改与删除数据能力不足；
可以构建物化视图，进行数据预聚合，但SQL的维护容易出错；

Druid

时序数据库（同样作为OLAP数据库，适合趋势分析、UV等）；
数据预聚合（相当于对所有维度列进行了group by)，适合聚合查询场景，度量列只能支持数值类型（因为需要按照维度进行预聚合计算）；
对每一维度列都构建了位图索引，可以提升查询效率；
缺陷：
同influxdb一样，同样作为时序数据库，与clickhouse相比，**sql 查询分析能力不够完善**， 但是作为时序数据库，对实时数据的写入能力要优于clickhouse；
不适合超高基维度（维度数量特别大，例如用户电话号码、 vid 这类数据就不适合存储在druid 中）；

公司内部druid集群性能描述：
写入千万QPS；
查询十亿级数据，亚秒级返回；

参考： Kylin、Druid、ClickHouse核心技术对比

influxdb

时序数据库, 特别适合处理与分析监控数据这种时序数据，但SQL 兼容性不高。
特点：
时序数据的写入性能不错，单机版也可以满足多数业务的需求, 适合小规模的业务数据;
使用灵活，满足一些特定场景的需求： 比如 数据修改 (cdn 的日志数据写入，经常出现需要数据覆盖的情况，而clickhouse 对数据修改不太支持、存储明细数据(druid 不支持）;
存储需求；
对比OpenTSDB、Druid，部署与运维也相对简单；
支持类sql的查询；
性能推荐：

缺点：
集群版没有开源，需要收费；
series (相当于druid中的维度列）数量最好不要超过100万；

OpenTSDB

基于HBase研发的数据库，用于公司整个metrics打点存储；
特点是：基于Hbase, 因此写入与存储能力很强大（scalable, 对比仅仅开源单机版的influxdb)；

ElasticSearch

明细查询，全文检索；
实时；
非结构化数据;
相比时序数据库，搜索能力更强，而分析能力更弱, 而且成本比较高，写入能力与查询能力一般情况下不如时序数据库；

公司内部elasticsearch描述：
适合做日志分析，与logstash（数据预处理）, kibana（数据可视化）共同组成完整的日志分析系统；
因为全文索引比较重， 写入能力相对较弱，支持50WQPS写入；

参考：各类时序数据库
各类数据库选择对比：

OLAP VS OLTP

OLTP(on line transaction process)场景, 适合该场景的数据库：mysql 等
OLAP(on line analytical process)场景，适合该处理场景的数据库： clickhouse 等

事实表

用来记录具体事件的

纬度表

纬度表为对时间表中事件要素的描述信息；代表了观察该事件的角度；
例如对于销售事实表，可以有5个不同的纬度表与其对应；

Cube

cube 是dimension(纬度）的组合， 是经过大量聚类运算好的加以特定方式存储的多维报表；
参考：Cube正方体