Ho parlato con l'architetto del database di wordpress.com, il servizio di hosting per WordPress. Ha detto che hanno iniziato con un database, ospitando tutti i clienti insieme. Dopotutto, il contenuto di un singolo blog non è poi così tanto. È logico che un singolo database sia più gestibile.
Questo ha funzionato bene per loro fino a quando non hanno ottenuto centinaia e migliaia di clienti, si sono resi conto che avevano bisogno di scalare , eseguendo più server fisici e ospitando un sottoinsieme dei propri clienti su ciascun server. Quando aggiungono un server, sarebbe facile migrare i singoli clienti sul nuovo server, ma più difficile separare i dati all'interno di un unico database che appartiene al blog di un singolo cliente.
Poiché i clienti vanno e vengono e i blog di alcuni clienti hanno un volume elevato di attività mentre altri diventano obsoleti, il ribilanciamento su più server diventa un lavoro di manutenzione ancora più complesso. Anche il monitoraggio delle dimensioni e dell'attività per singolo database è più semplice.
Allo stesso modo eseguendo un backup o ripristino del database di un singolo database contenente terrabyte di dati, rispetto ai singoli backup e ripristini di database di pochi megabyte ciascuno, è un fattore importante. Considera:un cliente chiama e dice che i suoi dati sono stati cancellati da SNAFU a causa di un errore di immissione di dati e potresti ripristinare i dati dal backup di ieri? Come ripristineresti uno dati del cliente se tutti i tuoi clienti condividono un unico database?
Alla fine hanno deciso di dividere in un database separato per cliente , sebbene complesso da gestire, ha offerto loro una maggiore flessibilità e hanno riprogettato il loro servizio di hosting su questo modello.
Quindi, mentre da una modellazione dei dati prospettiva sembra la cosa giusta da fare per mantenere tutto in un unico database, un po' di amministrazione del database le attività diventano più facili man mano che si supera un determinato punto di interruzione del volume di dati.
