Was MongoDB Ever the Right Choice? • Hacker News Board

Re: Was MongoDB Ever the Right Choice?

#121

Post by codepope » Wed, Mar 27, 2019, 1:32 PM UTC

gwbas1c wrote: post #120

I found developing with MongoDB a pleasure, until its lack of transactions became problematic. Fortunately, the project I was working on didn't go very far. At the time, I concluded that MongoDB was the "Visual Basic of Databases." It was very easy get something simple running, much like Visual Basic classic was. Quite honestly, something ACID-compliant with a MongoDB-like API is really needed for small-scale project…

It's called MongoDB. ACID multi-document transactions, here, now, introduced in version 4.0. https://www.mongodb.com/transactions

Re: Was MongoDB Ever the Right Choice?

#122

Post by rooam-dev » Wed, Mar 27, 2019, 1:34 PM UTC

wefarrell wrote: post #118

rooam-dev wrote: post #111

Earlier quoted context omitted.

Could you elaborate please on the untold pain part? We use Mongo as our primary storage at the moment and I would like to avoid painful issues. Thank you in advance. On the other note, I keep seeing people recommending Postgres, but to me that is apples vs. oranges. Just because it has json storage doesn't make it a replacement. How much effort and money a company needs to keep a replicated Postres cluster vs. Mongo?…

It’s been a while since I’ve worked with Mongo but I remember having significant performance issues with indexed arrays, particularly for compound indexes. They weren’t solvable by any tweaking, it was a fundamental problem with that feature, to the point where we wondered why they allowed it at all. It’s possible they’ve fixed it by now.

Thanks, we'll add to our "eye keeping" list.

Re: Was MongoDB Ever the Right Choice?

#123

Post by james-mcelwain » Wed, Mar 27, 2019, 1:34 PM UTC

skywhopper wrote: post #106

As with anything, it depends on the project. I’m working on an internal service that uses Mongo as a single merged cache for a lot of mostly unchanging data from various data stores with different credentials for each, which are distributed around the world, that we otherwise have to fetch through multiple comparatively slow API calls. For this, Mongo is perfect: no messing with schemas as they change, unannounced, f…

Elasticsearch can index documents dynamically, and doesn't require a schema to create an index. Dynamic data types for fields may not always produce what you want, but it's possible to define a partial schema for the fields that are important and let Elasticsearch handle the rest.

The query language is verbose but I would hesitate to call it a nightmare. You can always search using the Lucene query language, and SQL support is landing sometime soon.

Re: Was MongoDB Ever the Right Choice?

#124

Post by duncan-donuts » Wed, Mar 27, 2019, 1:35 PM UTC

skywhopper wrote: post #106

As with anything, it depends on the project. I’m working on an internal service that uses Mongo as a single merged cache for a lot of mostly unchanging data from various data stores with different credentials for each, which are distributed around the world, that we otherwise have to fetch through multiple comparatively slow API calls. For this, Mongo is perfect: no messing with schemas as they change, unannounced, f…

I used mongo years ago with pretty much the exact same use case and it was awesome. I moved companies a few years ago and they were using mongo as well, but for services that were 95% relational. It was awful. We no longer use mongo for anything

Re: Was MongoDB Ever the Right Choice?

#125

Post by JustSomeNobody » Wed, Mar 27, 2019, 1:36 PM UTC

Man, I remember the Mongo craze. You couldn't have a rational discussion about databases with some of the most rabid supporters. I made a comment on a post yesterday about tech having those few early and loud supporters who shut down any conversation that doesn't support their chosen technology. The Mongo craze was like that early on. It was really frustrating not being able to look at other databases when everyone was chanting "Mongo! Mongo!" Thankfully tech has moved on to Kubernetes and React and microservices and now we can finally have a rational discussion about databases.

Re: Was MongoDB Ever the Right Choice?

#126

Post by ajcodez » Wed, Mar 27, 2019, 1:41 PM UTC

scarface74 wrote: post #116

ajcodez wrote: post #107

Earlier quoted context omitted.

> And then what happens when they add a field to the form and the table already had a million rows? Maybe I don’t follow. You would insert a row into the fields table. Millions of rows should be fine. > I asked “what would have bought us”. I don’t know. None of this matters really, as long as the service works.

You said doing a “create table on the fly”. So if they needed to add or modify a field, you would have to do an alter table.

I don’t think we’re on the same page here. It’s all good.

Re: Was MongoDB Ever the Right Choice?

#127

Post by fouc » Wed, Mar 27, 2019, 1:42 PM UTC

teh_klev wrote: post #80

k__ wrote: post #67

Earlier quoted context omitted.

I worked in such a company too. Every time we wanted to do something new a founder would say "Domino can do this!" and then they would spend the whole weekend setting it up for what we were trying to do. All because we were some kind of IBM partner and they wanted to please the big wigs.

Once upon a time in a job far away, about 15% of my time was allocated to being the company sysadmin, and as all good sysadmins do, reduced that time to about 5%.....until.... One day, and despite my protests, I had to bin our perfectly fine and well maintained/loved Exchange server for fricken Notes/Domino just because one of the investors had some free licenses. After the migration, everyone hated it and I was pers…

I wonder if that poor sod will be an HN reader too, and end up seeing your post

Re: Was MongoDB Ever the Right Choice?

#128

Post by jandrewrogers » Wed, Mar 27, 2019, 1:49 PM UTC

TimFogarty wrote: post #61

bonesss wrote: post #53

Earlier quoted context omitted.

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.

The Jepsen tests [1] have been run against MongoDB - while older versions presented edge-case opportunities for data loss, that's no longer the case with recent versions. The Jepsen tests also specifically test sharded clusters. From Aphyr's report: > MongoDB 3.6.4’s sharded clusters offer comparable safety to non-sharded deployments. These tests are now integrated into MongoDB's regular test suite. Maybe MongoDB was…

FWIW, the data loss I was referring to happened on a single node. There may have been issues in a distributed environment as well but we never got there.

Re: Was MongoDB Ever the Right Choice?

#129

Post by splatcollision » Wed, Mar 27, 2019, 1:51 PM UTC

_Marak_ wrote: post #70

It's been over 10 years and CouchDB has not let me down once. Still using it in production everyday.

Came here and searched for "couch". Love it to death and have used it at medium large scale with very large custom indexes.

Once you understand the way that views and map/reduce work, it's super powerful for doing large scale statistics on data sets quickly. Only thing that I wish for is a Mongoose adapter for couchdb so I can use it as a backend for when an open-source project wants to use MongoDB (Looking at keystone.js for example)...

Re: Was MongoDB Ever the Right Choice?

#130

Post by gdulli » Wed, Mar 27, 2019, 1:51 PM UTC

> Bandwagon effect – Everyone knows this, and yet it is still hard to fight against. Just make sure that you’re choosing a technology because it solves real needs for you, not because the cool kids are doing it.

> Mere newness bias – Many software developers tend to undervalue technologies they have worked with for a long time, and overvalue the benefits of a new technology. This isn’t specific to software engineers, everyone has the tendency to do this.

> Feature-positive effect – We tend to see what is present, and overlook what isn’t there. This can wreak havoc when working in concert with the “Mere newness bias”, since not only are you inherently putting more value on the new technology, but you’re also overlooking the gaps of the new tech.

This is so much what I've always wanted to and tried to say on the topic. Adopting new technologies thoughtfully rather than reflexively is something I'd love to find out about a team before joining one again.