Azure表存储(NoSQL)中的单独表与一个大表

时间:2013-06-27 19:27:08

标签: database azure database-design nosql

我正在使用Azure表,我正在试图弄清楚我应该如何组织数据。

表中的每个实体都有一个PartitionKey和一个RowKey,我的理解是应该使用分区来组织类似的对象以实现可伸缩性。在网站上的示例中,他们使用电影实体,其中类别(动作,科幻等)是PartitionKey,而标题(速度和激情等)是RowKey。

按照上面的例子,假设我们没有重复的电影,你也想跟踪每个特定的电影租赁历史,即位置,截止日期,客户等。

让一个表存储所有这些并为租赁实体使用单独的分区是不是不好的做法?为了清楚起见,我正在谈论一个电影项目及其相应的历史项目在同一个非规范化表中的不同分区中。

使用两个单独的表是否有优势,如果没有,那么表的重点是什么?

编辑:
PartitionKey | RowKey | prop0 | prop1 | ...
---------------------------------------------- --...
科幻|星球大战| foo0:bar0 | foo1:bar1 | ...
租赁|星球大战| foo0:bar0 | foo1:bar1 | ...

1 个答案:

答案 0 :(得分:1)

首先,表存储的概念是你可以“转储”大量数据,因为知道搜索工具很差,你将无法发出SQL查询,因此没有RDBMS,而且它是一种手段存储大量数据。 实际上,partitionKey和rowKey是Azure存储中唯一的索引列,这意味着通过partitionKey或rowKey搜索比使用任何其他列搜索更快。如果您需要快速检索数据,那么blob存储或表存储是不行的。如果您只是想为审计目的或历史目的保留记录,那么是。 但是,如果您想在视频商店中使用它并需要检索客户端的详细信息,那么正如我所提到的那样,这是不好的做法。你最好使用RDBMS。最后,您不能在表存储中进行JOIN或其他RDBMS查询等,即在两个表之间。

相关问题