Quando utilizzare un archivio dati valore-chiave rispetto a un DB relazionale più tradizionale?

Question

Quando si sceglie un archivio dati valore-chiave su un DB relazionale? Quali considerazioni vanno nel decidere l'una o l'altra? Quando è il mix di entrambi i percorsi migliori? Si prega di fornire esempi se è possibile.

Answer 1

In base alla mia esperienza, se si sta anche chiedendo se utilizzare pratiche tradizionali o esoteriche, passare alla tradizione. Mentre le pratiche esoteriche sono sexy, stimolanti e divertenti, il 99,999% delle applicazioni richiede un approccio tradizionale.

per quanto riguarda relazionali vs KV, la domanda che dovrebbe porci è:

Perché dovrei nondesidera utilizzare un modello relazionale per questo scenario: ...

Dato che non hai descritto lo scenario, è impossibile per chiunque dirti perché non dovresti usarlo. La ragione "catch all" per KV è la scalabilità, che non è un problema ora. Conosci le regole dell'ottimizzazione?

1. Non farlo.
2. (solo per esperti) Non farlo ora.

KV è un altamente soluzione ottimizzata per scalabilità che molto probabilmente sarà completamente unecessary per l'applicazione.

Answer 2

Un database relazionale tradizionale presenta problemi di ridimensionamento oltre un punto. Dove quel punto dipende un po 'da quello che stai cercando di fare.

Tutti (la maggior parte?) Dei fornitori di cloud computing stanno fornendo archivi di dati di valore chiave.

Tuttavia, se si dispone di un'applicazione di dimensioni ragionevoli con una struttura di dati complicata, il supporto derivante dall'utilizzo di un database relazionale può ridurre i costi di sviluppo.

Answer 3

I sistemi di database a valori-chiave, gerarchici, di riduzione delle mappe o di grafici sono molto più vicini alle strategie di implementazione, sono fortemente legati alla rappresentazione fisica. La ragione principale per scegliere uno di questi è se c'è un argomento convincente sulle prestazioni e si adatta molto bene alla tua strategia di elaborazione dei dati. Attenzione, le query ad hoc di solito non sono pratiche per questi sistemi, e è meglio decidere in anticipo sulle query.

I sistemi di database relazionali cercano di separare il modello logico, orientato al business dalla sottostante rappresentazione fisica e dalle strategie di elaborazione. Questa separazione è imperfetta, ma comunque abbastanza buona. I sistemi relazionali sono grandi per gestire i fatti ed estrarre informazioni affidabili da raccolte di fatti. I sistemi relazionali sono anche grandi per le query ad-hoc, che gli altri sistemi sono notoriamente cattivi. Questo è un grande adattamento nel mondo degli affari e in molti altri posti. Ecco perché i sistemi relazionali sono così diffusi.

Se si tratta di un'applicazione aziendale, un sistema relazionale è quasi sempre la risposta. Per altri sistemi, è probabilmente la risposta. Se si ha più di un problema di elaborazione dati, come alcune pipeline di cose che devono accadere e si dispone di enormi quantità di dati, e si conoscono tutte le query in anticipo, un altro sistema potrebbe essere giusto per te.

Answer 4

Se i tuoi dati sono semplicemente un elenco di cose e puoi ricavare un identificatore univoco per ciascun articolo, allora un KVS è una buona corrispondenza. Sono implementazioni ravvicinate delle semplici strutture di dati che abbiamo appreso nell'informatica di matricola e non consentono relazioni complesse.

Un semplice test: puoi rappresentare i tuoi dati e tutte le sue relazioni come una lista collegata o tabella hash? Se sì, un KVS potrebbe funzionare. Se no, hai bisogno di un RDB.

È ancora necessario trovare un KVS che funzioni nel proprio ambiente. Il supporto per KVS, anche i più importanti, non è affatto vicino a PostgreSQL e MySQL/MariaDB.