DynamoDB 数据库设计（键值存储、noSQL）答案

【问题标题】：DynamoDB Database Design (Key-Value Store, noSQL)DynamoDB 数据库设计（键值存储、noSQL）
【发布时间】：2012-03-17 17:43:23
【问题描述】：

我已经习惯了 MySQL，现在正在尝试理解如何使用键值存储。我还没有看到像数据库设计以及如何插入和获取信息这样的优秀菜鸟示例。

这是您如何将 MySQL 中的数据存储在键值存储中的正确表示吗？

TYPE: MySQL
TABLE: users
COLUMNS: user_id(primary), username, location

TYPE: Key Value Store
TABLE: users
KEY: user_id
VALUES: username, location

所以，如果我在上面是正确的。提取一般用户信息很容易理解。但是我将如何在键值存储中执行以下查询？

SELECT username FROM users WHERE location = 'mexico'

我认为您可以轻松做到这一点的方法是创建另一个表。（假设有超过 5,000 个用户，如果你只有几百个，我相信还有其他方法可以做到这一点）

--Original Table--
TYPE: Key Value Store
TABLE: users
KEY: user_id
VALUES: username, location

--Additional "query" Table--
TYPE: Key Value Store
TABLE: user-location
KEY: location
VALUES: user_id

但是，现在我们需要在有人新加入、更新他们的位置等时调整两个表。我想这没什么大不了的，你只需要非常准确地处理你的应用程序代码。

这是解决这些问题的最佳方法吗？还是我错过了什么？

【问题讨论】：

一般来说，NoSQL 数据存储提供的功能较少。它们并不完全以开发人员的生产力而闻名。

标签： database-design nosql amazon-simpledb key-value-store amazon-dynamodb

【解决方案1】：

更新答案（2014 年 1 月）

DynamoDB 开始支持Global Secondary Indices，这意味着您现在可以在该位置上建立索引并仅快速检索那些生活在墨西哥的人。

请注意，在撰写本文时（这可能会发生变化），您无法向现有表添加索引。

原始答案（2013 年 3 月）

关于 NoSQL 的一般注意事项：
NoSQL DBMS 通常关注可扩展性。
它们通常还会在更多服务器端代码方面增加应用程序开销。

您应该问自己“我需要从墨西哥查询用户多少次”
在对数据库进行建模时，答案可能会指导您采用正确的方法。
这也是没有“完美契合”和没有真正“菜鸟样本”的原因（至少据我所知）

现在特别关注 DynamoDB，您没有二级索引的奢侈（与其他有的 NoSQL 解决方案相反），因此您需要创建表即索引。在您的模型中，您可以创建一个表，其中哈希键是位置，范围键是用户 ID。因此，通过 QUERY API 调用，您可以获得所有 MEXICO 用户。

您也可以考虑其他实现，例如将 id 串联在一个对象中，但同样，由于 DynamoDB 仅允许 64KB 对象 - 您可能会在此处遇到扩展问题。

【讨论】：

过时的答案，使用新的全局二级索引功能。
感谢@DanielSteigerwald - 我已经更新它以反映新的 GSI 功能。

【解决方案2】：

不要自己管理单独的索引表。

改为使用新的global secondary index 功能。

【讨论】：

【解决方案3】：

如果您的设计最终导致您基于位置进行大量查找，那么您应该重新设计用户表，其中 Location 作为 hashkey，userId 作为 range 键。但上述方式删除了查询用户姓名或用户 ID 的功能，同时插入新用户无法检查用户 ID 的唯一性（与 MySql 中的主键所做的相矛盾）。

现在，如果您不经常根据位置进行搜索，那么执行扫描操作可能是更好的解决方案。

最好的方法是根据您的需要在 API 级别进行所有这些处理。

【讨论】：