Аннотация

Meilisearch и Typesense стоит выбирать не по обещанию «быстрого поиска», а по тому, какой отказ приемлем. Meilisearch позволяет обменять RAM на дисковые чтения благодаря LMDB и mmap; Typesense держит поисковые структуры в памяти и требует заранее ограничить набор индексируемых полей. Однако mmap не делает память бесплатной, а оценка Typesense «2–3 размера данных» относится не ко всему JSON и не к пиковому RSS. У обоих движков переиндексация и восстановление требуют отдельного бюджета ресурсов.12

Допущение автономного обзора — один администратор, один сервер с локальным SSD и поисковый индекс над отдельной основной БД. Это документальное исследование по официальным руководствам, релизам, версионному исходному коду, документации Linux и одному обсуждению эксплуатации. Данные на 2026-11-06; собственный запуск движков, нагрузочный бенчмарк и восстановление из копии не проводились. Рабочие версии — Meilisearch 1.56.1 и Typesense 30.2. Исходный повод про Meilisearch 1.56 от 26 октября подтвердился, но к дате обзора уже вышел исправляющий релиз 1.56.1 от 2 ноября; оставаться в сравнении на 1.56.0 было бы неверно.345

Введение

Цель — выбрать поисковый индекс для собственного приложения, который можно обслуживать на одном сервере: понять расход памяти, контролировать релевантность русского текста и не потерять обновления при импорте. Это не метапоиск по внешнему вебу. В обзоре альтернатив SearXNG Meilisearch и Typesense занимали только короткую таблицу; здесь рассматривается принадлежащий приложению индекс. В отличие от материала про SQLite, важна не конкуренция SQL-транзакций, а доставка изменений в производное представление. В отличие от обзора локального инференса, объём памяти и задержка обсуждаются без переноса результатов чужого или собственного бенчмарка на другую нагрузку.

Границы. Основной сценарий — лексический поиск по каталогу или базе документов, локальный SSD, один узел, основная БД отдельно. Семантический поиск, генерация embeddings и кластерное масштабирование не сравниваются по скорости. Они добавляют другие расходы: руководство Typesense, например, отдельно считает память векторов и загружаемых моделей, поэтому текстовый ориентир sizing нельзя переносить на hybrid search.2

Методологическое ограничение важно: URL документации Typesense закреплены на 30.2, но даже такую страницу могут отредактировать. Неверсионные страницы Meilisearch и общие руководства Typesense ниже означают состояние документации, прочитанное 6 ноября, а не доказанный набор умолчаний любого старого бинарника. Версионный порядок ранжирования Meilisearch проверен по тегу v1.56.1. Конфигурационные советы обозначены как рекомендации автора, а не измеренные оптимальные значения.67

1. Релиз — часть модели отказов

Meilisearch 1.56.0 добавил sampledCount для распределения фасетов и улучшил реакцию на перегрузку внешнего embedder, включая Retry-After в секундах. Это не подтверждение общего автоматического backpressure для любого лексического импорта: изменение относится к конкретному внешнему сервису. В 1.56.1 исправлены расход памяти и время выполнения длинных фильтров, а также случай ranking score больше единицы. Официальная рекомендация — обновиться с 1.56.0.34

Typesense 30.2 в публичном списке релизов обозначен как Latest; GitHub указывает публикацию 19 апреля 2026 года. Среди исправлений — числовые фильтры !=, подсветка при конкурентных записях и отзывчивость /health во время массовой вставки. Поэтому исправный health endpoint и успешная индексация — разные проверки даже на уровне истории релиза.5

Кроме patch-версии важна миграция API. В документации ветки 30 synonyms и curations стали ресурсами верхнего уровня, а права для новых synonym endpoints требуют synonym_sets:*, не прежних synonyms:*. Автоматическая миграция данных не означает, что старый клиентский код и ограниченные ключи продолжат управлять ими без изменений. Для self-hoster это аргумент за пробный upgrade на копии, а не за бесконтрольное обновление контейнера.8

2. Два разных счёта за память

Meilisearch: mmap — способ доступа, а не отсутствие RAM

Официальное описание LMDB формулирует механизм так:

“LMDB stores its data in a memory-mapped file.”1

