приложение создает индекс раз в час i_timestamp переключается на него.
предьідущий удаляется. ( точнее не может удалиться — остается пустой фолдер и лок файл
Именно для таких случаев мы и сделали RT mode, когда можно создавать/удалять индексы на лету через CREATE TABLE / DROP TABLE, а не через SIGHUP, RELOAD INDEXES и прочие TRUNCATE RTINDEX WITH RECONFIGURE.
Отличия в синтаксисе если и есть, то минимальные, но drop-in replacement'ом мантикора стать не может, потому что отличается формат индекса. Мы б может написали конвертилку (как мы сделали для миграции sphinx 2 / manticore 2 -> manticore 3), но и это невозможно, потому что sphinx 3 не open source. Реверсинжинирить его никакого желания и возможности нет.
Если речь о mysql, то скорее всего нужно было бы вешать триггеры на таблицы, чтоб любой инсерт и (особенно) апдейт писал событие в соседнюю табличку, и оттуда уже выгребать. Или прикинуться слэйвом и читать с мастера, но тогда репликация должна быть не-statement. Или из binary log'а напрямую Иначе крайне сложно и может быть тормозно. Представьте, что в табличке mysql нет никаких ключей, как отслеживать изменения?
А по поводу "периодически выгребал из нужной таблички свежие данные в индекс" — так это уже по сути легко реализуется через main+delta схему. Ну да, оно конфигуряется не через какой-нибудь ADD SYNC FROM MYSQL host:port:db:table TO index_name в SQL, но так или иначе это доступно из коробки и в сфинксе, и в мантикоре.
Была идея сделать визард+демон, который бы упрощал процесс конфигурирования этого процесса и автоматизировал бы все внутренние процессы синка (чтоб в итоге всё синкалось в real-time индекс в мантикоре), но на счёт того, чтобы засовывать всё это внутрь Manticore Search не уверен. Наверное, оно всё равно было бы прикручено немного сбоку, так как на C++ это писать желания мало, да и особо смысла не вижу. На php/питоне/го легче и быстрее.
Если кластерные фичи не нужны и в принципе данных не очень много (т.е. атрибуты влезают в память), то можно пробовать Manticore уже. Если нужны и данных очень много, то лучше подождать, пока мы доделаем автоматическое шардирование, автоматический compaction и новый движок. Над всем этим работы ведутся. Бенчмарки мы тоже делаем, график в статье показывал, но не на всех датасетах и запросах пока что получается так хорошо. В общем, работаем над этим.
Супер-лёгкой интеграции real-time индексов с внешними источниками нет. Думали над этим, есть идеи, но руки не дошли. Пока можно только через ATTACH импортировать данные из plain индекса в real-time. Ну и когда доделаем интеграцию с logstash, то можно будет средствами logstash делать синк из mysql в manticore.
Версионность добавить несложно. С локализацией намного сложнее — нужны переводы. Если б были переводы, то и это прикрутить легко. Движок, на котором работает документация (рендерится .md с гитхаба) самописный, поэтому подобные вещи легко реализуются.
В системы полнотекстового поиска имеет смысл складывать тогда, когда скорость grep перестаёт удовлетворять. Не хочется же ждать 10 минут, пока он на 100 серверах перелопатит в общей сложности 10 терабайт логов, попутно прилично нагружая диски, что может влиять на другие процессы на этих серверах? Интерактивность в аналитике имеет значение. Больше запросов за минуту сделаете — быстрее разрулите даунтайм.
В системы аналитики (clickhouse, например) может иметь смысл складывать, потому что grep'ом и awk, sort'ом и uniq можно конечно какую-то аналитику сделать, но это часто нетривиально, болезненно, да и в данном случае не только диск, но ещё и проц и память загрузит.
В системы полнотекстового поиска + аналитики (Elasticsearch, Manticore в будущем) — чтоб не париться ни о первом, ни о втором.
А если речь об одном сервере и десятках/сотнях мегабайт логов, да ещё и аналитика не нужна
и нет проблемы подождать несколько секунд и визуализация тоже не нужна, то конечно достаточно простого grep'а, ну или чего-то чуть более мощного. Grafana Loki в таких случаях может быть неплох.
А можете завести баг про это с описанием того, как это повторить?
Именно для таких случаев мы и сделали RT mode, когда можно создавать/удалять индексы на лету через CREATE TABLE / DROP TABLE, а не через SIGHUP, RELOAD INDEXES и прочие TRUNCATE RTINDEX WITH RECONFIGURE.
Отличия в синтаксисе если и есть, то минимальные, но drop-in replacement'ом мантикора стать не может, потому что отличается формат индекса. Мы б может написали конвертилку (как мы сделали для миграции sphinx 2 / manticore 2 -> manticore 3), но и это невозможно, потому что sphinx 3 не open source. Реверсинжинирить его никакого желания и возможности нет.
Да-да, автоматизацию этого я и имел в виду под "Была идея сделать визард+демон".
Если речь о mysql, то скорее всего нужно было бы вешать триггеры на таблицы, чтоб любой инсерт и (особенно) апдейт писал событие в соседнюю табличку, и оттуда уже выгребать. Или прикинуться слэйвом и читать с мастера, но тогда репликация должна быть не-statement. Или из binary log'а напрямую Иначе крайне сложно и может быть тормозно. Представьте, что в табличке mysql нет никаких ключей, как отслеживать изменения?
А по поводу "периодически выгребал из нужной таблички свежие данные в индекс" — так это уже по сути легко реализуется через main+delta схему. Ну да, оно конфигуряется не через какой-нибудь
ADD SYNC FROM MYSQL host:port:db:table TO index_nameв SQL, но так или иначе это доступно из коробки и в сфинксе, и в мантикоре.Была идея сделать визард+демон, который бы упрощал процесс конфигурирования этого процесса и автоматизировал бы все внутренние процессы синка (чтоб в итоге всё синкалось в real-time индекс в мантикоре), но на счёт того, чтобы засовывать всё это внутрь Manticore Search не уверен. Наверное, оно всё равно было бы прикручено немного сбоку, так как на C++ это писать желания мало, да и особо смысла не вижу. На php/питоне/го легче и быстрее.
Если кластерные фичи не нужны и в принципе данных не очень много (т.е. атрибуты влезают в память), то можно пробовать Manticore уже. Если нужны и данных очень много, то лучше подождать, пока мы доделаем автоматическое шардирование, автоматический compaction и новый движок. Над всем этим работы ведутся. Бенчмарки мы тоже делаем, график в статье показывал, но не на всех датасетах и запросах пока что получается так хорошо. В общем, работаем над этим.
Что вы имеете в виду под ротацией реалтайм индексов? Ротация же — для plain индексов.
Супер-лёгкой интеграции real-time индексов с внешними источниками нет. Думали над этим, есть идеи, но руки не дошли. Пока можно только через ATTACH импортировать данные из plain индекса в real-time. Ну и когда доделаем интеграцию с logstash, то можно будет средствами logstash делать синк из mysql в manticore.
Есть интерактивный курс — https://play.manticoresearch.com/mysql/
В доке больше деталей — https://manual.manticoresearch.com/Adding_data_from_external_storages/Fetching_from_databases/Introduction
Вдохновлялись катакодой, но реализовали всё сами на k8s, gotty и т.д.
Версионность добавить несложно. С локализацией намного сложнее — нужны переводы. Если б были переводы, то и это прикрутить легко. Движок, на котором работает документация (рендерится .md с гитхаба) самописный, поэтому подобные вещи легко реализуются.
В системы аналитики (clickhouse, например) может иметь смысл складывать, потому что grep'ом и awk, sort'ом и uniq можно конечно какую-то аналитику сделать, но это часто нетривиально, болезненно, да и в данном случае не только диск, но ещё и проц и память загрузит.
В системы полнотекстового поиска + аналитики (Elasticsearch, Manticore в будущем) — чтоб не париться ни о первом, ни о втором.
А если речь об одном сервере и десятках/сотнях мегабайт логов, да ещё и аналитика не нужна
и нет проблемы подождать несколько секунд и визуализация тоже не нужна, то конечно достаточно простого grep'а, ну или чего-то чуть более мощного. Grafana Loki в таких случаях может быть неплох.