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

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

  

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

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

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

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

33 голоса | спросил rafamd 4 SunEurope/Moscow2011-12-04T02:23:40+04:00Europe/Moscow12bEurope/MoscowSun, 04 Dec 2011 02:23:40 +0400 2011, 02:23:40

9 ответов


24

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

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

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

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

ответил Berdir 4 SunEurope/Moscow2011-12-04T19:32:22+04:00Europe/Moscow12bEurope/MoscowSun, 04 Dec 2011 19:32:22 +0400 2011, 19:32:22
13

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

  1. Количество строк в таблице полей не является большой проблемой для производительности чтения, так как все поля извлекаются с помощью первичного ключа.
  2. Количество полей на тип узла может быстро перерасти в большие проблемы с производительностью при записи новых узлов. Если 30+ полей для одного типа узлов приводят к 60+ операторам INSERT при создании нового узла. Это займет несколько секунд. Если вы создаете много данных, это приведет к снижению производительности. Массовые вставки из 1000 узлов занимают почти час. Если вам нужно обновить 100'000 узлов, это большая проблема.
  3. Если вы считаете, что количество проблем с полями поразит вас, вы должны серьезно подумать о написании своего собственного хранилища полей или просто не использовать поля. (Вы можете заставить свой узел работать с представлениями с некоторыми дополнительными усилиями.)
  4. Слово о MongoDB. Это очень интересный проект, и я надеюсь, что он превратится в олимп больших БД. К сожалению, по сравнению со зрелостью MySql или PgSql это ребенок. Будьте готовы к работе с очень молодым продуктом.
ответил BetaRide 5 MonEurope/Moscow2011-12-05T01:28:19+04:00Europe/Moscow12bEurope/MoscowMon, 05 Dec 2011 01:28:19 +0400 2011, 01:28:19
5

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

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

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

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

ответил mpdonadio 7 WedEurope/Moscow2011-12-07T05:09:07+04:00Europe/Moscow12bEurope/MoscowWed, 07 Dec 2011 05:09:07 +0400 2011, 05:09:07
2

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

ответил jozwikjp 1 AMpWed, 01 Apr 2015 01:45:27 +030045Wednesday 2015, 01:45:27
2

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

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

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

ответил Andre Baumeier 6 MaramWed, 06 Mar 2013 06:08:00 +04002013-03-06T06:08:00+04:0006 2013, 06:08:00
1

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

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

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

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

ответил Waterskier19 14 FebruaryEurope/MoscowbFri, 14 Feb 2014 18:19:31 +0400000000pmFri, 14 Feb 2014 18:19:31 +040014 2014, 18:19:31
0

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

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

ответил joevallender 4 SunEurope/Moscow2011-12-04T13:33:03+04:00Europe/Moscow12bEurope/MoscowSun, 04 Dec 2011 13:33:03 +0400 2011, 13:33:03
0

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

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

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

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

ответил Oscar 29 PMpSun, 29 Apr 2018 17:22:55 +030022Sunday 2018, 17:22:55
-3

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

ответил purab 30 J000000Tuesday13 2013, 15:40:11

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132