Terminology mapping
- What you and I (and CouchDB) would call a database, Amazon SimpleDB calls a domain.
- CouchDb documents and SimpleDB items will be referred to in this post as records.
- The JSON name:value pairs used in CouchDb documents and the attribute-value pairs in SimpleDB items will be called simply attributes.
A brief explanation: The developer documentation for SimpleDB states that attributes may have multiple values, but that attributes are uniquely identified in an item by their name/value combination. In the same paragraph, the docs give this as an example of an item’s attributes:
{ 'a', '1' }, { 'b', '2'}, { 'b', '3' }
By Amazon terminology, the ‘b’ attribute has two values. I think it clearer to regard this item as having three attributes, two of which have ‘b’ as their key.
What SimpleDB and CouchDB have in common
- Not relational databases
- Schemaless
- CouchDB is built with Erlang. SimpleDB may be, as well.
- support for data replication (this is a very sloppy generalization)
- accessed via HTTP
How SimpleDB and CouchDB Differ
SimpleDB:
- provides SOAP and (what passes at Amazon for) REST interfaces to the API
- REST requests all use HTTP GET, specifying the API method with a query param
- requests specify the database, record, attributes, and modifiers with query params
- record creation, updating, and deletion is tomic, at the level of individual attributes
- all data is considered to be UTF-8 strings
- automatically indexes data, details unknown
- queries
- limited to 5 seconds running time. Queries that take longer “will likely” return a time-out error.
- defined with HTTP query parameters
- composed of Boolean and set operations with some obvious comparison operators(=, !=, >, >=, etc.)
- as all values are UTF-8 strings, there are no sorting options.
- responses are XML
CouchDB:
- all REST, all the time
- requests use HTTP GET, PUT, POST, and DELETE with their usual RESTful semantics
- requests specify the database and record in the URL, with query params used for modifiers
- record creation, updating, and deletion is atomic
- supports all JSON data types (string, number, object, array, true, false, null)
- indexing is under user control, by means of “views”
- defined with arbitrary Javascript functions
- can be stored as documents
- can be run ad hoc, as “temporary views”
- queries are basically views, with the addition of modifiers (start_key, end_key, count, descending) supplied as HTTP query parameters
- sorting is flexible and arbitrarily complex, as it is based on the JSON keys defined in the views. See here for more information
- responses are JSON
Advertisements