使用 Easysearch,日志存储少一半

在海量日志存储场景中,索引膨胀率是一个关键指标,直接影响存储成本和查询性能。它表示原始数据与索引数据在磁盘上所占空间的比率。较高的索引膨胀率不仅增加了存储成本,而且可能会影响查询速度,尤其是在 I/O 密集型的查询中。因此,我们需要密切关注和优化索引膨胀率。接下来,我们将比较 Elasticsearch 和 Easysearch 在处理相同数据时的索引膨胀率。

测试结果 #

一图胜千言,下图是 Easysearch v1.1 和 Elasticsearch v6.4.3 的索引大小测试对比,Y 轴单位是 MB。

使用 Easysearch v1.1 的压缩功能,比 Elasticsearch v6.4.3 的索引大小降低了 50%。

p1.png

测试说明 #

以下是对 Elasticsearch v6.4.3 版本,测试数据 500 万条大小 1.054G(1080M)的 nginx 日志,使用 es 默认的 mapping,分别用 best_compression 和 default 的压缩策略进行写入。 Elasticsearch v6.4.3

索引 大小(MB) 膨胀率 条数(万)
nginx_default_1g 1812.61 1.61 500
nginx_best_1g 1551.36 1.42 500

然后我们对比下,使用极限科技的 Easysearch 进行索引膨胀率的压测.

Easysearch 是什么? #

INFINI Easysearch 衍生自基于开源协议 Apache 2.0 的 Elasticsearch 7.10 版本。 Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能,与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。 安装包大小只有 54 兆,相比 Elasticsearch 动辄一两百兆的安装包更加轻量级。 Easysearch v1.1

索引 大小(MB) 膨胀率 条数(万)
nginx_default_1g 1514 1.33 500
nginx_best_1g 1286 1.138 500
nginx_zstd_1g 1015.3 0.94 500
nginx_reuse_1g 758.39 0.70 500

注意上面使用到的 Easysearch 的压缩策略有 4 种:

压缩策略 描述
default 和 Elasticsearch 的 default 压缩策略一致。
best_compression 和 Elasticsearch 的 best_compression 一致。
ZSTD ZSTD(Zstandard)是一种开源的压缩算法和压缩库,旨在提供高性能和高压缩比的数据压缩解决方案。由 Facebook 开发并开源的一个压缩库,Easysearch 1.1 版引入了这个压缩算法作为一个可选的压缩策略,分别对存储字段,doc_values,和词典文件进行了压缩,并且 Easysearch 使用的 zstd 是纯 java 版,不依赖底层的操作系统和 cpu 架构,无需单独编译可以直接部署在国产的操作系统和芯片上。
index.source_reuse Easysearch v1.1 新增加的一个索引配置项,表示是否对 source 中的字段进行复用,熟悉 Elasticsearch 存储结构的都知道,es 底层依赖 lucene 作为核心的存储和查询引擎,默认 mapping 下,在将 es 的字段解析成 lucene 的对应字段后,一个 keyword 类型的字段会分别存储在 _source 和 doc_values 字段里,Easysearch 将 keyword 字段在 source 存储时进行了过滤,然后在查询阶段又利用 doc_values 对 source 里过滤的 keyword 字段进行了无缝拼接,用户层面感知不到对 keyword 字段的特殊处理。

default 和 best_compression 比之前 6.43 版的膨胀率降低是因为得益于 lucene 版本的升级到了 8.11.2,新版的 lucene 的压缩比之前的版本有了很大提升。 重点是最后利用 ZSTD 加 index.source_reuse,存储资源的占用比之前 6.43 版本的 best_compression 的 1.5G 减少了 50%,对比相同 lucene 版本的 best_compression,存储资源也减少了 40%,带来以下几点好处:

  • 降低存储成本:较低的索引膨胀率意味着存储相同量的数据需要更少的磁盘空间,这将直接减少硬件和维护成本。
  • 提高系统扩展性:由于索引占用的存储空间较小,可以在相同的硬件上处理更多的数据,或者在扩展存储时,需要添加的硬件更少。
  • 更高效的数据备份和传输:小的索引文件意味着备份和传输数据的时间和带宽需求都会减少。

使用方法 #

##启用ZSTD
PUT nginx_zstd
{
  "settings": {
    "codec": "ZSTD"
  }
}

##启用index.source_reuse
PUT nginx_reuse
{
  "settings": {
    "index.source_reuse": true
  }
}

##结合使用
PUT nginx_reuse
{
  "settings": {
    "codec": "ZSTD",
    "index.source_reuse": true
  }
}

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,919评论 6 502
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,567评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,316评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,294评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,318评论 6 390
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,245评论 1 299
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,120评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,964评论 0 275
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,376评论 1 313
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,592评论 2 333
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,764评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,460评论 5 344
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,070评论 3 327
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,697评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,846评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,819评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,665评论 2 354

推荐阅读更多精彩内容