Вопрос или проблема
У меня есть всего 8 МБ данных и 55 000 элементов, которые я хочу использовать для нечеткого автозаполнения. Пользовательская база очень мала, и это исследовательский проект, поэтому мне не нужна 100% доступность и репликация. Даже с дебаунсингом, Fuse.js заставляет Firefox зависать, даже на Intel i7-9700. Поэтому я хочу добавить бэкенд поисковую систему, которую можно легко установить в контейнере Docker. Стандартом отрасли, по-видимому, является ElasticSearch, но на нашем единственном сервере осталось всего 1 ГБ ОЗУ, и это кажется избыточным. Стоит ли мне все-таки использовать ElasticSearch или есть что-то на DockerHub, что легко настроить, масштабируется лучше, чем Fuse.js и не так тяжеловесно, как ElasticSearch? Данные уже находятся на конечной точке Virtuoso SPARQL, у которой есть индекс “bif:contains”, однако это не поддерживает текст, содержащий пробелы, и нечеткий поиск. Библиотека на стороне клиента также может быть вариантом, если она достаточно быстра для реального нечеткого поиска и не блокирует главный поток.
Если вы разработчик программного обеспечения и можете позволить себе разрабатывать программное обеспечение на Linux в течение нескольких недель (или по крайней мере дней), то вы можете рассмотреть следующий подход:
Используйте какую-нибудь библиотеку или фреймворк для HTTP-сервера с открытым исходным кодом.
На C это будет libonion. В C++ попробуйте Wt. В Ocaml попробуйте Ocsigen. И все они разрабатываются в Европе, поэтому вы сможете легко связаться с их разработчиками (или оплатить поддержку).
8 мегабайт данных – это очень мало. Если у вас много одновременных подключений (проблема C10K), вам может потребоваться хранить их в какой-нибудь базе данных, например, PostGreSQL (или, возможно, sqlite).
Простой резервный поисковый движок можно легко закодировать, используя обычные методы мемоизации. Чтение книг, таких как руководство по сбору мусора, может быть полезным. Вы можете закодировать что-то такое, что “удаляет” или “забывает” старые запросы (например, через несколько секунд).
Если вам нужен исследовательский прототип для десятка одновременных подключений, я думаю, что аппаратное обеспечение RaspberryPi будет достаточно.
Не стесняйтесь связываться со мной по электронной почте на [email protected] (рядом с Парижем во Франции).
Как я комментировал, во многих случаях приобретение большего объема ОЗУ является экономически эффективным.
Ответ или решение
С учетом ваших требований к проекту, существует несколько легковесных альтернатив для Elasticsearch, которые могут с легкостью уместиться на сервере с 1 ГБ ОЗУ и задействовать ваши 8 МБ данных с 55 000 элементами. Вот некоторые варианты, которые вы можете рассмотреть:
-
MeiliSearch: Это быстрый и легкий полнотекстовый поисковый движок, который легко запускается в контейнерах Docker. Он поддерживает функции, необходимые для фуззи-поиска и автозаполнения. MeiliSearch нацелен на простоту использования и высокую производительность, что делает его отличным выбором для вашего проекта, особенно с ограниченными ресурсами.
Для установки в Docker вы можете использовать следующую команду:
docker run -it -p 7700:7700 getmeili/meilisearch -
Typesense: Это еще один легковесный поисковый движок, который обеспечивает быстрый и реальный фуззи-поиск. Он тоже поддерживает установку через Docker и ориентирован на производительность при малом потреблении ресурсов.
Установка в Docker:
docker run -d -p 8108:8108 typesense/typesense:latest --data-dir /data --api-key YOUR_API_KEY -
OpenSearch: Хотя прямо не легковесный, OpenSearch является ответвлением Elasticsearch и предлагает аналогичные функции, но может быть запущен в легковесной конфигурации. Однако, возможно, это будет все же более сложно, чем вам нужно.
-
Algolia или Swiftype: Эти облачные решения являются сторонними сервисами, которые предоставляют API для фуззи-поиска. Они могут справиться с вашими требованиями, хотя при использовании облачных сервисов нужно быть осторожным с конфиденциальностью данных.
-
Использование SQLite с FTS: Если вы предпочитаете более ручное управление, вы можете рассмотреть использование SQLite с поддержкой полнотекстового поиска (FTS). Это решение будет наиболее контроля в условиях малого объема данных и может быть полностью интегрировано в ваше приложение.
Для разработки клиентской библиотеки вы также можете рассмотреть использование Lunr.js или ElasticLunr.js. Эти библиотеки работают на стороне клиента и могут обеспечить быстрый поиск по вашему массиву данных, но вам придется учитывать потенциальную нагрузку на браузер.
В дополнение, если вы можете использовать сервер с большим объёмом памяти, это может существенно повысить производительность работы, особенно если ваши приложения начнут обрабатывать больше запросов.
В заключение, все предложенные выше решения могут легко интегрироваться с вашим проектом и решить вашу задачу автозаполнения при минимальных потребностях в ресурсах.