Обновление RT-индекса Sphinx параллельно - PullRequest
Новая
       9

Обновление RT-индекса Sphinx параллельно

0 голосов
/ 21 октября 2018

Поскольку я нигде не могу его найти, возможно ли параллельно обновлять RT-индекс Sphinx?

Например, я заметил снижение скорости обработки, когда документы имеют более 1000.000 слов.Поэтому я хотел бы разделить свой процессор при обработке документов с более чем 1.000.000 слов в отдельном потоке, не задерживая при обработке меньшие документы.

Однако я не смог найти ни одногоориентиры параллельного обновления RT-индекса.Также я не нашел никакой документации об этом?

Есть ли другие, кто использует этот подход, или это считается плохой практикой?

1 Ответ

0 голосов
/ 24 октября 2018

Прежде всего, позвольте мне напомнить вам, что когда вы обновляете что-то в Sphinx (на самом деле это мантикорный поиск / lucene / solr / эластичный) в реальном времени, вы фактически ничего не обновляете, вы просто добавляете изменения в новый сегмент(RAM-блок в случае Sphinx), который в конечном итоге (в основном намного позже) будет объединен с другими сегментами, и изменение будет действительно применено.Поэтому вопрос заключается в том, как быстро вы можете заполнить блок 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% лучше, чем начальная пропускная способность, которая кажетсяхороший результат.Играя с количеством индексов и одновременностей, вы можете найти оптимальные настройки для вашего случая.

...