Someone said a lot of material on Amazon's S3 and CouchDB. Not enough yet though, here is my question:

Both systems seem very attractive to me. CouchDB is shipped while using Apache License V2 with Amazon's S3, you have to pay per saved megabyte and also the traffic you generate. So there's a little of the difference economically.

But from the technical perspective, from things i understood, both systems assist you to at storing unstructured data of arbitrary dimensions (with respect to the underlying OS when i understand from CouchDB).

I'm not sure how easy it might be to develop a unified interface for each of them, to ensure that you can just improve your "datastore provider" because the need arises? Not needing to change all of your code.

I additionally have no idea if this sounds like technically easily achievable, haven't checked out their methods yet in great detail. But it is always good to postpone the provider decision to as late as you possibly can.

Also this may be interesting for integration testing reasons: You can for instance test against a nearby CouchDB instance and run your code against S3 for production use.

To formulate my question from the different position: Is Amazon's S3 and CouchDB basically fixing the identical factor or perhaps is this insane and that i skipped the entire point?

Up-to-date Question

After Jim's brilliant answer, allow me to then rephrase the question to:

"Common Interface for CouchDB and Amazon . com SimpleDB"

And following a same lines of thinking, would you see an issue with a typical interface between CouchDB and SimpleDB then?

You are missing the purpose, just slightly. CouchDB is really a database. S3 is really a filesystem. They are both relatively unstructured, however with S3 you are storing files under secrets while with CouchDB you are storing (randomly-structured) data under secrets.

The Amazon . com Web Services analogue to something similar to CouchDB could be Amazon SimpleDB.

Something similar to what you are searching for already is available for Ruby, and it is known as Moneta. It even can store stuff on S3, which might be exactly what you would like.

You're wrong Jim. S3 isn't a filesystem. It's a webservice for any key-value store.

Amazon . com gives you a vital. Yes, the need for that key could be data that signifies personal files. But, how that will get handled within the Amazon . com product is something entirely different. It may be saved in a single node, multiple nodes, geographically proper nodes with cloudfront, and so forth. There's nothing for the reason that key by itself that signifies the way the system will manage the file. The need for the bottom line is never personal files directly. It's data that signifies the file. How that value will get eventually resolved right into a file the client receives is entirely separate.

The need for that key can really be data that doesn't represent personal files. It's really a JSON dictionary. For the reason that sense, S3 might be used in the same manner as CouchDB.

And So I don't believe now you ask , missing the purpose. Actually, it's a perfectly legitimate question as data in CouchDB isn't distributed among nodes. Which could hamper performance.

Let us not really discuss Amazon . com SimpleDB. That's something separate. Do not mix terms and then suggest claims according to that.

If you're not convinced with this claim, and when people request it, I'm happy use a code bit that demonstrates a JSON dictionary in S3.

I respect your solutions with other questions Jim. But, here, you're clearly wrong and can't observe how individuals points are justified.

Technically a typical layer can be done. However question this will make sense. Couchdb has integrated map/reduce functions for the documents that are uncovered as "sights". I do not think SimpleDB hat anything like this. However SimpleDB has query expressions which Couchdb hasn't. Of coure you are able to model thos expressions like a view in Couchdb knowing your query at development time.

Beside the common function is only create/update/remove a vital-document pair.