3 ms·

Oh, the fud of it. The behavior is well documented here https://jira.mongodb.org/browse/SERVER-14766 https://jira.mongodb.org/browse/SERVER-14766 and in the l

Oh, the fud of it. The behavior is well documented here https://jira.mongodb.org/browse/SERVER-14766 https://jira.mongodb.org/browse/SERVER-14766 and in the linked issues. Seasoned users of mongodb know to structure their queries to avoid depending on a cursor if the collection may be concurrently updated by another process. The usual pattern is to re-query the db in cases where your cursor may have gone stale. This tends to be habit due to the 10-minute cursor timeout default. MongoDB may not be perfect, but like any tool, if you know its limitations it can be extremely useful, and it certainly is way more approachable for programmers who do not have the luxury of learning all the voodoo and lore that surrounds SQL-based relational DB's. Look for some rational discussion at the bottom of this mongo hatefest!

lars_francke 10y ago
I wouldn't call a JIRA ticket good documentation. While I agree that it's good to know the limitations of the tools you chose those limitations should be clearly spelled out in the documentation. I don't think most programmers have the luxury of learning all the voodoo and lore that surrounds MongoDB from JIRA tickets and blog posts.
- danbmil99 10y ago
  > I don't think most programmers have the luxury of learning all the voodoo and lore that surrounds MongoDB from JIRA tickets and blog posts. That's how I learned everything I know about most FOSS products I have encountered - through the code pages and social media surrounding the project. Pretty much everything about the mongodb hate derives from their marketing and sales. The truth is, they've obviously stumbled onto something the market wants, otherwise they would never have become so successful. For me, as a long-time programmer with no database experience, the mental mapping of JSON constructs as both data and query language was far easier for me to absorb than the relational model, which didn't fit the paradigms that I was used to. At my present gig, we've used Mongo DB for two years, scaling up to quite a large production setup. Like any technology it has strengths and weaknesses, but it has not been the utter failure that readers of Hacker News would be led to expect. We adopted it knowing quite a bit about its history, and it has turned out to be an excellent choice that has held up over time. Periodically we've considered switching to postgres, and we may do so for part of our stack. But for the core jobs of data collection and batch processing data with fluid schema, I'm pretty sure we will stick with mongodb for the duration. It's just a tool, folks.
tomp 10y ago
> The usual pattern is to re-query the db in cases where your cursor may have gone stale. You mean, every time you query the DB? Do you also need to re-query the re-queries?
NateDad 10y ago
Uh... things that seem to work fine in Mongo under light load tend to fall over during heavy load. Things like this problem. Like key reordering: https://jeremywsherman.com/blog/2013/04/23/key-reordering-ruins-mongodb/ https://jeremywsherman.com/blog/2013/04/23/key-reordering-ru... Yes, with enough extremely careful coding knowing exactly all the internals of the database, you can probably avoid these giant gotchas. But that's a hell of a lot of work for a DB that's supposed to be easy. And then you're still dealing with a database without ACID guarantees. No transactions, very little atomicity.... and good luck if your server crashes... we've had multiple customers have their DB corrupted that way. MongoDB is only good for storing data you don't really care about... in which case, why are you bothering to store it at all? What most people end up storing in Mongo: strongly schema'ed, relational data that is critical to their application. This is exactly what mongo is not for.

lars_francke 10y ago

I wouldn't call a JIRA ticket good documentation. While I agree that it's good to know the limitations of the tools you chose those limitations should be clearly spelled out in the documentation. I don't think most programmers have the luxury of learning all the voodoo and lore that surrounds MongoDB from JIRA tickets and blog posts.

danbmil99 10y ago
> I don't think most programmers have the luxury of learning all the voodoo and lore that surrounds MongoDB from JIRA tickets and blog posts. That's how I learned everything I know about most FOSS products I have encountered - through the code pages and social media surrounding the project. Pretty much everything about the mongodb hate derives from their marketing and sales. The truth is, they've obviously stumbled onto something the market wants, otherwise they would never have become so successful. For me, as a long-time programmer with no database experience, the mental mapping of JSON constructs as both data and query language was far easier for me to absorb than the relational model, which didn't fit the paradigms that I was used to. At my present gig, we've used Mongo DB for two years, scaling up to quite a large production setup. Like any technology it has strengths and weaknesses, but it has not been the utter failure that readers of Hacker News would be led to expect. We adopted it knowing quite a bit about its history, and it has turned out to be an excellent choice that has held up over time. Periodically we've considered switching to postgres, and we may do so for part of our stack. But for the core jobs of data collection and batch processing data with fluid schema, I'm pretty sure we will stick with mongodb for the duration. It's just a tool, folks.

tomp 10y ago

> The usual pattern is to re-query the db in cases where your cursor may have gone stale. You mean, every time you query the DB? Do you also need to re-query the re-queries?

NateDad 10y ago

Uh... things that seem to work fine in Mongo under light load tend to fall over during heavy load. Things like this problem. Like key reordering: https://jeremywsherman.com/blog/2013/04/23/key-reordering-ruins-mongodb/ https://jeremywsherman.com/blog/2013/04/23/key-reordering-ru... Yes, with enough extremely careful coding knowing exactly all the internals of the database, you can probably avoid these giant gotchas. But that's a hell of a lot of work for a DB that's supposed to be easy. And then you're still dealing with a database without ACID guarantees. No transactions, very little atomicity.... and good luck if your server crashes... we've had multiple customers have their DB corrupted that way. MongoDB is only good for storing data you don't really care about... in which case, why are you bothering to store it at all? What most people end up storing in Mongo: strongly schema'ed, relational data that is critical to their application. This is exactly what mongo is not for.