I wonder how much data they are storing and in what pattern that they actually need a NoSQL database. I'm curious why someone would make that choice.
MongoDB queries don’t always return all matching documents
181–190 of 419 posts
Re: MongoDB queries don’t always return all matching documents
#182Earlier quoted context omitted.
> 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.
> 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",
}
person = {
_id: "person123",
username: "lloyd-christmas"
}
comment = {
_id: "comment456",
person: {
_id: "person123",
username: "lloyd-christmas"
},
text: "This is also valid"
};
Obviously this is just an MCVE. My original point was that I find this to be a drastically more flexible process than starting off relational.
Re: MongoDB queries don’t always return all matching documents
#183Earlier quoted context omitted.
Is having seen something used some way a leading indicator of it being a good idea to have used that thing that way? Because I've seen Excel used as database with all kinds of macros and VBA scripts bolted-on/embedded to provide the workbook various shapes of stored-procedure and query capability... but, while sorta impressive in a "Holy crap, lol wut?" kind of way, I'm not sure any instance I observed of uses like t…
Did they make the company a lot more money than they cost? If so they were probably a good idea. Not all code needs to be "pretty" to serve a purpose. I've seen some pretty epic hacks that I know generated hundreds of thousands of dollars of new revenue.
They often had a significant "bus factor" problem as a result of this in the best cases, and in the worst cases these mountains of hacks were a massive impediment to growth and/or evolution to meet changing marketplace demands... despite being a central pillar of data management and revenue as it existed in the status quo.
Re: MongoDB queries don’t always return all matching documents
#184Everytime 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…
I've been in the opposite situation and I couldn't disagree more. But I will say this, it's always possible to take an RDBMS model and de-normalize it and use it like a NoSQL database (like reddit does, for example) but it's not possible to go the other way.
Re: MongoDB queries don’t always return all matching documents
#185Earlier 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…
MongoDB: Because /dev/null doesn't support sharding.
nc -vv -l 27017 > /dev/null
That and some round robin dns entries should be good enough for prod use, yeah?
('course it's not webscale ready till it's deploayble as a docker container which contains critical nodejs code with a dependancy on leftpad.js...)
Re: MongoDB queries don’t always return all matching documents
#186Earlier 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…
> 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".
I think if you re-read it, you might see that at no point did the post that you're replying to imply that Postgres was preferred because it had a longer list of features. They're speaking entirely about the strong guarantees that an ACID system gets you.
Document stores are only mentioned because this is one of the (incorrectly) perceived advantages that Mongo has over Postgres and other databases.
Re: MongoDB queries don’t always return all matching documents
#187Earlier 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…
"just last month I found MySQL, heck even SQLite supports triggers with code inlined into the trigger body but PostgreSQL mandates writing a separate function for the trigger"
The right response, as a postgres developer, is to agree that you describe a useful feature, and perhaps implement it to help other users.
But my advice to you is to be willing to put up with some short-term annoyances. Sometimes the best choices are a little annoying, and if you refuse to consider them, it will cost you (or your employer) much more later.
Re: MongoDB queries don’t always return all matching documents
#188Earlier quoted context omitted.
I haven't looked at Apollo, but GP should've explained that GraphQL is not a database and can be hooked up to any backend, so with it I'm guessing you can use any kind of database in Apollo/Meteor apps. Still, kind of weird. Another reason why I never bothered with Meteor.
I remember when Meteor was the JavaScript flavour-of-the-month and everyone was saying it will kill Rails. I wanted to believe so I looked into Meteor, then I saw its dependence on MongoDB... Nope!
If you study the backend JavaScript ecosystem you'll see no Rails-like all-in-one framework has ever succeeded. They're just not part of the culture. The only Rails-like thing in the JS ecosystem that's popular and great is Ember but that's only frontend.
Re: MongoDB queries don’t always return all matching documents
#189Earlier quoted context omitted.
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 i…
[deleted]
Re: MongoDB queries don’t always return all matching documents
#190Earlier quoted context omitted.
MongoDB: Because /dev/null doesn't support sharding.
nc -vv -l 27017 > /dev/null That and some round robin dns entries should be good enough for prod use, yeah? ('course it's not webscale ready till it's deploayble as a docker container which contains critical nodejs code with a dependancy on leftpad.js...)
These days all the cool kids use LPaaS on http://left-pad.io/, it scales much better than running leftpad on a local machine.