7 марта 2010 в 6:15
Друзья!
Хочу добавить на сайт автоматический вывод похожих материалов после основного текста ноды.
Прошерстил д.орг, отобрал кандидатуры.
Остались два основных вопроса:
- Качество работы с русским языком - латиницу модули наверняка обрабатывают нормально, будет ли то же самое с кириллицей?
- Производительность - очевидно, что подбор похожих материалов - это сравнение по словарям, либо поиск (не самые быстрые операции)
Вот модули, которые мне удалось найти:
- Similar Entries - выглядит наиболее подходящим с точки зрения процесса работы. Использует FULLTEXT для таблиц MyISAM;
- Relevant Content - использует таксономию для подбора похожих записей - выбирает записи с теми же терминами, а также смотрит на дату создания материала;
- Similar By Terms - очень похож на предыдущий модуль, тоже использует термины таксономии, требует наличия словаря "Tags", работающего в режиме freetagging (ноды, не имеющие терминов из него, выводиться не будут). Умеет кэшировать блоки, что хорошо для скорости работы;
- Related links - отсутствует версия для D6, так что дальше я изучать не стал.
Для меня наиболее подходящим выглядит Similar Entries (т.к. у меня нет тэгов), но вопрос снова в качестве и скорости его работы.
А используете ли вы похожие или один из этих модулей?
Мне было бы очень интересно услышать ваш отзыв (особенно о Similar Entries).
Комментарии
Еще можно посмотреть мой модуль cctags
Кратенькое описание возможностей здесь
там всё в UTF-8, какая разница какой шрифт
Строго говоря, вопрос скорости заканчивается на кэшировании. Similar Entries себя кэширует по самое небалуйся (по-моему, даже не привлекая стандлартный API кэширования, а совсем самостоятельно). В итоге, особой нагрузки нет, один запрос -- вынуть блок (ну, там не совсем один, но терпимо). Сам по себе FULLTEXT-индекс тоже работает быстро.
Единственная засада -- при достаточно больших объемах FULLTEX-индекс начинает тормозить операции вставки (у меня это было где-то в районе 170 тыс. документов, каждый -- около 4 Кбайт, на самом деле скорее зависит от настройки буферов в MySQL и специфики данных). Но при меньших объемах Similar Entries -- очень милая вещица.
А, единственный минус: с CCK не работает, теоретически, можно его переписать на Sphinx, если совсем припрет, о чем и подумываю (мне параметрическое сходство нужно).
Будет оно иметь полюбому свои 300-5оо запросов на страницу...Если это не сайт визитка
На двух сайтах делал вывод похожих нод по кол-ву одинаковых терминов. Пример: http://tube.sfu-kras.ru/video/631 (похоже видео), http://news.sfu-kras.ru/node/5335 (похожие новости). Сам делал select-ы для подсчета кол-ва терминов, совпадающих с терминами текущей ноды.
Судя по докам, они перешли на стадартный метод кэширования блоков, когда он появился (в Д6), т.е. если кэширование блоков отключено, то и в SE кэширования не будет.
(если я не правь, смело меня поправляйте)
Правильно ли я понимаю, что у вас на сайте было 170 тыс. нод?
И скажите пжл (опыт - это самое интересное): на каком хосте SE начинал тормозить на таком (совсем немаленьком) сайте?
Т.е.? Даже если у меня сайт, на котором сейчас 30 нод (и он ну очень навряд ли вырастет больше 700 документов), то что - при выводе любой из нод благодаря SE делается три сотни (!!) запросов??
Года полтора назад у аналогичного плагина для WP были проблемы с не-латиницей - его алгоритм в итоге начинал работать, если не ошибаюсь, через побуквенный поиск.
(точно подробностей не помню, но могу поискать)
Может быть. В любом случае, механизмы кэширования есть, и даже стандартный вполне справляется, думаю. Если припрет, то его переделать -- работы на 15 минут.
Почему "было"? Есть и увеличивается
Тормозить начинал не SE, он-то как раз занимаетися только выборкой, там все пучком. А вот при _вставке_ MySQL с ощутимым усилием прожевывал FULLTEXT-индекс (что понятно и он на это имеет полное право). А SE летал, ему-то что, ему пофиг -- запросил выборку, мускул по индексу быстро и выдал нужное. На то индекс и придуман
Это, я думаю, товарищ пугает, запросы генерятся не конкретно SE, а вообще Drupal на всю страницу. Но в целом да, Drupal любит наяривать базу. Другое дело, что запросы простые и достаточно быстро отрабатываемые. Но в целом любовь разработчиков к идее "все в БД" необъяснима рациональными причинами. Они когда-то рассказывали, что мол "все быстро ложится в кэш БД и проблем нет", но если речь идет о shared-хостинге, где кэш в момент забьется чужими запросами, это не работает. Но увы, это реальность, данная нам в ощущениях.
(А, и да, что меня в свое время подкупило в SE -- именно то, что там в общем один-два-три запроса. Модули, рисующие "похожие материалы" на базе таксономии насилуют БД значительно больше: запросов больше, джойны всякие...)
В WordPress и не такое могло быть
Сам недавно разбирался с подобным вопросом. Но мне было проще, есть тэги и сайт не нагруженный.
Свои изыскания записал - http://dovbysh.com/ru/article/moduli-drupal-pohozhie-materialy
На самом сайте http://dovbysh.com/ используется Relevant content удобно так как используется поле СКК для вывода.