4

我刚刚阅读了大量关于 Amazon 的 S3 和 CouchDB 的资料。也许还不够，所以这是我的问题：

这两个系统听起来都很吸引我。CouchDB 使用 Apache License V2 和 Amazon 的 S3 分发，您按存储的兆字节和您生成的流量付费。所以金钱上还是有一点区别的。

但是从技术的角度来看，据我了解，这两个系统都可以帮助您存储任意大小的非结构化数据（取决于我从 CouchDB 了解的底层操作系统）。

我不知道为它们提供一个统一的接口有多容易，这样您就可以在需要时更改您的“数据存储提供者”？无需更改任何代码。

我也不知道这在技术上是否容易可行，还没有详细查看他们的协议。但是，最好将提供者的决定推迟到尽可能晚。

对于集成测试目的，这也可能很有趣：例如，您可以针对本地 CouchDB 实例进行测试，然后针对 S3 运行您的代码以供生产使用。

从另一个角度提出我的问题：亚马逊的 S3 和 CouchDB 本质上是解决完全相同的问题，还是这很疯狂，我错过了重点？

更新的问题

在吉姆的精彩回答之后，让我将问题改写为：

“CouchDB 和 Amazon SimpleDB 的通用接口”

按照同样的思路，您是否发现 CouchDB 和 SimpleDB 之间的通用接口存在问题？

4

3 回答 3

11

你错过了重点，只是稍微。CouchDB 是一个数据库。S3 是一个文件系统。它们都是相对非结构化的，但是使用 S3，您将文件存储在键下，而使用 CouchDB，您将（任意结构化）数据存储在键下。

类似于 CouchDB 的 Amazon Web Services 将是Amazon SimpleDB。

对于 Ruby，您正在寻找的东西已经存在，它被称为Moneta。它甚至可以在 S3 上存储东西，这可能正是您想要的。

于 2009-07-18T20:54:46.713 回答
5

你错了吉姆。S3 不是文件系统。它是用于键值存储的 Web 服务。

亚马逊为您提供了一把钥匙。是的，该键的值可以是代表文件的数据。但是，如何在亚马逊系统中进行管理是完全不同的。它可以存储在一个节点、多个节点、具有云端的地理战略节点等。该密钥本身没有任何内容表明系统将如何管理文件。键的值永远不是直接的文件。它是代表文件的数据。该值如何最终解析为客户端接收的文件是完全独立的。

该键的值实际上可以是不代表文件的数据。它可以是 JSON 字典。从这个意义上说，S3 的使用方式与 CouchDB 相同。

所以我不认为这个问题没有抓住重点。事实上，这是一个完全合理的问题，因为 CouchDB 中的数据不是分布在节点之间的。这可能会影响性能。

我们甚至不要谈论 Amazon SimpleDB。那是分开的东西。请不要混淆条款，然后据此提出索赔。

如果您不相信这种说法，并且如果人们提出要求，我很乐意提供一个代码位来说明 S3 中的 JSON 字典。

我尊重你对吉姆其他问题的回答。但是，在这里，您显然错了，看不到这些观点是如何成立的。

于 2009-10-19T01:44:49.327 回答
3

从技术上讲，一个公共层是可能的。但是我质疑这是否有意义。Couchdb 为您的文档集成了 map/reduce 功能，这些功能显示为“视图”。我不认为 SimpleDB 有这样的东西。另一方面，SimpleDB 有 Couchdb 没有的查询表达式。当然，如果您在开发时知道您的查询，您可以将这些表达式建模为 Couchdb 中的视图。

除此之外，通用功能只不过是创建/更新/删除密钥-文档对。

于 2009-07-31T22:22:55.117 回答