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

71–80 of 118 posts

Re: Startup Engineers and Our Mistakes with MongoDB

#71

Post by owebmaster »

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 do think that mongodb is appropriate for 90% of the database installations, but also are mysql and postgres. Most of it is wordpress anyway.

Re: Startup Engineers and Our Mistakes with MongoDB

#72

Post by bdcravens »

scarface74 wrote: post #66
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…

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. I use ORMs to do just what the name implies -- to map relational models to objects. If I'm working with objects anyway, either I'm going to end up…

> "It's a poor carpenter that blames his tools"

I think the point of the article is that Mongo is being used mostly by "poor carpenters", and provides worse defaults than SQL does. It's obvious you're operating at an advanced level that young and hungry startups aren't.

Re: Startup Engineers and Our Mistakes with MongoDB

#73

Post by emodendroket »

mrtksn wrote: post #53
emodendroket wrote: post #42

Earlier quoted context omitted.

Sure, but it is also another service to keep running. Depends on what scale you're operating at.

Any RDBMS is just a toolset to manage files on some filesystem. If you are dealing with some config files you can spare yourself the trouble and just load them from the filesystem. NoSQL or classic RDBMS, these tools give you ways to manage your data on the filesystem(or in the memory?). You can spend time to write a code that processes files in a folder or you can use the software that does it for you. You can write…

I don't really have to write that code though; what language doesn't already have file-manipulation libraries?

Re: Startup Engineers and Our Mistakes with MongoDB

#74

Post by nevi-me »

kentosi wrote: post #56
optimuspaul wrote: post #10

Earlier quoted context omitted.

"Today in 2017, there is no real reason to use Oracle other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed relational store." Point being you can say just about the same thing about any other database. They are all flawed for one reason or another. I happen to like Mongo quite a lot, but I rarely use it. You need to understand what situations it works bes…

"You need to understand what situations it works best in" I always hear this, but with no "such as" examples given. Could you please provide some?

The same example I provide everywhere. I have successfully used Mongo as a geospatial data store, where I have a public transit app/website, and most objects/documents have geospatial properties.

Sure, there's PostGIS, but saving a GeoJSON multiline which I can slap an index on works for me.

I have grown fond of Mongo because I've been using it for almost 5 years now. I know its limitations, and also what I can do in RDBMS that I can also do in it.

I sometimes build OLAP logical models at work for clients, and most of what I touch at work is SQL, but sometimes when I start a project I use Mongo instead of SQL.

It's only one use-case, but I hope it is something.

Re: Startup Engineers and Our Mistakes with MongoDB

#75

Post by metheus »

flavio81 wrote: post #21
pryelluw wrote: post #6

I feel the best thing to come out of MongoDB is that Postgres now handles JSON.

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.

Re: Startup Engineers and Our Mistakes with MongoDB

#76

Post by mrtksn »

emodendroket wrote: post #73
mrtksn wrote: post #53

Earlier quoted context omitted.

Any RDBMS is just a toolset to manage files on some filesystem. If you are dealing with some config files you can spare yourself the trouble and just load them from the filesystem. NoSQL or classic RDBMS, these tools give you ways to manage your data on the filesystem(or in the memory?). You can spend time to write a code that processes files in a folder or you can use the software that does it for you. You can write…

I don't really have to write that code though; what language doesn't already have file-manipulation libraries?

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.

Re: Startup Engineers and Our Mistakes with MongoDB

#77

Post by STRML »

threeseed wrote: post #57
STRML wrote: post #16

Earlier quoted context omitted.

> I think document stores are a great thing; the only problem is that MongoDB isn't a good document store. To add to that - you know when you need one. If you don't know you need a document store, you don't need it. When you try a good document store, like Solr, you realize how appallingly limited Mongo really is. It's not suited for any practical use outside of demo apps.

Solr is not a document store. It's a search engine. If you actually tried using it as one you would realise how ignorant your comment is. Both the Solr and ElasticSearch have gone on record before stating that it should never be used as the source of truth.

And yet - it can be used as one. "If you actually tried using it" is a wholly inappropriate thing to say to someone you don't know. We used it in a large application indexing & faceting millions of documents, and it works just fine for the practical purpose of querying & retrieving those documents. Of course, we did mate it with Postgres to build the full app. Each tool to its strength.

There's no need for the vitriol.

Re: Startup Engineers and Our Mistakes with MongoDB

#78

Post by emodendroket »

mrtksn wrote: post #76
emodendroket wrote: post #73

Earlier quoted context omitted.

I don't really have to write that code though; what language doesn't already have file-manipulation libraries?

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.

Re: Startup Engineers and Our Mistakes with MongoDB

#79

Post by kazen44 »

bdcravens wrote: post #68
scarface74 wrote: post #63

Earlier quoted context omitted.

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.

Joins are typically a tiny intersection of 2 data sets. Multiply that by the number of web requests. Moreover, a query planner is far more optimized than the code you'd write on your web server.

also, scaling databases is not terribly difficult, it is just very "clumsy".

Still, having a proper transaction manager and query planner will give you far better performance compared to doing it on webservers.

Also, aren't bsically moving the complexity of the database to the webserver? Which makes your webserver far more complex and harder to scale in comparison. Especially if you need ACID. (which is a must if you are doing anything with data storage imo).

Re: Startup Engineers and Our Mistakes with MongoDB

#80

Post by kazen44 »

danpalmer wrote: post #5
cmenge wrote: post #3

I'm a long-time MongoDB user and largely a fan of it because I believe the interface is superior to some text-based SQL statements. But whatever DB you like, if you move the state of your application to another application (i.e, a database) you better make sure you really understand how it works. For SQL databases, many people think they know how they work, but misconceptions seem widespread. Essentially, many beginn…

> Some databases might be easier to understand than others, but I feel MongoDB is on the 'easier' end here. YMMV. I agree with most of this, relational databases have a lot of moving parts that many developers (myself included) don't fully understand. However, I believe relational databases (Postgres is what I have experience with) has defaults that are basically correct, and unlikely to cause significant issues, whe…

> However, I believe relational databases (Postgres is what I have experience with) has defaults that are basically correct, and unlikely to cause significant issues, whereas in my experience MongoDB did not have this. MongoDB might be easier to understand on the surface, but I think that's deceptive.

Postgres has good and sane defaults. Also the documentation INSIDE the config file is top notch. The one thing which makes postgres the golden standard in my opinion is its extensive documentation. Documentation is key to maintaining an RDBMS

Mysql does some weird things on an initial install, and documentation is sadly all over the place.

Post reply on HN