3 ms·
I have to agree with the author, especially since the points he raises are the ones that helped me greatly on my first "serious" personal project[1]. Coming fr
by emilburzo 11y ago
I have to agree with the author, especially since the points he raises are the ones that helped me greatly on my first "serious" personal project[1].
Coming from postgresql land I would have never thought you can have such great replication with automatic failover. I've had literally 100% uptime for the past year.
And that's on commodity servers (one of them being in a room in my apartment, the other two in a proper datacenter) going through the usual upgrades, downtime, reboots, going from mongo 2 to mongo 3 and such.
Speaking of which, the migration from mongo2 to mongo3 was another pleasant surprise: they've made it backwards compatible. So I could do the upgrade on the servers, one by one, checking everything was ok and after that I could focus on updating the drivers and rewriting the deprecated queries, no need to have everything ready at once.
The accessible oplog was another gem that fit my project really well. Gone was the need to poll the database, I could just "watch" the oplog. That, coupled with long polling on the browser side meant I'd have very little chatter between the db/server/web client when idle. Websockets would have been nice, but adoption wasn't high enough that I'd be comfortable going forward with it.
And all this considering MongoDB was my first NoSQL experience.
I agree it doesn't fit every project, but when it does, it's a really nice experience.
[1] https://graticule.link/ https://graticule.link/
- ngrilly 11y agoI agree that MongoDB has a great replication story. But I don't understand that part: > The accessible oplog was another gem that fit my project really well. Gone was the need to poll the database, I could just "watch" the oplog. Coming from PostgreSQL, you could do the same using LISTEN/NOTIFY?
- emilburzo 11y ago> Coming from PostgreSQL, you could do the same using LISTEN/NOTIFY? I have to admit I was not aware of this feature. However, from the docs[1]: > Commonly, the channel name is the same as the name of some table in the database, and the notify event essentially means, "I changed this table, take a look at it to see what's new". From what I understand, you just know that something has changed, the actual change is not included in the event, so you need at least another query to see what changed. Did I understand correctly? In MongoDB you get the operation (insert, update, delete), the document and another few details right in the event. [1] http://www.postgresql.org/docs/9.4/static/sql-notify.html http://www.postgresql.org/docs/9.4/static/sql-notify.html
- ddorian43 11y agoWhen you notify, you can also include a payload (ex json) which can be whatever you want.
- anentropic 11y agoI looked into this before and the Postgres docs say somewhere the payload size is limited and intended to be small metadata... in some cases you will not be able to fit the contents of the update into it
- danneu 11y agoLooks like the default limit is 8000 bytes.
- ngrilly 11y agoGood question :-) You can do as ddorian43 explained, by including a payload in your notification (using JSON or another format). Or you can do as you suggested and query the database to fetch more information about the change. Apart LISTEN/NOTIFY, which is a very powerful feature, PostgreSQL also provides "logical decoding" which solves problems similar to the ones solved by oplog tailing.
- count 11y agohttps://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-read... I don't know that it's story is so great. EASY, sure, but what good is easily replicating bad data?
- ngrilly 11y agoYes, I'm aware of aphyr's post, which reveals serious limitations in MongoDB. I said the replication story is great, not the consistency story ;-)