针对具有大量聚合的大型群集的ElasticSearch设置

Question

针对具有大量聚合的大型群集的ElasticSearch设置

Joh*_*ith 15 scalability aggregate cluster-computing elasticsearch

上下文和当前状态

我们正在将我们的集群从Cassandra迁移到完整的ElasticSearch集群.我们正在为每秒平均约250-300个文档索引文档.在ElasticSearch 1.2.0中,它代表每天~8Go.

{
 "generic":
    {
      "id": "twi471943355505459200",
      "type": "twitter",
      "title": "RT @YukBerhijabb: The Life is Choice - https://m.facebook.com/story.php?story_fbid=637864496306297&id=100002482564531&refid=17",
      "content": "RT @YukBerhijabb: The Life is Choice - https://m.facebook.com/story.php?story_fbid=637864496306297&id=100002482564531&refid=17",
      "source": "<a href=\"https://twitter.com/download/android\" rel=\"nofollow\">Twitter for  Android</a>",
      "geo": null,
      "link": "http://twitter.com/rosi_sifah/status/471943355505459200",
      "lang": "en",
      "created_at": 1401355038000,
      "author": {
        "username": "rosi_sifah",
        "name": "Rosifah",
        "id": 537798506,
        "avatar": "http://pbs.twimg.com/profile_images/458917673456238592/Im22zoIV_normal.jpeg",
        "link": "http://twitter.com/rosi_sifah"
      }
    },
 "twitter": {
   // a tweet JSON
 }
}

Run Code Online (Sandbox Code Playgroud)

我们的用户在我们的SQL数据库中保存请求,当他们要求他们的仪表板时,我们想要请求我们的ES集群查询(从数据库中检索)并使用新的ES聚合框架在其上进行一些聚合.

每个仪表板都显示一个明确的,用户选择的日期范围,因此我们始终使用

"range": {
 "generic.created_at": {
   "from": 1401000000000,
   "to": 1401029019706
  }
}

Run Code Online (Sandbox Code Playgroud)

以及ES查询.

我们以这种方式指定_routing:

"_routing":{
 "required":true,
 "path":"generic.id"
},

Run Code Online (Sandbox Code Playgroud)

和_id:

"_id": {
  "index": "not_analyzed",
  "store": "false",
  "path": "generic.id"
}

Run Code Online (Sandbox Code Playgroud)

大约5天,我们在一个索引中存储了6700万个文档(大约40个).我们已经了解了按日分割索引的良好做法.所以现在我们的指数按日分割([index-name] - [YYYY-MM-DD]).

目前每个索引有5个分片和1个副本,我们有一个由3台机器组成的集群,每台机器有8个内核,16个RAM和8个硬盘.我们计划使用另一台机器作为网关(8核,16Go RAM,1To HDD).

除了群集配置之外,我们默认保留ES配置.

问题

对于我们要索引的每个文档,我们明确说明要使用的索引.目前我们使用当天的日期.我们应该使用文件的日期以防止热点吗？因为目前它意味着来自不同日期的文档(在created_at中指定)可以存在于当天的相同索引中.
白天是否有21个60万个文件足够(或太多)5个分片？
如果我们希望在不到1秒的时间内处理所有聚合查询,我们应该设置多少个副本？
我们应该改变路线吗？由于我们事先不知道在对集群进行的每个请求的聚合之前将处理哪些文档(因为查询是用户定义的)
我们应该在这个集群中放置什么样的硬件(多少台机器,什么配置)来支持6个月的文件？

[更新]

以下是一些查询示例:

一个词云

GET idx-2014-05-01/stream/_search?search_type=count
{
 "query":{
   "bool": {
     "must": [{
       "query_string" : {
         "query" : "(generic.lang:fr OR generic.lang:en) AND (generic.content:javascript)"
        }},{
        "range": {
          "generic.created_at": {
            "from": 1401000000000,
            "to": 1401029019706
          }
        }}
     ]
   }
 },
  "aggs":{
    "words":{
      "terms":{
        "field": "generic.content",
        "size": 40
      }
    }
  }
}

Run Code Online (Sandbox Code Playgroud)

直方图

GET idx-2014-05-01/stream/_search?search_type=count
{
 "query":{
   "bool": {
     "must": [{
       "query_string" : {
         "query" : "generic.content:apple"
        }},{
        "range": {
          "generic.created_at": {
            "from": 1401000000000,
            "to": 1401029019706
          }
        }}
     ]
   }
 },
  "aggs":{
    "volume":{
      "date_histogram":{
        "field": "generic.created_at",
        "interval":"minute"
      }
    }
  }
}

