It depends what forum you were using before... we have specific exporters for most of the major forum software platforms.
If it's custom then you're looking at having to write your own or contact us at firstname.lastname@example.org for a quote.
I've found that NodeBB, when configured to use MongoDB, uses one single collection for all documents (users, posts...). And uses the
_key field 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...