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.