ScyllaDB is a NoSQL database compatible with Apache Cassandra and that is distinguished because each node supports millions of operations per second, with predictably low latency. Achieving such an advantage in speed is due to the fact that it uses a fully asynchronous programming model and which shares nothing, relies on its own memory allocators and meticulously schedules all its I/O requests.
Advantages of ScyllaDB
Scylla has some additional advantages:
- Has better performance (2 to 8 times) than even the latest version of Cassandra.
- The costs are lower especially because it saves time in administration, due to its lower complexity. For this reason, it is an alternative and replaces Apache Cassandra with great advantages.
- Another great advantage is its migration capabilities From the latter they make both databases fully compatible. They both have the same CQL interface, queries, controllers, and even the same format SSTable (Sorted Strings Table) On the disk.
- The advantage is that we will have an architecture designed to eliminate performance problems, limitations and operational barriers of Cassandra.
ScyllaDB vs Seastar
ScyllaDB uses seastar to fragment requests on each core. The application only has a thread per core. And how is this? When a session is being handled by core 1 and a query request for that session arrives at core 2, this request is directed to core 1 for processing. In this situation, either core can handle the response. In this way of working, where nothing is shared, there is a performance improvement, Since each thread has its own memory queues, CPU and buffer management NIC (Network Interface Card).
In cases where communication between cores cannot be avoided, the Framework Seastar offers asynchronous communication between several cores that is highly scalable.
When a row is found in a SSTable, must be sent over the network to the client. This involves copying data from user space to kernel space. However, Linux often performs blocking operations multithread which are not scalable. ScyllaDB takes care of it through the network stack framework Seastar. Network stack runs in user space and uses DPDK (Data Plane Development Kit) for faster packet processing. DPDK bypasses the kernel to copy data directly to the buffer of NIC and processes a packet within approximately 80 CPU cycles.
ScyllaDB and the page cache
Page caching is fine when you have sequential I/O and the data is stored on disk in wired. However, in Scylla/Cassandra, we have data in the form of SSTables. Page cache stores data in the same format which takes up a lot of memory for small data and needs serialization/deserialization when you want to transfer it and this can be a problem as we will see later.
ScyllaDB does not depend on page cache, allocates most of its memory to the row cache. Row-Cache (row cache) has the data in a memory format that is optimized, taking up less space and does not need serialization or deserialization. This makes it very secure, since serialization is a process of translating data structures into a format that can be stored and reconstructed later. Deserialization is transforming serialized data from a file, stream or network socket into an object, and it is in this last process where the vulnerability lies.
For all these reasons, depending on what you are looking for, Scylla It must be taken into account when high execution speeds are needed.
Excellent blog congratulations