江苏龙网

  1. 主页 > 生活百科 > >

Elasticsearch全攻略( 三 )

Elasticsearc


调度器：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，磁盘利用率等
总结本文，我们由简到深入再到实践实战，介绍了Elasticsearch使用的全部信息 。主要是分享干货 ，没有其他枝枝节节的描写和内容，希望对大家有所帮助 。




推荐阅读


上一篇：如何彻底删除烦人的电脑弹窗广告？

下一篇：使用网络构建复杂布局超实用的技巧，赶紧收藏吧