Manticore Search быстрее Elasticsearch, но экосистемы вокруг него нет

MAATRIX

Manticore Search выглядит как находка для тех, кому нужен полнотекстовый поиск, но не хочется отдавать серверу гигабайты RAM под JVM: форк Sphinx, написанный на C++, стартует за секунды, ест в разы меньше памяти и говорит на знакомом SQL-диалекте. Проблема вылезает не в бенчмарках, а через пару месяцев эксплуатации — когда нужен дашборд для мониторинга индекса, готовый коннектор для аналитики или просто ответ на StackOverflow на непонятную ошибку, а находится там в лучшем случае пара обсуждений на GitHub. Разберём честно: где Manticore реально выигрывает у Elasticsearch, а где за экономию ресурсов приходится платить временем на то, чего у Elastic давно есть из коробки.

Чем Manticore отличается от Elasticsearch архитектурно

Elasticsearch построен поверх Lucene и работает как Java-процесс: индексация, поиск, агрегации — всё крутится в JVM со своей кучей, сборщиком мусора и характерным аппетитом к памяти (типовое правило — отдавать под heap до половины RAM сервера, вторую половину оставлять под файловый кеш). Manticore Search — нативный C++-бинарник без виртуальной машины между процессом и железом. Это не деталь реализации ради красивого слова в описании, а причина, из-за которой Manticore стартует практически мгновенно и не тратит память на JVM-накладные расходы: нет прогрева JIT, нет пауз сборщика мусора, нет отдельного heap, который надо сайзить по формулам.

Второе принципиальное отличие — родной SQL-протокол. Manticore слушает порт 9306 по протоколу MySQL и понимает обычный mysql-клиент:

mysql -h127.0.0.1 -P9306

Дальше — привычный SQL с поисковыми расширениями:

CREATE TABLE products (
  title TEXT,
  description TEXT,
  price FLOAT,
  category_id INT
) engine='columnar';

INSERT INTO products (id, title, description, price, category_id)
VALUES (1, 'Механическая клавиатура', 'Hot-swap, RGB подсветка', 8990, 12);

SELECT * FROM products WHERE MATCH('механическая клавиатура') AND price < 10000
ORDER BY price ASC LIMIT 20;

В Elasticsearch тот же запрос — это JSON-документ с вложенными bool/must/filter-блоками через HTTP API. Работает надёжно, но синтаксис приходится учить отдельно, и для человека с опытом работы с реляционными БД порог входа в Manticore заметно ниже.

При этом у Manticore есть и HTTP JSON API, частично совместимый с Elasticsearch — можно слать _bulk-запросы почти в том же формате, что упрощает миграцию существующих индексаторов. Это осознанный ход разработчиков: не пытаться быть лучше во всём, а дать простой путь перехода тем, кто устал от ресурсоёмкости Elastic.

Установка и первый запуск: минимализм как фича

Через Docker поднимается один контейнер без внешних зависимостей вроде ZooKeeper или etcd:

docker run -d --name manticore \
  -p 9306:9306 -p 9308:9308 \
  -v manticore_data:/var/lib/manticore \
  manticoresearch/manticore

Порт 9308 — это HTTP/JSON-интерфейс, 9306 — SQL. Никакого отдельного узла координатора, никакой JVM, которую нужно предварительно настроить через jvm.options. На VPS с 2 ГБ RAM и 2 vCPU Manticore стартует и работает с индексами на десятки-сотни тысяч документов без танцев с бубном — для сравнения, Elasticsearch на такой конфигурации обычно уже требует урезания heap и мониторинга, не начнёт ли процесс падать по OOM.

Установка из репозитория на Ubuntu 24.04 — тоже без сюрпризов:

wget https://repo.manticoresearch.com/manticore-repo.noarch.deb
sudo dpkg -i manticore-repo.noarch.deb
sudo apt update
sudo apt install manticore manticore-extra
sudo systemctl enable --now manticore

Конфиг лежит в /etc/manticoresearch/manticore.conf и по объёму параметров сильно короче, чем elasticsearch.yml с сопутствующими системными лимитами (vm.max_map_count, ulimit на файловые дескрипторы, отключение свопа). У Manticore тоже стоит поднять лимит открытых файлов при больших индексах, но обязательных системных танцев вокруг ядра ОС, характерных для Elasticsearch, здесь заметно меньше.

