[RELEASE] Scylla 2.2 Release Candidate(RC) 1
Tzach Livyatan
<tzach@scylladb.com>The Scylla team is pleased to announce the release of Scylla 2.2 RC1, the first Release Candidate for Scylla 2.2. From now on only critical bugs, will be fixed in branch-2.2. We will continue to fix bugs and add features to the master branch.
Scylla 2.2 release includes improvements in latencies under different conditions, improved security with RBAC, improved HA with the hinted handoff, and many others.
Scylla is an open source, Apache-Cassandra-compatible NoSQL database, with superior performance and consistently low latency. Find Scylla 2.2 repository for your Linux distro here (under More Versions)
Use with caution; RC1 is not officially production-ready yet. Help us stabilize 2.2 by reporting bugs here. Please note only the last two minor releases of the Scylla open source project are supported. Once 2.2 is out, only 2.2 and 2.1 will be supported.
You can use Scylla 2.2-rc1 with Docker by running the following command:
docker run --name some-scylla-2.2rc1 -d scylladb/scylla:2.2-rc1
Related Links
* Get Scylla 2.2 (under “More Versions”)
* Upgrade from Scylla 2.1 to Scylla 2.2
New features in Scylla 2.2
* Role Based Access Control (RBAC) - compatible with Apache Cassandra 2.2
RBAC is a method of reducing lists of authorized users to a few roles assigned to multiple users. RBAC is sometimes referred to as role-based security.
For example:
CREATE ROLE agent;
GRANT CREATE ON customer.data TO agent;
GRANT DESCRIBE ON customer.data TO agent;
GRANT SELECT ON ALL KEYSPACES TO agent;
GRANT MODIFY ON customer.data TO agent;
CREATE ROLE supervisor;
GRANT agent TO supervisor;
For the rest of more on Scylla RBAC example here
For CQL RBAC reference here
Note that you need to have Authentication enabled to use roles.
* Hinted Handoff - experimental.
Hinted handoff is a Scylla feature that improves cluster consistency, compatible with Apache Cassandra 2.1 Hinted handoff feature. When a replica node is not available for any reason, the coordinator keeps a buffer of writes (hints) to this replica. When the node becomes available again, hints are replayed to the replica. The buffer size is limited and configurable. You enable or disable hinted handoff in the scylla.yaml file.
More on hinted handoff here
Performance improvements in Scylla 2.2
We continue to invest in increasing Scylla throughput and reduced latency, and in particular, improves consistent latency, focusing on high percentile latencies.
* Row-level cache eviction
Partitions are now evicted from in-memory cache with row granularity which improves the effectiveness of caching and reduces the impact of eviction on latency for workloads which have large partitions with many rows.
* Improve paged single partition queries #1865
Paged single partition queries are now stateful, meaning they save their state between pages so they don't have to redo the work of initializing the query on the beginning of each page. This results in improved latency and vastly improved throughput. This optimization is mostly relevant to workloads that hit the disk, as initializing such queries involves extra I/O. The results are 246% better performance with lower latency when selecting by partition key with an empty cache. More here.
* Improve row digest hash #2884
The algorithm used to calculate a row’s digest was changed from md5 to xxHash, improving throughput and latency for big cells. See the issue comment for a microbenchmark result. For an example of how digest is used in a Scylla Read Repair see here.
* CPU Scheduler and Compaction controller for STCS
With Scylla’s thread-per-core architecture, many internal workloads are multiplexed on a single thread. These internal workloads include compaction, flushing memtables, serving user reads and writes, and streaming. The CPU scheduler isolates these workloads from each other, preventing, for example, a compaction using all of the CPU and preventing normal read and write traffic from using its fair share.
The CPU scheduler complements the I/O scheduler which solves the same problem for disk I/O. Together, these two are the building blocks for the compaction controller.
* Promoted index for wide partitions (#2981)
Queries seeking through a partition used to allocate memory for the entire promoted index of that partition. In case of really huge partitions, those allocations would also grow large and cause ‘oversized allocation’ warnings in logs. Now the promoted index is consumed incrementally so that the memory allocation never grows uncontrollably.
Metrics updates from 2.2
scylla Grafana Monitoring project now includes Scylla 2.2 dashboard
See here for all metrics change in 2.2
Chan Lewis
<baiwfg2@gmail.com>Tzach Livyatan
<tzach@scylladb.com>--
You received this message because you are subscribed to the Google Groups "ScyllaDB users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scylladb-users+unsubscribe@googlegroups.com.
To post to this group, send email to scylladb-users@googlegroups.com.
Visit this group at https://groups.google.com/group/scylladb-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/scylladb-users/878451e8-98f8-4376-ae77-1178cbb09723%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Tomasz Grabiec
<tgrabiec@scylladb.com>Hi. Tzach. Right now I just want to know whether scylla's read path is totally same as cassandra's read path when a select request is received . The following is cassandra's read path:- our row cache covers only sstables (on-disk data), not sstables and memtables. So a read always combines from
I feel scylla's row_cache may be not working like that, but I'm not sure. So is scylla's read path same as the above description ?
