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
WARNING: cqlsh was built against 5.0-beta1, but this server is 5.0. All features may not work!
session_id | event_id | activity | source | source_elapsed | source_port | thread
--------------------------------------+--------------------------------------+-----------+------------+----------------+-------------+------------------------------
d4527520-2f69-11ef-bd2f-836fa334e187 | d452ea50-2f69-11ef-bd2f-836fa334e187 | Parsing ; | 172.31.0.2 | 2629 | null | Native-Transport-Requests-11
(1 rows)