Комментарии 50
А где пулл реквест от вас в оригинальный django-сфинкс?
+9
Еще как альтернатива github.com/linkedin/indextank-engine & github.com/linkedin/indextank-service Linked in недавно открыли их исходный код.
Сам же пользуюсь django-haystack(из мастера на github — он сильно отличается от стабильных) + solr.
Сам же пользуюсь django-haystack(из мастера на github — он сильно отличается от стабильных) + solr.
0
Вернее сильно отличается от зарелизенных версий)
Вот кстати еще github.com/flaptor/indextank-py
я пока их особо не смотрел, хотелось бы послушать мнения по поводу Indextank.
Вот кстати еще github.com/flaptor/indextank-py
я пока их особо не смотрел, хотелось бы послушать мнения по поводу Indextank.
0
Забыл эту ссылочку еще github.com/flaptor/django-indextank-py-demo
0
В solr хорошо с русскоязычным поиском? Я так понял поддержка стемминга на русском там заявлена.
0
НЛО прилетело и опубликовало эту надпись здесь
Solr на джаве, джава — тяжела. Например для VPS
0
НЛО прилетело и опубликовало эту надпись здесь
То есть вы предполагаете, что Solr может потреблять меньше памяти, чем Сфинкс? Именно память на VPSе самый ценный и ограниченный ресурс. А уж про внезапную прожорливость джавы до памяти ходят былины ;)
Лицензия — вас никто не заставляет встраивать код Sphinx в свои закрытые приложения, я слабо представляю себе, кому это могло бы понадобится, а использовать его в коммерческих целях как отдельный продукт GPL не запрещает.
Лицензия — вас никто не заставляет встраивать код Sphinx в свои закрытые приложения, я слабо представляю себе, кому это могло бы понадобится, а использовать его в коммерческих целях как отдельный продукт GPL не запрещает.
0
> отсутствие фасетного поиска из коробки
Смотрю, миф конкретно прилип.
Смотрю, миф конкретно прилип.
0
НЛО прилетело и опубликовало эту надпись здесь
Да вот же:
habrahabr.ru/blogs/django/136168/#comment_4529776
В сфинксе это не «фасетки» это группировка — разница только в терминах.
habrahabr.ru/blogs/django/136168/#comment_4529776
В сфинксе это не «фасетки» это группировка — разница только в терминах.
0
НЛО прилетело и опубликовало эту надпись здесь
Вот вам без мульти-запроса:
Будет один запрос, а группировка тут и есть add_facet, например, в pyes, просто оно тут так называется.
Группировка в документации описана. «Реализуется напрямую» — даже боюсь спросить что это значит.
s = SphinxClient()
s.SetGroupBy('tags', SPH_GROUPBY_ATTR, "@count desc" )
tags = s.Query('', index=index)
Будет один запрос, а группировка тут и есть add_facet, например, в pyes, просто оно тут так называется.
Группировка в документации описана. «Реализуется напрямую» — даже боюсь спросить что это значит.
0
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Правильно ли я понимаю, что если добавить в API новый метод FacetQuery с одним дополнительным параметром (список атрибутов, по которым нужна группировка) — то в Сфинксе, с вашей точки зрения, немедленно «появится» труевая поддержка «фасеточного поиска»?
+1
Если честно, для «трушности» не хватает стринговых mva и «правильно» считать все тот же MVA (мой коммент ниже). Да, все честно, это groupby и если в группе два значения, то это все равно группа, но это как раз и отличает фасетки от группировок. Второе может быть и есть в самом поиске, но в питон апи я его не нашел.
0
Раз уж такая пьянка.
Вот прямо сейчас как можно «закостылить» текстовые MVA? Ничего умнее списка md5-хешей я ничего не придумал, например, для тех же тегов: django, django sphinx.
Вот прямо сейчас как можно «закостылить» текстовые MVA? Ничего умнее списка md5-хешей я ничего не придумал, например, для тех же тегов: django, django sphinx.
0
Пока никак, только сконвертировать в список номеров, действительно. Solr умеет? Где почитать (я плохо ориентируюсь в их документации)? Ну и заодно, наверное про его актуальный набор поддерживаемых сегодня типов где почитать?
0
>Solr умеет?
К сожалению я не помню, делал я такое или нет сам. Солр у меня долго не прожил.
Вот тут речь о multiValued field, в примере:
Тут рассказывают как добавлять доки через CSV, там есть такая «строчка»:
Вот тут дока о «схеме»:
wiki.apache.org/solr/SchemaXml
Фасетки:
wiki.apache.org/solr/SolrFacetingOverview
wiki.apache.org/solr/SimpleFacetParameters
Все сразу:
wiki.apache.org/solr/
Очень наглядно для ElasticSearch (мне понравился больше чем солр, использует ту же библиотеку Lucene):
К сожалению я не помню, делал я такое или нет сам. Солр у меня долго не прожил.
Вот тут речь о multiValued field, в примере:
doc {
id : 1
keywords: [ hello, world ]
...
}
Тут рассказывают как добавлять доки через CSV, там есть такая «строчка»:
# Example: for the following input
id,tags
101,"movie,spiderman,action"
#to index the 3 separate tags into a multi-valued Solr field called "tags", use
f.tags.split=true
Вот тут дока о «схеме»:
wiki.apache.org/solr/SchemaXml
Фасетки:
wiki.apache.org/solr/SolrFacetingOverview
wiki.apache.org/solr/SimpleFacetParameters
Все сразу:
wiki.apache.org/solr/
Очень наглядно для ElasticSearch (мне понравился больше чем солр, использует ту же библиотеку Lucene):
'{"title" : "One", "tags" : ["foo"]}'
'{"title" : "Two", "tags" : ["foo", "bar"]}'
'{"title" : "Three", "tags" : ["foo", "bar", "baz"]}'
"facets" : {
"tags" : {
"_type" : "terms",
"missing" : 0,
"total": 5,
"other": 0,
"terms" : [ {
"term" : "foo",
"count" : 2
}, {
"term" : "bar",
"count" : 2
}, {
"term" : "baz",
"count" : 1
} ]
}
}
0
НЛО прилетело и опубликовало эту надпись здесь
Почему запрос-то? Вы видите чтобы я сохранял результат? Вот тут tags = s.Query('', index=index) мы получаем ответ от демона.
Апи собирает все наши запросы в список и только потом делает запрос.
Поэтому когда вы делаете Query на самом деле выполняется AddQuery и RunQuery и получаете results[0] — это такой враппер для ленивых.
>а в tags попадает количество совпадений? или это тоже надо вручную задавать? )
Это не совсем честный пример. К сожалению я не нашел способа делать группировку для MVA атрибутов, например, если статья содержит тег 1, а вторая 1&2, то мы получим такой результат: {1: 1, (1, 2): 1}, вместо {1: 2, 2: 1}
В случае пхп апи там есть костыль SetArrayResult, питоновцам не так повезло. Правда мне еще такое не пригождалось. Всякого рода «категории», «бренды» — да, это запросто.
Есть еще один момент %): сфинкс не умеет стринговые mva, а вот солр кажись умеет.
Однако я всеми руками за сфинкс, потому-как в нем есть то одно великое чего нет и в ближайшее время не будет в люцене: RT индексы — это просто железобитонный аргумент в пользу сабжа. Near-realtime, что обещают, не считается.
Апи собирает все наши запросы в список и только потом делает запрос.
Поэтому когда вы делаете Query на самом деле выполняется AddQuery и RunQuery и получаете results[0] — это такой враппер для ленивых.
>а в tags попадает количество совпадений? или это тоже надо вручную задавать? )
s = SphinxClient()
s.SetGroupBy('tags', SPH_GROUPBY_ATTR, "@count desc" )
tags = s.Query('', index=index)
tags = [(x['attrs']['tags'], x['attrs']['@count']) for x in tags['matches']]
print tags
{'django': 100, 'sphinx': 30}
Это не совсем честный пример. К сожалению я не нашел способа делать группировку для MVA атрибутов, например, если статья содержит тег 1, а вторая 1&2, то мы получим такой результат: {1: 1, (1, 2): 1}, вместо {1: 2, 2: 1}
В случае пхп апи там есть костыль SetArrayResult, питоновцам не так повезло. Правда мне еще такое не пригождалось. Всякого рода «категории», «бренды» — да, это запросто.
Есть еще один момент %): сфинкс не умеет стринговые mva, а вот солр кажись умеет.
Однако я всеми руками за сфинкс, потому-как в нем есть то одно великое чего нет и в ближайшее время не будет в люцене: RT индексы — это просто железобитонный аргумент в пользу сабжа. Near-realtime, что обещают, не считается.
0
> К сожалению я не нашел способа делать группировку для MVA атрибутов, например, если статья содержит тег 1, а вторая 1&2, то мы получим такой результат: {1: 1, (1, 2): 1}, вместо {1: 2, 2: 1}
Группировка по MVA есть и работает. Если документ принадлежит N группам, он во все N и попадет, все агрегатные функции посчитаются правильно.
Другое дело, что в каждой группе выбирается ровно 1 представитель группы, SQL style. Расширения для выбора M представителей группы пока нет. (Есть, вроде, древний запрос в багтрекере про это даже.) Беда в этом?
Группировка по MVA есть и работает. Если документ принадлежит N группам, он во все N и попадет, все агрегатные функции посчитаются правильно.
Другое дело, что в каждой группе выбирается ровно 1 представитель группы, SQL style. Расширения для выбора M представителей группы пока нет. (Есть, вроде, древний запрос в багтрекере про это даже.) Беда в этом?
+1
(headbang)
Вы не представляете как я сглупил, даже стыдно признаться %)
Я каким-то чудом проморгал атрибут @groupby, вместо него я брал значение из нужного поля, типа tags и пока в нем было одно значение оно работало, как только там попадало два и больше я не знал для кого подсчитан @count :)
Спасибо что спросили, порой, да, бревно в глазу не замечу.
Вы не представляете как я сглупил, даже стыдно признаться %)
Я каким-то чудом проморгал атрибут @groupby, вместо него я брал значение из нужного поля, типа tags и пока в нем было одно значение оно работало, как только там попадало два и больше я не знал для кого подсчитан @count :)
Спасибо что спросили, порой, да, бревно в глазу не замечу.
0
Понял почему порморгал. Если значение поля на русском (не mva), то атрибут приобретает вид '@groupby': 1174945792 и я его принял за какую-то служебную информацию. В MVA хранится числа, а в случае группировки в groupby записывается член группы, по которому шла группировка.
0
Ничего не понял. «Значение поля на русском» это как? :)
0
Например, 'brand_name': 'Оптика' или 'brand_name': 'Massive'
В смысле, текстовое. Я так понимаю оно потом «конвертируется» в число. В частности при группировки по этому атрибуту я получил вот это '@groupby': -8253040684853230141L.
При группировки по tags (MVA):
В атрибуте tags два тега, но в groupby записан айди тега, по которому шла группировка. В общем все хорошо.
В смысле, текстовое. Я так понимаю оно потом «конвертируется» в число. В частности при группировки по этому атрибуту я получил вот это '@groupby': -8253040684853230141L.
При группировки по tags (MVA):
'@count': 5,
'@groupby': 7,
'tags': [7, 8]
В атрибуте tags два тега, но в groupby записан айди тега, по которому шла группировка. В общем все хорошо.
0
НЛО прилетело и опубликовало эту надпись здесь
Исходя из заголовка:
можно предположить что sphinx = 0
jango+sphinx = jango-sphinx
можно предположить что sphinx = 0
+1
Интересно, что Haystack не поддерживает Sphinx из-за проблем с лицензией.
Пришлось использовать Sorl — работает отлично.
Пришлось использовать Sorl — работает отлично.
0
Парням из haystack достаточно было тупо написать мне письмо, и получить официальное разрешение использовать клиентскую библиотеку. Напишу-ка я им сам, раз они стеснительные.
+5
Daniel молчит. Нашел другой email адрес, пробую.
0
Посмотрите тут: github.com/toastdriven/django-haystack/issues/485
кто-то уже написал бэкенд для Sphinx и Даниэль рассказывает о минусах Sphinx и почему он не добавляет его.
Возможно он так и не получил ваши сообщения. Но там я думаю он точно увидит его. Либо увидят заинтересованные и донесут.
Кстати для тех кому интересно, вот Sphinx-бэкенд для django-haystack: github.com/btimby/sphinx-haystack
кто-то уже написал бэкенд для Sphinx и Даниэль рассказывает о минусах Sphinx и почему он не добавляет его.
Возможно он так и не получил ваши сообщения. Но там я думаю он точно увидит его. Либо увидят заинтересованные и донесут.
Кстати для тех кому интересно, вот Sphinx-бэкенд для django-haystack: github.com/btimby/sphinx-haystack
+1
Спасибо за ссылку!
Большая часть т.н. «минусов» вызывает у меня сильное офигение.
Впрочем, я давно убедился, что документацию никто не читает, зато в сложившиеся каким-то образом мифы верят многие.
Сейчас напишу ему туда.
Большая часть т.н. «минусов» вызывает у меня сильное офигение.
Впрочем, я давно убедился, что документацию никто не читает, зато в сложившиеся каким-то образом мифы верят многие.
Сейчас напишу ему туда.
0
Да, я тоже подумал что он просто когда-то давно чуток покопался со Sphinx и у него сложилось мнение.
Прошло время Sphinx изменился, а он этого не заметил. Я собственно и подразумевал что минусы в кавычках.
Прошло время Sphinx изменился, а он этого не заметил. Я собственно и подразумевал что минусы в кавычках.
0
Молодец, хорошо расписал там все! Надеюсь скоро займутся этим и в django-haystack бэкенд Shphinx будет «из коробки». Я на твиттере(и в некоторых комнатах IRC) с нужными хэш-тэгами выложил ссылку на твой комментарий. Те кому интересно проголосуют чтобы добавили или доработают тот что я выше по ссылке выложил. Спасибо!
0
Ну, вообще говоря, всякие абстрагирующие прокси типа haystack это прикольно, наверное; но я лично больше верю в родные специализированные решения на своем месте, чем кучи абстракций.
Те. считаю, задачу «давайте легко прикрутим поиск к фреймворку X» в идеальном мире должен хорошо решать вообще тот или иной наш нативный интерфейс; следующее допустимое приближение это родной плагин (видимо, это django-sphinx или любой его живенький форк); и только затем обобщенные абстракции типа haystack.
Причем мы ж завсегда готовы работать с авторами подобных штук; пишите письма; обсудим, поможем, приделаем. Однако если обстоятельный комментарий «почему нет» написать человек находит время, а тупо кинуть мне ссылку уже нет, то ничего конструктивного не произойдет, очевидно. Это как бы «намек» желающим форкнуть, доработать итп.
Те. считаю, задачу «давайте легко прикрутим поиск к фреймворку X» в идеальном мире должен хорошо решать вообще тот или иной наш нативный интерфейс; следующее допустимое приближение это родной плагин (видимо, это django-sphinx или любой его живенький форк); и только затем обобщенные абстракции типа haystack.
Причем мы ж завсегда готовы работать с авторами подобных штук; пишите письма; обсудим, поможем, приделаем. Однако если обстоятельный комментарий «почему нет» написать человек находит время, а тупо кинуть мне ссылку уже нет, то ничего конструктивного не произойдет, очевидно. Это как бы «намек» желающим форкнуть, доработать итп.
0
Понадобилось сделать поиск на сфинксе. В реализации django-sphinx не понравилось в первую очередь привязка к моделям. А если контент раскидан по связным моделям?
Тогда реализовал вывод через питоновское апи и индексацию по xml.
Тогда реализовал вывод через питоновское апи и индексацию по xml.
0
Про варианты. Есть еще один: можно ходить напрямую в Sphinx через SphinxQL, все будет совершенно аналогично работе с обычным MySQL.
Про режимы поиска. Они, может, некоторые мелочи слегка упрощают, но это таки легаси. Я бы советовал таки везде приводиться к MATCH_EXTENDED.
Про релизы. Мы обратно совместимы, практически всегда. Ну те. любая новая версия обязана работать с любыми старыми клиентами и умеренно старыми форматами индексов.
Про режимы поиска. Они, может, некоторые мелочи слегка упрощают, но это таки легаси. Я бы советовал таки везде приводиться к MATCH_EXTENDED.
Про релизы. Мы обратно совместимы, практически всегда. Ну те. любая новая версия обязана работать с любыми старыми клиентами и умеренно старыми форматами индексов.
+1
А я для себя просто сделал «обертку» python api. То есть, например, одна функция поиска, которая принимает многочисленные опции сфинкса в качестве параметров. Другая функция возвращает объекты по классу модели и результату сфинкса.
А с конфигами ИМХО лучше всё же разбираться вручную, т.к. там есть много полезных вещей, о которых вы можете не подозревать. ;)
А с конфигами ИМХО лучше всё же разбираться вручную, т.к. там есть много полезных вещей, о которых вы можете не подозревать. ;)
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Django + Sphinx = django-sphinx (?)