Каков хороший баланс между повторным использованием полей и созданием новых в контексте масштабируемости полей?

Я прочитал следующую фразу на сайте:

Вместо добавления новых полей к типу контента, добавление существующих полей является лучшим вариантом для снижения сложности системы и улучшения масштабируемости.

И некоторые сомнения возникают.

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

Сколько рядов будет разумным максимумом, к которому нужно стремиться при проектировании? Таким образом, мы могли бы решить, когда повторно использовать поля, а когда создавать новые (хотя шанс повторного использования есть).

Количество данных в поле обычно не является проблемой. Если вы беспокоитесь об этом, посмотрите на альтернативные плагины для хранения на местах или напишите свои собственные. Например, MongoDB , который может иметь дело практически со всем, что вы в него вложите. Например, используется на http://examiner.com .

Однако реальная проблема заключается в количестве полей, которые у вас есть. Поскольку в настоящее время в Drupal 7 полная конфигурация полей всех полей, независимо от того, загружены они или нет, извлекается из кэша при каждом отдельном запросе.

Я видел сайты с 250+ полями, где загрузка и десериализация конфигурации полей занимает 13 МБ + памяти.

Изменить: Кэш информации о полях был улучшен (см. Http://drupal.org/node/1040790 ) в Drupal 7.22, из кеша загружаются только поля пакетов, которые отображаются на определенной странице, и они отдельные записи кэша. Это работает, только если нет неправильных вызовов API, которые запрашивают экземпляры между несколькими пакетами.

Я полностью согласен с Бердиром. Вот мой опыт работы с проектом с миллионами строк и 30-40 полями на некоторых типах узлов.

1. Количество строк в таблице полей не является большой проблемой для производительности чтения, так как все поля выбираются по первичному ключу.
2. Количество полей на тип узла может быстро перерасти в большие проблемы с производительностью при написании новых узлов. Наличие более 30 полей для одного типа узла приводит к более 60 операторам INSERT при создании нового узла. Это займет несколько секунд, чтобы завершить. Если вы создаете много данных, это ухудшит вашу производительность. Массовая вставка из 1000 узлов займет почти час. Если вам нужно обновить 100 000 узлов, это большая проблема.
3. Если вы думаете, что проблема количества полей поразит вас, вам следует серьезно подумать о написании собственного хранилища полей или просто не использовать поля. (Вы все равно можете заставить свой узел работать с представлениями, приложив дополнительные усилия.)
4. Несколько слов о MongoDB. Это очень интересный проект, и я надеюсь, что он превратится в олимп больших БД. К сожалению, по сравнению со зрелостью MySql или PgSql это ребенок. Будьте готовы иметь дело с очень молодым продуктом.

Если вы действительно беспокоитесь о том, что произойдет, то я думаю, что симуляция в порядке.

Получите учетную запись в Rackspace Cloud, Amazon, Linode или в любом другом месте, где вы можете легко раскрутить VPS. Сделайте два одинаковых экземпляра. Установите Drupal на каждом. Создайте несколько фиктивных типов контента и настройте поля одним способом в одной системе, а другим - в другой. Используйте модуль devel для создания большого количества контента. Отрегулируйте настройки производительности, чтобы убедиться, что Drupal кэширует по мере необходимости. Запустите mysqltuner и настройте MySQL для каждого в соответствии с рекомендациями. Дважды проверьте настройки PHP и APC, чтобы не использовать swap и не менять кэш APC.

Как только вы получите хорошую базовую конфигурацию для каждого, начните моделировать трафик (как обычных посетителей, так и обновлений администратора) с помощью wget и drush, а затем профилируйте.

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

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

другой совет: наличие большого количества полей вызовет проблемы и со многими различными модулями. Например, графический интерфейс Token задержит ваш браузер на несколько минут, если вы попытаетесь изменить, например, псевдонимы URL. Такое поведение можно увидеть на всех страницах, где токен будет загружен и отображен (включая devel - dpm () и т. Д.)

При использовании InnoDB нет никакого выигрыша в производительности при распределении этих данных по нескольким таблицам (MyISAM отличается из-за блокировки таблиц). Итак, если вы знаете, что у вас будет много похожих типов контента со схожими полями (конфигурации которых также будут одинаковыми, возможно, будут отличаться только маркировкой), повторно используйте ваши поля!

Это также может упростить создание шаблонов из-за похожих атрибутов узла.

Просто поделившись своей историей, мы используем Drupal Commerce и имеем около 40 полей в наших вариантах продукта (Sku), а затем еще 460 (да, сумасшедших) в нашем Product Display. У нас были некоторые виды сравнения продуктов, которые рассмотрели бы все эти области. Без кэширования некоторые загрузки страницы могут занять до минуты!

Однако это сработало. Если вы использовали кеширование и Varnish, время ожидания пользователя было не таким уж плохим.

Основная проблема, с которой мы столкнулись с таким количеством полей, связана с Display Suite, так как это станет очень медленным (иногда без ответа), если мы попытаемся переставить или переместить поле.

К счастью, мы решили немного переформулировать наши продукты, чтобы мы могли надеяться, что максимальное количество полей снизится до диапазона 200-250 для наших самых сложных продуктов (мы занимаемся научными приборами, поэтому необходимы сложные измерения и спецификации) ,

Это интересный вопрос. Я думал об этом раньше, иногда повторное использование поля может быть удобным, если множество похожих полей не «лежат вокруг», но глупо иметь определенный тип контента, который приходится выбирать из большой загрузки данных, которые мы знать не должно быть возвращено в результате.

Мне нужно немного больше информации о проекте, чтобы посоветовать лучшие практики для масштабирования. Каков ожидаемый трафик, сколько пользователей войдет в систему и т. Д.? Например, если весь трафик, за исключением трафика вашего пользователя-администратора, не аутентифицирован и анонимно кэширован

До сих пор я всегда повторно использовал поля, но сейчас рассматриваю возможность использования уникальных полей для каждого типа узла для нового проекта. Я на самом деле хочу, чтобы все было разделено (поля, представления, правила, контексты и т. Д.) Для каждого пакета сущностей. Так что возник вопрос о масштабируемости, который привел меня сюда. Меня утешает редактирование Бердира (улучшен кэш информации о полях ( подробности см. На http://drupal.org/node/1040790 ) с Drupal 7.22, только поля пакетов, отображаемые на определенной странице, загружаются из кеш, и они являются отдельными записями кеша. Это работает, только если нет неправильных вызовов API, которые запрашивают экземпляры в нескольких пакетах).

Я просто хочу отметить, что есть очень интересный модуль, который я месяцами использую на нескольких сложных сайтах: https://www.drupal.org/project/render_cache . Это одна из тех скрытых жемчужин, на мой взгляд.

Как сказано на странице проекта, часть комментариев фактически используется в самом DO.

Итак, учитывая все это, повернется ли консенсус в пользу отдельных областей? Однако, упоминание о DS все еще является обломом. Очень раздражает то, как он экономит через ajax, а не, например, как интерфейс администрирования основного блока обрабатывает переупорядочение. Я чувствую, что это проблема DS, хотя ...

Согласно моему предложению, использование одних и тех же полей в отдельном типе контента - хорошая идея. Потому что это улучшит производительность вашего сайта. В Drupal 7, когда вы используете операцию выбора в то время, использование одних и тех же полей в типе контента действительно полезно для вашего сайта Drupal7.