Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Startup Engineers and Our Mistakes with MongoDB

nemil.com

Post reply on HN
Print view View original

81–90 of 118 posts

Re: Startup Engineers and Our Mistakes with MongoDB

#81

Post by adjkant »

scarface74 wrote: post #65
adjkant wrote: post #8

The reality of MongoDB is that it's a very specific use case of nonrelational data, which is very rare these days. I'm sad that so many people get looped into Mongo with a MEAN/MERN stack when those apps are almost always the CRUD apps that would benefit from SQL. Why force yourself to maintain a schema implicitly for relational data when you can get error messaging and explicit schemas? I think MongoDB is a great fi…

"I've been coding for 4 years and have yet to find a problem that fit Mongo best." I'm going to leave that right there.....

I can't read the implication of this, but to clarify, I haven't personally encountered a problem that fit Mongo best. I can imagine one.

Re: Startup Engineers and Our Mistakes with MongoDB

#82

Post by nulagrithom »

scarface74 wrote: post #63
MikeKusold wrote: post #7

> By far the most consistent mistake was choosing a non-relational database, when your data was strongly relational. Mongoose's ODM made this mistake surprisingly easy to make, which led to issues down the line. This mirrors my experiences with Mongo as well. The vast majority of data is relational. Mongoose allows people to make the mistake of structuring their data relationally. But all you are doing is pushing all…

But all you are doing is pushing all the joins to the web server (which in Node land is single threaded and compounds the mistake of choosing NoSQL). Why is pushing the joins "to the web" inherently bad? It's a lot easier to scale web servers than database servers.

Simplified, a JOIN on an SQL server will take advantage of its indexes to grab the data from the disk that matches the specified criteria. SQL databases are built for this sort of thing, and they're really freaking good at it.

Sending that same JOIN to the web server means, at the least, shipping everything from both tables matching the criteria and matching up those two potentially huge blobs of data with each other on the web server. Doing this in an even partially efficient manner will split your query logic between DB queries and other code. Also, it's not unlikely that you'll be doing this JOIN operation in a language that maybe isn't great at optimizing that sort of CPU intense behavior on its own, so you're probably going to need to drill in and optimize on your own (vs letting SQL do its magic). Plus, we're going to need to store all this data in memory while we match it. So now our web servers, while more easily scaled than a DB, are actually pretty damn big boxes with decent memory and CPU, and that's expensive to scale.

Re: Startup Engineers and Our Mistakes with MongoDB

#85

Post by winter_blue »

tinix wrote: post #64
winter_blue wrote: post #15

Earlier quoted context omitted.

Couple of points: 1. ORMs I'm not sure why you dismiss ORMs. Have you ever used a good ORM? There are a lot of high-quality ORMs out there, that do the heavy lifting, provide type safety, and take care of the boilerplate. There is no reason to write text-based SQL anymore. 2. Relations: Foreign keys are incredibly useful. They're the biggest feature I miss out in relational databases. They help keep your data in a sa…

Most of your points are ripe with folly. 1. ORMs are slow, but generally they are worth it, and it's trivial to dive into raw queries when needed for performance reasons. 2. Mongo supports relationships, not sure what you're trying to get at. Reverse delete rules are TRIVIAL to implement in your models. This is NOT the fault of the database engine, but fault of the developer, 100%. 3/4. Lack of normalization and sche…

You should try to not start a comment with an attack. It just makes you look bad. See: http://www.paulgraham.com/disagree.html

Regarding your points:

> 1. ORMs are slow

Maybe you haven't used any recent ORM. Where did you get this idea from? In the JVM world, Hibernate is nearly dead for new projects. EBean[1] and JOOQ[2] are both great choice server-side Java/Kotlin/Scala projects. On Android / for SQLite, there's DBFlow[3], which I've used, and had great experiences. These ORMs are fast, intuitive, and powerful.

Also relevant is: https://dzone.com/articles/martin-fowler-orm-hate

> 2. Mongo supports relationships

