全球二级索引是否遭受热键问题困扰 [英] Do Global Secondary Indexes suffer from hot key issues

问题描述

我知道DynamoDB中的表需要在各个分片之间进行均匀分配才能利用读/写能力，这对于全局二级索引也适用吗?

I know tables in DynamoDB require even distribution between shards to utilize read/write capacity, is this true for Global Secondary Indexes too?

推荐答案

是的，GSI具有与常规表索引相同的准则.您应该遵循使用表的准则中所述的相同准则..全球二级索引指南给出了一个例子，选择的密钥可能会导致分区上的热点和活动不均匀.

Yes, GSIs have the same guidelines as regular table indexes. You should follow the same guidelines described in Guidelines for Working with Tables. The Guidelines for Global Secondary Indexes documentation gives an example where a poorly chosen key can lead to hot-spotting and uneven activity accross partitions.:

例如，假设您有一个Employee表，其属性如下作为名称，标题，地址，电话号码，薪水和薪水水平.现在假设您有一个名为PayLevelIndex的全局二级索引，使用PayLevel作为哈希键.许多公司只有非常小的支付代码的数量，通常少于十个，即使对于具有数十万员工.这样的指数将无法提供对于应用程序有很多好处.

For example, suppose you have an Employee table with attributes such as Name, Title, Address, PhoneNumber, Salary, and PayLevel. Now suppose that you had a global secondary index named PayLevelIndex, with PayLevel as the hash key. Many companies only have a very small number of pay codes, often fewer than ten, even for companies with hundreds of thousands of employees. Such an index would not provide much benefit, if any, for an application.

PayLevelIndex的另一个问题是独特的价值观.例如，可能只有少数高管在公司工作，但有大量的小时工.查询PayLevelIndex不会非常有效，因为读取活动不会均匀分布在各个分区中.

Another problem with PayLevelIndex is the uneven distribution of distinct values. For example, there may be only a few top executives in the company, but a very large number of hourly workers. Queries on PayLevelIndex will not be very efficient because the read activity will not be evenly distributed across partitions.

这篇关于全球二级索引是否遭受热键问题困扰的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！