Small Datum

This explains how to build MongoRocks for MongoDB 3.4 and is derived from my notes for building for MongoDB 3.2. My server uses Ubuntu 16.04. # Install many of the dependencies for MongoRocks. # I assume this is still valid. sudo yum install snappy-devel zlib-devel bzip2-devel lz4-devel sudo yum install scons gcc-g++ git # Unpack MongoDB 3.4 source in $MONGOSRC # Directory in which git repos are created mkdir ~/git # Get MongoRocks engine cd ~/git git clone https://github.com/mongodb-partners/mongo-rocks.git cd mongo-rocks git checkout --track origin/v3.4 -b v34 # figure out which version of gcc & g++ is installed # for ubuntu 16.04 that is 5.4 g++ --version # get and build RocksDB libraries # disable the use of jemalloc features git clone https://github.com/facebook/rocksdb.git cd rocksdb git checkout --track origin/5.2.fb -b 52fb EXTRA_CFLAGS=-fPIC EXTRA_CXXFLAGS=-fPIC DISABLE_JEMALLOC=1 make static_lib # prepare source build with support for RocksDB cd $M

I used a database that doesn't fit in the DBMS cache for part 5 in my unending series on sysbench and MyRocks. In this case I used really fast storage - the database fits in the OS page cache, reads are served from the OS page cache and writes are done to the fast SSD. A previous post has more details on the hardware . tl;dr MyRocks is much faster than compressed InnoDB except for InnoDB-5.7 with long range scans MyRocks had better or similar throughput than uncompressed InnoDB-5.6 for update-only, insert-only and short range scans. It was slower for long range scans and the point query test. MyRocks was faster than uncompressed InnoDB-5.6 for the update-only tests and slower for insert-only and tests with range/point queries. MyRocks was faster than TokuDB for all tests except the longest range queries Disclaimer The goal for MyRocks is the best space efficiency, great write efficiency and good enough read efficiency. The best space efficiency means it needs less SS

This post has more results for the test described in my previous post . Here I share the impact from disabling the binlog and binlog crash safety. I will repeat the disclaimer from my previous report. This test is done with a small and cached database that has 8M rows. InnoDB is a great choice for such a workload. I am not surprised that MyRocks and TokuDB are not great at this workload. The value for MyRocks and TokuDB is better compression and less write-amplification and that usually requires a larger database and the benefit grows when the database doesn't fit in RAM. But early evaluators might use sysbench so I want to understand how they perform in this setup. tl;dr: MyRocks gets up to ~1.5X more throughput with binlog crash safety disabled MyRocks gets up to ~3X more throughput with the binlog disabled InnoDB gets up to ~1.5X more throughput with the binlog disabled Another way to explain this is that MyRocks loses more throughput than InnoDB with the binlog and b