Live data from Hacker News

MongoDB queries don’t always return all matching documents

engineering.meteor.com

51–60 of 419 posts

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

#51
Strongly biased comment here, but hope its useful.

Have you tried ToroDB (https://github.com/torodb/torodb)? It still has a lot of room for improvement, but it basically gives you what MongoDB does (even the same API at the wire level) while transforming data into a relational form. Completely automatically, no need to design the schema. It uses Postgres, but it is far better than JSONB alone, as it maps data to relational tables and offers a MongoDB-compatible API.

Needless to say, queries and cursors run under REPEATABLE READ isolation mode, which means that the problem stated by OP will never happen here. Problem solved.

Please give it a try and contribute to its development, even just with providing feedback.

P.S. ToroDB developer here :)

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

#52
post #28

Does Meteor support a proper database system yet, a la. MySQL or Postgres?

Yes - with Apollo/GraphQL (currently available as a technical preview): http://docs.apollostack.com/apollo-client/meteor.html I recommend you check out the Apollo Meteor Starter Kit: https://github.com/apollostack/meteor-starter-kit

Noticed how I referenced 2 proper RDBMS in my question? Then how you proceeded to introduce another flavour-of-the-month

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

#53
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 have any clustering / HA features. So out of the box it doesn't scale well.

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

#54

Earlier quoted context omitted.

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 can confirm. On HN, meetups, Twitter, etc. no one talks about MEAN stack any more because of Mongo and the Angular 1/2 split (and React's popularity). In the last hackathon I went to, like most "corporate sponsored" ones, you got a special prize for using it.

thanks for spelling that out for me

great incentive to dive into React further and ditch Mongo

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

#55
post #11
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.

Their website is quite hype prone: >The Standard for Modern Applications >MongoDB 3.0 features performance and scalability enhancements that place MongoDB at the forefront of the database market as the standard DBMS for modern applications. >Also included in the release is our new and highly flexible storage architecture, which dramatically expands the set of mission-critical applications that you can run on MongoDB.…

The people who wrote that are not the same people who write the database.

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

#56

Earlier quoted context omitted.

If you have a lot of relations in your data don't use mongo Why would you use Mongo if you have lots of relational data? Why would you not start with a relational database for that? I know Mongo has issues but it's never going to beat an RDBMS on relational queries.

We start our apps with mongo, and design them with a migration plan to postgres. We've found it's very easy to rapidly develop the application with mongo due to it's flexibility. Once we understand where or app is headed and what our relationships actually are, we pretty much pull the plug out of mongo and stick it in postgres. If you build a reasonably intelligent query wrapper it's fairly effortless. That being sai…

Meanwhile, normalized data is what gives me so much flexibility when using Postgres at the start of an app. I just store my data as generically as possible and usually all I need to change under churn is the queries.

Denormalizing on day 1 (Mongo) has you making guesses about your data access patterns at the worst possible time instead of just thinking about the data itself.

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

#57
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…

I was always a big fan of calling MongoDB the "Snapchat for databases". I think people even had some stickers printed for it..

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

#58
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…

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

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

#59
This use-case is not something that you would use MongoDB for. Try Zookeeper.

This being said, I would feel embarrassed to post this on behalf of the engineering department of a company.

This post is just a very illustrated way of saying "we have no idea about what we are doing and our services are completely unreliable".

This is so bad that is more of an HR problem than it is an engineering problem.

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

#60

Earlier quoted context omitted.

If you have a lot of relations in your data don't use mongo Why would you use Mongo if you have lots of relational data? Why would you not start with a relational database for that? I know Mongo has issues but it's never going to beat an RDBMS on relational queries.

We start our apps with mongo, and design them with a migration plan to postgres. We've found it's very easy to rapidly develop the application with mongo due to it's flexibility. Once we understand where or app is headed and what our relationships actually are, we pretty much pull the plug out of mongo and stick it in postgres. If you build a reasonably intelligent query wrapper it's fairly effortless. That being sai…

This feels like you lack an architect who can see the bigger picture of your applications. I don't mean that insultingly, but with experience you tend not to need that second system syndrome. Do you find there's less rewriting over time as you become more experienced? Or is it just the kind of projects you work on?
Post reply on HN