The new ArangoDB version 3.2 has been released with major improvements such as distributed graph processing based on Pregel and powerful data export tools. But the release is notable for its integration with Facebook’s RocksDB as ArangoDB’s first plug-in storage engine. With RocksDB, we can make ArangoDB support more data, as long as your disk is big enough.
Because this is a very important improvement, the community has many questions about the engine, and in this article we will focus on answering those questions.
Q: Can MY data exceed the system memory limit?
A: Yes, once the RocksDB storage engine is selected, the data size supported by the database is limited only by the size of the disk storage.
Q: What is the locking mechanism for RocksDB in ArangoDB?
A: When using the RocksDB storage engine, locks are write-based at the document level, while reads are not locked. Concurrent writes to the same document can result in write-write conflicts, and the error is returned to the calling code, so the user can simply retry.
Q: When you say that concurrent writes to the same document will result in write-write conflicts and the error will be returned to the calling code, does this mean that the locking behavior is different from that of existing memory-mapped files? Don’t write operations try to lock a document first?
A: Yes, the lock behavior is different from the current MMAP memory mapping. The MMAP engine is a collection-level lock, so there is no possibility of write-write conflicts. The RocksDB engine is a document-level lock, which can cause write-write conflicts.
Consider the following example: two transactions T1 and T2 both attempt to write a document to collection C.
In the old MMAP engine, these transactions were traversed, such as:
T1 begins
T1 writes document “a” in collection “c”
T1 commits
T2 begins
T2 writes document “a” in collection “c”
T2 commits
So there’s no write conflict.
With the RocksDB engine, transactions run in parallel, but once they modify the same document, locks are required to prevent some data updates from being lost. Xiamen dispatcher will cause write-write conflict:
T1 begins T2 begins T1 Document “A” in collection “C” T2 document “A” in collection “C” INDEX
At this point, T2 will be terminated to place the update lost. Concurrent writes to the same document cause write-write conflicts, and the error message is returned to the calling code, so the user can just try again when needed.
Q: Do I need a faster disk (such as SSD) when using the RocksDB storage engine?
A: Yes, using a faster disk is good for performance, whether RocksDB or MMAP file storage is the same.
Q: Can I choose different storage engines for different collections, or different storage engines for different databases?
The selection of storage engines is server – and cluster-specific, and the same ArangoDB instance or cluster cannot mix different storage engines.
Q: Can I change a collection of ArangoDB or the storage engine of the database from RocksDB to memory-mapped files?
This is a per-server or cluster choice. This selection is made when the server is started. The first server starts up and saves the selection of the storage engine in a disk file that is validated with each reboot. If you need to change the storage engine after the server is initialized, you can use Arangodump to export the data, then restart the ArangoDB service with an empty database directory and a different storage engine, and then restore the previously backed up data through arangoRestore.
Q: Is the index only stored on disk? Or just the type of index to store?
A: If you choose the RocksDB storage engine, all indexes will be persisted to disk.
Q: I use Microsoft Azure cloud host, which has very fast local SSD disks, but unfortunately this is temporary (meaning the host will be lost if it restarts), as well as slower network storage disks (also SSD, of course) that are not lost. Is there any way I can take advantage of this high-performance local SSD disk? For example, use it to do some quick queries, and then use the network disk to store persistent data?
RocksDB can generally specify different databases for different levels of databases. Typically, newer data is low-level, so low-level data can be written to SSDS first, and then RocksDB will move it to a slower HDD or network disk if it needs to move to a higher-level database. It is important to note that this is an option provided by RocksDB, not ArangoDB. In general, we do not think it is possible to implement a fast SSD or slow disk for each query, because a query may touch arbitrary data. However, the most recent data and some of the more frequently accessed data are stored in RocksDB’s in-memory cache block.