Quali sono alcuni "passaggi mentali" che uno sviluppatore deve adottare per iniziare a passare da SQL a NO-SQL (CouchDB, FathomDB, MongoDB, ecc.)?

Question

Ho la mia mente saldamente incastrata nei database relazionali e su come codificarli efficacemente. La maggior parte della mia esperienza è con MySQL e SQL. Mi piacciono molte delle cose che sento sui database basati su documenti, specialmente quando qualcuno in un recente podcast ha menzionato enormi benefici in termini di prestazioni. Quindi, se ho intenzione di percorrere quella strada, quali sono alcuni dei passaggi mentali che devo prendere per passare da SQL a NO-SQL?

Se fa qualche differenza nella risposta, sono uno sviluppatore C# principalmente (oggi, comunque). Sono abituato a ORM come EF e Linq a SQL. Prima degli ORM, ho lanciato i miei oggetti con generici e datareader. Forse è importante, forse no.

Qui ci sono alcuni più specifico:

1. Come ho bisogno di pensare si unisce?
2. Come interrogherò senza un'istruzione SELECT?
3. Cosa succede ai miei oggetti memorizzati esistenti quando aggiungo una proprietà nel mio codice?

(sentitevi liberi di aggiungere le domande del proprio qui)

Answer 1

In primo luogo, ogni archivio NoSQL è diverso. Quindi non è come scegliere tra Oracle o Sql Server o MySQL. Le differenze tra loro possono essere vaste.

Ad esempio, con CouchDB non è possibile eseguire query ad-hoc (query dinamiche se lo si desidera). È molto buono in scenari offline online ed è abbastanza piccolo da funzionare sulla maggior parte dei dispositivi. Ha un'interfaccia RESTful, quindi nessun driver, nessuna libreria ADO.NET. Per interrogarlo si usa MapReduce (ora questo è molto comune nello spazio NoSQL, ma non è onnipresente) per creare viste, e queste sono scritte in un numero di lingue, sebbene la maggior parte della documentazione sia per Javascript. CouchDB è anche progettato per arrestarsi in modo anomalo, ovvero se qualcosa va storto, riavvia semplicemente il processo (il processo di Erlang o gruppo di processi collegati che è, non l'intera istanza CouchDB in genere).

MongoDB è progettato per essere altamente performante, dotato di driver e, a causa di ciò, sembra un salto di qualità per molte persone nel mondo .NET. Credo comunque che in situazioni di crash sia possibile perdere dati (non offre lo stesso livello di garanzie transazionali intorno alle scritture che CouchDB fa).

Ora entrambi sono database di documenti e, in quanto tali, condividono che i loro dati non sono strutturati. Non ci sono tabelle, nessuno schema definito - sono schemi. Tuttavia, non sono come un archivio di valore-chiave, poiché insistono sul fatto che i dati che si mantengono sono comprensibili per loro. Con CouchDB questo significa l'uso di JSON, e con MongoDB questo significa l'uso di BSON.

Ci sono molte altre differenze tra MongoDB e CouchDB e questi sono considerati nello spazio NoSQL per essere molto vicini nel loro design!

Oltre ai database di documenti, sono soluzioni orientate alla rete come Neo4J, archivi colonnari (orientati a colonne anziché orientati a righe nel modo in cui mantengono i dati) e molti altri.

Qualcosa che è comune a molte soluzioni NoSQL, oltre a MapReduce, è che non sono database relazionali e che la maggior parte non utilizza la sintassi in stile SQL. Tipicamente l'interrogazione segue una modalità imperativa di programmazione piuttosto che lo stile dichiarativo di SQL.

Un altro tratto tipicamente comune è che la coerenza assoluta, come tipicamente fornita dai database relazionali, viene scambiata per eventuali modelli di coerenza.

Il mio consiglio a chiunque desideri utilizzare una soluzione NoSQL sarebbe in primo luogo capire veramente i requisiti che hanno, capire gli SLA (quale livello di latenza è richiesto, quanto deve rimanere costante la latenza man mano che le soluzioni si ridimensionano; il carico è previsto, il carico è consistente o sarà impennato, quanto deve essere coerente una vista utente dei dati, devono sempre vedere le proprie scritture quando interrogano, se le loro scritture sono immediatamente visibili a tutti gli altri utenti, ecc. ..). Comprendi che non puoi avere tutto, leggi il teorema di Brewers CAP, che in sostanza dice che non puoi avere una coerenza assoluta, disponibilità al 100% e tolleranza alle partizioni (far fronte quando i nodi non possono comunicare). Quindi esamina le varie soluzioni NoSQL e inizia ad eliminare quelle che non sono progettate per soddisfare le tue esigenze, capisci che il passaggio da un database relazionale non è banale e ha un costo associato (ho trovato il costo di spostare un'organizzazione in questa direzione, in termini di riunioni, discussioni, ecc. è di per sé molto elevata, impedendo di concentrarsi su altre aree di potenziale beneficio). La maggior parte delle volte non avrai bisogno di un ORM (la parte R di questa equazione è appena scomparsa), a volte solo la serializzazione binaria può essere ok (con qualcosa come DB4O per esempio, o un archivio di valori-chiave), cose come Newton JSON/La libreria BSON può essere d'aiuto, così come l'automapper. Trovo che lavorare con C# 3 sia un costo definito rispetto a lavorare con un linguaggio dinamico come, per esempio, Python. Con C# 4 questo può migliorare un po 'con cose come ExpandoObject e Dynamic dal DLR.

di guardare il vostro 3 domande specifiche, con tutto ciò che dipende dalla soluzione di NoSQL si adotta, in modo che nessuno risposta è possibile, ma con questo avvertimento, in termini molto generali:

1. Se persiste il oggetto (o aggregazione più probabile) nel suo insieme, i tuoi join saranno tipicamente in codice, sebbene tu possa fare un po 'di ciò attraverso MapReduce.

2. Di nuovo, dipende, ma con Couch si eseguirà un GET su HTTP contro una risorsa specifica o contro una vista MapReduce.

3. Molto probabilmente nulla. Basta tenere d'occhio gli scenari di serializzazione e deserializzazione. La difficoltà che ho riscontrato deriva dal modo in cui gestisci le versioni del tuo codice. Se la proprietà è puramente per spingere a un'interfaccia (GUI, servizio web), tende ad essere meno di un problema. Se la proprietà è una forma di stato interno su cui si baserà il comportamento, allora questo può diventare più complicato.

Spero che ti aiuti, buona fortuna!

Answer 2

solo smettere di pensare al database.

Pensa a modellare il tuo dominio. Costruisci i tuoi oggetti per risolvere il problema a portata di mano seguendo buoni schemi e pratiche e non preoccuparti della persistenza.