Live data from Hacker News

MongoDB gets support for multi-document ACID transactions

techcrunch.com

111–120 of 245 posts

Re: MongoDB gets support for multi-document ACID transactions

#111
post #6

MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. The RethinkDB retrospective[0] contains a lot of insight into how MongoDB has succeeded despite being vastly inferior on a technical level back when it first launched. I have to admit them a certain respect for executing their strategy so successfully. Choice quote: Every t…

> I have to admit them a certain respect for executing their strategy so successfully.

But be certain not to conflate your respect as a business strategist with your judgment as a mindful developer. To speak clearly: By systematically playing a weak spot of ours [1] they have used countless of small teams as a stepping stone to sell their business contracts to large players, while hurting a lot of these small teams with an (at the time) inappropriate product for their needs. And through these huge costs they still made a product that is inferior to one that was designed properly.

As a community (both as a startup, as well as a developer community) we should resent these tactics and try to find ways to protect us against players that abuse the common good of mindshare. And lest you say, that is the price you have to pay to at all get a product like MongoDB in harsh business environments: We could also lobby for open source funds that are organized like research funds, producing fundamental technology that benefit everyone. Not every technology fits the model of for-profit startup innovation.

[1] Our community has very little defenses against marketing that comes from our midst, aiming to produce the (false) impression that a disproportionate amount of our fellows have evaluated the product and found it to be excellent. See https://www.nemil.com/mongo/3.html for a discussion about MongoDb specifically (HN thread: https://news.ycombinator.com/item?id=15124306 )

Re: MongoDB gets support for multi-document ACID transactions

#112
post #2

Next up will be SQL compliance, and we'll be back to a relational database. I'm curious as to what the impact to speed will be, and what the use cases for these types of databases is now that the major SQL players support JSON.

Just remember, SQL is and always was "not only relational" - a play on the, should be long dead and buried acronym NoSQL (IMHO). Structured query language - I know for a fact from actually doing it (see Cache database, Hadoop schemaless SQL, even a product I worked on that was SQL to Mongo, heck the SQL standard itself) - guess what - it works with object/document stores too! Mongo could have implemented SQL on top o…

On this point, the datastores that have insisted on using a query language that isn't SQL have always seemed to just be attempts at setting up walled gardens. Plenty of people have extended SQL when their needs required it (MySQL, PostgreSQL, Oracle, TSQL/MSSQL) but intentionally rejecting the basic format of SQL queries just seems like an attempt to setup a barrier to ever move off your DBMS.

Speaking as someone who ported an application from MySQL to MSSQL there is still a lot of work required to remove those custom extensions, but the core of what you're doing can remain the same.

Re: MongoDB gets support for multi-document ACID transactions

#113
post #6

MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. The RethinkDB retrospective[0] contains a lot of insight into how MongoDB has succeeded despite being vastly inferior on a technical level back when it first launched. I have to admit them a certain respect for executing their strategy so successfully. Choice quote: Every t…

There is a trend I noticed where I work. Most people that “get it right” the first time around do not get any recognition whatsoever. It is the people that screw up, release with big flaws that the customer then pressures the company about, that are heralded as heroes and bacon savers when the fix those flaws. After 3 years and as many releases.

That is true in life in general, not just work place.

Nobody cares about people who are healthy all their life. But someone who suddenly realizes they need to eat better and exercise, and they do, they are applauded. They are defended too, if they go back to old ways. And so on...

Re: MongoDB gets support for multi-document ACID transactions

#114
post #6

MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. The RethinkDB retrospective[0] contains a lot of insight into how MongoDB has succeeded despite being vastly inferior on a technical level back when it first launched. I have to admit them a certain respect for executing their strategy so successfully. Choice quote: Every t…

A database which utterly fails the Jepsen test should not be considered for production. It might be good enough for a cache, but trusting it with real data is reckless.

Re: MongoDB gets support for multi-document ACID transactions

#115

Every time I hear about some NoSQL "breakthrough" that existed a while ago in SQL databases, I can't help but feel underwhelmed. In general, I'm convinced SQL is like Constitutional Democracy; it's not perfect, but it's better than any alternative humans have come up with so far.

The consistency is really nice too. I've always hated the fact that column declarations are the first portion of a query and wanted them at the end but... I'd rather be slightly disappointed all the time than occasionally need to rewrite huge swathes of queries if we're changing DBMSs

Re: MongoDB gets support for multi-document ACID transactions

#116
post #84

I keep hearing about how people have been burned by Mongo but nothing specific. Does anyone care to give any specifics?

http://hackingdistributed.com/2014/04/06/another-one-bites-t...

From what I'm reading they were trying to do things with Mongo that it wasn't designed to do around transactions. If you have a schema that is well defined and doesn't change frequently, why use a nosql database?

