Який хороший баланс між повторним використанням полів та створенням нових у контексті масштабованості полів?

Я прочитав таку фразу на веб-сайті:

Замість додавання нових полів до типу вмісту, додавання вже існуючих полів є кращим варіантом для зменшення складності системи та покращення масштабованості.

І виникають певні сумніви.

У системі, яку ми розробляємо, ми маємо можливість повторно використовувати поле через 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 вузлів займуть майже годину. Якщо вам доведеться оновити 100000 вузлів, це велика проблема.
3. Якщо ви думаєте, що проблема з кількістю полів торкнеться вас, вам слід серйозно задуматися над написанням власного польового сховища або просто не використовувати поля. (Ви все ще можете змусити ваш вузол працювати з видами з додатковими зусиллями.)
4. Слово про MongoDB. Це дуже цікавий проект, і я сподіваюся, що він перетвориться на олімпійські програми великих БД. На жаль, порівняно зі зрілістю MySql або PgSql це дитина. Будьте готові мати справу з дуже молодим продуктом.

Якщо ви дійсно переживаєте, що буде, то я думаю, що моделювання в порядку.

Отримайте обліковий запис у Rackspace Cloud, Amazon, Linode або будь-якому іншому, де ви зможете легко запустити VPS. Зробіть два однакові екземпляри. Встановіть Drupal на кожному. Створіть кілька типів фіктивного вмісту та налаштуйте поля в одному напрямку, а в іншому - в іншій. Використовуйте модуль devel, щоб створити завантажений вміст. Відрегулюйте параметри продуктивності, щоб переконатися, що Drupal кешує, якщо потрібно. Запустіть mysqltuner і відрегулюйте MySQL для кожної рекомендації. Двічі перевірте параметри PHP та APC, щоб ви не отримували своп і не керували кешем APC.

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

Симуляції ніколи не є ідеальними, але вони можуть привести вас у правильному напрямку.

Одне питання зі масштабованістю в полях при використанні індексів для кожного поля таблиці в кожному полі створеної таблиці. Індекс кластеризованого первинного ключа є складовою більшості полів, тоді він створював окремі індекси для кожного поля окремо. Індекси створюють тонну накладних записів для бази даних, і в більшості випадків ніколи не використовуються.

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

Немає переваги від продуктивності в розділенні цих даних на кілька таблиць при використанні InnoDB (MyISAM відрізняється через блокування таблиці). Отже - якщо ви знаєте, у вас буде багато подібних типів вмісту з подібними полями (конфігурації яких також будуть однаковими, можливо, відрізнятимуться лише міткою) повторно використовуйте свої поля!

Це також може полегшити створення шаблону через подібні атрибути вузла.

Тільки поділяючись моєю історією, ми використовуємо Drupal Commerce і маємо приблизно 40 полів у нашому варіанті продукту (Sku), а потім ще 460 (так, божевільно) на нашому Дисплеї товарів. У нас було кілька поглядів на порівняння продуктів, які розглянули б усі ці сфери. Без кешування деякі завантаження сторінок можуть зайняти до хвилини!

Однак це спрацювало. Якщо ви використовували кешування та 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.