Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB queries don’t always return all matching documents

engineering.meteor.com

Post reply on HN
Print view View original

361–370 of 419 posts

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

#361

Post by matwood »

Thaxll wrote: post #53
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…

Because Postgres doesn't have any clustering / HA features. So out of the box it doesn't scale well.

Scale to what though? RDBMs can easily handle large loads, have replication, etc... At the point where you need true scaling, you'll have a much better idea of your problem and can solve it appropriately.

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

#362

Post by gerbilly »

1879325237 wrote: post #250
Lazare wrote: post #223

Earlier quoted context omitted.

> Unless you have never written migrations in SQL before you would know that they are even scary and a big bunch of sql I've written a ton of SQL migrations this year, none of them are scary or even really count as "big bunch of sql". If this describes your code, you should probably stop and rethink what you're doing, because that's bad practice. The difference between, eg, merging your "first_name" and "last_name" f…

> I've written a ton of SQL migrations this year, none of them are scary or even really count as "big bunch of sql". If this describes your code, you should probably stop and rethink what you're doing, because that's bad practice. The difference between, eg, merging your "first_name" and "last_name" fields into a single "name" field with Mongo or a SQL DB is basically that the SQL DB has better tooling so it'll be cl…

>written in a shitty language (SQL)

SQL is old but it isn't shitty.

Reasons:

1) It is based on a solid mathematical theory[1].

2) It is declarative. Replacing SQL with a procedural language would be a spaghetti code disaster.

[1] https://en.wikipedia.org/wiki/Relational_calculus

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

#363

Post by snaky »

jeltz wrote: post #350
snaky wrote: post #341

Earlier quoted context omitted.

There's no need of serializable level of isolation in common case. It depends on particular data model, particular access pattern, particular database implementation (MVCC or blocking, and how exactly transaction isolation levels are implemented - e.g. Oracle's "serializable" is closer to PostgreSQL's "repeatable read"). Anyway, any sufficient modern RDBMS implementation provides pretty good level of performance even…

Not in the common case, but it is necessary in the general case. One of the main motivations I have heard from the few people actually using serializable in their systems is the ability to enforce arbitrary constraints under parallelism. And, yes, performance should in general still be good, but there is less knowledge out there about how to solve the performance issues specific to serializable since there are few pe…

Well, not so many people use serializable in their systems (in the whole system, for every transaction) and that is common and reasonable approach. They use the minimal isolation level for particular transaction that keeps their data consistent. Most widely used safe default is repeatable read, in PostgreSQL terms.

Broadly speaking, of course there are some quirks in the field, let's start from "A critique of ANSI SQL isolation levels"[1] by Jim Gray et al., an author of highly respected fundamental book about transactions [2]. But the very kind of problems discussed in RDBMS world, is a rather contrasting with an "ACID? why do we need it?" attitude that is so often in the world of "web scale NoSQL".

[1] http://dl.acm.org/citation.cfm?id=223785

[2] https://www.amazon.com/Transaction-Processing-Concepts-Techn...?

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

#364

Post by collyw »

1879325237 wrote: post #250
Lazare wrote: post #223

Earlier quoted context omitted.

> Unless you have never written migrations in SQL before you would know that they are even scary and a big bunch of sql I've written a ton of SQL migrations this year, none of them are scary or even really count as "big bunch of sql". If this describes your code, you should probably stop and rethink what you're doing, because that's bad practice. The difference between, eg, merging your "first_name" and "last_name" f…

> I've written a ton of SQL migrations this year, none of them are scary or even really count as "big bunch of sql". If this describes your code, you should probably stop and rethink what you're doing, because that's bad practice. The difference between, eg, merging your "first_name" and "last_name" fields into a single "name" field with Mongo or a SQL DB is basically that the SQL DB has better tooling so it'll be cl…

"No the difference is one has to be written in a shitty language (SQL), whereas the other can be written in an actual programming language."

Aren't mongo queries written in a subset of JavaScript?

SQL syntax is a bit crappy, but it is still one of the easiest languages to comprehend what is going on when reading code written by someone else.

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

#365

Post by pizzasynthesis »

lucasmullens wrote: post #12
Joeboy wrote: post #9

Earlier quoted context omitted.

> don't use mongo, it's just hype I'm kind of curious as to where this hype is. I've almost never heard anybody say anything positive about mongodb. All I ever see is people saying it's terrible / hilarious for various reasons.

The HN crowd tends to insult it, but outside of HN people hype it up. People keep talking about how much they love the MEAN stack. It's huge in the hackathon crowd, due to them sponsoring many of them, and its low learning curve. I wish people would stop using acronyms and realize Express/Angular/Node is just as good with something other than Mongo.

I like the Postgres/Express/Ember/Node stack, if not just for the acronym.

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

#366

Post by danneu »

lloyd-christmas wrote: post #182
smadge wrote: post #159

