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

11–20 of 118 posts

Re: Startup Engineers and Our Mistakes with MongoDB

#11

Post by adjkant »

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…

+1 - Mongo is much easier to misuse. Not to mention that many users of SQL these days use ORM's that abstract many of the complex SQL features with a professional library that actually knows how to handle the small details and only exposes a basic subset of functionality that is good enough for most use cases.

Re: Startup Engineers and Our Mistakes with MongoDB

#12

Post by STRML »

flavio81 wrote: post #4

Today in 2017, there is no real reason to use MongoDB other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed document store.

The hype is the real issue. Even today, the CTO appears to claim that 90% of apps aren't relational enough to need Mongo.

I did a startup in 2011/2012 where we bought into the hype and used MongoDB & Node + Mongoose. It was horrific.

Your app is relational, full stop. You would know if it wasn't. Do you have users? Do those users need to log in? Well, you now have access tokens related to users. Do those users need to create anything at all? You've now related those owned objects back to the user. We're talking the very basics of any application, and Mongo's support for it is basically nil.

We went down the road of embedding relations inside the model (e.g. an "user" has multiple "tickets" to "events"), and then we'd just filter through the "events" table to find the related one. But what if the admin running the event wants a list of all the tickets for his event? We're talking webapp 101 stuff, but we had to write some really gnarly application logic and duplicate a bunch of data to make it fast.

It was a complete waste of time.

At the crux of this is a fallacy that easier is always better. It's not. There is a reason SQL databases are a little complicated to use - they have evolved over many decades to fit the needs of real applications. MongoDB is only barely removed from writing raw JSON arrays to disk, which is probably the simplest "database" imaginable.

When you so callously discard the common wisdom on how to store data, you rediscover why it exists, the slow, hard way.

10gen made a business - and a fortune - out of misleading new developers.

Re: Startup Engineers and Our Mistakes with MongoDB

#13

Post by flavio81 »

optimuspaul wrote: post #10
flavio81 wrote: post #4

Today in 2017, there is no real reason to use MongoDB other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed document store.

"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…

Oracle RDBMS isn't flawed. It is expensive, complex to configure/mantain/extend, expensive in licensing, expensive in storage, and also expensive. Did i mention expensive?

PostgreSQL is eating Oracle's customers little by little.

RDBMS aren't flawed at all, this is technology that has been perfected for the last 40 years. What is flawed is to think that relational data can be easily stored on a document store (typical mistake).

I think document stores are a great thing; the only problem is that MongoDB isn't a good document store.

Re: Startup Engineers and Our Mistakes with MongoDB

#14

Post by hitgeek »

nothing much new here.

mongodb marketing/PR was a problem, advertising a general purpose RDMS alternative without the technology to support it.

users were also a problem, using a technology without understanding the architecture and trade-offs.

to be over critical of "mongodb" though is unproductive. there were a lot good people working on new software to solve hard problems and I'd like that to continue.

lets just not repeat the same mistakes. don't get caught in marketing hype, and carefully evaluate technology decisions.

Re: Startup Engineers and Our Mistakes with MongoDB

#15

Post by winter_blue »

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…

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 sane state. If a user deletes his account, you can configure your database use a DELETE CASCADE to automatically remove all data associated with the user.

3. Normalization: NoSQL databases encourage you to denormalize your data. I've seen NoSQL databses frequently run into problems with stale data, with date that is duplicated and not kept updated, where you have multiple out-of-sync version of the same piece of information. With NoSQL database, you have to handle all the complications of denormalization. (You, the developer, have to remember to update/delete/etc from the multiple places the same piece of data lives in.) The database doesn't do it for you. (The database is a dumb key-value store, nothing more.) Relational databases encourage keeping the logical design of your databse normalized. To quote Wikipedia: "The preferred method is to keep the logical design normalised, but allow the database management system (DBMS) to store additional redundant information on disk to optimise query response. In this case it is the DBMS software's responsibility to ensure that any redundant copies are kept consistent. This method is often implemented in SQL as indexed views (Microsoft SQL Server) or materialised views (Oracle).".

4. Schemas: The worst thing about NoSQL is the absence of an enforced schema. Schemaless databases are a scourge. There's always a schema -- it's just that it's scattered all over the code. If you are joining a new company, you have to sift through piles of code to figure what the structure of the data is. Schemas are like types, and my dislike for dynamically typed languages carries over to schema-less database. Relational databases make you think carefully about the schema, and specify the schema explicitly.

In the end, you end up needing to do a lot of extra work, likely end up with more unstable and buggy system, just to avoid the small amount of totally-worth-it upfront work that setting up a relational database requires.

Re: Startup Engineers and Our Mistakes with MongoDB

#16

Post by STRML »

flavio81 wrote: post #13
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…

Oracle RDBMS isn't flawed. It is expensive, complex to configure/mantain/extend, expensive in licensing, expensive in storage, and also expensive. Did i mention expensive? PostgreSQL is eating Oracle's customers little by little. RDBMS aren't flawed at all, this is technology that has been perfected for the last 40 years. What is flawed is to think that relational data can be easily stored on a document store (typica…

> 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.

Re: Startup Engineers and Our Mistakes with MongoDB

#17

Post by STRML »

pryelluw wrote: post #6

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

Yes, this was an incredible development, and lead to hilarious projects like ToroDB (MongoDB API on top of Postgres), which ended up being faster and safer, with relations when you need them.

JSON columns can be incredibly useful and easy to understand for things like user preferences, without the hassle of a metatable.

Re: Startup Engineers and Our Mistakes with MongoDB

#18

Post by 43224gg252 »

STRML wrote: post #12
flavio81 wrote: post #4

Today in 2017, there is no real reason to use MongoDB other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed document store.

The hype is the real issue. Even today, the CTO appears to claim that 90% of apps aren't relational enough to need Mongo. I did a startup in 2011/2012 where we bought into the hype and used MongoDB & Node + Mongoose. It was horrific. Your app is relational, full stop. You would know if it wasn't. Do you have users? Do those users need to log in? Well, you now have access tokens related to users. Do those users need t…

>Do you have users? Do those users need to log in? Well, you now have access tokens related to users.

Aren't those tokens supposed to be stored client side anyway? Aren't those tokens supposed to contain encoded information about the user that you decode server side? Why would you store the users token to begin with?

Re: Startup Engineers and Our Mistakes with MongoDB

#19

Post by flavio81 »

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…

> Choosing a system that only offers very few guarantees forces you to think about them more explicitly.

Yes, of course. And it also forces you to implement, on your own: relational (key) constraints, real transactions, etc.

And thus, you, on your own, compete against more or less 44 years of research, developing, and releases by brilliant computer scientists and engineers (Ingres DB, 1973- PostgreSQL latest version, 2017), scientists who already solved those problems {relational constraints, transactions, etc} and made said solutions perform to the max possible.

So a better alternative is to simply... learn more about relational databases.

Re: Startup Engineers and Our Mistakes with MongoDB

#20

Post by mrtksn »

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…

If data needs to be processed, an option would be to use MongoDB for collecting the data in bulk and later decide how you need to structure it for your needs.

When it comes to "read" the data, you read it only from processed database that can be anything.

Since you can do your processing completely independently of your web server, your are not necessarily pushing your computational load from the DB to the web server.

Post reply on HN