我们正在将我们的集群从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
}
}
我们的用户在我们的SQL数据库中保存请求,当他们要求他们的仪表板时,我们想要请求我们的ES集群查询(从数据库中检索)并使用新的ES聚合框架在其上进行一些聚合.
每个仪表板都显示一个明确的,用户选择的日期范围,因此我们始终使用
"range": {
"generic.created_at": {
"from": 1401000000000,
"to": 1401029019706 …我们使用弹性搜索几乎作为缓存,存储在时间窗口中找到的文档.我们不断插入大量不同大小的文档,然后我们使用结合日期过滤器的文本查询在ES中搜索,这样当前线程就不会获得它已经看到的文档.像这样的东西:
"((word1 AND word 2)OR(word3 AND word4))AND insertedDate> 1389000"
我们使用TTL功能在弹性搜索中维护数据30分钟.今天,我们每台机器每分钟至少有3台机器在批量请求中插入新文件,并使用上述问题进行搜索.
我们在索引和检索这些文档时遇到了很多麻烦,我们没有获得ES索引和返回的大量吞吐量文档.我们甚至无法获得每秒索引的200个文档.
我们认为问题在于同时查询,插入和TTL删除.我们不需要保持旧数据的弹性,我们只需要在给定时间以弹性索引的文档的小时间窗口.我们应该怎样做才能改善我们的表现？
提前致谢
机器的种类:
附加信息:
用于构建索引的代码如下所示:https: //gist.github.com/dggc/6523411
我们的elasticsearch.json配置文件:https: //gist.github.com/dggc/6523421
编辑
对于给你们一些反馈的长时间延迟感到抱歉.我们公司的事情很繁忙,我选择等待更平静的时间来更详细地说明我们如何解决我们的问题.我们仍然需要做一些基准来衡量实际的改进,但重点是我们解决了这个问题:)
首先,我认为索引性能问题是由于部分使用错误引起的.正如我之前所说,我们使用Elasticsearch作为一种缓存,在30分钟的时间窗口内查找文档.我们在elasticsearch中查找文档,其内容与某些查询匹配,并且其插入日期在某个范围内.然后,弹性将返回完整的文档json(除了索引内容之外,它还有大量数据).我们的配置错误地对文档json字段进行了弹性索引(除了content和insertDate字段之外),我们认为这是索引性能问题的主要原因.
但是,我们也做了一些修改,正如这里的答案所示,我们认为这些修改也改善了性能:
我们现在不使用TTL功能,而是在共同别名下使用两个"滚动索引".当索引变旧时,我们创建一个新索引,为其分配别名,并删除旧索引.
我们的应用程序每秒执行大量查询.我们认为这会产生弹性,并降低索引性能(因为我们只使用一个节点进行弹性搜索).我们为节点使用了10个分片,这导致我们触发的每个查询都被弹性转换为10个查询,每个分片对应一个查询.由于我们可以随时丢弃弹性数据(因此更改碎片数量对我们来说不是问题),我们只是将碎片数量更改为1,大大减少了弹性节点中的查询数量.
我们的索引中有9个映射,每个查询都会被触发到特定的映射.在这9个映射中,大约90%的文档插入到其中两个映射中.我们为每个映射创建了一个单独的滚动索引,并将另外7个保留在同一索引中.
这不是真正的修改,但我们从Sematext安装了SPM(可扩展性能监控),这使我们能够密切监控弹性搜索并学习重要指标,例如发出的查询数量 - > sematext.com/spm/index.html
我们的使用数量相对较小.我们有大约100个文件/秒到达,必须编入索引,峰值为400个文件/秒.至于搜索,我们每分钟大约有1500次搜索(在更改分片数量之前为15000次).在进行这些修改之前,我们正在解决这些性能问题,但现在不再存在.