Мы тут дотестировали, собрали бинарные пакеты и выложили версию Sphinx 2.0.2-beta (это такой опен-сорсный поисковой сервер, использующийся на куче вебсайтов), запланировали на середину декабря (революционное изменение!) к выпуску Sphinx 2.0.3-release, а также усердно готовимся к (бесплатному) слету пользователей Сфинкса 04 декабря в Санкт-Петербурге. Зарегистрироваться на слет нужно по ссылке чуть выше, подать крутой доклад через нашу контактную форму, а ряд подробностей про те ~30 новых фичей и планы/сроки по ближайшим релизам и их циклу можно прочитать под катом.
Понятно, что большая часть из тех 30 фичей это скорее приятные мелочи. Ну там, новый флажок, включающий возможность реплея логов в ситуации, когда на сервере почему-то резко прыгнуло время, поддержка размазанных на всех кластер (а не скопированных на каждой машине) сниппетов, поддержка 256 текстовых полей (а не 32), и т.п. Но снова есть несколько штук, которые мы считаем сравнительно большими и важными в целом.
Приделали поддержку MVA64 атрибутов. «Классические» MVA это множество 32-битных беззнаковых значений, новые MVA64 это, соотв-но, множество 64-битных знаковых. Очевидных применений навскидку могу вспоминать два: а) ликвидировать возможность коллизий, если в MVA сохранялись CRC32 от строчек, б) сохранить туда всякие дополнительные данные, но я уверен, что вы найдете еще массу менее очевидных и более интересных применений. MVA64 поддерживаются и в дисковых, и RT индексах.
Кстати, MVA атрибуты теперь тоже поддерживаются в RT индексах, равно как index_exact_words. Вообще все ранее отсутствующие в RT возможности делаем вот помаленьку.
Сделали поддержку dict=keywords в RT индексах. Это означает, что теперь в RT индексах есть поиск по началам ключевых слов (word*). Ранее существовавшие в дисковых индексах директивы min_prefix_len, min_infix_len, которые заранее индексировали все возможные подстроки, мы решили специально не делать: это везде сильный удар по индексации, но в случае дисковых индексов это вдобавок удар по (сравнительно большому) диску, а в случае RT по драгоценной памяти, которой всегда не хватает. Если раздувать в разы требования к диску для поиска подстрок я еще как-то был согласен, то требования к памяти никак нет. Ну, вот с появлением dict=keywords и поиск подстрок возможен, и память цела.
Еще одна новая интересная штука это ATTACH INDEX. Оно сейчас позволяет взять набитый данными дисковый индекс, определить новый пустой RT индекс, и сконвертировать дисковый в RT. После чего данные из дискового индекса пропадают, зато появляются в RT, и далее можно спокойно с тем RT работать, как обычно. Довольно удобно для быстрого начального импорта большого объема данных, ну или для оперативного восстановления RT, если вдруг с ним (тьфу-тьфу-тьфу) произойдет какая беда: понятно, что переиндексировать дисковый индекс одним ударом куда быстрее, чем вставлять записи в RT по одной и даже по несколько штук. Физически операция выливается всего лишь в переименование файлов, поэтому очень быстрая. По факту, реализованную прямо сейчас функциональность (разовая конверсия) было бы правильнее назвать CONVERT. Но мы планируем развивать эту штуку дальше и сделать возможность вот так вот импортировать большие шматки данных в непустой RT индекс тоже. Поэтому сразу забили ключевое слово ATTACH, на будущее.
Оператор UPDATE теперь поддерживает более полноценные условия в WHERE. Стало можно делать запросы типа UPDATE myindex SET deleted=0 WHERE MATCH('test'), ну или там… WHERE vendor=123. Те. грохнуть тыщу записей по условию только что стало в тыщу раз проще. Как и ранее существоваший апдейт значения колонок по ID, этот новый UPDATE тоже работает и в обычных, и в дисковых индексах.
И, наконец, последняя в списке «большая» фича это возможность делать собственные формулы для расчета релевантости и задавать их на лету (expression based ranker). В предыдущих версиях варианты расчета релевантности, доступной через WEIGHT(), по существу сводились к выбору из нескольких заранее нами написанных ранкеров (PROXIMITY_BM25, SPH04, итп). Понятно, что после этого можно было засунуть WEIGHT() в выражения и подмешать к нему еще какие-то атрибуты документа, но повлиять на расчет самого WEIGHT() и иначе скомбинировать всякие факторы ранжирования, рассчитываемые не для всего документа, а для отдельных полей, было невозможно. Да и факторов было не так много.
Теперь можно. Формулу ранжирования можно задавать хоть для каждого отдельного запроса. Плюс доступных факторов ранжирования стало существенно больше. Все ранкеры новым «скриптуемым» ранкером успешно эмулируются. Примеры есть в документации, тут приведу один:
Что удивительно, оно работает куда быстрее, чем я ожидал. Я ожидал замедления до нескольких раз, по факту на небольшой тестовой коллекции в 1,000,000 блог-постов наблюдаю замедление от 1.1x до 1.3x раз — это по сравнению с вкомпилированным C++ кодом, который вдобавок считает куда меньше факторов. Считаю, достаточно неплохо.
Ветка 2.0.x теперь заморожена, новых фичей там более не будет, только багфиксы и регулярные релизы с этими самиыми багфиксами. Ближайший назначен через 1 месяц, далее после этого либо опять по часам с интервалом в 1-2 месяц (если накапливается достаточно исправлений), либо по мере накопления.
Все новые фичи отсюда будут складываться в транк, следующая версия 2.1.1. Для него дата релиза еще пока никак не запланирована. Но ряд фич уже находится в активной разработке, поэтому можно подразниться уже сейчас. Уже делаем поиск подстрок (*word*), а не только по началу слова (word*), с использованием dict=keywords. Возможно (возможно), сделаем вдобавок поддержку масок (wildcards) для этого же случая. Работаем над интересным улучшением для кластеров с кучей агентов, чтобы запросы им рассылались параллельно (сейчас это все еще сериализованно). Плюс ведутся секретные работы про вкручивание известной библиотечки и улучшения поддержки русской морфологии.
Фичи фичами, вдобавок к ним мы снова трясли внутренние процессы тестирования, сборки и выкатки релизов. Вроде дотрясли, поэтому следующая версия, 2.0.3-release будет выкачена не как обычно, «когда будет готово» — а по звонку, через 1 месяц, в середине декабря 2011. Если ваш начальник решительно не велит ставить версии без такого тега — вот, он будет через месяц.
Еще можно ему передать, что текущий тег это, на самом деле, не beta, а вовсе даже rc. В смысле, никаких известных больших и серьезных багов в 2.0.2-beta на момент релиза традиционно нет. Для ранее существующего функционала тестов традиционно стало только больше, соотв-но для «просто поиска» оно должно быть стабильнее, чем было. Поэтому, в принципе, его можно было бы назвать Release Candidate, но я решил не усложнять набор тегов.
Несколько новых фич мы таки опять приделали, а политика такая, что в этом случае тег Release задерживается до момента, пока вдобавок к нашему внутреннему тестированию версию не потестируют живые люди из коммьюнити. Так что берите новую версию, пробуйте, и обязательно пишите нам про баги, если вдруг нарветесь на какие.Утром в газете, вечером в интернете Утром в багтрекере, вечером в транке!
Подробнее и про все новое, и правильное использование старого, и, надеюсь, кучу других вещей в ближайшем будущем можно не только почитать в редких блог-постах, но и послушать живьем на конференции пользователей. Устраиваем второй раз, по-прежнему бесплатная (ничему не научил первый раз!!!), но теперь для разнообразия не Москва, а Санкт-Петербург, воскресенье, 04 декабря. Просьба к читателям регистрироваться максимально заранее, просьба к писателям не стесняться и засылать нам предложения про доклады и-или lightning talks.
Всем привет, до новых релизов и, надеюсь, живых встреч на конференции.
Про фичи
Понятно, что большая часть из тех 30 фичей это скорее приятные мелочи. Ну там, новый флажок, включающий возможность реплея логов в ситуации, когда на сервере почему-то резко прыгнуло время, поддержка размазанных на всех кластер (а не скопированных на каждой машине) сниппетов, поддержка 256 текстовых полей (а не 32), и т.п. Но снова есть несколько штук, которые мы считаем сравнительно большими и важными в целом.
Приделали поддержку MVA64 атрибутов. «Классические» MVA это множество 32-битных беззнаковых значений, новые MVA64 это, соотв-но, множество 64-битных знаковых. Очевидных применений навскидку могу вспоминать два: а) ликвидировать возможность коллизий, если в MVA сохранялись CRC32 от строчек, б) сохранить туда всякие дополнительные данные, но я уверен, что вы найдете еще массу менее очевидных и более интересных применений. MVA64 поддерживаются и в дисковых, и RT индексах.
Кстати, MVA атрибуты теперь тоже поддерживаются в RT индексах, равно как index_exact_words. Вообще все ранее отсутствующие в RT возможности делаем вот помаленьку.
Сделали поддержку dict=keywords в RT индексах. Это означает, что теперь в RT индексах есть поиск по началам ключевых слов (word*). Ранее существовавшие в дисковых индексах директивы min_prefix_len, min_infix_len, которые заранее индексировали все возможные подстроки, мы решили специально не делать: это везде сильный удар по индексации, но в случае дисковых индексов это вдобавок удар по (сравнительно большому) диску, а в случае RT по драгоценной памяти, которой всегда не хватает. Если раздувать в разы требования к диску для поиска подстрок я еще как-то был согласен, то требования к памяти никак нет. Ну, вот с появлением dict=keywords и поиск подстрок возможен, и память цела.
Еще одна новая интересная штука это ATTACH INDEX. Оно сейчас позволяет взять набитый данными дисковый индекс, определить новый пустой RT индекс, и сконвертировать дисковый в RT. После чего данные из дискового индекса пропадают, зато появляются в RT, и далее можно спокойно с тем RT работать, как обычно. Довольно удобно для быстрого начального импорта большого объема данных, ну или для оперативного восстановления RT, если вдруг с ним (тьфу-тьфу-тьфу) произойдет какая беда: понятно, что переиндексировать дисковый индекс одним ударом куда быстрее, чем вставлять записи в RT по одной и даже по несколько штук. Физически операция выливается всего лишь в переименование файлов, поэтому очень быстрая. По факту, реализованную прямо сейчас функциональность (разовая конверсия) было бы правильнее назвать CONVERT. Но мы планируем развивать эту штуку дальше и сделать возможность вот так вот импортировать большие шматки данных в непустой RT индекс тоже. Поэтому сразу забили ключевое слово ATTACH, на будущее.
Оператор UPDATE теперь поддерживает более полноценные условия в WHERE. Стало можно делать запросы типа UPDATE myindex SET deleted=0 WHERE MATCH('test'), ну или там… WHERE vendor=123. Те. грохнуть тыщу записей по условию только что стало в тыщу раз проще. Как и ранее существоваший апдейт значения колонок по ID, этот новый UPDATE тоже работает и в обычных, и в дисковых индексах.
И, наконец, последняя в списке «большая» фича это возможность делать собственные формулы для расчета релевантости и задавать их на лету (expression based ranker). В предыдущих версиях варианты расчета релевантности, доступной через WEIGHT(), по существу сводились к выбору из нескольких заранее нами написанных ранкеров (PROXIMITY_BM25, SPH04, итп). Понятно, что после этого можно было засунуть WEIGHT() в выражения и подмешать к нему еще какие-то атрибуты документа, но повлиять на расчет самого WEIGHT() и иначе скомбинировать всякие факторы ранжирования, рассчитываемые не для всего документа, а для отдельных полей, было невозможно. Да и факторов было не так много.
Теперь можно. Формулу ранжирования можно задавать хоть для каждого отдельного запроса. Плюс доступных факторов ранжирования стало существенно больше. Все ранкеры новым «скриптуемым» ранкером успешно эмулируются. Примеры есть в документации, тут приведу один:
$client->SetRankingMode(SPH_RANK_EXPR, "sum(lcs*user_weight)*1000+bm25");Что удивительно, оно работает куда быстрее, чем я ожидал. Я ожидал замедления до нескольких раз, по факту на небольшой тестовой коллекции в 1,000,000 блог-постов наблюдаю замедление от 1.1x до 1.3x раз — это по сравнению с вкомпилированным C++ кодом, который вдобавок считает куда меньше факторов. Считаю, достаточно неплохо.
Про планы разработки
Ветка 2.0.x теперь заморожена, новых фичей там более не будет, только багфиксы и регулярные релизы с этими самиыми багфиксами. Ближайший назначен через 1 месяц, далее после этого либо опять по часам с интервалом в 1-2 месяц (если накапливается достаточно исправлений), либо по мере накопления.
Все новые фичи отсюда будут складываться в транк, следующая версия 2.1.1. Для него дата релиза еще пока никак не запланирована. Но ряд фич уже находится в активной разработке, поэтому можно подразниться уже сейчас. Уже делаем поиск подстрок (*word*), а не только по началу слова (word*), с использованием dict=keywords. Возможно (возможно), сделаем вдобавок поддержку масок (wildcards) для этого же случая. Работаем над интересным улучшением для кластеров с кучей агентов, чтобы запросы им рассылались параллельно (сейчас это все еще сериализованно). Плюс ведутся секретные работы про вкручивание известной библиотечки и улучшения поддержки русской морфологии.
Про релизы
Фичи фичами, вдобавок к ним мы снова трясли внутренние процессы тестирования, сборки и выкатки релизов. Вроде дотрясли, поэтому следующая версия, 2.0.3-release будет выкачена не как обычно, «когда будет готово» — а по звонку, через 1 месяц, в середине декабря 2011. Если ваш начальник решительно не велит ставить версии без такого тега — вот, он будет через месяц.
Еще можно ему передать, что текущий тег это, на самом деле, не beta, а вовсе даже rc. В смысле, никаких известных больших и серьезных багов в 2.0.2-beta на момент релиза традиционно нет. Для ранее существующего функционала тестов традиционно стало только больше, соотв-но для «просто поиска» оно должно быть стабильнее, чем было. Поэтому, в принципе, его можно было бы назвать Release Candidate, но я решил не усложнять набор тегов.
Несколько новых фич мы таки опять приделали, а политика такая, что в этом случае тег Release задерживается до момента, пока вдобавок к нашему внутреннему тестированию версию не потестируют живые люди из коммьюнити. Так что берите новую версию, пробуйте, и обязательно пишите нам про баги, если вдруг нарветесь на какие.
Про конференцию
Подробнее и про все новое, и правильное использование старого, и, надеюсь, кучу других вещей в ближайшем будущем можно не только почитать в редких блог-постах, но и послушать живьем на конференции пользователей. Устраиваем второй раз, по-прежнему бесплатная (ничему не научил первый раз!!!), но теперь для разнообразия не Москва, а Санкт-Петербург, воскресенье, 04 декабря. Просьба к читателям регистрироваться максимально заранее, просьба к писателям не стесняться и засылать нам предложения про доклады и-или lightning talks.
Всем привет, до новых релизов и, надеюсь, живых встреч на конференции.