1. http://www.thoughtworks.com/articles/nosql-comparison
2. Why now?
   1. Database scaling issues
   2. Availability of options (open src)
   3. Nature of data
   4. Schema changing and/or needs unconventional treatment
3. Characteristics
   1. Easy to use in conventional load-balanced clusters
   2. Persistence (not just cache)
   3. Scale to available memory
   4. No fixed schema; schema migration w/o downtime
   5. Individual query system; no std query language
   6. ACID within a node of cluster; eventually consistent across cluster
4. Use cases
   1. Relational DB does not scale
   2. Data distributed in time dimension; Can't save all in RDBMS
   3. Performance issues
   4. Lots of BLOB/CLOB
   5. Temporary data (e.g. shopping card)
   6. Non-crucial data; Durability not reqd
   7. Non-conventional queries
5. Query issues
   1. No SQL uniformity
   2. SparQL for RDF/Tuples
   3. Need something uniform
6. Deployment situations
   1. Decoupling helps
   2. No what must be RDBMS; what could be NoSQL
7. Implementations
   1. Key-value stores
      1. Tokyo cabinet, Voldemort
      2. Cache-type data
      3. Fast retrieval
      4. No schema
   2. Document databases
      1. MongoDB, CouchDB
      2. Can handle incomplete data; Document-type web apps
      3. Query performance bad; No query language
   3. Graph databases
      1. Neo4J, Infinite Graph
      2. Graph-type data and algorithms easy to handle
      3. Slow; Needs to traverse entire graph
   4. XML databases
      1. Oracle, MarkLogic
      2. Document workflow systems
      3. XML validation, XPath/XSL tools
   5. Distributed peer stores
      1. HBase, Cassandra, Riak
      2. Distributed file system type apps
      3. Fast retrieval; excellent distributed approach
      4. Low-level retrieval API
   6. Object stores
      1. db4o, ObjectStore
      2. Uses OO paradigm
      3. Low-latency acid
      4. Querying is an issue