本文根据许鹏老师在〖deeplus直播：开源分布式数据库CrateDB在携程的最佳实践〗线上分享演讲内容整理而成。
许鹏
携程研发总监
专注于分布式计算和存储，对Spark和PostgreSQL有深入研究，拥有多年Presto和Elasticsearch的运维经验。
今天的分享主要包含以下几个方面的内容：
CrateDB介绍
CrateDB在携程的实践
CrateDB在携程的优化
总结
一、CrateDB介绍
1、CrateDB
CrateDB是一款基于ElasticSearch的分布式数据库，它与ElasticSearch最大的区别是提供了ANSISQL查询访问接口。ElasticSearch在6.X版本以后，也开始提供SQL的查询，但CrateDB与ElasticSearch相比，能够支持多索引之间的关联查询，针对某些聚合函数，它返回的是精确的查询结果，而ElasticSearch返回的是近似值。
2、CrateDB的特性
适用于海量时序数据存储
CrateDB适用于海量时序数据存储，需要频繁更改的数据使用CrateDB存储效果较差。因为CrateDB基于ElasticSearch，频繁的删改操作会使它的性能大大受损。
高可靠水平可扩
CrateDB继承了ElasticSearch设计中高可靠的优点，集群较方便实现扩容，对于一些点查询或复杂度中等的查询均能够较为实时地返回结果。
支持DynamicSchema
CrateDB支持DynamicSchema，其最新版本能够支持json数据格式，写入数据更加方便。
我认为CrateDB的初衷是用SQL的方式查询访问基于ElasticSearch存储的数据。基于这一概念，我们可以看到它大概的分层（如上图所示），从外部访问从下到上依次到达最终的存储，其最外一层提供了PostgresSQL兼容的访问协议和RESTAPI的访问协议，接下来对语句进行解析，然后执行，获取存储在各个节点上的数据。
3、海量数据存储对比
因为类似技术较多，这里只对比几个典型的技术，CrateDB、ElasticSearch以及MongoDB，这三者都可以归类于Nosql。下文将从7个维度对三者进行对比。
1）Schema支持类型
这三个数据库均支持DynamicSchema。但在现实的生产环境下，我们推荐采用StructSchema，因为DynamicSchema可能会带来种种问题。
仅代表个人观点，并非适用于所有场景。
2）是否支持SQL访问
SQL诞生四十多年，已成为非常成熟的语言，具有极强的表达能力。同时SQL具有通用性，被大家普遍接受。CrateDB基于SQL的通用性不断发展，其支持ANSISQL，并且采用了PostgreSQL协议。
ElasticSearch起初只支持类json格式的查询语法，之后开始提供针对单索引的一些SQL语句支持函数，并不断丰富。MongoDB据我所知并未直接支持SQL，如果写入SQL语句，需要通过第三方插件才能够被MongoDB识别，这在一定程度上会影响查询性能。
3）可扩展性
从可扩展性角度出发，CrateDB和ElasticSearch采用gossip协议组建集群，简单来说节点之间相应对等。在一个ElasticSearch集群中，节点可分Master、Coordinator，以及承载数据的Data，一个节点可以同时扮演三个不同的角色，因此它们是对等的。
MongoDB则不同，如果用它来构建一个分布式集群，最起码有三个不同的Host，分别是ConfigServer、Mongos以及Data，为了实现高可靠，一个分片还需要分成相应的Master或Slave。
综上所述，从可扩展角度来看，ElasticSearch和CrateDB更好。
4）对于关联分析的支持程度
CrateDB支持跨索引之间的关联分析，而ElasticSearch则使用一些变通的方式支持此类关联查询，这意味着在写入数据时需要做相应变更。MongoDB在4.X版本时不支持关联查询，之后的版本未及时