从400+节点Elasticsearch集群的运维中，我们总结了这些履历
|
副问题[/!--empirenews.page--]
Meltwater 天天要处理赏罚数百万量级的帖子数据，因此必要一种能处理赏罚该量级数据的存储和检索技能。
从 0.11.X 版本开始我们就已经是 Elasticsearch 的忠适用户了。在经验了一些妨害之后，最终我们以为做出了正确的技能选型。 Elasticsearch 用于支持我们的首要媒体监控应用，客户通过该应用可以检索和说明媒体数据，好比消息文章、(果真的)Facebook 帖子、Instagram 帖子、博客和微博。我们通过行使一个殽杂 API 来网络这些内容，并爬取和稍作加工，使得它们可被 Elasticsearch 检索到。 本文将分享我们所学到的履历、怎样调优 Elasticsearch，以及要绕过的一些陷阱。 数据量 天天都稀有目相等复杂的消息和微博发生;在岑岭期必要索引约莫 300 多万社论文章，和近 1 亿条交际帖子数据。个中社论数据恒久生涯以供检索(可回溯到 2009 年)，交际帖子数据生涯近 15 个月的。当前的主分片数据行使了约莫 200 TB 的磁盘空间，副本数据约莫 600 TB。 我们的营业每分钟有 3 千次哀求。全部的哀求通过一个叫做“search-service”的处事，该处事会依次完成全部与 Elasticsearch 集群的交互。大部门检索法则较量伟大，包罗在面板和消息流中。好比，一个客户也许对 Tesla 和 Elon Musk 感乐趣，但但愿解除全部关于 SpaceX 或 PayPal 的信息。用户可以行使一种与 Lucene 查询语法相同的机动语法，如下：
我们最长的此类查询有 60 多页。重点是：除了每分钟 3 千次哀求以外，没有一个查询是像在 Google 里查询“Barack Obama”这么简朴的;这的确就是可骇的野兽，但 ES 节点必需全力找出一个匹配的文档集。
版本 我们运行的是一个基于 Elasticsearch 1.7.6 的定制版本。该版本与 1.7.6 骨干版本的独一区别是，我们向后移植(backport)了 roaring bitsets/bitmaps 作为缓存。该成果是从 Lucene 5 移植到 Lucene 4 的，对应移植到了 ES 1.X 版本。Elasticsearch 1.X 中行使默认的 bitset 作为缓存，对付稀少功效来说开销很是大，不外在 Elasticsearch 2.X 中已经做了优化。 为何不行使较新版本的 Elasticsearch 呢?首要缘故起因是进级坚苦。在主版本间转动进级只合用于从 ES 5 到 6(从 ES 2 到 5 应该也支持转动进级，但没有试过)。因此，我们只能通过重启整个集群来进级。宕机对我们来说险些不行接管，但或者可以应对一次重启所带来的约莫 30-60 分钟宕机时刻;而真正令人担忧的，是一旦产生妨碍并没有真正的回滚进程。 截至今朝我们选择了不进级集群。虽然我们但愿可以进级，但今朝有更为紧要的使命。现实上该怎样实验进级尚未有定论，很也许选择建设另一个新的集群，而不是进级现有的。 节点设置 我们自 2017 年 6 月开始在 AWS 上运行主集群，行使 i3.2xlarge 实例作为数据节点。之前我们在 COLO(Co-located Data Center)里运行集群，但后续迁徙到了 AWS 云，以便在新呆板宕机时能赢得时刻，使得我们在扩容和缩容时越发弹性。 我们在差异的可用区运行 3 个候选 master 节点，并配置 discovery.zen.minimum_master_nodes 为 2。这是停止脑裂题目 split-brain problem 很是通用的计策。 我们的数据集在存储方面，要求 80% 容量和 3 个以上的副本，这使得我们运行了 430 个数据节点。早先规划行使差异层级的数据，在较慢的磁盘上存储较旧的数据，可是因为我们只有相干的较低量级旧于 15 个月的数据(只有编辑数据，由于我们扬弃了旧的交际数据)，然而这并未奏效。每个月的硬件开销宏大于运行在 COLO 中，可是云处事支持扩容集群到 2 倍，而险些不损耗费几多时刻。 你也许会问，为何选择本身打点维护 ES 集群。着实我们思量过托管方案，但最后照旧选择本身安装，来由是： AWS Elasticsearch Service 袒露给用户的可控性太差了， Elastic Cloud 的本钱比直接在 EC2 上运行集群要高 2-3 倍。 为了在某个可用区宕机时掩护我们自身，节点分手于 eu-west-1 的全部 3 个可用区。我们行使 AWS plugin 来完成该项设置。它提供了一个叫做 aws_availability_zone 的节点属性，我们把 cluster.routing.allocation.awareness.attributes 配置为 aws_availability_zone。这担保了 ES 的副本尽也许地存储在差异的可用区，而查询尽也许被路由到沟通可用区的节点。 这些实例运行的是 Amazon Linux，姑且挂载为 ext4，有约 64GB 的内存。我们分派了 26GB 用于 ES 节点的堆内存，剩下的用于磁盘缓存。为何是 26GB?由于 JVM 是在一个黑邪术之上构建的。 我们同时行使 Terraform 自动扩容组来提供实例，并行使 Puppet 完成统统安装设置。 索引布局 由于我们的数据和查询都是基于时刻序列的，以是行使了 time-based indexing，相同于 ELK (elasticsearch, logstash, kibana) stack。同时也让差异范例的数据生涯在差异的索引库中，以便诸如社论文档和交际文档类数据最终位于差异的逐日索引库中。这样可以在必要的时辰只扬弃交际索引，并增进一些查询优化。每个日索引运行在两个分片中的一个。 该项配置发生了大量的分片(靠近 40k)。有了这么多的分片和节点，集群操纵偶然变得更非凡。好比，删除索引好像成为集群 master 的手段瓶颈，它必要把集群状态信息推送给全部节点。我们的集群状态数据约 100 MB，但通过 TCP 压缩可镌汰到 3 MB(可以通过 curl localhost:9200/_cluster/state/_all 查察你本身集群的状态数据)。Master 节点如故必要在每次改观时推送 1.3 GB 数据(430 节点 x 3 MB 状态巨细)。除了这 1.3 GB 数据外，尚有约 860 MB 必需在可用区(好比 最根基的通过民众互联网)之间传输。这会较量耗时，尤其是在删除数百个索引时。我们但愿新版本的 Elasticsearch 能优化这一点，起首从 ES 2.0 支持仅发送集群状态的差分数据这一特征开始。 机能 如前所述，我们的 ES 集群为了满意客户的检索需求，必要处理赏罚一些很是伟大的查询。 为应对查询负载，已往几年我们在机能方面做了大量的事变。我们必需实行公等分享 ES 集群的机能测试，从下列引文就可以看出。 （编辑：河北网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
