Комментарии 124
Отличное начало! Думаю, всё же стоит попробовать этот продукт.
Плюс один в карму за труды ;)
Плюс один в карму за труды ;)
Круто!
Да, интересно. Похоже сфинкс может делать полнотекстовый поиск по стемеру. Надо попробовать
спасибо! уже думаю, как бы это дело прикрутить...
а зачем тег mysql? там сорс не только из базы (и не только из mysql) можно тянуть, но и например xmlpipe :)
Апаю автора и топик!
Информация небесполезная.
Информация небесполезная.
спасибо, как раз поиск надо делать :)
Хотел поиграться с .NET + MSSQL но на странице загрузок видно что есть библиотека для Win32 только для MySQL, PostgreSQL...
а как на счет размером в районе 4-5 терабайт ??
справиться или проще свой написать ?
справиться или проще свой написать ?
Вот список особо крупных ресурсов, использующих Сфинкс. Возможно, справится =)
Это у тебя текста столько по которому надо что то искать ?
Сканируешь что то ? )
Сканируешь что то ? )
может просто много пишет
Слепым десятипальцевым методом Шахиджаняна.
Ну а как же еще-то?
Ну говорят, что у него появился конкурент - читалка мыслей
Ну до 2 териков скейлимся - думаю и 4-5 выдержим.
А чем это собственно лучше/хуже tsearch модуля в том же Postgres?
В tsearch нет поиска по фразам. Нам, например, уже этого хватило, что бы отбросить вариант применения tsearch в своем софте :(
Если не сложно, приведите примеры, как именно вы хотели искать в tsearch и не получилось? Зачастую, многие проблемы с ним все же удается решить после тщательного прочтения документации.
Я еще вчера хотел дать ссылку на описание проблемы, но мой сервер был недоступен :(
1: "Сегодня супер классная погода"
2: "Сегодня супер погода"
Запрос: "супер погода" вернет 2, но не вернет 1.
в данном случае ранк у матчей будет отличаться настолько, что вы сможете отсечь ненужные результаты. да, это не поиск по фразе, но лимитировать по расстоянию между словами в tsearch все же возможно.
2: "Сегодня супер погода"
Запрос: "супер погода" вернет 2, но не вернет 1.
в данном случае ранк у матчей будет отличаться настолько, что вы сможете отсечь ненужные результаты. да, это не поиск по фразе, но лимитировать по расстоянию между словами в tsearch все же возможно.
Плюс еще важно понимать, что ваши возможности с tsearch очень велики и вот почему. Он встроен в СУБД. Он работает очень быстро. Поэтому вы можете с его помощью сделать loose match по индексу, быстро вернув бОльшее кол-во результатов, чем вам нужно, а затем отобранные результаты обработать любым другим способом, добавив собственную эвристику произвольной сложности.
Это открывает удивительные возможности. Например, мало кто в опенсорс мире умеет делать нормальный быстрый suggest, потому что до недавнего времени префиксный поиск (то есть его индексная поддержка, разумеется) вообще не был нигде реализован (первыми, насколько мне известно, это опять сделали в tsearch-е, будет в след. релизе) шутка ли, поискать LIKE 'фраза%' по миллиону строк. Так вот, с помощью tsearch эта задача решается элементарно, используя упомянутый подход. Так что варианты есть всегда.
Это открывает удивительные возможности. Например, мало кто в опенсорс мире умеет делать нормальный быстрый suggest, потому что до недавнего времени префиксный поиск (то есть его индексная поддержка, разумеется) вообще не был нигде реализован (первыми, насколько мне известно, это опять сделали в tsearch-е, будет в след. релизе) шутка ли, поискать LIKE 'фраза%' по миллиону строк. Так вот, с помощью tsearch эта задача решается элементарно, используя упомянутый подход. Так что варианты есть всегда.
> Поэтому вы можете с его помощью сделать loose match по индексу, быстро вернув бОльшее кол-во результатов, чем вам нужно,
...и поиметь совершенно отвратительную производительность, если full-text запрос возвращает 10-100K совпадений, не говоря о миллионах.
Been there, done that, implemented attributes in Sphinx for this very reason.
...и поиметь совершенно отвратительную производительность, если full-text запрос возвращает 10-100K совпадений, не говоря о миллионах.
Been there, done that, implemented attributes in Sphinx for this very reason.
Для таких любопытных и практически важных :) случаев в tsearch есть gin_fuzzy_search_limit, который обрезает резалтсет на заданном уровне. Дело в том, что при низкой селективности пользователю в подавляющем большинстве случаев не важны уже даже десятки тысяч матчей. Или кто-то здесь мотает выдачу поисковиков по "стоп-слову" до десятитысячной страницы? :)
Но в целом вы правы и я не спорю у предложенного простого подхода есть ограничения. В некоторых случаях (на мой взгляд, они все же крайне редки) все же нужно анализировать гигантские резалтсеты. Но в tsearch и для них есть фишки, все зависит от задачи.
Но в целом вы правы и я не спорю у предложенного простого подхода есть ограничения. В некоторых случаях (на мой взгляд, они все же крайне редки) все же нужно анализировать гигантские резалтсеты. Но в tsearch и для них есть фишки, все зависит от задачи.
> Дело в том, что при низкой селективности пользователю в подавляющем большинстве случаев не важны уже даже десятки тысяч матчей.
Пользователю не нужны, факт.
Но это подмена понятий.
Поскольку обработать матчи-кандидаты все равно при этом нужно.
> Для таких любопытных и практически важных :)
Ирония неуместна.
Случай нередкий.
Ищем в базе пользователей на 10M человек тов. Иванова из Урюпинска.
Ивановых в базе 500K, Урюпинских 100K.
Ищем в базе на 20M предложений самый дешевый ipod nano в Москве.
Предложений ipod nano 20K, из них в Москве ровно половина, 10K.
Не обработаем хоть одно - рискуем показать неверный результат.
А в базе на 10K записей все отлично, факт.
Для нее не нужен Сфинкс.
Для нее прекрасно работают MySQL fulltext, tsearch, и даже LIKE '%keyword%'.
> в tsearch и для них есть фишки, все зависит от задачи.
С ваших слов, складывается впечатление, что tsearch умеет вообще все и вообще лучше всех.
Типа для всего есть "фишки", правда непонятно, какие ;)
Это очень круто, Sphinx не такой.
Впрочем, если фишки типа "будем резать result set", то можно спать спокойно ;)))
Пользователю не нужны, факт.
Но это подмена понятий.
Поскольку обработать матчи-кандидаты все равно при этом нужно.
> Для таких любопытных и практически важных :)
Ирония неуместна.
Случай нередкий.
Ищем в базе пользователей на 10M человек тов. Иванова из Урюпинска.
Ивановых в базе 500K, Урюпинских 100K.
Ищем в базе на 20M предложений самый дешевый ipod nano в Москве.
Предложений ipod nano 20K, из них в Москве ровно половина, 10K.
Не обработаем хоть одно - рискуем показать неверный результат.
А в базе на 10K записей все отлично, факт.
Для нее не нужен Сфинкс.
Для нее прекрасно работают MySQL fulltext, tsearch, и даже LIKE '%keyword%'.
> в tsearch и для них есть фишки, все зависит от задачи.
С ваших слов, складывается впечатление, что tsearch умеет вообще все и вообще лучше всех.
Типа для всего есть "фишки", правда непонятно, какие ;)
Это очень круто, Sphinx не такой.
Впрочем, если фишки типа "будем резать result set", то можно спать спокойно ;)))
Вы искажаете смысл моих слов. Про базы размером в 10К записей никто не говорит, они не интересны для рассмотрения. Также никто не говорит, что нужно всегда резать гигантские резалтсеты это не так. tsearch может и миллион записей вернуть. И если вам захочется их чем-то собственным обработать, у вас будут проблемы, да. Но такие же проблемы будут и в Сфинксе, если там вообще возможно добавлять произвольную логику в поиск.
Моя основная мысль проста и спорить с ней довольно глупо: tsearch встроен в мощную СУБД и поэтому вам вместе с его богатыми возможностями доступны еще и возможности СУБД. А это значит, что вы можете писать очень гибкие запросы и делать произвольные системы на основе полнотекстового поиска например, разграничивая полномочия пользователей на чтение документов, как кто-то здесь спрашивал в комментах.
Что касается тупого сравнения кто лучше, то давайте проведем бенчмарки :) Помнится, на РИТ-2007 цифирки о Sphinx разработчиков tsearch не очень впечатлили :) Ну а что касается функциональности то tsearch практически ни в чем не уступает тоже, даже во многом опережает. Давайте в отдельной дискуссии померяемся и поговорим про 100TB базы на tsearch? :)
Моя основная мысль проста и спорить с ней довольно глупо: tsearch встроен в мощную СУБД и поэтому вам вместе с его богатыми возможностями доступны еще и возможности СУБД. А это значит, что вы можете писать очень гибкие запросы и делать произвольные системы на основе полнотекстового поиска например, разграничивая полномочия пользователей на чтение документов, как кто-то здесь спрашивал в комментах.
Что касается тупого сравнения кто лучше, то давайте проведем бенчмарки :) Помнится, на РИТ-2007 цифирки о Sphinx разработчиков tsearch не очень впечатлили :) Ну а что касается функциональности то tsearch практически ни в чем не уступает тоже, даже во многом опережает. Давайте в отдельной дискуссии померяемся и поговорим про 100TB базы на tsearch? :)
> Вы искажаете смысл моих слов.
Это нормально.
Тк. вы начали заход с того, что искажете смысл моих.
Например, см. про придуманный вами "порог" в терабайт, которого нет.
Вижу, вы не можете внятно ответить, зачем вы его придумали.
> tsearch встроен в мощную СУБД и поэтому вам вместе с его богатыми возможностями доступны еще и возможности СУБД.
(зевает) А встраиваемый в MySQL клиент SphinxSE предоставляет возможность "встроить" результаты поиска в мощную СУБД MySQL и вместе с богатыми возможностями Сфинкса сделать доступными еще и возможность СУБД. А это значит... ну и т.д
> Моя основная мысль проста
Пока что все ваши комментарии действительно сводятся к одной простой мысли - tsearch умеет вообще всё, что нужно прогрессивному человечеству; не то, что этот ваш Sphinx.
Sphinx действительно умеет далеко не все, но когда вы начинаете расхваливать tsearch, противопоставляя его Sphinx во-1х и упоминая про всякое, что у нас отлично делается во-2х - это выглядит довольно странно.
Видимо, Бартунов вам больше друг, чем объективность.
Это нормально.
Тк. вы начали заход с того, что искажете смысл моих.
Например, см. про придуманный вами "порог" в терабайт, которого нет.
Вижу, вы не можете внятно ответить, зачем вы его придумали.
> tsearch встроен в мощную СУБД и поэтому вам вместе с его богатыми возможностями доступны еще и возможности СУБД.
(зевает) А встраиваемый в MySQL клиент SphinxSE предоставляет возможность "встроить" результаты поиска в мощную СУБД MySQL и вместе с богатыми возможностями Сфинкса сделать доступными еще и возможность СУБД. А это значит... ну и т.д
> Моя основная мысль проста
Пока что все ваши комментарии действительно сводятся к одной простой мысли - tsearch умеет вообще всё, что нужно прогрессивному человечеству; не то, что этот ваш Sphinx.
Sphinx действительно умеет далеко не все, но когда вы начинаете расхваливать tsearch, противопоставляя его Sphinx во-1х и упоминая про всякое, что у нас отлично делается во-2х - это выглядит довольно странно.
Видимо, Бартунов вам больше друг, чем объективность.
Извините, я не хотел выглядеть offensive. Я лично уважаю вас и вашу разработку, не так много действительно популярного софта пишется с участием российских разработчиков. Ну и, разумеется, tsearch умеет не все и ни в коем случае не является панацеей.
Барт мне больше объективность, чем друг все же :) За tsearch мне несколько обидно потому, что он объективно очень хорош, но с популярностью его зачастую незаслуженно обходят. Sphinx-у легче, связь с MySQL очень помогает, по моему мнению.
Кстати, если вы находитесь в Москве, приходите к нам на встречу PostgreSQL-сообщества, мы хотим устроить tutorial по настройке полнотекстового поиска для широкой публики. Там же и с бенчмарками можно разобраться. С вами было бы интересно лично побеседовать.
Ну а лист сравнения фич я бы все-таки сделал, чтобы пользователям было бы легче ориентироваться.
Барт мне больше объективность, чем друг все же :) За tsearch мне несколько обидно потому, что он объективно очень хорош, но с популярностью его зачастую незаслуженно обходят. Sphinx-у легче, связь с MySQL очень помогает, по моему мнению.
Кстати, если вы находитесь в Москве, приходите к нам на встречу PostgreSQL-сообщества, мы хотим устроить tutorial по настройке полнотекстового поиска для широкой публики. Там же и с бенчмарками можно разобраться. С вами было бы интересно лично побеседовать.
Ну а лист сравнения фич я бы все-таки сделал, чтобы пользователям было бы легче ориентироваться.
> Там же и с бенчмарками можно разобраться. С вами было бы интересно лично побеседовать.
Не в Москве, но регулярно бываю проездами.
Пишите почту, придумаем что-нибудь.
> Ну а лист сравнения фич я бы все-таки сделал,
Я разве возражаю? :)
Давайте попробуем сделать.
Авось, сумеем перейти от намекающих неправильное формулировов "а вот в XXX все хорошо с YYY" к конкретным словам "с фичой YYY в проекте XXX вот так, в ZZZ вот эдак"
Не в Москве, но регулярно бываю проездами.
Пишите почту, придумаем что-нибудь.
> Ну а лист сравнения фич я бы все-таки сделал,
Я разве возражаю? :)
Давайте попробуем сделать.
Авось, сумеем перейти от намекающих неправильное формулировов "а вот в XXX все хорошо с YYY" к конкретным словам "с фичой YYY в проекте XXX вот так, в ZZZ вот эдак"
Краткий список возможностей полнотекстового поиска в PostgreSQL из основного, что могу вспомнить на бегу
- 2 типа индексов: обобщенное поисковое дерево (быстрые апдейты, сравнительно медленные выборки) и обратный индекс (очень быстрые выборки, медленные апдейты)
- онлайн-обновление индекса без задержки
- морфология на основе Ispell (поддерживается множество языков)
- поддержка пользовательских словарей: стоп-слова, синонимы, тезаурус, словари регулярных выражений и др.
- онлайн-переписывание запросов (когда нет возможности переиндексировать все целиком)
- линейное масштабирование практически до произвольных масштабов (так как ранкинг локальный), известны production-инсталляции размером в 100 TB
- релевантность определяется с учетом расстояния между словами
- поддержка тегов внутри индекса (можно назначать разные веса заголовку и телу новости, например, или искать только по заголовкам внутри индекса)
- возможность highlight
- встроен в ядро СУБД, не нужно дополнительно инсталлировать, поэтому будет на хостингах
- индексная поддержка префиксного поиска 'abc%' и других LIKE-ов, например '%abc%'
- встроенные инструменты сбора статистики по индексу
- гибкая система конфигурации и управления порядком обработки запросов
- булевы выражения в полнотекстовых запросах, возможность сочетать полнотекстовые запросы с остальными возможностями СУБД
- 2 типа индексов: обобщенное поисковое дерево (быстрые апдейты, сравнительно медленные выборки) и обратный индекс (очень быстрые выборки, медленные апдейты)
- онлайн-обновление индекса без задержки
- морфология на основе Ispell (поддерживается множество языков)
- поддержка пользовательских словарей: стоп-слова, синонимы, тезаурус, словари регулярных выражений и др.
- онлайн-переписывание запросов (когда нет возможности переиндексировать все целиком)
- линейное масштабирование практически до произвольных масштабов (так как ранкинг локальный), известны production-инсталляции размером в 100 TB
- релевантность определяется с учетом расстояния между словами
- поддержка тегов внутри индекса (можно назначать разные веса заголовку и телу новости, например, или искать только по заголовкам внутри индекса)
- возможность highlight
- встроен в ядро СУБД, не нужно дополнительно инсталлировать, поэтому будет на хостингах
- индексная поддержка префиксного поиска 'abc%' и других LIKE-ов, например '%abc%'
- встроенные инструменты сбора статистики по индексу
- гибкая система конфигурации и управления порядком обработки запросов
- булевы выражения в полнотекстовых запросах, возможность сочетать полнотекстовые запросы с остальными возможностями СУБД
кстати, если атрибуты в Сфинкс это возможность добавить в запрос условия вроде and regionid = 1234 and price < 100, то тогда в tsearch это есть с самого начала, потому что это СУБД :) причем количество атрибутов неограничено, а типы данных и их индексная поддержка развита очень сильно, даже не имеет смысла сравнивать.
> в tsearch это есть с самого начала, потому что это СУБД :)
Атрибуты на стороне FT движка и на стороне общего вида СУБД это две большие разницы, увы. Иначе я бы просто не стал у себя делать атрибуты.
Забенчмаркайте боевой запрос, который возвращает 1M полнотекстовых матчей, с сортировкой по атрибуту. Всё станет наглядно.
Атрибуты на стороне FT движка и на стороне общего вида СУБД это две большие разницы, увы. Иначе я бы просто не стал у себя делать атрибуты.
Забенчмаркайте боевой запрос, который возвращает 1M полнотекстовых матчей, с сортировкой по атрибуту. Всё станет наглядно.
У меня такие цифры получаются quick & dirty если:
~10^6 строк в индексе, запрос возвращает 6*10^5 строк, сортировка по атрибуту. Все вместе на Xeon 2.4 (load average сервера от других процессов около 4 в этот момент) занимает 2300 мс, из которых индекс-скан ~200 мс, heap scan (из-за того, что индекс гистовый lossy) еще 700 мс, дальше quicksort-сортировка около 1200 мс. Но это не обратный индекс. С обратным будет быстрее. С сортировкой тоже можно что-то придумать.
У вас как?
~10^6 строк в индексе, запрос возвращает 6*10^5 строк, сортировка по атрибуту. Все вместе на Xeon 2.4 (load average сервера от других процессов около 4 в этот момент) занимает 2300 мс, из которых индекс-скан ~200 мс, heap scan (из-за того, что индекс гистовый lossy) еще 700 мс, дальше quicksort-сортировка около 1200 мс. Но это не обратный индекс. С обратным будет быстрее. С сортировкой тоже можно что-то придумать.
У вас как?
Z:\work\sphinx\rel098>bin\release\search -i lj -b the -s published,desc
Sphinx 0.9.8-release (r1371)
...
index 'lj': query 'the ': returned 1000 matches of 58129 total in 0.023 sec
Sphinx 0.9.8-release (r1371)
...
index 'lj': query 'the ': returned 1000 matches of 58129 total in 0.023 sec
каков размер индекса и сколько в нем позиций? мой запрос, кстати, не содержит лимита. с лимитом на 1000 мс быстрее. правильно я понимаю, что искалось слово 'the'? это же стоп-слово! плюс к тому, вы на порядок уменьшили result set это нечестно. 50 тыс. рядов у меня выбираются и сортируются с лимитом в 1000 за 150 мс. и это с медленным индексом. сейчас сделаю быстрый.
с обратным индексом и вашими параметрами (50 тыс. рядов, лимит 1000) выходит 52 мс. щас еще по-tweak-им и наскребем 23 мс :)
> вы на порядок уменьшили result set — это нечестно.
Блин, я тупо обсчитался. Непривычная нотация эти ваши 10^5, показалось, что 60K результатов, а не 600K. Вот пожалуйста -
Z:\work\sphinx\rel098>bin\release\search -i lj -b the -s published,desc
...
index 'lj': query 'the ': returned 1000 matches of 629132 total in 0.111 sec
Блин, я тупо обсчитался. Непривычная нотация эти ваши 10^5, показалось, что 60K результатов, а не 600K. Вот пожалуйста -
Z:\work\sphinx\rel098>bin\release\search -i lj -b the -s published,desc
...
index 'lj': query 'the ': returned 1000 matches of 629132 total in 0.111 sec
так а сколько всего документов в индексе? все же как-то странно у вас: один и тот же запрос, один и тот же индекс, а матчей разное количество. так разве бывает? :)
> так а сколько всего документов в индексе?
1M в этом - это не особо важно тк. производительность слабо зависит от числа документов в целом.
> все же как-то странно у вас: один и тот же запрос, один и тот же индекс, а матчей разное количество. так разве бывает? :)
Конечно бывает - это тестовый индекс и я его тупо перестраиваю с нужным количеством документов :) Это ж недолго ж совсем.
1M в этом - это не особо важно тк. производительность слабо зависит от числа документов в целом.
> все же как-то странно у вас: один и тот же запрос, один и тот же индекс, а матчей разное количество. так разве бывает? :)
Конечно бывает - это тестовый индекс и я его тупо перестраиваю с нужным количеством документов :) Это ж недолго ж совсем.
По моему пристрастному мнению постгресмена, tsearch лучше. Единственный существенный плюс сфинкса при сравнении он не связан с СУБД, в некоторых задачах это очень полезно.
да, кстати, tsearch легко масштабируется линейно до гигантских размеров, порога в несколько терабайт, как у Сфинкса, попросту нет. все дело в том, что функция релевантности у него локальна, поэтому полнотекстовый индекс можно побить на произвольное количество частей и разложить по нужному количеству машин. ну и с обратным индексом, который реализован в tsearch, по скорости выборки мало кто сравниться сможет. не знаю, правда, как с этим у Сфинкса.
> порога в несколько терабайт, как у Сфинкса, попросту нет.
Дяденька, про "порог" вы щаз сами придумали зачем-то.
Интересно, зачем?
2 TB это известная мне существущая БОЕВАЯ инсталляция, а не какой-то "порог".
Добавить побольше машин, будет урабатывать и побольше данных.
И эта - Сфинкс того, не менее успешно раскладывается на кучу машин.
Причем результаты умеет агрегировать сам - вопрос небольших изменений конфига.
> с обратным индексом, который реализован в tsearch,
Забенчмаркайте, опубликуйте результаты.
Мне несколько бежавших с tsearch человек сообщало, что Сфинкс таки быстрее.
Но конкретных цифр нет.
Дяденька, про "порог" вы щаз сами придумали зачем-то.
Интересно, зачем?
2 TB это известная мне существущая БОЕВАЯ инсталляция, а не какой-то "порог".
Добавить побольше машин, будет урабатывать и побольше данных.
И эта - Сфинкс того, не менее успешно раскладывается на кучу машин.
Причем результаты умеет агрегировать сам - вопрос небольших изменений конфига.
> с обратным индексом, который реализован в tsearch,
Забенчмаркайте, опубликуйте результаты.
Мне несколько бежавших с tsearch человек сообщало, что Сфинкс таки быстрее.
Но конкретных цифр нет.
Есть еще Яндекс.Сервер. Он гораздо лучше дружит с русским языком, чем большинство opensource-поисковиков, использующих лишь примитивные стеммеры.
Мы как раз выбирали движок для своей информационной системы и остановились на Яндексе и Сфинксе. Т.к. движет требуется распространять с базой, возникают проблемы с лицензией у Сфинкса :( А для сайтов можно юзать бесплатно. У Яндекса тоже есть непонятные места в лицензионном соглашении. Ищет он пожалуй получше на русском, но вот настройки там будут по-скромнее.
У Сфинкса же есть коммерческая лицензия
Я лично не вникал, но мне товарищ говорил, что там какие то бешеные условия. Вроде роялти минимум 100 долларов с каждой продажи. Повторю, сам лично не изучал их лицензии.
Ыыы. Там вообще-то условия "пишите, договоримся" - но видимо все читают только цифирь $100/copy и не читают всё, что вокруг нее написано. 8-)
Если нужно 10 лицензий для распространения в составе программно-аппаратного комплекса с ретейл ценой $15000 - да, ценник будет $100 за копию.
Если нужно 10000 копий для энциклопедии с ретейл ценой $10 - ценник будет куда меньше.
Если нужно 10 лицензий для распространения в составе программно-аппаратного комплекса с ретейл ценой $15000 - да, ценник будет $100 за копию.
Если нужно 10000 копий для энциклопедии с ретейл ценой $10 - ценник будет куда меньше.
Ну то, что все видят — это наверное от того, что так написано. Так что это это повод вам абзац этот как-то по-удачнее переписать.
А вообще, я завтра поговорю с сотрудниками, возможно попробуем "договориться" с вами :)
А вообще, я завтра поговорю с сотрудниками, возможно попробуем "договориться" с вами :)
Там написано, если дословно -
Final licensing price would depend on the application character, licensing volume, retail price, royalty policy, amount of required technical support, etc. Guideline price for small-volume (5-20 copies) royalty-free licensing is $100/copy.
Формально написано именно то, что я написал тут выше - соотв-но ценник $100/copy приведен скорее в порядке примера (см. guideline).
Но я согласен, что формулировка недостаточно четкая - глаз читатющего явно цепляется за $100/copy, мысль останавливается, написать мне письмо и уточнить уже сразу страшно :-) Изменю формулировку, да.
Final licensing price would depend on the application character, licensing volume, retail price, royalty policy, amount of required technical support, etc. Guideline price for small-volume (5-20 copies) royalty-free licensing is $100/copy.
Формально написано именно то, что я написал тут выше - соотв-но ценник $100/copy приведен скорее в порядке примера (см. guideline).
Но я согласен, что формулировка недостаточно четкая - глаз читатющего явно цепляется за $100/copy, мысль останавливается, написать мне письмо и уточнить уже сразу страшно :-) Изменю формулировку, да.
В PostgreSQL используется не только примитивный стеммер, но и морфология русского и других языков, словари синонимов и тезауруса (в том числе пользовательские), и куча других полезных фишек, с помощью которых поиск можно довести до идеального. Конечно, это не яндексовые технологии, но это отличный вариант, причем бесплатный и с открытым кодом.
> не только примитивный стеммер, но и морфология русского и других языков,
Ссылку можно?
По которой описывается подробнее, что это за морфология эдакая волшебная?
Потому что Гугл по запросу "tsearch2 morphology" находит токма - "Tsearch uses the dictionary words for morphology"
> словари синонимов и тезауруса (в том числе пользовательские),
Ну, эта.
Словари опять же отлично есть и в Сфинксе.
Можно для нормализации словоформ пользовать, можно для организации тезаурусов.
Можно скрещивать со стеммерами, для неизвестных словоформ.
И успешно используют.
Только мне наглости не хватает утверждать, что с их помощью можно сделать "идеальный" поиск ;)
Даром, что тоже бесплатный, и тоже с открытым кодом ;))
Ссылку можно?
По которой описывается подробнее, что это за морфология эдакая волшебная?
Потому что Гугл по запросу "tsearch2 morphology" находит токма - "Tsearch uses the dictionary words for morphology"
> словари синонимов и тезауруса (в том числе пользовательские),
Ну, эта.
Словари опять же отлично есть и в Сфинксе.
Можно для нормализации словоформ пользовать, можно для организации тезаурусов.
Можно скрещивать со стеммерами, для неизвестных словоформ.
И успешно используют.
Только мне наглости не хватает утверждать, что с их помощью можно сделать "идеальный" поиск ;)
Даром, что тоже бесплатный, и тоже с открытым кодом ;))
Автор прошу подробнее описать API, и все связанное с этим поисковиком. Буду благодарен. Спасибо и за эту статью.
Lucene уже не в моде?
НЛО прилетело и опубликовало эту надпись здесь
Маловато инфы про установку. Не совсем понятны требования к установке и кому он подойдет.
Скажем у меня хостинг за 3 доллара в месяц, PHP + MySQL, 200 Мб дискового пространства - он мне подойдет?
Скажем у меня хостинг за 3 доллара в месяц, PHP + MySQL, 200 Мб дискового пространства - он мне подойдет?
Надо как минимум SSH-доступ. А возможно, и некоторые превилегии, которых на shared нет. Надо уточнять это в мануале.
Надо ssh, gcc, пакет libmysqlclient-dev(кажется так), ну и за 3 бакса в месяц, вряд ли вам дадут столько ресурсов, чтобы это все нормально работало, хоть сфинкс и не особо прожорлив. На маленьких сайтах (200мб текста - это все-таки мало) хорошо будут работать вещи и попроще. Посмотрите на http://webscript.ru
Кстати, для сфинкса есть Perl обертка, http://search.cpan.org/~jjschutz/Sphinx-Search-0.11/lib/Sphinx/Search.pm, эквивалентная php-шной.
По поводу поддержки русского - да, похоже, только на уровне стеммера.
Радует, что стеммер у сфинкса, кроме английского, есть только для русского (может кто из разработчиков русский).
В принципе, стеммера на многое хватает. Сейчас юзаю LinguaStem, неплохо.
Более полная поддержка русского кроме яндекс сервера есть в нескольких коммерческих проектах.
По поводу поддержки русского - да, похоже, только на уровне стеммера.
Радует, что стеммер у сфинкса, кроме английского, есть только для русского (может кто из разработчиков русский).
В принципе, стеммера на многое хватает. Сейчас юзаю LinguaStem, неплохо.
Более полная поддержка русского кроме яндекс сервера есть в нескольких коммерческих проектах.
Сфинкс - это русский продукт =) разработчик - хабраюзер 
shodan
shodan
хех, да они все там русские )))
"Sphinx - созданный в России бесплатный поисковой движок с открытым кодом"
http://habrahabr.ru/blog/webdev/46689.html
"Sphinx - созданный в России бесплатный поисковой движок с открытым кодом"
http://habrahabr.ru/blog/webdev/46689.html
Еще есть движок поисковика nutch. Умеет работать в кластере, можно прикрутить русскую морфологию
Еще одна публикация о сфинксе на русском -
www.ibm.com/developerworks/ru/library/os-php-sphinxsearch
www.ibm.com/developerworks/ru/library/os-php-sphinxsearch
переиндексировать нужно все индексы
Наверное, «источники»?..
Наверное, «источники»?..
НЛО прилетело и опубликовало эту надпись здесь
Вопрос: можно ли с помощью сфинкса организовать поиск по документам системы с учётом прав пользователей: т.е. для одного пользователя - один набор документов, для другого пользователя - другой, и поиск осуществлять только в наборе документов, доступных для чтения данному юзеру?
Или может в tsearch2 (postgres) можно?
Или может в tsearch2 (postgres) можно?
Так как tsearch2 встроен в СУБД, вы можете в полнотекстовый запрос добавлять любые условия, в том числе на проверку прав пользователя читать соответствующий документ. То есть в постгресе это все делается и очень легко.
> поиск осуществлять только в наборе документов, доступных для чтения данному юзеру?
Можно - причем есть несколько механизмов.
Можно сохранить информацию о доступе в атрибуты, можно передавать извне, итд итп.
Можно - причем есть несколько механизмов.
Можно сохранить информацию о доступе в атрибуты, можно передавать извне, итд итп.
Спасибо большое за ответ. Написано ли об этом что-нибудь конкретно в документации? Или к этому можно прийти, только полностью изучив систему и все её фишки? Если дадите какую-нибудь конкретную ссылку, буду очень благодарен.
P.S.: Я не ленивый, просто нет времени, чтобы тратить его на полное изучение документации инструмента, пока я не уверен, что он с большой вероятностью мне подойдёт :)
P.S.: Я не ленивый, просто нет времени, чтобы тратить его на полное изучение документации инструмента, пока я не уверен, что он с большой вероятностью мне подойдёт :)
> Написано ли об этом что-нибудь конкретно в документации?
Вообще зависит от деталей задачи - насколько динамично меняются права, как конкретно организована система прав, насколько большие FT result set итп.
Для начала см. про атрибуты и фильтрацию http://sphinxsearch.com/doc.html#api-fun… - для несложных случаев этого может хватить - скажем сохраняем какую-нибудь группу документов в атрибут и передаем набор доступных пользователю групп фильтром.
Вообще зависит от деталей задачи - насколько динамично меняются права, как конкретно организована система прав, насколько большие FT result set итп.
Для начала см. про атрибуты и фильтрацию http://sphinxsearch.com/doc.html#api-fun… - для несложных случаев этого может хватить - скажем сохраняем какую-нибудь группу документов в атрибут и передаем набор доступных пользователю групп фильтром.
Интересно, когда на shared-хостингах появится возможность индексировать свою базу через такие локальные поисковики?..
Xapian (xapian.org) умеет и всё то что умеет sphinx и еще много всего и работает с очень большими базами быстрее, так же индексирует всё, и pdf и djvu и т.д., при этом быстрее Люцены
> Xapian (xapian.org) умеет и всё то что умеет sphinx и еще много всего
;) Это, мягко говоря, неправда.
Учет позиций слов при ранжировании - в Xapian отсутствует.
Распределенный поиск - в Xapian отсутствует.
Поддержка атрибутов - в Xapian отсутствует.
Это то, что видно с ходу.
> и работает с очень большими базами быстрее,
Покажите результаты бенчмарков?
Мне опять-таки давно интересно, но времени нету.
;) Это, мягко говоря, неправда.
Учет позиций слов при ранжировании - в Xapian отсутствует.
Распределенный поиск - в Xapian отсутствует.
Поддержка атрибутов - в Xapian отсутствует.
Это то, что видно с ходу.
> и работает с очень большими базами быстрее,
Покажите результаты бенчмарков?
Мне опять-таки давно интересно, но времени нету.
в чем подразумевается учет позиций при ранжировании? на больших базах xapian ищет быстрее Люцены.
Распределенный поиск что в вашем понимании?
Поддержка атрибутов это site:habrahabr AND sphinx ? Поддерживает уже давно всё, omega всё это умеет.
бенчмарки где-то были, в mailing lists точно были.
Распределенный поиск что в вашем понимании?
Поддержка атрибутов это site:habrahabr AND sphinx ? Поддерживает уже давно всё, omega всё это умеет.
бенчмарки где-то были, в mailing lists точно были.
> в чем подразумевается учет позиций при ранжировании?
Я хочу, чтобы документ с точным совпадением с запросом - был отранжирован выше всех.
Чтобы документ с частичным совпадением фразы - было отранжирован выше документов, где все слова случайно раскиданы по документу. Даже если вхождений каждого слова (усилиями спаммеров) очень много.
Можно такое?
> на больших базах xapian ищет быстрее Люцены.
Ваша исходная формулировка - "умеет все что sphinx ... и работает быстрее"
Извините, почему-то не догадался сразу, что речь была про lucene!!!
> Распределенный поиск что в вашем понимании?
Возможность разбить коллекцию на несколько машин и параллельно искать на каждой.
Затем агрегировать результаты.
Я краем глаза глянул в исходники, и этого не увидел.
Увидел страшное, похожее на доступ к данным удаленного индекса по сети... :)
> Поддержка атрибутов это site:habrahabr AND sphinx ?
Нет, это price>=100 and price<=200 and regionid=1234 and (1,3,5,7) in tags and fulltext-match('sphinx xapian benchmark')
В исходниках увидел только range и только по строкам.
Но, правда, смотрел пока невнимательно.
> бенчмарки где-то были, в mailing lists точно были.
Можете несколько уточнить ссылку? ;)
Я хочу, чтобы документ с точным совпадением с запросом - был отранжирован выше всех.
Чтобы документ с частичным совпадением фразы - было отранжирован выше документов, где все слова случайно раскиданы по документу. Даже если вхождений каждого слова (усилиями спаммеров) очень много.
Можно такое?
> на больших базах xapian ищет быстрее Люцены.
Ваша исходная формулировка - "умеет все что sphinx ... и работает быстрее"
Извините, почему-то не догадался сразу, что речь была про lucene!!!
> Распределенный поиск что в вашем понимании?
Возможность разбить коллекцию на несколько машин и параллельно искать на каждой.
Затем агрегировать результаты.
Я краем глаза глянул в исходники, и этого не увидел.
Увидел страшное, похожее на доступ к данным удаленного индекса по сети... :)
> Поддержка атрибутов это site:habrahabr AND sphinx ?
Нет, это price>=100 and price<=200 and regionid=1234 and (1,3,5,7) in tags and fulltext-match('sphinx xapian benchmark')
В исходниках увидел только range и только по строкам.
Но, правда, смотрел пока невнимательно.
> бенчмарки где-то были, в mailing lists точно были.
Можете несколько уточнить ссылку? ;)
value сейчас доделываются, есть даты, числа, > работает вроде, мне пока не нужно было, может и нету.
Удаленное подключение это поиск удаленно, оно данные не передает по которым надо искать)
а ранжирование это стандартное ранжирование, точное совпадение, близжайшее совпадение, вроде такое же ранжирование у всех по умолчанию.. и вес каждому полю тоже задается и выводится соответствующе в каком поле найдено и т.д.
Удаленное подключение это поиск удаленно, оно данные не передает по которым надо искать)
а ранжирование это стандартное ранжирование, точное совпадение, близжайшее совпадение, вроде такое же ранжирование у всех по умолчанию.. и вес каждому полю тоже задается и выводится соответствующе в каком поле найдено и т.д.
> value сейчас доделываются, есть даты, числа,
Я не сумел сходу найти в документации. Подскажите, куда копать?
> Удаленное подключение это поиск удаленно, оно данные не передает по которым надо искать)
Опять же, куда копать в документации?
В исходниках (backends/remote) я с наскоку нашел всякие class NetworkTermList/NetworkPostList, сразу стало страшно ;)
> а ранжирование это стандартное ранжирование,
В документации написано про BM25.
Это как раз которое не учитывет позиции слов совсем.
Я не сумел сходу найти в документации. Подскажите, куда копать?
> Удаленное подключение это поиск удаленно, оно данные не передает по которым надо искать)
Опять же, куда копать в документации?
В исходниках (backends/remote) я с наскоку нашел всякие class NetworkTermList/NetworkPostList, сразу стало страшно ;)
> а ранжирование это стандартное ранжирование,
В документации написано про BM25.
Это как раз которое не учитывет позиции слов совсем.
сортировка: http://xapian.org/docs/sorting.html , можно добавить свою схему, даже в рассылках были разные варианты от Olly.
удаленный доступ - http://xapian.org/docs/remote.html
диапазоны стандартные - http://xapian.org/docs/valueranges.html
лично я пользуюсь омегой, потому что привык и там многое уже сделано, а велосипеды это не моё...
http://xapian.org/docs/omega/overview.html
а вообще я не говорю что Сфинкс плохой, ему есть еще куда расти;)
удаленный доступ - http://xapian.org/docs/remote.html
диапазоны стандартные - http://xapian.org/docs/valueranges.html
лично я пользуюсь омегой, потому что привык и там многое уже сделано, а велосипеды это не моё...
http://xapian.org/docs/omega/overview.html
а вообще я не говорю что Сфинкс плохой, ему есть еще куда расти;)
> http://xapian.org/docs/sorting.html
Ага, вижу секцию про Values, спасибо.
> удаленный доступ - http://xapian.org/docs/remote.html
Это я нашел.
Но пока не нашел ни описания, как оно работает - ни кода, который таскал бы по сети именно результаты поиска, а не сами списки документов и позиций. Надо копать глубже..
> а вообще я не говорю что Сфинкс плохой, ему есть еще куда расти;)
Я процитирую дословно:
"Xapian (xapian.org) умеет и всё то что умеет sphinx и еще много всего"
Это категорически неправда.
Есть штуки, которые умеет Sphinx, но не умеет Xapian.
И наоборот, есть штуки, которые умеет Xapian, и не умеет Sphinx.
Разное они умеют, просто разное.
Ага, вижу секцию про Values, спасибо.
> удаленный доступ - http://xapian.org/docs/remote.html
Это я нашел.
Но пока не нашел ни описания, как оно работает - ни кода, который таскал бы по сети именно результаты поиска, а не сами списки документов и позиций. Надо копать глубже..
> а вообще я не говорю что Сфинкс плохой, ему есть еще куда расти;)
Я процитирую дословно:
"Xapian (xapian.org) умеет и всё то что умеет sphinx и еще много всего"
Это категорически неправда.
Есть штуки, которые умеет Sphinx, но не умеет Xapian.
И наоборот, есть штуки, которые умеет Xapian, и не умеет Sphinx.
Разное они умеют, просто разное.
У меня сложней ситуация, как быть?
CMS хранит записи в таблицах вида cms_table.
Есть каталог продукции, который выгружается из 1С, catalog. Т.е. поиск надо осуществлять по 2м разным структурам, а на выходе получать вместе.
Описание продукции хранится в файлах txt, вида 12345.txt, где 12345 значение поля в таблице catalog, соответствующее определенному артикулу.
Как поступить в этом случае?
CMS хранит записи в таблицах вида cms_table.
Есть каталог продукции, который выгружается из 1С, catalog. Т.е. поиск надо осуществлять по 2м разным структурам, а на выходе получать вместе.
Описание продукции хранится в файлах txt, вида 12345.txt, где 12345 значение поля в таблице catalog, соответствующее определенному артикулу.
Как поступить в этом случае?
Как-то преобразовать данные, чтобы сфинксу удобно было ими пользоваться. Это большие накладные расходы, но деваться некуда.
Преобразовать = скриптом засунуть в базу?
Ну либо так, либо на лету преобразовывать файлы и базу в какую-то xmlструктуру и выдавать её сфинксу как источник xmlpipe
Подробнее про xmlpipe
Подробнее про xmlpipe
Но почему именно Sphinx? Есть же ещё Lucene и выросшие из него Solr и Nutch. Это если говорить только о бесплатный поисковых системах. Потом есть бесплатные версии Я.Сервера (http://company.yandex.ru/technology/server/ ), есть IBM OnmiFind Yahoo! Edition (http://omnifind.ibm.yahoo.net/ ).
И вообще по-моему прекрасный источник информации о таких вещах - Yahoo Group Search_Dev http://tech.groups.yahoo.com/group/search_dev/ . Правда в ней нет особого акцента на открытые поисковые системы, и может быть слишком внимания там отдаётся Autonomy.
А для того чтобы понять что вообще существует на этом рынке по-моему очень интересно почитать отчёт Gartner по Information Access Techologies (http://mediaproducts.gartner.com/reprints/microsoft/vol6/article4/article4.html )
И вообще по-моему прекрасный источник информации о таких вещах - Yahoo Group Search_Dev http://tech.groups.yahoo.com/group/search_dev/ . Правда в ней нет особого акцента на открытые поисковые системы, и может быть слишком внимания там отдаётся Autonomy.
А для того чтобы понять что вообще существует на этом рынке по-моему очень интересно почитать отчёт Gartner по Information Access Techologies (http://mediaproducts.gartner.com/reprints/microsoft/vol6/article4/article4.html )
> Но почему именно Sphinx? Есть же ещё
Есть много чего еще.
Каждый волен выбирать наиболее удобный инструмент под свою задачу.
Сфинкс, очевидно, не серебряная пуля и (пока) не по всем параметрам лучше всех.
Мы над этим работаем ;)
Есть много чего еще.
Каждый волен выбирать наиболее удобный инструмент под свою задачу.
Сфинкс, очевидно, не серебряная пуля и (пока) не по всем параметрам лучше всех.
Мы над этим работаем ;)
Кстати, по следам Вашего поста я понял, что мне интересно будет написать или перевести обзор бесплатных и может быть части платных enterprise search. Потому, что как-то очень мало об этом на Хабре пишется.
Так что ждите :)
И успехов Вам со Сфинксом!
Так что ждите :)
И успехов Вам со Сфинксом!
> мне интересно будет написать или перевести обзор бесплатных
(вздыхает)
Нет бы забенчмаркать!
Могу поучаствовать в части про Сфинкс.
Чисто во избежание :)
(вздыхает)
Нет бы забенчмаркать!
Могу поучаствовать в части про Сфинкс.
Чисто во избежание :)
Забенчмаркить как следует я могу только, увы, Fast ESP (http://www.fast.no ) потому, что работаю с ней каждый день :) И что-то мне подсказывает, что она будет сильна (но может быть это просто любовь к приложению, с которым работаешь :) ).
Остальное может занять слишком много времени, но посмотрим.
Про Сфинкс: Ок, как только появятся какие-то намётки - я скажу.
Остальное может занять слишком много времени, но посмотрим.
Про Сфинкс: Ок, как только появятся какие-то намётки - я скажу.
давайте забенчмаркаем с tsearch, интересно все-таки. у меня под рукой сейчас есть небольшой 200MB индекс (прямой, обратный будет быстрее, очевидно) где-то на 10^6 документов на нескольких машинах (могу подобрать соответствующую). русский язык (испелл), несколько тезаурусных словарей на n*10^3 записей. вы можете подобрать что-то похожее у себя?
хотя наверное совсем правильно было бы использовать совершенно одинаковые данные, что сложнее организовать.
Вообще я имел в виду - поучаствовать в написании сравнительного анализа. ;) Во избежание всяких неожиданных выводов.
Бенчмаркать, кстати, более интересно не махонькие базы по 200 мег, а что-нибудь что таки не влезает в память целиком.
Бенчмаркать, кстати, более интересно не махонькие базы по 200 мег, а что-нибудь что таки не влезает в память целиком.
Я предлагаю взять последний дамп русской википедии: http://download.wikimedia.org/ruwiki/latest/ (ruwiki-latest-pages-articles.xml.bz2). Это примерно 370 Мб архивированного XML, я думаю, что 2-3 гигабайта XML данных на выходе вполне может получиться.
Ну или взять английскую версию, в которой только архив весит 3,7 Gb.
Ну или взять английскую версию, в которой только архив весит 3,7 Gb.
Английская годится вполне.
Только надо бы всю wiki разметку грохнуть, а это долгий и нудный препроцесс.
В общем, первый этап, это сделать SQL дамп с вики без разметки.
Я пытался когда-то, но почему-то не доделал.
И, кстати, может ужо заведем список рассылки и туда?
В комментариях на хабре, мнэээ, не самое удобное место для общения.
(Ненавижу, censored, деревянную структуру.)
Только надо бы всю wiki разметку грохнуть, а это долгий и нудный препроцесс.
В общем, первый этап, это сделать SQL дамп с вики без разметки.
Я пытался когда-то, но почему-то не доделал.
И, кстати, может ужо заведем список рассылки и туда?
В комментариях на хабре, мнэээ, не самое удобное место для общения.
(Ненавижу, censored, деревянную структуру.)
бенчмаркать лучше не гигантские базы, которых у пользователей никогда не будет, а более-менее реалистичные объемы. иначе интерес будет чисто академический. поэтому русская википедия мне кажется более интересной в этом отношении.
> бенчмаркать лучше не гигантские базы, которых у пользователей никогда не будет,
:)) Эта, у моих пользователей гигабайты в среднем как раз далеко не редкость.
Иначе скорее всего успешно работает что-нибудь другое, и нужды мигрировать на Сфинкс никакой.
Поэтому сильно интереснее бенчмаркать 10 гигабайт, чем 10 мегабайт.
:)) Эта, у моих пользователей гигабайты в среднем как раз далеко не редкость.
Иначе скорее всего успешно работает что-нибудь другое, и нужды мигрировать на Сфинкс никакой.
Поэтому сильно интереснее бенчмаркать 10 гигабайт, чем 10 мегабайт.
какой вы упрямый :) у моих пользователей тоже десятки гигабайт не редкость. но бенчмарк нужен не для моих или ваших пользователей, они с существующего решения не слезут. он нужен для пользователей, которые сомневаются и хотят обосновано выбрать. а у 95% таких база влезает в RAM относительно недорогого сервера. поэтому нескольких гигабайт русской википедии за глаза хватит. давайте лучше придумаем, как сделать дамп, пригодный для вставки во все СУБД.
> какой вы упрямый :)
Отчего же? Переубедить меня легко - только надо сначала правильно понять, а затем убедительно продемонстрировать неправоту! :)
> но бенчмарк нужен не для моих или ваших пользователей, ... он нужен для пользователей, которые сомневаются и хотят обосновано выбрать
Так точно. Именно поэтому нет смысла бенчмаркать махонькие базы.
На мелких объемах (см. 100K записей, 10M данных) - плевать на бенчмарки! Важна будет только функциональность. Потому что *любая* система покажет приемлемую скорость. Тем самым 95% плевать, за 1 ms или 100 ms будет работать поиск по 100K rows, если он работает как надо.
Бенчмарки нужны - когда начинаются вопросы по скорости, а они начинаются - когда данных много.
Поэтому мне интересно бенчмаркать 10 гигабайт, но совсем неинтересно 10 мегабайт.
Отчего же? Переубедить меня легко - только надо сначала правильно понять, а затем убедительно продемонстрировать неправоту! :)
> но бенчмарк нужен не для моих или ваших пользователей, ... он нужен для пользователей, которые сомневаются и хотят обосновано выбрать
Так точно. Именно поэтому нет смысла бенчмаркать махонькие базы.
На мелких объемах (см. 100K записей, 10M данных) - плевать на бенчмарки! Важна будет только функциональность. Потому что *любая* система покажет приемлемую скорость. Тем самым 95% плевать, за 1 ms или 100 ms будет работать поиск по 100K rows, если он работает как надо.
Бенчмарки нужны - когда начинаются вопросы по скорости, а они начинаются - когда данных много.
Поэтому мне интересно бенчмаркать 10 гигабайт, но совсем неинтересно 10 мегабайт.
Как потенциальный пользователь ;-) скажу, что лучше бенчмаркать и то и другое, а уж пользователи из всех сделанных бенчмарков будут смотреть те, которые ближе всего к их ситуации. При этом, по моему мнению, начинать надо с объёмов не в десятки, а в сотни мегабайт.
Вот за эту статью спасибо. Как раз хотел попробовать Сфинкс на одном из проектов (в связи с выходом его новой версии), теперь граблей будет меньше.
Паша! Поздравляю! Отличный первый пост, побольше-бы таких! :-)
Мало того, что ты мега-программист, так ещё и пишешь хорошо.
Кто-бы мог знать о таких талантах в тебе? :)
ps Я работаю с этим хабрачеловеком. Сам себе завидую :-)
Мало того, что ты мега-программист, так ещё и пишешь хорошо.
Кто-бы мог знать о таких талантах в тебе? :)
ps Я работаю с этим хабрачеловеком. Сам себе завидую :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поиск — это просто