Was MongoDB Ever the Right Choice? • Hacker News Board

Re: Was MongoDB Ever the Right Choice?

#211

Post by tracker1 » Thu, Mar 28, 2019, 12:03 AM UTC

matthewmacleod wrote: post #192

zjaffee wrote: post #171

Earlier quoted context omitted.

I have to absolutely disagree with the point you're making about mongodb never being something an experienced developers should use. An experience developer understands when the goal is to deliver something as fast as possible vs building something more resilient. If you're building an internal tool, particularly one that won't be storing data that would later be used for analytics, there's absolutely no reason to no…

You could be saving at least 20% of the time spent not having to worry about a datamodel. You are not "not worrying about a datamodel" – you are just ignoring the data model that exists . And that overhead, if it exists at all, is far less than "20%".

    s/datamodel/data-mapping/

Re: Was MongoDB Ever the Right Choice?

#212

Post by tracker1 » Thu, Mar 28, 2019, 12:04 AM UTC

matthewmacleod wrote: post #194

ex_ex_nihilo wrote: post #158

Earlier quoted context omitted.

Postgres is not an alternative to Mongo, though. Provide a noSQL alternative if you want an alternative. RDBs and non-RDBs seek to address different sets of problems, and sometimes you do not want or need a relational database.

In what situations do you feel MongoDB is a better solution than Postgres? The latter is both relational and document-oriented as required.

Setting up a simple cluster without relying on addons, or having to worry about which server in the cluster your writes are going to (bisected application configurations)

Re: Was MongoDB Ever the Right Choice?

#213

Post by tracker1 » Thu, Mar 28, 2019, 12:06 AM UTC

mailslot wrote: post #143

I went to production with Mongo and it exceeded my expectations. It operated without a single issue for years under high load. It was a dream to administer and a vital piece of a multimillion dollar franchise. Everybody else I know, however, has had nothing but headaches. They’re the same reasons I’ve seen people fail at using Cassandra, Redis, or Spanner. If you can’t adjust to the limitations and paradigm shift, yo…

biggest headaches I ever saw with it, was when Azure had several regions down (could happen with any cloud)... when it came up, it was spotty and the cluster itself never really recovered. Fortunately it was replicated read data from another source and in the end it was faster to stand up a new cluster. It could have been much more painful that it was for my own experience.

Re: Was MongoDB Ever the Right Choice?

#214

Post by tracker1 » Thu, Mar 28, 2019, 12:12 AM UTC

tinco wrote: post #141

tgtweak wrote: post #117

Earlier quoted context omitted.

You and I must be the only ones on HN using mongo at scale and enjoying it. We use it as an event database which collects over 100M+ semi-structured records daily with about 200 (and growing) different schemas... It keeps 1.5TB of records in the collection which is achieved using the invaluable capped collection function, and we can index the structured fields very easily. We also pipe the data into elastic for quick…

My project as well, sharded over 4 nodes, ingesting about a TB every two weeks. Automatic deletion of old data was too slow so we had to work with a scheme that allowed us to drop daily collections, but beside that it ran great. This was 6 to 3 years ago though. Maybe there's a better log stash out there now? I haven't seen one yet.

ElasticSearch does most of what you are saying in the box, can even have each day read into a different collection and query them on joined aliases. At least IIRC, I'm not an expert. When I first tried using it and Mongo, I had issues with ES geo indexing, but since then have used both with little issue. Just depends on the scenario.

Re: Was MongoDB Ever the Right Choice?

#215

Post by tgtweak » Thu, Mar 28, 2019, 4:13 AM UTC

tracker1 wrote: post #214

tinco wrote: post #141

Earlier quoted context omitted.

My project as well, sharded over 4 nodes, ingesting about a TB every two weeks. Automatic deletion of old data was too slow so we had to work with a scheme that allowed us to drop daily collections, but beside that it ran great. This was 6 to 3 years ago though. Maybe there's a better log stash out there now? I haven't seen one yet.

ElasticSearch does most of what you are saying in the box, can even have each day read into a different collection and query them on joined aliases. At least IIRC, I'm not an expert. When I first tried using it and Mongo, I had issues with ES geo indexing, but since then have used both with little issue. Just depends on the scenario.

Latest ES supports purging expiry based on a time field I believe, but before that you were creating daily/hourly indexes and haggling with elastic curator to delete them. There is also no meaningful way to do it by logical size.

Elastic is great in it's own sense, but it's not as flexible as mongo when it comes to schemas.

Re: Was MongoDB Ever the Right Choice?

#216

Post by tgtweak » Thu, Mar 28, 2019, 4:16 AM UTC

felixfbecker wrote: post #89

scarface74 wrote: post #63

Earlier quoted context omitted.

I’m a big fan of Mongo for the use case you described - searching by ID and all information in one document. But people don’t seem to understand that there are plenty of scenarios where you really either don’t know the schemes in advance and/or the “schema” is defined by an external source. I worked for a company that sold software that allowed users to create forms that could be filled out either on the web or via a…

PostgreSQL's JSON columns are pretty powerful

They added Json fields to mssql too, didn't make it a mongo killer.

Re: Was MongoDB Ever the Right Choice?

#217

Post by tgtweak » Thu, Mar 28, 2019, 4:21 AM UTC

a13n wrote: post #52

These "caveats" are mostly false, or outdated. > Loss of transactions MongoDB 4.0 supports ACID transactions: https://www.mongodb.com/transactions > Loss of relational integrity (foreign keys) > Having a database enforce these relationships can offload a lot of work from your application, and therefore from your engineers. I've never seen anyone use MongoDB without also using something like Mongoose where you get all…

Mongo has supported schema enforcement for a few years now, it's not used often but if you want it, it's there.

Re: Was MongoDB Ever the Right Choice?

#218

Post by jd_mongodb » Thu, Mar 28, 2019, 12:57 PM UTC

acl777 wrote: post #75

If one researches the company's history, MongoDB came from a specific need the founders had for another product: ShopWiki. ShopWiki is a shopping price listing site, where it keeps tracks of prices for any item: computer, clothing, food, etc. ShopWiki needs to be able to store, access, AND search amongst all of these different items. So, MongoDB is the perfect solution. If the application being built has similar requ…

Untrue. MongoDB arose from the frustrations the founders had with scaling SQL databases while building DoubleClick.

Re: Was MongoDB Ever the Right Choice?

#219

Post by [deleted] » Thu, Mar 28, 2019, 9:17 PM UTC

scarface74 wrote: post #144

jacques_chester wrote: post #73

Earlier quoted context omitted.

1. Writing DDL is not hard. It's just not very hard. 2. You can go from strict guarantees to looseness safely, when you demonstrably need to. The reverse isn't true -- it's easy to wind up realising, much too late, that you actually needed particular guarantees that you didn't even think of. Relational databases didn't become incredibly popular by accident. It's because they were a drastic improvement -- theoreticall…

Writing DDLs are hard when you don’t know in advanced what the schema is or the schema is changing frequently. A lot of things “become popular” but that doesn’t necessarily mean they are good.

[deleted]

Re: Was MongoDB Ever the Right Choice?

#220

Post by scarface74 » Fri, Mar 29, 2019, 1:21 AM UTC

mr_toad wrote: post #207

felixfbecker wrote: post #89

Earlier quoted context omitted.

PostgreSQL's JSON columns are pretty powerful

And if you create a table with a single ID column and a single JSON column you’ve essentially re-invented a NoSQL database. But I guess you can pretend it isn’t.

And it’s a lot worse and the tooling isn’t as robust...