【问题标题】:Microsoft Azure DocumentDB vs Azure Table StorageMicrosoft Azure DocumentDB 与 Azure 表存储
【发布时间】:2015-05-09 18:48:09
【问题描述】:

近年来,Microsoft 提供了一种“NoSQL”键/值存储,称为“表存储”(http://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-tables/)

表存储提供高性能、可扩展性(通过分区)和相对较低的成本。 Tables 的一个主要缺点是只能索引 Partition 和 Row 键 - 因此对值进行查询非常低效。

最近微软宣布了一项新的“NoSQL”服务,称为“DocumentDB”(http://azure.microsoft.com/en-us/documentation/services/documentdb/)

DocumentDB 存储 JSON 对象,而不是存储属性列表(像 Tables 那样)。被索引的整个对象 - 可以基于存储对象的每个属性和任何嵌套属性创建高效查询。

Microsoft 表示 DocumentDB 还提供高性能和可扩展性。

如果是这样 - 为什么有人会使用表存储而不是 DocumentDB?听起来 DocumentDB 提供了与 Tables 相同的功能,但具有其他功能,例如索引任何内容的能力。

如果有人可以在 DocumentDB 和 Table Storage 之间进行比较,我会很高兴,并突出它们的优缺点。

【问题讨论】:

    标签: azure azure-cosmosdb azure-table-storage


    【解决方案1】:

    两者都是 NoSQL 技术,但它们有很大的不同。 Azure Tables 是一个简单的键/值存储,不支持复杂查询等复杂功能(其中大多数无论如何都需要完整的分区/表扫描,这会降低性能并节省成本)、自定义索引(索引基于仅限 PartitionKey 和 RowKey,您目前无法对任何其他实体属性进行索引,并且搜索 PartitionKey/RowKey 组合以外的任何内容将需要分区/表扫描)或存储过程。您也不能批量读取多个实体的请求(如果所有实体都属于同一分区,则支持通过批量写入请求)。有关 Azure Tables 的实际应用,请参阅HERE

    如果您的数据需求(尤其是查询数据)很简单(如上面的示例),那么 Azure Tables 可以满足您的需求,由于定价、性能和存储容量的原因,您最终可能会使用它来支持 DocDB。例如,Azure Tables performance target 是每秒 20.000 次操作。尝试在 DocDB 上获得相同水平的性能将为您带来更高的service cost。此外,Azure 表受您的 Azure 存储帐户 (500TB) 的容量限制,而 DocDB 存储受您购买的容量单位的限制。

    【讨论】:

    • 所以基本上你是说 Azure Tables 唯一的好处就是定价。
    • @Luis“无论如何,它们中的大多数都需要完整的分区/表扫描,这会影响您的性能和成本节约”——只有当您以这种方式设计表时才会如此。如果您知道自己在做什么,那么您设计的表就不会像任何其他键/值 NoSQL 数据库一样进行全表扫描。这也是两者之间最大的区别之一,通过阅读文档,听起来 Microsoft 使用 DocumentDB 为您处理了大部分(如果不是全部)这些东西,而使用 Table Storage 则取决于您如何有效地设计它。跨度>
    【解决方案2】:

    Table Services 主要是一个键值类型 NOSQL,而 DocumentDB(顾名思义)是一个 Document Type NoSQL 存储。您要问的本质上是这两种 NOSQL 方法之间的区别。如果你根据这个来塑造你的研究,你肯定能得到更好的理解。

    为了简单起见,我建议您考虑一下 DocumentDB 和表服务的定价方式之间的差异。不仅这些服务的成本彼此相差很大,而且 DocumentDB 在“供应优先”模型上工作并且表服务以纯消费为基础的定价提供这一事实可能会为您提供一些比较/对比的线索。

    让我问你这个;如果 Table Services 中的功能很好地满足了我的需求,我为什么要使用 DocumentDB? ;) 我建议您看看当前的 Azure 诊断工具如何使用 Azure 存储服务,存储指标如何在其自身上使用 Azure 存储,以了解表服务的用处以及 DocumentDB 在某些情况下的杀伤力有多大。

    希望这会有所帮助。

    【讨论】:

    【解决方案3】:

    我认为比较全部是关于交易价格以获得性能。表服务只是存储服务,它的上限似乎为每秒 20,000 次操作,但一直为这种吞吐量支付费用(因为存储一直提供给我们)是每月 1,200 美元。疯狂的钱。

    表服务具有简单的索引,因此查询非常有限。适用于通过 ID 写入和读取的任何内容。 DocumentDB 索引整个文档,因此可以对任何属性进行查询。

    最后,表服务受其所在存储帐户的存储限制(如果直接与 Microsoft 协商,可能会变得非常高),其中 DocumentDB 存储似乎是无限的。

    所以这是一种平衡。您是否在一个地方需要大量数据(数百个演出或 TB)?文档数据库。您需要支持复杂的查询吗?文档数据库。您是否有数据需要快速来来去去,但基于 1 对 2 属性查找?餐桌服务。你会为了避免为吞吐量付出代价而不得不围绕一个简单的索引进行编码吗?餐桌服务。

    还有 Redis,有人提到过……伙计,我不知道。即使在缓存框架(Redis 提供)中存在持久性也不会将其变成一种技术选择......保存“经常使用但可能丢失或丢失的数据”的持久性存储之间存在巨大差异time-retired”,就像缓存一样,以及保证您的数据存在的持久存储。

    【讨论】:

      【解决方案4】:

      一个真实的例子:

      我必须存储一些令牌,检索它们,删除它们。只有曾经完成的查询将基于用户 ID。

      所以我使用表存储,因为它完美地满足了我的要求。我根据用户 ID 保存令牌。

      Document DB 似乎对此有点过头了。

      【讨论】:

      • 听起来redis缓存比表存储更好。
      • 感谢您的建议。 Redis Cache 可能会更好,但它更多的是 Table storage 和 Document DB 之间的比较。
      • Redis 并不好。它首先是缓存,具有可选的持久性,并且要求所有数据都适合内存,以及运行和维护服务器。同时,Azure 表存储将花费几美分,完全托管、持久、可靠,并且当您在同一区域中运行时延迟非常低。
      【解决方案5】:

      这是microsoft's official docs的答案

      Cosmos DB、Azure 表存储和 Azure SQL 数据库的通用属性:

      • 99.99 可用性 SLA

      • 完全托管的数据库服务

      • 符合 ISO 27001、HIPAA 和欧盟示范条款

      • 下表显示了 Azure Cosmos DB 的不常见属性, Azure 表存储

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2016-06-16
        • 2011-03-26
        • 1970-01-01
        • 2014-10-16
        • 1970-01-01
        • 2012-05-02
        • 2013-01-23
        • 2018-07-09
        相关资源
        最近更新 更多