Elasticsearch 内部数据结构深度解读

题记

最近知识星球里几个问题都问到了 doc values、store field、fielddata 等的概念。

问题1：”群主有介绍 doc value, field data, store fields 比较好的文章么？一直感觉有点模糊“

问题2：“请教下星主关于ES存储相关的问题， 一个文档有如下几个地方可能会存储：

 

 • 倒排索引。

 

 • Source 字段。

 

 • store 存储（如果开启）

 

 • doc_values。

 

不知道我理解的是否正确？

 

如果这几个地方都存储， 那是不是可以理解为数据大致会膨胀了4倍？

死磕 Elasticsearch 知识星球（http://t.cn/RmwM3N9）

 

非常有必要好好梳理一下，于是就有了这篇文章。

Elasticsearch 数据结构的理解和合理使用，对深入理解 Elasticsearch大有裨益！

 

1、数据存储认知前提

正如 Elastic 官方文档所说：

 

Elasticsearch 特点之一是：分布式文档存储。

 

Elasticsearch不会将信息存储为类似列数据库的行（row），而是存储为已序列化为JSON文档的复杂数据结构。

 

当集群中有多个Elasticsearch节点时，存储的文档会分布在整个集群中，并且可以从任何节点立即访问。

 

存储文档后，将在1秒钟内（默认刷新频率为1s）几乎实时地对其进行索引和完全搜索。

 

如何做到快速索引和全文检索的呢？ 

 

Elasticsearch使用倒排索引的数据结构，该结构支持非常快速的全文本搜索。

 

倒排索引列出了出现在任何文档中的每个唯一单词，并标识了每个单词出现的所有文档。

 

索引可以认为是文档的优化集合，每个文档都是字段的集合，这些字段是包含数据的键值对。

默认情况下，Elasticsearch 对每个字段中的所有数据建立索引，并且每个索引字段都具有专用的优化数据结构。

 

例如，文本字段存储在倒排索引中，数字字段和地理字段存储在BKD树中。

不同字段具有属于自己字段类型的特定优化数据结构，并具备快速响应返回搜索结果的能力使得 Elasticsearch 搜索飞快！

 

1、Inverted Index 倒排索引

 

面对海量内容，如何快速的找到包含用户查询词的内容，倒排索引扮演了关键角色。

 

倒排索引是单词到文档映射关系的最佳实现形式。

 

下图是：书的末页的索引结构，展示了核心关键词与书页码的对应关系。

试想一下，没有这个索引页，根据关键词从全书查找有多慢，就能直观体会出索引的妙处！

 

拿官方文档的示例：

 

假设我们有两个文档，每个文档的 content 域包含如下内容：

对索引编制索引会受到标记化和标准化的处理analysis。

 

数据索引化制约因素：分词器 analyzer 的选型。

 

倒排索引（基于 默认Standard 标准分词器分词）如下所示：

如上所示，对于文档中的每个词，都包含了其所在文档的列表。

 

 • 在索引时创建
 • 序列化到磁盘
 • 全文搜索非常快
 • 不适合做排序
 • 默认开启

 • 查询
 • 全文检索

2、Doc Values 正排索引

在 Elasticsearch 中，Doc Values 就是一种列式存储结构，默认情况下每个字段的 Doc Values 都是激活的（除了 text 类型），Doc Values 是在索引时创建的，当字段索引时，Elasticsearch 为了能够快速检索，会把字段的值加入倒排索引中，同时它也会存储该字段的 Doc Values。

 

区别于倒排索引的定义，Doc Values 被定义为：“正排索引”。

 • 在索引时创建
 • 序列化到磁盘
 • 适合排序操作
 • 将单个字段的所有值一起存储在单个数据列中
 • 默认情况下，除text之外的所有字段类型均启用 Doc Values。

Elasticsearch 中的 Doc Values 常被应用到以下场景：

 

 • 对一个字段进行排序
 • 对一个字段进行聚合
 • 某些过滤，比如地理位置过滤
 • 某些与字段相关的脚本计算

注意：

 

