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

34

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

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

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

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

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

entities performance

— rafamd
источник

6

Я хотел бы видеть ответы, подкрепленные фактическими метриками.

— mpdonadio

Думаю, мы собрали очень конструктивные и информативные комментарии по этому вопросу. Тем не менее, я подожду один или два дня, прежде чем пометить ответ, поскольку что-то внутри меня настаивает на том, что сохранение одного или двух наиболее тяжелых полей отдельно (несмотря на то, что они могут быть повторно использованы) может быть хорошей идеей :) ... особенно зная тех Поля могут легко вырасти на 5, 10 или 20 миллионов единиц в год.

— rafamd

24

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

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

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

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

— Berdir
источник

Привет Бердир, спасибо за ваш ответ. Я не знал об этих накладных расходах по количеству полей. Итак, мы должны попытаться использовать как можно больше, но все же, разве мы не должны пытаться разделить тех, кого мы знаем, самые тяжелые? Я не знаю много о монго и тому подобном, но действительно ли им все равно, какой размер группы они должны запросить? Благодарность !

— rafamd

Я на самом деле не знаю. Зависит, наверное. Проведение теста, как предложено MPD, не может быть плохой идеей. Вы могли бы даже сравнить это очень низкоуровнево прямо в Mysql. Создайте две таблицы с тем же форматом и индексами, что и у таблиц данных поля, запишите 10-метровые (убедитесь, что на самом деле используются разные значения для entity_id) в одну, а 5-метровую во вторую. Затем сравните производительность записи и производительность чтения (на основе entity_id или индекса). Я подозреваю, что производительность чтения будет почти одинаковой благодаря индексу, но производительность записи может иметь значение.

— Бердир

Тем не менее, наличие нескольких полей более или менее не будет иметь большого значения, поэтому, если вы чувствуете себя более комфортно, это не должно быть проблемой.

— Бердир

Пишет сложная часть, поэтому моя рекомендация о проведении теста. Что может быть нелогичным, так это тот факт, что MySQL удаляет кэшированные записи на основе таблицы, а не строки (последний раз, когда я проверял). Я не уверен, что будет больше влияния, накладные расходы памяти нескольких полей и таблиц или пропуски кэша от записи в одну и ту же таблицу. Это, безусловно, зависит от трафика / использования. Системы с несколькими кэшами (кэш Drupal, код операции APC, пользователь APC, кэш запросов MySQL, memcached, лак и т. Д.) Делают решения на основе кишок очень сложными без профилирования.

— mpdonadio

это больше не так: drupal.org/node/1040790

— jackbravo

13

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

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

— BetaRide
источник

Привет @ BetaRide, спасибо за понимание. О 2), мы уже пытаемся минимизировать количество полей для каждого типа контента, и это не совсем то, что мы обсуждаем здесь. Реальная сделка заключается в следующем: должен ли я слепо повторно использовать поля, когда это возможно, или я должен стараться (по крайней мере) оставить самые тяжелые одно или два отдельных (даже если они могут легко быть одинаковыми, например: они на самом деле имеют одинаковые имена и т. Д.). Да, монго должно быть нашей последней альтернативой на данный момент :)

— rafamd

5

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

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

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

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

— mpdonadio
источник

2

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

— jozwikjp
источник

2

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

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

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

— Андре Баумайер
источник

1

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

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

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

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

— Waterskier19
источник

0

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

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

— joevallender
источник

Привет @drupaljoe, спасибо за ваш ответ. Ожидаемый трафик сложно оценить, потому что это совершенно новый сайт. Он разрабатывается с большой тщательностью, и мы ожидаем некоторого успеха, поэтому, скажем, нам удалось привлечь около двухсот одновременно работающих пользователей (большинство из которых прошли проверку подлинности). Это именно то, о чем я думал. Запрашивать эту огромную таблицу, должно быть, непросто, поэтому, возможно, нам следует создать архитектуру для повторного использования тех полей, которые не будут слишком сильно расти, и отделить те, которые будут содержать больше данных. Что можно считать слишком много? 1 миллион ? 100 миллионов? 300000000 ? ...

— rafamd

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

— joevallender

0

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

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

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

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

— Оскар
источник

-3

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

— purab
источник

1

В Drupal 7 они начали использовать Doctrine ORM ... нет, они этого не сделали. Drupal 8 даже не использует Doctrine

— Клайв

«Doctrine всегда возвращает объект из всех отображаемых данных», также является ложным утверждением. Объекты могут быть аннотированы для указания доктрине, что поведение по умолчанию не подходит. Не то чтобы это было ужасно актуально, учитывая, что, как говорит Клайв, Drupal не использует Doctrine.

— Летарион