Database da 100 terabyte su PostgreSQL senza sharding

È realistico impostare un database da 100 TB (circa 90 TB in realtà) su PostgreSQL senza condivisione dei dati tra un numero di nodi? Ci sono storie / esempi di successo su configurazioni simili?

50 K scrive al secondo che devono essere assorbiti è più che una sfida di solito. Anche nei benchmark sintetici con inserti abbastanza semplici, i limiti di PostgreSQL tendono a raggiungere un massimo di circa 10 K / s - e lì non hai nemmeno una bestia così grande in termini di dimensioni del database.

Anche il sistema I / O per quel singolo nodo PostgreSQL sarà interessante come anche con RAID 10 e supponendo che gli inserti da 50K saranno pari a soli 50K IOPS (il che è probabilmente sbagliato, ma dipende dallo schema del database e dagli indici ), avrai bisogno di circa un centinaio di dischi abbinati a un array molto buono che ti salva dall'acquisto di diverse centinaia di dischi per servire quelle scritture in modo tempestivo.

Se lo sharding è facile e ti aspetti un carico di scrittura così grande, allora scegli lo sharding. Le scritture possono essere molto difficili da ridimensionare.

È realistico e funzionerà. Le prestazioni dipendono in larga misura dalla quantità di RAM disponibile. Maggiore è la RAM, maggiore è la cache e più lungo PostgreSQL può memorizzare nella cache i dati prima di scaricare su disco.

PostgreSQL scriverà i dati nella cache e scaricherà la cache di volta in volta. Pertanto, 50.000 INSERTI al secondo non verranno tradotti in 50.000 IOPS. Sarà molto meno, perché raggrupperà insieme i record e li scriverà tutti contemporaneamente.

Un database così grande non è un problema se la maggior parte del lavoro è INSERT. PostgreSQL dovrà cambiare gli indici qua e là, ma è davvero un lavoro facile. Se avessi un sacco di SELECT su un database di queste dimensioni, avresti davvero bisogno di partizionare.

Una volta ho lavorato su un DB Oracle (Oracle 10g) con 400 TB su un server da 16 GB, solo un'istanza. Anche il carico di lavoro del database era INSERT primario, quindi alcuni SELECT al giorno e milioni di INSERT ogni giorno. Le prestazioni erano lungi dall'essere un problema.

A 100 TB hai alcune sfide importanti. Se funzionerà per te o no dipende da come vuoi affrontarli.

1. Sono necessari modi sufficienti per assorbire il carico di scrittura. Questo dipende dal carico di scrittura. Ma con una memoria sufficientemente impressionante può essere risolto. La velocità è un grosso problema qui. Allo stesso modo, l'accesso alla lettura deve essere esaminato attentamente.

2. La maggior parte dei database non sono costituiti da un gruppo di tabelle piccole ma spesso ne hanno una o due veramente grandi, che possono raggiungere la metà della dimensione del db. PostgreSQL ha un limite rigido di 32 TB per tabella. Dopodiché il tipo di marea esaurisce i contatori di pagine. Questo potrebbe essere gestito da una build personalizzata di PostgreSQL o dal partizionamento delle tabelle, ma è una sfida seria che deve essere affrontata all'inizio.

3. PostgreSQL ha limiti reali nella quantità di RAM che può utilizzare per varie attività. Quindi avere più RAM può aiutarti o meno oltre un certo punto.

4. Backup .... I backup sono interessanti su questa scala. Il db da 60 TB che conosco doveva usare i backup dell'istantanea fs e quindi falsificare i backup per barman per l'archiviazione wal. Questi backup falsi erano proxy per i backup di istantanee di fs. Come ho detto "Non sono backup falsi. Sono backup alternativi!"

Ci sono persone con database che si avvicinano a questo intervallo. Ho incontrato almeno un individuo che lavorava per una banca nei Paesi Bassi con un database PostgreSQL da 60 TB. Tuttavia, dipende molto dal carico di lavoro e le dimensioni da sole non sono il problema.