Il database è il collo di bottiglia o no? Conversazione ad alta scalabilità

Question

Il database è il collo di bottiglia o no? Conversazione ad alta scalabilità

#1 da (7 voti)
#2 da (6 voti)
#3 da (5 voti)

5

Ho trovato un articolo interessante sul sito Web ad alta scalabilità in cui si parla della scalabilità di EBay e in particolare di un passaggio specifico mi ha colpito:

"(Ebay strategies)...Move work out of the database into the applications because the database is the bottleneck. Ebay does this in the extreme. We see it in other architecture using caching and the file system, but eBay even does a lot of traditional database operations in applications (like joins)."

e quanto sopra non è un errore perché di nuovo nello stesso articolo:

"Move cpu-intensive work moved out of the database layer to applications applications layer: referential integrity, joins, sorting done in the application layer! Reasoning: app servers are cheap, databases are the bottleneck."

Qualche spiegazione su questo? Se quanto sopra fosse vero, dovrei usare il database solo per recuperare i dati e fare tutte le altre operazioni nella logica di programmazione.

Mi è sempre stato detto il contrario: "i database sono ottimizzati per le operazioni su dati e selezioni complesse, quindi usali".

Qualche informazione?

database scalability

posta dendini 30.07.2013 - 12:14

fonte

3 risposte

Leggi altre domande sui tag database scalability

Fonti autorevoli per le best practice di gestione delle eccezioni [chiuso] Sviluppo di Python su Windows e distribuzione su Linux

score 7 · Answer 1

"Misura. Non indovinare".

Non possiamo presumere che i colli di bottiglia di Ebay siano uguali ai nostri. Per le applicazioni specifiche su cui lavoro, quando si verifica un collo di bottiglia, raramente è il database (o se lo è, è a causa di query scarsamente ottimizzate). Lo so perché abbiamo esaminato le istanze di prestazioni scadenti e profilato le prestazioni delle normali prestazioni della nostra applicazione.

score 6 · Answer 2

Sì, i database relazionali sono dei colli di bottiglia in termini di scalabilità orizzontale; per scalare il server RDBMS nella maggior parte dei casi è necessaria una macchina più potente e questo porta a un limite. Questo è uno dei motivi principali per cui i database NoSQL sono apparsi in alternativa a RDBMS, scambiando le transazioni ACID. Il collo di bottiglia è ancora più grande se si inserisce la logica dell'applicazione nel database, sotto forma di stored procedure.

Spostando la potenza di elaborazione nel livello applicazione, l'intera applicazione può scalare più facilmente, poiché un server delle applicazioni ben scritto può essere distribuito su più server macchina. Un'alternativa a questo è l'utilizzo dei suddetti archivi dati NoSQL per raggiungere la scalabilità; Gli archivi dati NoSQL possono anche essere facilmente implementati su più nodi.

Nota che questo rende sens sens in un discorso ad alta scalabilità, come hai sottolineato nella domanda. Nella maggior parte dei casi, se usati correttamente, i database non rappresentano un reale collo di bottiglia e fanno il loro lavoro molto bene, dato che lo hanno fatto per decenni.

score 5 · Answer 3

La memoria è veloce e non resistente, mentre le unità sono lente e resistenti. Se si estrae i dati da un database e lo si inserisce in memoria, il suo accesso sarà sempre significativamente più rapido di quello in caso contrario, se il server non funziona, perderai i dati.

I database sono perfetti per la maggior parte delle applicazioni là fuori. Solo una piccola percentuale di applicazioni ha la portata di google, twitter, ecc, e mentre è sempre affascinante sul modo in cui quelle aziende hanno superato le loro sfide, sarebbe ingenuo provare a implementare le loro soluzioni fin dall'inizio.