Говорих с архитекта на базата данни от wordpress.com, хостинг услугата за WordPress. Той каза, че са започнали с една база данни, като хостват всички клиенти заедно. В крайна сметка съдържанието на един блог сайт наистина не е толкова много. Разбираемо е, че една база данни е по-управляема.
Това работи добре за тях, докато не получиха стотици и хиляди клиенти, те разбраха, че трябва да мащабират , работещи с множество физически сървъри и хостващи подмножество от своите клиенти на всеки сървър. Когато добавят сървър, би било лесно да се мигрират отделни клиенти към новия сървър, но по-трудно да се отделят данни в рамките на една база данни, която принадлежи към блога на отделен клиент.
Тъй като клиентите идват и си отиват и блоговете на някои клиенти имат голям обем активност, докато други застояват, балансирането на множество сървъри се превръща в още по-сложна работа по поддръжката. Наблюдението на размера и активността за отделна база данни също е по-лесно.
По същия начин правите резервно копие или възстановяване на база данни на единична база данни, съдържаща терабайти данни, в сравнение с отделни резервни копия на база данни и възстановяване на няколко мегабайта всяко, е важен фактор. Помислете:клиент се обажда и казва, че данните му са били SNAFU-а поради някакво лошо въвеждане на данни и бихте ли могли да възстановите данните от вчерашния архив? Как бихте възстановили един клиентски данни, ако всичките ви клиенти споделят една база данни?
В крайна сметка те решиха, че се разделят в отделна база данни за всеки клиент , макар и сложен за управление, им предложи по-голяма гъвкавост и те преструктурираха своята хостинг услуга към този модел.
И така, докато от моделиране на данни от перспектива изглежда като правилното нещо да се държи всичко в една база данни, някаква администрация на база данни задачите стават по-лесни, когато преминете определена точка на прекъсване на обема на данните.
