Как стать автором
Обновить

Комментарии 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
Требовалось каждую секунду вынимать последние новости? Или может быть более разумным решением было бы кэшировать их хотя бы на несколько минут?
И кешировалось и более того — ложилось в статику
А не проще было при вставке делайть апдейт дополнительного поля is_last=1 а всем остальным is_last=0 ну и выгребать уже подготовленный записи?
сам по себе запрос очень трудоемкий, и даже один раз — слижком много и долго. поэтому кешированием делу не поможешь, разве что только если кешировать не по запросу, а каждые 5 минут ВСЕ возможные варианты запросов, но это тоже довольно нелепо, имхо
Я в свое время делал сайт где была достаточно хитрая система вывода новостей в категории. MySQL на выборке задумывался секунд на 10, Postgres секунд на 5, и в итоге я перешел на Sphinx, который конечно же отдалавал все моментально.
Ммм, что-то я не верю в такие хитрые запросы. Я когда тестирую сложные запросы — создаю таблицы с лямом записей. Если где-то что-то не то с индексами, то думает секунд 30.
Да? правда? запрос с джоинами через 3 таблицы?
Правда. Джойны через три таблицы с грамотными индексами — херня.
Значит вам не попадались запросы, работающие с десятками таблиц одновременно, с нетривиальными подзапросами и сложной логикой объединения. Последний встретившийся нам «чемпион» был в длину 150(!) строчек, причём навскидку этот запрос не сокращался. Предметная область — банковские приложения.
Эти запросы пишут идиоты. В них нельзя ничего понять. Логика приложения не должна быть в запросе, она должна быть в коде. Быстрее и проще реализовать нужные объединения в прикладном коде. Я мечтаю о том прекрасном мире, когда не будет ни больших неповоротливых сложнопонимаемых запросов на 150 строк, ни хранимых процедур, ни тупых реализацций ООП, где приходится на каждый интерфейс делать класс *Impl.
У вас опечатка — "$category" вместо просто $category без кавычек.
да спасибо, подчищал кое что из кода, не касающееся рассматриваемого вопроса, не вес лишнее убрал
У меня на cenugids.lv, например, вывод товаров с 3х стран полностью на сфинксе, включая подсчет по странам, полнотекстовой поиск и все такое. Сфинкс как readonly БД прекрасно себя зарекомендовал.
10 минут для попадания новости в требуемую выдачу — несерьезно.
Что мешает завести вспомогательную таблицу last_news_from_source, которую можно теми же триггерами обновлять во время вставки новой новости?
производительность мешает. а 10 минут — еще как серьезно — обновление индекса Sphinx запускается после того, как отработали скрипты загрузки новостей, так что задержка попадания тут больше зависит не от индексации, а от скорости скачивания RSS
А например, как быть если последнюю новость заблокировал модератор, нужно срочно поменять местами предпоследнюю и последнюю, и т.д. и т.п.? Перестойка даже дельта индекса гораздо медленней, а менеджеры над душой стоят.
А если данные берутся из основного поиска (индекса), так вообще урезается любая возможность маневра.
Даже для сфинкса очень желательна эта «last_news_from_source» таблица. Почитать можнотут.
ссылочка не открывается
>>руководство поставило следующую задачу: показывать по одной последней новости из каждого источника
а просто завести отдельную (кэширующую) табличку, в которой хранить последнюю новость для каждого источника?
обновлять можно по триггеру after insert из основной таблицы новостей
Ладно, согласен — можно сделать эту самую отдельную таблицу, но тогда надо хранить не только последнюю новость в каждом источнике, но и в каждой категории, а тригеры — в MySQL это вообще плохая идея, пришлось бы перевести таблицу новостей в Innodb, а оно на наших задачах работает ну ооочень медленно
вам на местах видней
в задаче руководства не было ни слова про категории :)
Это еще почему InnoDB? Триггеру-то не пофиг ли?
да вроде как и на MyISAM триггеры работают
проблему с мгновенно деактивацией новости можно решить через setFilter по числовому полю.
Вопрос, зачем нужен mysql, если он используеться только для выборки по ID? хеши аля беркля датут вам тааакой выйгрыш!
ну как бы упомянутая в статье выборка не единственная, есть и другие, менее ресурсоемкие, и их делает MySQL
Подскажите, пожалуйста, может ли Sphinx искать по частям слов?
Насколько мне известно (я могу быть неправ), fulltext search делает выдачу только по словам, а не по их частям.
«показывать по одной последней новости из каждого источника»

Скажите пожалуйста, а можно как-то сделать отображение например 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.

Или тогда нада использовать какой то другой метод?
«Оказалось, что MySQL сначала выполняет группировку» facepalm
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории