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

51–60 of 118 posts

Re: Startup Engineers and Our Mistakes with MongoDB

#51

Post by threeseed »

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 to other databases. It is a document database with easy to use scalability options in a market that doesn't have many of these. And it's mentioned throughout their documentation and by third parties about the pros/cons of document databases and how to appropriately model your data.

And yes these postmortems are becoming very tiring. Engineers should not be pushing any technology without a spike to determine whether it's appropriate or not. If you don't have a document orientated data model then don't use a document store.

Re: Startup Engineers and Our Mistakes with MongoDB

#52

Post by mbreese »

eberkund wrote: post #41

What about for IoT devices? I could see NoSQL still having a place there, although I could also see it working just as well with a SQL database.

What is special about IoT devices that make them more suited towards a NoSQL solution? Scale? Is that really an issue for the majority of IoT deployments?

Re: Startup Engineers and Our Mistakes with MongoDB

#53

Post by mrtksn »

emodendroket wrote: post #42
mrtksn wrote: post #30

Earlier quoted context omitted.

You definitely can but MongoDB provides convenience over storing and managing JSON files on you filesystem by your own efforts.

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 a code that relates two files in a folder or you can use a software that already can do it and you can just ask that software for the outcome.

Re: Startup Engineers and Our Mistakes with MongoDB

#54

Post by threeseed »

flavio81 wrote: post #27
mrtksn wrote: post #20

Earlier quoted context omitted.

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…

> 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. OR, i can open a file stream, serialize my data to JSON, entity by entity, and dump all to a file. The good old file.

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 ?

Re: Startup Engineers and Our Mistakes with MongoDB

#55

Post by tinix »

Bartweiss wrote: post #33
danpalmer wrote: post #5

Earlier quoted context omitted.

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

> 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. Strongly, strongly agreed. Learning every moving part in InnoDB (as an example) is quite a task. But not knowing about those features will rarely burn you, and it's usually apparent when you need to know someth…

Man, people just looooove to link 5 year old blogs about fault tolerance, meanwhile that isn't even relevant anymore, and honestly, it wasn't relevant at the time either, because changing the write concern is trivial.

The real nugget of truth here is this; don't use tools that you don't understand... PERIOD.

Further, there are a plethora of alternative engines for Mongo that do have fault tolerance in mind.

Re: Startup Engineers and Our Mistakes with MongoDB

#56

Post by kentosi »

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…

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

Re: Startup Engineers and Our Mistakes with MongoDB

#57

Post by threeseed »

STRML wrote: post #16
flavio81 wrote: post #13

Earlier quoted context omitted.

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.

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.

Re: Startup Engineers and Our Mistakes with MongoDB

#58

Post by lowbloodsugar »

mrtksn wrote: post #30
emodendroket wrote: post #23

Earlier quoted context omitted.

It that point it's harder for me to understand why I'm not just writing out JSON files or something.

You definitely can but MongoDB provides convenience over storing and managing JSON files on you filesystem by your own efforts.

No, I really can't think of any situation where installing, managing, updating, maintaining, and crying over a mongodb cluster would be easier for a flat-file datastore than say, a file system, or S3. In fact if one is on AWS, then nothing beats just dumping them in S3 and processing them as necessary. If I'm a startup and I really wanted some querying then PostgreSQL looks great, with Amazon handling the maint and backups.

Re: Startup Engineers and Our Mistakes with MongoDB

#59

Post by eip »

nemild wrote: post #2

(I’m the author of this series) Eliot Horowitz (HN: @ehwizard), MongoDB’s current and founding CTO, reached out after my last post - and spent two hours providing feedback last week in Palo Alto. It was an expansive discussion, and Eliot was reflective and eager to understand the perspectives I had heard. He noted how much it mattered to him what HN thought. I left with tremendous empathy for the challenges of buildi…

> In that sense, he argues that Amazon RDS is a form of NoSQL today

Lol. What?

RDS is literally hosted RDBMS SQL databases.

Re: Startup Engineers and Our Mistakes with MongoDB

#60

Post by tinix »

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.

THIS, so much this!!!!

I'm working on overhauling (rewriting, from scratch) a project right now where the previous developer decided in his infinite wisdom that using ES as a database was a good idea.

I have tried repeatedly to explain to him, and the product owner, why using a search engine as a storage database is a horrific idea. Owner gets it, dev doesn't. I asked that dev if he could overhaul the project, what would he do, and he said "not use SQL at all, and use ES 100%". I think this is the problem with Mongo too... you have people misusing it, and then want to throw the baby out with the bath water and act like Mongo is the problem, when really, the problem is how they are using it.

Post reply on HN