我正在关注亚马逊的DynamoDB，因为它看起来像是消除了维护和扩展数据库服务器的所有麻烦 . 我目前正在使用MySQL，维护和扩展数据库是一个令人头痛的问题 .
我已经阅读了文档，并且我很难尝试如何构建数据，以便可以轻松检索 .
我是NoSQL和非关系型数据库的新手 .
从Dynamo文档中可以看出，您只能查询主哈希键上的表，以及使用有限数量的比较运算符查询主范围键 .
或者，您可以运行全表扫描并对其应用过滤器 . 问题是它一次只扫描1Mb，因此您可能不得不重复扫描以找到X个结果 .
我意识到这些限制允许它们提供可预测的性能，但似乎它很难将数据输出 . 执行全表扫描似乎效率非常低，随着时间的推移，随着时间的推移，效率会降低 .
对于Instance，说我有一个Flickr克隆 . 我的图像表可能看起来像：
-
图像ID（编号，主哈希键）
-
添加日期（编号，主范围键）
-
用户ID（字符串）
-
标签（字符串集）
-
等
因此，使用查询我将能够列出过去7天内的所有图像，并且非常容易将其限制为X个结果 .
但是，如果我想列出来自特定用户的所有图像，我需要进行全表扫描并按用户名进行过滤 . 标签也是如此 .
而且因为您一次只能扫描1Mb，您可能需要进行多次扫描才能找到X个图像 . 我也没有看到一种方法可以轻松停止X个图像 . 如果您尝试抓取30张图片，则第一次扫描可能会找到5张，而第二张扫描可能会找到40张 .
我有这个权利吗？它基本上是一种权衡吗？您可以获得真正快速可预测的数据库性能，几乎无需维护 . 但是，权衡是你需要 Build 更多的逻辑来处理结果吗？
或者我完全不在这里？
3 回答
是的，您对性能和查询灵活性之间的权衡是正确的 .
但是有一些技巧可以减轻疼痛 - 二级指数/非规范化可能是最重要的 .
例如，您可以在用户ID上键入另一个表，列出所有图像 . 添加图像时，更新此表以及向图像ID上键入的表添加行 .
您必须决定所需的查询，然后围绕它们设计数据模型 .
我认为你需要使用另一个表创建自己的 secondary index .
此表“架构”可以是：
这样您就可以按用户ID进行查询，也可以按日期过滤
您可以使用 composite hash-range key 作为主索引 .
从DynamoDB页面：