Data consistency and performance

Changing the consistency level can affect read performance. The tracing output shows that as you change the consistency level from ONE to QUORUM to ALL, performance degrades in from 1714 to 1887 to 2391 microseconds, respectively. If you follow the steps in this tutorial, it is not guaranteed that you will see the same trend because querying a one-row table is a degenerate case, used for example purposes. The difference between QUORUM and ALL is slight in this case, so depending on conditions in the cluster, performance using ALL might be faster than QUORUM.

Under the following conditions, performance using ALL is worse than QUORUM:

The data consists of thousands of rows or more.
One node is slower than others.
A particularly slow node was not selected to be part of the quorum.

Tracing queries on large datasets

You can use probabilistic tracing on databases having at least ten rows, but this capability is intended for tracing through much more data. After configuring probabilistic tracing using the nodetool settraceprobability command, you query the system_traces keyspace.

SELECT * FROM system_traces.events;

Results

 session_id                           | event_id                             | activity  | source     | source_elapsed | thread
--------------------------------------+--------------------------------------+-----------+------------+----------------+--------------
 59e4f4d0-38c3-11ef-bd85-f92c3c7170c3 | 59e765d0-38c3-11ef-bd85-f92c3c7170c3 | Parsing ; | 172.26.0.2 |           9995 | CoreThread-6

(1 rows)

Data consistency and performance

Tracing queries on large datasets

Was this helpful?

Give Feedback