5 ms·

No mention of Mongo "/dev/null as a service" DB's infamous issues with data loss? Apparently their new replication protocol isn't as utterly broken as the old

No mention of Mongo "/dev/null as a service" DB's infamous issues with data loss? Apparently their new replication protocol isn't as utterly broken as the old one, but my understanding is that data recovery after server crashes is still a problem.

btown 9y ago
I ran into a doozy in our production Mongo 3.2 replica set just this week, where initial sync completely failed because the oplog was growing too fast. It seems this class of errors was actually fixed ( https://docs.mongodb.com/manual/core/replica-set-sync/#initial-sync https://docs.mongodb.com/manual/core/replica-set-sync/#initi... ) in 3.4, which also fixed a number of the data reliability issues you mentioned (see https://jepsen.io/analyses/mongodb-3-4-0-rc3 https://jepsen.io/analyses/mongodb-3-4-0-rc3 ). But since we hadn't upgraded, the only way to fix things was to throttle back our write-heavy background tasks during a period of low usage - definitely not the kind of thing you want to have to explain to users. At the end of the day (see my other comment in this thread), I'm bullish about the developer experience of Mongo/Meteor, and I think that 363 days a year of significantly increased developer productivity is worth the 1 day of devops hell that might ensue from that stack choice, and 1 day of realizing that your performance problems all stem from Mongo query performance being much more reliant on manually creating indices on fields vs. an unindexed Postgres table of the same size. Sigh. On the reliability end, it helps that our (largely append-only) data model is such that inconsistencies are possible to clear up manually if needed. But on those couple days a year, I'm definitely not a Mongo fan.
- beager 9y ago
  Developer productivity vs devops hell is a compelling argument for MongoDB for fast iteration when building out. I'm fortunate to deal with relatively low scale with my Mongo deployment, but I'm hoping by the time the seams show in Mongo for our needs, we'll be large enough to abide the long road to a hardened and reliable data infrastructure. MongoDB 3.4 seems like it has a lot of great stuff and I hope to move to it soon.
- zepolen 9y ago
  I've seen this 'increased productivity' argument for Mongo over and over but I just don't see it in practice. I've dealt with many apps and teams that use Mongo, and the amount of time spent tracking annoying bugs because of a lack of schema, writing migration scripts and the abysmal performance of the database leads me to believe that the only reason Mongo devs think they are more productive is because they can get 3 lines of code to make a new collection + record in the database in 5 seconds, and ignore the 5 months of time they spent down the line.

btown 9y ago

I ran into a doozy in our production Mongo 3.2 replica set just this week, where initial sync completely failed because the oplog was growing too fast. It seems this class of errors was actually fixed ( https://docs.mongodb.com/manual/core/replica-set-sync/#initial-sync https://docs.mongodb.com/manual/core/replica-set-sync/#initi... ) in 3.4, which also fixed a number of the data reliability issues you mentioned (see https://jepsen.io/analyses/mongodb-3-4-0-rc3 https://jepsen.io/analyses/mongodb-3-4-0-rc3 ). But since we hadn't upgraded, the only way to fix things was to throttle back our write-heavy background tasks during a period of low usage - definitely not the kind of thing you want to have to explain to users. At the end of the day (see my other comment in this thread), I'm bullish about the developer experience of Mongo/Meteor, and I think that 363 days a year of significantly increased developer productivity is worth the 1 day of devops hell that might ensue from that stack choice, and 1 day of realizing that your performance problems all stem from Mongo query performance being much more reliant on manually creating indices on fields vs. an unindexed Postgres table of the same size. Sigh. On the reliability end, it helps that our (largely append-only) data model is such that inconsistencies are possible to clear up manually if needed. But on those couple days a year, I'm definitely not a Mongo fan.

beager 9y ago
Developer productivity vs devops hell is a compelling argument for MongoDB for fast iteration when building out. I'm fortunate to deal with relatively low scale with my Mongo deployment, but I'm hoping by the time the seams show in Mongo for our needs, we'll be large enough to abide the long road to a hardened and reliable data infrastructure. MongoDB 3.4 seems like it has a lot of great stuff and I hope to move to it soon.
zepolen 9y ago
I've seen this 'increased productivity' argument for Mongo over and over but I just don't see it in practice. I've dealt with many apps and teams that use Mongo, and the amount of time spent tracking annoying bugs because of a lack of schema, writing migration scripts and the abysmal performance of the database leads me to believe that the only reason Mongo devs think they are more productive is because they can get 3 lines of code to make a new collection + record in the database in 5 seconds, and ignore the 5 months of time they spent down the line.