索引中的活动段存储在段信息文件 segments_N中，索引中可能有一个或多个segments_N文件，但是具有最大值的那个是有效的段信息文件（当存在较旧的segments_N文件时，因为它们暂时无法删除，或者，writer正在提交，或者正在使用自定义 IndexDeletionPolicy ）。此文件按名称列出每个段，并包含有关编解码器和删除的generation的详细信息。
还有一个segments.gen文件，该文件包含当前索引的generation（segments_N中的N）。这仅用作备用，以防单独的目录列表无法准确确定当前的generation（对于某些具有基于时间的目录缓存到期的NFS客户端的情况）。此文件简单地包含一个 Int32版本Header（ FORMAT_SEGMENTS_GEN_CURRENT），接着的是以Int64格式写入两次的generation
很多使用Elasticsearch的同学会关心数据存储在ES中的存储容量，会有这样的疑问：xxTB的数据入到ES会使用多少存储空间。这个问题其实很难直接回答的，只有数据写入ES后，才能观察到实际的存储空间。比如同样是1TB的数据，写入ES的存储空间可能差距会非常大，可能小到只有300~400GB，也可能多到6-7TB，为什么会造成这么大的差距呢？究其原因，我们来探究下Elasticsearch中的数据是如何存储。文章中我以Elasticsearch 2.3版本为示例，对应的lucene版本是5.5，Elasticsearch现在已经来到了6.5版本，数字类型、列存等存储结构有些变化，但基本的概念变化不多，文章中的内容依然适用。
Elasticsearch对外提供的是index的概念，可以类比为DB，用户查询是在index上完成的，每个index由若干个shard组成，以此来达到分布式可扩展的能力。比如下图是一个由10个shard组成的index。
shard是Elasticsearch数据存储的最小单位，index的存储容量为所有shard的存储容量之和。Elasticsearch集群的存储容量则为所有index存储容量之和。
一个shard就对应了一个lucene的library。对于一个shard，Elasticsearch增加了translog的功能，类似于HBase WAL，是数据写入过程中的中间数据，其余的数据都在lucene库中管理的。
所以Elasticsearch索引使用的存储内容主要取决于lucene中的数据存储。
下面我们主要看下lucene的文件内容，在了解lucene文件内容前，大家先了解些lucene的基本概念。
lucene包的文件是由很多segment文件组成的，segments_xxx文件记录了lucene包下面的segment文件数量。每个segment会包含如下的文件。
下面我们以真实的数据作为示例，看看lucene中各类型数据的容量占比。
写100w数据，有一个uuid字段，写入的是长度为36位的uuid，字符串总为3600w字节，约为35M。
数据使用一个shard，不带副本，使用默认的压缩算法，写入完成后merge成一个segment方便观察。
使用线上默认的配置，uuid存为不分词的字符串类型。创建如下索引：
首先写入100w不同的uuid，使用磁盘容量细节如下：
可以看到正排数据、倒排索引数据，列存数据容量占比几乎相同，正排数据和倒排数据还会存储Elasticsearch的唯一id字段，所以容量会比列存多一些。
35M的uuid存入Elasticsearch后，数据膨胀了3倍，达到了122.7mb。Elasticsearch竟然这么消耗资源，不要着急下结论，接下来看另一个测试结果。
我们写入100w一样的uuid，然后看看Elasticsearch使用的容量。
这回35M的数据Elasticsearch容量只有13.2mb，其中还有主要的占比还是Elasticsearch的唯一id，100w的uuid几乎不占存储容积。
所以在Elasticsearch中建立索引的字段如果基数越大(count distinct)，越占用磁盘空间。
我们再看看存100w个不一样的整型会是如何。
从结果可以看到，100w整型数据，Elasticsearch的存储开销为13.6mb。如果以int型计算100w数据的长度的话，为400w字节，大概是3.8mb数据。忽略Elasticsearch唯一id字段的影响，Elasticsearch实际存储容量跟整型数据长度差不多。
我们再看一下开启最佳压缩参数对存储空间的影响：
结果中可以发现，只有正排数据会启动压缩，压缩能力确实强劲，不考虑唯一id字段，存储容量大概压缩到接近50%。
我们还做了一些实验，Elasticsearch默认是开启_all参数的，_all可以让用户传入的整体json数据作为全文检索的字段，可以更方便的检索，但在现实场景中已经使用的不多，相反会增加很多存储容量的开销，可以看下开启_all的磁盘空间使用情况：
开启_all比不开启多了40mb的存储空间，多的数据都在倒排索引上，大约会增加30%多的存储开销。所以线上都直接禁用。
然后我还做了其他几个尝试，为了验证存储容量是否和数据量成正比，写入1000w数据的uuid，发现存储容量基本为100w数据的10倍。我还验证了数据长度是否和数据量成正比，发现把uuid增长2倍、4倍，存储容量也响应的增加了2倍和4倍。在此就不一一列出数据了。
文件名为：segments_xxx
该文件为lucene数据文件的元信息文件，记录所有segment的元数据信息。
该文件主要记录了目前有多少segment，每个segment有一些基本信息，更新这些信息定位到每个segment的元信息文件。
lucene元信息文件还支持记录userData，Elasticsearch可以在此记录translog的一些相关信息。
文件后缀：.si
每个segment都有一个.si文件，记录了该segment的元信息。
segment元信息文件中记录了segment的文档数量，segment对应的文件列表等信息。
文件后缀：.fnm
该文件存储了fields的基本信息。
fields信息中包括field的数量，field的类型，以及IndexOpetions，包括是否存储、是否索引，是否分词，是否需要列存等等。
文件后缀：.fdx, .fdt
索引文件为.fdx，数据文件为.fdt，数据存储文件功能为根据自动的文档id，得到文档的内容，搜索引擎的术语习惯称之为正排数据，即doc_id ->content，es的_source数据就存在这
索引文件记录了快速定位文档数据的索引信息，数据文件记录了所有文档id的具体内容。
索引后缀：.tip,.tim
倒排索引也包含索引文件和数据文件，.tip为索引文件，.tim为数据文件，索引文件包含了每个字段的索引元信息，数据文件有具体的索引内容。
5.5.0版本的倒排索引实现为FST tree，FST tree的最大优势就是内存空间占用非常低 ，具体可以参看下这篇文章： http://www.cnblogs.com/bonelee/p/6226185.html
http://examples.mikemccandless.com/fst.py?terms=&cmd=Build+it 为FST图实例，可以根据输入的数据构造出FST图
生成的 FST 图为:
文件后缀：.doc, .pos, .pay
.doc保存了每个term的doc id列表和term在doc中的词频
全文索引的字段，会有.pos文件，保存了term在doc中的位置
全文索引的字段，使用了一些像payloads的高级特性才会有.pay文件，保存了term在doc中的一些高级特性
文件后缀：.dvm, .dvd
索引文件为.dvm，数据文件为.dvd。
lucene实现的docvalues有如下类型：
其中SORTED_SET 的 SORTED_SINGLE_VALUED类型包括了两类数据 ： binary + numeric， binary是按ord排序的term的列表，numeric是doc到ord的映射。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）