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.
Like with any online community, Hacker News can be kind of an echo chamber where groupthink reigns and alternative points of view aren't encouraged. MongoDB hype has died down here, but there are still some people that are fans. There are some things MongoDB does fairly well: * MongoDB is really easy to use * Document databases can be great and flexible solutions for some kinds of projects * Documentation is fairly g…
MongoDB queries don’t always return all matching documents
81–90 of 419 posts
Re: MongoDB queries don’t always return all matching documents
#82Seriously, who looks at MongoDB and thinks "this is a sane way of doing things"? To be fair, I've never been much of a fan of the whole NoSQL solution, so I may be biased, but what real benefits do you gain from using NoSQL over anything else?
Re: MongoDB queries don’t always return all matching documents
#83Earlier 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…
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
#84Earlier 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.…
Hang out on the freenode room for mongo and you will see that most people, working on production software, make inquiries that reflect a complete lack of knowledge, common sense and leave you facepalming with no hope in humanity at a large.
Re: MongoDB queries don’t always return all matching documents
#85When you're developing MVPs, work with ever changing designs and features, ability to cut off this whole migration part comes around really handy. I would however recommend to anybody to keep migration plan for the moment the product stabilizes. If you don't, you end up in the world of pain.
Re: MongoDB queries don’t always return all matching documents
#86Earlier 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…
> 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…
Re: MongoDB queries don’t always return all matching documents
#87This 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.
Zookeeper is fine for things like service discovery that deal with a bounded amount of data. You don't want to use it for something where the amount of data depends on, say, how many containers your customers decide to start. Every ZK server keeps all of its data on the Java heap, so if your data gets too big, pow. How big is too big? Don't worry, you'll find out the hard way sooner or later!
Plus, there's no sharding -- every write operation has to be acknowledged by a majority of nodes in your cluster. So for write-heavy workloads (which is what I would expect a service status dashboard to experience) your cluster actually gets slower if you try to add more machines.
Re: MongoDB queries don’t always return all matching documents
#88Earlier quoted context omitted.
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?
Re: MongoDB queries don’t always return all matching documents
#89Earlier 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.
Like with any online community, Hacker News can be kind of an echo chamber where groupthink reigns and alternative points of view aren't encouraged. MongoDB hype has died down here, but there are still some people that are fans. There are some things MongoDB does fairly well: * MongoDB is really easy to use * Document databases can be great and flexible solutions for some kinds of projects * Documentation is fairly g…
* Mongo is only easy to learn. Beyond simple demos, it gets harder and harder to use as projects evolve i.e. you have to do a lot of work yourself imo this is a common problem with nosql datastores that isn't exclusive to Mongo
* "Document databases can be great and flexible solutions for some kinds of projects": Postgresql has been able to work directly with JSON for some time now. There are also other document datastores that are more reliable than Mongo
* Scaling with Mongo is difficult, specifically the crazy setup. Even if you set it up properly, the results don't tend to match the marketing https://aphyr.com/posts/322-jepsen-mongodb-stale-reads
* "arguably quicker to get a project off of the ground with than traditions RDBMs" unless you're using Meteor, I'm also going to disagree here. Most frameworks target a relational database by default. Developing by convention tends to get you off the ground much faster than using something more specialized and niche
Re: MongoDB queries don’t always return all matching documents
#90Earlier quoted context omitted.
Because Postgres doesn't have any clustering / HA features. So out of the box it doesn't scale well.
If you want that you can always use a variant of postgres that does like greenplum, citus, and a few others. They're battle proven. There's also MySQL and its variants as well. Not to mention that are NoSQL alternatives that have a better track record than Mongo like Cassandra.