1. What is Redis?
1.1. original idea and 1st version are from Salvatore Sanfilippo
1.2. open-source, written in ANSI C, networked, in-memory, key-value data store with optional durability, BSD licensed
1.3. write speed = read speed
1.3.1. asynchronous SET operation
1.3.2. asynchronous background saving
1.4. scalable
1.4.1. replication
1.4.2. clustering
1.5. can be used as shared memory for interoperability among system elements
1.6. sponsored by VMware
2. Features
2.1. key-value server
2.1.1. key is a string
2.1.2. value is a binary safe string (max 512 Megabytes)
2.2. data structure server
2.2.1. some data structures can be used as values
2.2.1.1. list
2.2.1.2. set
2.2.1.3. sorted set
2.2.1.4. hash
2.2.1.5. bit-map
2.2.1.5.1. NOT for storing pictures!
2.2.1.5.2. for bit operations
2.2.1.6. hyperloglog
2.2.1.6.1. creating sets
2.2.1.6.2. merging (union of) sets
2.2.1.6.3. get element count of sets
2.3. can persist (key-value store)
2.3.1. SAVE
2.3.1.1. syncronous
2.3.2. BGSAVE
2.3.2.1. asyncronous
2.3.2.2. configurable autosave
2.4. Transactions
2.5. topic subscription (publish-subscribe)
2.5.1. NOT durable!
2.6. replication
2.6.1. master-slave replication
2.6.1.1. SLAVEOF host port
2.6.2. tree replication
2.6.3. Publish/Subscribe feature is fully implemented, so a client of a slave may SUBSCRIBE to a channel and receive a full feed of messages PUBLISHed to the master, anywhere up the replication tree
2.6.4. Replication is useful for read (but not write) scalability or data redundancy.
2.7. clustering
2.7.1. will come in redis 3..0
2.7.2. more master with sharding
2.8. scripting
2.8.1. LUA
3. Clients available
4. OS support (server side)
4.1. Linux/Unix
4.2. OS X
4.3. Windows NOT supported, unofficial version exists
5. NoSQL
5.1. (Eric)Brewer's theorem in (max 2 letters of CAP but never 3 can be.)
5.1.1. Database classification by CAP
5.2. Data system design philosophies: ACID vs. BASE
5.2.1. ACID
5.2.1.1. Atomicity
5.2.1.1.1. Requires that each transaction be "all or nothing": if one part of the transaction fails, the entire transaction fails, and the database state is left unchanged.
5.2.1.2. Consistency
5.2.1.2.1. The consistency property ensures that any transaction will bring the database from one valid state to another.
5.2.1.3. Isolation
5.2.1.3.1. The isolation property ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially, i.e. one after the other.
5.2.1.3.2. The effects of an incomplete transaction might not even be visible to another transaction.
5.2.1.4. Durability
5.2.1.4.1. Durability means that once a transaction has been committed, it will remain so, even in the event of power loss, crashes, or errors.
5.2.1.4.2. DML result needs to be stored permanently
5.2.2. BASE
5.2.2.1. Basically Available
5.2.2.1.1. indicates that the system does guarantee availability, in terms of the CAP theorem.
5.2.2.2. Soft state
5.2.2.2.1. indicates that the state of the system may change over time, even without input. This is because of the eventual consistency model.
5.2.2.3. Eventual consistency
5.2.2.3.1. indicates that the system will become consistent over time, given that the system doesn't receive input during that time.
5.2.3. What does Redis guarantie from ACID?
5.2.3.1. Atomicity
5.2.3.1.1. transaction is possible with transaction delimiter statements: MULTI (begin), EXEC (commit), DISCARD (rollback)
5.2.3.2. Consistency
5.2.3.2.1. only for a standalone Redis server (because of the single threaded architecture)
5.2.3.2.2. NOTin a distributed environment (more nodes)
5.2.3.3. Isolation
5.2.3.3.1. because of the single threaded architecture
5.2.3.4. Durability
5.2.3.4.1. when 'appendfsync always' is set
5.2.3.4.2. asynchronous saving!