Файл отображён в виртуальное адресное пространство, а физические страницы подгружает ОС. Большой размер отображения не означает, что столько же RAM занято прямо сейчас. Но когда запрос обращается к отсутствующей странице, работу переносит на диск. Следовательно, возможность открыть индекс больше памяти — это возможность заплатить задержкой за промахи cache, а не обещание той же производительности на маленьком VPS.1

Нужно различать виртуальный размер, резидентные файловые страницы, анонимные выделения и учёт контейнера. Linux определяет RSS как резидентную часть отображения, PSS — как пропорциональную долю разделяемых страниц; smaps отдельно показывает clean/dirty и anonymous memory. Поэтому нельзя весь RSS Meilisearch объявлять heap, а потом прибавлять к нему те же отображённые страницы второй раз как независимый page cache. Для диагностики требуется разложение, а не одна колонка top.9

Документация Meilisearch сообщает о наблюдениях, где отношение RAM к размеру базы на диске около трети, иногда около одной десятой, работает приемлемо. Это наблюдения поставщика, без достаточной здесь методики для переноса на чужой корпус и p99. Более того, речь о базе на диске, не размере входного JSON. Правильный вывод узкий: полный индекс в RAM не является обязательным условием запуска; сколько cache достаточно именно приложению, ещё предстоит измерить.1

MEILI_MAX_INDEXING_MEMORY — не эквивалент лимита контейнера. Справочник допускает превышение настройки, а разработчик в обсуждении #6112 уточняет область действия:

“This limit only applies to the data structures used for indexing documents in the core indexer.”10

Там же названы LMDB и HTTP-библиотека как дополнительные потребители. Обсуждение относится к более старым версиям и не доказывает утечку в 1.56.1; оно объясняет, почему бюджет индексатора нельзя трактовать как жёсткий cap RSS. В частности, эксперимент с уменьшением памяти в этой переписке сопровождался жалобой на ухудшение переиндексации. Экспериментальные параметры оттуда не следует копировать в новый deployment без проверки версии и эффекта.1110

Typesense: индекс в RAM, но не весь документ

Typesense прямо пишет, что весь поисковый индекс находится в памяти, а копия исходных документов — на диске. Ориентир 2–3× относится к значениям полей, по которым нужен поиск и фильтрация; много уникальных токенов сдвигает расход к верхней границе. Неиндексируемые поля для отображения можно оставить на диске. Это существенно отличается от утверждения «на каждый гигабайт JSON нужны три гигабайта RAM».2

Схема превращается в инструмент контроля бюджета. index: false запрещает поиск, сортировку, фильтрацию и faceting по полю; это не то же самое, что store: false, которое убирает значение из сохраняемого документа. Например, длинное тело статьи, нужное только для выдачи, можно не индексировать, сохранив его для отображения. Но если требуется искать именно по нему, вынести его из расчёта RAM уже нельзя.12

К постоянному индексу добавляются временная память импорта, структуры allocator, RocksDB и кэши. Документация 30.2 описывает RocksDB write buffers и лимит числа memtables; endpoint /metrics.json различает allocated, active, resident и retained. Это не четыре независимо складываемых потребителя: показатели отражают разные стороны учёта allocator. Сам по себе рост resident после импорта не доказывает рост живых данных или утечку.1314

Контейнер ограничивает обе модели

В cgroup v2 memory.current учитывает использование группы и потомков, а memory.stat разделяет, в частности, anon и file; последнее включает кэш файловой системы. memory.max — жёсткая граница, при невозможности уменьшить использование вызывается OOM killer. Поэтому файловые страницы Meilisearch тоже участвуют в давлении на лимит. Рекомендация: наблюдать одновременно cgroup, разложение процесса, дисковые чтения и задержку поиска, а не считать «вытесняемый cache» памятью вне контейнера.15

У Typesense 30.2 --memory-used-max-percentage и --disk-used-max-percentage служат для отклонения записей при превышении порога. Документированный default 100 обозначен как never reject. Это не резерв памяти для безопасного завершения любой пачки и не аналог memory.max. Выставить порог раньше полного исчерпания — разумная защита, но конкретное значение надо выбирать по наблюдаемому запасу и пику, не по универсальному рецепту.13

