1. Приветствуем Вас на неофициальном форуме технической поддержки XenForo на русском языке. XenForo - коммерческий форумный движок от бывших создателей vBulletin, написанный на PHP.

TagS - система тегов

Тема в разделе "Основные вопросы по XenForo", создана пользователем infis, 31.03.2012.

Загрузка
  1. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    В связи с началом разработки плагина тегов (меток, ключевых слов) предлагаю обсудить необходимый функционал.
    Я не хочу копировать функционал из vBulletin, поэтому прошу всех желающих высказаться по данному поводу.

    Пока я вижу такой функционал:
    1. Теги пока только для тем, но в будущем их можно расширить и для другого контента. Скорее всего в плагине будет предусмотрено расширение сторонними плагинами.
    2. Поддержка облака тегов (вывод наиболее популярных тегов по количеству использований).
    3. Теги в теме задаются через запятую. Их количество неограниченно, но максимальное количество символов в строке тегов - 255.
    4. Теги в теме можно добавлять и удалять путем редактирования строки тегов.
    5. Права на добавление и изменение тегов аналогичны правам на редактирование темы.
    6. Теги создаются автоматически из строки тегов.
    7. В админке теги можно изменять, добавлять и объединять.
    8. Поиск похожих тем по ключевым словам при просмотре темы.
    9. Показ тегов при просмотре темы.
    10. Если надо, теги можно будет добавлять в блоки meta страницы (для поисковиков).
    11. Если получится, можно будет попробовать сделать автодополнение существующих тегов в строке ввода тегов.
    12. Наличие стоп-списка слов, поддерживаемым администратором.
    13. Автоматическое формирование списка тегов из первого сообщения темы (на будущее). Алгоритм тут неоднозначен, да и нужность также под вопросом. Но почему бы и нет?
    14. Дополнительная галочка в поле поиска "Только по тегам". Без галочки поиск будет вестись в обычном виде, включая поиск по тегам.
    --- добавлено : Mar 31, 2012 3:19 PM ---
    Думаю, что еще один пункт нужно добавить:

    15. В админке добавить настройку "Использовать на форумах", где нужно будет указать, где использование тегов разрешено. Это избавит от массы ненужных тегов в таких разделах, как "Офтоп", "Архив", "Помойка" и т.д.
     
    Air Jordan, shaman480, SeM13 и ещё 1-му нравится это.
  2. guiltar

    guiltar Местный

    Регистрация:
    15.04.11
    Сообщения:
    137
    Симпатии:
    231
    А есть возможность тэги на другой базе сделать сделать?
    Говорят, это производительность сильно убивает.
     
  3. Yoskaldyr

    Yoskaldyr Пользователь

    Регистрация:
    27.09.10
    Сообщения:
    1 921
    Симпатии:
    1 163
    Версия XF:
    1.0.4
    Ну на другой базе заточенной под подобные задачи скорость будет в десятки раз быстрее, но насколько я знаю в задаче только использовать мускуль и все
     
  4. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    Конечно это убивает производительность. Использовать другую базу можно всегда, но это уже будет индивидуально. А нужно решение универсальное. И каждый администратор уже сам будет думать, стОит ли ему использовать теги на своем форуме или нет.
    Кстати о производительности, насколько она снизится при большой базе? Тут ведь нужно учитывать, что лучше - нормализовать базу тегов, раскладывая сами теги и линки по разным таблицам, или пожертвовать объемом таблицы линков, рассчитывая на оптимизацию индексами самим сервером базы данных. В последнем случае отсутствие дополнительного подзапроса может дать выигрыш, так как поле с именем тега не требует полнотекстового индекса, что в свою очередь делает индекс таблицы вполне компактным и легко помещающимся в памяти сервера базы данных. То есть убираем лишний джойн и увеличиваем производительность, но теряем гибкость в некоторых случаях. Опять таки, будет зависеть от настроек сервера базы данных. Если ему не будет хватать памяти для кеша или индекс перестанет полностью влазить в память, то деградация производительности будет налицо. Нормализация в этом случае просто необходима, так как тогда гарантированно индекс поместится в памяти сервера. Но есть опасность того, что серверу базы данных придется создавать временную таблицу, если при выборке с использованием джойна перестанет хватать места.
    В общем производительность однозначно упрется в тюнинг сервера базы данных при любом подходе.

    Лично я хочу отказаться от использования таблицы с сетами тегов или аналогичного поля в таблице тем (или любого другого контента). Дело в том, что эти сеты не всегда можно использовать без необходимости других запросов. Например, если для всех тем отображать похожие темы по тегам, то отдельная таблица сетов или поле с сетами становится просто бессмысленным. Такое поле или такая таблица нужно лишь для легкого запроса при формировании списка тех же тем, где будут упоминаться теги. А оно нужно? Я вот не могу для себя определить ситуации, когда таблица или поле сетов будут необходимы, а таблица линков будет не нужна. Если такие ситуации есть, то может кто нибудь их описать?

    Теперь по тегам в другой базе. В какой? В Oracle, Cache,...? Любая из них стОит не один рубль. Да и полностью переходить на другой сервер базы данных потребует переписывания ксена, что исключаем сразу. Использование других серверов базы данных в принципе можно не рассматривать. Это другая задача.
    Можно, конечно, использовать системы для полнотекстового поиска типа Sphinx. А оно нужно? Ведь теги - это не совсем для полнотекстового поиска. Вернее, они могут использоваться для поиска, но их задача все же другая. Это систематизация контента по ключевым словам, что в понятие полнотекстового поиска в общем не входит. Если хранить теги, допустим, в отдельном поле в таблице с контентом, а затем поисковой системе скормить эти теги с бОльшим весом, чем контент, то можно получить некоторый профит. Но на этом, собственно, вся их полезность и закончится. А как же выборки по тегам, статистика и прочие полезности именно систематизации по тегам?

    Я эту тему потому и создал, чтобы определиться, какую структуру таблиц сделать для тегов, а также как это потом использовать. Слишком много будет зависеть от требуемой функциональности.
     
  5. guiltar

    guiltar Местный

    Регистрация:
    15.04.11
    Сообщения:
    137
    Симпатии:
    231
    Я имел ввиду не заменять мускул на другую базу, а просто использовать дополнительную, например Mongo или Redis. Тут пускай Yoskaldyr посоветует.
     
  6. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    Так он и посоветовал. Не изобретать велосипед и забить на это дело :)

    Можно было бы содрать то, что на vB есть, но мне половина функций там не нужна, а часть функций не хватает. Потому и структуру таблиц не имеет смысла копировать.
    С трудом себе представляю, какие это даст плюсы.
     
  7. Yoskaldyr

    Yoskaldyr Пользователь

    Регистрация:
    27.09.10
    Сообщения:
    1 921
    Симпатии:
    1 163
    Версия XF:
    1.0.4
    Да потому что там есть конструкции, на которые теги ложатся из коробки с минимальными манипуляциями.
    Но понятно что нужна универсальность - значить будут построение целого производственного комплекса велосипедных фабрик на мускуле :)))
     
  8. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    Я не об этом. Просто трудно себе представить высоконагруженный форум без тюнинга и собственной VDS или железного сервера. В то же время маловероятно наличие возможности установить что-то свое или уже готовое к использованию на обычном хостинге, на котором крутится подавляющее большинство различных форумов. Получается, что высокопроизводительная система тегов нужна тем, кто вполне может позволить себе разработку своей собственной системы тегов со своим блек-джеком и шл.хами. Ну или на худой конец будет какой-то готовый коммерческий продукт, который уже будет требовать определенное окружение или развернутые специализированные серверы.
    Разрабатывать систему, которой смогут воспользоваться единицы, не имеет большого смысла. Или сразу делать коммерческий вариант.

    Все же я ориентируюсь на большинство форумов с максимум средней нагруженностью, которым просто нужен функционал тегов, пусть и не с бешеной производительностью.

    В любом случае я готов попробовать это реализовать и с помощью других инструментов. Пусть будет тот же Redis. Кто поможет? Могу и сам ковыряться, но боюсь, что это займет слишком много времени, так как у меня нет опыта с ним.
     
  9. Yoskaldyr

    Yoskaldyr Пользователь

    Регистрация:
    27.09.10
    Сообщения:
    1 921
    Симпатии:
    1 163
    Версия XF:
    1.0.4
    Сначала точно определитесь с функционалом, от этого будет зависеть все остальное. Можно и на мускуле сделать и будет работать норм до каких-то объемов (на булке ведь работает).
    Кстати Вы пишете что в булке не хватает какого-то функционала, а какой-то излишен. Так вот в 3-й булке функционал именно тот что описан в первом сообщении - ни больше ни меньше (ну может более детально админ функционал прописан)
     
  10. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    Я третью булку не ковырял, потому не могу по ней делать какие-то выводы. Возможно, мои желания совпали с возможностью 3-ки :)
    Решил таки посмотреть, как в мире "борются" с тегами на мускуле и вообще. В общем народ все же больше использует схему, при которой:
    1. Таблица тегов с двумя полями id и tag.
    2. Таблица линков с контентом. Достаточно двух полей: tag_id, content_id.
    3. Поле в таблице контента с перечнем тегов. Используется не всегда, так как не всегда требуется увидеть теги без других взаимосвязей. Лично для меня эта возможность сомнительна, так как я не вижу практического применения этому.

    Все же давайте отписываться в том числе и по функционалу. Как теги будут использоваться? Из того, что я описал, 3-е поле не нужно будет. В общем это не сильно усложнит реализацию, но увеличит размер базы и потребует синхронизации такого поля при любых изменениях тегов.

    Есть момент, который я сразу не учел, но, возможно, он все же понадобится. Это хранение в таблице линков дополнительно даты и времени создания или обновления контента. Увеличится размер таблицы, но можно будет легко получать актуальные теги.
     
  11. guiltar

    guiltar Местный

    Регистрация:
    15.04.11
    Сообщения:
    137
    Симпатии:
    231
  12. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    Не. Это выделение ника пользователя. Если по аналогии с чатом, то обращение.
    --- добавлено : Apr 3, 2012 6:39 AM ---
    Итак, господа (возможно, дамы тоже присутствуют)!

    Что делать-то будем? Мнения и пожелания еще будут?

    Пока я вижу примерно следующую реализацию.
    1. Таблица тегов с двумя полями: ид и тег.
    2. Таблица линков между тегами и контентом с тремя полями: ид_тега, ид_контента, тип_контента.
    3. Дополнительное поле в таблице контента (в данном случае в таблице тем), в котором хранится строка тегов, перечисленных через запятую.

    Работать будет не шустро, но при вменяемом размере базы должно работать вполне удовлетворительно. Т.е. количество тем - 100 тысяч, в каждой теме в среднем 5 тегов дадут таблицу линков в 500 тысяч. Большое количество записей в таблице линков на самом деле будет отрабатывать довольно быстро, так как там будут только ид и индексы по ним, что даже на выборках в несколько миллионов будет вполне быстрым. Добавление тегов будет происходить быстро, но удаление или изменение тега будет не быстрым. Также при удалении темы поиск затронутых тегов также даст дополнительную серию запросов. В связи с тем, что операции удаления тем и изменения тегов являются не частыми, то это не повлияет на общую производительность форума. Поиск похожих тем имеет смысл делать отключаемым в админке, так как он создаст некоторую нагрузку, сильно зависящую от количества тегов и линков, что может привести к деградации производительности. При хорошем сервере в этом случае можно продолжать использовать поиск похожих тем, а на слабом сервере придется отключать. Но в любом случае сами теги смогут работать и дальше.
    Формирование облака можно делать пока по принципу наибольшего количества использований. Это не идеальный вариант, но в общем вполне рабочий. Можно сделать по последним использованиям, тогда нужно будет добавить в таблицу тегов еще одно поле - дата использования. Это поле плюс количество использований могут дать выборку наиболее популярных и свежих тегов. Беда в том, что запрос на количество использований будет достаточно трудоемким, а поэтому в идеале его нужно делать, например, кроном раз в сутки в наименее нагруженное время. Можно также сразу пробовать в таблицу тегов загонять в отдельное поле количество использований, тогда сортировка будет практически мгновенной. Но и дата использования и отдельное поле количества использований потребуют обновления во время изменения контента и/или тегов.
    Синонимы я бы пока делать не стал. Это сильно усложнит реализацию и попутно ухудшит производительность. Насколько это все нужно?

    От массы проблем с производительностью и тяжеловесными выборками можно избавиться, используя только таблицу тегов и отдельную базу на том же Redis. Таблица тегов потребуется все равно, если нам нужно будет производить поиск по тегам не по полному тегу. Это может потребоваться, например, для автодополнения или других специфичных случаях.

    Пойдет такая схема?

    P.S. Прошу активнее высказываться в этой теме, так как функция в общем довольно популярная и нужная, а реализация ее не столь сложна, сколько требует оценки нужности каких-то фич, сильно влияющих на производительность. В любом случае система тегов (если делать ее только на MySQL) негативно влияет на производительность. Поэтому строить функциональное, но сильно просаживающее сервер, решение - не правильно и не нужно. Таким образом, нужно как-то выбрать золотую середину :)
     
  13. guiltar

    guiltar Местный

    Регистрация:
    15.04.11
    Сообщения:
    137
    Симпатии:
    231
    Может правда лучше на Redis сделать? или на Mongo. Уж если делать так надо с размахом и с потенциалом для роста. Я бы тоже подключился, но только если это будет выдерживать хайлоад и большие базы.
     
  14. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    На Redis это делается в общем не сложно. Я еще не проверял, но не думаю, что там будут серьезные грабли. Есть мелочь в виде невозможности поиска по частичному значению/ключу. Поэтому, если нужно будет производить поиск по неполному тегу, то есть два варианта:
    1. Использовать таблицу MySQL параллельно аналогичной таблице в Redis.
    2. Строить свой велосипед полностью на Redis. При этом придется создать таблицу, в которой будут храниться как бы массивы символов. Плюс будет таблица с ключами по имени теги и со списками значений (символов) к каждому ключу. Как-то так. В общем непонятный монстр.

    Проще использовать первый вариант и не мучиться.

    Минус редиса в том, что он потребует выделенного сервера (хоть виртуального, хоть железного), а на шареде работать уж точно не будет. Но в качестве плюса - выдержит без особых проблем большие массивы тегов.
     
  15. guiltar

    guiltar Местный

    Регистрация:
    15.04.11
    Сообщения:
    137
    Симпатии:
    231
    так а смысл тегов теряется, если нет больших массивов данных.
    для небольшого форума и разделение разделами прекрасно упорядочивает контент.
     
  16. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    Нет. Это не так. Ключевые слова, метки, теги - не важно, как они называются, позволяют найти схожие темы. Никакое разделение на разделы не может выделить схожие темы по тегам. Конечно, теги не всем нужны. Например, на этом форуме теги в общем не будут иметь большого смысла, хотя и смогут немного упорядочить контент. С другой стороны чуть ли не для каждой темы нужно будет делать свой уникальный набор тегов, что в результате приведет к их обесцениванию. Вообще много использование десятков тысяч тегов, да даже несколько тысяч, уже выходит за рамки разумного, так как не позволяет сделать эффективным облако и т.д. Ведь тег полезен только в том случае, когда он указывает на множество сходного контента. Если форум уж очень разносторонен, то количество тегов может быть значительным. В этом случае можно вообще начинать рассматривать вариант, когда в каждом крупном разделе будут только свои наборы тегов - по аналогии с префиксами.

    По большому счету большой массив данных тут только один получается при любом раскладе - таблица линков. Все остальное - мелочь, которую любая СУБД переварит без особых проблем. И дело тут не только в большом количестве записей в таблице линков. Просто либо нужно делать много выборок из этой таблицы (например, найти все похожие темы по всем тегам), либо делать неоптимальный джойн, который при большом количестве записей заставит MySQL сильно расходовать большой объем памяти и т.д. и т.п.

    Кстати, можно вообще делать сразу универсальный вариант, когда фактически вся логика работы будет в модели и в датарайтере, а непосредственно взаимодействие с базой данных будет в отдельном классе, который будет в зависимости от доступности (настройки) использовать MySQL или Redis. Изврат, конечно, но это и будет универсальным решением. При этом можно будет предусмотреть конвертацию базы из MySQL в Redis и обратно.
    Блин, чет меня уже понесло... :)
     
  17. Yoskaldyr

    Yoskaldyr Пользователь

    Регистрация:
    27.09.10
    Сообщения:
    1 921
    Симпатии:
    1 163
    Версия XF:
    1.0.4
    О Редис сразу забудьте - с ним Вы повышаете требования по памяти к конфигу сервера в разы, Redis - memory only (да с зеркалированием на диск ,но все равно вся база должна помещаться в память), следовательно под него понадобится ну очень много свободной памяти для большого количества тегов. Хотя система тегов хорошо ложится в структуру сетов.

    Поэтому если использовать что-то альтернативное, то лучше монго (может и коуч подойдет - не знаю, его не тестировал сильно).

    Но все равно изначально все равно надо писать на мускуле. Использовать сеты тегов (строка тегов через запятую отдельным полем) в мускуле или нет будет зависеть от того необходимо ли будет выводить теги для каждой темы в списке тем или нет.
     
  18. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    Эм... А как же высоконагруженные проекты? :)
    И я выше уже говорил, что нет смысла в очень большом количестве тегов. Ну пусть их будет 10000. Допустим, по 10 символов по 2 байта на символ. Получим чистых данных 10*2*10000 = 200000 - это всего лишь 200 Кбайт, если грубо. Не знаю, сколько будет занимать индекс, но пусть будет в 2 раза больше размера данных. Плюс усушка и утряска. Ну будет 1 Мбайт. Это на примере MySQL.
    Теперь прикинем, сколько будет весить таблица линков (на примере MySQL). Например, будет 1 млн тем. Каждая тема пусть содержит 5 тегов. Тогда получим 5 миллионов записей. Теперь прикинем, каков будет размер таблицы. Пусть будут 3 поля: tag_id (int), tag_content (int), content_type (set). Тогда получим 4+4+1 байта на одну запись. Умножим это на 5 млн. В результате таблица будет весить около 45 Мбайт. Не знаю, сколько будут весить индексы. Пусть весят в два раза больше. Имеем 1 Мб на первую таблицу и 135 Мб на вторую таблицу. Округлим это до 150 Мбайт. Разве это не подъемно даже для простой VDS?
    При этом даже большое количество тегов (даже 100 тысяч) на вторую таблицу в общем никак не влияет. Ну увеличится размер первой таблицы в 10 раз? Это не критично.
    Что-то народ его не сильно жалует для таких задач, как теги... Да и он сложнее вроде как (больше команд требуется выполнить и т.д.). Если честно, то не знаю в реальной работе ни тот, ни другой. Сужу лишь поверхностно по разным статьям и обсуждениям.
    Да пусть будет. В общем оно не сильно мешает. В крайнем случае можно сделать его не в реальном времени. Т.е. с отложенной синхронизацией или синхронизацией по запросу. Т.е., когда понадобится, тогда и синхронизировать (при просмотре темы можно сформировать заново эту строку, если все равно будем искать похожие), а при отображении списка тем можно показывать и слегка устаревшую информацию - для актуальных тем синхронизация пройдет быстро, а для неактуальных (до которых пользователи не доберутся в течение дня, например) - по крону раз в сутки обновится.

    А писать на мускуле - это я и сегодня напишу, наверное. Там ведь элементарные запросы. Просто выжимать там оптимальный вариант практически невозможно. Схемы в общем понятные и уже отработанные везде и всеми. Выше я описал общую структуру. Ничего нового я там не изобрел. На первое время можно не заморачиваться отложенной синхронизацией а "влоб" сделать также, как и в булке - при удалении/изменении пройтись по затронутому контенту и сформировать заново строку тегов.
     
  19. Yoskaldyr

    Yoskaldyr Пользователь

    Регистрация:
    27.09.10
    Сообщения:
    1 921
    Симпатии:
    1 163
    Версия XF:
    1.0.4
    преждевременная оптимизация - зло. И высоконагруженный проект всегда допилит под себя.
    не считайте с потолка. сначала попробуйте. У Вас пока что только предположение (даже не теория). Вы забыли такое важный момент как фрагментация в памяти и битность.
    Так что на данный момент, сразу говорю - забудьте об редисе (кстати с темиже пхп расширениями для редиса не все так просто как хотелось-бы). Редис решение для хайлоада - да, но определенно не всегда, у него тоже есть свои бока, но их надо знать.
    Да и в принципе надо вообще забыть о хайлоаде - а просто написать правильно и все.
    Вот и пишите на мускуле :)

    P.S. Основной плюс сетов вместе с контентом, что почти нигде не увеличивается количество допзапросов. Но это только мое субъективное мнение - пишите как именно Вам кажется правильным.
     
  20. mono

    mono Местный

    Регистрация:
    21.02.12
    Сообщения:
    20
    Симпатии:
    6
    Версия XF:
    1.4.10
    Добрый День.
    Хотел поинтересоваться планируется ли релиз задуманного плагина?
    Пока все, что есть под XF для тегов не работает как хотелось бы.
     

Поделиться этой страницей