MongoDB queries don’t always return all matching documents • Hacker News Board

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

#211

Post by chucky_z » Wed, Jun 08, 2016, 5:05 AM UTC

chx wrote: post #174

eloff wrote: 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…

This will be highly subjective but you need to get over the "postgresql has the longest feature list so why don't you use it". The last startup I have been involved with tried to use PostgreSQL and needed to move to MySQL (yeah, well) because commercial support was both more expensive and less useful than what we were able to get for MySQL. Perhaps today it's different. While I no longer use PostgreSQL much, every ti…

My response to the comment for triggers and PGSQL would be: Postgres tries its best to stop you shooting yourself in the foot.

Similar to the top comment, all the real problems I've ever encountered with postgres (heck, all major RDBMS's for that matter) come from certain areas, mainly triggers.

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

#212

Post by skeoh » Wed, Jun 08, 2016, 5:06 AM UTC

mikekchar wrote: post #172

skeoh wrote: post #103

Earlier quoted context omitted.

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

I'm not the original poster, but I can give you some of my limited experience with CouchDB from an application I inherited. The original idea for the project still seems like a good idea to me. Basically they wanted to record events that came into the system and store them in a write only ledger. Then they wanted to version every change so that you have an audit trail. Finally they wanted to be able to create views o…

Thanks for the detailed response. I'll keep this all in mind next time I need to choose a DB for even a small project.

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

#213

Post by ahi » Wed, Jun 08, 2016, 5:09 AM UTC

lath wrote: post #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. Lo…

This has also been my experience. Millions of large documents on a single (beefy) node with a single user it's been fine. Although, the sysadmins had previously left me with flat file xml on shared storage so the bar was pretty low.

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

#214

Post by nevi-me » Wed, Jun 08, 2016, 5:13 AM UTC

catnaroek wrote: post #127

Pxtl wrote: 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.

> Mongo is a dumb, dead-end platform, but they know how important ease-of-use is. By “ease of use”, do you mean “ease of making something that seems to work” or “ease of making something that actually works”? I've never used a schema-free database, and ended up thinking to myself “I'm completely sure this database can't possibly contain garbage data”. Or do programmers simply not care about data integrity anymore?

Well, I have used one and had that assertion. Ease of use means making something that works. It seems we're condoning lack of knowledge or experience with programming. If you've never used databases in your life, whether you're using SQL orNoSQL you'll likely end up with rubbish data. In the SQL world it could be that you're storing time in the wrong format, concatenating long fields, or not normalising when you should or the other way around.

In NoSQL you could be reinventing the wheel, or storing data that you can't query efficiently because you can't index it well etc.

All the excuses of not using some document stores beyond ACID really sound like people won't know what the heck they're doing.

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

#215

Post by gaius » Wed, Jun 08, 2016, 5:16 AM UTC

1879325235 wrote: post #204

> 1) Have migrations (except they're going to be some scary ad hoc nodejs script that loop through your document store and modify fields on the fly). Unless you have never written migrations in SQL before you would know that they are even scary and a big bunch of sql. What is even worse is that, despite nobody here acknowledging it, must SQL databases are used with an ORM. Now in your migration script you have to hac…

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 actually do, or worry about.

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

#216

Post by EpicEng » Wed, Jun 08, 2016, 5:20 AM UTC

catnaroek wrote: post #128

spriggan3 wrote: post #76

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…

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

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

#217

Post by SmirkingRevenge » Wed, Jun 08, 2016, 5:23 AM UTC

eloff wrote: post #41

im_down_w_otp wrote: post #16

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…

Or if you want a rock solid json document-based db with an awesomely killer api - use RethinkDb.

Its a phenomenal product.

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

#218

Post by nevi-me » Wed, Jun 08, 2016, 5:29 AM UTC

5350-uiop-1130 wrote: post #137

Is MongoDB really that bad? I am someone just getting into Meteor Js and it seems like moving from MongoDB would make it Meteor trickier to learn. Is it difficult to switch to an alternative? Thanks

It's not, go ahead and use it, learn and gain experience. It's not a replacement for SQL databases. It doesn't have joins and the biggest issue academics and as sysadmins have is it's not fully ACID compliant, so no transactions for example.

If I was writing this 2 years ago, I would say horizontal scaling is much easier. Add a node to your replica, watch it catch up, and continue.

Have data stored in an array 4 levels deep? Mongo will find it for you. It's only difficult to switch to an alternative to the extent that you've convolved your schema in an unfriendly way. Most migration entails normalising your data into different SQL table and exporting it. Not rocket science as people make it seem to be.

I use SQL at work, Oracle, SAS excuse, a bit of MySQL and sometimes Postgres - I'm a consultant. I have tried some NoSQL DBs but always come back to Mongo, for personal projects.

I've done a few prototypes for clients using Mongo, but those are almost always for geospatial support.

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

#219

Post by SmirkingRevenge » Wed, Jun 08, 2016, 5:30 AM UTC

m_mueller wrote: post #118

spriggan3 wrote: post #76

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.

I really like Couch, I wish it had more adoption than it seems to have and that its ecosystem was more mature than it seems to be... and that javascript wasn't its first class citizen.

But its a really cool database (though I'm partial to rethinkdb now)

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

#220

Post by nulagrithom » Wed, Jun 08, 2016, 5:38 AM UTC

Lazare wrote: post #124

spriggan3 wrote: post #76

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…

> Because some people can't stand having to work with SQL,migrations,schema and constraints The thing is, if you actually try and write an app using MongoDB, you will rapidly find that you: 1) Have migrations (except they're going to be some scary ad hoc nodejs script that loop through your document store and modify fields on the fly). 2) Have schemas (except they'll be implicit and undocumented) 3) Constraints (exce…

This list makes me want to cry a little. It rings too true.

> Have migrations (except they're going to be some scary ad hoc nodejs script that loop through your document store and modify fields on the fly).

I literally just spent the better part of tonight AND yesterday evening dealing with one of these scripts. I had pulled down the production table to locally test the script (gross), but when I later ran it in the production environment, we'd somehow had an array sneak in to what was an object field. The whole thing just felt like a mess.