4

I've heard about RethinkDB and since I'm developing a multi-player online game I think if MongoDB pushes the changes (let's say new rows) instead of pulling rows, it would be much faster for both server-side and client-side.

Is there any wrapper or techniques to make a realtime query to MongoDB or not?

Afshin Mehrabani
  • 33,262
  • 29
  • 136
  • 201
  • Jorge @ RethinkDB here. Just out of curiosity, why not just use RethinkDB? It's also a NoSQL document store and you get changefeeds out of the box. I don't mean to be pushy, I'm actually just curious! – Jorge Silva Apr 19 '15 at 03:00
  • @JorgeSilva Nice to have you here! You know, mongodb has tons of articles, resolved issues and drivers. Also most of NodeJS developers use MongoDB because of the `Mongoose`. To be honest, I think replication and sharding in MongoDB works really better. – Afshin Mehrabani Apr 19 '15 at 05:59

1 Answers1

2

You can leverage tailable cursors on capped collections. At the lowest level, that would require writing all changes to the capped collection first, then have them be applied by some kind of worker (an event sourcing pattern). That's a severe change of application architecture, so it's probably not what you want.

A more generic approach is to watch the oplog, a special capped collection that is used to synchronize master and secondary nodes and that contains all operations performed on documents, so no change in application architecture is required.

Still, this is somewhat more low-level than what RethinkDB exposes, in particular because you need to perform a diff. There are wrappers that can hide some of the complexity, but I haven't used them and I don't know what programming language you're using. Oplog monitoring is used, for example, by Meteor, which is pretty much built on publish/subscribe and hides most of the complexity, so it's generally possible, though it seems it's more complicated than with RethinkDB.

mnemosyn
  • 45,391
  • 6
  • 76
  • 82
  • 1
    Awesome answer, thank you. One more question, after detecting a change using `tail oplog`, should I make a new query to the `mongo` instance and fetch the records or not? – Afshin Mehrabani Apr 18 '15 at 10:16
  • hm, now that you say it, that's probably a very easy way to get around the diff problem ;-) I mean, you don't *have* to, because the oplog information is sufficient to advance the document to its current state, but on the other hand, that requires understanding and re-implementing how mongodb applies those operations, which is relatively hard to do. Re-fetching is definitely a lot easier, but will incur more queries, so this is a code-complexity / performance tradeoff. Start with re-querying, if performance is sufficient, you're done, if not reiterate. – mnemosyn Apr 18 '15 at 10:20
  • Aha, got it! So, I think this is directly related to performance issues as well. – Afshin Mehrabani Apr 18 '15 at 10:28