Hi, I am Eduardo Berrocal from Intel. And in this video, I cover how the software architecture of Apache Cassandra has transformed in order to use persistent memory. 

Persistent memory is byte-addressable. This property, which allows us to directly persist without [? serialization ?] or data structures is key in order to simplify code complexity dealing with data persistence. 

For the application, this code simplification means fewer instructions to execute in both the read and write paths, in turn, improving overall performance. Let's take a look at the changes we have done to the Cassandra architecture to take advantage of persistent memory. 

Due to performance considerations in write-heavy workloads, writes in Cassandra are stored only on the main table data structure in memory, doing event or flashing operations in order to synchronize with the tables on these. In order to avoid possible data losses due to node crashes, Cassandra also writes all operations to a log-on which can be used for recovery if needed. 

Compare that with the persistent memory version of Cassandra. In this case, only one data structure is needed. Since the structure presides on persistent memory already, one single write is all we need. No log-in or any other write-to-disk is necessary. 

Let's look now to the case of reads. Read parts in the original Cassandra are even more complex than writes. First, Cassandra uses the blue filter to determine if the key we want to read is likely to be in the note. 

Next, it looks in the key cache. If we are lucky and the key is there, then Cassandra accesses the compression offsets to know where should we go and look for the requested data on the SS table files. 

If the key is not in the key cache, however, Cassandra needs to perform an extra read-to-disk in order to find the keys-related information in the partition index. Once the data is read from the SS table, the main table is explored in case there are recent writes not flashed yet to disk. If that is the case, the data read from the main table is merged with the data read from the SS table before returning it to the client. 

If we go back to the persistent memory version of Cassandra, we can see that, again, a single read through a single data structure is all we need to fetch the keys-related data for the client. 

With this new design, Cassandra does not need to split the data model into the performance optimized part, store in the ram, versus the persistent part, store in disk. Persistent memory allows Cassandra to have a single, unified data model. 

This transformation is not only possible for just Cassandra. Any distributed database out there can be modified using the same principles shown in this video. If you are a software developer for distributed database systems, I urge you to take a look at the benefits that persistent memory can bring to your system. 

The Apache Cassandra transformation to persistent memory is open-source, and is available at the link provided. Thanks for watching. Don't forget to like this video and subscribe.