Qual è il modo moderno di partizionare PostgreSQL su più macchine, quando i dati sono "naturalmente partizionabili"


22

Dopo diversi anni passati a soffermarmi nello spazio "NoSQL", ora ho un problema abbastanza "relazionale" nella sua natura. Oggi vedo archivi dati con occhi abbastanza diversi rispetto a prima. Cose come Riak mi hanno viziato in un modo in cui non posso più tollerare singoli punti di errore, "in manutenzione" ecc. Naturalmente, (o spero), non ho perso del tutto la sanità mentale. Questo è un progetto personale che non ha (o ancora) requisiti estremamente elevati.

La maggior parte delle soluzioni di sharding non mi danno ciò che voglio (almeno per uno sguardo), probabilmente perché il mio problema è abbastanza "facile" da risolvere. Almeno a livello concettuale (ignorando le restrizioni che gli stessi RDBM mettono in campo).

  1. Ho una piccola quantità di dati "condivisi", che possono essere duplicati liberamente. Non ha requisiti di consistenza dura. Questo può essere archiviato in un database simile a una dinamo e si ridimensionerà all'infinito. Ma vorrei ancora andare con un singolo database, se possibile.

  2. Ho molti dati "per utente". Cioè - molti utenti, con ogni utente che ha dati di dimensioni assolutamente ragionevoli, sono davvero adatti per essere memorizzati su un singolo nodo PostgreSQL. Stiamo parlando di decine di migliaia di record al massimo.

  3. Non ho mai bisogno di interrogare tra utenti e non ho bisogno di atomicità tra utenti.

Sembra estremamente facile da ottenere. Almeno quando lo guardo con i miei "occhi NoSQL".

Ecco le mie idee ingenui per iniziare:

  1. All'estremo, potrei semplicemente serializzare l'intero utente come una singola chiave / valore in Riak. Naturalmente, la de / serializzazione costante di diversi megabyte di dati sarà lenta ed è per questo che sto prendendo in considerazione l'utilizzo di PostgreSQL. Un sacco di Riak K / Vs è un gioco da ragazzi, poiché ho bisogno di atomicità / transazioni all'interno dei dati di ciascun utente.

  2. Potrei usare un database SQLite per utente e usare qualcosa come GlusterFS per ridondanza / disponibilità. Questa è probabilmente la soluzione che sceglierò se non riesco a trovare qualcosa di altrettanto buono usando PostgreSQL. Pro: può scendere / salire davvero bene; Contro: preferirei avere i tipi e la severità di PostgreSQL su SQLite

Quindi, cosa idealmente richiederei da una soluzione di sharding PostgreSQL:

  1. Conserva automaticamente diverse copie dei dati di ogni utente (su macchine diverse). Essere in grado di cambiare dinamicamente il nodo master per utente / shard (se il master precedente scende).
  2. Essere in grado di scalare / scalare dinamicamente, aggiungendo / rimuovendo i nodi del server. Principalmente come Riak è in grado di fare.
  3. Non è necessario che la mia applicazione sappia con quali nodi parlare e quando.

Ciao loxs, come avete risolto questo problema?
Dikla,

Partizionamento a livello di applicazione con più archivi di dati. Davvero un
bel

Risposte:



4

Penso che l'opzione migliore sia pgpool-II . Puoi avere fino a 128 nodi e

  1. È possibile impostare complesse regole di partizionamento e distribuzione dei dati
  2. Supporto "Provisioning online". Non scrive in scala ma è scalabile in lettura
  3. Non sono sicuro, se possibile, pronto all'uso. Forse devi usare LVS

Un'altra opzione potrebbe essere Stado

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.