Key-Value Stores vs. RDBMs & & # 8220; Cloud & # 8221; DB (SDB) [chiuso]

Question

Mi trovo a mio agio nello spazio MySQL, avendo progettato diverse app negli ultimi anni e perfezionando continuamente gli aspetti di prestazioni e scalabilità. Ho anche avuto qualche esperienza di lavoro con memcached per fornire accelerazioni lato applicazione su set di risultati frequentemente richiesti. E recentemente ho implementato Amazon SDB come il mio "database" principale per un esperimento di e-commerce.

Per semplificare troppo, una rapida giustificazione che ho trovato nella mia mente per l'utilizzo del servizio SDB era che l'uso di una struttura di database senza schema mi avrebbe permesso di concentrarmi sul problema logico del mio progetto e di accumulare rapidamente contenuto nel mio archivio di dati . Cioè, non preoccuparti di impostare e normalizzare prima tutte le possibili permutazioni degli attributi di un prodotto; inizia semplicemente a caricare i prodotti e l'SDB ricorderà semplicemente tutto ciò che è disponibile.

Ora che sono riuscito a superare le prime iterazioni del mio progetto e ho bisogno di configurare semplici interfacce per i dati, sto correndo per problemi che avevo dato per scontato lavorando con MySQL. Esempio: raggruppamento in istruzioni selezionate e limitazione della sintassi per interrogare "articoli da 50 a 100". Il vantaggio di facilità che ho ottenuto utilizzando l'architettura senza schema di SDB, ho perso a causa di un colpo alle prestazioni di query / loop di un set di risultati con poco più di 1800 elementi.

Ora sto leggendo progetti come Tokyo Cabinet che stanno estendendo il concetto di negozi di valori-chiave in memoria per fornire funzionalità pseudo-relazionali a velocità ridicolmente più elevate (14x ho letto da qualche parte).

La mia domanda: Ci sono alcune linee guida rudimentali o euristiche che io come progettista / sviluppatore di applicazioni posso esaminare per valutare quale tecnologia DB è la più appropriata in ogni fase del mio progetto.

Esempio: in una fase di prototipazione in cui incognite logiche / tecniche dell'applicazione rendono fluida la struttura dei dati: utilizzare SDB. In una fase più matura in cui i risultati degli utenti sono una priorità, utilizzare strumenti tradizionali in cui non è necessario dedicare tempo agli sviluppatori a scrivere logiche di ordinamento, raggruppamento o paginazione.

L'esperienza pratica con questi strumenti sarebbe molto apprezzata.

Grazie SO!

Shaheeb R.

Answer 1

Le nuove soluzioni non sono proiettili d'argento.

Rispetto al tradizionale RDBMS, questi sistemi apportano miglioramenti in alcuni aspetti (scalabilità, disponibilità o semplicità) compensando altri aspetti (capacità di query ridotta, eventuale coerenza, prestazioni orribili per determinate operazioni).

Pensa a questi non come sostituti del database tradizionale, ma sono strumenti specializzati per un'esigenza nota e specifica.

Prendi Amazon Simple DB, ad esempio, SDB è fondamentalmente un enorme foglio di calcolo, se è così che appaiono i tuoi dati, allora probabilmente funziona bene e la superba scalabilità e semplicità ti farà risparmiare un sacco di tempo e denaro.

Se il tuo sistema richiede query molto strutturate e complesse ma insisti con una di queste nuove fantastiche soluzioni, ti ritroverai presto nel mezzo di reimplementare un RDBMS dilettantesco e mal progettato, con tutte le sue problemi inerenti.

A questo proposito, se non sai se questi risponderanno alle tue esigenze, penso che sia effettivamente meglio fare le tue prime iterazioni in un RDBMS tradizionale perché ti offrono la migliore flessibilità e capacità soprattutto in una distribuzione su un singolo server e sotto carico modesto. (vedi Teorema della PAC ).

Una volta che hai un'idea migliore di come appariranno i tuoi dati e come verranno utilizzati, allora puoi abbinare le tue esigenze con una soluzione alternativa.

Se desideri la semplicità di una soluzione ospitata su cloud, ma hai bisogno di un database relazionale, puoi consultare: Amazon Servizio di database relazionale

Answer 2

I problemi che stai riscontrando sono il motivo per cui gli specialisti di RDBMS vedono alcuni dei sistemi alternativi con un occhio itterico. Sì, i sistemi alternativi gestiscono determinati requisiti specifici in modo estremamente rapido, ma non appena si desidera fare qualcos'altro con gli stessi dati, il più flottante diventa improvvisamente il ritardatario. Al contrario, un RDBMS in genere gestisce le variazioni con maggiore aplomb; potrebbe non essere così veloce come il più fluttuante per il carico di lavoro specializzato che il più flottante è micro-ottimizzato per gestire, ma raramente si deteriora rapidamente quando viene richiesto di gestire altre query.