Neo4j invece del database relazionale

Question

Sto implementando un portale web basato su sinatra/rails che potrebbe eventualmente avere pochi: molte relazioni tra tabelle/modelli. Si tratta di un team one-man e part-time ma app del mondo reale.

Ho discusso la mia entità con qualcuno e mi è stato consigliato di provare neo4j. Provenendo da un mondo imprenditoriale "non sexy", la mia inclinazione è quella di usare il db relazionale fino a quando non smette di ridimensionare o diventa un incubo a causa della condivisione, ecc. E poi penso a qualsiasi altra cosa.

TUTTAVIA,

• Sto usando Postgres per la prima volta in questo progetto insieme a DataMapper e la sua mi prendere tempo per iniziare molto veloce
• sto solo provando alcune cose e la costruzione di un uso più casi quindi devo aggiornare costantemente il mio schema (idea di prototipazione e feedback dalla versione beta). Non dovrò farlo in neo4j (eccetto cambiare le mie richieste)
• Sembra essere molto facile da configurare la ricerca usando neo4j. Ma Postgres può anche effettuare ricerche di testo completo.
• Postgres ha recentemente annunciato il supporto per json e javascript. Mi chiedo se dovrei limitarmi a usare PG e investire più tempo nell'apprendimento del PG (che ha una buona comunità) invece neo4j.

Ricerca di casi in cui neo4j è migliore, soprattutto in fase di prototipazione/iniziale di un progetto. Capisco che se il sito cresce, potrei finire per avere più tecnologie persistenti come s3, relazionale (PG), mongo ecc.

Inoltre sarebbe bene sapere come si gioca con l'ecosistema Rails/Ruby.

---

Update1:

ho avuto un sacco di buone risposte e sembra che la cosa giusta da fare è attaccare con Postgres per ora (soprattutto da quando schiero a Heroku)

Tuttavia l'idea di essere senza schema è allettante. Fondamentalmente sto pensando ad un approccio in cui non si definisce un datamodel fino a quando non si dicono 100-150 utenti e si è capito un buon schema (casi d'uso aziendali) per il proprio prodotto, mentre si sta solo dimostrando il concetto e ottenendo feedback con iscrizioni limitate. Quindi si può decidere uno schema e iniziare con relazionale.

sarebbe bello sapere se ci sono facili da usare meno l'opzione di persistenza schema/(basato sulla facilità di utilizzare/setup per nuovo utente) che potrebbero rinunciare a dire il ridimensionamento ecc

Answer 1

database grafico dovrebbe essere considerata se hai un modello di dati davvero caotico. Erano necessari per esprimere relazioni altamente complesse tra entità. Per fare ciò, memorizzano le relazioni a livello di dati mentre RDBMS utilizza un approccio dichiarativo. Memorizzare le relazioni ha senso solo se queste relazioni sono molto diverse, altrimenti finirai per duplicare i dati più e più volte, occupando molto spazio per niente. Per richiedere una tale varietà nelle relazioni dovresti gestire una grande quantità di dati. È qui che i database dei grafici risplendono perché instand di fare tonnellate di join, scelgono solo un record e seguono le sue relazioni. Per supportare la mia affermazione: noterai che ogni use cases sul sito Web di Neo4j tratta dati molto complessi.

In breve, se non ti senti preoccupato di ciò che ho detto sopra, penso che dovresti usare un'altra tecnologia.Se si tratta solo di ridimensionamento, schematicità o avvio rapido di un progetto, allora si guardano altre soluzioni NoSQL (in particolare, database a colonna o orientati ai documenti). Altrimenti dovresti seguire PostgreSQL. Potresti anche, come hai detto, considerare polyglot persistence,

Informazioni sull'aggiornamento, potresti considerare hStore. Penso che soddisfi le tue esigenze. È un modulo PostgreSQL che funziona anche su Heroku.

Answer 2

Non credo di essere d'accordo sul fatto che si dovrebbe utilizzare un database grafico solo quando il modello di dati è molto complesso. Sono sicuro che potrebbero gestire anche un semplice modello di dati/relazioni.

Se non hai precedenti esperienze con Neo4j o Postgres, molto probabilmente entrambi richiedono molto tempo per imparare bene.

Alcune cose da tenere a mente al momento del ritiro:

1. Non si tratta solo di sviluppo contro una tecnologia di database. Dovresti considerare anche la distribuzione. Quanto è facile implementare e scalare Postgres/Neo4j?

2. Considerate la comunità e gli strumenti attorno a ciascuna tecnologia. Esiste un mapper dei dati per Neo4j come per Postgres?

3. Considerare che i modelli di dati sono considerevolmente diversi tra i due. Se riesci già a pensare in modo relazionale, allora probabilmente starei con Postgres. Se vai con Neo4j farai molti errori per diversi mesi con i tuoi modelli di dati.

4. Nel corso del tempo ho imparato a mantenere le cose semplici quando posso. Postgres potrebbe essere la scelta noiosa rispetto a Neo4j, ma noioso non ti tiene sveglio la notte. =)

Inoltre non ho mai visto nessuno ne parla, ma si dovrebbe guardare a Riak (http://basho.com/riak/) troppo. È un database di documenti che fornisce anche relazioni (collegamenti) tra oggetti. Non è maturo come un database grafico, ma può collegare rapidamente alcune entità.

Answer 3

La scelta più appropriata dipende dal problema che si sta tentando di risolvere.

Se si dispone di poche tabelle molti a molti, un database relazionale può andare bene. In generale, esiste un supporto OR-mapper migliore per i database relazionali, poiché sono molto più vecchi e hanno un'interfaccia standardizzata e una struttura a righe. Inoltre sono stati migliorati per molto tempo, quindi sono stabili e ottimizzati per quello che stanno facendo.

Un database grafico è migliore se ad es. il tuo problema riguarda più le connessioni tra entità, specialmente se hai bisogno di connessioni a distanza più alte, come "rilevare cicli (di lunghezza non specificata)", alcuni "che cosa amano gli amici di un amico". Cose del genere diventano ingombranti quando sono limitate ai join SQL. Un linguaggio specifico per il problema come cypher in caso di Neo4j lo rende molto più conciso. Al rovescio della medaglia, ci sono mapper tra il grafico dbs e gli oggetti, ma non per ogni struttura e linguaggio sotto il sole.

Recentemente ho implementato un prototipo di sistema utilizzando neo4j ed è stato molto utile poter parlare della struttura e delle connessioni dei nostri dati ed essere in grado di modellarli uno a uno nell'archiviazione dei dati. Inoltre, l'aggiunta di altre connessioni tra i punti di dati era facile, dato che neo4j era uno storage senza schemi. Abbiamo finito per passare a mongodb a causa di problemi con le prestazioni in scrittura, ma non penso che avremmo potuto completare il prototipo con quello nello stesso tempo.

Altri datastore NoSQL come il valore-chiave basato su documento, colonna, coprono anche casi specifici. La persistenza di Polyglot è definitivamente qualcosa da guardare, quindi tieni la tua scelta di backend ragionevolmente separata dalla tua logica di business, per consentirti di cambiare la tua tecnologia più tardi se hai imparato qualcosa di nuovo.