Dividere il database tra MySQL e NoSQL

1

Il mio è un tipico sito Web sviluppato con lo stack LAMP. A causa di problemi di scalabilità, stiamo pianificando di incorporare NoSQL per l'applicazione.

Per l'implementazione, stiamo pianificando di implementare una soluzione ibrida: usare NoSQL solo per alcune delle tabelle ad alto volume nel database e continuare a utilizzare MySQL per tutte le altre. Quindi, stiamo dividendo il database in due con due server diversi che utilizzano una diversa tecnologia di database.

Stiamo valutando i pro e i contro per questo approccio. Ad esempio, con questo approccio dovremo dipendere dall'applicazione web per mantenere l'integrità dei dati. Ci saranno 2 punti di errore a causa di 2 server DB, invece di uno.

È una pratica normale? Quali sono i pro e i contro?

    
posta Ruchit Rami 26.03.2014 - 06:14
fonte

1 risposta

1

La soluzione migliore per migliorare la scalabilità è concentrarsi sulla rimozione delle chiamate al database, piuttosto che sulla rimozione dei dati dal database. (sebbene ciò possa accadere con cose come i dati di sessione)

Se la tua applicazione web è come la maggior parte che ho visto, un caricamento di una sola pagina attiva più richieste HTTP. Ciascuna di queste richieste è in grado di attivare il recupero dei dati di sessione, il recupero dei dettagli dell'utente e quindi anche il database per i dati per le informazioni che rispondono alla richiesta.

Ci sono alcune cose ovvie che possono essere fatte qui.

  1. I dati di sessione sono una cosa ovvia da spostare in un database NoSQL. È un'operazione Key / Value semplice e qualcosa come Riak è un buon posto dove archiviare questi dati.
  2. I dati del database come i dettagli dell'utente che vengono letti spesso, ma modificati raramente, sono anche una buona combinazione per l'archiviazione in Riak. Il modo in cui gestisci le condizioni di gara in caso di aggiornamenti varierà in base alla tua capacità di tollerare l'utilizzo di dati obsoleti.
  3. Allo stesso modo, probabilmente il tuo sito web ha molti altri dati che elabora in sezioni HTML che non variano da utente a utente. L'implementazione di un meccanismo di memorizzazione nella cache per archiviare il risultato di questa elaborazione può anche ridurre sostanzialmente gli accessi sul tuo database.

Alla fine però, scoprirai che alcune tabelle conterranno alcune informazioni critiche che non possono essere memorizzate nella cache. Quando raggiungi questo punto, le tue scelte sono di ridisegnare la struttura dei tuoi dati principali (che probabilmente non è possibile, l'avresti già fatto) o di buttare soldi (e hardware) per consentire al database di continuare a funzionare. In un ambiente con cui ho lavorato, questo significava un server MS SQL con 128 core con il disco più veloce e la massima quantità di memoria che poteva comprare.

    
risposta data 26.03.2014 - 11:10
fonte

Leggi altre domande sui tag