Live data from Hacker News

MongoDB queries don’t always return all matching documents

engineering.meteor.com

101–110 of 419 posts

Re: MongoDB queries don’t always return all matching documents

#101
post #41

Said it before, will say it again... "MongoDB is the core piece of architectural rot in every single teetering and broken data platform I've worked with." The fundamental problem is that MongoDB provides almost no stable semantics to build something deterministic and reliable on top of it. That said. It is really, really easy to use.

As a guy who works on ACID database internals, I'm appalled that people use MongoDB. You want a document store? Use Postgres. Why on earth would you use a database that makes so little in the way of guarantees about what results you get from it? I think most people have really low load and concurrency, so things seem to work. When things get busier you're in for a world of pain. Look I get that's it's easy to use and…

Because postgres doesn't focus on the first-five-minutes experience the way Mongo does. Even the name is hard to say.

Mongo is a dumb, dead-end platform, but they know how important ease-of-use is.

Re: MongoDB queries don’t always return all matching documents

#102

I have moved from Mongo to Cassandra in a financial time series context, and it's what I should have done straight from the getgo. I don't see Cassandra as that much more difficult to setup than Mongo, certainly no harder than Postgres IMHO, even in a cluster, and what you get leaves everything else in the dust if you can wrap your mind around its key-key-value store engine. It brings enormous benefits to a huge clas…

Genuinely curious: when you say "it brings enormous benefits to a huge class of queries that are common in timeseries", what are you referring to, exactly?

I run Cassandra in production and I love its operational simplicity, scale-out design, and write performance. But I think its support for time series is perhaps over-hyped. To me, it seems the only queries you can run in Cassandra is a key lookup (partition key row get) and a column slice (partition key row get filtered by an ordered range of columns). This allows for a certain time series use case e.g. where each row represents exactly one series, and where the only thing you want to do with a series is to get its raw values. But it doesn't allow for many of the things I personally think of when I think about "time series queries", e.g. resampling, aggregates, rollups, and the like.

Re: MongoDB queries don’t always return all matching documents

#103

CouchDB is simple and reliable. You can understand it from day one. I can't imagine why it isn't being used.

I really want an excuse to build something with CouchDB and PouchDB (https://pouchdb.com/). Can you expand on your experiences with it?

Re: MongoDB queries don’t always return all matching documents

#104
A lot of Mongo DB bashing on HA. We use it and I love it. Of course we have a dataset suited perfectly for Mongo - large documents with little relational data. We paid $0 and quickly and easily configured a 3 node HA cluster that is easy to maintain and performs great.

Remember, not all software needs to scale to millions of users so something affordable and easy to install, use, and maintain makes a lot of sense. Long story short, use the best tool for the job.

Re: MongoDB queries don’t always return all matching documents

#105
post #95

Earlier quoted context omitted.

> Why on earth would you use a database that makes so little in the way of guarantees about what results you get from it? Because some people can't stand having to work with SQL,migrations,schema and constraints, it's as simple as that ( That's not my opinion,that's just the rational behind MongoDB). Even if you use Postgres with the Json column type, you still need to write SQL queries and schemas. In the context of…

It’s useful for prototyping. When you don’t know which schema you’ll end up using having an *SQL database is tedious because you have to do migrations every time you change the schema. Once you’re done prototyping you can switch to a better alternative.

Exactly. Use the right tool for the right job. Start prototyping and development with MongoDB and then migrate to Postgres, or Cassandra or whatever suits your user-case better.

Re: MongoDB queries don’t always return all matching documents

#106

Said it before, will say it again... "MongoDB is the core piece of architectural rot in every single teetering and broken data platform I've worked with." The fundamental problem is that MongoDB provides almost no stable semantics to build something deterministic and reliable on top of it. That said. It is really, really easy to use.

All I ever hear is terrible things about it. I'm not a "gotta hear both sides" kind of person so that means something to me.

Re: MongoDB queries don’t always return all matching documents

#110
post #90

Earlier quoted context omitted.

If you want that you can always use a variant of postgres that does like greenplum, citus, and a few others. They're battle proven. There's also MySQL and its variants as well. Not to mention that are NoSQL alternatives that have a better track record than Mongo like Cassandra.

Are there NoSQL alternatives that have a worse track record than Mongo?

Cassandra, HBase etc had checkered pasts with plenty of their own data loss and inconsistency bugs.

Now they are considered two of the most rock solid NoSQL databases. The hatred towards MongoDB really is pretty irrational given just how popular the database is.

Post reply on HN