2009-03-24 9 views
5

Sembra esserci una grande spinta per database basati su valori/valori, che credo siano memcache.Database basati su valori-chiave, qualcuno può spiegarmi come usarli praticamente?

Il valore solitamente è una sorta di raccolta o file xml che potrebbe contenere dati più significativi?

In caso affermativo, è generalmente più veloce deserializzare i dati, quindi fare in modo congiuntamente JOIN e selezionare sulle tabelle che restituiscono un set di risultati basato su riga?

risposta

3

Come per la maggior parte delle cose, "dipende". Se i join sono relativamente irrilevanti (ovvero, un piccolo numero di join su dati ben congegnati) e si memorizzano dati particolarmente complessi, potrebbe essere meglio attenersi alla query più complessa.

È anche una questione di freschezza. In molti casi lo scopo di molti join è di riunire dati molto disparati; cioè, dati che variano ampiamente nella relativa freschezza. Può aggiungere considerevole complessità e sovraccarico per mantenere sincronizzata una tabella coppia valore-chiave quando viene aggiornata una piccola porzione di dati su un numero elevato di coppie. La complessità del sistema può essere spesso considerata una forma di costo delle prestazioni; il tempo, i rischi e i costi per apportare modifiche a un sistema complesso senza influire sulle prestazioni è spesso molto più grande di uno semplice.

La soluzione migliore è sempre il codice che funziona nel modo più semplice possibile. Nella maggior parte dei casi, direi che questo significa creare un progetto di database completamente normalizzato e unirsi a lui. Rivedere il tuo design solo dopo le prestazioni diventa un problema evidente. Quando si analizza il problema, sarà anche ovvio dove si trovano i problemi e cosa è necessario fare per risolverli. Se riduce i join, allora così sia. Saprai quando devi sapere.

+0

Non sono affatto d'accordo con il "... unirsi alla merda". parte. La mia esperienza mi dice che unirsi dovrebbe essere fatto in modo ragionevole. Troppa normalizzazione è quasi sempre una brutta cosa. –

2

Non ho molta esperienza con chiave/valore dbs, quindi prendi quello che dico con un pizzico di sale.

Con ciò detto, la prima cosa che dovrei sottolineare è che memcached non è una chiave/valore database. Un database implica un tipo di archivio persistente, che non è memcached. Memcached è destinato a essere un archivio temporaneo per salvare una query nel database effettivo.

Oltre a ciò, mi risulta che non sarà possibile sostituire il proprio RDBMS con un database di chiavi/valori. Tendono ad essere i migliori per dati non strutturati o altri dati in cui potresti non conoscere tutti gli attributi che devono essere memorizzati. Se hai bisogno di archiviare dati altamente strutturati, non puoi fare molto meglio di un RDBMS tradizionale.

6

Ciò che è accaduto è che alcuni davvero, davvero, DAVVERO grandi siti web come Google e Amazon occupano un teeny, piccola nicchia dove la loro memorizzazione dei dati e requisiti di recupero sono così diverso da chiunque altro che un nuovo modo di la memorizzazione/il recupero dei dati è richiesto. Sono sicuro che questi ragazzi sanno quello che stanno facendo, sono molto bravi in ​​quello che fanno.

Tuttavia, questo viene rilevato e segnalato e distorto in "i database relazionali non sono in grado di gestire i dati per il Web". Inoltre, i lettori iniziano a pensare "hey, se i database relazionali non sono abbastanza buoni per Amazon e Google, non sono abbastanza buoni per me."

Queste inferenze sono entrambe errate: il 99,9% di tutti i database (compresi quelli dietro i siti Web) non si trovano nello stesso parco di Amazon e Google - non entro diversi ordini di grandezza. Per questo 99,9%, nulla è cambiato, i database relazionali funzionano ancora bene.

+0

Amen, fratello! :-) – ObiWanKenobi

+0

Quindi le mie applicazioni web funzioneranno perfettamente con MySQL e (possibilmente) Memcached? –

+0

Immagino di sì, sì. Non so nulla di Memcached, ma avendo appena effettuato il comando su Google, vedo che si tratta semplicemente di un meccanismo per il "ricordo" dei valori una volta recuperati dal database in una sessione, anziché tornare ripetutamente al database per ottenerli. Non ha nulla a che fare con i database di chiavi/valori AFAICT. Tale memorizzazione nella cache è probabilmente ragionevole se usata con giudizio: non usarla per i dati che probabilmente sono cambiati dall'ultimo accesso (a meno che, ovviamente, non ti interessi che lo sia). –

1

possono essere dati strutturati complessi che richiedono la deserializzazione. Possono anche essere semplici record a dimensione fissa, proprio come il tuo RDBMS. Parte del vantaggio è che puoi prendere questa decisione da solo. Quando ottimizzi il tuo database, non sei limitato a ciò che SQL può fare.

Il modo in cui si fa sembrare il join o la deserializzazione sarà sempre il collo di bottiglia. Ma in qualsiasi database, le cose non sono mai così semplici. Puoi anche inserire dati denormalizzati nel tuo RDBMS o scrivere un'interfaccia RDBMS su un database di valori-chiave, se lo desideri.