Riak Tutorial (Øredev)
by Sean Cribbs
- 4,051 views
Detailed discussion and exercises for understanding Riak, from Øredev 2010
Detailed discussion and exercises for understanding Riak, from Øredev 2010
Accessibility
Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Likes
- 15
- Downloads
- 0
- Comments
- 0
- Embed Views
- Views on SlideShare
- 4,019
- Total Views
- 4,051
1) large, fixed-size key-space
2) no rehashing of keys - always hash the same way
1) large, fixed-size key-space
2) no rehashing of keys - always hash the same way
1) large, fixed-size key-space
2) no rehashing of keys - always hash the same way
1) large, fixed-size key-space
2) no rehashing of keys - always hash the same way
1) large, fixed-size key-space
2) no rehashing of keys - always hash the same way
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
2) Get handler starts up to service the request
3) Hashes key to its owner partitions (N=3)
4) Sends similar “get” request to those partitions
5) Waits for R replies that concur (R=2)
6) Resolves the object, replies to client
7) Third reply may come back at any time, but FSM replies as soon as quorum is satisfied/violated
FT = fault-tolerance, C = consistency
Strong consistency (as opposed to strict) means that the participants in each read or write quorum overlap. The typical example is N=3, R=2, W=2. In all successful read requests, at least one of the read partitions will be one that accepted the latest write.
FT = fault-tolerance, C = consistency
Strong consistency (as opposed to strict) means that the participants in each read or write quorum overlap. The typical example is N=3, R=2, W=2. In all successful read requests, at least one of the read partitions will be one that accepted the latest write.
FT = fault-tolerance, C = consistency
Strong consistency (as opposed to strict) means that the participants in each read or write quorum overlap. The typical example is N=3, R=2, W=2. In all successful read requests, at least one of the read partitions will be one that accepted the latest write.
FT = fault-tolerance, C = consistency
Strong consistency (as opposed to strict) means that the participants in each read or write quorum overlap. The typical example is N=3, R=2, W=2. In all successful read requests, at least one of the read partitions will be one that accepted the latest write.
When there’s a detectable node outage/partition, writes will be sent to fallbacks (hinted handoff), which means that Riak is HIGHLY write-available.
Also, there’s an implied R quorum because the internal Erlang client has to fetch the object to update it and the vclock.
When there’s a detectable node outage/partition, writes will be sent to fallbacks (hinted handoff), which means that Riak is HIGHLY write-available.
Also, there’s an implied R quorum because the internal Erlang client has to fetch the object to update it and the vclock.
When there’s a detectable node outage/partition, writes will be sent to fallbacks (hinted handoff), which means that Riak is HIGHLY write-available.
Also, there’s an implied R quorum because the internal Erlang client has to fetch the object to update it and the vclock.
When there’s a detectable node outage/partition, writes will be sent to fallbacks (hinted handoff), which means that Riak is HIGHLY write-available.
Also, there’s an implied R quorum because the internal Erlang client has to fetch the object to update it and the vclock.
Finally here’s how you can submit all queries. Use the @- to signify that your data will come on the next line and be terminated by Ctrl-D.
Finally here’s how you can submit all queries. Use the @- to signify that your data will come on the next line and be terminated by Ctrl-D.