1. Some key-value stores using log-structure Zhichao Liang frankey0207@gmail.com LevelDB Riak

2. Outline Why log structure? Riak: log-structure hash table Rethinkdb: log-structure b-tree Leveldb: log-structure merge tree Conclusion

3. Outline Why log structure? Riak: log-structure hash table Rethinkdb: log-structure b-tree Leveldb: log-structure merge tree Conclusion

4. Log Structure A log-structured file system is a file system design first proposed in 1988 by John K. Ousterhout and Fred Douglis. Design for high write throughput, all updates to data and metadata are written sequentially to a continuous stream, called a log. Conventional file systems tend to lay out files with great care for spatial locality and make in-place changes to their data structures.

5. Log Structure for SSD Random write degrades the system performance and shrinks the lifetime of ssd. Log structure is ssd-friendly natively! Magnetic DiskSSD free data 1 new data 1 data 2 data 3 data 4 new data 3 block data 3 data 2 data 1 RAM free data 2 erased new data 1 data 2 data 3

6. Outline Why log structure? Riak: log-structure hash table Rethinkdb: log-structure b-tree Leveldb: log-structure merge tree Conclusion

7. Riak ? Riak is an open source, highly scalable, fault-tolerant distributed database. Supported core features: - operate in highly distributed environments - no single point of failure - highly fault-tolerant - scales simply and intelligently - highly data available - low cost of operations

8. Bitcask A Bitcask instance is a directory, and only one operating system process will open that Bitcask for writing at a given time. The active file is only written by appending, which means that sequential writes do not require disk seeking.

9. Hash Index: keydir A keydir is simply a hash table that maps every key in a Bitcask to a fixed-size structure giving the file, offset and size of the most recently written entry for that key.

10. Merge The merge process iterates over all non-active file and produces as output a set of data files containing only the “live” or latest versions of each present key.

11. Outline Why log structure? Riak: log-structure hash table Rethinkdb: log-structure b-tree Leveldb: log-structure merge tree Conclusion

12. RethinkDB ? RethinkDB is a persistent, industrial-strength key-value store with full support for the Memcached protocol. Powerful technology: - Linear scaling across cores - Fine-grained durability control - Instantaneous recovery on power failure Supported core features: - Atomic increment/decrement - Values up to 10MB in size - Multi-GET support - Up to one million transactions per second on commodity hardware

13. Installation & usage RethinkDB works on modern 64-bit distributions of Linux. Running the rethinkdb server: Ubuntu 10.04.1 x86_64 Ubuntu 10.10 x86_64 Red Hat Enterprise Linux 5 x86_64 CentOS 5 x86_64 SUSE Linux 10 Ubuntu 10.04.1 x86_64 Ubuntu 10.10 x86_64 Red Hat Enterprise Linux 5 x86_64 CentOS 5 x86_64 SUSE Linux 10 Default installation path: /usr/bin/rethinkdb-1.0./rethinkdb-1.0 -f /u01/rethinkdb_data./rethinkdb-1.0 -f /u01/rethinkdb_data -c 4 -p 11500./rethinkdb-1.0 -f /u01/rethinkdb_data -f /u03/rethinkdb_data -c 4 -p 11500 Default installation path: /usr/bin/rethinkdb-1.0./rethinkdb-1.0 -f /u01/rethinkdb_data./rethinkdb-1.0 -f /u01/rethinkdb_data -c 4 -p 11500./rethinkdb-1.0 -f /u01/rethinkdb_data -f /u03/rethinkdb_data -c 4 -p 11500

14. The methodology Firstly, lack of mechanical parts makes random reads on SSD are significantly efficient! Secondly, random writes trigger more erases, making these operations expensive, and decreasing the drive lifetime! RethinkDB takes an append-only approach to storing data, pioneered by log-structured file system! What are the consequences of appen- only ?

15. Append-only consequences Data Consistency Hot Backups Instantaneous Recovery Easy Replication Lock-Free Concurrency Live Schema Changes Database Snapshots 2) large amount of data that quickly becomes obsolete in an environment with a heavy insert or update workload 1) eliminating data locality requires a larger number of disk access

16. Append-only B-tree Page 1 15 Page 2 9 9 5 5 Page 3 19 15 Data File … … 5 5 9 9 19 15 Page 1 15 Page 2 9 9 5 5 Page 3 19 15 Page 3 19 15 Page 3 19 15 Page 1 15 Page 1 15

17. Outline Why log structure? Riak: log-structure hash table Rethinkdb: log-structure b-tree Leveldb: log-structure merge tree Conclusion

18. LevelDB ? LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values. Supported core features: - Data is stored sorted by key - Multiple changes can be made in one atomic batch - Users can create a transient snapshot to get a consistent view of data - Data is automatically compressed using the Snappy compression library

19. Installation & usage LevelDB works with snappy, which is a compression /decompression library. It is a library, no database server! svn checkout http://leveldb.googlecode.com/svn/trunk/leveldb-read-onlyhttp://leveldb.googlecode.com/svn/trunk/leveldb-read-only cd leveldb-read-only make && cp libleveldb.a /usr/local/lib && cp -r include/leveldb /usr/local/include svn checkout http://leveldb.googlecode.com/svn/trunk/leveldb-read-onlyhttp://leveldb.googlecode.com/svn/trunk/leveldb-read-only cd leveldb-read-only make && cp libleveldb.a /usr/local/lib && cp -r include/leveldb /usr/local/include download snappy from http://code.google.com/p/snappy/http://code.google.com/p/snappy/ cd snappy-1.0.4./configure && make && make install download snappy from http://code.google.com/p/snappy/http://code.google.com/p/snappy/ cd snappy-1.0.4./configure && make && make install libleveldb.a

20. Log-structure merge tree LevelDB

21. Outline Why log structure? Riak: log-structure hash table Rethinkdb: log-structure b-tree Leveldb: log-structure merge tree Conclusion

22. Log-structure