Run Code Online (Sandbox Code Playgroud)

必须用语言

GET idx-2014-05-01/stream/_search?search_type=count
{
 "query":{
   "bool": {
     "must": [{
       "query_string" : {
         "query" : "(generic.lang:fr OR generic.lang:en) AND (generic.content:javascript)"
        }},{
        "range": {
          "generic.created_at": {
            "from": 1401000000000,
            "to": 1401029019706
          }
        }}
     ]
   }
 },
  "aggs":{
    "top_source":{
      "terms":{
        "field": "generic.lang"
      }
    }
  }
}

Run Code Online (Sandbox Code Playgroud)

Answer 1

Joh*_*one 16

让我先写下我的所有答案/评论,并尽可能地尝试自己测试这些场景.虽然Elasticsearch具有很高的可扩展性,但有许多权衡因文档大小和类型,摄取和查询量,硬件和操作系统而受到很大影响.虽然有许多错误的答案,但很少有正确的答案.

我将这个响应基于几个活动集群,其中包含(目前)大约50万个活动文档,以及我们以大约4倍的数量执行的一些最近的基准测试(在基准测试期间每天摄取大约8,000个文档).

1)首先,当你甚至有一个包含5个分片和每个分片1个副本的索引时,你不会创建3个节点的大部分热点.Elasticsearch会将每个副本从它的主副本分离到不同的节点,并且通常会尝试平衡分片的负载.默认情况下,Elasticsearch将对ID进行哈希处理以选择要索引的分片(然后将其复制到副本).即使使用路由,如果您有每天创建大量文档的单个ID(这是索引的范围),您也只会遇到热点问题.即使这样,它也不会成为一个问题,除非这些ID产生相当大的总体积百分比,并且它们中只有极少数你只能在1或2个分片上聚集.

只有您可以根据您的使用模式确定 - 我建议您对现有数据集进行一些分析,以寻找过高的浓度,并分析您可能的查询.

我遇到的一个更大的问题是查询的性质.您没有显示完整查询,也没有显示完整模式(我看到"generic.id"引用但未在文档架构中引用,并且您的查询显示在一个时间范围内拉出每个文档 - 这是正确的吗？).当您的查询受到用于路由的字段的完全匹配的约束时,自定义路由索引非常有用.因此,如果我的索引包含每个人的文档,而我的查询模式只是在单个查询中检索单个用户的文档,那么按用户ID自定义路由对于提高查询性能和减少整体群集负载非常有用.

要考虑的第二件事是摄取与查询的总体平衡.您每天要摄取超过20M的文档 - 您每天执行的查询数量是多少？如果该数字是<<<摄取率,您可能需要考虑通过自定义路线的需要.此外,如果查询性能良好或很好,您可能不希望添加额外的复杂性.

最后通过摄取日期与created_at进行索引.我们也在努力解决这个问题,因为我们在收到新文件方面有些滞后.现在我们已经通过摄取日期进行存储,因为它更易于管理,并且一次查询多个索引并不是一个大问题,特别是如果您自动创建1周,2周,1个月,2个月的别名等.一个更大的问题是分发是什么 - 如果您有几周或几个月后出现的文档,或许您想要通过created_at更改为索引,但这需要将这些索引保持在线并打开相当长的一段时间.

我们目前每天使用几个文档索引,基本上是" - "格式.实际上,这目前意味着每天5个索引.这使我们能够更有选择性地将数据移入和移出集群.我们所学到的东西对我们来说并不适合你.

2)这是关于ES的好想法 - 每天创建一个新的索引,你可以随着时间的推移调整,以增加每个索引的分片数量.虽然您无法为现有索引更改它,但您每天都在创建一个新索引,并且您可以根据实际生产分析做出决策.您当然希望观察数字,并准备增加分片数量,如果您每天摄入量增加.这不是最简单的权衡 - 每个分片都是Lucene实例,可能有多个文件.每个索引的更多分片不是免费的,因为它与时间相乘.鉴于您的6个月的使用情况,超过1800个分片在3个节点上开放(182天x 5个初选和5个复制品每天).每个碎片可能有多个文件打开.我们发现某些级别的开销和对节点上资源使用的影响,因为集群中的总分片数增加到这些范围内.您的里程可能会有所不同,但是当您计划一次保留182个索引(6个月)时,我会小心增加每个索引的分片数量 - 这是一个相当大的乘数.如果您对默认的分片计数进行任何更改,我肯定会提前对此进行基准测试.

