Live data from Hacker News

Guide to MongoDB for startups

optinidus.com

41–50 of 66 posts

Re: Guide to MongoDB for startups

#41
post #7

I find it somewhat depressing that the first comments on any post about MongoDB generally seem to be short, disparaging and dismissive without offering much if any substance. We use MongoDB in production, processing millions of new records every month and it works great. Our data has differing and evolving schemas and can be used as JavaScript objects or python dictionaries with little effort. It works and performs w…

I find it somewhat depressing that the first comments on any post about MongoDB generally seem to be short, disparaging and dismissive without offering much if any substance

There's just not much to say tho'. If this were an aviation site and people kept posting about how piston engines were the future because jets "don't scale to large aircraft" and "were never designed for long journeys" how would you argue against that? There would just be no point.

I'll say this tho': in 1969 IBM released a NoSQL product called IMS, which was designed to handle the BOM for the Saturn project. IMS has been continuously developed since then. Have a look at it and what it can do, then look again at MongoDB, which is - genuinely - about 40 years behind the state-of-the-art. Then understand why experienced database guys* can't be bothered to debunk it any more.

* my own stats: 50+Tb in Oracle with 800G changes/day, replicated to 2 other identical databases over WAN links. 2+Tb in MySQL. 10,000 commits/sec + 50,000 reads/sec on Oracle. 99.99% uptime on all of this. When people tell me "SQL databases" don't scale or aren't reliable, I laugh. And then ignore them.

Re: Guide to MongoDB for startups

#42
post #37

With the increasing data the search engines, e-commerce stores need to provide us with accurate results. Which means processing huge amount of data. Which SQL databases were never designed for. What? There is no limit how much data you can stuff into a relational database and it mostly works really good. There are definitely some scenarios where relational databases are not optimal, for example aggregating huge datas…

Good comment, dreadful article.

> The statement that RDBMs are not designed to handle huge datasets is plain wrong.

It's especially strange given Mongo's less-than-stellar scaling.

Re: Guide to MongoDB for startups

#43
post #36

Earlier quoted context omitted.

Do you think it is MongoDB problem or all NoSQL dbs has the some problem?

Other NoSQL solutions were not marketed as a replacement for relational databases. MongoDB might be better now,but you cant take managers for idiots an expect them to buy into your product again. Right now MongoDB only lives because of javascript and nodejs ,since nodejs sucks big time with anything that is not MongoDB,library and driver wise.

Absolute rubbish. The node Postgres driver is excellent and has performed flawlessly for us.

Re: Guide to MongoDB for startups

#44
post #7

I find it somewhat depressing that the first comments on any post about MongoDB generally seem to be short, disparaging and dismissive without offering much if any substance. We use MongoDB in production, processing millions of new records every month and it works great. Our data has differing and evolving schemas and can be used as JavaScript objects or python dictionaries with little effort. It works and performs w…

Aphyr has thoroughly explained what is wrong with MongoDB[1]. I'm quite sure that things aren't probably as swell with your tech stack you might imagine. A commenter here has in the past demonstrated how to cause someone using MongoDB data problems by sending too much information too quickly for MongoDB to handle in a targeted way although I can't find the link to it now. I have been wanting to try it myself to see i…

Aphyr did the same "Call Me Maybe" posts for other databases as well, highlighting their shortcomings. MongoDB has issues, but other databases have their rough edges as well. It all depends on how you use them.

For a group of people that know nothing but hammers, screwdrivers don't make much sense. This feels often what these "bash Mongo" arguments sound like.

There is no silver bullet. Just flippin' understand the tool you are using and how to use it.

Re: Guide to MongoDB for startups

#45
post #7

I find it somewhat depressing that the first comments on any post about MongoDB generally seem to be short, disparaging and dismissive without offering much if any substance. We use MongoDB in production, processing millions of new records every month and it works great. Our data has differing and evolving schemas and can be used as JavaScript objects or python dictionaries with little effort. It works and performs w…

That's because it really is a terrible database. It does absolutely nothing better than other popular databases. It's slower, less durable and has less features than Postgres, but also slower, less reliable and worse at sharding than Cassandra.