Mongo's approach to relations[4] is far weaker and less powerful than what an RDBMS can handle. It was almost tacked on later as an afterthought. In addition, joins aren't a easy and straightforward with the kind of relations that NoSQL databases, like MongoDB support.

> 3/4. Lack of normalization and schema is only a problem if you let it be. This is why model layers exist!

NoSQL databases actively encourage de-normalization. For example, just take a look at this Firebase blog post[A] or see this page in their documentation[B]. It's almost sad and a shame that a company like Google is encouraging such poor ideas and practices; practices that they likely don't follow themselves (but I could be wrong).

I know some young devs, who just graduating out of college, swoon all over databases like Firebase's. They read articles like these that say "schema-free" is cool, and denormalization is "normal". Ugh... I almost want to throw up.

Model layers are optional. I recently worked at, and quickly quit, a (Fortune 500) company that used MongoDB, had an incredibly complex data model, and had no model layer or schema enforcement of any kind. Their codebase was thoroughly bug-ridden, and their heavily denormalized data had out-of-sync and stale copies all over the place. It was disgusting.

[1] http://ebean-orm.github.io/

[2] https://www.jooq.org/

[3] https://agrosner.gitbooks.io/dbflow/content/

[4] https://stackoverflow.com/a/6994654

[A] https://firebase.googleblog.com/2013/04/denormalizing-your-d...

[B] https://firebase.google.com/docs/database/web/structure-data

Re: Startup Engineers and Our Mistakes with MongoDB

#86

Post by pritambaral »

threeseed wrote: post #51
slap_shot wrote: post #29

It terrifies me to see this quote from their CTO: "MongoDB's CTO disagrees with this statement arguing that nearly 90% of database installations today would benefit from being replaced with MongoDB." I used to attend "office hours" at MongoDB's office where guests ask MongoDB employees for help. Most of my questions involved very complex aggregation queries (that would have been trivial in SQL) that even MongoDB empl…

I really don't understand your comments. You're critical that MongoDB employees whose job it is to help people use the product showed users approaches to implement their use cases. How is that bad or somehow unique ? I've been to Datastax, MySQL, Oracle, Teradata, Cloudera, Hortonworks workshops before and all of them did the same thing. It's their job. Also MongoDB has been crystal clear what it offers in comparison…

> approaches to implement their use cases.

This is where you and your parent disagree. Your parent believes they showed "hacks" and not "approaches to implement their use cases".

Re: Startup Engineers and Our Mistakes with MongoDB

#87

Post by mrtksn »

emodendroket wrote: post #78
mrtksn wrote: post #76

Earlier quoted context omitted.

Well I guess some people wonder why people are using ready software when you can achieve the exact same thing with a text editor and a compiler.

That's not the same thing at all; you're suggesting an approach that probably takes more code and definitely takes more setup.

You are underestimating the complexities of file management

Re: Startup Engineers and Our Mistakes with MongoDB

#89

Post by pritambaral »

bdcravens wrote: post #69
threeseed wrote: post #54

Earlier quoted context omitted.

Because we want to do partial updates, searches, indexing etc. Your position can be applied to all databases. Why not abandon them all and just use CSV ?

You could always do that, dump the data to s3, and use Athena :-) https://aws.amazon.com/athena/

And then be locked-in to Amazon. From ubiquitous files to ... a single service provider.

Re: Startup Engineers and Our Mistakes with MongoDB

#90

Post by pritambaral »

metheus wrote: post #75
flavio81 wrote: post #21

Earlier quoted context omitted.

No doubt the best thing that has happened lately to Postgres as well! And Postgres can do JSON with vastly more performance than Mongo: https://www.enterprisedb.com/postgres-plus-edb-blog/marc-lin...

If you're going to get on the "MongoDB was overhyped" bandwagon, you should probably not post links to performance comparisons you pulled off of an EDB Postgres website.

At least EDB used an inspectable and reproducable test. I think posting links to performance comparisons is fine when the performance comparison can be independently verified.
Post reply on HN