Live data from Hacker News

Dear MongoDB users, we welcome you in Azure DocumentDB

azure.microsoft.com

51–60 of 119 posts

Re: Dear MongoDB users, we welcome you in Azure DocumentDB

#51
post #14

AWS needs something like this. The missing piece for the AWS serverless story is a database that is suitable for writing real world applications. DynamoDB is far from suitable for that task, which leaves AWS serverless with no good database.

AWS has RDS - That's most certainly a database suitable for writing real world applications as its MySQL. Does serverless somehow mandate a non SQL solution?

RDS also supports PostgreSQL, SQL Server, Oracle, Aurora and MariaDB

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcom...

Re: Dear MongoDB users, we welcome you in Azure DocumentDB

#52
post #14

AWS needs something like this. The missing piece for the AWS serverless story is a database that is suitable for writing real world applications. DynamoDB is far from suitable for that task, which leaves AWS serverless with no good database.

AWS has RDS - That's most certainly a database suitable for writing real world applications as its MySQL. Does serverless somehow mandate a non SQL solution?

RDS is server based - you need to pay to have an instance running per hour. That's not serverless. That's "serverful".

Re: Dear MongoDB users, we welcome you in Azure DocumentDB

#53
post #52

Earlier quoted context omitted.

AWS has RDS - That's most certainly a database suitable for writing real world applications as its MySQL. Does serverless somehow mandate a non SQL solution?

RDS is server based - you need to pay to have an instance running per hour. That's not serverless. That's "serverful".

I'm not sure how that differs from Azure Document DB? I have no inside info on this, but, I'm pretty sure it runs on a server too.. In the specific context of databases used for "serverless", clearly there are servers involved, it's simply that your application and ops team doesn't manage them.

What I'm getting at is, a hosted DB is a hosted DB.. What makes SQL unsuitable for serverless?

Re: Dear MongoDB users, we welcome you in Azure DocumentDB

#54
post #52

Earlier quoted context omitted.

RDS is server based - you need to pay to have an instance running per hour. That's not serverless. That's "serverful".

I'm not sure how that differs from Azure Document DB? I have no inside info on this, but, I'm pretty sure it runs on a server too.. In the specific context of databases used for "serverless", clearly there are servers involved, it's simply that your application and ops team doesn't manage them. What I'm getting at is, a hosted DB is a hosted DB.. What makes SQL unsuitable for serverless?

Replying to myself here, I missed a key point.. the issue you raise is that you're billed per hour, even when it's unused? That makes some amount of sense, but any data storage is going to come with a per hour bill - either for the instance of it, or the data within it.

Anyway, my bad, I now see your point :)

Re: Dear MongoDB users, we welcome you in Azure DocumentDB

#55
post #50
post #39

Never looked at DocumentDB before. So if I get this straight, I can get a fully managed DB that can scale easily, but still have all the advantages and compatibility of a regular NoSQL like Mongo? I think that's a first, right?

Isn't it the same general idea as Amazon's DynamoDB?

So long as you skip over the costs if you want any kind of performance (you need to configure a "number of accesses per time period" with costs scaling alarmingly the higher you go)

Re: Dear MongoDB users, we welcome you in Azure DocumentDB

#56
post #19

Earlier quoted context omitted.

DynamoDB is effectively useless for querying, except perhaps for some sort of highly specialised application able to fit within the DynamoDB strange and arcane query model. What sort of database is effectively useless for querying? Also they need to ditch the really, really confusiong and limiting scaling model. For a database that advertises scaling as one of its key strengths, DynamoDB sure has a bad scaling story.

> What sort of database is effectively useless for querying? Cassandra, Riak, Voldemort, HBase, Bigtable, Azure Table Storage, and many other implementations of wide column stores have similarly limited querying. I'm also not sure what you mean by the limiting scaling model. I can go from 0 to 160k reads/second by turning a knob, and 160k is only the default limit (you can request higher limits). It is not a document…

The price for that 160k is horrifying though, esp. if the requirement is bursty rather than continuous.

Re: Dear MongoDB users, we welcome you in Azure DocumentDB

#57
Yes, except you can't do the most basic things with DocumentDB and it becomes very expensive very fast. Especially if you want multiple collections.

There's a lot lacking with DocumentDB, as evident from the feedback forum, that comparing it to Mongo is like comparing an infant to an adult. The infant might be cute, but it can't do a whole lot.

https://feedback.azure.com/forums/263030-documentdb/filters/...

Re: Dear MongoDB users, we welcome you in Azure DocumentDB

#58
We used to use DocumentDB, but switched to Azure Table Storage a while back. Did some benchmarking and DocumentDB was too slow for our needs (getting documents for a range between two epochs). Not sure if others experienced the same thing or if things have gotten better since then though.

Re: Dear MongoDB users, we welcome you in Azure DocumentDB

#59

I've been out of touch with Mongo for a while, but when did it stop being common practice to just hide :27017 behind a firewall with only your app's DB access layer (or, at most, a few nodes in the local subnet) talking to it?

> hide :27017 behind a firewall with only your app's DB access layer talking to it?

Because if you can do without it, why bother? Developing an access layer costs time and money. If you can leverage the DB features to do what you need, you can make you stack simpler and more maintainable.

Re: Dear MongoDB users, we welcome you in Azure DocumentDB

#60
post #47

Earlier quoted context omitted.

Using a service means trusting a service. Nothing wrong with either, it's a decision up to the consumer. I am just saying, in this specific case, should you trust Microsoft with your data? That's all.

https://www.microsoft.com/en-us/TrustCenter/Privacy/default.... If you don't trust MS you can trust one of the organisations that certified them for the strictest compliance and regulations in the public cloud space.

Sounds good. But how do you exactly verify those claims? Again, you can't. You are back to square 1: trusting Microsoft acts in good faith and acts in your best interest.
Post reply on HN