ES存储开销实验分析

ES 版本 6.6
kibanna 版本与 ES 版本相同
测试内容为随机字符串，一行大小约为1KB

实验样本一

message 为完全随机字符串，不分词，类型为 keyword

ES mapping: es_user

{
  "es_user" : {
    "mappings" : {
      "es_user" : {
        "properties" : {
          "code" : {
            "type" : "keyword"
          },
          "message" : {
            "type" : "keyword"
          },
          "name" : {
            "type" : "keyword"
          },
          "salary" : {
            "type" : "long"
          },
          "userId" : {
            "type" : "text",
            "fields" : {
              "keyword" : {
                "type" : "keyword",
                "ignore_above" : 256
              }
            }
          }
        }
      }
    }
  }
}

数据条数与存储空间统计

1000条 ：2.9MB
1W条： 29.5MB (貌似 keyword 比 text 更消耗空间，但是 text 会分词，这是为什么呢？)
10W: 294.7MB
200W：5.7GB 如果按照一万条的存储空间，200W 条应该为5.8GB, 可见此种场景下 ES并没有比较高的压缩比。

400W： 13.4GB 相比200W 情况，每条开销反而变大了。但是十分钟后就变成 11.5GB了， 貌似内部有刷新机制

实验样本二

message 为完全随机字符串，分词，类型为 text, 但因为完全为随机字符串，分词效果应该也不大

{
  "es_text_user" : {
    "mappings" : {
      "es_text_user" : {
        "properties" : {
          "code" : {
            "type" : "keyword"
          },
          "message" : {
            "type" : "text"
          },
          "name" : {
            "type" : "keyword"
          },
          "salary" : {
            "type" : "long"
          }
        }
      }
    }
  }
}

100W条：2.1GB
200W条：4.2GB
400W条：8.5GB

实验样本三 ：

message 非随机字符串，每行日志都通过一个词汇池随机组合1000个长度（分词会有效果）。分别观察 text 和 keyWord两种存储开销

	KeyWord	TEXT
1W条	25.9MB	9.5MB
10W条	259.1MB	92.8MB
100W 条	2.5GB	918.3MB
200W 条	5GB	2.1GB

存储开销结论

1. 对于日志类数据（字符串为主），ES 没有提供一个强大的压缩能力，不能指望将日志压缩进 ES，至少这个量级是这样的。
2. 对于分词的字段的存储开销会小于没有分词的字段， 比例取决于日志的可分词程度。