Ik sprak met de database-architect van wordpress.com, de hostingservice voor WordPress. Hij zei dat ze begonnen met één database, waarin alle klanten samen werden gehost. De inhoud van een enkele blogsite is eigenlijk niet zo veel. Het spreekt vanzelf dat een enkele database beter beheersbaar is.
Dit werkte goed voor hen totdat ze honderden en duizenden klanten kregen, ze realiseerden zich dat ze moesten uitschalen , het runnen van meerdere fysieke servers en het hosten van een subset van hun klanten op elke server. Wanneer ze een server toevoegen, zou het gemakkelijk zijn om individuele klanten naar de nieuwe server te migreren, maar moeilijker om gegevens te scheiden binnen een enkele database die bij de blog van een individuele klant hoort.
Naarmate klanten komen en gaan, en de blogs van sommige klanten veel activiteit hebben, terwijl andere verouderd raken, wordt het opnieuw in evenwicht brengen over meerdere servers een nog complexere onderhoudstaak. Het monitoren van de grootte en activiteit per individuele database is ook eenvoudiger.
Evenzo een database back-up of herstel . doen van een enkele database met terrabytes aan gegevens, versus individuele databaseback-ups en herstelbewerkingen van elk enkele megabytes, is een belangrijke factor. Overweeg:een klant belt en zegt dat zijn gegevens door SNAFU zijn gehaald vanwege een slechte gegevensinvoer, en zou u alstublieft de gegevens van de back-up van gisteren kunnen herstellen? Hoe zou je één herstellen? klantgegevens als al uw klanten één database delen?
Uiteindelijk besloten ze dat op te splitsen in een aparte database per klant , hoewel complex om te beheren, bood hen meer flexibiliteit en ze hebben hun hostingservice opnieuw ontworpen naar dit model.
Dus, terwijl uit een gegevensmodellering perspectief lijkt het het juiste om te doen om alles in een enkele database te houden, wat databasebeheer taken worden gemakkelijker naarmate u een bepaald breekpunt van gegevensvolume passeert.