Quando si tratta di decine di miliardi di righe in una tabella di app Web, un database NoSQL sarà notevolmente più veloce di uno relazionale? [chiuso]

Nessuna startup ha mai scritto la prima versione del suo software con questo tipo di scalabilità in mente.

Facebook è iniziato in PHP e ha scritto un cross-compilatore per convertire il loro codice PHP in C ++ per ridurre il numero dei server di cui hanno bisogno del 50%. Twitter ha apportato importanti modifiche architettoniche e ha ottenuto un 3X miglioramento della velocità .

In entrambi i casi, iniziarono con un sistema piccolo ma agile, in genere in uno strumento di sviluppo rapido, e passarono a sistemi più robusti e scalabili in seguito. La capacità di scrivere un sistema funzionante e portarlo sul mercato rapidamente è tutto ciò che conta quando sei piccolo.

Se ti capita di diventare grande come Facebook o Twitter, sei un problema di scalabilità sarà un buon problema avere e avrai tempo e denaro per sistemarli correttamente.

RDBMS vs. NoSQL

La domanda RDBMS vs. NoSQL, nonostante le affermazioni di alcuni fornitori, non è una semplice questione di prestazioni e scalabilità. È una questione di struttura dei dati e di cosa intendi fare con esso.

Se i tuoi dati sono altamente strutturati, puoi certamente trarre vantaggio da un RDBMS e ridimensionarlo se necessario, utilizzando server più grandi, aggiungendo più processori , distribuisci i tuoi dati attraverso diversi database che utilizzano uno schema di partizionamento intelligente e utilizzano anche alcuni implementazioni SQL basate su hadoop avendo in mente big data ... tutto questo se la struttura dati lo consente.

Tuttavia, se i tuoi dati non sono così strutturati, o hanno una struttura che potrebbe evolvere rapidamente, un database NoSQL come MongoDB, Aerospike, Cassandra o altri potrebbe certamente essere un'alternativa più flessibile. Questi database, grazie alla loro struttura flessibile, sono anche più facili da distribuire. Alcuni sono persino abilitati al contenitore, consentendo così la migliore scalabilità possibile. Ma per selezionare quello più appropriato, devi anche occuparti del tipo di NoSQL di cui hai bisogno, i modelli di lettura / scrittura nella tua applicazione, e anche qualche architettura di sistema di basso livello aspetti (esempio: uso della tecnologia in-memory, o archiviazione SSD rispetto ai tradizionali dischi rigidi).

Come scegliere?

Quindi la prima cosa di cui hai bisogno è avere una visione chiara della tua applicazione e dei dati che deve gestire. e gestire l'architettura generale del tuo prodotto.

Uno degli aspetti è la distribuzione della tua webapp su server Web per garantire la scalabilità e l'uso di eventuali middleware come kafka come broker di messaggi e, infine, utilizzo di microservizi, con diversi database liberamente collegati.

Un altro aspetto sarà l'interfaccia tra l'applicazione e il database. L'approccio migliore qui è di progettare l'architettura del software in modo da isolare le interazioni con il database, consentendo di modificare se necessario, con un impatto minimo sul resto dell'applicazione. Questo approccio ti consentirà di iniziare con un database e cambiare se necessario senza troppe preoccupazioni, guadagnando dall'esperienza man mano che i flussi di dati crescono.

Il fattore di guida in questa scelta non è la velocità di funzionamento, ma la struttura dei dati.

Nel tuo caso hai un post con i Mi piace associati. Se si visualizza sempre il post e si usa il Mi piace insieme senza riferimento ad altri dati, questo si adatta al modello no-sql.

Devi solo selezionare il post per id o forse un ID utente indicizzato e il db restituisce automaticamente i Mi piace richiesti.

Se tuttavia volessi visualizzare i Mi piace medi per post con la data odierna o il post con il maggior numero di Mi piace. un dl sql sarebbe più adatto in quanto una singola selezione può calcolare l'aggregato sulle tabelle.

Quando parli di miliardi di righe devi considerare anche la dimensione dei dati. Qualsiasi query che deve esaminare tutti i dati sarà lenta indipendentemente dalla struttura del database.