可扩展性和弹性
集群,节点,分片
ElasticSearch可随时构建,并根据你们的需要进行扩展。它是通过自然的分配来实现的。您可以将服务器(节点)添加到集群以增加容量,ElasticSearch会自动将数据和查询负载分布到所有可用节点上。ElasticSearch不需要彻底检查您的应用程序,它知道如何平衡多节点集群以提供规模和高可用性。节点越多,越轻松。
ElasticSearch是怎么工作的?在这个疑问下,理解 弹性搜索索引实际上只是一个或多个物理分片的逻辑分组,其中每个分片实际上是一个独立的索引。通过将索引中的文档分布在多个分片上,并将这些分片分布在多个节点上,ElasticSearch可以确保冗余,这既可以防止硬件故障,也可以随着节点添加到集群中而增加查询容量。随着集群的增长(或缩小),ElasticSearch会自动迁移分片以重新平衡集群。
有两种类型的分片:primaries 和副本。索引中的每个文档都属于一个主分片,副本分片是主分片的副本。副本分片提供数据的冗余副本,防止硬件故障,并增加服务于读取请求(搜索或检索文档)的容量。
索引中主分片的数量在创建索引时是固定的,但是副本分片的数量可以随时更改,而不会中断索引或查询操作。
it depends...(这取决于…)
对于一个索引配置的切分大小和主切分的数量,有许多性能考虑因素和权衡因素。分片越多,维护这些索引的开销就越大。分片大小越大,当ElasticSearch需要重新平衡集群时,分配分片所需的时间就越长。
查询大量的小分片可以加快每个分片的处理速度,但是更多的查询意味着更多的开销,因此查询较小数量的较大分片可能更快。简而言之……视情况而定。
作为起点:
-
目标是将平均碎片大小保持在几GB到几十GB之间。对于基于时间的数据的用例,通常可以看到20GB到40GB范围内的碎片。
-
避免较多分片的问题。一个节点的分片数据可保持在一个可用的堆空间比列。作为一项基本的准则,堆空间的每GB的分片数量至少为20。
确定用例最佳配置的最佳方法是通过使用自己的数据和查询进行测试。
如果发生灾难(in case of disaster)
出于性能原因,集群中的节点需要位于同一网络上。在不同数据中心的节点之间平衡集群中的分片只需要太长时间。但是高可用性体系结构要求您避免将所有鸡蛋放在一个篮子中。在一个位置发生重大故障时,另一个位置的服务器需要能够接管。无缝连接。答案是什么?跨群集复制(CCR)。
CCR提供了一种方法,可以自动将索引从主集群同步到可充当热备份的辅助远程集群。如果主集群出现故障,则辅助集群可以接管。您还可以使用CCR创建辅助集群,以在地理位置接近您的用户的情况下为读取请求提供服务。
跨群集复制是主动-被动的。主集群上的索引是活动的前导索引,处理所有写请求。复制到次要群集的索引是只读的关注者。
监控/关注
与任何企业系统一样,您需要工具来保护、管理和监控您的ElasticSearch集群。集成到ElasticSearch中的安全、监视和管理功能使您能够使用Kibana作为管理集群的控制中心。数据汇总和索引生命周期管理等功能可帮助您随着时间的推移智能地管理数据。