MongoDB è appropriato per i sistemi che probabilmente cambieranno?

4

Ho usato MongoDb (principalmente con Meteor) e per me è stato un ottimo modo per mascherare rapidamente prototipi e prove di concetti.

Mi stavo solo chiedendo, dopo aver creato il prodotto iniziale, se è probabile che il tuo prodotto cresca e cambi, è una buona idea attaccare con mongoDb?

Perché sembra che con MongoDb, devi sapere molto su come userai i dati in anticipo. Dalla mia sola esperienza, mi è sembrato di provare costantemente a decidere se un tipo di dati debba essere un documento a sé stante o un sotto-documento.

Il fatto di renderlo un documento gli dà flessibilità, ma se si hanno tutti i tipi di dati come documenti, beh, allora si ha praticamente un database SQL con chiavi esterne prive di gruppi di chiavi straniere.

Renderlo un documento secondario rende le cose migliori mentre sono comode - non è necessario unire tabelle (che sembra dover fare manualmente) - ma il problema sembra essere se devi interrogare quel tipo di dati al di fuori del contesto del genitore, è molto difficile.

Ad esempio, se creo un sito Web con chat, potrei avere due tipi di dati: chat e textEntries.

Chatroom sarà il proprio documento. Ma textEntries può essere un documento a sé stante o un documento secondario all'interno di Chatroom.

Se creo un documento con TextEntries, allora dovrei tenere traccia manualmente della relazione tra chatroom e textEntries che vanifica lo scopo di usare mongoDB.

Se faccio di TextEntries un documento secondario, questo renderà le cose più semplici ma cosa succederebbe se in seguito avessi un nuovo requisito in cui voglio cercare tra tutti i TextEntries in tutte le chat per una parola particolare?

Con un prototipo, so esattamente cosa sto costruendo, quindi queste decisioni tendono a basarsi sul solo modo di far funzionare il prodotto. Ma a lungo termine, non saprei come o in che modo ho intenzione di interrogare i dati, quindi alla luce di ciò, sarebbe meglio passare semplicemente a un database SQL?

    
posta RoboShop 26.08.2014 - 04:06
fonte

3 risposte

3

MongoDB è un NoSQL database che si concentra sui documenti.

La ricerca di documenti in generale si basa su corrispondenze arbitrarie nel mezzo di grandi quantità di testo, logica fuzzy / matching e altre attività che non sono confronti secchi e logici booleani che esistono in SQL.

Conosco personalmente più sviluppatori su Hyland Software , la società dietro OnBase che è un database NoSQL proprietario che ricerca in modo efficiente milioni di di documenti. Per ottenere dati nel software, è necessario eseguirne la scansione: le funzionalità OCR si collegano ai dati testuali che possono essere successivamente ricercati. Piuttosto che fare un appello all'autorità , dirò che questo mi ha illuminato all'utilizzo dei database NoSQL nell'azienda e il loro ruolo.

In un database SQL, spesso devi conoscere il contesto dei dati che desideri. È un nome? Numero di modulo? Qualche altro campo? Con una soluzione NoSQL basata su documenti, è possibile cercare qualsiasi cosa utilizzando una logica che non è l'ideale (per SQL) con un impatto minimo sulle prestazioni. Non stai dicendo "find me records where field X contains Y" stai dicendo "find me documents with Y" e il database è ottimizzato per questi tipi di query. I documenti spesso non contengono campi chiari. Mentre una lettera (cara nonna) può contenere un indirizzo, non è annotata come tale. In un RDBMS, i campi degli indirizzi sarebbero suddivisi e interrogabili. Vuoi la strada o la città? È distinto dagli altri elementi. In un database di documenti, è tutto bloccato insieme. La ricerca di un codice postale specifico non è chiara come una query, ma i database dei documenti sono costruiti per questo.

Altre volte, i database relazionali hanno prestazioni migliori. Hai bisogno di documenti in cui sai che il campo è un valore specifico o link a un record specifico? SQL è il vincitore.

Martin Fowler afferma che ogni tipo di database ha il suo posto e spesso vengono usati insieme. Sulla base del suo parere di un esperto, non sceglierei un database o l'altro: li utilizzerei entrambi, sfruttando ciascuno dove i suoi punti di forza sono maggiori delle sue debolezze.

Nell'esempio specifico di chat su un sito web, ha senso che una voce di testo sia un documento secondario di una chat room (documento). Una voce di testo potrebbe essere citata fuori dal contesto, ma la sua identità è, in parte, la chat room che la contiene. Senza la chat room, le voci di testo sono un caos disordinato e senza significato.

    
risposta data 26.08.2014 - 05:31
fonte
2

La mia risposta generale è che usi qualsiasi database che ritieni possa migliorare il tuo servizio.

Hai scritto:

I'm just wondering, after building the initial product, if your product is likely to grow and change, is it a good idea to stick with mongoDb?

