Ho sentito che le prestazioni di database relazionali non frammentati come MySQL o PostgreSQL "si rompono" oltre i 10 TB.
Ho il sospetto che esistano limiti in quanto tali in quanto non si verificherebbero Netezza, Greenplum o Vertica, ecc. Tuttavia, vorrei chiedere se qualcuno qui ha un riferimento a qualsiasi documento di ricerca o case study formali in cui tali limiti sono quantificati.
Risposte:
Non esiste una risposta semplice alla tua domanda, ma qui ci sono alcune cose a cui pensare.
Innanzitutto, la scala non è l'unica cosa di cui preoccuparsi. Quello che fai con i tuoi dati è. Se disponi di 500 tabelle da 30 TB di dati e stai eseguendo un semplice OLTP con pochissimi rapporti, non credo che avrai troppi problemi. Esistono database da 32 TB su PostgreSQL. Tuttavia, allo stesso tempo le prestazioni diminuiranno leggermente perché deve colpire il disco su tutto. Allo stesso modo se hai 50 TB se i dati ma hai un set comunemente colpito di circa 100 GB, puoi costruire un server con RAM sufficiente per mantenere in memoria quella parte del db e sei d'oro.
D'altra parte, se stai cercando di estrarre la modalità (il valore più comune) da 1 TB di dati, non importa quale sistema stai usando, questo sarà doloroso con o senza sharding. (Modifica: la frammentazione potrebbe, in effetti, aggravare questo problema . )
I maggiori problemi che incontrerai con enormi database su MySQL e PostgreSQL riguardano il fatto che nessuno dei due supporta il parallelismo intraquery. In altre parole, una query viene eseguita come blocco singolo da un singolo thread e non può essere suddivisa in parti ed eseguita separatamente. Questo è spesso un problema quando si eseguono query analitiche di grandi dimensioni su grandi quantità di dati. È qui che Postgres-XC e Green Plum vengono in soccorso poiché separano lo stoccaggio dall'esecuzione e possono farlo a livello di coordinatore. Nota che Postgres-XC e Green Plum usano essenzialmente lo sharding internamente, ma i coordinatori applicano tutta la coerenza a livello globale.
Con il parallelismo intraquery è possibile suddividere la query, far processare parti di processori / canali I / O su disco diversi e riportare parti del set di risultati da assemblare e restituire all'applicazione. Ancora una volta, questo è di solito più utile nei carichi analitici piuttosto che nell'elaborazione delle transazioni.
La seconda cosa è che alcuni sistemi, come Vertica o Greenplum, memorizzano colonne di informazioni insieme. Ciò rende il sistema più difficile da utilizzare dal punto di vista OLTP e diminuisce le prestazioni lì, ma aumenta drasticamente le prestazioni per grandi carichi di lavoro analitici. Quindi questo è un compromesso specifico del carico di lavoro.
Quindi la risposta è che una volta arrivati sopra 1-2 TB di dimensioni si può trovare se stessi di fronte ad una serie di compromessi tra i sistemi e carichi di lavoro. Ancora una volta, questo è specifico per i database, la dimensione dei set di lavoro, ecc. Tuttavia, a questo punto devi davvero andare con i sistemi a fiocco di neve, cioè quelli unici e su misura per il tuo carico di lavoro.
Questo ovviamente significa che i limiti non sono generalmente quantificabili.
Modifica : ora ho lavorato con un database da 9 TB che gestisce una combinazione di supporto alle decisioni e carichi di lavoro di elaborazione transazionale in PostgreSQL. La sfida più grande è che se hai domande che colpiscono ampie porzioni del set di dati, dovrai aspettare un po 'per la risposta.
Tuttavia, con un'attenta attenzione ai fondamenti (inclusi indici, autovacuum, come funzionano a basso livello, ecc.) E risorse di calcolo sufficienti, questi sono completamente gestibili (e stimerei che siano gestibili bene nell'intervallo di 30 TB in Pg).
Modifica2 : una volta che vai a 100 TB, tuttavia, ciò che funziona dipenderà dal tuo set di dati. Sto lavorando su uno in questo momento che non si ridimensionerà in questo intervallo perché colpirà prima il limite di 32 TB per tabella in PostgreSQL.