Чи може бути гарною ідеєю створити нову таблицю для кожного клієнта веб-сайту?

10

Це напівгіпотетично, і оскільки я не маю досвіду роботи з масивними таблицями баз даних, я не маю уявлення, чи це жахливо з якихось причин. Про ситуацію:

Уявіть веб-додаток - скажімо, бухгалтерське програмне забезпечення - яке має 20 000 клієнтів, а кожен клієнт має 1000+ записів у таблиці. Це 20 мільйонів рядків, які, на мою думку, можуть, безумовно, уповільнити складні запити.

У такому випадку, чи має сенс створювати нову таблицю в базі даних для кожного клієнта? Як бази даних реагують на 20k (або більше!) Таблиць?

web-applications database-development

— Буде
джерело

15

Взагалі кажучи, ні, немає сенсу мати таблицю (я думаю, ви тут фактично маєте на увазі базу даних) на кожного клієнта. 20 мільйонів рядків порівняно мало для таблиці бази даних. Швидкість запитів проти цього не повинна бути проблемою, якщо база даних буде належним чином налаштована (індексована) та запити правильно зібрані. Яку б вигоду ви не отримали від розділення їх, компенсується додатковою складністю управління 20 000 індивідуальних баз даних. Наприклад, що відбувається, коли ви хочете змінити структуру таблиці? Тепер ви повинні це зробити 20 000 разів!

Гірший випадок, якщо ви врешті-решт виявите, що розмір бази даних стає проблемою, ви завжди зможете згодом розкласти їх в окремі бази даних.

— ГрандмайстерB
джерело

ні, я буквально мав на увазі таблиці в базі даних. Я не можу уявити собі причину для створення бази даних для кожного клієнта. А якщо 20 мільйонів рядків мало, що велике? І що ти робиш у той момент?

— Буде

1

@ChrisF, саме - є дуже багато випадків, коли технологія або бізнес-модель вимагає окремих баз даних на клієнта. Але я не можу придумати причину для окремих таблиць в одній БД.

— гросмайстерB

1

@GrandmasterB - Я думаю, що @Will задає неправильне запитання.

— ChrisF

1

@Will: Якщо можливо, перейдіть на засідання групи користувачів Oracle або еквівалент для будь-якої іншої бази даних високого класу. Ви побачите, що ваші ідеї "малого" та "великого" потребують великої перебудови. Це сталося зі мною. Підказка: якщо він вміщується на одному диску, він не є великим за стандартами DBA.

— Девід Торнлі

1

@Gorton, InnoDB, як правило, вважається кращим за надійність та сумісність, MyISAM за швидкість. Тож вам дійсно потрібно оцінити різні механізми зберігання даних, виходячи з очікуваного використання бази даних вашої програми.

— гросмайстерB

5

Звучить погана ідея.

Не намагайтеся перехитрити базу даних з подібними екзотичними конструкціями. Двигуни бази даних розроблені з великою кількістю оптимізацій для роботи з великими наборами даних. Наприклад, те, що ви описуєте, звучить надзвичайно близько до спроби вручну реалізувати індекси. Просто використовуйте індекси, надані DB Engine, вони реалізовані набагато краще, ніж ви, ймовірно, зможете зробити самостійно, і це не потребуватиме стільки обслуговування.

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

— JohnFx
джерело

Я б подав пропозицію один раз за кожен ваш два абзаци, якщо це дозволено.

— Девід Торнлі

3

Ось стаття, яку я завжди закликаю людей читати, коли вони задають це питання:

http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html

— Мчл
джерело

Я не здогадувався, що БД створює фактичний файл за таблицею = x

— Буде

1

Це може залежати від фактично використовуваних RDBMS. MySQL робить це (до трьох файлів у таблиці, якщо ви використовуєте MyISAM). Інші не можуть.

— Mchl

Корпоративна версія SQL Server зробить це, якщо створити його таким чином, але не автоматично.

— JeffO

Oracle точно не робить цього.

— користувач281377

Oracle може це зробити так само, як це може зробити SQL Server , але я не уявляю, чому ви коли-небудь розробляли свою схему, щоб мати один файл в таблиці. Розбиття бази даних на кілька файлів має сенс, але не один файл в таблиці.

— Дін Хардінг

1

IMHO, одна таблиця не повинна бути проблемою, тому не створюйте проблеми там, де такої не існує - поки що. Ви можете багато зробити для покращення продуктивності. Ви можете розділити одну таблицю на кілька файлів на основі clientID або поля дати, щоб допомогти з IO. Ваш db не повинен відслідковувати, оптимізувати та кешувати 20 000 різних операторів sql для кожного запиту, який вам знадобиться на сайті. Індексувати можна за клієнтом. Клієнти 20K можуть заплатити за багато обладнання.

Для цього типу таблиць може використовуватися db типу NoSQL.

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

— JeffO
джерело

`Ви можете розділити одну таблицю на кілька файлів на основі clientID або поля дати, щоб допомогти з IO.` - не впевнений, що ви маєте на увазі під цим. Будь-яке уточнення?

— Буде

Кілька файлів в операційній системі. Сервер може більше читати / записувати у багато файлів, а не лише в один.

— JeffO

Я думаю, я мав на увазі: я ніколи не чув про таке, де я можу отримати більше інформації про це? :-) Але я піду гугл ~

— Буде

msdn.microsoft.com/en-us/library/ms345146(v=sql.90).aspx Ви можете зіткнутися з проблемами продуктивності резервного копіювання, якщо індекси знаходяться в окремих файлах, ніж у таблицях, які вони індексують (або, можливо, накопичувачі?).

— JeffO

0

Це дійсно поганий підхід.

Розділіть таблицю вертикально, 2 сервери баз даних: один для непарних ідентифікаторів користувачів, а інший для парних повинні працювати добре (дані не пов'язані між користувачами).

Сортуйте дані по user_id і, якщо це неможливо, отримайте величезну кількість оперативної пам’яті або SSD дисків.

— Славек
джерело