Sì, soprattutto se lo schema sta per cambiare, MongoDB è più facile da mantenere in questo caso. In un certo senso, è uno dei motivi per cui molte persone lo preferiscono. Si può dire che è uno dei suoi principali casi d'uso.

Cause it seems like with MongoDb, you need to know a lot about how you're going to use the data upfront. From my experience only, I seemed to constantly be trying to decide whether a datatype should be a document in its own right or a sub-document.

Al contrario, molte persone preferiscono semplicemente scaricare i documenti e preoccuparsene più tardi. Ovviamente sto esagerando, ma ha i suoi meriti quando hai clienti che cambiano idea troppo spesso, o il progetto avanza in modo sporadico a causa dell'entrata in acque inesplorate. Ovviamente rende difficile utilizzare gli indici in modo efficiente, ma sarebbe utile quando si modificano parti della propria logica e non si dovrà eseguire la migrazione dei dati.

Making it a document gives it flexibility, but if you have all your datatypes as documents, well then you pretty much just have an SQL database with foreign keys that have no foreign key constaints.

Making it a subdocument makes things perform better whilst being convenient - you don't need to join tables (which you seem to have to do manually) - but the problem seems to be if you need to query that datatype outside the context of the parent, it's very hard.

So for example, if I'm building a website with chatrooms, I might have two datatypes - chatrooms and textEntries.

Chatroom will be its own document. But textEntries can either be a document in its own right or a subdocument within Chatroom.

Sei molto corretto. Potresti provare denormalizzando i tuoi dati o recuperare i tuoi dati in 2 passaggi come in seguito (usando una logica imperativa per la demo). Questo sarà abbastanza veloce, molto probabilmente più veloce di una soluzione sql. (assicurati di indicizzare i campi interrogati)

var user = db.user.query({_id: user_id});
var chatrooms_id = user.current.chatrooms_id;
var messages = db.textEntries({
  chatrooms_id: chatrooms_id, 
  created_at: { $gt: since_last_checked }
});

If I make TextEntries a document, then I would need to manually keep track of the relationship between chatroom and textEntries which defeats the purpose of using mongoDB at all.

Devi anche assicurarti di non superare il limite di 16 MB del documento, se decidi di inserire molti dati in un documento. Per questo motivo, la memorizzazione di tutti i messaggi di testo all'interno di un documento di chatroom è eccessiva e non funzionerebbe con stanze di grandi dimensioni. Se hai perso questo link sugli esempi di modellazione dei dati nella documentazione, sarebbe utile dare un'occhiata.

If I make TextEntries a subdocument, this will make things easier but what if later on, I have a new requirement where I want to search across all TextEntries in all chatrooms for a particular word?

Vorrei semplicemente usare ElasticSearch per questo. Non sono sicuro che una soluzione sql sarebbe molto più veloce di Mongodb. I loro sistemi di ricerca full-text in genere non sono molto performanti, rispetto a una soluzione dedicata come ES, Sphinx, Lucene, Solr, scegli il tuo preferito.

With a prototype, I know exactly what I'm building so these decisions tend to be based on just getting the product working. But longer term, I wouldn't know how or in what way I'm going to want to query the data so in light of that, would I be better off just moving to an SQL database?

Vorrei utilizzare tutti e tre i motori di ricerca di testo, sql, nosql. Inoltre, aggiungerei i database in memoria, colonnari e grafici a questo, se le tue esigenze li richiedono. Perché limitarti? Non è l'uno o l'altro, è quello che mi porterà dove voglio andare più veloce nel tempo che ho.

Ad esempio, è possibile utilizzare MongoDB per le scritture client-facing, poiché è più veloce scrivere. Potresti sincronizzare questi risultati con un dl sql, e fare analisi e alcune query su questo. Puoi conservare gli ultimi 15 minuti di voci di testo in Redis, quindi non avresti nemmeno colpito il disco per la maggior parte dei casi.

    
risposta data 02.09.2014 - 19:02
fonte
1

Dato che MongoDB non ha schemi molte persone sostengono che è più appropriato per i sistemi che sono suscettibili di cambiamenti, sebbene io sia completamente d'accordo con te che devi strutturare attentamente i dati in modo appropriato per il tuo specifico use case.

Riguardo al caso d'uso che hai citato, potrebbe essere utile tenere a mente la dimensione massima per un singolo documento - 16 MB credo, anche se ammetto che sarebbe una busy chat room -

Potrebbe essere la mia età avanzata, ma credo che l'attuale passaggio a NoSql prima sia probabilmente sbagliato. Può essere molto più semplice mappare oggetti grafici a Document Databases ma ci sono alcuni compromessi significativi che vengono con NoSql e personalmente sento che usare un RDBMS fino a quando non si inizia a colpire i limiti di prestazioni che impone (o alcuni hanno bisogno specialistico di un RDBMS non può riempire ) è probabilmente una scommessa più sicura.

    
risposta data 01.09.2014 - 15:34
fonte

Leggi altre domande sui tag