55

我正在研究 Amazon 的 DynamoDB，因为它看起来消除了维护和扩展数据库服务器的所有麻烦。我目前正在使用 MySQL，维护和扩展数据库是一件令人头疼的事情。

我已经浏览了文档，我很难理解如何构建数据以便可以轻松检索它。

我对 NoSQL 和非关系数据库完全陌生。

从 Dynamo 文档看来，您只能在主哈希键上查询表，并且主范围键具有有限数量的比较运算符。

或者您可以运行全表扫描并对其应用过滤器。问题是它一次只能扫描 1Mb，因此您可能必须重复扫描才能找到 X 个结果。

我意识到这些限制使它们能够提供可预测的性能，但似乎很难将数据取出。执行全表扫描似乎效率很低，并且随着表的增长，效率只会随着时间的推移而降低。

例如，假设我有一个 Flickr 克隆。我的图像表可能类似于：

  • 图像 ID（编号、主哈希键）
  • 添加日期（数字，主要范围键）
  • 用户 ID（字符串）
  • 标签（字符串集）
  • ETC

因此，使用查询我将能够列出过去 7 天的所有图像，并很容易将其限制为 X 个结果。

但是，如果我想列出来自特定用户的所有图像，我需要进行全表扫描并按用户名过滤。标签也是如此。

而且因为您一次只能扫描 1Mb，您可能需要进行多次扫描才能找到 X 个图像。我也没有看到一种方法可以轻松地停在 X 个图像上。如果您尝试抓取 30 张图像，您的第一次扫描可能会找到 5 张，而第二次扫描可能会找到 40 张。

我有这个权利吗？它基本上是一种权衡吗？您可以获得真正快速、可预测的数据库性能，几乎无需维护。但权衡是您需要构建更多逻辑来处理结果？

还是我完全不在这儿？

4

3 回答 3

20

是的，您对性能和查询灵活性之间的权衡是正确的。

但是有一些技巧可以减轻痛苦——二级索引/非规范化可能是最重要的。

例如，您将有另一个以用户 ID 为键的表，列出他们的所有图像。当您添加图像时，您会更新此表并在以图像 ID 为键的表中添加一行。

你必须决定你需要什么查询，然后围绕它们设计数据模型。

于 2012-02-03T22:42:36.400 回答
6

我认为您需要使用另一个表创建自己的二级索引。

此表“模式”可能是：

    User ID (String, Primary Key)
    Date Added (Number, Range Key)
    Image ID (Number)

--

这样您就可以按用户 ID 查询并按日期过滤

于 2012-02-03T17:19:58.623 回答
5

您可以使用复合散列范围键作为主索引。

从 DynamoDB 页面：

主键可以是单属性散列键或复合散列范围键。例如，单个属性哈希主键可以是“UserID”。这将允许您快速读取和写入与给定用户 ID 关联的项目的数据。

复合散列范围键被索引为散列键元素和范围键元素。这个多部分键维护第一个和第二个元素值之间的层次结构。例如，复合散列范围键可以是“UserID”（散列）和“Timestamp”（范围）的组合。保持散列键元素不变，您可以搜索范围键元素以检索项目。例如，这将允许您使用 Query API 来检索跨一系列时间戳的单个 UserID 的所有项目。

于 2013-04-19T04:34:55.063 回答