Комментарии 8
Ссылки на проект, вроде бы, почистил, так как хабраэффект он не переживетСтатья узконаправленная, может и переживет, было бы интересно посмотреть :)
Вся суть статьи: «Мы поняли, что like в mssql работает медленно и перешли на sphinx. Вот пару строк кода.».
Это всё круто, но не помешали бы ещё небольшие заметки почему был выбран именно sphinx, а не тот же lucene. Итоговый прирост в скорости, хотя бы на уровне запроса до Mssql/sphinx. Неплохо было бы дописать почему like медленный. И если статья всё-таки про выбор и использование «Fulltext Search Engine», то к чему тут jtemplates. Как минимум заголовок «Sphinx для ASP.NET через jTemplates» звучит как «Двигатель для Машины через алюминевый бампер» — можно было на мой взгляд просто в статье указать «вот пример вывода на клиенте используя jtemplates».
Можете ли что-то сказать про поддержку многопоточности (на одном из проектов нактнулись на ограничение на одновременное количество запросов в lucene). Клиент поддерживает async api для запросов?
К слову, для статьи из песочницы неплохо, относительно кратко и по делу. Спасибо.
Это всё круто, но не помешали бы ещё небольшие заметки почему был выбран именно sphinx, а не тот же lucene. Итоговый прирост в скорости, хотя бы на уровне запроса до Mssql/sphinx. Неплохо было бы дописать почему like медленный. И если статья всё-таки про выбор и использование «Fulltext Search Engine», то к чему тут jtemplates. Как минимум заголовок «Sphinx для ASP.NET через jTemplates» звучит как «Двигатель для Машины через алюминевый бампер» — можно было на мой взгляд просто в статье указать «вот пример вывода на клиенте используя jtemplates».
Можете ли что-то сказать про поддержку многопоточности (на одном из проектов нактнулись на ограничение на одновременное количество запросов в lucene). Клиент поддерживает async api для запросов?
К слову, для статьи из песочницы неплохо, относительно кратко и по делу. Спасибо.
Спасибо за комментарий к моей первой статье!
Буду учитывать в будущих.
На многопоточность не жаловались, делали нагрузку в 100 мбит в 1000 клиентов с 1 запросом страницы поиска в минуту, сфинкс всё отдавал как положено.
ASP.NET+MS SQL + Sphinx вертится на одной машине 4GB, 2,9 GHz, обычные харды.
Сам сфинкс async api держит, но в клиенте мы не проверяли — небыло таких у нас нагрузок и не скоро будет. Полагаю, что при связи с сфинксом по TCP/IP мы будем иметь те же достоинства/недостатки, что и для клиентов к базам данных.
По хорошему, сфинкс нужно вынести физически на openSUSE машину, так как он под *x платформы в первую очередь делается. В свое время в Windows мы столкнулись с проблемой ротейшна индекса. Спасибо Стасу Климову, быстро подсказал в форумах как подправить и проблема была устранена в следующих релизах — быстрая и адекватная поддержка пользователей + большой FAQ — было решающим для нас при выборе движка.
А на других движках даже примеры сложно найти, тем более кого-то спросить.
Буду учитывать в будущих.
На многопоточность не жаловались, делали нагрузку в 100 мбит в 1000 клиентов с 1 запросом страницы поиска в минуту, сфинкс всё отдавал как положено.
ASP.NET+MS SQL + Sphinx вертится на одной машине 4GB, 2,9 GHz, обычные харды.
Сам сфинкс async api держит, но в клиенте мы не проверяли — небыло таких у нас нагрузок и не скоро будет. Полагаю, что при связи с сфинксом по TCP/IP мы будем иметь те же достоинства/недостатки, что и для клиентов к базам данных.
По хорошему, сфинкс нужно вынести физически на openSUSE машину, так как он под *x платформы в первую очередь делается. В свое время в Windows мы столкнулись с проблемой ротейшна индекса. Спасибо Стасу Климову, быстро подсказал в форумах как подправить и проблема была устранена в следующих релизах — быстрая и адекватная поддержка пользователей + большой FAQ — было решающим для нас при выборе движка.
А на других движках даже примеры сложно найти, тем более кого-то спросить.
Главный минус решений как Sphinx или Lucene, это проблема, когда кроме полнотекстовых фильтров нужно применить ещё и логические фильтры или заджойнить какую-нибудь таблицу. Когда я работал с Lucene.NET я столкнулся с этой проблемой единственным решением, которой для меня было, индексировать полнотекстовую информацию + айдишники строк БД, а потом получать по этим айдишникам сущности Entity Framework. Таким образом каждый запрос к Lucene получал айдишники всех элементов(для того чтобы в Entity Framework мы могли фильтровать по всем элементам), вместо 10-20, которые мне нужны. В общем, увеличение скорости по сравнению БД в десятки раз отзывается усложнением работы, но думаю это того стоит. К сожалению, я не нашел либы, которая скрывала бы эти сложности.
Знакомые грабли.
Почему бы в индексах не хранить все нужные аттрибуты для генерации страниц, в том числе из джоинов?
Мы, например, так и сделали, все джоины (имя продавца, его адрес и др.) во вьюхе при создании индекса делаются и сфинкс нам отдает всё что нужно для генерации страницы поиска без БД.
Почему бы в индексах не хранить все нужные аттрибуты для генерации страниц, в том числе из джоинов?
Мы, например, так и сделали, все джоины (имя продавца, его адрес и др.) во вьюхе при создании индекса делаются и сфинкс нам отдает всё что нужно для генерации страницы поиска без БД.
Кстати, хорошая идея хранить это в каком-то подобии вьюх. Когда работал с Lucene, не очень пользовался вьюхами БД, но теперь после некоторого опыта работы с вьюхами, скажу что для списков каких-то элементов вьюхи довольно удобный способ представления информации. Неизвестно, правда, как с производительностью у такого индекса — если обновлять индекс при каждом обновлении базы, то может получиться довольно серьезная нагрузка.
Возможно вам стоит посмотреть в сторону материализованных представлений, этот тип представлений создан специально для повышения производительности
Круто, что MS SQL до 20 тысяч записей норм работает. Если честно, думала, что он начнет тупить с гораздо меньшего количества.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Sphinx для ASP.NET через jTemplates