Производительность и потребление ресурсов: где выигрыш реален

Здесь важно сразу оговориться: точные цифры «во сколько раз быстрее» сильно зависят от размера индекса, типа запросов, схемы данных и железа — у вас будут другие числа, чем в любом чужом бенчмарке, включая маркетинговые материалы самого Manticore. Но направление, которое стабильно подтверждается и документацией, и практикой самостоятельного хостинга, такое:

• Потребление RAM в простое. Elasticsearch даже без нагрузки держит выделенный JVM heap плюс служебные структуры кластера. Manticore в простое занимает памяти на порядок меньше — процесс не резервирует кучу заранее, память растёт вместе с реальными данными в индексе.
• Холодный старт. JVM нужно время на прогрев (class loading, JIT-компиляция горячих путей) — первые запросы после рестарта Elasticsearch заметно медленнее, чем через несколько минут работы. Manticore такого эффекта почти не показывает: C++-бинарник работает на полной скорости сразу.
• Простые точные и префиксные запросы. На типовых сценариях (поиск по каталогу, автодополнение) Manticore за счёт более лёгкой архитектуры и columnar-хранилища часто выигрывает по задержке и по числу запросов в секунду на равном железе.
• Тяжёлые агрегации и аналитические сценарии. Здесь преимущество Manticore менее очевидно или вовсе исчезает — движок Elasticsearch с его богатым набором агрегаций (percentiles, significant terms, вложенные bucket-агрегации) отточен именно под такие нагрузки, и Manticore для сложной аналитики поверх больших объёмов данных пока не полноценная замена.

Практический вывод: если задача — полнотекстовый поиск по каталогу товаров, статьям блога или логам с несложной фильтрацией, разница в потреблении ресурсов у Manticore ощутимая и позволяет держать поиск на более скромном сервере. Если задача — аналитический дашборд с десятками типов агрегаций поверх терабайтов логов, разрыв в зрелости инструментария начинает перевешивать экономию памяти.

Реалтайм-индексы и обновление данных без переиндексации

Одна из сильных сторон, унаследованных от Sphinx, — реалтайм-индексы (RT), в которые можно писать данные напрямую через SQL или HTTP без отдельного шага «собрать индекс из источника»:

CREATE TABLE articles_rt (
  title TEXT,
  body TEXT,
  published_at TIMESTAMP
) engine='rt' rt_mem_limit='256M';

INSERT INTO articles_rt (id, title, body, published_at)
VALUES (101, 'Как настроить бэкап VPS', 'Полный текст статьи...', 1756800000);

UPDATE articles_rt SET published_at = 1756900000 WHERE id = 101;
DELETE FROM articles_rt WHERE id = 101;

