父文章

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

底层存储结构

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

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

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

控制单个索引的文档数量不要过高，最好在数百万条以内，以免影响性能。
对于大规模数据，建议进行分片和副本配置，以提高并发能力和可靠性。
充分利用 Elasticsearch 的分布式特性，合理分配数据节点和查询节点。
根据数据的访问模式，优化搜索引擎的查询策略，提高检索速度和准确性。

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

单个文档的大小上限

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

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

控制单个文档的大小：建议单个文档的大小控制在几兆字节以内，这样有助于提高搜索效率以及避免服务器出现瓶颈。
对于非常大的文档，建议拆分成适当大小的文档进行索引：如果因为某种原因，必须对非常大的文档进行索引，则可以将其拆分成适当大小的子文档进行索引。这将有助于提高检索速度以及避免服务器出现瓶颈。
对于结构化数据，使用正确的数据类型：正确地为数据类型分配数据类型有助于优化索引和建议搜索。如果数据的类型被不正确地分配，索引可能会非常缓慢，导致查询的运行时间过长。数据类型分配还有助于更好地实现相似度分数算法，并且最终结果的排序更准确。
避免不必要的字段：构建文档时需要非常谨慎地考虑哪些字段是必要的，哪些是不需要的。当建立更多的字段或重复的字段时，将减慢检索速度。通过删除不需要的字段和频繁使用小字段，确保完全利用 lucene 倒排索引，是索引文档的最优方式。

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