Live data from Hacker News

MongoDB queries don’t always return all matching documents

engineering.meteor.com

251–260 of 419 posts

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

#251
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.

I have never managed to build a prototype that didn't end up being used in a production setting.

I am trying to remember if I ever built a prototype that got rewritten. Probably not.

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

#252

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…

in this case, please use Postgresql jsonb data tables. Just as powerful as mongo... but with the stability and guarantees of postgres

It has been pointed out before that json(b) has problems with indexing. IIRC the cost estimates of indexes on JSON data are static, and therefore very rarely accurate. I'm terribly sorry but couldn't find a reference with 5min of searching. I still like postgres over mongo

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

#253

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…

So my question is then: Why not use CouchDB instead? I don't see what Mongo gives you over that and CouchDB is at least dependable and predictable in its operation.

Is CouchDB still alive? I spent a weekend playing with it in January, but it seemed to be a very quiet project, with the last stable release being almost two years ago.

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

#254
post #222
post #101

Earlier quoted context omitted.

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.

What they neglect to mention is not that you don't need a DBA, that you are the DBA yourself. With all the responsibilities that go along with that role. Who's getting paged at 3am now...?

If thats really a problem host your database on a cloud platform and let those guys do the job of a DBA. Works for me at present. I am aware its not going to be a solution for everyone, though it still sounds a lot better than being your own Mongo DBA.

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

#255

Earlier quoted context omitted.

> Because some people can't stand having to work with SQL,migrations,schema and constraints The real question is “How come these people are allowed anywhere near data stores?” SQL isn't ideal, but how many of the alternatives are better at protecting the integrity of your data?

Thank you. Not everything is easy. This is the difference between engineering and 'hacking'. Hacking is not something to aspire to; it's something you do because of crushing, external pressures.

Hacking is trying to get the SQL representation into something programmers use via the way of an ORM. At the end of the day, a SQL database doesn't represent the data in a way the programmer uses the data. It has to be transformed and that is a bigger hack than loosening some constraints.

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

#256
post #254
post #222

Earlier quoted context omitted.

What they neglect to mention is not that you don't need a DBA, that you are the DBA yourself. With all the responsibilities that go along with that role. Who's getting paged at 3am now...?

If thats really a problem host your database on a cloud platform and let those guys do the job of a DBA. Works for me at present. I am aware its not going to be a solution for everyone, though it still sounds a lot better than being your own Mongo DBA.

The DBA is the role who is reponsible for the organizations data. Even if you outsource the routine tasks such as "doing backups" you still need someone to assume that role.

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

#257
post #215

Earlier quoted context omitted.

I have been a DBA for 20 years, Oracle, SQL Server, Sybase, Informix, Postgres, MySQL/MariaDB... About the only big name I haven't had serious experience with is DB2. We did hot-releases into Prod routinely. I have absolutely no idea what a "SQL migration" is or why it would be so hard. I assume it's just a bogeyman made up by the MongoDB snake-oil salesmen. It is certainly not something "traditional" database people…

> I have absolutely no idea what a "SQL migration" Transforming data to conform to a new schema. It's a tedious process that could use some automation, but ditching schemas because data migrations are tedious is like ignoring traffic rules because you're in a hurry. > I assume it's just a bogeyman made up by the MongoDB snake-oil salesmen. It's just like dynamic type marketing: “If you never define the structure of y…

Oh, that doesn't happen much, because serious organizations have dozens of apps connected to a DB and no-one would be crazy enough to big-bang change them all at once to use a different schema. Adding columns and tables tho' is easy, populating new tables from existing, replacing tables with views, no problem.

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

#258
post #41

Earlier quoted context omitted.

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…

What do you think about noSQL in general. From what I could follow from aphyr rethinkdb seems pretty awesome. I like it a lot, but I am also not getting a ton of traffic on localhost:3000...

> What do you think about noSQL in general.

That is an unanswerable question since it's about everything. "NoSQL" is a huge variety of techniques - many of them yet to be invented, that only have one thing in common: "not SQL". From document storage over key/value storage to graph databases. Anyone who tells you what they think "about NoSQL" either has to redirect the question to become a useful one, or if they actually attempt to answer it take your popcorn and expect entertainment at best.

"Types and examples of NoSQL databases" - https://en.wikipedia.org/wiki/NoSQL#Types_and_examples_of_No...

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

#259

Earlier quoted context omitted.

I worked at a Data Analytics start up in Palo Alto back in 2011 and we had 8 or 9 databases in our arsenal for storing different types of data. MongoDB was by far the worst and most unstable database we had. It was so bad that for the presidential debate, I had to stay up and flip servers all night because even though the shards were perfectly distributed, the database would crash and fail over to two other machines…

I had a similar experience in 2011 with Mango where we were running map reduce jobs which Mongo advertised to support. The whole system got blocked from running the map reduce and the Tengen consultant sighed when we told him we were running map reduce jobs.

Which isn't the best argument to make against MongoDB since you should have known - it's even part of their course curriculum - that map/reduce is not the optimal way to aggregate in MongoDB. They have their own aggregation framework (https://docs.mongodb.com/manual/core/aggregation-pipeline/).

I have no intention of defending MongoDB because what do I know, never worked with it in real life - but just out of curiosity I took the free courses they offer (https://university.mongodb.com/) and I find that a sizable share of the complaints about MongoDB come from people who don't seem to have learned much about the product they are using. It's like people complaining their new truck behaves badly in water.

A lot of critics seem to have chosen MongoDB when they needed a SQL DB from day one. If you need full flexibility to (re)combine data you need SQL, for example. A document store isn't "schema-less" at all - much of the schema is built-in and very inflexible after that.

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

#260

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.

I (used to) hear lots of good stuff, but the type of devs were always hype driven. Asking for a reason why Mongo was used, the reply sounded just like the marketing hype on Mongo's homepage - lots of buzzwords and catchphrases ("big data", "schemaless") with no substance to the reason for choosing it.
Post reply on HN