ElasticSearch期望的表现

Question

我正在将一个搜索引擎从一个sql数据库移植到elasticsearch。这样做的主要原因是能够轻松计算方面。

目前我们通过生成precalc表在sql方面。它运行良好，但维护很困难，只有一部分数据支持方面。

现在ES原型正在工作，我正在对这两个解决方案进行基准测试，看起来ES版本在性能方面略逊于sql版本（在可维护性方面它更好）。

我使用完全相同的机器构造中，一个64位的平台，压头的32场演出中，SSD磁盘，和四核Intel Xeon在3GHz比较SQL和ES。

该文件是不小，有大约200个字段，取决于所述请求，基于脚本的排序被使用，并且刻面总是计算在文档的8个字段。

该索引包含3百万个文档，如果我没有弄错它对于ES可以处理的相对较小。

在查询方面，我使用的是过滤查询，并且对于一些要求，一个custom_filters_score查询来计算分数，并用它进行排序。

一些过滤器是全球性的，因为小面的，但总有一些过滤器在过滤查询，所以扫描文档的数量应减少（不是所有的索引扫描）。

我用在我的测试两项措施：所花费的时间在服务器上执行搜索，并通过并行运行100个线程的客户端执行的第二个查询的数量。

对于elasticsearch，花费在服务器上的平均时间为每个查询约500毫秒（用于并行100个查询），以及平均查询由第二客户端上的是约160（一些毫秒丢失在构建查询，发送它，接收结果和解析它们）。 这是一个有1个分片和0个副本的索引，当我增加分片/副本的数量时，性能显着下降。

对于SQL，平均花费的时间来执行一个查询约为360毫秒（同上，与并行运行的100个查询），并通过第二个客户端上的平均查询约为200

我知道这是很难进行比较，但由于我对可预期的结果没有任何了解，我不知道有人能评论这些措施。

也许我错过了一些东西，它应该是一个数量级的速度更快，或者也许这些都是类似environnements矿典型的结果，我不知道。

对我而言，我可以期待什么？ 你在类似的情况下使用ES观察到了什么？ 它是否支持并发请求？ 同时进行100个查询时，执行查询的时间应该在500毫秒的范围内吗？ 有一些方法可以提高搜索性能吗？

欢迎提供任何信息或意见，这是决定工业化原型的重要组成部分。

谢谢。

Answer 1

这不是问题;这听起来更像是一场讨论。

也就是说，没有多少人可以评论，因为我们所有的用例都不一样。您纯粹将其用作分析工具。我使用ElasticSearch作为数据库和实时分析工具。所以我对我有用的基准将与你有很大不同。

版本明智，我仍然使用1.8.7（因为Logstash），但目前的版本是在这个时候写在0.19.4。即使谈到标准基准测试也有太多不同的参数，因为Elastic Search并不完全是人们今天使用的标准工业工具，所以我想你需要重新考虑你所要求的内容，以便人们进行实际评论。

Answer 2

很难给你一个确切的答案，但你的数字听起来不太出人意料。

• 确保已与段数优化了指数= 1
• 调高线程池的大小弹性搜索。
• 确保Xms和Xmx相同，全部使用模拟锁。

这应该给你一些性能提升虽然我并不感到惊讶，只有3万个文档一个高性能的关系数据库的效果是否好或更好，所不同的是，DB会变慢，而ES将执行与数百万的数字一样。