3. Релевантность: порядок критериев важнее ярлыка fuzzy

Meilisearch: последующее правило не отменяет предыдущее

В исходном коде 1.56.1 порядок default_criteria() такой: words, typo, proximity, attributeRank, sort, wordPosition, exactness. Это важное уточнение к старым примерам с единым attribute. Документация описывает последовательную сортировку по группам: если раннее правило уже разделило документы, позднее не поменяет их взаимный порядок.616

Практическое следствие: «повыше поставить популярное» и «обязательно сортировать по цене» — разные требования. Низко стоящий sort упорядочивает документы внутри уже разделённых групп релевантности; высокий делает сортировку более строгой ценой приоритета текстового соответствия. Аналогично, изменение порядка searchableAttributes действует в рамках соответствующего критерия, а не отменяет все предыдущие. Сначала нужно сформулировать, какую ошибку выдачи исправляют, потом двигать правила.16

Typo tolerance управляет множеством допустимых совпадений, а правило typo — их порядком. Удалить правило ранжирования не означает запретить исправления. Текущая документация позволяет отключить tolerance для отдельных атрибутов, слов и чисел. Для артикулов или номера модели это содержательно важнее общего обещания fuzzy: близкое написание может оказаться другим товаром. Конкретные пороги нельзя переносить между продуктами только потому, что оба называют функцию typo tolerance.17

Typesense: веса полей зависят от режима агрегации

В Typesense 30.2 query_by_weights работает вместе с text_match_type. В режиме max_score, обозначенном в версионной документации как default, представителем документа становится лучшее совпадение среди полей, а веса разрешают равенство текстового score. max_weight выбирает score наиболее весомого поля; sum_score складывает оценки полей. Поэтому «увеличить вес заголовка» без указания режима — неполная рекомендация и не аналог перестановки правила Meilisearch.7

У Typesense отдельно настраиваются опечатки, prefix и ослабление многословного запроса через drop_tokens_threshold. Если результат появился после отбрасывания слова, это не доказательство хорошей морфологии и не обязательно хороший ответ. В строгом тесте идентификаторов нужно явно отключать нежелательные расширения; в поиске по бытовому названию товара они могут быть полезны. Сравнивать выдачу надо при одинаковом пользовательском требовании, а не обязательно при одинаково названном параметре.7

Русский: алфавит, основа слова и лемма — не одно и то же

Документация Meilisearch описывает Charabia и языковые pipelines, а в текущей таблице для Russian/Cyrillic указывает default segmentation и decomposition/lowercase normalization. Это подтверждает обработку письменности и нормализацию, но не устанавливает качество русской лемматизации. Из факта «понимает кириллицу» нельзя вывести, что все формы существительного будут сведены к одной словарной форме.1819

Typesense 30.2 явно перечисляет locale: "ru" и включает stemming отдельно через stem: true; в таблице схемы stem по умолчанию false. Для выбора алгоритма используется locale поля, а руководство называет Snowball и предупреждает о побочных эффектах на именах, брендах и географии. Предлагаются и словари соответствий. Это проверяемое функциональное различие, но не основание объявлять Typesense победителем на русском без теста собственных запросов.1220

Для приёмки я предлагаю отдельные классы запросов: точное название, перестановка слов, опечатка, падежная форма, е/ё, смешанная кириллица/латиница, артикул и редкое собственное имя. Это проект теста, не полученные результаты. Проверять стоит нужный документ в первых результатах, лишние совпадения и причину расширения запроса. Числовую оценку качества нельзя подменять наличием слов locale, fuzzy или stemming в перечне возможностей.7171220

4. Подтверждение записи: очередь и частичный успех

Meilisearch возвращает taskUid и enqueued, когда операция поставлена в очередь. Для зависимого чтения нужно дождаться succeeded, а при failed проверить error: документация говорит, что изменения такой задачи в БД не сделаны. Сохранить только HTTP-успех и сразу подтвердить синхронизацию клиенту — значит перепутать принятие задания с готовностью индекса. Полезно связывать номер события основной БД с taskUid и итоговыми receivedDocuments/indexedDocuments.21

