Dr. Chuck Cartledge. 3 Dec. 2015

Transcription

1 CS-695 NoSQL Database Redis (part 2 of 2) Dr. Chuck Cartledge 3 Dec /14

2 Table of contents I 1 Miscellanea 2 DB comparisons 3 Assgn. #7 4 Misc. things 6 Course review 7 Conclusion 8 References 5 Summary 2/14

3 Corrections and additions since last lecture. Assignment #07 is over due by today 3/14

4 How different DBs compare to a RDBMS We have some terms to compare now[1] RDBMS K/V Columnar Doc. Graphic Redis DB. instance cluster cluster instance database namespace id table bucket table collection row key-value row document node id key-value rowid key id key col. col. fam. key schema database join DBRef INT rel. id 4/14

5 Words of explanation. The full text is available at: In general terms: 1 Design the database, particularially the definition of a key 2 Parse data 3 Populate the database 4 Query the database using the keys 5 Manipulate the results (may be minimal based on how keys are defined) 6 Plot data 5/14

6 A collection of things that are nice to know Durability 1 By default, Redis is memory resident. Data can be snapshotted under user control Format: save seconds number keys Example: save Example: save All write directives are maintained in an Append-Only File when server starts, the AOF file is re-executed All save directives are independent /14

7 A collection of things that are nice to know Security Redis is designed to be accessed by trusted clients inside trusted environments. 2 Network security (trusted clients, ACL, etc.) Thin protection via AUTH commands Disabling of specific commands via obfuscation Snapshot files can be written anywhere, so they make all internal data vulnerable In general, Redis is not optimized for maximum security but for maximum performance and simplicity /14

8 A collection of things that are nice to know Replication Slave has an exact copy of the master. Writes to master are propagated to the slave(s) Slaves are read-only by default When master is lost, slave can be promoted to master Image from [2]. Allows upgrades to master with minimal downtime (may be 0). 8/14

9 A collection of things that are nice to know Clustering via Redis Sentinel 3 Monitoring constantly checks if your master and slave instances are working as expected. Notification Sentinel can notify the system administrator, another computer programs, via an API, that something is wrong with one of the monitored Redis instances. Automatic fail over if a master is not working as expected, Sentinel can start a fail over process where a slave is promoted to master, the other additional slaves are reconfigured to use the new master, and the applications using the Redis server informed about the new address to use when connecting. Configuration provider Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a fail over occurs, Sentinels will report the new address /14

10 Strengths and weaknesses Good and not so good Strengths: It is fast Supports interesting search capabilities and operations on keys and values The user controls when data is persisted It is memory resident Master-slave relationship supports eventual replication Lots of commands for interacting with keys and values Weaknesses: It is memory resident The user controls when data is persisted (data vulnerable if memory resident before persisted) Does not (deliberately) use virtual memory. Goal is speed. 10/14

11 Applicabilities Good for, and not so good for Good fit; Manipulating in memory data structures (leaderboards, order by user votes/time, unique N items, real-time analysis) Publisher/subscriber systems Queues All things cache related Not so good fit: Exotic data queries Redis is an in-memory data structure server. 11/14

12 Things that we covered Databases, queries, presentations We covered several database technologies (RDBMS, K/V, columnar, document, graphic, and data structure), their strengths and weaknesses, and where each is a good (or not so good) fit. We covered different data presentations (Sarah and Hasta), and some of the strengths and weaknesses of each. We added tools to our tool bag. 12/14

13 What have we covered? Reviewed assignment #07 Reviewed the course Next time: We will cover different topics. 13/14

14 References I [1] Eric Redmond and Jim R Wilson, Seven databases in seven weeks, Pragmatic Bookshelf, [2] Packt Staff, Implementing persistence in redis, /14