36
REmote DIctionary Server Chris Keith James Tavares

Redis Presentation

Embed Size (px)

Citation preview

Page 1: Redis Presentation

REmote DIctionary Server

Chris KeithJames Tavares

Page 2: Redis Presentation

OverviewHistoryUsersLogical Data Model

Atomic OperatorsTransactions

Programming Language APIsSystem Architecture

Physical Data StructuresData PersistenceReplication, Consistency, Availability

Benchmarks

Page 3: Redis Presentation

HistoryEarly 2009 - Salvatore Sanfilippo, an Italian developer, started the Redis projectHe was working on a real-time web analytics solution and found that MySQL could not provide the necessary performance.June 2009 - Redis was deployed in production for the LLOOGG real-time web analytics websiteMarch 2010 - VMWare hired Sanfilippo to work full-time on Redis (remains BSD licensed)Subsequently, VMWare hired Pieter Noordhuis, a major Redis contributor, to assist on the project.

Page 4: Redis Presentation

Other Users

Page 5: Redis Presentation
Page 6: Redis Presentation
Page 7: Redis Presentation

Logical Data Model

Data ModelKey

Printable ASCII

ValuePrimitives

StringsContainers (of strings)

HashesListsSetsSorted Sets

Page 8: Redis Presentation

Logical Data Model

Data ModelKey

Printable ASCII

ValuePrimitives

StringsContainers (of strings)

HashesListsSetsSorted Sets

Page 9: Redis Presentation

Logical Data Model

Data ModelKey

Printable ASCII

ValuePrimitives

StringsContainers (of strings)

HashesListsSetsSorted Sets

Page 10: Redis Presentation

Logical Data Model

Data ModelKey

Printable ASCII

ValuePrimitives

StringsContainers (of strings)

HashesListsSetsSorted Sets

Page 11: Redis Presentation

Logical Data Model

Data ModelKey

Printable ASCII

ValuePrimitives

StringsContainers (of strings)

HashesListsSetsSorted Sets

Page 12: Redis Presentation

Logical Data Model

Data ModelKey

Printable ASCII

ValuePrimitives

StringsContainers (of strings)

HashesListsSetsSorted Sets

Page 13: Redis Presentation

Shopping Cart ExampleRelational Modelcarts

cart_lines

UPDATE cart_linesSET Qty = Qty + 2WHERE Cart=1 AND Product=28

Cart Product Qty1 28 11 372 22 15 12 160 52 201 7

CartID User1 james2 chris3 james

Page 14: Redis Presentation

Shopping Cart ExampleRelational Modelcarts

cart_lines

UPDATE cart_linesSET Qty = Qty + 2WHERE Cart=1 AND Product=28

Redis Modelset carts_james ( 1 3 )set carts_chris ( 2 )hash cart_1 { user : "james" product_28 : 1 product_372: 2}hash cart_2 { user : "chris" product_15 : 1 product_160: 5 product_201: 7}

HINCRBY cart_1 product_28 2

Cart Product Qty1 28 11 372 22 15 12 160 52 201 7

CartID User1 james2 chris3 james

Page 15: Redis Presentation

Atomic Operators - KV StoreStrings - O(1)

GET keySET key valueEXISTS keyDEL key

SETNX key valueSet if not exists

GETSET key valueGet old value, set new

Hashes - O(1)�HGET key fieldHSET key field valueHEXISTS key field

HDEL key field

Hashes - O(N)HMGET key f1 [f2 ...]

Get fields of a hash

KKEYS key | HVALS keyAll keys/values of hash

Page 16: Redis Presentation

Atomic Operators - SetsSets - O(1)

SADD, SREM, SCARDSPOP key

Return random member of the set

Sets - O(N)SDIFF key1 key2SUNION key1 key2

Sets - O(C)SINTER key1 key2

Page 17: Redis Presentation

Atomic Operators - SetsSets - O(1)

SADD, SREM, SCARDSPOP key

Return random member of the set

Sets - O(N)SDIFF key1 key2 ...SUNION key1 key2 ...

Sets - O(C*M)SINTER key1 key2 ...

Sorted Sets - O(1)ZCARD key

Sorted Sets - O(log(N))ZADD key score memberZREM key memberZRANK key member

Sorted Sets - O(log(N)+M))ZRANGE key start stopZRANGEBYSCORE

key min max

Page 18: Redis Presentation

TransactionsAll commands are serialized and executed sequentiallyEither all commands or no commands are processedKeys must be overtly specified in Redis transactions Redis commands for transactions:

WATCHMULTIDISCARD EXECUNWATCH

Page 19: Redis Presentation

Programming Language APIs

ActionScriptC

C#C++

ClojureCommon Lisp

ErlangGo

HaskellhaXe

Io

Java LuaObjective-CPerlPHPPythonRubyScalaSmalltalkTcl

Page 20: Redis Presentation

API Examples

Page 21: Redis Presentation

System ArchitectureRedis Instance

