Differenza tra ridimensionamento orizzontale e verticale per database [chiuso]

Ho incontrato molti database NoSQL e database SQL. Esistono diversi parametri per misurare la forza e i punti deboli di questi database e la scalabilità è uno di questi. Qual è la differenza tra il ridimensionamento orizzontale e verticale di questi database?

Il ridimensionamento orizzontale significa scalare aggiungendo più macchine nel pool di risorse mentre il ridimensionamento verticale significa scalare aggiungendo più potenza (CPU, RAM) a una macchina esistente .

Un modo semplice per ricordare questo è pensare a una macchina su un server rack, aggiungiamo più macchine in direzione orizzontale e aggiungiamo più risorse a una macchina in direzione verticale .

In un mondo di database il ridimensionamento orizzontale si basa spesso sul partizionamento dei dati, ovvero ogni nodo contiene solo una parte dei dati, nel ridimensionamento verticale i dati risiedono su un singolo nodo e il ridimensionamento viene effettuato tramite multi-core, ovvero dividendo il carico tra le risorse CPU e RAM di quella macchina.

Con il ridimensionamento orizzontale è spesso più facile ridimensionare dinamicamente aggiungendo più macchine al pool esistente: il ridimensionamento verticale è spesso limitato alla capacità di una singola macchina, oltre a tale capacità spesso comporta tempi di inattività e presenta un limite superiore.

Buoni esempi di ridimensionamento orizzontale sono Cassandra, MongoDB, Google Cloud Spanner .. e un buon esempio di ridimensionamento verticale è MySQL - Amazon RDS (la versione cloud di MySQL). Fornisce un modo semplice per ridimensionare verticalmente passando da macchine più piccole a più grandi. Questo processo comporta spesso tempi di inattività.

Le griglie di dati in memoria come GigaSpaces XAP , Coherence ecc. Sono spesso ottimizzate per il ridimensionamento sia orizzontale che verticale semplicemente perché non sono legate al disco. Ridimensionamento orizzontale tramite partizionamento e ridimensionamento verticale tramite supporto multi-core.

Puoi leggere di più su questo argomento nei miei post precedenti: Scale-out vs Scale-up e The Common Principles Behind the NOSQL Alternatives

Ridimensionamento orizzontale ===> Migliaia di servitori faranno il lavoro insieme per te.

Ridimensionamento verticale ===> Un grosso grosso farà tutto il lavoro per te.

Cominciamo con la necessità di un ridimensionamento che sta aumentando le risorse in modo che il sistema ora possa gestire più richieste di quanto non potesse in precedenza.

Quando ti rendi conto che il tuo sistema sta rallentando e non è in grado di gestire il numero corrente di richieste, devi ridimensionare il sistema.

Questo ti offre due opzioni. O si aumentano le risorse nel server che si sta attualmente utilizzando, ovvero si aumenta la quantità di RAM, CPU, GPU e altre risorse. Questo è noto come ridimensionamento verticale.

Il ridimensionamento verticale è in genere costoso. Non rende tollerante ai guasti del sistema, ovvero se si esegue il ridimensionamento dell'applicazione in esecuzione con un singolo server, se tale server si arresta, il sistema si disattiva. Anche la quantità di thread rimane la stessa nel ridimensionamento verticale. Il ridimensionamento verticale potrebbe richiedere il blocco del sistema per un momento in cui si verifica il processo. Aumentare le risorse su un server richiede un riavvio e mettere il sistema inattivo.

Un'altra soluzione a questo problema è aumentare la quantità di server presenti nel sistema. Questa soluzione è molto utilizzata nel settore tecnologico. Ciò alla fine ridurrà la frequenza di richiesta al secondo in ciascun server. Se è necessario ridimensionare il sistema, è sufficiente aggiungere un altro server e il gioco è fatto. Non ti verrà richiesto di riavviare il sistema. Il numero di thread in ciascun sistema diminuisce portando a un throughput elevato. Per separare le richieste, allo stesso modo per ciascuno dei server delle applicazioni, è necessario aggiungere un bilanciamento del carico che funga da proxy inverso per i server Web. L'intero sistema può essere chiamato come un singolo cluster. Il tuo sistema potrebbe contenere un gran numero di richieste che richiederebbero una quantità maggiore di cluster come questo.

Spero che tu abbia il concetto completo di introdurre il ridimensionamento nel sistema.

Esiste un'architettura aggiuntiva che non è stata menzionata: i servizi di database basati su SQL che consentono il ridimensionamento orizzontale senza la complessità dello sharding manuale. Questi servizi eseguono lo sharding in background, quindi ti consentono di eseguire un database SQL tradizionale e di ridimensionarlo come faresti con i motori NoSQL come MongoDB o CouchDB. Due servizi che conosco sono EnterpriseDB per PostgreSQL e Xeround per MySQL. Ho visto un post approfondito di Xeround che spiega perché il ridimensionamento dei database SQL è difficile e come lo fanno in modo diverso: trattatelo con un pizzico di sale in quanto è un post di un fornitore. Controlla anche la voce del database cloud di Wikipedia, c'è una bella spiegazione di SQL vs NoSQL e servizio vs. self-hosted, un elenco di fornitori e opzioni di ridimensionamento per ogni combinazione. ;)

