Question

由于我在任何地方都找不到它，是否可以并行更新Sphinx的RT索引？

例如，我发现文档多于1.000.000字时，处理速度会降低。因此，我想将我的处理器拆分成一个单独的线程来处理超过1.000.000个字的文档，而不是阻止较小的文档被处理。

但是，我找不到并行更新RT索引的任何基准。我也没有找到任何文档吗？

还有其他人正在使用这种方法吗？还是被认为是不良做法？

Answer 1

首先让我提醒您，当您在Sphinx（实际上也是manticore搜索/ lucene / solr / elastic）实时索引中更新smth时，您实际上并没有更新任何内容，您只需将更改添加到新细分中（如果是Sphinx，则为RAM块）（最终会在大多数情况下）将与其他段合并，并且更改将真正应用。因此，问题在于用新记录填充RT RAM块的速度如何，并发性如何改变吞吐量。我已经根据https://github.com/Ivinco/stress-tester进行了测试，这是我得到的：

snikolaev@dev:~/stress_tester_github$ for conc in 1 2 5 8 11; do ./test.php --plugin=rt_insert.php -b=100 --data=/home/snikolaev/hacker_news_comments.smaller.csv -c=$conc --limit=100000 --csv; done;
concurrency;batch size;total time;throughput;elements count;latencies count;avg latency, ms;median latency, ms;95p latency, ms;99p latency, ms
1;100;28.258;3537;100000;99957;0.275;0.202;0.519;1.221
concurrency;batch size;total time;throughput;elements count;latencies count;avg latency, ms;median latency, ms;95p latency, ms;99p latency, ms
2;100;18.811;5313;100000;99957;0.34;0.227;0.673;2.038
concurrency;batch size;total time;throughput;elements count;latencies count;avg latency, ms;median latency, ms;95p latency, ms;99p latency, ms
5;100;16.751;5967;100000;99957;0.538;0.326;1.163;3.797
concurrency;batch size;total time;throughput;elements count;latencies count;avg latency, ms;median latency, ms;95p latency, ms;99p latency, ms
8;100;20.576;4857;100000;99957;0.739;0.483;1.679;5.527
concurrency;batch size;total time;throughput;elements count;latencies count;avg latency, ms;median latency, ms;95p latency, ms;99p latency, ms
11;100;23.55;4244;100000;99957;0.862;0.54;2.102;5.849

即将并发从1增加到11（在我的情况下是在8核服务器上）可以让您将吞吐量从每秒3500文档增加到每秒4200文档。即20％-不错，但性能提升不大。

在您的情况下，也许可以找到另一种方法-您可以更新一个索引，而不是一个索引，而可以更新多个索引，然后使用分布式索引来将它们组合在一起。在其他情况下，您可以这样做，称为分片。例如，如果您写入两个RT索引而不是一个，则可以得到以下信息：

snikolaev@dev:~/stress_tester_github$ for conc in 1 2 5 8 11; do ./test.php --plugin=rt_insert.php -b=100 --data=/home/snikolaev/hacker_news_comments.smaller.csv -c=$conc --limit=100000 --csv; done;
concurrency;batch size;total time;throughput;elements count;latencies count;avg latency, ms;median latency, ms;95p latency, ms;99p latency, ms
1;100;28.083;3559;100000;99957;0.274;0.206;0.514;1.223
concurrency;batch size;total time;throughput;elements count;latencies count;avg latency, ms;median latency, ms;95p latency, ms;99p latency, ms
2;100;18.03;5543;100000;99957;0.328;0.225;0.653;1.919
concurrency;batch size;total time;throughput;elements count;latencies count;avg latency, ms;median latency, ms;95p latency, ms;99p latency, ms
5;100;15.07;6633;100000;99957;0.475;0.264;1.066;3.821
concurrency;batch size;total time;throughput;elements count;latencies count;avg latency, ms;median latency, ms;95p latency, ms;99p latency, ms
8;100;18.608;5371;100000;99957;0.613;0.328;1.479;4.897
concurrency;batch size;total time;throughput;elements count;latencies count;avg latency, ms;median latency, ms;95p latency, ms;99p latency, ms
11;100;26.071;3833;100000;99957;0.632;0.294;1.652;4.729

即并发速度为每秒6600个文档5。现在，它比初始吞吐量提高了近90％，这似乎是一个很好的结果。使用索引和并发数，您可以找到适合您情况的最佳设置。

Sphinx RT-index并行更新

1 个答案: