Sphinx RT索引并行更新

因为我在任何地方都找不到它，有可能同时更新斯芬克斯的RT索引吗

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

然而，我还没有找到任何并行更新RT索引的基准。我都没有找到它的任何文档

---

还有其他人在使用这种方法吗？或者这被认为是一种不好的做法吗？

首先，让我提醒您，当您在Sphinx（实际上也是manticore search/lucene/solr/elastic）实时索引中更新smth时，您实际上并没有更新任何内容，您只需将更改添加到一个新段（Sphinx的情况下是RAM块）最终（大部分时间以后）将与其他细分市场合并，并将真正应用更改。因此，问题是您可以以多快的速度用新记录填充RT RAM块，以及并发性如何改变吞吐量。我做了一个测试，我得到的是：

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

---

i、 e.并发5时每秒6600个文档。现在它几乎比最初的吞吐量高出90%，这似乎是一个很好的结果。通过使用索引和并发，您可以为您的案例找到最佳设置。

感谢您对实际统计数据的出色响应！然而，我对Sphinx还很陌生，对分布式索引也不熟悉。但需要注意的是，多达100万字的文档占用了我的处理器（增加了索引）。所以，基本上我产生了两个线程。一个线程处理1mln字以下的所有文件，一个线程处理超过此限制的所有文件。这似乎很有效。根据字数和队列中文件的数量，我每分钟最多可以访问4000个文件？此外，分布式索引理论上比一个索引慢，对吗？或者这是一种错误的思维方式？在大多数情况下，分布式索引速度更快，尤其是当搜索查询不是很简单并且有大量文档时。其背后的思想是，普通索引最多只能占用一个内核，而分布式索引+dist_threads=N设置允许您在CPU之间并行搜索过程。当然也有例外：例如，如果你的索引很小，那么从几个子索引合并结果的时间可能比只使用单个索引要长。或者，如果您有密集的搜索请求加载，并且CPU已经加载，那么在子索引中分配这些请求可能没有任何意义。“多达100万字的文档占用了我的处理器”-此时检查您的资源利用率，如果您的磁盘/CPU没有得到充分利用，您可以通过拆分为更多索引来获得更好的性能。然后，您可以使用分布式索引将它们合并回来，以使整个数据可搜索。