Earlier quoted context omitted.

Can you explain what you mean? As far as I know, normalizing is a nonsensical process for a document store. You can only normalize a relational schema.

> You can only normalize a relational schema. Normalization is just a method of organization to minimize repetition of data. It has nothing to do with efficiency of operation. This is perfectly valid code: person = { _id: "person123", username: "lloyd-christmas" } comment = { _id: "comment123", person: "person123", text: "This is how I start", } You don't have to do: person = { _id: "person123", username: "lloyd-chri…

You can normalize data in Mongo and replicate relational database features in your application layer.

I'm just curious how that's an upside to using a relational database from the beginning when your plan is to migrate to a relational database anyways.

Switch out "Mongo" for "Postgres" in your bulk paragraph and you have the same scenario but with less work on your part and more features to help establish your data model.

One upside I can see if it you're more familiar with Mongo where using a relational database slows you down.

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

#367

Post by bsg75 »

rgo wrote: post #126

Everytime I hear arguments for going back to relational databases, I remember all the scalability problems I lived through for 15 years in relational hell before switching to Mongo. The thing about relational databases is that they do everything for you. You just lay the schema out (with ancient E-R tools maybe) load your relational data, write the queries, indexes, that's it. The problem was scalability, or any toug…

> do data consistency in your code, moving data logic into solid models that are tested and versioned from day one

So your consistency check code is more reliable that that which has been built and tested over many years, people and projects?

And your code is guaranteed to be deployed into any project that need to access that database later?

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

#368

Post by im_down_w_otp »

jeltz wrote: post #350
snaky wrote: post #341

Earlier quoted context omitted.

There's no need of serializable level of isolation in common case. It depends on particular data model, particular access pattern, particular database implementation (MVCC or blocking, and how exactly transaction isolation levels are implemented - e.g. Oracle's "serializable" is closer to PostgreSQL's "repeatable read"). Anyway, any sufficient modern RDBMS implementation provides pretty good level of performance even…

Not in the common case, but it is necessary in the general case. One of the main motivations I have heard from the few people actually using serializable in their systems is the ability to enforce arbitrary constraints under parallelism. And, yes, performance should in general still be good, but there is less knowledge out there about how to solve the performance issues specific to serializable since there are few pe…

> "using serializable in their systems is the ability to enforce arbitrary constraints under parallelism"

That's a funny way to say that. :-) Because what it really means is, "wanting to enforce a total lack of parallelism when under parallelism." I mean I get what you're saying, it was just funny to read.

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

#369

Post by 1879325272 »

orf wrote: post #324
1879325238 wrote: post #292

Earlier quoted context omitted.

Mongodb isn't always accessed through an ORM. I have no idea what you are talking about. > Enforcing arbitrary constraints belongs in the business logic of your app Oh so you have some constraints enforced in your database, like the length of a strength can't be greater than 5, yet others you consider arbitrary just because they are not in SQLs list of constraints? How on earth did you define arbitrary otherwise? Any…

You're replies in the comments are rude and borderline fanatical in tone. There are two classes of constraints: one being 'this string shouldn't be longer/shorter than x' or 'this value should only be between 1 and 10'. The other kind is 'on the first Tuesday of every month only during a full moon can this record be deleted, and only by a user with permission X'. The first can easily be modelled in SQL, the second sh…

This is just a semantics argument which is boring. A number between 1 and 10 on Tuesday is only slightly different. You can say it is not arbitrary, whatever.

You have just proved my point. Just in case you forgot the original claim, it was that if you use a SQL database, the constraints are in your database, but if you use mongo, the constraints are in your code.

I refuted this by saying that the constraints are also in the code in a SQL database. You have proven the point even further by highlighting that they are even more complex than the constraints in the database.

Therefore, saying that it is a great win that a SQL database can do some basic constraints checking is a ridiculous argument because it hardly contributes any benefit due to the fact that even more complex constraints are in the code.

So you have not actually contributed anything and I never said you should throw out SQL just because it can't model every constraint. Nice strawman. You lose the argument though right?

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

#370

Post by NateDad »

gaius wrote: post #299
joncrocks wrote: post #279

Earlier quoted context omitted.

I'd argue the inverse. Serious organisations shouldn't have lots of different apps reading from each other's databases, for the reason you suggest above. It makes changes difficult and the application landscape fragile. It also encourages not having well-documented interdependencies between your apps (and consequently no way of knowing what the impact of any given change to an app will have). It's not uncommon howeve…

They are not "each others" databases tho'. It is "the database", deliberately chosen as the integration point. The alternative is a horrific tangle of replication, or a vast undiscoverable landscape of tiny APIs.

That sounds horrible. No wonder you've never done a migration - it's been made impossible. Why would you not hide the database behind an API, so that you CAN migrate it, change it, etc? This is like not having a separate data layer in your application, except it's across many applications all at once.
Post reply on HN