实测ES数据膨胀

构造原始数据

先写一个GenLocalLog程序，生成格式为“用户id，访问时间，IP地址，响应码，访问接口”这样5字段的测试日志，共计100000条记录：

如图：青色、橙色、黄色、绿色和紫色分别是对应的示例数据，模拟实际情况。

数据示例如下，采用空格分隔，当然也可以生成时直接用逗号分隔，变成csv文件。

142e307b-bf31-4c20-a979-87c153350e64 2020-11-17T10:12:13 33.60.47.29 500 /login
19050e5b-4160-436e-bc3c-569c5f1436cc 2019-05-04T10:12:13 192.20.253.36 500 /like/up/comment
84abefb7-77e8-4b07-b8a7-699e50903ed2 2018-04-08T10:12:13 64.35.208.191 401 /index.html
c2dd78d4-dda1-46dc-b444-72cd96f412d2 2022-09-22T10:12:13 202.130.99.110 302 fail/404
e70791d4-78c3-47d6-95d5-6053c85fa457 2019-06-21T10:12:13 113.31.249.9 100 fail/404
72b579e8-f491-4d8f-9213-1505901d9d7a 2022-06-18T10:12:13 247.69.179.58 201 /login
649f9e76-4b48-49ef-b776-d23b250b1593 2021-06-04T10:12:13 241.103.35.87 502 /index.html
21185f54-6aed-472a-b657-3dc700e0a6ae 2018-02-25T10:12:13 154.28.143.178 200 /login
3a7b6e1c-e7f9-4953-b765-715aabb542de 2022-02-09T10:12:13 108.242.107.172 401 /login
80e00d54-6672-4a7c-89d7-8f8da31f1d68 2021-02-10T10:12:13 137.74.169.7 201 /index.html

此时，原始数据(名为test-log.txt)的纯文本文件大小是8385KB（约8.2MB）。

写入ES索引

创建索引

设置3个主分片，1个副本，默认分词器，字段类型进行如下的合理设置：

PUT test-log-index
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "uid": {
        "type": "keyword",
        "index": false
      },
      "timestamp": {
        "type": "text"
      },
      "ip": {
        "type": "ip"
      },
      "code": {
        "type": "integer"
      },
      "api": {
        "type": "keyword"
      }
    }
  }
} 

写入数据

再写一段Spark程序（SaveToES）读取前面造的10w数据写入ES，只用了4秒。

EsSparkSQL.saveToEs(oneDF, "test-log-index/_doc")

注：由于构造的数据中“时间戳”的格式不合规，在ES中没法直接当做date处理，这里当做普通文本text类型。

膨胀路径分析

• 原始的10万行记录行均大小是85B
• 对应的json格式存储抽样大小是150B
• 不算压缩，初步估算数据膨胀系数 150/85 = 1.76

那么ES实际存储数据占用了多少空间？查询索引的存储占用结果如下：

health status index          uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   test-log-index Lrn0FdoEThC6mCs76-uAuA   3   1     100000            0     29.8mb         14.8mb

主分片14.8（MB）除以8.2（MB）得到 1.80，这个结果与粗估的1.76非常接近，误差仅2%。

由于设置了1副本，总存储大小是29.8MB，简单的倍增关系。

补充压缩影响

设置ES的压缩参数index.codec为default，也就是LZ4压缩算法，存储减少0.4MB，约3%。（会不会默认就是开启的？？）

设置压缩算法为best_compression，存储减少了3MB，约20%，这个较为可观。

结论

本文实践得到一段常见日志的数据膨胀率为180%，也即1GB的原始日志索引到ES后占用的物理存储为1.8GB。其余情况以此类推，副本可忽略，其影响是倍数关系。

显而易见，原始数据与ES的json之间的差距越小，膨胀率越低。

生产环境规划时可以根据主数据存储的的膨胀路径分析得到ES的数据膨胀系数。