根据行数或大小选择Azure表分区键

我正在设计一个哈希算法，它将为azure表生成分区键。我考虑了两种情况：

基于行计数生成密钥 根据数据大小生成密钥 解释：假设我有300个实体要插入，记住这是一个非关系商店，所以让我们假设它，10个客户，50个销售，240个销售项目。。。为了平衡它们，我将使用两个分区键：K1和K2。 在行计数模式下，插入1将有K1，插入2将有k2，插入3->K1，插入4->k2等等。。。非常直截了当地问大多数人做什么。。。 如果我使用数据大小，假设前50kb将得到K1,51-100kb K2，101-150 K1，151-200 K2，这可能导致：使用K1插入1,2和3，使用K2插入4，使用K1插入5，使用K2插入6,7,8,9,10,11,12,13和14

我的问题是：在搜索时，哪些tatics将实现最佳吞吐量

Edti1：

---

我最担心的是分区和原始性能之间的不平衡。让我们进一步扩展并想象这是一个多租户应用程序。如果我选择租户Id作为分区键，我将不得不绕过这样一个事实，即当租户数据变得更大时，查询性能将比选择租户Id+销售月份这样的分区键下降得更快，因为在第二个场景中，我将能够运行并行查询，例如租户1月、租户1月、租户2月、，租户1马尔卡尔…

要回答你的具体问题，我两个都不同意

分区键是设计表存储查询时要考虑的最重要的事项。如果我正确理解了你的PK方案，那么要快速获得你正在保存的任何信息，你需要知道它保存了多少行，或者所有其他数据的大小

---

我会退后一步，考虑您希望如何获取这些数据，然后考虑您希望使用什么PK和RK。

我认为这一问题的答案在很大程度上取决于应用程序的业务逻辑。最常执行的读取类型是什么？根据什么标准可以找到这些读取的记录？使用PartitionKey+RowKey时读取速度最快。当通过不是这两个键之一的字段扫描记录时，读取速度会慢得多。它还可以取决于您拥有的记录数量以及您访问它们的频率。例如，如果您有几千条记录，您可以通过partitionkey读取它们并在本地缓存它们。