Main memory databaseSingle-threaded event loop (no locks!)

Virtual MemoryEvicts "values" rather than "pages"Smarter than OS with complex data structuresMay use threads

Sharding: application's job!

Page 22: Redis Presentation

Data PersistencePeriodic Dump ("Background Save")

fork() with Copy-on-Write, write entire DB to diskWhen?

After every X seconds and Y changes, or,BGSAVE command

Append Only FileOn every write, append change to log fileFlexible fsync() schedule:

Always, Every second, or, NeverMust compact with BGREWRITEAOF

Page 23: Redis Presentation

Data Structure InternalsKey-Value Store ("hash table")

Incremental, auto-resize on powers of twoCollisions handled by chaining

Hash Collection< 512 entries

"zipmap" -- O(N) lookups, O(mem_size) add/delete

> 512 entriesHash Table

Page 24: Redis Presentation

Data Structure InternalsSet Collection

< 512 integers: "intset" -- O(N) lookupseverything else: Hash Table

Sorted Set Collection -- O(log N) insets/deletesIndexable Skip List: Scores+Key => ValuesHash Table: Key => Score

List Collection< 512 entries: "ziplist"

O(mem_size) inserts/deletes > 512 entries: Doubly Linked List

O(1) left/right push/pop

Page 25: Redis Presentation

ReplicationTopology (Tree)

Master is largely "unaware" of slavesNo quorums (only master need accept the write)

Selection of master left to client!All nodes accept "writes"All nodes are master of their own slaves Writes propagated downstream ONLY (asynchronously)

Slave Roles:Offload save-to-diskOffload reads (load balancing up to client)Data redundancy

Write GlobalData Here

Write LocalData Here

Page 26: Redis Presentation

Redis & CAP TheoremC & A

Writes: single masterReads: any node

Eventually consistent, no read-your-own-writes

C & POn failure: inhibit writesConsequence: decreased availability

A & POn failure: elect new masterConsequence: inconsistent data,no easy reconciliation

"Redis Cluster" is in development but not currently available

Page 27: Redis Presentation

Benchmarks - Client Libraries

Page 28: Redis Presentation

Benchmarks - Hardware

Page 29: Redis Presentation

Questions?

Page 30: Redis Presentation

Additional Slides

Page 31: Redis Presentation

MotivationImagine

lots of datastored in main memory as:

hash maps, lists, sets, and sorted setsO(1) -- GET, PUT, PUSH, and POP operationsO(log(N)) -- sorted operations

Imagine 100k requests per second per machine

Imagine Redis!

Our Goal:Give you an overview of Redis externals & internals

Page 32: Redis Presentation

Replication ProcessChronology

SLAVE: Connects to master, sends "SYNC" commandMASTER: Begins "background save" of DB to diskMASTER: Begins recording all new writesMASTER: Transfers DB snapshot to slaveSLAVE: Saves snapshot to diskSLAVE: Loads snapshot into RAMMASTER: Sends recorded write commandsSLAVE: Applies recorded write commandsSLAVE: Goes live, begins accepting requests

Page 33: Redis Presentation

Used in "crowd-sourcing" application for reviewing documents related to MP's (members of Parliament) expense reportsMajor challenge was providing a random document to a reviewInitial implementation used SQL "ORDER BY RAND()" command to choose an new document for a reviewerRAND() statement account for 90% of DB loadRedis implementation leveraged SRANDMEMBER() command to generate a random element (document id) from a setRedis was also used to manage account registration process for document reviewers

Page 34: Redis Presentation

Uses Redis as a three level site-caching solution"Local-Cache" for 1 server/site pair

user sessions/pending view count updates "Site-Cache" for all servers in a site

Hot question id lists/user acceptance rates "Global-Cache" is shared among all sites and servers

Inbox/usage quotas Cache typically includes approximately 120,000 keys

Most expire within minutesNumber is expected to grow as confidence is gained

Peak load is a few hundred reads/writes per secondCPU Usage on dedicated Redis machine is reported to be 0%Memory usage on dedicated Redis machine is < 1/2 GB

Page 35: Redis Presentation

SchemaSchema

Informal, free-form "Namespaces"

Example Keys:user:1000:pwd

User 1000's password

user.next.idThe next user ID to be assigned

Page 36: Redis Presentation

Redis and the CAP TheoremAchieving the ideals of the CAP Theorem depends greatly on how an instance of Redis is configured. A clustered version of Redis is in development but not currently available.

ConsistencyA single node instance of Redis would provide the highest levels of consistency. Writes propagate down the replication tree. Consistent writes must be written directly to the master node. Consistent reads depend on the speed of the synchronization process.

Availability Adding more nodes increases availability for reads and writes. However, adding more nodes greatly increases the complexity of maintaining consistent data due to the "down-hill" propagation of write operations.

Partition ToleranceTolerating network partitions is a major weakness of a Redis system. Logic for detecting failures and promoting slave nodes to master's and reconfiguring the replication tree must be handled by the application developer.