【发布时间】：2014-06-09 21:14:01
【问题描述】：
我正在设计一种散列算法，它将为 azure 表生成分区键。我考虑了两种情况：
- 根据行数生成键
- 根据数据大小生成密钥
解释：假设我有 300 个实体要插入（请记住，这是一个非关系商店，所以可以说它，10 个客户，50 个销售，240 个销售项目）......为了平衡它们，我将使用 2 个分区键：K1 和 K2。
在“行计数模式”中插入 1 将有 K1，插入 2 将有 k2，插入 3->K1，插入 4->k2 等等。 .. 非常直截了当，并探究大多数人的所作所为...
如果我使用“数据大小”，假设前 50kb 将得到 K1,51-100kb K2, 101-150 K1, 151-200 K2，这可能导致：插入 1、2 和3 使用 K1，插入 4 使用 K2，插入 5 使用 K1，插入 6,7,8,9,10,11,12,13 和 14 使用 K2...
我的问题是：在搜索时，哪些“策略”可以实现最佳吞吐量？
Edti1：
我在这里最担心的是分区和原始性能之间的不平衡。让我们进一步扩展并想象这是一个多租户应用程序。如果我选择Tenant Id 作为分区键，我将不得不解决这样一个事实，即随着租户数据变大，查询性能将比我选择分区键（如Tenant Id + Month of the Sale）下降得更快，因为在第二种情况下，我将能够运行并行查询，例如“tenant1January”、“tenant1February”、“Tenant1Marchar”...
【问题讨论】：
-
我认为这个问题的答案很大程度上取决于您的应用程序的业务逻辑。最常执行哪些类型的读取？通过什么标准可以找到这些读取的记录？使用 PartitionKey + RowKey 时读取速度最快。当通过不是这两个键之一的字段扫描记录时，读取速度会慢得多。它还可能取决于您拥有的记录数量以及您访问它们的频率。例如，如果您可能有几千条记录，您可能会通过 partitionkey 读取它们并在本地缓存它们。
标签： azure azure-table-storage nosql