azure - 设计用于存储复选框状态的 Windows Azure 表数据库

Question

由于设计非关系数据库(具体来说是 Azure 存储表)的经验为零，我很难想出一个好的设计来存储我的应用程序的数据。

该应用程序非常简单。它基本上是一个多用户待办事项列表:

User selects a "Procedure".
User gets presented with webpage with several checkboxes.
User starts checking checkboxes.
Each check/uncheck gets stored in the DB.

例如，假设我们有一个获取牛奶的过程:

Procedure 1 - How to obtain Milk:
    [_] Step 1 - Open fridge
    [_] Step 2 - Get Milk
    [_] Step 3 - Close fridge

Alice 决定执行此过程，因此她创建了一个新的执行并开始检查复选框:

Procedure 1, Execution 1:
    Executor(s): Alice
    [X] Step 1 - Open fridge
    [X] Step 2 - Get Milk
    [_] Step 3 - Close fridge

Bob 也决定执行此程序，但不与 Alice 一起执行。因此，Bob 创建了一个新的执行。另一方面，查理想要帮助鲍勃，因此他没有创建新的执行，而是加入了鲍勃的执行:

Procedure 1, Execution 2:
    Executor(s): Bob, Charlie
    [_] Step 1 - Open fridge
    [X] Step 2 - Get Milk
    [_] Step 3 - Close fridge

综上所述，我们可以有多个过程，每个过程可以有多次执行:

所以，我们需要一种存储过程的方法(复选框列表)；处决(谁、何时、复选框说明)；以及检查/取消检查的历史记录。

这是我到目前为止所想到的:

• 创建三个表:程序、执行、操作。
• Procedures 表存储每个过程中的复选框。
• 执行表存储谁以及何时启动过程的执行，以及复选框状态。
• 操作表存储每个复选框的选中和取消选中，包括谁和何时。

出于多种原因，我对这种方法不太满意。例如，每次用户单击复选框时，我们都需要更新执行表行并同时将新行插入到操作表中。另外，我不确定此设计是否可以扩展到大量的过程、执行和操作。

使用 Azure 存储表或类似的 NoSQL 存储来存储这些数据的好方法是什么？您将如何设计这个数据库？并且，您将如何对数据进行分区(行键、分区键)？

Answer 1

首先，您不需要将 Azure 表强制转换为关系结构。它们非常快且非常便宜，其设计使您可以转储数据 block 并在检索它时担心其结构。

其次，正确识别和构建分区键可以使检索速度更快。

第三，Azure 表不必具有统一的结构。即使使用相同的分区键，您也可以在一张表中存储不同类型的数据。这开辟了 RDBMS 所不具备的可能性。

那么您打算如何检索数据？有哪些用例？

假设您的主要用例是按时间检索数据，例如审核日志。在这种情况下，我建议采用这种方法:

• 将您的过程、执行和操作全部放在同一个表中。
• 为每个时间单位创建一个新表，为每个表提供数万到数十万行，或其他有意义的单位。 (对于我最近完成的一个项目，应用程序的事件日志每月使用一张表，每个表增长到大约 100,000 行。)
• 创建一个分区键，为每个分区提供数百到数千行。 (我们使用 DateTimeOffset.MaxValue 之前的剩余小时数。当您在不使用分区键的情况下查询 Azure 表时，您会首先看到最低的分区。这种按小时降序排列的方案意味着最近一小时的条目位于我们的 Azure 工具中结果 Pane 的顶部。)
• 将行键构建为人类可读的。请记住，它们在表中必须是唯一的。因此，像 Procedure_Bob_ID12345_20140514-134630Z_unique 这样的行键(其中 unique 是计数器或哈希)可能会起作用。
• 当您查询数据时，拉回整个分区(请记住，它只是几百行)并在内存中过滤结果，这样速度更快。

假设您有第二个用例，您需要按用户名检索数据。简单:在同一个表中，添加包含相同数据的第二行，但具有基于用户名的分区键 (bob_execution_20140514)。

要考虑的另一件事是将整个过程等对象图存储在表中。回到我们的日志记录示例，日志条目可能包含详细信息，因此我们只需将整个 JSON block 放入表中即可。 (我们通常在 Azure 云服务中检索它，因此网络吞吐量并不是一个有意义的限制，因为同一区域内 Azure 到 Azure 的速度为每秒千兆位。)