Изменения видны в поиске сразу, без задержки на переиндексацию. У Elasticsearch похожий эффект достигается через near real-time search (документ доступен для поиска после refresh, по умолчанию раз в секунду) — архитектурно другой механизм, но для пользователя разница на типовых нагрузках небольшая. Реальное отличие в том, что у Manticore есть ещё и классические plain-индексы (собираются из внешнего источника пакетным indexer'ом) — более компактное и быстрое по построению хранилище для данных, которые не обновляются ежесекундно, например архивный поиск по товарам, снятым с продажи. Возможность выбирать между RT и plain-индексом под конкретный паттерн нагрузки — гибкость, которой у Elasticsearch в таком явном виде нет.

Чего не хватает: экосистема визуализации и аналитики

Вот здесь начинается собственно тема статьи. У Elasticsearch есть Kibana — родной инструмент визуализации, построения дашбордов, настройки алертов прямо поверх индексов, без дополнительной прослойки. У Manticore официального аналога Kibana нет. Из вариантов, что остаются: Grafana через MySQL data source (работает, но «в обход» — без нативной поддержки специфики полнотекстового поиска, фасетов, подсветки совпадений, дашборд придётся собирать через ручные SELECT-запросы, а не визуальным конструктором под поисковую специфику); самописные скрипты поверх HTTP API для мониторинга состояния индексов — то, что у Elastic Stack закрывается Kibana и Elastic APM «из коробки»; частичная совместимость с некоторыми Elasticsearch-инструментами через compatibility-слой HTTP API — но только для базовых операций индексации и поиска, а не для всего экосистемного стека.

Для проекта, где поиск — внутренний компонент приложения (каталог, блог, документация), отсутствие Kibana некритично: продуктовый интерфейс поиска вы всё равно строите сами поверх API. Но если нужен инструмент для команды поддержки или аналитиков — «зайти и посмотреть, что происходит с индексом, без разработчика» — здесь Elasticsearch с Kibana ощутимо впереди.

Сообщество, документация и готовые решения проблем

Elasticsearch существует с 2010 года, у него огромное коммьюнити, тысячи вопросов на Stack Overflow с ответами на конкретные коды ошибок, десятки книг и курсов, официальный форум с активными обсуждениями, множество независимых блогов с разборами продакшн-инцидентов. Когда у вас непонятная ошибка при старте узла или странное поведение шардов — практически всегда кто-то уже наступил на эти грабли и написал решение.

У Manticore ситуация другая — не потому, что проект плохой, а потому что сообщество кратно меньше. Официальная документация подробная для базовых сценариев (установка, SQL-синтаксис, конфигурация), но заметно тоньше для нестандартных случаев — распределённые кластеры, тюнинг под специфичную нагрузку, разбор редких ошибок. Вопросов с тегом Manticore на Stack Overflow на порядки меньше, чем с Elasticsearch — по многим специфичным ошибкам вы будете первым, кто их гуглит, а не сотым. Обсуждения ведутся в основном в официальном Telegram-чате и на GitHub Issues, где разработчики отвечают достаточно оперативно, но это не заменяет многолетний архив готовых ответов. Обучающих курсов и структурированных материалов на русском и английском языках заметно меньше — придётся больше разбираться самостоятельно по документации и исходному коду.

Практический вывод для планирования времени: если команда впервые сталкивается с полнотекстовым поиском и рассчитывает быстро находить готовые ответы на возникающие вопросы, Manticore потребует больше самостоятельной работы и экспериментов методом проб и ошибок. Если в команде уже есть инженер, готовый читать документацию и исходники, а не только гуглить чужие решения, — разрыв ощущается меньше.

Клиентские библиотеки и интеграции с языками программирования

У Elasticsearch — официальные клиенты почти для всех популярных языков (Python, Java, Go, PHP, Node.js, Ruby), активно поддерживаемые, с богатой типизацией запросов и покрытием всего API. У Manticore ситуация двойственная: поскольку это MySQL-протокол, для базовых операций подходит любой MySQL-драйвер на любом языке — плюс, не нужно ждать официальную библиотеку, чтобы начать работать. Но специализированные клиенты обновляются менее активно и покрывают не всю функциональность движка — часть возможностей (специфичные для полнотекстового поиска опции, columnar-функции) доступна только через прямой SQL или HTTP API, без удобной обёртки в объекты языка. Готовых пакетов для фреймворков (Laravel, Django и подобных), зрелых и активно поддерживаемых, как для Elasticsearch, под Manticore либо нет, либо они держатся на энтузиастах не на постоянной основе. Для простого CRUD поверх поиска этого достаточно, но ORM-подобный слой с билдером запросов под Manticore, скорее всего, придётся писать самим.

Когда выбирать Manticore, а когда Elasticsearch или OpenSearch

Сводная логика выбора, без религии:

Если вам нужен поиск по каталогу, блогу, документации или логам на VPS с ограниченным бюджетом на RAM, и вы готовы писать SQL руками без готового дашборда для нетехнической команды — Manticore закроет задачу быстрее и дешевле по ресурсам, чем Elasticsearch. Если нужна сложная многоуровневая аналитика, встроенная визуализация для команды поддержки, широкий выбор готовых интеграций — экономия на памяти не перекроет время, потраченное на самостоятельную сборку недостающих частей вокруг Manticore. Компромиссный вариант для тех, кто хочет меньше ресурсов, чем у Elasticsearch, но больше готовых интеграций, чем у Manticore, — присмотреться также к Meilisearch и Typesense: у них тоже нет Kibana, но экосистема клиентских SDK и документация зрелее, чем у Manticore, при сопоставимой экономичности.

Частые вопросы