Was MongoDB Ever the Right Choice? • Hacker News Board

Re: Was MongoDB Ever the Right Choice?

#51

Post by taffer » Wed, Mar 27, 2019, 10:43 AM UTC

myrryr wrote: post #36

mruts wrote: post #15

Earlier quoted context omitted.

Why not just use a SQL db that handles json and stick everything in a couple columns? Changing databases is a lot of work, and as far as I can tell, mongo isn’t really providing much value over SQL dbs that already support schemaless json columns.

Because you still have to write a layer between your web app and the database at the prototyping stage? I can't just make calls from Html + JS to Postgres. But I can with MongoDB

Or you can use something like Postgrest: http://postgrest.org

Re: Was MongoDB Ever the Right Choice?

#52

Post by a13n » Wed, Mar 27, 2019, 10:46 AM UTC

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 this for free. Zero work for your engineers. https://mongoosejs.com/

> Lack of ability to enforce data structure

Again, Mongoose. The work doesn't fall on your engineers, it falls on an awesome, heavily-used, heavily-tested library.

> Custom query language

Can you give an example of something that you realistically would want to do in SQL that you can't with a JSON query?

> Loss of tooling ecosystem

This might be the only valid caveat in the entire article.

Re: Was MongoDB Ever the Right Choice?

#53

Post by bonesss » Wed, Mar 27, 2019, 10:47 AM UTC

jandrewrogers wrote: post #50

My anecdote: several years back I had a test lab for measuring the performance and scalability characteristics of various geospatial databases. We added MongoDB to the mix a couple years after they released geospatial support. We always verified basic correctness with a new database by inserting several billion geometries as fast as the database would accept them, reading the entire data set back out, and comparing i…

I evaluated several distributed databases for a healthcare-related system. The ability to lose messages in sharding scenarios, and the specifics of how one would recover them, made me think I could never support MongoDB for anything more serious than Reddit.

Re: Was MongoDB Ever the Right Choice?

#54

Post by willvarfar » Wed, Mar 27, 2019, 10:51 AM UTC

matthewmacleod wrote: post #32

gnur wrote: post #21

Off course it was, prototyping speed on mongodb was (and probably still is) always excellent. Some features that don't scale are very nice to have when you don't have scaling issues. For example, if you add tags to your documents and you want to query on those tags (find all documents containing tag A and B), it's nice that's just a builtin. I haven't found a single datastore that is as developer friendly that suppor…

The other answers have confirmed that Postgres will do this with array fields, and it's good advice to follow. It's also in my view much easier to read than MongoDB's query language is! CREATE TABLE documents (name text, tags text[]); INSERT INTO documents VALUES ('Doc1', '{tag1, tag2}'); INSERT INTO documents VALUES ('Doc2', '{tag2, tag3}'); INSERT INTO documents VALUES ('Doc3', '{tag2, tag3, tag4}'); SELECT * FROM…

Postgres array columns are super neat!

As I already use MySQL in many projects, I do much the same thing with MySQL's json support.

I believe json is now supported by Sqlite too.

Basically, if you already have an up-to-date relational database, then the chances are you can already use it as a sane document store.

Just saying, so nobody reading the threads thinks they have to go grab some new database if they are already using one!

Re: Was MongoDB Ever the Right Choice?

#55

Post by superwayne » Wed, Mar 27, 2019, 11:04 AM UTC

The really interesting part of the article comes after the "What could have been done differently?" headline. I think the article would have been better if it wasn't focused as much on MongoDB because now everybody is discussing if the caveats still apply or ever applied.

Re: Was MongoDB Ever the Right Choice?

#56

Post by ants_a » Wed, Mar 27, 2019, 11:06 AM UTC

ddebernardy wrote: post #33

geezerjay wrote: post #29

Earlier quoted context omitted.

> Why not just use a SQL db that handles json and stick everything in a couple columns? Honest question: what's wrong with just defining a domain model, adopting an ORM and a serialization framework, and simply go with a conventional RDBMS? Afaik all reference web application frameworks handle this right out of the box.

Nothing on paper, if you get the schema more or less correctly the first time. The problem is when you need to do a schema change that affects terabytes of data down the road.

That is going to be a problem regardless of technology.

With an enforced schema you will at least know that all of the existing data matches the schema. Without it you have to hope that you had zero bugs while collecting the terabytes of data.

Re: Was MongoDB Ever the Right Choice?

#57

Post by TimFogarty » Wed, Mar 27, 2019, 11:06 AM UTC

Great article - it's definitely vital to fully understand the tradeoffs of any technology you choose, and not just going with the latest fad.

I work at MongoDB, so I do want to mention that MongoDB has changed a lot over the past few years. MongoDB now has multi-document ACID transactions. Also, schema validation means you can enforce a strict data structure if you want. On top of that there have been improvements in data durability and consistency (the Jepsen tests are now integrated into the MongoDB test suite).

As mentioned in the article MongoDB has matured a great deal. It's far more mature and fully-featured in 2019 than it was in 2012.

Re: Was MongoDB Ever the Right Choice?

#58

Post by marcodave » Wed, Mar 27, 2019, 11:19 AM UTC

giornogiovanna wrote: post #28

gfody wrote: post #19

Earlier quoted context omitted.

Mongo's debut was well timed to ride the JSON crazewave.

Sorry for my ignorance, but what JSON craze?

after 2010 there was also the surge of single page application frameworks a-la Angular.js, my take is that having a JSON-native database with REST interface meant that anybody could whip up a nice angular frontend with Mongo as its only backend. Sure, business logic in the browser, antipatterns all over the place, security be damned, but if it meant that the business could live at all, then people got on with it.

Re: Was MongoDB Ever the Right Choice?

#59

Post by huffmsa » Wed, Mar 27, 2019, 11:20 AM UTC

Great for prototyping, and cases where you can contain everything in one document, but as soon as you're referencing model2 from model1, it's probably time to switch to a SQL based DB.

I know MongoDB supports references, but it's like using a flathead driver for a Phillips head screw.

Re: Was MongoDB Ever the Right Choice?

#60

Post by scarface74 » Wed, Mar 27, 2019, 11:23 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…

Lack of ability to enforce structure - when using Mongo with C# you’re working with a strongly typed Collection where types are enforced by the compiler when you add records and a strongly type IMongoQueryable when you query the database.

Custom query language - I bet he also hates ElasticSearch. But again, using C# and the first party Mongo LINQ library, you are working with LINQ - the same built in C# query language that every C# developer should be familiar with. One of the requirements I wrote when I was hiring contractors for a Mongo based project was familiarity with Entity Framework. Even though we wouldn’t be using EF, if they knew it, it would be seamless to transition over to Mongo/LINQ.

Edit:

And as a side note, creating your “application defined schema” from a pre-existing JSON document, is a simple matter of copying the JSON to:

http://json2csharp.com/