0

初探DocumentDB

为什么需要NoSQL

凭借着结构化数据模型以及直观易学的SQL语言,关系数据库技术已经承载了多年的风雨。随着互联网以及物联网的高速发展,超大规模数据处理、非结构化数据、非固定schema等新需求往往让关系数据库技术力不从心。NoSQL技术应运而生,特意从水平线性扩容、灵活的数据结构等特性入手,非常适合处理运营数据处理这样的应用场景。好比倚天屠龙,我们需要同时了解SQL和NoSQL,这样在实战中才能做到双剑合璧。

azure-documentdb-01

NoSQL其实是一个统称,大致可以分为:

  • 列数据库(column store)
  • 键值数据库(key-value store)
  • 图形数据库(graph store)
  • 文档数据库(document store)

Azure其实提供了许多NoSQL技术,比如Apache HBase是列数据库,而Azure Table Storage是键值数据库。今天我们要看的是DocumentDB这个新推出的文档数据库。

什么是DocumentDB

简而言之,DocumentDB是一个可以存取并查询JSON文档的NoSQL数据库,拥有以下特性:

  • 全托管的服务:用户可以享受提供企业级的SLA,不需要操心底层的虚拟机。
  • 原生支持JSON:用户可以存取JSON文档,不用被schema所束缚。
  • 索引和查询:用户可以用类似SQL的语法来进行查询,自动创建的索引保证了性能,据说还使用了Hekaton技术。
  • 性能与扩展:用户可以享受SSD带来的高性能,并且根据需求还可以水平扩容。

根据TechEd讲座Select * from Azure DocumentDB提供的信息,DocumentDB已经被MSN采用,坐拥4.25亿独立用户以及20TB的JSON文档,并能提供15毫秒以下的写入以及10毫秒以下的读取性能,还是比较惊艳的。

如何使用DocumentDB

百闻不如一见,我们可以通过http://www.documentdb.com/sql/demo试玩一下。首先执行以下查询:

SELECT *
FROM Families f
WHERE f.id = "WakefieldFamily"

可以得到完整的Wakefield家庭信息:

{
  "id": "WakefieldFamily",
  "parents": [
    {
      "familyName": "Wakefield",
      "givenName": "Robin"
    },
    {
      "familyName": "Miller",
      "givenName": "Ben"
    }
  ],
  "children": [
    {
      "familyName": "Merriam",
      "givenName": "Jesse",
      "gender": "female",
      "grade": 1,
      "pets": [
        {
          "givenName": "Goofy"
        },
        {
          "givenName": "Shadow"
        }
      ]
    },
    {
      "familyName": "Miller",
      "givenName": "Lisa",
      "gender": "female",
      "grade": 8
    }
  ],
  "address": {
    "state": "NY",
    "county": "Manhattan",
    "city": "NY"
  },
  "isRegistered": false,
}

如果想进一步了解该家庭孩子们的名字,可以执行:

SELECT c.givenName
FROM Families f JOIN c IN f.children
WHERE f.id = 'WakefieldFamily'

结果是:

[
  { "givenName": "Jesse" },
  { "givenName": "Lisa"}
]

与传统的关系数据库相比,DocumentDB的查询语言有以下特点:

  • 可以引用JSON文档任意深度的结点
  • 返回的JSON文档不一定遵循固定的schema
  • JOIN仅仅发生在同一JSON文档内部

最后我们来看看性能优化。对于强一致性和最终一致性相信大家已经耳熟能详了,实际上在两者之间还有许多折衷的方案。DocumentDB提供了以下四种一致性模型,总有一款适合你:

  • 强一致性(strong consistency):用户永远看到最新的数据,代价是较慢的读写,适合银行账户存取的应用场景。
  • 有限过期一致性(bounded staleness consistency):用户可能看到旧数据,但是变化的顺序是保证正确的,适合在线多人游戏这种对性能要求高但是又对顺序敏感的场景。
  • 会话一致性(session consistency):用户永远看到自己的最新数据,不过别人读起来的时候可能会读到顺序都不对的旧数据,比如博客这类应用场景。实际上,这类的应用场景应该是最丰富的,所以这也是DocumentDB的默认一致性模型。
  • 最终一致性(eventual consistency):性能最佳,不过用户可能看到顺序不一致的旧数据。

至此,我们对DocumentDB有了一个基本的了解。总体而言,如果你需要传统的关系数据模型、处理事务、复杂的SQL查询,那么Azure Database比较适合你;如果你更看重大规模数据处理、水平扩展、非固定schema、灵活的数据格式,那么DocumentDB是一个更好的选择。

一句题外话,想来XML在JSON面前肯定会感慨既生瑜何生亮,同样是树状的文档结构,这流行程度怎么差别这么大呢?XML在SQL Server里面只是一个小小的功能,而JSON在DocumentDB里面却是唯一的一等公民。此外,Web服务也纷纷从返回XML的SOAP风格全面转向返回JSON的REST风格。鄙以为,less is more应该最能诠释个中原因了吧。

 



张 琪

发表评论

电子邮件地址不会被公开。 必填项已用*标注