Асинхронность не создаёт пропускную способность из ничего. Совместимые задания могут объединяться в batches, служебные задачи имеют приоритеты; простой лозунг FIFO не описывает весь scheduler. Поэтому клиентский показатель свежести — не длина очереди сама по себе, а возраст самого старого ещё не применённого события и время от приёма до завершения. Ограничивать предлагается число незавершённых пачек и их суммарные байты: это рекомендация управления нагрузкой, а не найденный серверный предел.21

У Typesense другая ловушка. Версионная документация bulk import предупреждает:

“The import endpoint will always return a HTTP 200 OK code, regardless of the import results of the individual documents.”22

Код 200 OK не исключает строк с success: false. Нужно разобрать весь ответ, сопоставить ошибки с документами и повторять исправленные неуспешные записи с учётом ID и выбранного action. Повторить целиком пачку с create и объявить дубликаты новой аварией — не корректная стратегия восстановления после частичного успеха.22

Ответ bulk import не следует трактовать как транзакцию всего набора. Также рассмотренные источники не дают основания обещать строгую одинаковую read-after-write семантику всех путей обоих продуктов при обрывах связи. Безопасный прикладной протокол — хранить доставляемые события до подтверждения на уровне нужной операции и иметь сверку индекса с источником. Это инженерный вывод из разных форм подтверждения, не результат испытания отказов.2122

5. Импорт и переиндексация: сначала допуск нагрузки

В Typesense 30.2 серверный batch_size bulk import по документации равен 40: между порциями обслуживается поиск. Это не рекомендация отправлять HTTP-запросы по 40 документов. Клиентская пачка и внутренняя порция — разные регуляторы. Увеличение внутренней порции может ухудшить поиск, а большие пачки увеличивают временную память; поэтому сначала ограничивают клиентский параллелизм и измеряют совместную нагрузку, а не выкручивают оба параметра вверх.22

Meilisearch рекомендует сначала настроить индекс, потом добавлять документы: изменение ряда настроек запускает полную переиндексацию. Там же оговаривается компромисс больших payload: меньше накладных расходов, но больше RAM и риск падения при нехватке памяти. Поэтому максимальный допустимый HTTP payload не является оптимальным размером пачки, а отдельное ускорение импорта не доказывает сохранение задержки пользовательского поиска.23

Для фонового перестроения Typesense предлагает новую коллекцию и переключение alias; Meilisearch — атомарный swap пары индексов. Это решает смену поискового представления, но не обеспечивает бесплатно ресурсы для двух представлений. Пока обе коллекции Typesense существуют, нужны оба in-memory индекса плюс импорт. У Meilisearch обе базы и рабочие выделения конкурируют за диск и cache. Формула «нужно ровно вдвое больше RSS» не подтверждена: структура индексов, настройки и доля резидентных страниц могут отличаться.242512

Не менее важна граница обновлений. Переключение alias само по себе не доставляет в новую коллекцию изменения, произошедшие после начала полного экспорта. Документация Typesense для смены схемы описывает dual writes и последующее переключение; при этом универсальной гарантии устранения гонок между backfill и более свежей записью она не устанавливает. Рекомендация — выделить проверяемую границу событий, догнать изменения, сверить контрольные документы и только затем переключить чтение. У Meilisearch swap оставляет enqueued tasks неизменными: надо заранее понять, куда попадут уже принятые задания.1225

Практическое правило допуска нагрузки: до старта полного rebuild проверить место под старый и новый индекс, копию для отката и временные данные; затем определить условие остановки производителя. Если растёт возраст очереди, RSS приближается к лимиту или портится хвост задержки, уменьшать поступление новых пачек. Конкретные пороги — часть приёмки на своей машине. Ни наличие очереди Meilisearch, ни защитный процент Typesense не заменяют этого решения.212213

6. Копия ещё не означает восстановление

Meilisearch различает snapshot и dump. Snapshot — точная копия базы для быстрого восстановления на той же версии; dump — экспорт документов и настроек, полезный для миграции, с повторной индексацией при импорте. Поэтому «есть переносимый dump» не означает короткий RTO: документация предупреждает, что до завершения импорта API недоступен. Импорт нового dump в старую версию отдельно не рекомендуется.262728

