I had back this problem a 2nd time 2 days ago, I don't know if it's related but I was doing iptables FW settings on the VM, I had nodeBB running, and also redis and from my computer desktop redis desktop manager connected to DB.
Then I made a mistake in iptables, blocked all redis port (even local), saying nodebb unable to connect to redis (so as redis desktop manager) then when I openned back 6379 port, all data was gone, not sure if it's related, just an information.
mongodb single collection?
I've found that NodeBB, when configured to use MongoDB, uses one single collection for all documents (users, posts...). And uses the
_keyfield to differentiate between them.
Well, my first impression is: WTF? Why not using different collections, with different indexes for each? Is there any reason to avoid separate collections? Are there any performance implications on using a single collection?
I'm not saying this is bad, it is just that I'm surprised, as I haven't seen this before. Could you please explain the reason/s behind this decision?
When we first started out we only used redis, mongodb support was added later on. Redis does not have a collection system like mongodb everything is stored as key/value pairs. So the mongodb code mimics that.
For example when you delete a key from the database you do
db.delete('keyname');if we were to use multiple collections we would have to check each collection to search for that key name. This also applies to stuff like renaming keys as well. The database system doesn't know anything about users/posts/categories, all of these are stored as objects.
If you look through the mongodb code here https://github.com/NodeBB/NodeBB/tree/master/src/database/mongo you will see it just provides a redis like interface for stuff like hashes, sets, sorted sets and so on.
Performance wise, on mongodb 2.6 and lower updates do block reads on the same collection so on a write heavy forum mongodb performance isn't great but this is being addressed in mongodb 2.8 which will bring document level locking so updating a document will not lock the entire collection.
In a nutshell, because database abstraction layers make compromises...