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

171–180 of 323 posts

Re: Amazon DocumentDB, with MongoDB compatibility

#171

Post by scarface74 »

alittletooraph wrote: post #166
scarface74 wrote: post #135

Earlier quoted context omitted.

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.

You're right they're not profitable — and neither is MongoDB — but the point is that AWS launched an Elasticsearch service 3 years prior to Elastic having a very successful IPO supported by stellar metrics (also found in the SEC filing you linked). So the statements made at the beginning of this thread are probably a bit premature.

Only in tech do people think that a money losing company is “successful” because they were able to convince investors to buy stock instead of defining success as having a business model where income is greater than expenses.

In reality long term profitability is the only metric that matters for a corporation

Re: Amazon DocumentDB, with MongoDB compatibility

#172

Post by pritambaral »

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.

> 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 and wire protocols are awful (looking at you, Oracle[2]) shouldn't mean one should go running to the hills, let alone to JSON.

----

1: https://www.postgresql.org/docs/current/protocol.html

2: https://noss.github.io/2009/04/28/reverse-engineering-oracle...

Re: Amazon DocumentDB, with MongoDB compatibility

#173

Post by kerng »

Analemma_ wrote: post #87
tootie wrote: post #22

Earlier quoted context omitted.

Azure has been running a Mongo-compliant DB under their Cosmos umbrella for quite a while. It's not clear to me that either Azure or AWS are actually running Mongo software under the hood or rather a proprietary DB that uses the Mongo wire protocol. https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb-int...

Doesn’t Azure also have a not-Mongo service also called DocumentDB? Is this the same code? These cloud services are confusing enough when they don’t borrow each other’s names.

Correct. They added more gateway compat layers in addition to Mongo and renamed it from DocumentDB to Azure CosmosDB then.

Re: Amazon DocumentDB, with MongoDB compatibility

#174

Post by drb91 »

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…

MongoDB is not horizontally scalable either is it?

Re: Amazon DocumentDB, with MongoDB compatibility

#176

Post by drb91 »

meddlepal wrote: post #148
Lazare wrote: post #127

Earlier quoted context omitted.

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…

Could Mongo or other companies use the Oracle v. Google precedent regarding API copyright to extract money from competitive vultures like Amazon?

Even if true this would not be a win for open software.

Re: Amazon DocumentDB, with MongoDB compatibility

#177

Post by [deleted] »

KaoruAoiShiho wrote: post #144
SpicyLemonZest wrote: post #116

Earlier quoted context omitted.

There's no secret formula to stop people from competing with you. If MongoDB Inc is successful, it should be because they run a good document-database-as-a-service people want to use, not because they earn indefinite seigniorage from launching a popular open source project.

But isn't it wrong to place all economic value in the hosting layer rather than the software layer?

[deleted]

Re: Amazon DocumentDB, with MongoDB compatibility

#178

Post by koolba »

athrun wrote: post #156
gazzini wrote: post #137

Earlier quoted context omitted.

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

> I'm not sure I fully grasp the problem (why doesn't DynamoDB need to be accessed from within a VPC?) This is due to the fact that DynamoDB's query API is a standard AWS API which means granular internal/external access can be provided through IAM mechanisms (ie: roles, temporary tokens, federation, etc.). On the contrary, to access RDS, Redshift or DocumentDB you would use standard ODBC/JDBC/Mongo facilities, which…

Not quite. It’s not the auth mechanism or even the wire protocol. The issue is to accesS traditional resources in a VPC you need to have an IP address within the VPV to route network traffic to/from it. It’d be the same if you ran a DB on and EC2 instance or even ran your own DynamoDB clone with no auth.

AWS services don’t have that issue because they’re accessible from anywhere on the network, even through an internet gateway / internal NAT.

Re: Amazon DocumentDB, with MongoDB compatibility

#179

Post by talawahtech »

evil-olive wrote: post #170
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...

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.

1. https://youtu.be/yvBR71D0nAQ

Re: Amazon DocumentDB, with MongoDB compatibility

#180

Post by mrep »

drb91 wrote: post #174
mrep wrote: post #167

Earlier quoted context omitted.

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…

MongoDB is not horizontally scalable either is it?

Yes it is: https://docs.mongodb.com/manual/sharding/
Post reply on HN