Ci sono ORM (OKM) per gli archivi di valori-chiave?

Question

Object-Relational-Mappers sono stati creati per aiutare le applicazioni (che pensano in termini di oggetti) a gestire i dati archiviati in un modo più facile per l'applicazione come ogni altra classe/oggetto.

Tuttavia, non ho mai visto un OKM (Object-Key/Value-Mapper) per NoSQL "Key/Value" sistemi di storage. Il che sembra strano perché la necessità dovrebbe essere molto più grande dato che più relazioni di valore dovranno essere codificate nell'app rispetto a un normale oggetto riga singola tabella SQL.

four requests: 
user:id 
user:id:name 
user:id:email 
user:id:created 

vs one request: 
user = [id => ..., name => ..., email => ...] 

Inoltre è necessario tenere traccia di "liste" (Post has_many) in quanto non si dispone di has_many attraverso tabelle o chiavi esterne.

INSERT INTO user_groups (user_id, group_id) VALUES (23, 54) 

vs 

usergroups:user_id = {54,108,32,..} 
groupsuser:group_id = {23,12,645,..} 

e ci sono molti altri esempi della logica ha aggiunto che la domanda avrebbe bisogno di replicare alcune funzionalità di base che i database relazionali normale utilizzo. Tutti questi motivi rendono l'idea di un OKM come una scarpa.

Ci sono? Ci sono ragioni per cui non ce ne sono?

Answer 1

Il progetto Ruby's DataMapper è un ORM e parlerà felicemente con un archivio di valori-chiave tramite l'uso di un adattatore.

Redis e MongoDB dotati di schede già esistenti. CouchDB ha un adattatore - non è mantenuto, ma a un certo punto ha funzionato abbastanza bene. Non credo che nessuno abbia ancora fatto niente con Cassandra, ma non c'è ragione per cui non si possa fare. Lo strumento Dubious framework per Google App Engine adotta un approccio molto simile a Data Mapper per rendere l'archivio dati disponibile per le applicazioni.

Quindi è molto possibile fare ORM con negozi di valore-chiave. L'ORM ha proprio bisogno di evitare il presupposto che SQL sia il suo vocabolario primario.

Answer 2

Gli ORM non si adattano molto bene alla natura senza schema degli archivi di valori chiave. Detto questo, se stai usando Riak e Ruby, potresti dare un'occhiata a Ripple. Ci sono molti altri driver per Riak che potrebbero adattarsi alla tua lingua.

Se stai esaminando MongoDB (più di un negozio di documenti che di un negozio di k/v), è disponibile un numero di drivers.

Answer 3

Uno degli obiettivi di progettazione di SQL è che qualsiasi dato può essere memorizzato/interrogato in qualsiasi database relazionale. Ci sono alcune differenze tra le piattaforme, ma in generale il modo corretto di gestire una particolare struttura di dati è ben noto e facilmente automatizzato ma richiede un codice abbastanza dettagliato. Questo non è il caso di NoSQL: in genere si memorizzeranno i dati direttamente come nell'applicazione anziché tentare di associarli a una struttura relazionale, e senza join o altre differenze di oggetti/relazioni il codice di mapping è banale.

Oltre a generare il codice di accesso ai dati boilerplate, uno degli scopi principali di un ORM è l'astrazione delle differenze tra le piattaforme. Nella mia esperienza, la possibilità di cambiare piattaforma è sempre stata puramente teorica, e questo approccio con il minimo comune denominatore non funzionerà per NoSQL in quanto la piattaforma viene solitamente scelta specificamente per le funzionalità non presenti su altre piattaforme. Il tuo esempio è solo per l'archivio dei valori chiave più banale - a seconda della tua piattaforma hai probabilmente qualche utile comando aggiuntivo, quindi il tuo primo esempio potrebbe essere

Utente MGET: id: nome utente: id: email ... (multiget - ottenere qualsiasi numero di chiavi in ​​una singola chiamata)

GET utente: id: * (jolly chiave)

HGETALL utente: id (Redis hash - ottiene tutte le sottochiavi di utenti)

potrebbero anche il tuo oggetto utente è memorizzato in una forma serializzata - diversamente da un database relazionale questo non interromperà tutte le tue query.

Il lavoro con gli elenchi non è eccezionale se la tua piattaforma non ha il supporto integrato - il supporto elenco/set nativo è uno dei motivi per cui mi piace usare i redis - ma a parte i blocchi potenzialmente necessari non è peggio che ottenere il elenco di sql.

Vale anche la pena notare che potresti non aver bisogno di tutte le relazioni che dovresti definire in sql - ad esempio se hai un gruppo contenente un milione di utenti, la possibilità di ottenere un elenco di tutti gli utenti di un gruppo è completamente inutile, quindi non creerai mai l'elenco dei gruppi utente e piuttosto che un elenco di gruppi separati avrà utente: id: groups come una proprietà multivalore. Se hai solo bisogno di verificare l'appartenenza, puoi impostare le chiavi come gruppi di utenti: userid: groupid e ottenere una ricerca costante di tempo.

Trovo utile pensare in termini di indici piuttosto che di relazioni: quando si imposta il codice di accesso ai dati decidere quali campi dovranno essere interrogati e aggiungere record di indice appropriati quando questi campi vengono scritti.

Answer 4

Il db UNIVERSE, che è un discendente di Pick, consente di memorizzare un elenco di coppie di valori chiave per una determinata chiave. Tuttavia questa è tecnologia molto vecchia e il mondo è scappato da questi database molto tempo fa.

È possibile implementare questo in un database SQL con una tabella a tre colonne

CREATE TABLE ATTRS (KEYVAL VARCHAR(32), 
         ATTRNAME VARCHAR(32), 
         ATTRVAR VARCHAR(1024) 
        ) 

Sebbene la maggior parte DBA colpiranno voi sopra la testa con il molto spessa edizione rilegata Codd e Data se si propone questo, è in Infatti, un modello molto comune nelle applicazioni pacchettizzate consente di aggiungere attributi specifici del sito a un sistema.

Per inaridire i commenti di Richrd Stallman su LISP. "Qualsiasi sistema di datastorage ragionevolmente funzionale finirà per implementare la propria versione di RDBMS."