Live data from Hacker News

Amazon DocumentDB, with MongoDB compatibility

aws.amazon.com

211–220 of 323 posts

Re: Amazon DocumentDB, with MongoDB compatibility

#212
post #202

Earlier quoted context omitted.

They always were the OK guys in that argument. Google invented a whole new VM and bastardized the language just to get out of a $1/device licensing fee for mobile uses. The Java ecosystem has been irreparably harmed by Dalvik and its lack of support for more modern versions of Java. On another note, anyone that doesn't think API design is a creative endeavor and worthy of protection probably has never made a great AP…

I also always found it amusing that people thought API design was not creative and protectable. Like, “how many ways can you do a date api”, and then turn around to look at the original java Date api, the Calendar api, JodaTime and JSR310.

An API is just a collection of facts of the form, "if the system gets input X, the system produces output Y". And facts shouldn't be copyrightable.

Re: Amazon DocumentDB, with MongoDB compatibility

#213

Earlier quoted context omitted.

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.

> I've never seen a SQL driver and wire protocol that was not awful in some way. Have you seen the PostgreSQL wire protocol[1]? I recently built a logical replication client driver for a project and found the protocol to be excellent. After looking at the documentation, I'm no longer limited to languages that have drivers for Pg, because I know how easy it'd be for me to just write one. Just because some SQL drivers…

An HTTP/JSON protocol doesn't have to replace the standard one. But having such a standard protocol makes sense in the age of web apps, particularly when NoSQL offerings that are perceived by the market as competitors (leaving aside whether they really are - perception matters more here) do that already.

Re: Amazon DocumentDB, with MongoDB compatibility

#214

Earlier quoted context omitted.

I think it is likely it was the other way around. MongoDB caught wind of what AWS was about to release and changed the license.

Does that even apply? This is api-compatible, but doesn't appear to be using any actual MongoDB code.

It seems like Amazon may think so, with this line:

> Amazon DocumentDB implements the Apache 2.0 open source MongoDB 3.6 API by emulating the responses that a MongoDB client expects from a MongoDB server

Re: Amazon DocumentDB, with MongoDB compatibility

#216
post #10

Earlier quoted context omitted.

SSPL style licenses only work if the software can't be cloned but that's a difficult assumption.

Operating systems, compilers, and web browsers come to mind. There are currently: * 4 independently-developed competitive compilers (gcc, clang, msvc, icc) * 4 independently-developed competitive operating systems (windows, macos, linux, and bsd --I'm grouping the BSDs as one since their source code has a common ancestor) * 3 independently-developed competitive browser engines, soon-to-be 2 (edgehtml, gecko, webkit)…

Throwing Chrome/Blink under WebKit is a pretty hard sell at this point. They’ve diverged enough that supporting one far from guarantees you’ll support the other. You might as well replace WebKit with KHTML in your list.

Re: Amazon DocumentDB, with MongoDB compatibility

#217

Earlier quoted context omitted.

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'…

3+ years ago, so it's entirely possible that things have changed since I left. I don't have any more recent information on the state of the system.

At least when I was there, the strong focus was always on adding new features (global & local secondary indexes, change streams, cross-region replication, and so on) to keep up with the Joneses (MongoDB et al).

Meanwhile, a bunch of internal Amazon teams were taking a dependency on it instead of being their own DBAs, and those teams didn't care that much about the whiz-bang features, they just wanted a reliable scale-out datastore that someone else would get paged about when some component failed.

Adding features at a breakneck pace while keeping up umpteen-nines reliability and handful-of-milliseconds performance meant tech debt and non-user-facing improvements, including WiredTiger, all got sidelined. Around the time I left, our page load was around 200 per week. That's one page every 50 minutes, 24/7, if you're keeping score at home.

Re: Amazon DocumentDB, with MongoDB compatibility

#218
post #127
post #79

Earlier quoted context omitted.

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

Ultimately, Cantrill put it well: > ...for those open source companies that still harbor magical beliefs, let me put this to you as directly as possible: cloud services providers are emphatically not going to license your proprietary software. I mean, you knew that, right? MongoDB Inc cannot make Amazon pay commercial license fees. That is not a thing that will happen. They have a lever in front of them with two posi…

Pricing for smaller workloads is better on MongoDB Atlas right now. The DocumentDB performance pays of for super large collections and really high read/write workloads.

Re: Amazon DocumentDB, with MongoDB compatibility

#219
There is a serious amount of weasel words in that statement. Implementing the Apache 2.0 API I think is just weasel words for "Works more or less with the MongoDB drivers" which is the only thing Apache 2.0 licensed that I know off and is obviously not the API which is the combination of the MongoDB wireprotocol and the commands supported by the MongoDB server.

Re: Amazon DocumentDB, with MongoDB compatibility

#220
post #33

Earlier quoted context omitted.

I was asking about DocumentDB, not MongoDB, but maybe I missed something. From their site: > Amazon DocumentDB implements the Apache 2.0 open source MongoDB 3.6 API by emulating the responses that a MongoDB client expects from a MongoDB server, allowing you to use your existing MongoDB drivers and tools with Amazon DocumentDB So, is this a "managed MongoDB" or is it a NOSQL AmazonDB that just implements the same API…

Sounds like the latter to me, they probably implemented it on top of one of their other DBs.

Lmao I was a bit afraid this might be some surface-level API wrapper around DynamoDB, in which case this is less cool than I thought. It doesn't seem to be the case at a first glance but I wish it was a bit more clear on the site exactly how this relates to DynamoDB, if at all.

Maybe I'll just have to read more about it. Hopefully the internal architecture gets away from DynamoDB-style partitioning.

Post reply on HN