Amazon web services DynamoDB中包含超过2列的复合键？

我正在探索DynamoDB在我工作的应用程序中的使用，该应用程序目前只有一个数据库组件——一个运行在RDS上的MySQL数据库

我们大量使用AWS，并对数据库使用分片方案，但这只能在没有人工干预的情况下实现。在使用Aurora时，我发现与MySQL数据库相比，性能明显下降，因此我正在评估DynamoDB，看看它是否适合我们，因为它可以高效地存储JSON数据，并且可以轻松扩展（只需在AWS控制台中增加每秒的读写次数，让Amazon来完成繁重的工作）

在我们的几个MySQL表中，我们有一个主键，它是一个自动增量列，但我们还有几个索引在其上以其他方式支持查询性能。其他指数至关重要，因为我们的一些表中有超过10亿行。本质上，我们在客户机、对象名称等之间进行分区。因此，我可能在MySQL中执行以下操作：

Create Table: CREATE TABLE `record` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `client_id` int(10) unsigned NOT NULL,
  `data_id_start` bigint(20) unsigned NOT NULL,
  `data_id_end` bigint(20) unsigned NOT NULL DEFAULT '8888888888888888',
  `object_name` varchar(255) NOT NULL,
  `uuid` varchar(255) NOT NULL,
  `deleted` tinyint(1) unsigned NOT NULL DEFAULT '0',
  ...
  PRIMARY KEY (`id`),
  ...
  KEY `client_id_object_name_data_id_data_id_end_deleted` (`client_id`,`object_name`,`data_id_start`,`data_id_end`,`deleted`),
  KEY `client_id_object_name_data_id_end_uuid_id` (`client_id`,`object_name`,`data_id_end`,`uuid_id`),
  ...
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

我正在评估将一些数据复制到DynamoDB中用作缓存，因此在某些情况下，我们不必到S3检索存储在那里的数据。相反，我将直接将JSON数据存储在缓存中。在DynamoDB中，看起来可以在键中使用散列或散列和范围属性。例如，我可以使用MySQL表中的autoincrement列作为散列，但是我看到的所有范围键、全局/局部二级索引等示例都只指定一个其他属性作为范围。当在“where”子句中指定了3个或更多值时，我想创建一个用于高效查找的索引

例如，我想使用如下表达式查询此表：

var params = {
    TableName: "Cache",
    KeyConditionExpression: "clientId = :clientId and objectName = :objectName and uuid = :uuid",
    ExpressionAttributeValues: {
        ":clientId": 17,
        ":objectName": "Some name",
        ":uuid": "ABC123-KDJFK3244-CCB"
    }
};

请注意，KeyConditionExpression中的“where子句”使用3个值。我们可能有4或5个值。那么，在DynamoDB中有没有办法创建包含两个以上属性（列）的复合键呢

---

如果没有，我想我可以将3列连接成一个字符串，并在每次插入时将其用作主键。或者至少连接clientId和objectName，然后使用uuid作为范围或类似的东西。实际上，我需要对特定cliclid/ObjtNeX组合的所有值进行页面遍历，然后根据每行中的一些属性，或者直接从缓存中获取其值，或者将其视为一个错误，并从S3检索值（这相当慢）。.

DynamoDB允许对基本上无限量的数据进行一致的低延迟查询。您建议的连接值的模型似乎是一个好方法

需要注意的一点是，哈希键属性值限制为2048字节。如果要连接的值不是可预测的长度（您无法很好地填充它们）或超过此限制，则更好的方法可能是散列项目的值并基于项目的散列进行搜索。以下是有关限制的相关文档：。DynamoDB项的总数据量也限制为400KB

---

为了正确性，我还将为范围键使用一些唯一标识符，这将允许哈希值发生冲突（即使很少），并且模式是可伸缩的，因为每个哈希键值有少量项。

Hmm…如果我连接客户端和对象，它实际上会导致相当多的冲突。我们的一些客户拥有2400万个相同类型的对象。如果这是散列值，那么会有很多冲突。然后每个记录的唯一ID可以是一个范围，但同样——这仍然是大量潜在的冲突。但是你能回答我的问题吗？我是否可以创建一个包含两列以上的索引？你不能创建包含两列以上的索引。此限制允许DynamoDB在数据模型适合的情况下以任何规模提供一致的低延迟写入/读取。你能提供更多关于为什么会有这么多碰撞的信息吗？如果每个客户端ID都是唯一的，并且每个客户端都有唯一的对象名，这将提供一个非常好的均匀分布的哈希键值。好的，谢谢。2列与我在各处看到的内容相呼应。同样，我们的客户机可以拥有数百万个相同类型的对象。因此，连接clientId+objectName意味着数百万条记录都具有相同的哈希。uuid可以是唯一的范围属性，但24M+记录可能具有相同的哈希值，然后uuid将打破这一关系，这是一个问题吗？如果这是关系型的，我会做一些类似于“从缓存中选择*，其中client_id=？和object_name=？LIMIT X OFFSET Y”的事情，并对所有记录进行分页。如果单个散列键的读/写访问频率高于其他键，则可能会遇到热键问题（因此，使用相同散列的24M+记录可能会有很大问题）。那么同一个clientId是否存在重复的objectName值？最好的方法是在哈希键值中使用clientId和objectName的唯一值进行查找。由于哈希键值可以是2048字节，因此哈希键可能有2^（2048*8）~10^4932个值。是。这是Salesforce数据，因此，例如，单个客户端可能有数百万个Account对象。select可能类似于：mysql>select client_id、object_name、uuid from record；|1 |科目| AB1 | 1 |科目| AB2 | 1 |科目| AB3 |。。。也许我应该在（客户机id、对象名称）上使用另一个MySQL数据库和索引，但我看不出这与Dynamo中的哈希冲突有多大区别。