Комментарии 39
За java клиент с «человеческим лицом» отдельная благодарность.
Можно пробовать затащить к себе в проект…
Всё это позволит писать данные в Manticore Search вместо Elasticsearch из Logstash, Fluentd, Beats и им подобных.
Возможно, тут как раз подходящее место, чтобы задать вопрос, который мучает меня довольно долго. Зачем нужно складывать логи приложений в системы полнотекстового поиска? Лично мне очень сложно представить себе реальный пример, когда для поиска по логам нужно что-то сложнее grep или его микросервис-аналога типа Grafana Loki.
В системы аналитики (clickhouse, например) может иметь смысл складывать, потому что grep'ом и awk, sort'ом и uniq можно конечно какую-то аналитику сделать, но это часто нетривиально, болезненно, да и в данном случае не только диск, но ещё и проц и память загрузит.
В системы полнотекстового поиска + аналитики (Elasticsearch, Manticore в будущем) — чтоб не париться ни о первом, ни о втором.
А если речь об одном сервере и десятках/сотнях мегабайт логов, да ещё и аналитика не нужна
и нет проблемы подождать несколько секунд и визуализация тоже не нужна, то конечно достаточно простого grep'а, ну или чего-то чуть более мощного. Grafana Loki в таких случаях может быть неплох.
ЗЫ блин такие клевые вещи делаете, и чего я системы поиска не пишу 8(
Версионность добавить несложно. С локализацией намного сложнее — нужны переводы. Если б были переводы, то и это прикрутить легко. Движок, на котором работает документация (рендерится .md с гитхаба) самописный, поэтому подобные вещи легко реализуются.
О! Обучалки на KataCode сделаны?
В русской wiki sphinx тогда же и написал упоминание про форк)
Сильно был удивлен тем что нигде нет информации и новости о форке. Наткнулся совершенно случайно.
Есть интерактивный курс — https://play.manticoresearch.com/mysql/
В доке больше деталей — https://manual.manticoresearch.com/Adding_data_from_external_storages/Fetching_from_databases/Introduction
Супер-лёгкой интеграции real-time индексов с внешними источниками нет. Думали над этим, есть идеи, но руки не дошли. Пока можно только через ATTACH импортировать данные из plain индекса в real-time. Ну и когда доделаем интеграцию с logstash, то можно будет средствами logstash делать синк из mysql в manticore.
сам сервер цеплялся к SQL серверу и просто периодически выгребал из нужной таблички свежие данные в индекс
Если речь о 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/питоне/го легче и быстрее.
Представьте, что в табличке mysql нет никаких ключей, как отслеживать изменения?
Это не мешает же в схеме main+delta как-то отслеживать дельту? Конечно это авто-инкримент ключ или ключ даты-времени в записях SQL. Просто дельта — это запуск indexer по крону или еще как и выгребание из двух индексов сразу, что не всегда удобно. Сейчас в ES это предполагается делать через odbc источник для Logstash. Что конечно тоже можно и к Manticore применить.
Что вы имеете в виду под ротацией реалтайм индексов? Ротация же — для plain индексов.
приложение создает индекс раз в час i_timestamp переключается на него.
предьідущий удаляется. ( точнее не может удалиться — остается пустой фолдер и лок файл
Именно для таких случаев мы и сделали RT mode, когда можно создавать/удалять индексы на лету через CREATE TABLE / DROP TABLE, а не через SIGHUP, RELOAD INDEXES и прочие TRUNCATE RTINDEX WITH RECONFIGURE.
А можете завести баг про это с описанием того, как это повторить?
Если кластерные фичи не нужны и в принципе данных не очень много (т.е. атрибуты влезают в память), то можно пробовать Manticore уже. Если нужны и данных очень много, то лучше подождать, пока мы доделаем автоматическое шардирование, автоматический compaction и новый движок. Над всем этим работы ведутся. Бенчмарки мы тоже делаем, график в статье показывал, но не на всех датасетах и запросах пока что получается так хорошо. В общем, работаем над этим.
А может мантикора стать drop-in replacement для 3го сфинкса? Если есть отличия в синтаксисе sql, то где можно почитать?
Отличия в синтаксисе если и есть, то минимальные, но drop-in replacement'ом мантикора стать не может, потому что отличается формат индекса. Мы б может написали конвертилку (как мы сделали для миграции sphinx 2 / manticore 2 -> manticore 3), но и это невозможно, потому что sphinx 3 не open source. Реверсинжинирить его никакого желания и возможности нет.
В Sphinx 2.3.2 и ранее многие пользователи опасались использовать real-time индексы, т.к. это часто приводило к крэшам и другим побочным эффектам.
Это всегда приводило к крашам, если размер индекса был больше, rt_mem_limit в описании индекса. Причина в говнокоде, работающем с чанками индекса.
В двух словах: ненужный чанк сбрасывался не на диск, а в /dev/null, что приводило к «интересным» последствиям.
Чтобы как-то обозначить режимы, мы назвали декларативный режим (как в Sphinx 2) plain mode, а императивный режим RT mode (real-time mode).
Что создает изрядную путаницу — при том, что есть еще plain indexes и RT-indexes.
Впрочем, мы это обсуждали в слаке :)
Manticore Search — форк Sphinx: отчёт за 3 года