Risorse per la frammentazione e il partizionamento del database

Question

Sto lavorando con uno schema di database in esecuzione in problemi di scalabilità. Una delle tabelle nello schema è cresciuta fino a circa 10 milioni di righe e sto esplorando le opzioni di sharding e partizionamento per consentire a questo schema di ridimensionare a set di dati molto più grandi (diciamo, da 1 a 100 miliardi di righe). La nostra applicazione deve anche essere distribuibile su diversi prodotti di database, inclusi, a titolo esemplificativo, Oracle, MS SQL Server e MySQL.

Questo è un grosso problema in generale e mi piacerebbe leggere su quali opzioni sono disponibili. Quali risorse sono disponibili (libri, white paper, siti Web) per le strategie di partizionamento e partizionamento del database?

Answer 1

Sono d'accordo con le altre risposte che dovresti esaminare il tuo schema e gli indici prima di ricorrere allo sharding. 10 milioni di righe rientrano nelle capacità di tutti i principali motori di database.

Tuttavia, se desideri alcune risorse per conoscere l'argomento dello sharding, prova queste:

• Best practice sulla scalabilità: lezioni da eBay
• Randy Shoup sui principi architettonici di eBay - Video e presentazione
• Sito ad alta scalabilità
• Mr. Moore arriva a puntare sullo sharding (quando non farlo)

Answer 2

Sono d'accordo con l'osservazione di Mike Woodhouse secondo cui le dimensioni attuali non dovrebbero essere un problema - e l'interrogante è d'accordo.

La maggior parte dei DBMS commerciali fornisce supporto per tabelle frammentate in un modo o nell'altro, con un nome o più altri. Una delle domande chiave è se esiste un modo ragionevole di suddividere i dati in frammenti. Un modo comune è farlo in base a una data, quindi tutti i valori per, diciamo, di novembre 2008 vanno in un frammento, quelli per ottobre 2008 in un altro e così via. Questo ha dei vantaggi quando arriva il momento di rimuovere i vecchi dati. Probabilmente è possibile eliminare il frammento contenente dati dall'ottobre 2001 (conservazione dei dati per sette anni) senza influire sugli altri frammenti. Questo tipo di frammentazione può anche aiutare con "l'eliminazione dei frammenti"; se la query chiaramente non ha bisogno di leggere i dati da un determinato frammento, allora sarà lasciata non letta, il che può darti un magnifico vantaggio in termini di prestazioni. (Ad esempio, se l'ottimizzatore sa che la query ha una data nell'ottobre 2008, ignorerà tutti i frammenti tranne quello che contiene i dati dell'ottobre 2008.)

Esistono altre tecniche di frammentazione: round robin distribuisce il carico su più dischi, ma significa che non è possibile trarre vantaggio dall'eliminazione dei frammenti.

Answer 3

10 milioni di righe non sono davvero grandi in termini di DBMS e guarderei prima i miei piani di indicizzazione e query prima di iniziare a pianificare una distribuzione fisica di dati con frammenti o partizioni, che non dovrebbe essere realmente necessario fino a quando la tabella cresciuto di un paio di ordini di grandezza.

Tutti gli IMHO, ovviamente.

Answer 4

Nella mia esperienza, i tavoli di grandi dimensioni ti colpiscono sempre sul lato I / O. La soluzione più economica è aggiungere abbastanza indici multi-colonna in modo che tutte le tue query possano ottenere i dati direttamente dall'indice, senza dover caricare le pagine dei dati principali. Ciò rende gli inserimenti e gli aggiornamenti più intensivi di I / O, ma potrebbe essere OK. La prossima opzione facile massimizza la RAM nel tuo server. Nessun motivo per avere meno di 32 GB se il tuo database è grande. Ma alla fine ti ritroverai ancora legato all'I / O e dovrai acquistare molti dischi rigidi e mantenere un complesso schema di partizionamento, che costa una fortuna tra hardware e manodopera. Spero che ci sia un'alternativa migliore in questi giorni - spostare il database dalla rotazione dei dischi rigidi alle unità a stato solido SLC - questo dovrebbe rendere le tue letture e scritture casuali cento volte più veloci delle unità SAS di fascia alta e rimuovere l'I / O collo di bottiglia. Gli SSD partono da $ 10 per gigabyte, quindi spenderai qualche centesimo ma è ancora molto più economico delle SAN, ecc.