Azure 表服务中是否需要表的概念？答案

【问题标题】：is the notion of a Table required at all in Azure Table service?Azure 表服务中是否需要表的概念？
【发布时间】：2013-08-07 18:08:26
【问题描述】：

我正在使用 azure 表服务。我想问的是 Azure 内部是否关心 Table 的概念？

让事情变得快速很大程度上取决于分区键和行键。表格看起来不像容器或实体分组，因为您可以创建的表格数量没有限制。总存储大小与我的存储帐户相关联。

那么 Table 只是帮助人们从 RDBMS 领域过渡的一个概念，还是它们在内部服务于某个目的？我可以用单表设计做应用程序而不用担心性能吗？毕竟，如果表只是一个标签，那么我也可以将其作为分区键的一部分。

编辑

举个例子，表格分区键看起来很像 Cassandra 行，而表格行就像 Cassandra 列。可以将存储视为一大桶键（RowKey）-值对。分区键是分片机制。那么表格只是作为一个“标签”的概念出现。

【问题讨论】：

表怎么不是容器？我没有关注你。
Azure 表存储与 SQL 等传统 RDBMS 的设计截然不同。如果您不使用一堆关系数据，您可以设计一个仅使用单个表的应用程序。如果您不能根据分区和行键进行查找，那么表的性能就会成为问题。 Julie 有很好的Azure Table Storage writeup 你可能有兴趣阅读。

【解决方案1】：

您可以将所有实体存储在一个 azure 表存储中，并通过深思熟虑选择正确的分区键和行键组合来获得最佳性能，但恕我直言，最好将相关实体分别放在单独的表中，因为那样会易于管理（从开发人员的角度来看）。你知道你的应用程序的哪个部分正在访问哪个表。

您可能希望查看此录制的会话，其中讨论了最佳实践和内部原理。 Windows Azure Storage: What’s Coming, Best Practices, and Internals

【讨论】：

谢谢，我已经阅读了该博客以及我能找到的任何其他内容。我还用更多细节更新了这个问题。重点是该表只需要 from_developer_perspective 。如果某些开发人员对 Azure 表存储作为一大桶按 PK 分区以提高性能的键值对感到满意，那么表只是一个标签，别无其他。
你说得对，这是为开发人员提供便利。决定性能的是经过深思熟虑选择的分区键，以便基础架构可以在分区变热的情况下对分区进行负载平衡。这里还有一个视频链接microsoftpdc.com/2009/SVC09

【解决方案2】：

您可以将表名和分区键的联合视为一个性能单位。

您可能正在考虑重新发明由 Lokad 开发的 FatEntities.。

“表格”的概念有很多限制和问题。例如，如果您在一个分区中有一个包含 100,000 个条目的大表，那么如果不遍历每个条目，您就不能轻易地跳转到条目 99,001。倒退是不可能的（你不能从最后一个入口开始倒退）

【讨论】：

我不这么认为，我的论点是 - 您可以将表格数量增加到您喜欢的任何数量。另外，您的示例不正确。使用正确的分区键和行键，我可以去我存储区域的任何地方。就像我说的，我可以在不影响性能的情况下进行单表设计。 “桌子”的概念只是为了让人放心。