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

131–140 of 323 posts

Re: Amazon DocumentDB, with MongoDB compatibility

#131

Post by DannyBee »

dman wrote: post #79
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…

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 willing to touch this 3rd rail in exchange for a Series A.

Re: Amazon DocumentDB, with MongoDB compatibility

#132

Post by morpheuskafka »

I really wish this was serverless. Azure CosmosDB offers SQL and MariaDB interface against a serverless, pay for what you use database and DynamoDB is the only product of that class Amazon has. Even Aurora "serverless" appears to be little more than autoscale, and it requires an elastic IP which slows launch of lambdas since they have to connect to VPC.

Re: Amazon DocumentDB, with MongoDB compatibility

#133

Post by scarface74 »

erikig wrote: post #80
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:…

It would be nice if Amazon provided an API to access the data via SQL alongside the MongoDB API; I've seen quite a number of organizations migrate from mongo to Postgres once they get out of the rapid development phase. This would make that transition butter smooth.

Anecdote:

I led a C# project where we could seamlessly switch back and forth between Mongo and SQL Server without changing the underlying LINQ expressions.

We sent the expressions to the Mongo driver and they got translated to MongoQuery we sent the expressions to Entity Framework and they got translated to Sql Server.

Re: Amazon DocumentDB, with MongoDB compatibility

#134

Post by iamed2 »

morpheuskafka wrote: post #132

I really wish this was serverless. Azure CosmosDB offers SQL and MariaDB interface against a serverless, pay for what you use database and DynamoDB is the only product of that class Amazon has. Even Aurora "serverless" appears to be little more than autoscale, and it requires an elastic IP which slows launch of lambdas since they have to connect to VPC.

> it requires an elastic IP which slows launch of lambdas since they have to connect to VPC

Do you have any other info/links related to this?

Re: Amazon DocumentDB, with MongoDB compatibility

#135

Post by scarface74 »

alittletooraph wrote: post #93
XorNot wrote: post #74

I'm pretty sure this is going to kill Mongo as a company dead. With this in existence there's literally no reason to use Atlas. If they wanted to twist the knife they should get to work implementing a pass through migration option.

Have you heard of Amazon Elasticsearch Service, launched in 2015? Elastic is doing fine.

Elastic Co isn’t profitable by definition it isn’t “doing fine”.

From their SEC filing:

https://www.sec.gov/Archives/edgar/data/1707753/000119312518...

We have a history of losses and may not be able to achieve profitability or positive cash flows on a consistent basis. If we cannot achieve profitability or positive cash flows, our business, financial condition, and results of operations may suffer.

Re: Amazon DocumentDB, with MongoDB compatibility

#136

Post by throwaway204 »

zepolen wrote: post #104
throwaway204 wrote: post #32

Earlier quoted context omitted.

ES grew out of Lucene, which provided an inverted index of all the text in a document, with a bunch of NLP related features bolted onto that. While ostensibly designed to be developer friendly, ES had and still has a horribly hacked together API with bugs and mis-documented misfeatures all over the place. In my experience it's anything but developer friendly. But if all you need is a text index on a document store wi…

> 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.

Re: Amazon DocumentDB, with MongoDB compatibility

#137

Post by gazzini »

iamed2 wrote: post #134
morpheuskafka wrote: post #132

I really wish this was serverless. Azure CosmosDB offers SQL and MariaDB interface against a serverless, pay for what you use database and DynamoDB is the only product of that class Amazon has. Even Aurora "serverless" appears to be little more than autoscale, and it requires an elastic IP which slows launch of lambdas since they have to connect to VPC.

> it requires an elastic IP which slows launch of lambdas since they have to connect to VPC Do you have any other info/links related to this?

There's an enlightening graph in this post:

https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-lat...

I was surprised to learn this. When working in Lambda, you have to choose between a relational database & a responsive API. It seems inevitable that AWS will fix this soon, but apparently this is a significant architectural problem. As I understand it, RDS instances should (must?) be accessed from within a VPC, and anything inside of a VPC needs an IP address, so the Lambda function has to wait ~10 seconds on cold-start for the Elastic IP service.

The only workaround I've heard of is to setup a service, such as CloudWatch, to call your Lambda function every ~25 secs to keep it "warm", but this seems anti-thetical to the value proposition of serverless architecture in the first place.

Of course, you could "just" use DyanmoDB, but IMO the query language is really limited, and I'm not sure I fully grasp the problem (why doesn't DynamoDB need to be accessed from within a VPC?)

Re: Amazon DocumentDB, with MongoDB compatibility

#138

Post by talawahdotnet »

erikig wrote: post #80
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:…

It would be nice if Amazon provided an API to access the data via SQL alongside the MongoDB API; I've seen quite a number of organizations migrate from mongo to Postgres once they get out of the rapid development phase. This would make that transition butter smooth.

I doubt that they actually built this on top of Postgres. They probably just integrated the WiredTiger[1] storage engine used by Mongo with their Aurora storage subsystem.

I am however really hoping Amazon provides a MySQL 8.0 compatible version of Aurora with full support for its new hybrid SQL and Document Store interfaces[2] courtesy of the X DevAPI[3] and lightweight "serverless" friendly connections courtesy of the new X Protocol.

That way your don't have to choose just one approach, and you can have your data in one place with high reliability and durability.

My ultimate pipe dream would be that they also provided a redis compatible key/value interface that allows you to fetch simple values directly from the underlying innodb storage engine without going thru the SQL layer, similar to how the memcached plugin currently works[4]

1. https://github.com/wiredtiger/wiredtiger

2. https://mysqlserverteam.com/mysql-8-0-announcing-ga-of-the-m...

3. https://dev.mysql.com/doc/x-devapi-userguide/en/devapi-users...

4. https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached.htm...

Re: Amazon DocumentDB, with MongoDB compatibility

#139

Post by innocentoldguy »

aynsof wrote: post #64
rjbwork wrote: post #5

Earlier quoted context omitted.

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?"

I worked at Microsoft for a while and I swear most of their "upgrades" are nothing more than renaming things and juggling menu items around so people can't find them.

Re: Amazon DocumentDB, with MongoDB compatibility

#140

Post by kllvql »

LamaOfRuin wrote: post #119
mabbo wrote: post #106

Earlier quoted context omitted.

The correct pricing strategy of any product is "whatever the customer is willing to pay for it". If you feel the price is too steep for your use-case, then don't buy it.

That's rarely actually true for anyone that wants to operate for more than a short time period. There are significant costs to gouging your customers. Anything from it being illegal, to it encouraging competition and your customers being motivated to actively flee you and shit on your reputation. The correct pricing strategy for people that don't have a long term enforceable monopoly is "whatever most customers are w…

I think you've hit on what always bothers me about this sentiment. It is obvious that at any point in time you can charge the maximum customers are willing to pay, but that allows for disruption through the channels like competition. The opposite where you charge the minimum to continue providing the goods or services seems optimal, though, leads to a company with zero profits that is unattractive to investment. Is there any literature on how to identify the optimal point of "whatever customers are willing to reasonably happily pay"? Businesses successfully exist on many points in the spectrum of zero profits to most profits the market will bear, but I'd be interested in anything discussing optimality.

[Edit] Amazon employee working in Physical Consumer (not AWS). Asking out of personal curiosity.

Post reply on HN