Azure Cosmos DB 简测
CommosDB现在能支持5种API ，支持DocumentDB API 、MongoDB API 、Graph API 、表 API 、Cassandra API 。对于各种API 和语言支持情况，如下：
cosmosDB 是一个分布式数据库，可以全球范围数据同步，达到毫秒级，并且保证一致性保证。
是我来创建一个cosmosdb，测试下 cosmosdb，是不是能做到这样的水平，是不是吹牛来着 。
季测试，我们测试Document DB，
首先创建一个基于SQL API的CosmosDB
在全球复制上，我选了多个区域，一致性默认的是：会话
为了测试简单，我使用标准的sample代码。点击快速入门，默认创建了items集合
本人喜欢.net代码，所以测试使用.net代码。
1、这里下载的示例直接运行是不会成功的。 需要安装NuGet 包。在 Visual Studio 中，右键单击解决方案资源管理器中的项目，并单击“管理 NuGet 包”。
2、在 NuGet“浏览”框中，键入 DocumentDB。
3、从结果中安装“Microsoft.Azure.DocumentDB”库。 这会安装 Microsoft.Azure.DocumentDB 包以及所有依赖项
如果导入失败，报告400错误什么的，建议更换程序包源，：
编译通过后，就可以生成如下这样的应用。
我创建了3个站点来进行测试， 分别在 澳大利亚东南部、美国中部、日本东部。
修改代码：DocumentDBRepository.cs
添加三个区域，每个区域的站点分别都本数据中心的数据。 下面是日本站点的代码
ConnectionPolicy connectionPolicy = new ConnectionPolicy();
// connectionPolicy.PreferredLocations.Add(LocationNames.EastUS); // second preference
//connectionPolicy.PreferredLocations.Add(LocationNames.AustraliaSoutheast); // second preference
connectionPolicy.PreferredLocations.Add(LocationNames.JapanEast); // third preference
同理可以分别发布美国和澳大利亚的代码
ConnectionPolicy connectionPolicy = new ConnectionPolicy();
connectionPolicy.PreferredLocations.Add(LocationNames.EastUS); // second preference
//connectionPolicy.PreferredLocations.Add(LocationNames.AustraliaSoutheast); // second preference
//connectionPolicy.PreferredLocations.Add(LocationNames.JapanEast); // third preference
ConnectionPolicy connectionPolicy = new ConnectionPolicy();
// connectionPolicy.PreferredLocations.Add(LocationNames.EastUS); // second preference
connectionPolicy.PreferredLocations.Add(LocationNames.AustraliaSoutheast); // second preference
//connectionPolicy.PreferredLocations.Add(LocationNames.JapanEast); // third preference
由于次是肉测，所以我也写了一个简单的页面
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title></title>
</head>
<body>
<table width="">
<tr>
<td><iframe id="if1" name="iframe1" frameborder= marginheight= marginwidth= scrolling=no src="http://australiasoutheast.azurewebsites.net/" width="" height="500px"></iframe></td>
<td><iframe id="if2" name="iframe2" frameborder= marginheight= marginwidth= scrolling=no src="http://japaneasttest.azurewebsites.net/" width="" height="500px"></iframe></td>
</tr>
<tr>
<td><iframe id="if3" name="iframe3" frameborder= marginheight= marginwidth= scrolling=no src="http://esus01.azurewebsites.net/" width="" height="500px"></iframe></td>
<td>
<input type="button" onclick="flush();" value="刷新" />
</td>
</tr>
</table>
<script type="text/javascript">
function flush() {
document.getElementsByName("iframe1").iframe1.src = document.getElementsByName("iframe1").iframe1.src;
document.getElementsByName("iframe2").iframe2.src = document.getElementsByName("iframe2").iframe2.src;
document.getElementsByName("iframe3").iframe3.src = document.getElementsByName("iframe3").iframe3.src;
setTimeout("flush()", 1000);
}
</script>
</body>
</html>
此页面一秒钟刷新一次，在任意一个站点输入数据。观察数据同步情况。
从肉测来看，数据是同步的，每一笔数据写入后，读出数据同步。但是毕竟是肉测无法确定是不是毫秒级。 从系统提供的监视来看如下：
读取延迟，SLA是提供10ms的延迟，实际是读取是不到2ms，写入延迟提供15ms的SLA，实际是不到8ms的延迟。
但是此数据是小量写入，而且无压力可言。因此可以搞一个压力测试。测试如下。下载测试代码
https://github.com/Azure/azure-documentdb-dotnet/tree/master/samples/documentdb-benchmark
创建了一个测试数据集 sample
使用了大的性能的RU/S，会很贵。基本上一天要几百美金。一个月6000美金
使用此工具写入200000条结果集，在我的本机进行写入的性能是这样的：
可以说差的一塌糊涂。 20万条数据写了10多分钟。每秒写入206，差就一个字。
我突然想到是不是我们伟大的国度的网络问题，因此我到azure.com开了一台虚拟机，再来测试，发现结果如下
结果是快了10倍！10倍啊！
20万笔不到2分钟写完。这个结果是不错的。同时同步到全球的结果集是怎么样的情况，再看看指标。
从指标看是很完美的。但是本测试只是从指标来看。
数据集总条目：
从简单的测试虽然不能确认同步读取的时间，一致性问题。有5种级别的一致性，目前测试的是会话。因此需要测试的内容非常多。
不过从简单的测试来看，我认为cosmosdb确实可以实现分布式的数据库，毫秒级同步，全球范围内部署你的应用。适合于构建全球的网站。 而国内的应用来看就比较尴尬，因为只有2个点，作为应用的负载分配来说，感觉没有多大的意义。其他的数据库都可以实现。
另外CosmosDB 也是一个写入区域，多个读取区域，优点在于同步速度毫秒级，可以在全球30多个数据中心分发数据。如果要实现多点写入，多区域读取，可以通过分区的方法来从业务层面来实现。 在文档中也有说明和介绍。
相关文章