我已经习惯了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'
我认为可以很容易地做到这一点的方法是创建另一个表。（假设有5000多个用户，如果你只有几百个，我相信还有其他方法可以做到这一点）
--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
然而，现在我们需要在有人新加入时调整两个表，更新他们的位置等。我想这不是什么大不了的事，你只需要对你的应用程序代码非常准确。
这是解决这些问题的最佳方法吗？还是我错过了什么？
更新答案（2014年1月）
DynamoDB开始支持全球二级指数，这意味着你现在可以在该地点建立指数，并只快速检索那些居住在墨西哥的人。
请注意，在撰写本文时（这可能会改变），您不能向现有表添加索引。
原始答案（2013年3月）
关于NoSQL的一般说明：
NoSQL DBMS通常关注可伸缩性
它们通常还会增加服务器端代码方面的应用程序开销。
您应该问问自己"我需要查询来自墨西哥的用户多少次"
答案可能会指导您在对数据库建模时采用正确的方法
这也是没有"完美匹配"和真正"noob样本"的原因（至少据我所知）
现在特别关注DynamoDB，您没有二级索引的奢侈（与其他NoSQL解决方案相反），因此您需要创建表作为索引。在您的模型中，您可以创建一个表，其中哈希键是位置，范围键是用户id。因此，通过QUERY API调用，您可以获取所有墨西哥用户
您也可以考虑其他实现，例如将id连接在一个对象中，但同样，由于DynamoDB只允许64KB的对象，您可能会遇到缩放问题。
不要自己管理单独的索引表。
而是使用新的全局辅助索引功能。
如果您的设计最终基于位置进行了大量查找，那么您应该重新设计以location为hashkey、userId为range key的用户表。但上述方式删除了查询用户姓名或userID的功能，同时插入新用户时也无法检查userID中的唯一性（与MySql中的主键所做的相反）。
现在，如果你不经常根据位置进行搜索，那么执行扫描操作可能是更好的解决方案。
最好的方法是如您所述，根据您的需要在API级别上进行所有这些处理。