No SQL

1. Use Cases

1.1. Relational DB does not scale

1.2. Data distributed in time dimension; Can't save all in RDBMS

1.3. Performance issues

1.4. Lots of BLOB/CLOB

1.5. Temporary data (e.g. shopping card)

1.6. Non-crucial data; Durability not reqd

1.7. Non-conventional queries

2. Query Issues

2.1. No SQL uniformity

2.2. SparQL for RDF/Tuples

2.3. Need something uniform

3. Deployment situations

3.1. Decoupling helps

3.2. No what must be RDBMS; what could be NoSQL

4. Why Now?

4.1. Database scaling issues

4.2. Availability of options (open src)

4.3. Nature of data

4.4. Schema changing and/or needs unconventional treatment

5. Characteristics

5.1. Easy to use in conventional load-balanced clusters

5.2. Persistence (not just cache)

5.3. Scale to available memory

5.4. No fixed schema; schema migration w/o downtime

5.5. Individual query system; no std query language

5.6. ACID within a node of cluster; eventually consistent across cluster

6. Implementation

6.1. Key-value stores

6.1.1. Tokyo cabinet, Voldemort

6.1.2. Cache-type data

6.1.3. Fast retrieval

6.1.4. No schema

6.2. Document databases

6.2.1. MongoDB, CouchDB

6.2.2. Can handle incomplete data; Document-type web apps

6.2.3. Query performance bad; No query language

6.3. Graph databases

6.3.1. Neo4J, Infinite Graph

6.3.2. Graph-type data and algorithms easy to handle

6.3.3. Slow; Needs to traverse entire graph

6.4. XML databases

6.4.1. Oracle, MarkLogic

6.4.2. Document workflow systems

6.4.3. XML validation, XPath/XSL tools

6.5. Distributed peer stores

6.5.1. HBase, Cassandra, Riak

6.5.2. Distributed file system type apps

6.5.3. Fast retrieval; excellent distributed approach

6.5.4. Low-level retrieval API

6.6. Object stores

6.6.1. db4o, ObjectStore

6.6.2. Uses OO paradigm

6.6.3. Low-latency acid

6.6.4. Querying is an issue