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

61–70 of 323 posts

Re: Amazon DocumentDB, with MongoDB compatibility

#61

Post by misframer »

ahachete wrote: post #50

My bet is that it is built on top of Aurora PostgreSQL. By looking at the "Limits" section ( https://docs.aws.amazon.com/documentdb/latest/developerguide... ), identifiers are limited to 63 characters and the same characters that PostgreSQL limits identifiers to; and a collection size limit of 32TB, coincidentally maximum PostgreSQL table size. Edit: I can confirm: does not allow the UTF-8 null character in strings:…

I think they're built on a common storage system, just like the MySQL compatible version too.

Re: Amazon DocumentDB, with MongoDB compatibility

#62

Post by dfischer »

anonytrary wrote: post #20
dfischer wrote: post #12

Earlier quoted context omitted.

DynamoDB has specific requirements on how data is partitioned. You have to do upfront planning on how you access your data based on keys. Mongodb is more flexible in this regard. I’m sure there’s other big differences but this is the biggest to my experience with both.

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…

I get what you're saying now. I assumed it was a managed mongoDB – I should have paid more attention. Thanks!

Re: Amazon DocumentDB, with MongoDB compatibility

#63

Post by uberduper »

orestes910 wrote: post #34

Is it really THAT hard to to run on prem/cloud because of the "complexity that comes with setting up and managing MongoDB clusters at scale"? The documentation is strong, it was built with horizontal scalability in mind. I don't see the struggle.

Yes. Sharded mongo has many pitfalls that can challenge your devs, dbas and devops people. Mongo api without all the mongo scaling problems is pretty awesome.

Re: Amazon DocumentDB, with MongoDB compatibility

#64

Post by aynsof »

rjbwork wrote: post #5
vaer-k wrote: post #2

Finally an AWS service where the name makes sense and describes what it is. I hope this is the start of a trend.

I love Azure for this. The names are almost all extremely straightforward. There are a handful that have made the jump from confusing to straight forward, and a handful that have made the jump from straightforward to confusing (CosmosDB, formerly DocumentDB, chiefly comes to mind).

Except for the fact that Azure names seem to change once per year.

Our Azure SA was giving us a presentation and actually got confused himself. "So that's TFS... I mean VSTS... Actually wait, it's Azure DevOps now?"

Re: Amazon DocumentDB, with MongoDB compatibility

#65

Post by jkchu »

napsterbr wrote: post #15
vaer-k wrote: post #2

Finally an AWS service where the name makes sense and describes what it is. I hope this is the start of a trend.

Surprised they didn't go with a 3-letter acronym. AWS DDB. Recently I made a typo on a formal document. Wrote "AMI" when I meant to to write "IAM". Oops.

I would have preferred AWS D2B.

Re: Amazon DocumentDB, with MongoDB compatibility

#66

Post by kstrauser »

orf wrote: post #37
a13n wrote: post #35

Earlier quoted context omitted.

Yeah, that's pricy. They're definitely not going after early-stage startups then. But if you have a medium-sized data set (eg. 50+ GB), this is definitely competitively priced. More RAM, storage, compute than Mongo Atlas and Compose for less money. Here's hoping they introduce cheaper options!

50GB is a really small data set.

A recent work Slack chat had a dev asking what a particular table contained. They were going through our data inventory and found a randomly-named table 18TB in size. When I ran "select count()" against it, I got back 5,325,451,020,708 rows (that's a copy-and-paste).

50GB isn't trivial, but it's utterly manageable.

Re: Amazon DocumentDB, with MongoDB compatibility

#67

Post by orf »

djohnston wrote: post #48
orf wrote: post #37

Earlier quoted context omitted.

50GB is a really small data set.

in my experience it qualifies as "medium"

If it can be stuck in a sqlite database and run on a developer laptop, then no, it is not medium by any standard.

Please elaborate why you think 50Gb is anything other than a small dataset that can fit in memory on any half-decent server though.

Re: Amazon DocumentDB, with MongoDB compatibility

#68

Post by Aeolun »

ma2rten wrote: post #56
dstaley wrote: post #18

If I'm reading the pricing page correctly, DocumentDB would run a _minimum_ of $200/month. That's for the smallest instance and no storage or I/O. Kind of steep if you ask me.

Seems to be really aimed at businesses which want to get off of MongoDB desperately.

So they’ll have a huge target market.

Re: Amazon DocumentDB, with MongoDB compatibility

#69

Post by Aeolun »

kstrauser wrote: post #66
orf wrote: post #37

Earlier quoted context omitted.

50GB is a really small data set.

A recent work Slack chat had a dev asking what a particular table contained. They were going through our data inventory and found a randomly-named table 18TB in size. When I ran "select count()" against it, I got back 5,325,451,020,708 rows (that's a copy-and-paste). 50GB isn't trivial, but it's utterly manageable.

It seems a bit wrong if you have a 18TB table but no idea what it contains...

Re: Amazon DocumentDB, with MongoDB compatibility

#70

Post by abrookewood »

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 (and will pay for!) won’t even move the needle in terms of their effort."

[0] http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts...

Post reply on HN