Комментарии 31
«High Performance MySQL»:
Sphinx can complement a MySQL-based application in many ways, bolstering performance
where MySQL is not a good solution and adding functionality MySQL
can’t provide. Typical usage scenarios include:
• Fast, efficient, scalable, relevant full-text searches
• Optimizing WHERE conditions on low-selectivity indexes or columns without
indexes
• Optimizing ORDER BY… LIMIT N queries and GROUP BY queries
• Generating result sets in parallel
• Scaling up and scaling out
• Aggregating partitioned data
Sphinx can complement a MySQL-based application in many ways, bolstering performance
where MySQL is not a good solution and adding functionality MySQL
can’t provide. Typical usage scenarios include:
• Fast, efficient, scalable, relevant full-text searches
• Optimizing WHERE conditions on low-selectivity indexes or columns without
indexes
• Optimizing ORDER BY… LIMIT N queries and GROUP BY queries
• Generating result sets in parallel
• Scaling up and scaling out
• Aggregating partitioned data
+1
Требовалось каждую секунду вынимать последние новости? Или может быть более разумным решением было бы кэшировать их хотя бы на несколько минут?
+1
И кешировалось и более того — ложилось в статику
+1
сам по себе запрос очень трудоемкий, и даже один раз — слижком много и долго. поэтому кешированием делу не поможешь, разве что только если кешировать не по запросу, а каждые 5 минут ВСЕ возможные варианты запросов, но это тоже довольно нелепо, имхо
+4
Я в свое время делал сайт где была достаточно хитрая система вывода новостей в категории. MySQL на выборке задумывался секунд на 10, Postgres секунд на 5, и в итоге я перешел на Sphinx, который конечно же отдалавал все моментально.
+1
Ммм, что-то я не верю в такие хитрые запросы. Я когда тестирую сложные запросы — создаю таблицы с лямом записей. Если где-то что-то не то с индексами, то думает секунд 30.
-2
Да? правда? запрос с джоинами через 3 таблицы?
-1
Значит вам не попадались запросы, работающие с десятками таблиц одновременно, с нетривиальными подзапросами и сложной логикой объединения. Последний встретившийся нам «чемпион» был в длину 150(!) строчек, причём навскидку этот запрос не сокращался. Предметная область — банковские приложения.
0
Эти запросы пишут идиоты. В них нельзя ничего понять. Логика приложения не должна быть в запросе, она должна быть в коде. Быстрее и проще реализовать нужные объединения в прикладном коде. Я мечтаю о том прекрасном мире, когда не будет ни больших неповоротливых сложнопонимаемых запросов на 150 строк, ни хранимых процедур, ни тупых реализацций ООП, где приходится на каждый интерфейс делать класс *Impl.
-1
У вас опечатка — "$category" вместо просто $category без кавычек.
+2
У меня на cenugids.lv, например, вывод товаров с 3х стран полностью на сфинксе, включая подсчет по странам, полнотекстовой поиск и все такое. Сфинкс как readonly БД прекрасно себя зарекомендовал.
+5
10 минут для попадания новости в требуемую выдачу — несерьезно.
Что мешает завести вспомогательную таблицу last_news_from_source, которую можно теми же триггерами обновлять во время вставки новой новости?
Что мешает завести вспомогательную таблицу last_news_from_source, которую можно теми же триггерами обновлять во время вставки новой новости?
+1
производительность мешает. а 10 минут — еще как серьезно — обновление индекса Sphinx запускается после того, как отработали скрипты загрузки новостей, так что задержка попадания тут больше зависит не от индексации, а от скорости скачивания RSS
0
А например, как быть если последнюю новость заблокировал модератор, нужно срочно поменять местами предпоследнюю и последнюю, и т.д. и т.п.? Перестойка даже дельта индекса гораздо медленней, а менеджеры над душой стоят.
А если данные берутся из основного поиска (индекса), так вообще урезается любая возможность маневра.
А если данные берутся из основного поиска (индекса), так вообще урезается любая возможность маневра.
+1
>>руководство поставило следующую задачу: показывать по одной последней новости из каждого источника
а просто завести отдельную (кэширующую) табличку, в которой хранить последнюю новость для каждого источника?
обновлять можно по триггеру after insert из основной таблицы новостей
а просто завести отдельную (кэширующую) табличку, в которой хранить последнюю новость для каждого источника?
обновлять можно по триггеру after insert из основной таблицы новостей
+2
Ладно, согласен — можно сделать эту самую отдельную таблицу, но тогда надо хранить не только последнюю новость в каждом источнике, но и в каждой категории, а тригеры — в MySQL это вообще плохая идея, пришлось бы перевести таблицу новостей в Innodb, а оно на наших задачах работает ну ооочень медленно
-1
проблему с мгновенно деактивацией новости можно решить через setFilter по числовому полю.
0
Вопрос, зачем нужен mysql, если он используеться только для выборки по ID? хеши аля беркля датут вам тааакой выйгрыш!
0
Подскажите, пожалуйста, может ли Sphinx искать по частям слов?
Насколько мне известно (я могу быть неправ), fulltext search делает выдачу только по словам, а не по их частям.
Насколько мне известно (я могу быть неправ), fulltext search делает выдачу только по словам, а не по их частям.
0
конечно может, смотрите sphinxsearch.com/docs/current.html#conf-min-infix-len
0
«показывать по одной последней новости из каждого источника»
Скажите пожалуйста, а можно как-то сделать отображение например 2х последних новостей из каждого источника?
Потому как в документации читаю sphinxsearch.com/docs/current.html#clustering
The final search result set then contains one best match per group. Grouping function value and per-group match count are returned along as «virtual» attributes named @group and @count respectively.
Или тогда нада использовать какой то другой метод?
Скажите пожалуйста, а можно как-то сделать отображение например 2х последних новостей из каждого источника?
Потому как в документации читаю sphinxsearch.com/docs/current.html#clustering
The final search result set then contains one best match per group. Grouping function value and per-group match count are returned along as «virtual» attributes named @group and @count respectively.
Или тогда нада использовать какой то другой метод?
0
«Оказалось, что MySQL сначала выполняет группировку» facepalm
-1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Sphinx — не только для поиска!