Периодический snapshot тоже требует внешнего процесса хранения. Руководство Meilisearch говорит, что старая локальная копия перезаписывается и в каталоге остаётся только последняя. Следовательно, нужны вынос с диска сервера и собственная политика поколений. Сохранять вместе с копией точную версию запуска, конфигурацию и сведения о границе применённых событий — рекомендация, чтобы не обнаружить несовместимость уже после потери узла.2728

Typesense 30.2 предлагает POST /operations/snapshot: point-in-time копия состояния и данных в указанный каталог, который затем можно восстановить как data directory. Эта страница не является обещанием совместимости любых двух версий. Консервативный план — сначала восстановление той же сборкой, затем отдельно проверяемый upgrade. Документированный snapshot API предпочтительнее самодельного копирования рабочего каталога, для которого в рассмотренных источниках нет соответствующей гарантии согласованности.14

Для одного узла итоговый критерий — не «команда backup вернула успех», а проверенное время до поиска после потери сервера. Предлагаемый учебный прогон: восстановить копию в изолированном окружении, сверить документы и настройки релевантности, выполнить контрольные запросы, догнать события из основной БД. В этом обзоре такой прогон не выполнен. RPO ограничен точкой копии и доступностью последующего журнала; RTO включает перенос данных, запуск, импорт или построение индекса и проверку готовности.261428

7. Дискуссионные вопросы и противоречия

«Meilisearch экономнее, Typesense быстрее». Это слишком широкая формула. Typesense держит индекс в RAM, Meilisearch допускает диск за счёт mmap; но меньший резидентный набор не гарантирует меньшую p99, а полностью помещающийся индекс не гарантирует нужную скорость при совместном импорте. Даже сравнительная страница Typesense признаёт случай, когда Meilisearch лучше подходит при индексе больше RAM. Это позиция заинтересованного поставщика, согласующаяся с механизмом хранения, но не независимый сравнительный замер.1229

«Meilisearch лучше для русского по определению». В сравнительном блоге Meilisearch утверждается, что Typesense испытывает затруднения с морфологически богатыми языками, включая русский. Но документация Typesense 30.2 прямо описывает русский locale и выбираемый stemming. Это не опровержение любого возможного преимущества Meilisearch в качестве, а опровержение способа доказательства: маркетинговый вывод нельзя переносить на текущую версию без проверки корпуса. Таблица языковых pipelines Meilisearch тоже не заменяет такую проверку.30122019

«Высокий RSS — всегда утечка» и «это всегда cache». Оба объяснения преждевременны. В #6112 есть сообщения о росте памяти после повторных rebuild, обсуждение anonymous RSS и признание разработчиком, что причина не установлена. Проблема описана для старых версий, а не доказана здесь для 1.56.1. Противоположное успокоение «всё mmap, ОС освободит» тоже не следует из Linux: есть анонимная память, dirty pages и жёсткий cgroup limit. Диагноз требует разделить виды памяти и повторить цикл на выбранном бинарнике.10915

«Один узел достаточно надёжен, потому что индекс производный». Это верно только при приемлемом времени повторного построения и живом источнике данных. Typesense рекомендует для production несколько узлов и объясняет необходимость трёх для переноса отказа одного по Raft. Но кластер не входит в этот сценарий и не появляется от включения флага на одном сервере. Выбор одного узла здесь — осознанное принятие простоя, а не обещание высокой доступности.2

8. Недостаточность данных

Остались три существенных пробела. Первый — сравнительная релевантность русского корпуса: рассмотрены заявленные механизмы и встречные утверждения поставщиков, но нет использованного здесь независимого теста с одинаковыми документами, запросами, настройками и экспертной разметкой. Победитель по русскому языку не установлен. Второй — пиковая память и p99 при регулярной переиндексации: документация даёт ориентиры, а issue — сообщения об отдельных нагрузках; универсального множителя для выбранных версий не получено.12101230

Третий — фактическое восстановление и граница видимости при отказах. Форматы копий, task statuses и частичные ошибки импорта описаны, но время восстановления, поведение при конкретном обрыве сети и полнота воспроизведения событий на выбранной инфраструктуре не испытаны. Поэтому статья не назначает безопасную частоту backup, размер VPS или максимальное число запросов. Эти параметры должны стать результатом отдельной приёмки, а не экстраполяцией документации.21222614

