Sistema di database scalabile, richiesta critica

Question

Sto cercando di creare una soluzione di database scalabile per il back-end del mio sito Web. Ho letto di recente sulla progettazione di database e sembra che abbia sviluppato un'idea per conto mio che potrebbe funzionare. Penso che questo sia un nuovo modo di mantenere n database con dati sincronizzati, ma potrei sbagliarmi. Quindi sto chiedendo a SO di valutare l'idea e di dirmi se è pazzo o no. (o se esiste già ed è implementato)

In questo schema ci sono un gruppo di nodi del server. Un nodo esegue un bilanciamento del carico di query (chiamiamolo A ) e il resto esegue un tipico dbms, chiamiamo collettivamente quei nodi N .

Ogni N è disconnessa dalle altre. cioè) un nodo in N non ha bisogno di comunicare con nessuno degli altri. Ogni N ha una connessione solo a A .

Il processo funziona in questo modo

• Tutte le query del database vengono passate attraverso A . (Supponiamo per ora che A abbia una capacità di elaborazione e capacità di elaborazione infinita)
• A controlla ogni query ( Q ) e determina se si tratta di un'operazione che leggerà da un database o di una query che scriverà in un database. (in sql, leggi sarebbe selezionato e scrivi sarebbe aggiornato)
• Se Q è un'operazione leggi , inoltralo a uno dei nodi in N
• se Q è un'operazione scrivi , inoltralo a tutti dei nodi in N

Supponendo che sia implementato correttamente, questo porta a tutti i nodi in N con contenuti di database sincronizzati. Le query che stanno solo leggendo i dati devono essere inviate a un nodo.

Questa idea sembra funzionare particolarmente bene per me perché nel mio sistema ci sono pochissime operazioni di scrittura, meno dell'1%.

Quindi alcune domande su questa idea

• Uno schema come questo ha senso da un punto di vista teorico?
• Se questo ha senso, esiste una soluzione già implementata o commerciale o gratuita?

Answer 1

L'impostazione tipica per molte letture poche scritture è di avere un master db di lettura / scrittura e n di db slave replicati che sono di sola lettura. La replica è gestita da RBDMS. Le query di sola lettura possono essere bilanciate in base al carico su tutti i nodi n di sola lettura e se il master di lettura / scrittura si interrompe temporaneamente, almeno l'app sarà in grado di eseguire operazioni di lettura. Non hai bisogno di un " A " centrale proxy per decidere se una query è una lettura o una scrittura. Il client che emette la query dovrebbe essere abbastanza intelligente da sapere se sta leggendo o scrivendo. In questo modo non verrai colto di strozzature sul tuo " A " server.

L'impostazione proposta ha il netto difetto nel fatto che se si scrive simultaneamente su n nodi, cosa succede se una o più di queste scritture falliscono?

Answer 2

Il tuo schema funziona solo con nodi infinitamente disponibili. Come hai intenzione di gestire i tempi di inattività dei nodi? Se un nodo è inattivo per qualsiasi motivo e ha perso un aggiornamento, servirà dati sporchi alla prossima richiesta.

Answer 3

Non è una risposta diretta alla tua domanda, ma SQL Server 2008 supporta già qualcosa di equivalente a quello che stai descrivendo. Si chiama Replica transazionale peer-to-peer . Sono sicuro che anche gli altri RDBMS lo fanno. Penso che MySQL la chiami replica master-master.