Вот вы все сидите и ничего не знаете, а мы тем временем понемногу делаем мега-релиз поисковая система Сфинкс номер 3.0. Грядет ряд больших изменений.
Некоторые из них, как и ожидалось, еще даже толком не стартовали.
Однако большая часть уже скорее готова, чем нет. И отдельные изменения произошли даже в государственная отрасль 2.3 .
Так что, пожалуй, пора вкратце поговорить о том, чего ожидать в светлом будущем: будем надеяться, не столь отдаленном.
Для интересующихся чтением все под катом; кто хочет послушать, приходите встреча в эту субботу .
Короче говоря: прощай с концепцией двигателя, дополняющего основную базу; привет, хранилище документов, тотальное RT, репликация, REST и ряд других известных ключевых слов.
Начнем с главного, краткий список запланированных большой изменения:
- новый формат индекса FT: более быстрая индексация, более быстрый поиск, меньший размер;
- новый формат атрибутов: прощайте со всеми глупыми историческими ограничениями;
- полный переход к потокам: до свидания, директива Workers, привет, пул потоков;
- полный переход на RT-индексы: индексатор остаётся, но директива type не так хороша;
- онлайн-репликация индексов RT: постепенная замена адского ручного кластера на автоматический;
- хранение оригинальных документов: до свидания, концепция вспомогательного индекса, здравствуй мир, теперь мы еще и база;
- собственные индексы атрибутов: эмуляция с ключевыми словами работает как-то, но индексы можно использовать;
- REST-интерфейс: API для ботов, SQL для себя, REST для людей.
Зачем и почему все это? Старый формат индекса FT концептуально тянется, страшно подумать, аж с 2001 года.
Нет, конечно, в него регулярно вносились какие-то изменения и оптимизации, так что старичок до сих пор в хорошем расположении духа.
Однако радикальных концептуальных изменений, естественно, с 2001 года не произошло.
Мы храним пачку дельт внешних docid, закодированных в varint, так же, как мы их хранили.
Более того, будучи достаточно низкоуровневым кирпичом, формат индекса влияет не только на собственно хранение данных, но и влияет на ряд других вещей во внутренней архитектуре, которые затем вытекают наружу: требование предоставления внешнего DocID, головная боль с дубликаты документов, ряд странных моментов в производительности, вот и всё.
Сегодня мы можем добиться большего.
В новом формате нет «волшебного» внешнего уникального атрибута DocID; внутренняя нумерация документов отделена от внешней.
Это одно изменение делает возможным множество вещей: внезапно в индекс могут быть добавлены повторяющиеся идентификаторы или вообще не требуется числовой идентификатор; внезапно, при необходимости, для подмножества индексных документов можно создавать компактные битовые маски, а не здоровенные списки идентификаторов; внезапно сами данные полнотекстового индекса можно сжимать гораздо эффективнее, используя всевозможные групповые кодеки, такие как PFD, Group Varint и т. д.; внезапно при индексировании не нужен скучный этап сортировки, индекс можно строить практически поэтапно; и так далее.
Индекс становится до 1,5 раз меньше, строится в 2-3 раза быстрее и теоретически по нему тоже можно искать до 2-3 раз быстрее, по крайней мере, по отдельным запросам.
Прибыль со всех сторон.
Последнее провоцирует очередную маленькую революцию.
Поскольку новый алгоритм инкрементной индексации (который, грубо говоря, «добавляет» по 1 записи к существующему подиндексу в памяти) легко оказался в 2-3 раза быстрее существующего сейчас пакетного индексирования дисковых индексов, то зачем дифференцировать между дисковыми индексами и индексами RT вообще? Отлично, долой дисковые индексы, долой директиву типа.
Раз уж теперь мы можем сделать все индексы RT, без потери производительности, а точнее даже с ускорением, значит, нам нужно это сделать.
(Внутри, конечно, еще есть варианты на базе диска/ОЗУ для реализации отдельных сегментов индекса.
Диск и память по-прежнему различаются по характеристикам производительности и не помнить об этом невозможно.
Однако это настоящая головная боль «как это сделать эффективно» для разработчиков, но заметны снаружи.
Функциональных отличий для пользователей быть не должно.
) Интересно, что утилита индексатор в принципе никуда не исчезает. Еще полезно иметь ETL-инструмент для выгрузки данных из базы и загрузки их в поиск.
Однако раньше он строил дисковый индекс, а теперь будет строить RT-индекс (либо для прямой загрузки в демон, либо для «приклеивания» свежепроиндексированного пакета данных к существующему индексу, это уже не важно).
Так как формат полнотекстовой части все равно сильно меняется, то одновременно надо менять и формат хранения атрибутов, вот так (ломать совместимость, ломать)!!! Теперь все столбцы переменной длины (строки, MVA, JSON и любые другие хитрые типы, если они будут добавлены в будущем) для одного документа хранятся в одном большом блобе, и указатель на этот блоб тоже хранится один.
(А раньше для каждого типа был отдельный файл, и для каждого столбца отдельный индекс, ох.
) Заодно устранена глупая ошибка молодости «4 ГБ должно хватить всем», плюс всё можно обновляется, удаляется и т. д. в едином порядке.
В целом атрибуты фиксированной длины хранятся как и раньше (только при переключении на внутренние номера доступ к ним происходит гораздо быстрее), атрибуты переменной длины потребляют чуть меньше памяти (8 байт на всё сразу, а не по 4 байта на каждое) , плюс теперь ограничен в размере.
Плюс другие небольшие приятные улучшения: например, формат теперь поддерживает справедливый NULL. Или теперь ключи сжимаются внутри данных JSON. Переход на RT, в свою очередь, означает, что форк/префорк становится не просто трудно поддерживать, а невозможно.
Однако здесь на этот раз есть решение «и быстрое, и хорошее», без этих проклятых компромиссов: пул потоков (уже доступен в 2.3) работает максимально быстро с точки зрения скорости поиска (см.
быстро), фундаментальная модель параллельного обработка остается как бы одной, многопоточной, а не многопроцессной (см.
добро).
Если бы сбои еще и успели затронуть только один поток, это было бы идеально, но в жизни идеала не бывает. Поэтому, чтобы облегчить боль от сбоя, теперь подавляющее большинство необходимых данных при запуске выполняется mmap(), а не копируется, благодаря чему запуск (и перезапуск) даже с большими индексами стал довольно быстрым.
Помимо потоков, из-за форсирования RT, очень и очень необходимой становится репликация.
Раз мы заявляем об отказе от дисковых индексов, которые можно было бы как-то копировать туда-сюда в виде файлов, значит, нам нужны хоть какие-то инструменты для RT. Можно, конечно, сделать горячее резервное копирование/восстановление, но это скучно.
Гораздо интереснее онлайн-репликация индексов RT. Что ж, давайте сделаем это.
1 мастер, N динамических реплик, автоматическая передача исходного снапшота, репликация входящих изменений, перевыбор мастера, все это.
Следующий шаг — всевозможные инструменты для построения и управления кластером, но сначала дайте репликации как следует зажить.
Тиражировать «просто полнотекстовые индексы» как-то мелочно, плюс регулярно просят разрешить сохранять исходные документы, плюс для дальнейшего ускорения сниппетов нужно уметь сохранять блоб со всякими странными фаршами, плюс формат индекса Отвязанный от docid позволяет вам грамотно реализовать что угодно.
Ну и мы еще делаем docstore, т.е.
дисковое хранилище не только атрибутов, но и полей индексируемых документов, а также любой связанной с ними метаинформации (пока это только индексы уровня документа для сниппетов).
Маленький шаг для кода, большой шаг для функционала: теперь в Sphinx можно добавить не только полнотекстовый индекс, но и использовать его как базу данных.
Странно, но элементарно.
Было бы неплохо иметь в базе индексы не только по ключевым словам, так одновременно нужно позаботиться и об индексах по атрибутам.
Ну, это значит, что WHERE MATCH('the who') ANDauthor=1234 выполняется "из индекса", так что WHERE MATCH('самая большая редкость') ANDgender='m' выполняется "из поиска", но оба автоматически выполняются оптимально, а не так, что в вызывающем PHP-скрипте необходимо реализовать аналог SQL-оптимизатора и генератора запросов типа WHERE MATCH('the who _author1234').
Эмулировать атрибуты тучей ключевых слов глупо, как кажется (кажется) еще принято знать где, это тоже, конечно, возможно, но если уже это сделать, то по большому счету!!! И наконец, SQL немодно, плюс звонить отовсюду не удобно, поэтому нужно добавлять доступ по HTTP/REST. Самая базовая начальная реализация уже есть в версии 2.3, оттуда мы будем ее расширять и углублять.
Ничего интересного, даже скучно.
При всем этом Sphinx 3.0 попытается взлететь.
Некоторые из описанных вещей, конечно, все еще находятся на стадии разработки и могут не быть включены в первоначальные альфа-версии.
Однако это общий план, плюс, скажем так, больше половины этого плана уже выполнено.
Работы осталось изрядно, но поворачивать назад уже поздно!!! Понятно, что по каждому отдельному большому моменту можно написать отдельную увесистую статью с кучей технических подробностей, но начинать с чего-то надо.
Здесь я постарался дать краткий обзор предстоящих изменений.
То же самое расскажу чуть подробнее через 3 дня, в эту субботу на встрече оводов Сфинкса (конечно, Москва), у которого сразу возникло миллион уточняющих вопросов и нет возможности написать их все в комментариях, заходите ко мне, я постараюсь ответить.
По мере возможности я буду писать здесь (и/или в блоге на сайте) больше статей о предстоящих мега-функциях.
В общем грядёт Сфинкс 3.0, грядёт много изменений, думаю будет интересно.
Ведь не может быть в мире ровно ОДНА библиотека для полнотекстового поиска, да ещё та на безбожной Java?!!! :-) Теги: #сфинкс #рефакторинг длиной в год #теги всё равно никто не читает #сфинкс
-
Обзор Dell Studio 1537-G87P43B
19 Oct, 24 -
Портфельные Инвестиции)
19 Oct, 24 -
Вам Нужно Использовать Веб-Хостинг Mac?
19 Oct, 24 -
Какая Сила Нужна «Сильному Ии»?
19 Oct, 24 -
Разработка Программного Обеспечения На Заказ
19 Oct, 24
