È una buona idea usare un database per oltre 50.000 negozi?

So che Shopify usa un solo database per tutti i negozi. Ma come possono gestire il loro database con dati così grandi? È una buona idea utilizzare un unico database per oltre 50.000 negozi?

Nota: sto rispondendo dal punto di vista di SQL Server, quindi menziono alcuni concetti specifici di SQL Server, ma credo che tutti questi concetti abbiano equivalenti in altre principali piattaforme RDBMS, con vantaggi e limitazioni simili.

Probabilmente continuerò anche a modificare questa risposta mentre penso ad altri potenziali vantaggi / svantaggi.

Bene, dipende davvero dallo schema, dal volume, ecc. Cosa memorizza esattamente un negozio? In che cosa differisce dalla memorizzazione di dati su circa 50.000 gatti o 50.000 prodotti o 50.000 noci?

Esistono diversi motivi (oltre all'aspetto di per sé) per cui potresti non voler archiviare i dati per 50.000 clienti diversi in un unico database, se in effetti i dati possono essere completamente separati dal cliente (ad esclusione di tabelle di ricerca come codici postali o tabelle specifiche dell'applicazione, che potrebbero andare in un unico database centrale):

• se un cliente supera l'applicazione, non esiste un modo semplice per estrarre solo i propri dati e spostarli in un'altra istanza, server, ecc. per ridimensionarli, a meno che non si pianifichi in anticipo e si divida su qualcosa di simile CustomerIDe si disponga di 50.000 filegroup (si è limitati a 15.000 partizioni comunque, o 1.000 se si utilizza una versione precedente di SQL Server e avere troppi filegroup può essere disastroso ). Si noti inoltre che il partizionamento richiede Enterprise Edition.

• se si scopre che tutti i tuoi clienti sono semplicemente troppo grandi per questa istanza, ridimensionare significa ottenere nuovo hardware e spostare l'intero database lì (e potenzialmente farlo di nuovo lungo la strada).

• l'eliminazione di un cliente può essere ugualmente dolorosa, poiché dovrai eliminare una parte del% di righe da tabelle molto grandi e ciò non sarà economico.

• probabilmente avrai un'ampia distribuzione dei dati dei clienti (un cliente con un miliardo di righe, un altro cliente con 5.000). Questo può portare a cose come lo sniffing dei parametri e le prestazioni dannose che coinvolgono cardinalità e qualità del piano (dal momento che probabilmente riutilizzerai gli stessi piani per le stesse query rispetto a set di dati molto diversi).

• tutti i tuoi clienti sono soggetti agli stessi identici SLA e piani HA / DR. O hai l'intero database in modalità di ripristino completo con backup dei registri n-minute, oppure sei semplice e fai affidamento su backup full + diff. Se è necessario ripristinare a causa di un errore del cliente o se è necessario ripristinare il database in un determinato momento, ciò influisce su ogni singolo cliente.

• vi sono potenziali errori nel recupero dei dati: i bug nei casi in cui le clausole, ad esempio, possono portare a un cliente a vedere i dati di un altro cliente o tutti i dati di altri clienti.

• potrebbero esserci implicazioni legali (alcune aziende avranno requisiti rigorosi in vigore per cui non si collocano i loro dati nello stesso database di qualsiasi altra società, in particolare quelli dei loro concorrenti).

• se la sicurezza dei dati di un cliente è importante, è molto più semplice ottenerlo utilizzando la separazione del database piuttosto che la separazione all'interno di una tabella.

Alcuni vantaggi di avere ciascun cliente in un database separato (o almeno avere più database, ciascuno per un gruppo di clienti):

• in termini di dimensioni, richiederà circa la stessa dimensione sul disco.
• il ridimensionamento è più semplice, poiché è possibile spostare un database (o molti) su un server diverso.
• l'eliminazione di un cliente e tutti i suoi dati equivalgono approssimativamente a DROP DATABASE.
• stai usando più memoria per i piani (o hai meno piani nella cache per cliente), ma almeno quei piani sono rilevanti per i dati nei rispettivi database e sono meno inclini a problemi di statistiche / sniffing dei parametri.
• puoi facilmente avere diversi SLA e piani DR, posizionando alcuni database per intero e altri semplicemente. Anche il ripristino o il ripristino in un determinato momento influisce solo sul cliente.
• puoi facilmente posizionare database diversi (ad esempio, i tuoi clienti con priorità alta) su I / O più veloci. Potresti farlo in un unico database con filegroup, ma è molto più complicato da gestire (almeno IMHO).

Alcuni inconvenienti:

• a parte le dimensioni, probabilmente non vorrai avere 50.000 database su una singola istanza di SQL Server, quindi questo probabilmente significherà ridimensionamento su più server.
• il tempo di avvio aumenta perché è presente un sovraccarico inerente all'avvio di ciascun database.
• l'app deve essere un po 'più intelligente: invece di avere CustomerID sulla clausola where, deve connettersi dinamicamente al database di CustomerID. Questo non è difficile con un livello medio adeguato ma è un cambiamento.
• sì, hai molte copie delle stesse tabelle e procedure, ma codice e schema sono identici nei database, solo i dati sono diversi. Quindi la distribuzione delle modifiche al codice / schema è ora solo un ciclo anziché una singola esecuzione.
• la manutenzione è leggermente diversa quando si gestiscono 50.000 database - di nuovo le dimensioni complessive sono all'incirca le stesse ma il processo deve cambiare - non è possibile solo deframmentare / reindicizzare / eseguire il backup di tutti i 50.000 database contemporaneamente. Detto questo, nel mio lavoro precedente ho gestito istanze con 500-1000 database identici e la differenza tra la gestione di 3 database identici e 750 database identici è semplicemente il tempo impiegato.