我正在努力将搜索引擎从sql数据库移植到elasticsearch。 这样做的主要原因是能够轻松地计算构面。
目前我们通过生成预分类表在sql上有方面。它运行良好，但维护很痛苦，只有数据的一个子集支持facet。
现在ES原型正在运行，我正在对这两个解决方案进行基准测试，看起来ES版本在性能方面略逊于sql版本（就可维护性而言，它要好得多）。
我使用了完全相同的机器配置，64位平台，32 GB内存，一个ssd磁盘和一个3 GHz的四核Intel Xeon来比较sql和ES。
文档不小，大约有200个字段，具体取决于请求，使用基于脚本的排序，并且总是在doc的8个字段上计算facets。
索引包含3百万个文档，如果我没弄错的话，它与ES可以处理的相对较小。
在查询方面，我使用过滤查询，对于某些请求，我使用custom_filters_score查询来计算得分并将其用于排序。
由于方面的影响，某些过滤器是全局的，但过滤后的查询中总会有一些过滤器，因此应减少扫描的文档数量（并非所有索引都被扫描）。
我在测试中使用了两个度量：服务器执行搜索所花费的时间，以及并行执行100个线程的客户端执行的查询数量。
对于elasticsearch，每个查询在服务器上花费的平均时间约为500毫秒（并行100个查询），客户端上的平均查询时间约为160（构建查询时会丢失一些ms，发送，接收结果和解析它们。 这是一个具有1个分片和0个副本的索引，当我增加分片/副本的数量时，性能会显着下降。
对于sql，执行查询所花费的平均时间大约为360毫秒（同上，并行运行100个查询），客户端上的平均查询大约为200秒。
我知道很难比较，但由于我对预期的结果一无所知，我想知道是否有人可以评论这些措施。
也许我错过了一些东西，它应该快一个数量级，或者这些是类似环境的典型结果，我不知道。
在我的案例中，我能期待什么？ 您在ES的类似情况下观察到了什么？ 它是否支持并发请求？ 在同时进行100次查询时，执行查询的时间是否应该在500毫秒的范围内？ 有没有办法提高搜索性能？
欢迎任何信息或评论，这是决定是否将原型工业化的重要部分。
谢谢。
答案 0 :(得分：0)
这不是一个问题;这听起来更像是一场讨论。
尽管如此，没有多少人可以评论，因为我们所有的用例都不同。您纯粹将其用作分面分析工具。我使用ElasticSearch作为数据库和实时分析工具。所以我对你有用的基准将与你截然不同。
版本明智，我仍然使用1.8.7（因为Logstash），但是在撰写本文时当前版本为0.19.4。甚至谈论标准基准测试还有太多不同的参数，因为弹性搜索并不是人们今天使用的标准工业工具，所以我想你需要重新提出你要求的内容，以便人们真正发表评论。
答案 1 :(得分：0)
很难给你一个确切的答案，但你的数字听起来并不太意外。
这些应该会给你带来一些性能上的提升虽然我并不感到惊讶的是，只有300万个文档的高性能关系数据库表现同样好或更好，不同之处在于DB会变慢，而ES会执行相同的百万分之百。