3)没有任何其他人可以提前为您预测查询性能.它基于整体集群负载,查询复杂性,查询频率,硬件等.它非常适合您的环境.你将不得不对此进行基准测试.我个人认为你已经加载了数据我会使用ES快照并进行恢复,以便在测试环境中提供这些数据.尝试使用默认的1副本,看看它是如何进行的.添加副本分片非常适合数据冗余,并且可以帮助在整个群集中分散查询,但价格相当陡峭 - 存储量增加50%以及每个额外的副本分片将为其运行的节点带来额外的摄取成本.如果您需要冗余并且可以节省容量,那就太好了,如果您没有足够的查询量来真正利用它,那就太好了.

4)你的问题是不完整的(它以"我们从不"结束),所以我不能直接回答它 - 但更大的问题是为什么你开始定制路由？当然,它可以带来很好的性能优势,但只有在您可以按照用于路由的字段分割一组文档时,它才有用.如果是这种情况,那么从您的示例数据和部分查询中并不完全清楚.我个人测试它没有任何自定义路由,然后尝试相同,看看它是否有重大影响.

5)另一个问题需要你做一些工作.您需要跟踪(至少)JVM堆使用情况,总体内存和CPU使用率,磁盘使用情况以及磁盘运行时间.我们这样做,阈值设置为在发现问题之前提醒,以便我们可以尽早向集群添加新成员.请记住,当您向群集添加节点时,ES将尝试重新平衡群集.如果丢失节点出现问题(堆耗尽,JVM错误,硬件故障,网络故障等),那么仅使用3个具有大型初始文档集的节点运行生产可能会导致问题.ES将会变黄并在重新洗牌时留在那里很长一段时间.

就个人而言,对于大型文档编号和高摄取,我会先开始添加节点.如果您将一个节点用于维护,那么如果有更多节点,则不会出现问题.关于您现有的配置,您是如何获得每节点8 TB的硬盘的？考虑到每天摄取8GB的数据,这似乎有点过了6个月的数据.我强烈怀疑,考虑到数据量和索引/分片数量,您需要移动到更多节点,这甚至会进一步降低每个节点的存储需求.

我肯定希望通过在只有1或2个节点的集群上循环通过高容量摄取和正常查询频率循环来对每个节点的最大文档量进行基准测试,并查看它失败的位置(性能,堆耗尽或其他问题) ).然后,我计划将每个节点的文档数量远远低于该数量.

所有这一切都说我会走出困境说我怀疑你会对3个16GB节点上的40多亿个文件感到高兴.即使它工作(再次,测试,测试,测试)失去一个节点将是一个非常重要的事件.我个人喜欢较小的节点,但更喜欢它们.

其他想法 - 我们最初基于3个Amazon EC2 m1.xlarge实例(4个内核,15 GB内存)进行基准测试,这些实例在每天80M文档的摄取数天内工作正常,平均文档大小比您看起来要大.最大的问题是索引和分片的数量是开放的(我们每天创建几百个新索引,每天可能还有几千个分片,这就产生了问题).我们之后添加了几个具有30GB内存和8个内核的新节点,然后添加了另外80M文档来测试它.我们目前的生产方法是保持更喜欢更适中的节点而不是几个大节点.

更新:

关于基准测试硬件,如上所述基于3个运行ubuntu 12.04 LTS和ES 1.1.0的Amazon EC2 m1.xlarge虚拟实例进行基准测试.我们每天运行大约80M文档(从我们之前使用的MongoDB数据库中提取数据).每个实例通过Amazon EBS拥有1 TB的存储空间,提供的IOPS相当于1000 IOPS.我们跑了大约4-5天.我们似乎每天只有80M的cpu受限,并且相信更多的节点会增加我们的摄取率.随着基准运行并且索引和分片的数量增加,我们看到内存压力增加.我们创建了大量索引和分片(每1M文档大约有4到5个索引或每天大约400个索引,每个索引有5个主分片和1个副本分片).

关于索引别名,我们通过cron条目滚动索引别名创建1周后,2周后等等,这样我们的应用程序就可以命中一个已知的索引别名,并且总是在今天的设定时间范围内运行.我们使用索引别名rest api来创建和删除它们:

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-aliases.html

归档时间：	11 年，5 月前
查看次数：	6275 次
最近记录：	9 年，7 月前