В інтернет приходять звичайні люди, вкладають гроші, роблять проекти. І багато проходять через етап вибору CMS, який є окремою великою темою для суперечок і обговорення.
Але от уявімо, що якийсь відсоток з проектів «вистрілює», і на сайт починає котитися трафік наприклад від 10 000 до 30 000 осіб на добу. Та й база сайту неабияк зросла за рахунок великого обсягу контенту.
Сайт починає пригальмовувати і його переносять на виділений сервер, але моніторинг каже що і поточних потужностей замало, база даних пожирає ресурси. Проаналізувавши ситуацію ми бачимо вузьке місце в зберігання даних у вигляді: Entity-attribute-value. Записів в таблиці де зберігаються значення полів вже під мільйон і запити раз у раз потрапляють в -log-slow-queries. CMS була вибрана не остання з рейтингу і грошей було заплачено за ліцензію та й за сам сайт чимало. І що ж робити далі?
Коротко: Модель EAV - Сутність-атрибут-значення - структура БД залишається незмінною, все значення всіх полів зберігаються в одній великій таблиці виду ItemID | FieldID | FieldValue
1. Чи має право на життя модель EAT на відвідуваному ресурсі?
2. Чи є реальні приклади відвідуваних проектів?
3. Як Ви ставитеся до того, що спочатку студія або розробник, не розглядають успішний варіант розвитку подій при виборі технології / CMS?
P.S. Кешування не вирішує проблему повністю.
1. Чи має право на життя модель EAT на відвідуваному ресурсі?
Має, але часто воно має сісдамінов і розробників
2. Чи є реальні приклади відвідуваних проектів?
www.eldorado.ru/
3. Як Ви ставитеся до того, що спочатку студія або розробник, не розглядають успішний варіант розвитку подій при виборі технології / CMS?
Це називається мудаки
P.S. Кешування не вирішує проблему повністю.
Кешування в EAT взагалі ніфіга не допомагає. (Ох, як вантажиться ця бд = ()
eldorado.ru на Бітрікс якщо не помиляюся? Якщо так, то там саме так і йдуть справи зі зберіганням даних.
Ох, як вантажиться ця бд = (ну ось це я про те ж
Ну а що тут такого, що сайт став популярним і не вистачає ресурсів?
З поточними проектами розібралися слава богу. Питання скоріше про вибір технологій (CMS) на майбутні.
Та й взагалі цікаво, почути досвід, тих хто стикався з такими проблемами.
Просто деякі популярні cms якраз використовують модель EAT для зберігання даних.
а можна дізнатися як Ви вирішили цю проблему? яку CMS Ви використовували?
По одному проекту конкретно EAV залишилося жити.
Там UMI.CMS. але більшість модулів (слава богу) реалізовано в обхід ієрархії Юмі, через свої таблиці.
Але в деяких місцях мені довелося переписати Юмі, де вона зверталася до своєї EAV ієрархії. У нових версіях до речі вони виправили те що я переписував сам.
+ ряд інших заходів, я про це писав раніше.
І зараз там основного навантаження конкретно на EAV немає.
Тому і виник даний пост. цікавий досвід інших. Чи варто будувати майбутні рішення і закладати всю ієрархію даних сайту в такому вигляді. Чим далі думаю, тим більше сумніваюся. Але ті ж UMI і Bitrix використовують саме цю модель.
Як розробник я розумію, потрібно плюнути на все, спроектувати нормальну модель даних, без всяких EAV і реалізувати рішення на фреймворку за всіма правилами. Але цей час і більше ресурсів.
При реалізації того ж проекту на базі тієї ж Юмі, часу і ресурсів на багато менше, але чи маю я право вибирати таке рішення якщо воно призведе до серйозних проблем в момент успіху?
Взагалі-то, нічого поганого в EAV я не бачу, потрібно просто правильно її готувати;)
А за описаним Вами, так відразу нічого сказати не можна.
Потрібен аудит коду, запитів і самої бази.
Гальмують запити пошуку і фільтрації даних, в даному випадку доцільно проводити такі операції через зовнішній індексатор.
Рекомендую дивитися в бік Sphinx.
Перед тим, як починати кусати лікті і думати про те, що ж робити зі зростаючою базою, що не може собі з навантаженням, подивитися а чи правильно налаштована СУБД.
Наприклад, MySQL зі стандартними настройками може використовуватися, максимум, як рубрикатор домашньої колекції фільмів.
Тут потрібен тлумачний DBA, що спеціалізується конкретно на Вашій СУБД.
Ну як точку відправлення для MySQL можу порадити tuning-primer.sh або MySQLTuner.
В порядку оффтопіком: Раз вже я заговорив про MySQL, то це досить цікава СУБД в плані різнобічності поглядів. Хтось лається на її гальма, коли розмір бази виростає до 2 Гб, а у мене в MySQL зберігається майже пара сотень мільйонів записів і СУБД не кашляти навіть. Це при тому, що залізяка на якій він крутиться досить посередня.
Завдання у виборі рішення, тобто питання про гіпотетичні проблеми, які виникнуть у разі якщо проект буде відвідуваним.
На рахунок аудиту коду, можна дивитися останні версії UMI.CMS і Bitrix. Як EAV «приготовлена» в них? Я подебажіл останню Юмі 2.8.3, виконали велику роботу, всі запити стали прості (ніяких join'ов), хоч їх і багато (На тестових сайтах дистрибутива до 200. на головній сторінці).
А ось що буде коли все 3 таблиці EAV виростуть в обсязі, ось тут питання.
Так EAV має певні недоліки, пов'язані з вибіркою даних за кількома умовами і угрупованням результату. Все таки потрібно вибрати час і розібратися з цим звіром Сфінксом, але це теж докорінно змінювати Модель роботи з базою даних в CMS, що теж час сили і мізки. (Якщо я звичайно правильно зрозумів призначення Sphinx).
Значить Ви вважаєте, що модель EAV має право жити на навантаженому ресурсі, з урахуванням грамотного коду, запитів і правильному налаштуванні СУБД?
Я, зізнатися чесно, не дуже компетентний у виборі коробкових CMS, тому не можу нічого сказати про EAV в UMI або Бітрікс.
Все більш-менш великі проекти в яких мені довелося взяти участь писалися з нуля на будь-якому open source фреймворку.
Відповідно у нас не було проблем зі зміною моделі або підходу зберігання даних.
А за 200 запитів на сторінку (хоч і простих), ми били один одного по руках :)
На досить великому і відвідуваному проект у нас був свій корпоративний бзік за кількістю запитів - 10-20 штук на сторінку. Всі інші дані повинні прилітати з кеша.
Взагалі у такого підходу для розробки проектів купа плюсів, але є і мінуси:
1. Висока вартість на початковому етапі розробки проекту.
В середньому, над проектом на початковому етапі трудиться команда з 5 чоловік (менеджер проекту, провідний розробник, 2 програміста і дизайнер). Розробка проекту займає від 3 до 9 місяців. Як мінімум, їм всім потрібно платити конкурентну зарплату на весь час розробки.
2. Підтримка проекту.
Так просто написати код, викотити його на сервера і забути про розробників не вийде. Один програміст повинен в будь-якому випадку залишитися на підтримку проекту.
І за скрипти спасибі! Перлової тюнер вже в арсеналі)