Slower than Postgres ... ha.

Re: Guide to MongoDB for startups

#46
post #7

I find it somewhat depressing that the first comments on any post about MongoDB generally seem to be short, disparaging and dismissive without offering much if any substance. We use MongoDB in production, processing millions of new records every month and it works great. Our data has differing and evolving schemas and can be used as JavaScript objects or python dictionaries with little effort. It works and performs w…

> We use MongoDB in production, processing millions of new records every month and it works great. It fails miserably in various ways when processing millions of new records per hour . On a very large scale MongoDB is unusable, but it is fine for problems 2-3 orders of magnitude smaller, so long as the data is not mission-critical.

Man, I need to go break the news to our customers that are successfully inserting millions of documents per hour (and their apps running nicely ... probably an app you have used) to inform them that, in all reality, they are "failing miserably."

They'd be shocked(!) at the news. ;)

Re: Guide to MongoDB for startups

#47
post #7

I find it somewhat depressing that the first comments on any post about MongoDB generally seem to be short, disparaging and dismissive without offering much if any substance. We use MongoDB in production, processing millions of new records every month and it works great. Our data has differing and evolving schemas and can be used as JavaScript objects or python dictionaries with little effort. It works and performs w…

> It works and performs well for us and our use case. 100% agree. I think it's become cool to knock MongoDB, just because it is MongoDB. It isn't a silver bullet, and its use cases are more limited than RDBMs. But if you know what you're doing, it has some great applications.

I'm sorry, this is absurd. You truly think that so many experienced database professionals and software developers speak out about the dangers of using it solely to be "cool"?

You really don't think it has anything to do with the numerous serious technical deficiencies it suffers from? (Read some of the other comments for this submission if you really do need more details about these problems.)

When it comes to databases, fooling around just isn't an option. If a given database technology has flaws, then those flaws need to be widely known. And this isn't done to be "cool". This is done because the safety and integrity of data are of the utmost importance when working with database systems, and it's absolutely critical to know about anything that may cause problems.

Re: Guide to MongoDB for startups

#48
post #36

Earlier quoted context omitted.

Do you think it is MongoDB problem or all NoSQL dbs has the some problem?

Other NoSQL solutions were not marketed as a replacement for relational databases. MongoDB might be better now,but you cant take managers for idiots an expect them to buy into your product again. Right now MongoDB only lives because of javascript and nodejs ,since nodejs sucks big time with anything that is not MongoDB,library and driver wise.

Absolute poppycock. Redis, Riak, Postgres, MSSQL drivers all work quite well.

Re: Guide to MongoDB for startups

#49
post #47

Earlier quoted context omitted.

> It works and performs well for us and our use case. 100% agree. I think it's become cool to knock MongoDB, just because it is MongoDB. It isn't a silver bullet, and its use cases are more limited than RDBMs. But if you know what you're doing, it has some great applications.

I'm sorry, this is absurd. You truly think that so many experienced database professionals and software developers speak out about the dangers of using it solely to be "cool"? You really don't think it has anything to do with the numerous serious technical deficiencies it suffers from? (Read some of the other comments for this submission if you really do need more details about these problems.) When it comes to datab…

> You truly think that so many experienced database professionals and software developers speak out about the dangers of using it solely to be "cool"?

Yes, I do, actually. I see a TON of out-of-date commentary on places like HN, or just stuff that is factually incorrectly.

I have used MongoDB in production for 3+ years, and it hasn't caused any problems.

I will say the out-of-the-box set up isn't what you want in production.

Re: Guide to MongoDB for startups

#50

Earlier quoted context omitted.

That's because it really is a terrible database. It does absolutely nothing better than other popular databases. It's slower, less durable and has less features than Postgres, but also slower, less reliable and worse at sharding than Cassandra.

Slower than Postgres ... ha.

You're kinda all over the place trying to defend MongoDB...

So, what is your stake in it? You like it? You have a lot of customers on it and you want to validate your decision?

I'm just curious, because by my tastes, MongoDB is an awful database. It's like the PHP of Databases. It seems like there are a lot of better choices out there especially in the last few years.

Post reply on HN