Rozmawiałem z architektem baz danych z wordpress.com, usługi hostingowej dla WordPressa. Powiedział, że zaczynali od jednej bazy danych, obsługującej wszystkich klientów razem. W końcu zawartość jednego bloga to naprawdę niewiele. Jest zrozumiałe, że pojedyncza baza danych jest łatwiejsza w zarządzaniu.
To działało dla nich dobrze, dopóki nie zdobyli setek i tysięcy klientów, zdali sobie sprawę, że muszą skalować , obsługujące wiele serwerów fizycznych i obsługujące podzbiór swoich klientów na każdym serwerze. Po dodaniu serwera łatwo byłoby przenieść poszczególnych klientów na nowy serwer, ale trudniej byłoby oddzielić dane w ramach jednej bazy danych, która należy do bloga indywidualnego klienta.
Ponieważ klienci przychodzą i odchodzą, a na blogach niektórych klientów występuje duża aktywność, podczas gdy inne stają się nieaktualne, przywracanie równowagi na wielu serwerach staje się jeszcze bardziej złożoną pracą konserwacyjną. Monitorowanie rozmiaru i aktywności w poszczególnych bazach danych jest również łatwiejsze.
Podobnie robienie kopii zapasowej lub przywracania bazy danych jednej bazy danych zawierającej terabajty danych, w porównaniu do pojedynczych kopii zapasowych i przywracania poszczególnych baz danych o wielkości kilku megabajtów każda, jest ważnym czynnikiem. Zastanów się:klient dzwoni i mówi, że jego dane zostały uszkodzone przez SNAFU z powodu złego wprowadzenia danych i czy możesz przywrócić dane z wczorajszej kopii zapasowej? Jak możesz przywrócić jeden dane klienta, jeśli wszyscy Twoi klienci współdzielą jedną bazę danych?
W końcu zdecydowali, że podział na oddzielną bazę danych na klienta , choć skomplikowane w zarządzaniu, zapewniało im większą elastyczność i przebudowali swoją usługę hostingową na ten model.
Tak więc podczas modelowania danych z perspektywy wydaje się, że jest to właściwe, aby zachować wszystko w jednej bazie danych, trochę administracji bazy danych zadania stają się łatwiejsze, gdy przekroczysz pewien punkt przerwania objętości danych.
