ES VS CK，成本太高，效率太低？不存在的

今天无意间一个客户问到CK和ES对比的问题。通常来说，ES并不是一个应该和CK进行横向比较的产品，ES是用综合数据库，一个大数据系统，一个搜索引擎，而CK是一个列式存储数据库的管理系统，两者最主要的使用场景并不特别重合。但因为ES出色的检索性能和丰富的数据分析能力，在数据分析产品预算有限的情况下，会有不少客户选择直接将ES用在OLAP分析的场景，而不是再额外部署一个OLAP系统，因此，自然免不了要被拿出来和CK作比较。

比较就比较吧，虽然在OLAP分析领域以列式存储库为主，ES并不是为这个场景而生的（You know, for search）, 但综合各方面的能力之后，既然有很多用户选择使用ES作为OLAP分析工具，那我们就应该给大家以合适的指引。

特别是当互联网上出现如下这些描述不当的文章可能给人以误解时，我们有必要去做一些澄清。

文章原文我放在这，携程ClickHouse日志分析实践，分享实践是好的，但做产品比较以及下定论这种事，还是要严谨，要慎重。

这里我也不做一一的纠正，也不去做ES和CK的比较。我只是针对其中的一些表述，帮经常使用ES的同学来进行一些解惑

ES占用内存多？

ClickHouse相对ES占用更少的内存。
ES为了提高查询效率会将很多数据放在内存中，如：segment的索引数据、filter cache、field data cache、indexing buffer等；ES内存的使用量与索引量、数据量、写入量、查询量等成正比。删除（下线）索引、迁移索引或者扩容是应对ES内存问题的常用手段。但是删除（下线）索引导致用户希望保存更长时间数据的需求无法满足，而服务器扩容导致又了成本上升。
ClickHouse的内存消耗主要包括内存型的engine，数据索引，加载到内存中待计算的数据，搜索的结果等。在ClickHouse中日志的数据量和保存时间主要和磁盘有关。

我们可以看一下这里的描述，似乎侧面的意思同样的数据，ES的内存使用效率会更低？其实并不是。

• 首先，ES是运行在JVM上的应用程序，而CK是C++编译的可运行程序，两者内存使用和管理的机制不同，不宜直接横向比较。（当然，看起来C++没有JVM的负担，貌似有丢丢优势，但如果垃圾回收没做好，也是有不能合理利用资源的可能的，这块水太深，不聊）
• 其次，ES不是专门用于OLAP分析的列式库，整个ES节点上面运行了大量的额外功能去支持其他复杂的场景，并不是所有的资源都用于快速读/写，比如，ES对高并发的支持就比CK好很多，ES也能做Schema On Read的运行时字段提取和操作。因此，在场景和功能特性不同的情况下，也不适宜做内存的比较
• 再有，ES有大量的其他数据结构，比如倒排索引支持全文检索和模糊查询、BKD tree支持快速的range排序和地理位置边界查询，将这些数据加载到内存用于加速搜索无可厚非，最主要的是，这些数据是否生成，是否加载都是可控的，用户需要知道合理的数据建模，而不是让系统自动推测数据类型

就好比方说，比较BMW的混动7系和常规动力的丰田陆巡的油耗，得出结论BMW在省油方面做得比丰田强，看似结论成立，但实际上如果不考虑场景和用法，并没有多大的指导意义

Off-Heap

另外，这里说的内存到底是指的JVM使用的内存，还是把整个系统的内存都算到ES上面呢？如果大家了解过最新版本上的Off-Heap的特性，其实新版本的ES在内存使用上已经有很非常巨大的改进：

结合7版本最新的内存断路器，在最新版本上，已经很少听到用户反馈说 “ES中一个大查询导致OOM的问题”

因此，这里非常重要的一个点，要把ES升级到最新的版本

ES占用存储多？

熟悉ES的同学应该知道，ES提供了大量的选项可以控制生成数据的大小的，并且不同版本的ES性能和效率上也有不同，这里并没有给出ES具体的版本，也没有给出日志和mapping，所以很容易让人产生误导

ES指标型数据存储压缩

这里，我做了个测试，我用这样的一个数据集来测试：

原始数据1000多万行，1.4GB。

数据样本如下：

{
   "geonameid": 2986043, "name": "Pic de Font Blanca", "latitude": 42.64991, "longitude": 1.53335, "country_code": "AD", "population": 0}
{
   "geonameid": 2994701, "name": "Roc Mélé", "latitude": 42.58765, "longitude": 1.74028, "country_code": "AD", "population": 0}
{
   "geonameid": 3007683, "name": "Pic des Langounelles", "latitude": 42.61203, "longitude": 1.47364, "country_code":