Заключение

Meilisearch разумнее рассматривать первым, если важна возможность держать индекс больше RAM и приемлема зависимость задержки от локального SSD и cache. Условие — контролировать завершение задач и помнить, что бюджет индексатора не ограничивает весь процесс. Typesense разумнее рассматривать первым, если индексируемые поля можно дисциплинированно уложить в RAM, нужна явная схема и удобен query-time контроль совпадений. Условие — проверять каждый результат bulk import и закладывать отдельный запас для rebuild.121072122

Для русского текста решение начинается с тестового набора, а не с названия алгоритма: tokenization, typo tolerance и stemming решают разные задачи. Для одного узла решение заканчивается не работающим demo, а проверенным rebuild и восстановлением копии. Если новое представление нельзя построить рядом со старым или после потери диска поиск не возвращается в допустимое время, практический предел узла уже достигнут — даже если число документов далеко от формального максимума.17122024252614

Quality Metrics

MetricValue
Sources found173
Sources read36
Sources cited30
Academic sources0
Official/documentation29
Industry reports0
News/journalism0
Blog/forum1
Citation coverage94% (48/51 содержательных абзацев)
Слов в основном тексте2990; разделённые пробелами слова без frontmatter, метрик и сносок, из них 2526 русских токенов
Единица учётаFound — URL-кандидаты, включая отсеянные нерелевантные результаты; read/cited — документы; проверенные перенаправления, raw/blob и .md объединены
Доля official/academic среди cited96.7%
ДоступРелевантные разделы полного текста; abstract-only нет
Counter-arguments searchedYes
Research rounds2
Основные вопросы6: версии, память, релевантность, доставка, rebuild, восстановление
Нерешённые эмпирические вопросы3
Собственный бенчмарк и restore drillНе проводились

  1. Meilisearch. “Storage - Meilisearch Documentation.” Текущая документация, прочитана 6 ноября 2026. https://www.meilisearch.com/docs/resources/internals/storage ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. Typesense. “Typesense System Requirements | Typesense.” Текущее руководство, прочитано 6 ноября 2026. https://typesense.org/docs/guide/system-requirements.html ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  3. Meilisearch. “Release v1.56.0 🐫 · meilisearch/meilisearch.” GitHub, 26 октября 2026. https://github.com/meilisearch/meilisearch/releases/tag/v1.56.0 ↩︎ ↩︎

  4. Meilisearch. “Release v1.56.1 🐫 · meilisearch/meilisearch.” GitHub, 2 ноября 2026. https://github.com/meilisearch/meilisearch/releases/tag/v1.56.1 ↩︎ ↩︎

  5. Typesense. “Release Version 30.2 · typesense/typesense.” GitHub, 19 апреля 2026. https://github.com/typesense/typesense/releases/tag/v30.2 ↩︎ ↩︎

  6. Meilisearch. “meilisearch/crates/milli/src/criterion.rs at v1.56.1 · meilisearch/meilisearch · GitHub.” Исходный код тега v1.56.1. https://github.com/meilisearch/meilisearch/blob/v1.56.1/crates/milli/src/criterion.rs ↩︎ ↩︎

  7. Typesense. “Typesense Search API Parameters | Typesense.” API 30.2, прочитано 6 ноября 2026. https://typesense.org/docs/30.2/api/search.html ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  8. Typesense. “Typesense API Documentation v30.2 | Typesense.” API 30.2, прочитано 6 ноября 2026. https://typesense.org/docs/30.2/api/ ↩︎

  9. Linux man-pages. “proc_pid_smaps(5) — Linux manual page.” Прочитано 6 ноября 2026. https://man7.org/linux/man-pages/man5/proc_pid_smaps.5.html ↩︎ ↩︎

  10. Meilisearch contributors. “MEILI_MAX_INDEXING_MEMORY is ignored · Issue #6112 · meilisearch/meilisearch.” GitHub, issue и комментарии прочитаны 6 ноября 2026. https://github.com/meilisearch/meilisearch/issues/6112 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  11. Meilisearch. “Configuration reference - Meilisearch Documentation.” Текущая документация, прочитана 6 ноября 2026. https://www.meilisearch.com/docs/resources/self_hosting/configuration/reference ↩︎

  12. Typesense. “Typesense Collections API | Typesense.” API 30.2, прочитано 6 ноября 2026. https://typesense.org/docs/30.2/api/collections.html ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  13. Typesense. “Typesense Server Configuration and Ports | Typesense.” API 30.2, прочитано 6 ноября 2026. https://typesense.org/docs/30.2/api/server-configuration.html ↩︎ ↩︎ ↩︎

  14. Typesense. “Cluster Operations | Typesense.” API 30.2, прочитано 6 ноября 2026. https://typesense.org/docs/30.2/api/cluster-operations.html ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  15. Linux kernel. “Control Group v2 — The Linux Kernel documentation.” Прочитано 6 ноября 2026. https://docs.kernel.org/admin-guide/cgroup-v2.html ↩︎ ↩︎

  16. Meilisearch. “Built-in ranking rules - Meilisearch Documentation.” Текущая документация, прочитана 6 ноября 2026. https://www.meilisearch.com/docs/capabilities/full_text_search/relevancy/ranking_rules ↩︎ ↩︎

  17. Meilisearch. “Typo tolerance.” Текущая документация, прочитана 6 ноября 2026. https://www.meilisearch.com/docs/capabilities/full_text_search/relevancy/typo_tolerance_settings ↩︎ ↩︎ ↩︎

  18. Meilisearch. “Tokenization - Meilisearch Documentation.” Текущая документация, прочитана 6 ноября 2026. https://www.meilisearch.com/docs/capabilities/indexing/advanced/tokenization ↩︎

  19. Meilisearch. “Language.” Текущая документация, прочитана 6 ноября 2026. https://www.meilisearch.com/docs/resources/help/language.md ↩︎ ↩︎

  20. Typesense. “Stemming | Typesense.” API 30.2, прочитано 6 ноября 2026. https://typesense.org/docs/30.2/api/stemming.html ↩︎ ↩︎ ↩︎ ↩︎

  21. Meilisearch. “Tasks and asynchronous operations.” Текущая документация, прочитана 6 ноября 2026. https://www.meilisearch.com/docs/capabilities/indexing/tasks_and_batches/async_operations ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  22. Typesense. “Typesense Documents API | Typesense.” API 30.2, прочитано 6 ноября 2026. https://typesense.org/docs/30.2/api/documents.html ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  23. Meilisearch. “Indexing best practices - Meilisearch Documentation.” Текущая документация, прочитана 6 ноября 2026. https://www.meilisearch.com/docs/capabilities/indexing/advanced/indexing_best_practices ↩︎

  24. Typesense. “Typesense Collection Aliases | Typesense.” API 30.2, прочитано 6 ноября 2026. https://typesense.org/docs/30.2/api/collection-alias.html ↩︎ ↩︎

  25. Meilisearch. “Swap indexes - Meilisearch Documentation.” Текущая документация, прочитана 6 ноября 2026. https://www.meilisearch.com/docs/reference/api/indexes/swap-indexes ↩︎ ↩︎ ↩︎

  26. Meilisearch. “Exporting and importing dumps - Meilisearch Documentation.” Текущая документация, прочитана 6 ноября 2026. https://www.meilisearch.com/docs/resources/self_hosting/data_backup/dumps ↩︎ ↩︎ ↩︎ ↩︎

  27. Meilisearch. “Exporting and using Snapshots - Meilisearch Documentation.” Текущая документация, прочитана 6 ноября 2026. https://www.meilisearch.com/docs/resources/self_hosting/data_backup/snapshots ↩︎ ↩︎

  28. Meilisearch. “Backing up Meilisearch data.” Текущая документация, прочитана 6 ноября 2026. https://www.meilisearch.com/docs/resources/self_hosting/data_backup/overview.md ↩︎ ↩︎ ↩︎

  29. Typesense. “Typesense vs Meilisearch: A Production Comparison.” Сравнение поставщика, прочитано 6 ноября 2026. https://typesense.org/typesense-vs-meilisearch/ ↩︎

  30. Meilisearch. “Meilisearch vs Typesense.” Сравнительный блог поставщика, прочитан 6 ноября 2026. https://www.meilisearch.com/blog/meilisearch-vs-typesense ↩︎ ↩︎