I chose Mongo for a relatively large project that I was responsible for because I knew the schema would change frequently, we didn't have a need for transactions and honestly we hardly ever update documents. We insert and replace.

I also had enough sense to set my Write concerns appropriately.

My choice was also informed by a preexisting project that the company was using that had close to 150K new documents a day with basically the same semantics as the one we started.

Re: MongoDB gets support for multi-document ACID transactions

#117

Most software developers have a negative impression of MongoDB, based on the many flaws that it had back in 2010. Among the people who did the best job of documenting those flaws, was Kyle Kingsbury, in his Jespen series: https://aphyr.com/posts/284-jepsen-mongodb But it is important to realize that the team at MongoDB has actually been working with Kingsbury, for several years now, and they have slowly and patiently…

I'm one of those people who come in and comment about MongoDB, positively. My first "stack" was LAMP, in 2012 when I learnt how to use it, it was:

- a JSON store that works well with NodeJS - a geospatial database (yea, it has what I need) that was "easier" to work with - a database that made it easier for me to change my schema (if you just throw data at it, garbage in, garbage out).

Over the years, I've followed development, and adopted new features to make my life easier.

- I was one of the people who were excited about full GeoJSON support in the 2.* days, because that's something I depended on. - I've tailed the oplog for as long as I remember (never needed Redis), and have been learning about change streams (announced in 3.6) with the hope of submitting a PR to Apache Beam to support them. - I adopted a lot of the aggregation framework (Asya Kamsky from MongoDB personally helped me a lot) - The last time I migrated data from MongoDB was when I turned on WiredTiger in 3.0.*

My little replica has been up for as long as I remember, the only time I have downtime is when restarting my server.

When I start a new project these days, I still go to Mongo, because what held true in its early days still holds. It's quick to get something started. Yeah, there's $lookups, transactions in future; I've just leveraged features as they become available. I have Postgres in my stack, which runs TimescaleDB and is a backing store for my Gitlab instance.

Would I use MongoDB professionally? It depends on the use-case. Over the past 2 years I've worked with Oracle, SAP HANA, Teradata, Hive+Impala, etc. From OLTP to OLAP, but once in a while when I find it quick to, I still use MongoDB, and when I have it my way, I don't later migrate elsewhere.

Re: MongoDB gets support for multi-document ACID transactions

#118

Mongodb can be quite a nightmare once you start requiring anything more than a 1:1 relationship, which is pretty much any kind of app that is doing anything meaningful. Having to resort to doing things like map/reduce for a simple group by / order is not the way to go IMO. I think you later truly realize the beauty of SQL once you get far down that rabbit hole. Initially I rode on the Mongo's NoSQL bandwagon when I s…

> Having to resort to doing things like map/reduce for a simple group by / order is not the way to go IMO.

Perhaps you are unaware, but that is a straw-man. That’s not how you’re supposed to with MongoDB. You’d use the aggregation framework:

db.sales.aggregate( [ { $group : { _id : null, totalPrice: { $sum: { $multiply: [ "$price", "$quantity" ] } }, averageQuantity: { $avg: "$quantity" }, count: { $sum: 1 } } } ] )

https://docs.mongodb.com/manual/reference/operator/aggregati...

https://docs.mongodb.com/manual/reference/operator/aggregati...

This has been the case since MongoDB 2.0, in 2012.

Re: MongoDB gets support for multi-document ACID transactions

#119

Mongodb can be quite a nightmare once you start requiring anything more than a 1:1 relationship, which is pretty much any kind of app that is doing anything meaningful. Having to resort to doing things like map/reduce for a simple group by / order is not the way to go IMO. I think you later truly realize the beauty of SQL once you get far down that rabbit hole. Initially I rode on the Mongo's NoSQL bandwagon when I s…

Do you have an ORM that can translate to good PG queries using JSON/JSONB functions? I would LOVE that in Java/on the JVM.

Re: MongoDB gets support for multi-document ACID transactions

#120

Earlier quoted context omitted.

No, it doesn’t work for that use-case. It would all need to happen within a single service in a single invocation. To enable transactions across network boundaries, you need to enable the transactional safety at the application/API level. And, for the record, one service per table is a terrible idea. It would have none of the benefits of a service-oriented architecture, while adding all the complexity and caveats of…

Except I've implemented it that way in highly visible, high traffic internal web applications that were lauded as some of the most successful transitions in company history in a very large corporation. So your argument is really legacy opinion and not relevant to micro-service architectures.

None of the things you've just said make any difference to the fact that it doesn't make sense and is a terrible idea.

I fail to see in what way my statements are "legacy" or not relevant to micro-services. My company (Cuvva, insurance in the UK) runs a "micro" service architecture and deals with these problems every day.

It is not possible to use DB-level locking/transactions across network boundaries. It's just as simple as that. It's not an opinion - it's a fact.

Post reply on HN