Sì, il ridimensionamento in senso orizzontale implica l'aggiunta di più macchine, ma implica anche che le macchine siano uguali nel cluster. MySQL può ridimensionare orizzontalmente in termini di lettura dei dati, attraverso l'uso di repliche, ma una volta raggiunta la capacità del mem / disco del server, è necessario iniziare a condividere i dati tra i server. Questo diventa sempre più complesso. Spesso mantenere i dati coerenti tra le repliche è un problema in quanto i tassi di replica sono spesso troppo lenti per tenere il passo con i tassi di modifica dei dati.

Couchbase è anche un fantastico database NoSQL con ridimensionamento orizzontale, utilizzato in molte applicazioni e giochi commerciali ad alta disponibilità e probabilmente il più performante della categoria. Partiziona i dati automaticamente attraverso il cluster, l'aggiunta di nodi è semplice e puoi utilizzare hardware di base, istanze VM più economiche (ad esempio utilizzando macchine Large anziché High Mem, High Disk su AWS). È costruito su Membase (Memcached) ma aggiunge persistenza. Inoltre, nel caso di Couchbase, ogni nodo può fare letture e scritture e sono uguali nel cluster, con solo la replica di failover (non la replica completa del set di dati su tutti i server come in mySQL).

Per quanto riguarda le prestazioni, puoi vedere un eccellente benchmark Cisco: http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server

Ecco un fantastico post sul blog su Couchbase Architecture: http://horicky.blogspot.com/2012/07/couchbase-architecture.html

I database relazionali tradizionali sono stati progettati come sistemi di database client / server. Possono essere ridimensionati in orizzontale, ma il processo per farlo tende ad essere complesso e soggetto a errori. I database NewSQL come NuoDB sono sistemi di database distribuiti incentrati sulla memoria progettati per scalare orizzontalmente mantenendo le proprietà SQL / ACID dei tradizionali RDBMS.

Per ulteriori informazioni su NuoDB, leggi il loro white paper tecnico .

Database SQL come Oracle, db2 supportano anche il ridimensionamento orizzontale tramite cluster di dischi condivisi. Ad esempio Oracle RAC, IBM DB2 purescale o Sybase ASE Cluster edition. È possibile aggiungere un nuovo nodo al sistema Oracle RAC o al sistema purescale DB2 per ottenere il ridimensionamento orizzontale.

Ma l'approccio è diverso dai database noSQL (come mongodb, CouchDB o IBM Cloudant) è che lo sharding dei dati non fa parte del ridimensionamento orizzontale. Nei database noSQL i dati vengono distribuiti durante il ridimensionamento orizzontale.

Hai un'azienda e c'è solo 1 lavoratore ma hai 1 nuovo progetto in quel momento assumi un nuovo candidato - questo è il ridimensionamento orizzontale. dove il nuovo candidato sono le nuove macchine e il progetto è il nuovo traffico / chiamate verso le API.

Dove come 1 progetto con un ragazzo IIT / NIT che gestisce tutte le richieste al tuo api / traffico. Se in qualsiasi momento più richieste ai tuoi API, poi licenzialo e sostituendolo con un ragazzo IQ NIT / IIT alto - questo è il ridimensionamento verticale.

L'aggiunta di molti servizi di bilanciamento del carico crea sovraccarico e latenza extra e questo è lo svantaggio di ridimensionare orizzontalmente nei database nosql. È come la domanda per cui la gente dice che RPC non è raccomandato poiché non è robusto.

Penso che in un sistema reale dovremmo usare sia i database sql che nosql per utilizzare sia le capacità multicore che il cloud computing dei sistemi di oggi.

D'altra parte, le query transazionali complesse hanno prestazioni elevate se si utilizzano database sql come Oracle. NoSql potrebbe essere utilizzato per bigdata e scalabilità orizzontale mediante lo sharding.

La risposta accettata è precisa sulla definizione base di ridimensionamento orizzontale e verticale. Ma a differenza della convinzione comune che il ridimensionamento orizzontale dei database è possibile solo con Cassandra, MongoDB, ecc. Vorrei aggiungere che il ridimensionamento orizzontale è anche molto possibile con qualsiasi RDMS tradizionale; anche quello senza usare soluzioni di terze parti.

Conosco molte aziende, specialmente quelle con sede in SaaS che lo fanno. Questo viene fatto usando una semplice logica applicativa. Praticamente prendi una serie di utenti e li dividi su più server DB. Quindi, ad esempio, in genere si avrebbe un database / tabella "meta" che memorizzerebbe client, stringhe di connessione / server DB, ecc. E una tabella che memorizza il mapping client / server.

Quindi semplicemente indirizzare le richieste da ciascun client al server DB a cui sono mappate.

Ora alcuni potrebbero dire che questo è simile al partizionamento orizzontale e non al "vero" ridimensionamento orizzontale e avranno ragione in qualche modo. Ma il risultato finale è che hai ridimensionato il tuo DB su più server Db.

L'unica differenza tra i due approcci al ridimensionamento orizzontale è che un approccio (MongoDB, ecc.) Il ridimensionamento viene eseguito dal software DB stesso. In questo senso stai "comprando" il ridimensionamento. Nell'altro approccio (per il ridimensionamento orizzontale RDBMS), il ridimensionamento viene creato in base al codice / logica dell'applicazione.