Elasticsearch底层存储结构 和 一些上限 from chatgpt

父文章 

hbase hive elasticsearch(elsearch) mysql mongodb 技术选型_个人渣记录仅为自己搜索用的博客-CSDN博客

底层存储结构

Elasticsearch 底层存储结构主要由以下几种组件构成：

1. 索引(Index)：每个节点含有一个或多个索引，除了一些特殊的索引，每个索引可以被分成多个分片。
2. 分片(Shard)：文档分片用于分配数据到多个节点，每个分片本身就是一个完全独立的索引。
3. 主分片(Primary Shard)：原始数据划分的分片，每个文档在确认单个主分片之上都会具有复制的副本。
4. 副本分片(Replica Shard)：主分片的拷贝，主分片上的每个文档都有一个或多个备份，可以用于保证高可用性。
5. Lucene 倒排索引(Lucene Inverted Index)：每个文档建立索引后都会生成一个 Lucene 倒排索引，方便后续查询操作。
6. Mappings：相当于关系型数据的 Schema，规定了索引中文档应该具备的字段、数据类型、分析器等详细信息。
7. Document：类似于一行记录或一条文档。
8. Type：文档类型，可以用于进行文档数据的较细粒度分类。但 Elasticsearch 7.0 开始已经废除，使用 _doc 进行代替。
9. Field：文档中每个字段代表的属性。

综上，Elasticsearch 利用分片和副本的策略将巨量的数据广泛分散式存储在集群里，同时通过 Lucene 倒排索引进行文本检索操作，使得查询操作延迟较低、缩短了查询所需的搜索时间，实现了搜索引擎高效稳定的运行。

https://www.cnblogs.com/tech-lee/p/15225276.html

Elasticsearch分别为每个field都建立了一个倒排索引，一个字段有一个自己的倒排索引。Kate, John, 24, Female这些叫term，而[1,2]就是Posting List。Posting list就是一个int的数组，存储了所有符合某个term的文档id。

Elasticsearch 内部数据结构深度解读 - 腾讯云开发者社区-腾讯云

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

问题1：”群主有介绍 doc value, field data, store fields 比较好的文章么？一直感觉有点模糊“ 问题2：“请教下星主关于ES存储相关的问题， 一个文档有如下几个地方可能会存储：

Elasticsearch 存储原理-lucene底层数据结构_lucene 数据结构_水的精神的博客-CSDN博客

很多使用Elasticsearch的同学会关心数据存储在ES中的存储容量，会有这样的疑问：xxTB的数据入到ES会使用多少存储空间。这个问题其实很难直接回答的，只有数据写入ES后，才能观察到实际的存储空间。比如同样是1TB的数据，写入ES的存储空间可能差距会非常大，可能小到只有300~400GB，也可能多到6-7TB，为什么会造成这么大的差距呢？究其原因，我们来探究下Elasticsearch中的数据是如何存储。文章中我以Elasticsearch 2.3版本为示例，对应的lucene版本是5.5，Elasticsearch现在已经来到了6.5版本，数字类型、列存等存储结构有些变化，但基本的概念变化不多，文章中的内容依然适用。

Elasticsearch 原理（上） -- 文档存储结构与索引数据结构 - 腾讯云开发者社区-腾讯云

Elasticsearch对外提供的是index的概念，可以类比为DB，用户查询是在index上完成的，每个index由若干个shard组成，以此来达到分布式可扩展的能力。比如下图是一个由10个shard组成的index。

索引数量的上限

Elasticsearch并没有硬性规定索引数量的上限。因为Elasticsearch的分布式原理，您可以水平扩展到多个节点并分配分片（shard）来处理大量数据和请求。不过，高数量的索引会导致JVM进程RAM负荷增加，从而可能引起麻烦，比如：

• 内存压力降低了垃圾回收性能；
• 如果Java代码运行时间太久，会花费大量时间进行垃圾回收（这被称为STW）：
  ◦ 如果Elasticsearch JVM因STW阻塞并停止，则无法响应请求从而导致数据不可快速搜寻；
  ◦ 阻塞的时间取决于可用RAM和API使用情况，如果您遇到了这个问题可能最简单的解决方案是添加更多的节点；
• 不同设备的CPU和存储设备在工作环境中会发挥不同程度的效率，因此很重要思考如何根据系统制约而确定令一个合理的最大值；

尽管Elasticsearch支持无限索引上限，但在实践中，理智的索引命名、常规的管理和维护等依然十分重要，因而索引数量上限也取决于如何管理您的Elasticsearch实例。 。

Elasticsearch 的文档数量上限主要取决于所使用的硬件、集群的规模和配置以及文档的大小等因素。一般来说，Elasticsearch 对文档数量的限制是非常高的，可以应对中小型和大规模的数据集。

在实际使用过程中，建议保持以下几点：

1. 控制单个索引的文档数量不要过高，最好在数百万条以内，以免影响性能。

2. 对于大规模数据，建议进行分片和副本配置，以提高并发能力和可靠性。

3. 充分利用 Elasticsearch 的分布式特性，合理分配数据节点和查询节点。

4. 根据数据的访问模式，优化搜索引擎的查询策略，提高检索速度和准确性。

总的来说，Elasticsearch 的文档数量上限不受严格限制，但需要合理使用并配合相关的硬件、软件和网络配置，以达到最佳的性能。

单个文档的大小上限

Elasticsearch 单个文档的大小上限一般是默认限制在 100MB。然而，建议单个文档的大小最好不要超过几兆字节，这将有助于提高搜索效率和响应速度。

以下是一些关于 Elasticsearch 单个文档大小的建议：

1. 控制单个文档的大小：建议单个文档的大小控制在几兆字节以内，这样有助于提高搜索效率以及避免服务器出现瓶颈。

2. 对于非常大的文档，建议拆分成适当大小的文档进行索引：如果因为某种原因，必须对非常大的文档进行索引，则可以将其拆分成适当大小的子文档进行索引。这将有助于提高检索速度以及避免服务器出现瓶颈。

3. 对于结构化数据，使用正确的数据类型：正确地为数据类型分配数据类型有助于优化索引和建议搜索。如果数据的类型被不正确地分配，索引可能会非常缓慢，导致查询的运行时间过长。数据类型分配还有助于更好地实现相似度分数算法，并且最终结果的排序更准确。

4. 避免不必要的字段：构建文档时需要非常谨慎地考虑哪些字段是必要的，哪些是不需要的。当建立更多的字段或重复的字段时，将减慢检索速度。通过删除不需要的字段和频繁使用小字段，确保完全利用 lucene 倒排索引，是索引文档的最优方式。

综上，保持单个文档的大小在几兆字节的范围之内，想方设法优化数据分配以及避免不必要的字段可以帮助优化 Elasticsearch 搜索的效率。