Elasticsearch全攻略( 二 ) _Elasticsearch

文章插图

段合并前面我们说过，分片存储数据。数据将以..文件的形式存储在文件系统中。在Lucene和Elasticsearch中，这些文件被称为段（Segments）。一个分片会有一到数千个段。
段是物理上实际存在的文件，可以在ES安装的data目录中看到。所以端文件的操作是个开销。如果要查看，必须要找到对应的文件并打开。如果要打开许多文件，那么将会带来很大的开销。由于Lucene中的段是不可变的，只能写入不可更改。放入ES中的每个文档都将创建一个仅包含单个文档的段。那么，如果集群中有十亿个文档则对应会有十亿个段文件么？
实际上不是这样的。在Lucene后台，会进行段合并。该操作不对段进行更改，但是可以两个较小段的数据合并创建新的段，并将合并的两个小段清理掉：

文章插图

lucene会不断段合并，并保持段数量不会太大。
消息路由在Elasticsearch中，可以对集群中的任何节点运行任何命令，并且保持结果将相同。然而，在最底层文档将只存在于一个主分片及其副本中，而ES该文档位于何处，也没有映射说明特定文档位于特定分片中。
如果进行搜索，请求入口点ES节点会将其广播到索引中的所有分片，这些分片来查看该文档的所有段。如果要插入，则ES节点会随机选择一个主分片并??将文档放在其中，然后将其写入该主要分片及其所有副本。
生产实践【Elasticsearch全攻略】最后部分来说说在生产中如何部署和管理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设置：