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 搜索的效率。

你可能感兴趣的:(lucene,搜索引擎,elasticsearch)