2.  70s - Database access is hard and depends on the app  80s – Relational databases come on the scene  90s – Object oriented programming and DBs  00s – Interpreted languages, Agile

3.  Means an app that supports millions of users  Represents relationships  Variable usage (viral apps)  Data that is important aggregated, not by itself  Time-to-market vs. proper design  Uptime (availability) vs. correctness  Ease of management vs. customization

4.  Rejection of RDBMS as one-size-fits-all  Minimal functions and minimal admin  BASE  Basically available, Soft state, Eventually consistent  ACID  Atomic, Consistent, Isolation, Durable

5.  Written in C  Open-source and free (no royalties)  New BSD license  By Salvatore Sanfilippo  Created for a Web analytics project  Sponsored by VMWare  Used by various projects: github, craigslist, stackoverflow, digg

6.  Key-value dictionary with sets, lists  Single-threaded  Delayed writes  Data needs to be kept in-memory  Simple protocol  Lack of table, schema, or database  Very basic security

7.  Session store  One (or more) sessions per user  Many reads, few writes  Throw-away data  Timeouts

8.  Logging  Rapid, low latency writes  Data you don’t care that much about  Not that much data (must be in-memory)

9.  Low-latency write  Many reads throughout transaction  Short (less than a day)  Think a shopping cart or a file upload

10.  Data that you don’t mind losing  Records that can be accessed by a single primary key  Schema that that is either a single value or is a serialized object

11.  Java  Jedis (github) .NET  ServiceStack (Google Code)  Ruby  redis-rb (github)

12.  SET k v  GET k  MSET k v [k2 v2]  MGET k [k2 …]  GETSET k v  Returns value before set, sets new value  SETNX k v (only sets if does not exist)  SETEX k n v (expires a key after n seconds)

13.  Set is unordered grouping of values  SADD k v  SCARD k – counts set  SISMEMBER k v – checks to see if v is in set  SUNION k [k2 …] – adds sets  SINTER k [k2 …] – intersects sets  SDIFF k [k2 …] – subtracts sets

14.  Ordered group  LPUSH k v – prepends  LPOP k v – removes 1 st element  LINSERT k BEFORE || AFTER n v – inserts v before or after the nth element  RPUSH kv – appends  RPOP k v – removes last element  LLEN k – number of elements  LRANGE k n m – gets range n to m inclusive

15.  SLAVEOF host port  Asynchronous  Can chain together pub -> slave -> slave  Cannot chain together pub pub

16.  Sorted sets (indexed but with set operations, higher big-O complexity)  Hashes (many values for one key)  HSET k field v – sets v for field for k  HGET k field  MULTI / EXEC / DISCARD / WATCH – xactions  Message queues (Pub/Sub)

17.  Startup info  Client logins  Databases and number of keys  Background saves and time  Replication

18.  Bottleneck on memory  Low CPU  Disk only on flush

19.  Amortized  SET, GET, etc – O(1)  KEYS – O(N)  ZADD, ZREM, etc – O(log(n))

20.  General Types of Databases  Relational Databases – Oracle, Postgres, MySQL  Object Stores – Objectivity, Cache, db4o  Key Value Stores – Berkelely DB, Riak, Cassandra  Document Stores – Mongo, Lotus, Couch  Graph Databases – Neo4j, InfoGrid Redis is a key value store

21.  Intentionally made for clustering  Replicas are not consistent  Written in Java  Much more robust organization  Often called a column-store, though this is a misnomer  Imitates Dynamo

22.  Written in Erlang  Robust organization  REST Api  Made for clustering, similar to Cassandra  Imitates Dynamo

23.  Document store – can represent objects natively – understands its data  Can access by values  Much more advanced architecture  Auto-sharding