Based on my previous post, Azure vs. Automatic weather station data service comparison, today, I want to write about the cost and power database of the sky blue universe database and Neptune. Today I will give an example, only comparing the NoSQL service provided by Azure and the automatic weather station.
For Sky Blue, the service provided by NoSQL is Sky Blue Universe Database. The universe database is the place to meet all your key-value, document and graph database needs. (If your cable company starts to provide a database, the universe database is what we want. Phone, TV, and the Internet are all bundled together. The price is very low. It sounds good, but the key value, file and chart prices are the same. Shut up, Take my money. In terms of automatic weather stations, we have a dynamic database for keys and documents, and Neptune for charts.
For the purpose of this article, I will try to price the simplest deployment to match the service. In other words, I am not going to delve into multi-regional or geo-replicated databases today. I will assume that we have 50GB of storage requirements for three database services: key-value, document, and graph. I will keep reading and writing the same, and do my best to keep everything equal.
Let's break it down. First of all, the universe database pricing.
Azure's pricing page seems simple. You pay for your storage and these things are called request units per second, or RU/s. The FAQ section of the universe database page explains the meaning of RU/s in simple terms. However, this reference page better the meaning of RU / s, and to understand this dimension is very important . This page also details the read data from the database universe fee lower than the cost of writing data. I will use one of the 4kb size examples, 500 reads and 500 writes, for a total of 4,150 RU/s. We will use it with a modest 50GB storage. The pricing calculator looks like this:
The fact that support is included with 99 is not shown in the figure. The availability of the local regional database is 99% (99. 999% for the multi-region database). It is also worth noting that the read service level agreement of the universe database is 10 milliseconds, and the write service level agreement is 15 milliseconds. If Azure cannot meet the service level agreement, you will get a point on the next bill.
Let's continue to discuss AWS. For this, we need to consider two services: Momentum Database and Neptune.
For dynamic databases, the pricing calculator requires more input. Similar to the universe database, we need to know the storage and expected reads and writes. But we also need to know the details about the expected throughput, the consistency model (obviously you paid 2 times more for "strong" consistency in the dynamic database), and how many requests for the dynamic database stream. The link shows that I I will use a dynamic database stream to implement my own form of replication across automatic weather station areas. Therefore, we will not include these in the pricing today. It looks like this:
One thing to note here is that the consistency model is a factor of price. For the universe database, there is no difference in the price based on the consistency model. I chose "strong" consistency here, and we should assume that I will deploy a universe database with strong consistency. It is also worth mentioning that the dynamic database stream is in preview, and the first 25 million requests are free. Finally, I split the read/write throughput into 80/20.
Oh, we still lack one thing: the ability to use charts.
Enter Neptune, the automatic weather station graphic database service. First of all, I want you to know that from this article (starting in March 2018, Neptune is in preview. You won’t find it on the calculator page. Instead, you have to go to Neptune’s pricing page and figure out your the cost of.
This alone makes it difficult to compare the services between Azure and Automatic Weather Station. For the universe database example above, I don't need to worry about what service I use-I only pay a price.
From the Neptune pricing page, it will show that billing will involve instance size, storage, input/output, and data transfer. For our purpose here, let us assume that we have moderate demand and 25% of the universe database workload is related to graphics. This is 10 GB of storage and 830 channels/sec. We will calculate the cost of Neptune.
I will use the lowest-end memory optimization example. r4. Large (and allocate 10GB of storage. For all requests, we need to do some calculations. The universe database example above is 4200 units/sec (730 hours) a month. In order to get the same number of requests from Neptune, we will accept 4200 20% of requests, or 840 requests per second. That would be 2.2. 7 million requests per month. The last piece of information we need is data transfer. Let us assume a 20% dynamic database transfer rate, so 8GB output, 2 GB input.
The total number of Neptune is:
- database. r4. Large instance is $255. 50/month
- 10 Gb存储每月1美元
- 220 .700万次请求是4400万美元。14/月
- 数据传输率是0美元。72/月
总共是301美元。36/月,满足我们的图形需求。
但是现在我们需要调整动态数据库,减少20%. 这样做，我们有：
DynamoDB 60美元，301美元。
海王星号36，总价$ 1,091。
96。
您将获得全部三项服务。
一张账单与两张账单。
96 .
遗漏了一些内容，例如特定区域的成本，故障转移，可用性，备份等。
我试图使事情尽可能简单，以使您对所提供的成本和服务有所了解。
随意将这种方法用于我在上一篇文章中谈到的任何其他服务。
正如我在那篇文章中提到的那样，在检查成本时评估服务要比尝试检查服务提供的资源限制容易得多。
一张账单与两张账单。
考虑到这一点，我有一天醒来发现Neptune吸收了DynamoDB不足为奇。
毕竟，Cosmos DB去年吸收了DocumentDB。
如果海王星成为唯一的产品，它将使上面的示例更容易完成。
而且我必须更新我的备忘单。
我试图使事情尽可能简单,以使您对所提供的成本和服务有所了解。