The shard-level request cache module caches the local results on each shard. This allows frequently used (and potentially heavy) search requests to return results almost instantly.
Т.е. это обычный query cache, просто не глобальный, а пошардовый. Но ситуацию это особо не меняет. "almost instantly" там потому, что никаких вычислений и не делается, просто тупо достают из памяти готовенький результат. Мерить производительность такой операции в наши планы не входило, т.к. из полезной нагрузки остаётся только мерджинг результатов, но там сложность тоже невысокая и его вклад в общее время отклика среднего запроса обычно пренебрежительно мал.
Я понимаю, что это можно сделать. Интересно сделано ли, есть ли вообще такая практика в сфере бенчмарков. Я просто читал много статей от разных вендоров бд и независимых специалистов по бд с разными бенчмарками. Есть TPC. Есть Кликхаусовские бенчмарки. И я вижу, что обычно тестируют или latency (и часто неправильно в плане точности измерений) или throughput. Поэтому и интересуюсь, т.к. возможно что-то упускаю и есть какой показательный бенчмарк, демонстрирующий то, что вы имеете в виду.
И Эластик и Мантикора используют mmap и page cache операционки, именно там обычно и происходит прогревание. В сделанных тестах это никаким образом не блокируется, а даже наоборот - в главную метрику "Fast avg" не попадает 20% наиболее холодных запросов на ещё возможно непрогретом кэше, который обеспечивает операционная система посредством mmap.
Если вы имеете в виду какие-то другие конкретные кэши, то скажите.
В реальном проде не важно, с какой latency сервис обслуживает эти холодные запросы
Не соглашусь. Это важно, когда прод - это аналитика данных, в том числе log management: открываете вы dashboard в Кибане раз в сутки посмотреть как дела, а он делает десятки холодных запросов, это с Эластиком может занимать до минуты и больше, потом сутки вы ничего не делаете. Или data analyst, делающий разнообразные запросы, чтобы поймать какие-то закономерности и найти интересные факты: каждый из запросов он сделает один раз. И чем быстрее он закончится, тем больше разных запросов он может сделать или хотя бы меньше шанс, что он пойдёт попить кофе в ожидании окончания совсем уж тяжелого запроса.
Вы, наверное, правы, что нет смысла тестировать 100% попадание в query cache. Или кстати почему?
Потому что сложность алгоритма получается O(1).
тестировать его при горячих кешах и постоянно идущих вставках
их логично тестировать при горячих кешах и разных значениях предиката
Да конечно можно и такое тестировать, просто будет уже другой тест. В имеющихся была идея максимально точно протестировать latency конкретного запроса. Про тестирование throughput есть в roadmap'е https://github.com/db-benchmarks/db-benchmarks#features-wishlist . Тестирование чтения при одновременной записи тоже интересно, но опасаюсь плохой повторяемости результатов теста (сейчас погрешность 2-3% вплоть до 1-2 мс).
Если вы про методику тестирования на http://db-benchmarks.com/ , то в каждой статье (например https://db-benchmarks.com/test-taxi/#about-caches) там подробно описано почему было решено сделать именно так. Вкратце: не хочется тестировать скорость извлечения пары килобайт из памяти по ключу, а хочется тестировать алгоритмы и структуры данных. Кэш ОС наоборот используется! Зло - это именно query cache. Он есть в Мантикоре, есть в Эластике, поэтому в обоих отключается, иначе просто везде даже для очень тяжёлых запросов будет очень низкое latency - бессмысленные результаты.
Наверное имеется в виду пропускная способность (т.е. кол-во запросов в секунду), а не просто кол-во одновременных запросов. Тут всё очень сильно зависит от данных в индексе и запросов. К сожалению, мы ещё не делали детальных сравнительных тестов пропускной способности Manticore аналогичных тестам latency, описанным в статье. Но в общем и целом можно предположить, что с производительность в плане throughput всё хорошо, т.к. пользователи не жалуются.
Если при REPLACE меняется одно поле и это поле атрибут (не full-text), то может попробовать UPDATE? Хотя в Sphinx (и Manticore до 4-й версии) с ним могут быть проблемы в RT индексах при апдейте и одновременном мердже (апдейты могут потеряться или крэш случиться), но если аккуратно, то может помочь.
есть ли дисковые чанки? Обновления касаются документов из них?
делается ли OPTIMIZE?
Могу предположить, что в вашем случае сценарий такой: много replace'ов -> делается дисковый чанк при наступлении rt_mem_limit -> много реплэйсов -> делается новый дисковый чанк с теми же документами и килл-листом, который подавляет документы из первого дискового чанка -> и т.д. А OPTIMIZE не запускается. Важно понять суть реплэйсов и килл-листов.
Хорошо, что в Manticore Search 4 есть автоматический OPTIMIZE и включен по дефолту. Во многих случаях этого достаточно и о подобных проблемах можно забыть.
Данный режим до сих пор остался в мантикоре по соображениям обратной совместимости. С версии 2.3.1-beta сфинкса был добавлен режим конкурентности thread pool
Пока что есть довольно существенная проблема в мантикоре, это то, что real-time индекс фрагментируется, по мере роста кол-ва постоянных обновлений
Есть такая операция в мантикоре OPTIMIZE, она решает проблему фрагментированного rt-индекса, и позволяет "схлопнуть" все блоки в один, тем самым удерживая общую производительность в пределах нормы.
Есть такое. Автоматический OPTIMIZE доделываем.
рекомендуется выставлять max_children в 1.5*кол-во ядер на машине
max_children тоже нет почти год
Существенная проблема мантикоры - это исчерпание пула потоков, если джобы "уперлись" в диск например
Попробуйте версию с корутинами, может в вашем случае станет получше, хотя если что-то упирается в диск, то тут в принципе вариантов немного.
Вот гайд https://manual.manticoresearch.com/Quick_start_guide . Справа можно переключать язык программирования.
Да, и Мантикора тоже анализирует.
Ну они же пишут в своей доке:
Т.е. это обычный query cache, просто не глобальный, а пошардовый. Но ситуацию это особо не меняет. "almost instantly" там потому, что никаких вычислений и не делается, просто тупо достают из памяти готовенький результат. Мерить производительность такой операции в наши планы не входило, т.к. из полезной нагрузки остаётся только мерджинг результатов, но там сложность тоже невысокая и его вклад в общее время отклика среднего запроса обычно пренебрежительно мал.
Кликхаус кстати недавно заоупенсурсили свои бенчмарки и вот что они пишут про кэши https://github.com/ClickHouse/ClickBench/#caching
Я понимаю, что это можно сделать. Интересно сделано ли, есть ли вообще такая практика в сфере бенчмарков. Я просто читал много статей от разных вендоров бд и независимых специалистов по бд с разными бенчмарками. Есть TPC. Есть Кликхаусовские бенчмарки. И я вижу, что обычно тестируют или latency (и часто неправильно в плане точности измерений) или throughput. Поэтому и интересуюсь, т.к. возможно что-то упускаю и есть какой показательный бенчмарк, демонстрирующий то, что вы имеете в виду.
А можно пример тестов, где так делается? Интересно было бы понять больше про методику таких тестов.
И Эластик и Мантикора используют mmap и page cache операционки, именно там обычно и происходит прогревание. В сделанных тестах это никаким образом не блокируется, а даже наоборот - в главную метрику "Fast avg" не попадает 20% наиболее холодных запросов на ещё возможно непрогретом кэше, который обеспечивает операционная система посредством mmap.
Если вы имеете в виду какие-то другие конкретные кэши, то скажите.
Ну если цель - померить исключительно производительность query cache'а каждой базы данных, то да :)
Не соглашусь. Это важно, когда прод - это аналитика данных, в том числе log management: открываете вы dashboard в Кибане раз в сутки посмотреть как дела, а он делает десятки холодных запросов, это с Эластиком может занимать до минуты и больше, потом сутки вы ничего не делаете. Или data analyst, делающий разнообразные запросы, чтобы поймать какие-то закономерности и найти интересные факты: каждый из запросов он сделает один раз. И чем быстрее он закончится, тем больше разных запросов он может сделать или хотя бы меньше шанс, что он пойдёт попить кофе в ожидании окончания совсем уж тяжелого запроса.
Потому что сложность алгоритма получается O(1).
Да конечно можно и такое тестировать, просто будет уже другой тест. В имеющихся была идея максимально точно протестировать latency конкретного запроса. Про тестирование throughput есть в roadmap'е https://github.com/db-benchmarks/db-benchmarks#features-wishlist . Тестирование чтения при одновременной записи тоже интересно, но опасаюсь плохой повторяемости результатов теста (сейчас погрешность 2-3% вплоть до 1-2 мс).
Если вы про методику тестирования на http://db-benchmarks.com/ , то в каждой статье (например https://db-benchmarks.com/test-taxi/#about-caches) там подробно описано почему было решено сделать именно так. Вкратце: не хочется тестировать скорость извлечения пары килобайт из памяти по ключу, а хочется тестировать алгоритмы и структуры данных. Кэш ОС наоборот используется! Зло - это именно query cache. Он есть в Мантикоре, есть в Эластике, поэтому в обоих отключается, иначе просто везде даже для очень тяжёлых запросов будет очень низкое latency - бессмысленные результаты.
Наверное имеется в виду пропускная способность (т.е. кол-во запросов в секунду), а не просто кол-во одновременных запросов. Тут всё очень сильно зависит от данных в индексе и запросов. К сожалению, мы ещё не делали детальных сравнительных тестов пропускной способности Manticore аналогичных тестам latency, описанным в статье. Но в общем и целом можно предположить, что с производительность в плане throughput всё хорошо, т.к. пользователи не жалуются.
Среди известных багов такого нет. Нужно смотреть логи searchd в первую очередь. Если они остались - заведите issue, пожалуйста https://github.com/manticoresoftware/manticoresearch/issues/new/choose
Сделайте feature request с описанием ситуации, когда без этого никак - https://github.com/manticoresoftware/manticoresearch/issues
Это в принципе не должно быть сложно прикрутить.
В Эластике тоже нет JOIN. Возможно variables могут помочь https://manual.manticoresearch.com/Server_settings/Setting_variables_online#SET
Конечно есть: и просто GROUP BY и FACET.
Если при REPLACE меняется одно поле и это поле атрибут (не full-text), то может попробовать UPDATE? Хотя в Sphinx (и Manticore до 4-й версии) с ним могут быть проблемы в RT индексах при апдейте и одновременном мердже (апдейты могут потеряться или крэш случиться), но если аккуратно, то может помочь.
Апдейт от 28-го сентября 2021:
автоматический оптимайз доделали
поддержку columnar для RT зарелизили
Больше информации про новый релиз тут https://manual.manticoresearch.com/Changelog#Version-4.0.2,-Sep-21-2021
Зависит от многих факторов:
обновления - UPDATE или REPLACE?
есть ли дисковые чанки? Обновления касаются документов из них?
делается ли OPTIMIZE?
Могу предположить, что в вашем случае сценарий такой: много replace'ов -> делается дисковый чанк при наступлении rt_mem_limit -> много реплэйсов -> делается новый дисковый чанк с теми же документами и килл-листом, который подавляет документы из первого дискового чанка -> и т.д. А OPTIMIZE не запускается. Важно понять суть реплэйсов и килл-листов.
Хорошо, что в Manticore Search 4 есть автоматический OPTIMIZE и включен по дефолту. Во многих случаях этого достаточно и о подобных проблемах можно забыть.
Спасибо за статью!
Несколько поправок и комментариев:
Есть - https://manual.manticoresearch.com/Adding_documents_to_an_index/Adding_documents_to_a_real-time_index#Auto-ID
Поддерживает - https://play.manticoresearch.com/docstore/
64-битные MVA тоже есть https://mnt.cr/multi64
Уже почти год как перешли на корутины https://manual.manticoresearch.com/Changelog#Version-3.5.0,-22-Jul-2020
workers уже нет
Есть такое. Автоматический OPTIMIZE доделываем.
max_children тоже нет почти год
Попробуйте версию с корутинами, может в вашем случае станет получше, хотя если что-то упирается в диск, то тут в принципе вариантов немного.
Кстати доделываем columnar storage https://github.com/manticoresoftware/columnar . Уже есть поддержка RT. Будем рады, если потестите.
Если интересно, статья про активно разрабатываемый форк Sphinx'а тут https://habr.com/ru/post/541126