Comments 83
Фатальный недостаток: отсутствие JOIN ). На самом деле, проблема в исключении из результатов поиска чего-угодно содержимого персонального черного списка. Есть идеи, как это могло бы работать в мантикоре?
В Эластике тоже нет JOIN. Возможно variables могут помочь https://manual.manticoresearch.com/Server_settings/Setting_variables_online#SET
Были бы пользовательские переменные сессионными, можно было бы попробовать. А так персонификация всё портит.
Сделайте feature request с описанием ситуации, когда без этого никак - https://github.com/manticoresoftware/manticoresearch/issues
Это в принципе не должно быть сложно прикрутить.
Так и сделаю, спасибо. Хотя там есть и другие варианты, но все не идеальные.
Фатальный недостаток - это немного про другое.
Отличная статья! Теперь я вижу какой это был огромный труд продолжить дело Sphinx. Не просто подхватить разработку, а вот так вот серьезно за нее взяться. Очень рад, что месяц назад набрел на Manticoere в поисках замены SphinxSE для MySQL 8. Думал, все, труба! Не компилился он у меня, ошибок куча. Пошарился по форумам и узнал, что Sphinx пылью покрылся. И случайно набрел на Manticore. Разработчики в чате оперативно пофиксили баг с Federated и все завелось! В общем, Manticore - это search engine здорового человека!
Спасибо, Manticore действительно быстро развивается вашими усилиями!
Смигрировал электронную библиотеку со Sphinx в Manticore.
Все вроде ок, но при обновлениях (CentOS8) из офф. репозитария часто (в большинстве обновлений) портится индекс (документы перестают находиться, иногда сервер не может стартовать), хотя документов немного (в районе 1 млн.). Помогает перестроение индекса, но это долго и требует ручного вмешательства в процесс.
Можете подсказать, это у меня какие-то проблемы или такое у многих бывает при обновлении сервера?
Среди известных багов такого нет. Нужно смотреть логи searchd в первую очередь. Если они остались - заведите issue, пожалуйста https://github.com/manticoresoftware/manticoresearch/issues/new/choose
А скажите насколько он производительный? Какое максимальное количество одновременных запросов может выдерживать?
Наверное имеется в виду пропускная способность (т.е. кол-во запросов в секунду), а не просто кол-во одновременных запросов. Тут всё очень сильно зависит от данных в индексе и запросов. К сожалению, мы ещё не делали детальных сравнительных тестов пропускной способности Manticore аналогичных тестам latency, описанным в статье. Но в общем и целом можно предположить, что с производительность в плане throughput всё хорошо, т.к. пользователи не жалуются.
Если вы про методику тестирования на http://db-benchmarks.com/ , то в каждой статье (например https://db-benchmarks.com/test-taxi/#about-caches) там подробно описано почему было решено сделать именно так. Вкратце: не хочется тестировать скорость извлечения пары килобайт из памяти по ключу, а хочется тестировать алгоритмы и структуры данных. Кэш ОС наоборот используется! Зло - это именно query cache. Он есть в Мантикоре, есть в Эластике, поэтому в обоих отключается, иначе просто везде даже для очень тяжёлых запросов будет очень низкое latency - бессмысленные результаты.
Вы, наверное, правы, что нет смысла тестировать 100% попадание в query cache. Или кстати почему?
Если говорить про запрос типа `SELECT avg(total_amount) FROM taxi` он как раз будет повторяться раз за разом, логично тестировать его при горячих кешах и постоянно идущих вставках.
А если говорить про запросы типа `SELECT * FROM taxi where match('harlem east') LIMIT 20` то их логично тестировать при горячих кешах и разных значениях предиката. А если у вас достаточно памяти, чтобы все возможные значения предиката попали в query cache, то у вас скорее всего данные плохи.
В реальном проде не важно, с какой 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 мс).
В моей практике по логам работает алертинг.
Или data analyst, делающий разнообразные запросы, чтобы поймать какие-то закономерности и найти интересные факты: каждый из запросов он сделает один раз
Это не запросы в холодную. Это каждый из запросов он сделает один раз ПОСЛЕ ДРУГОГО запроса. Т.е. внутренние кеши БД будут прогреты, даже если не будет 100% попадания к query cache
И Эластик и Мантикора используют mmap и page cache операционки, именно там обычно и происходит прогревание. В сделанных тестах это никаким образом не блокируется, а даже наоборот - в главную метрику "Fast avg" не попадает 20% наиболее холодных запросов на ещё возможно непрогретом кэше, который обеспечивает операционная система посредством mmap.
Если вы имеете в виду какие-то другие конкретные кэши, то скажите.
Ну они же пишут в своей доке:
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" там потому, что никаких вычислений и не делается, просто тупо достают из памяти готовенький результат. Мерить производительность такой операции в наши планы не входило, т.к. из полезной нагрузки остаётся только мерджинг результатов, но там сложность тоже невысокая и его вклад в общее время отклика среднего запроса обычно пренебрежительно мал.
Так это же наоборот хорошо
Ну если цель - померить исключительно производительность query cache'а каждой базы данных, то да :)
А можно пример тестов, где так делается? Интересно было бы понять больше про методику таких тестов.
Я понимаю, что это можно сделать. Интересно сделано ли, есть ли вообще такая практика в сфере бенчмарков. Я просто читал много статей от разных вендоров бд и независимых специалистов по бд с разными бенчмарками. Есть TPC. Есть Кликхаусовские бенчмарки. И я вижу, что обычно тестируют или latency (и часто неправильно в плане точности измерений) или throughput. Поэтому и интересуюсь, т.к. возможно что-то упускаю и есть какой показательный бенчмарк, демонстрирующий то, что вы имеете в виду.
Кликхаус кстати недавно заоупенсурсили свои бенчмарки и вот что они пишут про кэши https://github.com/ClickHouse/ClickBench/#caching
Ну вот вам пользовательский сценарий, встречайте. Есть логсташ, который жил себе спокойно с логами с бакенда. Менеджеру ну очень понравилось что мы тыкаем логи онлайн. Так вот, у нас есть система сборки самописная (что то похожее Jenkins/Teamcity и тп, но более ентрпрайзное) которая пишет логи сборки в файл, манагер сказал пихаем все теперь в еластик и смотрим логи онлайн. Ну вроде не страшно, добавили ссылку на логи по клику можно поглядеть. В то же время команда фронтенда запилила новый просмоторщик прогресса сборки, воодушевленные GitHub actions, теперь вместе с прогрессом отображаются бегущие в реалтайме логи, так с 1 запроса в 5-10-60 минут, открыв эту страницу мы получаем запрос каждые пару секунд. Пока все норм, переход на страницу прогресса по клику (после старта билда мы предлагаем юзеру посмотреть прогресс или закрыть (популярный вариант, потому что билды бегут часами)).
Вызывало это интересный эффект, юзеры начали приводить логи сборки в порядок и тыкать на прогресс чаще чем на закрыть просто наслаждаясь бегущими букавками????? Фидбек от юзеров - а давайте мы будем сразу перенаправлять после старта на прогресс, а не показывать юзлесс кнопочки!
Итог: каждый час запускается пару десятков билдов, логи в реалтайме на странице прогресса которую юзеры забывают закрывать - превращаются в несколько сотен запросов в минуту.
Эта идея очень малоинтересная, если честно.
спасибо большое за продукт, на самом деле юзаю в проде уже дольше 4 лет, вроде с начала 2018ого. напишу завтра в офис, чтобы вам задонатили, если есть у вас для этого ссылка.
Поною, как «счастливый» пользователь Elasticsearch с 2015 года. Если вы заборете Elasticsearch, то это будет невероятный буст прогресса для всего человечества. Потому что Elasticsearch ~могуч, вонюч и колюч~ крив и тормозён до невозможности чисто в силу своей архитектуры даже. Это жаба-глюкалово надо убить, но он также слишком живуч и чрезвычайно энтерпрайзен кармически, поэтому пока что никому не удалось этого сделать.
С названием/брендингом у вас только что-то не то. Очень трудно читается и трудно запомнить (но это ИМХО).
Еще C++ будет портить карму. Трудно избавится от стереотипа про то, что так и будет крэшиться (а это и не всегда стереотип). Вот если бы Раст, было бы современно, надежно, молодежно.
Ну это же все-таки форк sphinx. Ну и как используют же люди написанные на C++ postgres, mysql, clickhouse, tarantul.
Несколько я знаю, Postgres всё-таки на C.
Ну, половина из того, что перечислено, не на си++ а на си (что, впрочем, не делает их менее падучими; что реально делает их менее падучими, так это давно утерянная в веках магия древних друидов, которые были тысячелетиями заперты в пещерах и от безысходности высекли напильниками фотонные звездолеты), а половина из второй половины - местечковое. Так что так себе аргумент. :)
"Немного" удивляет разница в скорости заливки данных.
Насколько я понимаю, Эластик при записи анализирует текст по-дефолту.
Мантикора в этом случае тоже анализирует текст? Если да, то, получается, анализатор работает со скоростью более 400 тыс. объектов в секунду на указанных ресурсах?
Да, и Мантикора тоже анализирует.
Круто! Правильно ли я понимаю, что в обоих случаях это просто токенизация без нормализации?
Есть ли статистика по скорости нормализации?
Что конкретно вы имеете в виду под нормализацией?
Нормализация текста для полнотекстового поиска. Или стоит дождаться отдельной статьи про полнотекст? :)
У вас указано в тексте про релевантность и широкие возможности, но хочется понимать: а) более детальную разницу б) разницу в скорости работы с полнотекстом.
После второй версии ElasticSearch, которая требует 256Мб оперативки и вполне крутится на двухядерных VPS, Шай пошел за деньгами и превратил свое детище в прожорливый энтерпрайз.
Кстати, схема все равно нужна, записать что угодно получится только при первом запросе. Бессхемность сомнительная штука, как и эвристика типов.
А есть гайд "для дебилов" ? Я вот далек от веб технологии, но уже долгое время вынашиваю мечту сделать поиск по своим 100гб пдф файлов, разложенных по папкам. Чего бы хотелось - Линукс сервер, примитивный Web UI, с возможностью отметить галками папки, аналогичной структуры как на диске. И поискать документы в них с выдачей а-ля Гугл (какой кусок нашелся, подсветка ключевых слов).
Вроде бы типичная задача для создания портала документов в небольшой организации ?
Вот гайд https://manual.manticoresearch.com/Quick_start_guide . Справа можно переключать язык программирования.
Не помню точно у кого есть Web UI в дополнение к обычному GUI и CLI. Но, возможно, вашу задачу осилят локальные поисковики. Сам активно использовал Recoll, но перебрался на DocFetcher. У меня схожая задача - в огромной массе документов, в том числе pdf, часто приходится искать нужную информацию.
https://en.wikipedia.org/wiki/List_of_search_engines#Desktop_search_engines
У меня всё-таки не локальный поиск. Есть группа энтузиастов (менее 10 человек) и накопленная база знаний. Вот хотелось бы привести ее в централизованный вид. На имеющемся сервере. Идеально ещё иметь для пользователей возможность ставить пометки и хештеги, а также иметь историю версий для документа. (Они, обычно, уже версилнированы вендором, типичное число версий 1-5. Самое мерзкое - есть тенденция убирать из новых версий полезности, бывшие в старых). Поэтому я и написал про "небольшую организацию" - ИМХО задача такая же.
Я не нашел поддержки FreeBSD :(
FreeBSD ограниченно поддерживается. Наш CI проверяет, что Мантикора собирается под FreeBSD, но автотесты не делаются. Пакетирование мы тоже пока не осилили. Но вручную собрать можно, вот инструкция https://manual.manticoresearch.com/dev/Installation/Compiling_from_sources#Building-using-CI-docker .
Ох, там еще проверка сборки с кучей библиотек :(
Через сборочный докер собираться должно легко. Вручную искать какие-то либы и пр. не нужно, всё уже в докере.
Docker не поддерживается FreeBSD.
Нужно будет нативная сборка, чтоб устанавливать во FreeBSD через порты и пакеты.
В том-то и фишка нашего сборочного докера, что собирать можно в линуксе. Sysroot'ы от всех систем уже готовы https://repo.manticoresearch.com/repository/sysroots/roots_with_zstd/ , что делает возможным такой трюк. Мы даже под винду собираем под линуксом.
Вы предлагаете FreeBSD crossbuild with GCC/CLANG on Linux host.
Для разработки и автоматизированных тестов, возможно и подойдет, но для пакетирования придется дополнительно обмазаться тестами из 4-х веток FreeBSD, разных версий библиотек Mysql,Postgre, OpenSSL/LibreSSL.
Отдельно тестить варианты с ODBC, icu, expat, iconv, pcre2.
Все это перечисленное должно ставиться из пакетной базы.
Спасибо за статью. Используем во многих проектах Sphinx и Manticore. Знаком со Sphinx наверно с 2014 года. Действительно обидно когда решение незаслуженно уходит на второй план, многие даже про Sphinx и Manticore не слышали.
Нужно больше статей про Manticore. Я когда-то написал парочку на хабр. Возможно ещё напишу, - есть что рассказать.
Если бы пользователи не ошибались всё было бы отлично :).
Но в реальном мире хотелось бы:
функцию проверки расстояния Дамерау-Левенштейна в дополнение к уже имеющейся LEVENSHTEIN(), т.к. перестановки иногда случаются;
поиск похожих по расстоянию Дамерау-Левенштейна, в дополнение к SUGGEST();
исправить ошибку в SUGGEST();
сделать levenshtein() multibyte safe
есть и другие хотелки, но они не так актуальны :)
Подскажите, пожалуйста, какое максимальное количество маппингов(свойств) поддерживает индекс? В эластике не рекомендуют заводить много индексов для разделения по tenant, а советуют всё держать в одном индексе. Как стоит делать в Manticore?
256 полнотекстовых полей и несколько тысяч атрибутов.
Я догадываюсь почему про Эластик может быть такая рекомендация - из-за ограничения на количество файловых дескрипторов. На Мантикор это ограничение действует аналогично: каждый индекс съедает сколько-то файловых десрипторов, если индексов очень много - они могут кончиться. В остальном же не вижу причин рекомендовать в Мантикоре держать всё в одном индексе, когда требуется делать иначе.
Вариант на английском будет на блоге на днях.
планируете ли в дополнение к стандартному и enterprise планам SaaS-решение? А еще лучше managed-solution
Да, планируем и то и то, уже есть некоторые наработки.
Вот статья на английском https://manticoresearch.com/blog/manticore-alternative-to-elasticsearch/
Отличная статья и прекрасная работа !!!
Будет ли клиент для .NET/C#?
И есть ли алиасы как в elasticsearch (может невнимательно читал, но не увидел про них)? Например, у меня частый сценарий работы - есть массив данных, который периодически обновляется целиком, после чего подгружается в эластик для поиска по нему. При этом чтобы не останавливать прод, создается новый индекс, в него грузятся данные, по окончанию алиас переключается со старого индекса на новый.
Будет ли клиент для .NET/C#?
Бета уже есть https://github.com/manticoresoftware/manticoresearch-net
Скажите, если хотите помочь с тем чтоб сделать его GA, там чуть-чуть осталось.
есть ли алиасы как в elasticsearch
Есть, но называется по-другому и требуется несколько миллисекунд на переключение:
snikolaev@dev:~$ time mysql -P9306 -h0 -e "drop table if exists alias; create table alias type='distributed' local='t2';"
real 0m0.011s
user 0m0.010s
sys 0m0.000s
Schemaless режим работы. Хотим чтоб про схемы данных не нужно было думать в большинстве случаев.Что вы подразумеваете под неподдержкой schemaless в Manticore? В Elasticsearch нет никакого настоящего schemaless (и не может быть), поля-индексы умеют добавляться в реальном времени (ну как умеют, лучше сделать это вручную и заранее). Получается, в Manticore нельзя добавить поле realtime или всего лишь нет автодобавления нового поля?
А JSON покрывает базовую функциональность: поисковые запросы и запросы на вставку и обновление данных.Вся красота JSON — в аналитике, позволяющая строить многоэтажные агрегации, которые ко всему прочему легко машиночитаемы. Наверно для логов хватит SQL, но для чего-то более сложного — едва ли.
Что вы подразумеваете под неподдержкой schemaless в Manticore?
Подразумеваю автодетект типов полей на основании первого документа (и возможную корректировку через какое-то время, есть такая идея)
Получается, в Manticore нельзя добавить поле realtime или всего лишь нет автодобавления нового поля?
Поле добавить можно. Автодетекта типа нет.
Вся красота JSON — в аналитике, позволяющая строить многоэтажные агрегации, которые ко всему прочему легко машиночитаемы
Согласен, поэтому для поиска в Мантикоре JSON нормальный. Nested boolean query вот добавили в последней версии https://manual.manticoresearch.com/Searching/Filters#Nested-bool-query
А для управления нодой пока что SQL через mysql и через HTTP (/sql?mode=raw)
В Elasticsearch намного больше возможностей и можно строить сложные многоэтажные группировки с удобным выводом. При этом ES SQL такой же более ограниченный GROUP BY, что говорит о том, что и вам либо придётся сделать запросы JSON более функциональными, чем SQL, либо соревноваться в области аналитики не получится.
А можно конкретный пример что можно через JSON и нельзя через SQL?
query: ...
aggregations:
terms ->
filter1 ->
terms
filter2 ->
metric (e.g. sum)
terms ->
...
Это простейший пример, я не вспоминаю про всякие pipelines и прочие расширенные возможности. JSON группировки в Elasticsearch — это многоуровневые процедуры обработки данных. Конечно, можно с помощью своего кода и нескольких запросов как-то вывернуться, но сомневаюсь, что во всём и это производительно.
Даже для поиска JSON API предоставляет мелкие настройки вроде minimum_should_match для условий, которые в SQL просто не предполагаются. SQL хорош только ad-hoc для глупых кожаных мешков.
Ваш пример непонятен:
filter1/2 - что это? "filter" или это такие имена агрегаций просто
"terms" в трёх местах на трёх уровнях - что это?
То ли вы имеете в виду multi_terms, то ли что-то ещё. Не хочу гадать. Если вы приведёте конкретный пример в синтаксисе Эластика, то я постараюсь сконвертировать его в SQL и буду рад, если это не удастся сделать. Значит будет повод задуматься о расширении синтаксиса.
Есть в природе гайд по переезду с ES на Manticore?
Вот навскидку, чем заменить char_filter?
{ "settings": {
"index": {
"analysis": {
"char_filter": {
"e_char_filter": {
"type": "mapping",
"mappings": ["Ё => Е", "ё => е"]
}
}, ......
Или е-ё, и-й поддерживается из коробки?
Видимо маппинги в charset_table
U+401->U+415
Да. И Ё->Е из коробки поддерживается, а Й->И нет, т.к. ситуация тут совсем другая, чем с Ё.
Поэкспериментировать с дефолтными настройками можно так:
mysql> drop table if exists t; create table t(f text); call keywords('Ё ё Й й', 't');
Query OK, 0 rows affected (0.03 sec)
Query OK, 0 rows affected (0.04 sec)
+------+-----------+------------+
| qpos | tokenized | normalized |
+------+-----------+------------+
| 1 | е | е |
| 2 | е | е |
| 3 | й | й |
| 4 | й | й |
+------+-----------+------------+
4 rows in set (0.00 sec)
Manticore — альтернатива Эластику на C++ с 21-летней историей