3

我已经习惯了 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

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

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

4

3 回答 3

2

更新答案（2014 年 1 月）

DynamoDB 开始支持全球二级索引，这意味着您现在可以在该位置上放置一个索引并快速检索那些生活在墨西哥的人。

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

原始答案（2013 年 3 月）

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

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

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

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

于 2012-03-19T16:55:32.017 回答
1

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

而是使用新的全局二级索引功能。

于 2014-01-09T21:09:17.340 回答
0

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

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

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

于 2012-03-30T08:28:16.370 回答