既然到处都找不到，是否可以并行更新Sphinx的RT索引？

例如，我注意到当文档超过1.000.000字时，处理速度会降低。因此，我希望在单独的线程中处理超过1.000.000字的文档时拆分我的处理器，而不会阻碍处理较小的文档。

然而，我还没有找到任何并行更新RT-index的基准。我也没有找到任何有关它的文档？

是否有其他人正在使用此方法，或者这是否被视为不良做法？

推荐答案

首先让我提醒您，当您在一个Sphinx(实际上也是Manticore Search/Lucene/solr/el龄)实时索引中更新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

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