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

151–160 of 419 posts

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

#151

Post by lloyd-christmas »

nostrademons wrote: post #88
baudehlo wrote: post #60

Earlier quoted context omitted.

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?

I've actually observed the opposite, that the more experienced you get, the more rewriting occurs and the less you tend to plan things out ahead of time, until you're Google/Facebook level and just accept that you will be rewriting constantly.

I'm not necessarily sure that you actually rewrite more, but that you're more willing to accept the current status and plan on some rewrites.

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

#152

Post by btown »

badminton1 wrote: post #150
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…

Using a document oriented data store as a log aggregator? Please lord, take him in his sleep.

It does work for a certain volume of data. You can index fields you're interested in, even do so after the fact, and it's like any other database in that case. And sometimes you have small apps that do need complete historical log data, so Kafka et al just introduce unnecessary complexity since you'd need to aggregate into a key value store anyways.

But if you do this, god forbid you go beyond where indices can fit in RAM of a single machine. And you will do so, with probability one given your product doesn't shut down. So you're running a gauntlet against a redesign.

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

#153

Post by blitzkriegpunk »

toomuchtodo wrote: post #86
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…

Who knew you'd need to learn how to use tools to use them!

Get. Out. Of. Town.

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

#155

Post by JustSomeNobody »

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.

I remember during peak mongo that if you weren't working on a project that used mongo, other devs looked down their noses at you.

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

#156

Post by StavrosK »

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?

The single biggest source of grief in our production database has been the one JSON field we used once to avoid adding another table. That goddamn thing has crashed the server so many times with invalid data, that I'm never using anything schemaless again. We recently migrated to a proper table and I'm thanking my lucky stars I finally got rid of that devil.

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

#158

Post by Pxtl »

themartorana wrote: post #134
catnaroek wrote: post #127

Earlier quoted context omitted.

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

Prototyping on Mongo is bad. MySQL takes 10 seconds to install. I'm imagining with the public Docker registry, so does Postgres. How many times have you promised to fix something later and then later comes and... Prototyping is not an excuse for laziness. It does feel like some programmers don't care.

You can insult the developers that use Mongo or you can look at how to get those users onto a better platform. With the modern expectations of full-stack development, is it any wonder that something promising simplicity and zero-configuration data storage does well?

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

#159

Post by smadge »

lloyd-christmas wrote: post #120
danneu wrote: post #56

Earlier quoted context omitted.

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.

> Denormalizing on day 1 This has nothing to do with database choice. This is just shitty development. It's a strawman at best.

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.

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

#160

Post by xapata »

red_hare wrote: post #149
Lazare wrote: post #124

Earlier quoted context omitted.

> 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. My company used mongo for years before we got our shit together. Schmemas were always implicit (until we got our shit together and started defining and enforcing them with Python Schematics). Migrations were crazy scripts you run in prod or hacks you stick into your code to "transition". And yes, surprise constrains left and right causing awful anti-patterns. One-character key names to save disk. Hashed values…

> used mongo for years before we got our shit together.

That's actually a legit use case. Use MongoDB while you get your shit together. I use global variables while I'm noodling around in code. Eventually I refactor.

Post reply on HN