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