CouchDB 和 Amazon S3 的通用接口
我刚刚阅读了大量有关 Amazon S3 和 CouchDB 的材料。 也许还不够，所以这是我的问题：
这两个系统听起来都对我很有吸引力。 CouchDB 使用 Apache License V2 进行分发，并通过 Amazon S3 进行分发，您可以按存储的兆字节和生成的流量付费。 所以在金钱上有一点区别。
但从技术角度来看，据我了解，这两个系统都可以帮助您存储任意大小的非结构化数据（取决于我从 CouchDB 中了解到的底层操作系统）。
我不知道为它们提供一个统一的接口有多容易，这样您就可以在需要时更改您的“数据存储提供商”？ 不必更改您的任何代码。
我也不知道这在技术上是否容易实现，还没有详细研究他们的协议。 但如果能尽可能晚地推迟提供商的决定，那就太好了。
此外，这对于集成测试目的可能很有趣：例如，您可以针对本地 CouchDB 实例进行测试，并针对 S3 运行代码以供生产使用。
从不同的角度阐述我的问题：Amazon 的 S3 和 CouchDB 本质上解决的是完全相同的问题，还是这很疯狂而我错过了全部要点？
更新的问题
在 Jim 出色的回答之后，让我将问题改写为：
“CouchDB 和 Amazon SimpleDB 的通用接口”
遵循相同的思路，您是否看到了那么 CouchDB 和 SimpleDB 之间的通用接口有问题吗？
I just read tons of material on Amazon's S3 and CouchDB. Maybe not enough yet though, so here is my question:
Both systems sound very appealing to me. CouchDB is distributed using the Apache License V2 and with Amazon's S3, you pay per stored megabyte and the traffic you generate. So there is a bit of a difference monetarily.
But from a technical point of view, from what I understood, both systems help you at storing unstructured data of arbitrary sizes (depending on the underlying OS as I understand from CouchDB).
I don't know how easy it would be to come up with a unified interface for both of them, so that you could just change your "datastore provider" as the need arises? Not having to change any of your code.
I also don't know if this is technically easily feasible, haven't looked at their protocols yet in great detail. But it would be great to postpone the provider decision to as late as possible.
Also this could be interesting for integration testing purposes: You could for example test against a local CouchDB instance and run your code against S3 for production use.
To formulate my question from a different angle: Is Amazon's S3 and CouchDB essentially solving the exact same thing or is this insane and I missed the whole point?
Updated Question
After Jim's brilliant answer, let me then rephrase the question to:
"Common Interface for CouchDB and Amazon SimpleDB"
And following the same lines of thinking, do you see a problem with a common interface between CouchDB and SimpleDB then?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
你没有抓住要点，只是稍微有点。 CouchDB 是一个数据库。 S3 是一个文件系统。 它们都是相对非结构化的，但是使用 S3，您在键下存储文件，而使用 CouchDB，您在键下存储（任意结构化）数据。
Amazon Web Services 类似于 CouchDB 的东西是 Amazon SimpleDB。
Ruby 中已经存在类似您正在寻找的东西，它的名称为 Moneta。 它甚至可以在 S3 上存储内容，这可能正是您想要的。
You're missing the point, just slightly. CouchDB is a database. S3 is a filesystem. They're both relatively unstructured, but with S3 you're storing files under keys while with CouchDB you're storing (arbitrarily-structured) data under keys.
The Amazon Web Services analogue to something like CouchDB would be Amazon SimpleDB.
Something like what you're looking for already exists for Ruby, and it's called Moneta. It even can store stuff on S3, which may be exactly what you want.
你错了吉姆。 S3 不是文件系统。 它是一个用于键值存储的 Web 服务。
亚马逊为您提供了一把钥匙。 是的，该键的值可以是代表文件的数据。 但是，亚马逊系统中的管理方式却完全不同。 它可以存储在一个节点、多个节点、带有cloudfront的地理战略节点等。 该密钥本身没有任何内容表明系统将如何管理该文件。 键的值永远不是直接的文件。 它是代表文件的数据。 该值如何最终解析为客户端接收的文件是完全独立的。
该键的值实际上可以是不代表文件的数据。 它可以是 JSON 字典。 从这个意义上说，S3 可以像 CouchDB 一样使用。
所以我不认为这个问题没有抓住重点。 事实上，这是一个完全合理的问题，因为 CouchDB 中的数据并不分布在节点之间。 这可能会影响性能。
我们甚至不谈论 Amazon SimpleDB。 那是不同的事情。 请不要混合术语，然后据此提出索赔。
如果您不相信这个说法，并且如果人们提出要求，我很乐意提供一段代码来说明 S3 中的 JSON 字典。
吉姆，我尊重你对其他问题的回答。 但是，在这里，你显然是错误的，并且看不出这些观点是如何合理的。
You are wrong Jim. S3 is not a filesystem. It is a webservice for a key-value store.
Amazon provides you with a key. Yes, the value of that key can be data that represents a file. But, how that gets managed in the Amazon system is something entirely different. It can be stored in one node, multiple nodes, geographically strategic nodes with cloudfront, and so on. There is nothing in that key in and of itself that indicates how the system will manage the file. The value of the key is never a file directly. It is data that represents the file. How that value gets eventually resolved into a file that the client receives is entirely separate.
The value of that key can actually be data that does not represent a file. It can be a JSON dictionary. In that sense, S3 could be used in the same way as CouchDB.
So I don't think the question is missing the point. In fact, it is a perfectly legitimate question as data in CouchDB is not distributed amongst nodes. And that could hamper performance.
Let's not even talk about Amazon SimpleDB. That is something separate. Please don't mix terms and then make claims based on that.
If you are not convinced by this claim, and if people request it, I am happy to provide a code bit that illustrates a JSON dictionary in S3.
I respect your answers to other questions Jim. But, here, you are clearly wrong and cannot see how those points are justified.
从技术上讲，公共层是可能的。 但我怀疑这是否有意义。
Couchdb 为您的文档集成了映射/归约功能，这些功能作为“视图”公开。 我不认为 SimpleDB 有这样的东西。 另一方面，SimpleDB 具有 Couchdb 没有的查询表达式。 当然，如果您在开发时知道您的查询，您可以将这些表达式建模为 Couchdb 中的视图。
除此之外，通用功能不过是创建/更新/删除密钥文档对。
Technically a common layer is possible. However I question that this would make sense.
Couchdb has integrated map/reduce functions for your documents which are exposed as "views". I don't think SimpleDB has anything like that. On the other hand SimpleDB has query expressions which Couchdb has not. Of coure you can model those expressions as a view in Couchdb if you know your query at development time.
Beside that the common function is not more than create/update/delete a key-document pair.
这是一个老问题，但在我的搜索中它首先出现。
PouchDB 是一个完全兼容的 CouchDB 接口，并使用 LevelDown 作为其后端。 它能够使用任何 LevelDown 兼容接口。
S3 LevelDown 是一个 Level Down 兼容接口，使用 S3 作为其后端存储。
https://github.com/loune/s3leveldown
理论上，你可以将它们放在一起创建一个完整的 CouchDB 风格实现，由 S3 支持。
https://github.com/loune/s3leveldown/tree/master/examples/袋数据库
This is an old question, but it comes up first in my searches for this.
PouchDB is a fully compliant CouchDB interface, and uses LevelDown for its backend. It is capable of using any LevelDown compliant interface.
S3 LevelDown is a Level Down compliant interface that uses S3 as its backend store.
https://github.com/loune/s3leveldown
In theory, you could put them together to create a full CouchDB style implementation, backed by S3.
https://github.com/loune/s3leveldown/tree/master/examples/pouchdb