因为文档值被序列化到磁盘，我们可以依靠操作系统的帮助来快速访问。

 

 • 当 工作集（working set） 远小于节点的可用内存，系统会自动将所有的文档值保存在内存中，使得其读写十分高速；

 

 • 当其远大于可用内存，操作系统会自动把 Doc Values 加载到系统的页缓存中，从而避免了 jvm 堆内存溢出异常。

 

对于不需要：排序、聚合、脚本计算、地理位置过滤的业务场景，可以考虑禁用：Doc Values，以节约存储。

3、fielddata

如前第1、2小结所述：

 

 • 搜索需要回答“哪个文档包含此词？”的问题。借助：倒排索引实现。
 • 排序和汇总则需要回答一个不同的问题：“此字段对本文档的价值是什么？” 。借助：正排索引实现。

text 类型字段是不支持 Doc Values正排索引的，text字段使用是：查询时创建的基于的内存数据结构（query-time in-memory data structure） fielddata。

 

fielddata 将 text 字段用于聚合、排序或在脚本中使用时，将按需构建此数据结构。

 

实现机理：它是通过从磁盘读取每个段的整个反向索引，反转词项↔︎文档关系并将结果存储在JVM堆中的内存中来构建的。

严格意义讲，2.2 的示例，放到这里会更合适。

 • 适用于文档之类的操作
 • 但仅适用于 text 文本字段类型
 • 在查询时创建
 • 内存中数据结构
 • 没有序列化到磁盘
 • 默认情况下被禁用（构建它们很昂贵，并且在堆中预置）

 • 全文统计词频
 • 全文生成词云
 • text类型：聚合、排序、脚本计算

 • 在启用字段数据之前，请考虑为什么将文本字段用于聚合、排序或在脚本中使用。
 • 启用 fielddata 通常没有任何意义，因为它非常耗费内存资源。
 • 仅仅是做全文搜索的应用，就不需要启用fielddata。

4、_source 字段解读

_source 字段包含在索引时间传递的原始JSON文档主体。

 

_source 字段本身未构建索引（因此不可搜索），但已存储该字段，以便在执行获取请求（如get或search）时可以将其返回。

 

 

第一：尽管非常方便，但是source字段确实会导致索引内的存储开销。因此，可以将其禁用。

 

第二：禁用前要做好以下衡量 禁用 _source 后，如下操作将不可用：

 

1.update, update_by_query 和 reindex API
2.高亮操作

所以，要在存储空间、业务场景之间权衡利弊后选型。

5、store 字段解读

默认情况下，对字段值进行索引以使其可搜索（第1节的 倒排索引），但不存储它们。

 

这意味着可以查询该字段，但是无法检索原始字段值。

 

通常这无关紧要。该字段值已经是_source字段的一部分，默认情况下已存储。

 

但，某些特殊场景下，如果你只想检索单个字段或几个字段的值，而不是整个_source的值，则可以使用源过滤来实现。

 

这个时候， store 就派上用场了。

 

如 5.2 示例，在某些情况下，存储字段可能很有意义。例如，采集的新闻数据是：带有标题、日期和很大内容字段的文档，

 

则可能只想检索标题和日期，而不必从较大的_source字段中提取这些字段。

 

6、小结

回到文章开头的两个问题：

 

 • 问题1：看完本文后，doc values , field data , store fields  就非常清晰了。

 

 • 问题2：字段类型不一样，存储不一样。默认：倒排索引默认所有字段都启用，正排索引 Doc Values 非 text 类型默认启用， source （存储原始文档的 所有字段的 json 结构数据）和 store （存储指定字段的 json 数据） 的启用与否需要结合业务实际。假设：正排索引、倒排索引、_source 、store 都启用了，存储肯定会增加，但不是线性的 4倍。

 

对于不明白的问题，反复研读官方文档，拷贝到kibana Dev tool 去实践，直到弄明白为止。

 

文章尽量参考官方文档，尽管如此，难免表述纰漏，欢迎大家指正交流。

 

和你一起，死磕 Elasticsearch ！