java的Elasticsearch从基本概念到生产使用分析
这篇文章主要介绍"java的Elasticsearch从基本概念到生产使用分析"，在日常操作中，相信很多人在java的Elasticsearch从基本概念到生产使用分析问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答"java的Elasticsearch从基本概念到生产使用分析"的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
基础概念
对于一个Elasticsearch(ES)的新手，首先需要学习一些基本概念。
Elasticsearch项目源于Java的优秀的分布式搜索引擎Apache Lucene，Luncene还派生了另一个非常优秀的搜索项目Solor。不管是是Elasticsearch和Solor其底层保存数据和搜索引擎部分都是Lucene。ES在基于Lucene内核上更加优秀的一个分布式实时搜索引擎，尤其在分布式集群和横向扩展方面做的非常好，可以很轻松地运行管理数千个Lucene实例。
在ES架构中的最高级别单元是群集(Cluster)。集群是ES节点和索引的集合。
节点(Node)是ES的实例。它们可以是单个服务器，也可以仅仅为服务器上运行的ES进程。注意：服务器并等价于节点不相同。VM虚拟机或物理服务器都可以容纳许多ES进程，每个ES进程都是一个节点。节点可以完全加入一个集群。有不同类型的节点。其中最有重要两个节点是数据节点(Data Node)和备选主节点(Master-Eligible Node)。一个节点可以同时具备多种属性。数据节点运行所有数据操作。即存储，索引和搜索数据。备选主节点用来投票为运行集群和索引管理的主机。
索引(Index)是数据的高级抽象。索引本身不保存数据。它们只是对实际存储数据的另一种抽象。对数据执行的任何操作(例如插入，删除，建立索引和搜索)都会对索引产生影响。索引可以完全属于一个簇，并且由分片组成。
分片(Shard)是Apache Lucene的实例。一个分片可以容纳许多文档。分片是实际数据存储，索引和搜索的对象。一个分片恰好属于一个节点和索引。分片分两种类型：主(primary)分片和副本(replica)。两者基本上是等同的，它们拥有相同的数据，并且并行搜索所有分片。在拥有相同数据的所有分片中，一个是主分片，是唯一可以接受索引请求的分片。如果主分片所在的节点死亡，则副本分片将自动接管成为主分片。然后，ES将创建一个新的副本分片并复制数据。总体上可以用一个简单的图示如下：
深入了解
如果想运行一个系统，首先需要了解该系统。在了解基础概念后，我们来实际了解Elasticsearch的各个部分。
Quorum
理解Elasticsearch组织是一个民主机制很重要。节点通过投票决定谁是老大Master，即主节点。该主节点主运行很多集群管理进程，在集群中享有最终决定权。ES的 选举是有条件的，既只有备选节点才能参与选举成为主节点。符合Master资格的是其配置中设置为下面条件的所有节点：
node.master: true
在群集启动时或主节点退出群集时，所有符合主节点条件的节点都会开始选举新的主节点。因此，需要具有2n + 1个符合主机要求的节点。否则，可能会出现选举55开的裂脑情况。
节点加入
当ES流程启动时，它就独立自由存在，他如何知道自己所处的集群呢?有不同的方法可以完成此操作。但常用一种叫做种子主机(Seed Hosts)的方法来这个过程。
Elasticsearch节点会不断地和他所见过的所有其他节点进行对话。因此，一个节点最初只需资询几个其他节点即可了解整个集群。整个过程不是一个恒定的过程：节点不属于集群时，它们仅共享有关他们发现的其他节点的信息。一旦加入群集，节点便会停止该操作，并依靠当选群集主节点共享所发生的变化信息。这样可以节省了大量不必要的网络闲聊。在ES 7.x中，节点间只交流他们所见到到备选主机节点，发现过程会忽略备选主机节点。
以一个三节点集群的为例：
初始状态：
节点A和C只是知道B。B是种子主机。种子主机要么以配置文件的形式提供给ES，要么直接放入elasticsearch.yml中。
节点A与B连接并交换信息：
一旦节点A连接到B，B现在就知道了A的存在。A没有任何变化。
节点C连接并与B共享信息
现在C连线，C会和B通讯。B就会告诉C A的存在。C和B现在都知道群集中的所有节点。下一次A重新连接到B，它也会知道C的存在。
段合并
前面我们说过，分片存储数据。数据将以..文件的形式存储在文件系统中。在Lucene和Elasticsearch中，这些文件被称为段(Segments)。一个分片会有一到数千个段。
段是物理上实际存在的文件，可以在ES安装的data目录中看到。所以端文件的操作是个开销。如果要查看，必须要找到对应的文件并打开。如果要打开许多文件，那么将会带来很大的开销。由于Lucene中的段是不可变的，只能写入不可更改。放入ES中的每个文档都将创建一个仅包含单个文档的段。那么，如果集群中有十亿个文档则对应会有十亿个段文件么?
实际上不是这样的。在Lucene后台，会进行段合并。该操作不对段进行更改，但是可以两个较小段的数据合并创建新的段，并将合并的两个小段清理掉：
lucene会不断段合并，并 保持段数量不会太大。
消息路由
在Elasticsearch中，可以对集群中的任何节点运行任何命令，并且保持结果将相同。然而，在最底层文档将只存在于一个主分片及其副本中，而ES该文档位于何处，也没有映射说明特定文档位于特定分片中。
如果进行搜索，请求入口点ES节点会将其广播到索引中的所有分片，这些分片来查看该文档的所有段。如果要插入，则ES节点会随机选择一个主分片并将文档放在其中，然后将其写入该主要分片及其所有副本。
生产实践
最后部分来说说在生产中如何部署和管理Elasticsearc。
Elasticsearch实践中最常见的一个问题是，估计需要的集群规模，包括节点数量，需要硬件资源等。
内存
首先要考虑内存使用，内存大小将限制所有其他资源。
Java堆
ES是用Java开发的。Java要用堆，可以将其视为Java保留的内存。关于堆，有所有重要的东西会使这个文档的大小增加三倍。
关于尽量可能多的使用，但堆大小不要超过30G。
有一个这很多人都不知道的关于堆的秘密：堆中的每个对象都需要一个唯一的地址，即一个对象指针。该地址的长度是固定的，所以可以寻址的对象数量是有限的。简而言之，在某一时刻，Java会需要使用压缩的对象指针而不是未压缩的对象指针。这样每个内存访问都将涉及其他步骤，并且速度会慢得多。请不要超过此阈值(大约32G)。
根据社区对Elasticsearch的不同文件系统，堆大小，FS和BIOS的组合的基准测试，结果如下：
如上图所示，从32G的堆大小开始，性能突然开始变差(50%访问延时，越小越好)。
吞吐量结果(越大越好)也类似：
总之，请使用29G或30G的内存，请使用XFS，并尽可能使用hardwareprefetch和llc-prefetch。
文件缓存
绝大大多数人会在Linux上运行Elasticsearch，Linux使用RAM作为文件系统缓存。常见的建议是将64G用于ES服务器，这样一半的缓存，一半的堆。大型ES群集(如用于日志记录)可以从拥有大容量的FS缓存中获益。如果所有的索引都适合堆，则不需要那么多。
Elasticsearch 7.x会在其堆上需要一定数量的直接内存，并且还有其他开销，这就是为什么建议堆大小不超过物理内存的50%的原因。这是一个上限，64GB主机上的32GB堆可能不能为文件系统缓存保留太多空间。文件系统缓存是Elasticsearch/Lucene性能的关键，并且较小的堆有时可以产生更好的性能(它们为文件系统缓存留出更多空间，并且对于GC而言也更便宜)。
CPU
这取决于对群集执行的操作。如果要进行大量索引编制，则与仅执行日志记录相比，需要更多，更快的CPU。对于日志记录，一般来说8核CPU就绰绰有余，但是更具不同用途，要具体实践而定。
磁盘
如果索引分配到合适的内存，则磁盘仅在节点冷时才重要。而且实际可以存储的数据量取决于索引布局。每个分片都是Lucene实例，它们都有内存需求。这样可以在堆中容纳最大数量的分片。通常，可以将所有数据磁盘放入RAID0。应该在Elasticsearch级别进行复制，因此丢失节点无关紧要。不要请将LVM和多个磁盘一起使用，因为LVM一次只能写入一个磁盘，根本就不会给带来多个磁盘的好处。
关于文件系统和RAID设置：
调度器：cfq和截止日期优于noop。如果有nvme，Kyber可能会很好(未严格测试过)
QueueDepth：尽可能高
预读：是的，请使用
Raid块大小：无影响
FS块大小：无影响
FS类型：XFS优于ext4
索引布局
大程度上取决于的用例。从日志集群背景为例来说。
分片
简而言之：
对于写繁重的工作负载，主分片=节点数
于读繁重的工作负载，主分片*复制=节点数
更多副本=更高的搜索性能
可以通过一个公式来计算写入性能：
节点吞吐量*主分片数
原因很简单：如果只有一个主分片，那么只能像一个节点可以写入数据那样快地写入数据，因为一个分片只能位于一个节点上。如果确实想优化写入性能，则应确保每个节点上只有一个分片(主节点或副本)，因为副本显然获得与主节点相同的写入，并且写入很大程度上取决于磁盘IO。
注意：如果有很多索引，则可能不正确，而瓶颈可能是其他原因。
如果要优化搜索性能，可以通过以下公式给出搜索性能：
节点吞吐量*(主分片数+副本数)
对于搜索，主碎片和副本分片基本上是等同的。因此，如果想提高搜索性能，只需增加副本数即可。
规模大小
关于索引大小有很懂资料。我们在此一个经验是：
30G堆=每个节点最多140个分片
使用多余140分片，可能会使Elasticsearch进程崩溃并出现内存不足错误。因为每个分片都是Lucene实例，并且每个实例都需要一定数量的内存。所以，每个节点可以有多少个分片。
如果有节点数量，分片数量和索引大小，则可以容纳多少个索引：
分片数量=(140*节点数)/(主分片数*副本率)
这样就可以计算出，所需要的大小：
索引大小=(节点数 * 硬盘大小)/索引数量
请注：较大的索引也相对较慢。对于日志记录来说，一定程度是可以的，但是对于真正搜索繁重的应用程序，应该根据所拥有的内存数量来增加大小。
段合并
请记住，每个段都是文件系统上的实际文件。基本上，对于每个搜索查询，都会转到索引中的所有分片，再从那里到分片中的所有段。段文件太多会极大地增加群集的读取IOPS，直至无法使用。因此，最好将段数保持在尽可能低的水平。
有一个force_merge API，允许将段合并到一定数量，例如1。如果进行索引轮换，例如，因为使用Elasticsearch进行日志记录，则在不使用群集时进行常规使用中的强制合并是一个好主意。
强制合并会占用大量资源，并且会大大降低群集的速度，如果有很多索引，则必须要强制合并。
集群布局
对于除最小设置以外的所有内容，最好使用专用的符合主机资格的节点。保持具有2n + 1个备选节点以确保仲裁。但是对于数据节点，只希望能够随时添加一个新节点，而不必担心。另外，也不希望数据节点上的高负载影响的主节点。
最后，主节点是种子节点的理想候选者。
记住，种子节点是在Elasticsearch中执行节点发现的最简单方法。由于的主节点很少会会更改，因此，它们是最佳选择，他们已经知道了集群中的所有其他节点。
主节点可能很小，一个核心甚至4G的内存就可以满足大多数群集的需求。与往常一样，关注实际使用情况并进行相应调整。
监控
监控是个好东西，对Elasticsearch也是如此。ES为提供了大量的指标，并且支持以JSON的形式为方便调用，在监控工具中添加这些指标非常简单。以下是一些有用的监控指标包括：
段数，堆使用率，堆GC时间，搜索、索引、合并的平均用时，IOPS，磁盘利用率等
到此，关于"java的Elasticsearch从基本概念到生产使用分析"的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注网站，小编会继续努力为大家带来更多实用的文章！
