[
https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14630048#comment-14630048
]
T Jake Luciani commented on CASSANDRA-6477:
-------------------------------------------
We've made some performance related changes to the write path. I'll walk
through the results.
* Fixed timeout bug (this caused all the timeout exceptions we were seeing)
* Removed the need for a Coordinator batchlog when running RF=1
* Made the Base -> View batchlog update local only. Since each base replica
is paired to a view replica we only need to guarantee durability of the
batchlog on the local base node.
* Made the base -> view mutations async. Once we write to the local
batchlog, we don't care if the actual mutations are sent, it's best effort. So
we can fire and forget these and update the base memtable.
The performance hit is caused mostly 50% Batchlog and 50% Read before write.
TL;DR anything we can do to make BL or reads faster in trunk we will get
improvements on MV writes....
I'll start with the graph that I think is most relevant. RF=3 Batchlog vs RF=3
Materialized View
http://riptano.github.io/cassandra_performance/graph_v5/graph.html?stats=mv-2015-07-15%2Fcassandra-mv-vs-si-benchmark-rf3-batchlog.log&metric=op_rate&operation=3_user_logged&smoothing=1&show_aggregates=true&xmin=0&xmax=1092.08&ymin=0&ymax=20973.7
Overall 50% slower.
----
This next graph shows RF=1 results (These are not a realistic benchmark IMO but
these are the numbers)
http://riptano.github.io/cassandra_performance/graph_v5/graph.html?stats=mv-2015-07-15%2Fcassandra-mv-vs-si-benchmark-rf1.log&metric=op_rate&operation=3_user&smoothing=1&show_aggregates=true&xmin=0&xmax=621.28&ymin=0&ymax=131803.1
50% slower than 2i. >60% slower than regular writes
> Materialized Views (was: Global Indexes)
> ----------------------------------------
>
> Key: CASSANDRA-6477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6477
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Jonathan Ellis
> Assignee: Carl Yeksigian
> Labels: cql
> Fix For: 3.0 beta 1
>
> Attachments: test-view-data.sh, users.yaml
>
>
> Local indexes are suitable for low-cardinality data, where spreading the
> index across the cluster is a Good Thing. However, for high-cardinality
> data, local indexes require querying most nodes in the cluster even if only a
> handful of rows is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
