Как уже отмечалось здесь, он был выпущен недавно Сфинкс 2.0.1 .
Возможно, релиз произошел в небольшой спешке.
"совершенно неожиданно" (примерно как сессия или Новый год) тоже вышло книга для начинающих , который описывает только новую версию.
Книга «Про ствол» слишком эксцентрична, поэтому пришлось срочно публиковать версию.
Хорошо, что мы потратили месяц-два на подготовку к релизу: исправили ошибки и не сильно сломали функционал.
В этой заметке я расскажу вам о всевозможных нововведениях последней версии 2.0.1 и планах на следующую версию, смотрите подстрочный индекс.
Новые возможности 5 самых заметных (лично на мой взгляд) из 37 новых функций получились такими.
- обнаружение границ предложения и абзаца при индексации, операторов SENTENCE, PARAGRAPH при поиске;
- поддержка иерархических (!) зон внутри документа при индексировании, оператора ZONE при поиске;
- новый тип словаря, значительно ускоряющий индексацию с возможностью поиска подстрок (индексация происходит до 5-10 раз быстрее, а индекс меньше);
- улучшенная поддержка строковых атрибутов: ORDER BY, GROUP BY, параметры сортировки;
- улучшенный синтаксис SphinxQL: избавьтесь от магии, перейдите к SQL'92.
В язык запросов добавлено несколько операторов.
Аргументы операторов (слева и справа от ПРЕДЛОЖЕНИЯ, ПАРАГРАФА) могут быть одним из трех: либо простое ключевое слово; или фраза («унесенные ветром» ПРИГЛАШЕНИЕ тираж); или сам оператор (мама SENTENCE мыла кадр SENTENCE).
Поместить туда произвольное подвыражение весьма нетривиально по техническим причинам.
Для тех, кому интересно, как работает средство сопоставления запросов внутри, эти операторы в дереве оценки запроса получают поток вхождений ключевых слов из поддеревьев и фильтруют этот поток.
Соответственно, после фильтрации вхождений в одном предложении или абзаце в общем случае невозможно с уверенностью сказать, совпадают ли отфильтрованные вхождения по-прежнему или уже не совпадают. Надо как-то еще раз проверить, это достаточно технически сложно (если вдруг кому-то легко, пришлите рабочий патч и заодно пожелания по зарплате).
Поэтому необходимо, чтобы вхождения были атомарными (тогда оно либо совпадает, либо не существует вообще, фильтр его убил).
Ну, вот почему это либо слово, либо фраза.
Чтобы различать границы предложений и абзацев, при индексировании необходимо их обнаружить и сохранить в указателе.
Для этого есть директива index_sp=1 .
Границей абзаца считается серия HTML-тегов уровня блока, написанных в коде.
Поэтому для индексации абзацев необходимо одновременно включить стриппер HTML (html_strip=1), возможно.
HTML обрабатывается там.
Границы предложения определяются на основе текста; для них стриппер включать не нужно.
Границей всегда считается вопросительный и восклицательный знаки, а также, за некоторыми исключениями, точка.
Исключения обозначаются такими сокращениями, как USA или Goldman Sachs S.r.l., такими именами, как John D. Doe и т.п.
Конечно, они могут допускать ошибки, по мере накопления отзывов мы будем добавлять всякие исключения.
Но в целом в тестах он показал себя хорошо.
Об индексации зон Бывает, что люди пытаются поместить внутрь документов текст с какой-то внутренней структурой, не умещающийся в простой фиксированный список полей.
Типичный пример — просто книга: главы, разделы, подразделы, приложения, сноски и т. д. Теперь, начиная с 2.0.1, появилась поддержка такой произвольной структуры (внутри любого регулярного поля).
Включено директивой индексные_зоны , а также использует инструмент для удаления HTML, вам также необходимо его включить.
При индексировании документа будут сохранены границы всех зон, отмеченных выбранными тегами: где начинается и заканчивается каждый h1, например, или приложение.
При поиске соответственно можно ограничить поиск зонами: (ZONE:h1 hello world).
Зон может быть произвольное количество.
Зоны могут быть вложены друг в друга любым способом.
Ограничена только длина тега, примерно 120 байт. Индексируются не все теги подряд, а только те, которые явно указаны в директиве.
Вы можете указать как точный тег, так и префиксную маску: index_zones = h*, глава, раздел, приложение.
При поиске в операторе можно указать несколько зон, аналогично полям: (ЗОНА:(h1,приложение) hello world).
Ограничений по именам нет, т.е.
Вы можете индексировать HTML с этими зонами, вы можете индексировать XML. В отличие от требований XML, технически нет проблем, если зоны перекрываются (например, одна, две, четыре, пять, шесть).
Однако крайне важно, чтобы каждое открытое пространство было закрыто.
О новом словаре На десятом году разработки мы наконец-то прикрутили словарь, в котором (барабанная дробь).
сохраняются сами ключевые слова.
Раньше сохранялись только хеши.
Собственно, сами слова для поиска всё равно не нужны: замена хэшами работает нормально.
Однако при старом типе словаря (dict=crc) для поиска подстрок все эти подстроки нужно было заранее проиндексировать (поскольку поиск подстрок по хэшу утомителен).
Такая прединдексация всех возможных подстрок, кстати, работает максимально быстро при поиске.
Однако время индексации и размер индекса сильно страдают; оно оказывается в 5-10 раз медленнее, чем «обычное» индексирование, и индекс соответственно раздувается.
Для небольших индексов, 1-3 ГБ данных (которых вроде бы хватит для индексации чуть меньше, чем все торренты в мире), это еще терпимо.
Для индексов размером более 100 ГБ текста больше нет. Так вот в переговорах с неким клиентом выяснилось, что в таких коллекциях иногда нужен поиск подстроки.
Ну добавили новый словарь, что с ним делать.
Это включается директивой dict=ключевые слова в настройках индекса.
По сравнению с обычной (!) индексацией она медленнее примерно в 1,3 раза (по нашим внутренним тестам, YMMV и все такое).
Соответственно, по сравнению с индексацией префиксом или, того хуже, инфиксами, он летает в 3+ раза быстрее и занимает меньше места.
Кстати, по понятным причинам результирующий словарь (файл .
spi) существенно меньше, который по умолчанию полностью кэшируется в памяти.
Таким образом, он также потребляет меньше памяти.
За такое адское ускорение скорости индексации и экономию диска/памяти, конечно, приходится чем-то платить.
Теоретически должна пострадать скорость поиска, не более того.
Это связано с тем, что при использовании dict=keywords каждое ключевое слово «со звездочкой» автоматически расширяется внутри в большое, жирное ИЛИ всех слов, найденных в словаре для указанной маски слов.
Запрос более сложный и потребляет больше процессорного и дискового времени.
Чем больше слов соответствует маске ВАСЯ*, тем дольше мы будем искать Васю.
Однако на практике может оказаться, что новый словарь выходит быстрее.
Это потому, что если старый индекс абсолютно не помещался в память и каждый раз, когда я чихал, я шел неторопливо сидеть в iowait, читать диск, шуршать головками, сливать кеш и только после этого выходить из туалета системных вызовов, и новый индекс размещен (или, по крайней мере, гораздо лучше кэшируется), то новые «медленные» запросы к памяти все равно будут быстрее, чем старые «быстрые» запросы к диску.
Лучше десять раз за раз, чем десять раз вообще! Степень расширения, кстати, контролируется отдельной новой настройкой, расширение_предела .
По умолчанию сейчас 0, т.е.
ограничений нет. Если вы хотите, чтобы запросы типа A* не заменялись на ИЛИ из миллиона слов и не убивали демона насмерть, лучше установить какой-нибудь разумный экспансион_предел.
Если существует ограничение, при расширении будут взяты первые N наиболее часто встречающихся слов.
О строковых атрибутах Очереди у нас уже были, но мы мало что могли с ними сделать, был бардак.
Мы добавили поддержку ORDER BY и GROUP BY для строковых атрибутов, давно пора.
(Осталось только добавить WHERE, но если у вас есть поиск по словам, это не самая острая необходимость.
) Сортировка и группировка через SphinxAPI тоже работает. Поскольку строки не являются числами и сравниваются по-разному в зависимости от требований языка и/или чувствительности к регистру, нам пришлось добавить сопоставления , те.
на ваших пальцах разные функции сравнения строк.
Так как нам приходится вручную реализовывать кучу сопоставлений, то, честно говоря, лень, поэтому мы сделали минимальный джентльменский набор:binary, utf8_general_ci, libc_ci, libc_cs. Первые два сравнивают строки либо тупо побайтово, либо по «общим» (языковым и регистронезависимым) правилам UTF-8 соответственно.
Вторые два цинично используют libc и locale. Кстати, с удивлением обнаружил, что LOCALE=ru_RU.utf-8 не работает в 1х при запуске демона, плюс в 2х локали из коробки часто особо не устанавливаются.
Ну, мне пришлось приложить директиву collation_libc_locale для выбора локали при запуске демона, и изучения локали - команда и еще какой-то непонятный apt-get, ням.
О СфинксQL В предыдущих версиях SphinxQL по существу представлял собой очень легкую оболочку поверх «старой» поисковой системы, доступной через SphinxAPI. Из-за этого возникали разного рода остаточные явления: в любой набор результатов обязательно добавлялись столбцы id, Weight; при группировке добавлялись магические столбцы @group, считать ; Порядок атрибутов, явно запрошенных в SELECT, мог быть нарушен (тот, что в запросе, был заменен атрибутом в индексе).
Подобные явления противоречат стандарту SQL'92 и здравому смыслу, и было решено это исправить.
Запросы остаются теми же, но ответ другой: никаких дополнительных магических столбцов теперь не добавляется, все виды WEIGHT() и COUNT(*) теперь нужно запрашивать явно.
И порядок атрибутов теперь задается именно так, как запрошено, а не так, как выбрал индексатор при построении индекса.
Однако! Вы не можете внезапно (тм) изменить поведение и сломать существующие приложения; вам нужно дать возможность обновить приложение (а потом вдруг поменять и все сломать).
Благодаря этому появилась загадочная директива compat_sphinxql_magics , который по умолчанию равен 1 (дайте ответ «по-старому», с магическими столбцами), но в светлом будущем должен быть везде равен 0 (дайте ответ «по-новому», как завещал ANSI SQL) ).
При запуске демон выдает предупреждение о своем собственном значении по умолчанию.
Это символизирует необходимость двигаться в ногу с прогрессом, и так и задумано.
Список изменений (он довольно небольшой) находится в документации в специальные разделы об обновлении SphinxQL В принципе, все должно быть достаточно интуитивно понятно.
Наша цель — старый добрый SQL, хорошо всем известный.
Там, где раньше мы писали SELECT * FROM .
, теперь мы пишем SELECT *, WEIGHT() `weight` FROM., где раньше мы писали только GROUP BY, теперь мы явно пишем COUNT(*) myalias и обновляем приложение до перейти в столбец myalias и т. д. Новые пакеты Компилировать вручную скучно, поэтому постепенно учимся собирать официальные бинарные пакеты для разных платформ.
Релиз 2.0.1 уже скомпилирован для RH/Centos, Win32, MacOS. В планах и тестах (надеюсь в ближайшие 1-2 недели) также пакеты для Ubuntu и Win64. Тогда фантазия подводит и надо будет проводить опрос, для чего еще вам нужны официальные бинарники.
Всевозможные другие новые функции В формате «галопом по Европе» я коснусь и ряда других потенциально интересных вещей.
Мы сделали многопоточную и распределенную конструкцию пакета сниппетов, на тот случай, когда их нужно быстро собрать из больших документов, лежащих на сервере.
Включается, если на сервере есть dist_threads, load_files в запросе сниппетов, и пока работает только через API. Сделал поддержку UDF. Вы можете писать функции на C, на лету подключать их к серверу и использовать в вычислениях выражений (см.
SELECT).
Интерфейс очень похож на MySQL, хотя система типов другая.
Пересобрать UDF из MySQL под Sphinx — довольно тривиальная задача.
Мы создали новый формат журнала query_log_format=sphinxql. Все поисковые запросы (как через API, так и через QL) конвертируются в правильный синтаксис SphinxQL и пишутся, пишутся.
В отличие от обычного журнала, здесь фиксируются фильтры, выражения SELECT, ошибки и т. д. Удобно для отладки и профилирования.
Мы также собираемся завершить регистрацию всех непоисковых запросов (сниппетов и т. д.).
Мы создали директиву blend_mode для индексации последовательностей со смешанными символами в нескольких различных вариантах.
(Например, для индексации «слова» @sphinxsearch# нужно использовать все три варианта @sphinxsearch, sphinxsearch#, @sphinxsearch#, а не только последний.
) Мы сделали сторожевой таймер, чтобы в тред-режиме демон брал себя за волосы, если что.
Можно отключить.
Сделана поддержка загрузки индексов id32 в демоны id64. Мы всегда будем принудительно включать --enable-id64, мы готовимся здесь.
Мы сделали поддержку мультизапросов, UPDATE по атрибутам, DESCRIBE, SHOW TABLES, DELETE. WHERE id IN(.
) и всякие другие приятные мелочи в SphinxQL. Мы несколько раз оптимизировали английский стеммер; с morphology=stem_en индексация ускорилась примерно в 1,3 раза.
Оптимизировали сниппеты на больших и толстых файлах, вместе со стеммером получилось в 1,5, а то и в 2 раза быстрее.
Ну и баги пофиксили без счёта, конечно.
Чего (и когда) ожидать в версии 2.0.2 Мне очень хочется сломать порочную тенденцию выпускать релизы раз в год, а остальное время жить в багажнике.
Поэтому этим летом мы собираемся выпустить версию 2.0.2 с исправлениями ошибок дурака и поэтессы и небольшими новыми функциями.
Есть автоматические тесты, делаем автоматические сборки под всякие платформы.
Вот если бы кто-нибудь автоматически написал документацию, и тогда — ух ты.
Помимо всегда присутствующих задач «багов и скорости» (внесение ошибок и устранение скорости, ага), есть в краткосрочной перспективе ряд фич для RT (поддержка поиска подстрок, MVA, что-то еще), какие-то секретные работа над качеством поиска и т.д. .
"незначительные улучшения.
Что, кстати, нас плавно подводит. Как правильно кричать на ухо Функции в Sphinx обычно появляются четырьмя разными способами.
Во-первых, иногда они самопроизвольно порождаются из грязной одежды и горсти пшеницы, но в последние столетия (после отмены эфира и флогистона) это случалось крайне редко.
Во-вторых, иногда мы сами сидим и думаем: а не сделать ли нам такую фичу? А мы нет, конечно.
Мы думаем лучше и делаем что-то другое.
В-третьих, иногда приходит клиент и говорит: я очень хочу фичу, я даже готов платить деньги, вот насколько это ужасно.
Не всегда удается убедить клиента и побороть жадность; тебе придется это испортить.
4х, иногда приходят пользователи и пишут: почему ты еще не сделал фичу? Мы думаем: действительно, почему мы до сих пор не сделали фичу? Посидим, подумаем, покурим, и опять, конечно, не делаем.
Но мы закладываем это в план, а делаем потом! Вот, чтобы нужные появились тебе особенности, нам нужно говорить об этом громко, четко и периодически.
Для этого вы можете дважды воспользоваться баг-трекером.
Во-первых, туда следует размещать запросы на новые функции.
Во-вторых, вам необходимо подписаться на существующие запросы (Monitor Bug).
На главной странице баг трекер Существует незаметный список наиболее отслеживаемых ошибок.
Другого хорошего автоматизированного метода определения важности фич у нас пока нет, поэтому мы собираемся посмотреть там и соответственно просим вас «проголосовать» за фичи в этом баг-трекере.
Общий Сделанный куча функций И выпуск 2.0.1-бета .
В то же время о нем писали книга для начинающих и думаем о следующей книге для продвинутых ребят. Мы хотим победить злейшего врага (себя) и многое сделать в следующем выпуске, но побыстрее для разнообразия.
Можем ли мы сделать это? помогите всеми возможными способами .
Традиционно мы ждем каждого обратная связь и характерный вал обнаруженные ошибки .
Такие вот дела.
Теги: #сфинкс #сфинкс
-
Слишком Много Игр – Хорошо Или Плохо?
19 Oct, 24 -
Умный Город На Mobile World Congress 2014
19 Oct, 24 -
Обфускация Html В Один Байт?
19 Oct, 24 -
Контакт Вводит Ограничения
19 Oct, 24 -
Natural Geektimes: Делаем Пространство Чище
19 Oct, 24
