Should we use dbref or embedded document in a read-heavy application

Question

We are developing an application which is read heavy and could possibly have millions of documents. We need to refer to user information in almost every collection. User information has some attribute that can change from time to time.

Should we use DBref or embed the user information in all collections?

How bad is DBref performance in a heavy read app?

If we will not use DBref, how can we update each document, if the user information changes periodically?

In Mongodb, is there any alternative for DBref and embedded documents for this kind of use case?

Answer 1

DBref isn't anything like a Foreign key in traditional relational systems. Its only a convention which easily tells a driver (who's capable of) to autoload those referred documents. Please see DBRef for more information on this.

Depending on the driver used, you may be able to load those references automatically only when you need them (lazy), so the performance overhead should be really small. But the storage overhead is a bit higher than a simple referenced _id of another document. Basically, I would say that you should only use those DBrefs if the linked document can be of variable type. If it's static then you're stuck with _id-references and maybe your own lazy loader functionality, so you don't repeat yourself.

Don't repeat yourself (or data duplication in database terms) applies in your context as well, as MongoDB recommends (so I would too), is to only link your documents. Else you would have higher storage usage and somewhat long running updates, to update only one logical entity (duplicated physically very often).

With the previously mentioned custom lazy loader you may add some caching so that not every lookup actually results in a mongodb lookup. Most likely you would then need to take care of your data consistency between cache and db.