Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amazon DocumentDB, with MongoDB compatibility

aws.amazon.com

Post reply on HN
Print view View original

181–190 of 323 posts

Re: Amazon DocumentDB, with MongoDB compatibility

#181

Post by karmelapple »

WorldMaker wrote: post #24
anonytrary wrote: post #11

Earlier quoted context omitted.

Out of curiosity, what use cases did you have for CouchDB that weren't feasible with MongoDB?

In my case, at least, PouchDB is still a lot handier of an offline-first mobile-capable DB than just about anything else, and because it speaks the CouchDB replication/sync API that still leaves a lot of use cases where CouchDB is more feasible. (It would be great to have more document DBs converge on a replication/sync API for offline-first applications. I've voted on the UserVoice suggestions to CosmosDB on the ide…

Same here. We love how replication is built in to CouchDB from the ground up.

I wish MongoDB, which seems to still have more love for it in the world than CouchDB/Cloudant, would have that replication built-in.

Re: Amazon DocumentDB, with MongoDB compatibility

#182

Post by senderista »

mrep wrote: post #167
talawahtech wrote: post #126

Earlier quoted context omitted.

It sounds like it is built on top of the Aurora storage subsystem that is used by both Aurora MySQl and Aurora Postgres[1]. I kinda expected them to build it on top of DynamoDb's backend and provide the same kind of "Serverless" on demand experience, but I guess the architecture didn't fit, or maybe this was just faster. 1. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

Definitely because it was faster. Amazon's strategy is to launch new features ASAP and then rely on everyone having to be on-call to fix shit when it inevitably breaks in prod because they rushed to launch. I will admit that while their "operational excellence" is shit, the security engineers do have quite a bit of power to block launches so their security isn't as bad as the reliability. However, the fact that write…

I was there for the launch of a major AWS service where they had an entire separate team working on the next iteration since well before launch (because the initial design wasn’t even intended to be sustainable). They are happy to incur technical risk (and in this case, to eat major losses in hardware costs) in order to be first to market.

Re: Amazon DocumentDB, with MongoDB compatibility

#183

Post by [deleted] »

throwaway204 wrote: post #136
zepolen wrote: post #104

Earlier quoted context omitted.

> IMHO a JSON-over-HTTP API No no no no, again no. We don't need yet another shitty query language bolted onto one of the most error prone and annoying to type serialization formats while transmitting data on top of a by default stateless protocol that makes no sense for a database. I'm sick of it. SQL. The same queries will work in 95% of the case on any SQL db. There is a driver in almost every language that is rob…

Sure, keep the SQL. Just make it a field in a JSON POST payload, and send the results back as JSON. The "drivers in almost every language" suck. They all suck. I've never seen a SQL driver and wire protocol that was not awful in some way. The statefulness is part of what makes them awful. We have better ways to keep track of state now.

[deleted]

Re: Amazon DocumentDB, with MongoDB compatibility

#184

Post by kemitchell »

cortesoft wrote: post #130
dman wrote: post #79

Earlier quoted context omitted.

What is the way out? Would love to hear from people.

The linked blog sorts of hints at it, but the way out is to not try to build business models around people paying directly for some sort of license. Successful open source does not require someone making money off developing it. It is successful when it is something that helps a profitable company but is not core to their business; then, they benefit from making it open source and having everyone contribute to its de…

SSPL, the new license for Mongo, isn’t written to force developers already using Mongo to build apps to pay license fees. It’s designed to stop cloud companies from offering managed Mongo with closed service rigging.

I suppose Mongo could sell exceptions to cloud companies, the way other companies dual license libraries or frameworks. But even Mongo’s bread and butter paid deals aren’t primarily about alternative license rights for open code. They’re about closed add-on code and services, as you describe.

Dual licensing, on its own, is an old and plenty good model for funding development of open source code. I’ve heard wind of dual licensing deals done decades and decades ago, maybe even before GPLv2.

Re: Amazon DocumentDB, with MongoDB compatibility

#185

Post by talawahdotnet »

I am pretty frustrated that DB services like Aurora, and now DocumentDB are still limited to last-gen instance types like r4 instead of the latest instances like r5 and t3 which have marked improvements in terms of CPU and networking performance.

I wonder if it is that they just have a so much r4 inventory left that they are forcing us to use it or if they haven't fully integrated/validated the latest instance types with their custom storage backend.

Re: Amazon DocumentDB, with MongoDB compatibility

#186

Post by kemitchell »

DannyBee wrote: post #131
dman wrote: post #79

Earlier quoted context omitted.

What is the way out? Would love to hear from people.

Stop assuming the value in the development ecosystem belongs to you (and should be extractable as money). It doesn't. Realistically, the next step you will see, unless something changes, is that they will start going after people for API duplication. They have precedent (currently) on their side in the US. None of the reasonable players will touch this, but you can be sure some VC backed "open source" player will be…

Arguendo: Cloud providers seem to be assuming that the development ecosystem belongs to them. They are extracting tons of money. Why don’t they just accept that hosting storage and compute will become commodity services, driving margins toward zero, and give up?

Plenty of reasonable players will touch Oracle v. Google going forward. I’m as eager to debate the opinion as other counsel. But procedural history demonstrates directly, not theoretically, that it’s effective against tech giants.

In the matter of API Owner v. Google, if API Owner touches that “third rail”, Google gets the shock.

Re: Amazon DocumentDB, with MongoDB compatibility

#187

Post by evil-olive »

talawahtech wrote: post #179
evil-olive wrote: post #170

Earlier quoted context omitted.

DynamoDB is written on top of MySQL (more specifically, MySQL's storage engine, not the query engine) so using Aurora which has a newer design would make sense.

Saying DynamoDB is built on top of InnoDB is a pretty big oversimplification of a much more complex distributed system[1] and for all we know they could have switched out the low level the storage engine on the backend to something like RocksDB or WiredTiger. The Aurora storage subsystem is much more limited in terms of horizontal scalability and performance, they probably chose it because it was a better/quicker fit…

Yeah, I used to work on DynamoDB, I know it's more complicated (much more complicated than that video makes out - their code quality was atrocious, like 2000-5000 line Java classes in 3 or 4 deep inheritance hierarchies; no unit tests, only "smoke tests" that took 2 hours to run and were so prone to race conditions that common advice was to close everything else on your machine, run them, then leave them alone while you went to meetings)

There was work underway at the time I left to replace InnoDB with WiredTiger. It seemed to be very slow going, and I suspect WiredTiger being acquired by 10gen had a part in it. They also had only 1-2 engineers on the project of ripping out MySQL and replacing it, in a long-lived branch that constantly dealt with merge conflicts from more active feature development happening on mainline.

Aurora, simply by virtue of being newer and learning from DDB's mistakes (in the same way DDB learned from SimpleDB and the original Dynamo) probably has better extension points for supporting (MySQL, Postgres, Mongo) in a sane way.

Re: Amazon DocumentDB, with MongoDB compatibility

#188

Post by kemitchell »

api wrote: post #155
abrookewood wrote: post #70

I was reading a post [0] by Brian Cantrill that predicted this would be the result of licences like the SSPL. I instinctively disagreed with him, but it turns out he was right: "The cloud services providers are currently reproprietarizing all of computing — they are making their own CPUs for crying out loud! — reimplementing the bits of your software that they need in the name of the service that their customers want…

Years ago I realized that a hidden driver for the growth of cloud is this. The cloud is DRM, and almost uncrackable DRM at that since you have neither the code nor the hardware.

If you haven’t already, do a search on FSF.org for “service as a software substitute”.

Re: Amazon DocumentDB, with MongoDB compatibility

#189

Post by kemitchell »

jchw wrote: post #4

Seems like this is likely to be the real result of licenses like the SSPL. Not even a terrible outcome if the different implementations remain relatively compatible.

I’d be surprised to learn that AWS started and launched this project since the SSPL announcement. I suspect they began when latest Mongo was still AGPL, with no sign of impeding change.

Re: Amazon DocumentDB, with MongoDB compatibility

#190

Post by talawahdotnet »

evil-olive wrote: post #187
talawahtech wrote: post #179

Earlier quoted context omitted.

Saying DynamoDB is built on top of InnoDB is a pretty big oversimplification of a much more complex distributed system[1] and for all we know they could have switched out the low level the storage engine on the backend to something like RocksDB or WiredTiger. The Aurora storage subsystem is much more limited in terms of horizontal scalability and performance, they probably chose it because it was a better/quicker fit…

Yeah, I used to work on DynamoDB, I know it's more complicated (much more complicated than that video makes out - their code quality was atrocious, like 2000-5000 line Java classes in 3 or 4 deep inheritance hierarchies; no unit tests, only "smoke tests" that took 2 hours to run and were so prone to race conditions that common advice was to close everything else on your machine, run them, then leave them alone while…

Interesting, how long ago was that? I would be curious to know if the WiredTiger switch ever happened, and what that support relationship looks like not given the contentious relationship between MongoDB and AWS. The old Wired Tiger Inc website[1] still lists AWS as a customer.

Then again, the relationship between AWS and Oracle is even more contentious and Aurora MySQL is one of AWS's most popular products so I don't think they are terribly worried about building on competitor's technologies.

1. http://www.wiredtiger.com/

Post reply on HN