Как стать автором
Обновить

Комментарии 39

Очень интересный проект.
За java клиент с «человеческим лицом» отдельная благодарность.
Можно пробовать затащить к себе в проект…
Всё это позволит писать данные в Manticore Search вместо Elasticsearch из Logstash, Fluentd, Beats и им подобных.

Возможно, тут как раз подходящее место, чтобы задать вопрос, который мучает меня довольно долго. Зачем нужно складывать логи приложений в системы полнотекстового поиска? Лично мне очень сложно представить себе реальный пример, когда для поиска по логам нужно что-то сложнее grep или его микросервис-аналога типа Grafana Loki.

В системы полнотекстового поиска имеет смысл складывать тогда, когда скорость grep перестаёт удовлетворять. Не хочется же ждать 10 минут, пока он на 100 серверах перелопатит в общей сложности 10 терабайт логов, попутно прилично нагружая диски, что может влиять на другие процессы на этих серверах? Интерактивность в аналитике имеет значение. Больше запросов за минуту сделаете — быстрее разрулите даунтайм.

В системы аналитики (clickhouse, например) может иметь смысл складывать, потому что grep'ом и awk, sort'ом и uniq можно конечно какую-то аналитику сделать, но это часто нетривиально, болезненно, да и в данном случае не только диск, но ещё и проц и память загрузит.

В системы полнотекстового поиска + аналитики (Elasticsearch, Manticore в будущем) — чтоб не париться ни о первом, ни о втором.

А если речь об одном сервере и десятках/сотнях мегабайт логов, да ещё и аналитика не нужна
и нет проблемы подождать несколько секунд и визуализация тоже не нужна, то конечно достаточно простого grep'а, ну или чего-то чуть более мощного. Grafana Loki в таких случаях может быть неплох.

Спасибо за такой подробный и исчерпывающий ответ!

юзаю в опенкарте, доволен как слон, спасибо

 Для обычного поиска или построения фасетов категорий?

для обычного поиска, всего 2 явно выраженные категории и тысячи товаров

но есть еще одна особенность, есть кейворды, которые нельзя показывать на витрине, но нужно иметь поиск по ним

Какая интересная штука… спасибо, будем нюхать.

ЗЫ блин такие клевые вещи делаете, и чего я системы поиска не пишу 8(
Решил как раз воспользоваться случаем, и поинтересоваться как обстоят дела с поддержкой локализации и версионности документации? Реально ли добавить пару волшебных кнопок с выбором версии и локали на любой странице, и насколько сложно?

Версионность добавить несложно. С локализацией намного сложнее — нужны переводы. Если б были переводы, то и это прикрутить легко. Движок, на котором работает документация (рендерится .md с гитхаба) самописный, поэтому подобные вещи легко реализуются.

О! Обучалки на KataCode сделаны?

Вдохновлялись катакодой, но реализовали всё сами на k8s, gotty и т.д.

Ого! Действительно круто!

Пользуюсь форком с 18-го года. Очень доволен.

В русской wiki sphinx тогда же и написал упоминание про форк)

Сильно был удивлен тем что нигде нет информации и новости о форке. Наткнулся совершенно случайно.
Пошел пробовать. А есть дока как быстро и тупо подрубить mysql табличку на внешнем сервере в качестве источника?
Ну так это для plain index как в сфинксе. Хотелось реалтайма, если это вообще реально.

Супер-лёгкой интеграции real-time индексов с внешними источниками нет. Думали над этим, есть идеи, но руки не дошли. Пока можно только через ATTACH импортировать данные из plain индекса в real-time. Ну и когда доделаем интеграцию с logstash, то можно будет средствами logstash делать синк из mysql в manticore.

Вообще хотелось бы чего-то подобного, как было в (ныне потерянном в ES) RavenODBC плагине, когда сам сервер цеплялся к SQL серверу и просто периодически выгребал из нужной таблички свежие данные в индекс. Исключалось промежуточное звено типа параллельного экспорта из приложения или прокладки типа logstash
Яростно плюсую! Было бы круто. Я тоже сначала подумал, что оно умеет
сам сервер цеплялся к SQL серверу и просто периодически выгребал из нужной таблички свежие данные в индекс
Ну почему этот плагин выпилили из ES понятно, он там нарушал архитектуру 6+ версии. Хотя было круто, любой инсерт или апдейт в SQL прилетал в индекс самосоятельно, причем update в новую версию

Если речь о 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 применить.
Просто дельта — это запуск indexer по крону или еще как

Да-да, автоматизацию этого я и имел в виду под "Была идея сделать визард+демон".

НЛО прилетело и опубликовало эту надпись здесь

Что вы имеете в виду под ротацией реалтайм индексов? Ротация же — для plain индексов.

НЛО прилетело и опубликовало эту надпись здесь
приложение создает индекс раз в час i_timestamp переключается на него.
предьідущий удаляется. ( точнее не может удалиться — остается пустой фолдер и лок файл

Именно для таких случаев мы и сделали RT mode, когда можно создавать/удалять индексы на лету через CREATE TABLE / DROP TABLE, а не через SIGHUP, RELOAD INDEXES и прочие TRUNCATE RTINDEX WITH RECONFIGURE.

НЛО прилетело и опубликовало эту надпись здесь

А можете завести баг про это с описанием того, как это повторить?

НЛО прилетело и опубликовало эту надпись здесь
Очень круто. А было бы круто сравнить с elasticsearch. Имеет ли смысл с него уходить?

Если кластерные фичи не нужны и в принципе данных не очень много (т.е. атрибуты влезают в память), то можно пробовать 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, что приводило к «интересным» последствиям.
*fix: больше, чем rt_mem_limit
Чтобы как-то обозначить режимы, мы назвали декларативный режим (как в Sphinx 2) plain mode, а императивный режим RT mode (real-time mode).


Что создает изрядную путаницу — при том, что есть еще plain indexes и RT-indexes.

Впрочем, мы это обсуждали в слаке :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории