DataStax Academy FAQ

DataStax Academy migrated to a new learning management system (LMS) in July 2020. We are also moving to a new Cassandra Certification process so there are changes to exam bookings, voucher system and issuing of certificates.

Check out the Academy FAQ pages for answers to your questions:


question

pranali.khanna101994_189965 avatar image
pranali.khanna101994_189965 asked ·

Were reads and writes asynchronous even before DSE 6.0?

in the course DS201 there is a section in which in DSE6.0 there are huge performance improvements in cassandra with respect to vertical scaling which is now supported due to one thread per core handling strategy.

it said reads and writes are asynchronous .

" Writes :

1. Each thread gets its own memtable section to write to.

2. writes divided by token amogst available threads. "

Was this introduced in DSE 6.0 only ?

before dse6.0 all reads and writes were synchronous or ?

when there is multiple read/write request for same partition key landing on the same node. were they executed synchronously or asynchronously before?

performancethread-per-core
10 |1000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

Erick Ramirez avatar image
Erick Ramirez answered ·

Open-source Apache Cassandra uses the traditional staged event-driven architecture (SEDA) where tasks are executed by threads synchronously. This has worked well for quite some time now but we know that the synchronous nature of the architecture can lead to extremely high context-switching during peak loads which can cause resource contention and degrades the performance of the nodes.

In DSE 6.0, we released a new feature called Advanced Performance. Under the hood is a thread-per-core (TPC) architecture which significantly improves read and write performance with asynchronous IO -- read and write requests are no longer synchronous to remove thread contention and keeps IO threads processing.

This feature uses the Linux kernel LibAIO access library libaio, AIO being short for asynchronous input/output. This means that it only works when the libaio package is installed on the nodes. Otherwise, reads and writes are done synchronously as before.

For more info, see the blog post DSE Advanced Performance: Apache Cassandra™ Goes Turbo. Cheers!

Share
10 |1000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

saravanan.chinnachamy_185977 avatar image
saravanan.chinnachamy_185977 answered ·

@pranali.khanna101994_189965 Apache Cassandra uses a traditional, staged, event-driven architecture (SEDA). DSE 5.1 Architecture used multiple threads per task and hence the threads needed coordination and context switching. Also events were synchronous. That is the reason adding more cpu cores did result in contentions and slowdowns.


In DSE 6.0, major architecture changes were introduced. Coordination free, thread per core and asynchronous operation for reads, writes, and other tasks were introduced.

Please refer to our documentation for more details and performance comparisons at DSE 6.0 Architecture

Share
10 |1000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.