The ScyllaDB team is pleased to announce the availability of ScyllaDB Open Source 3.1.0, a production-ready release of our open source NoSQL database.
ScyllaDB is an open source NoSQL database offering the same Cassandra Query Language (CQL) interface as Apache Cassandra, along with the same horizontal scale-out and fault-tolerance characteristics. Implemented from scratch in C++ with a close-to-the-hardware architecture, ScyllaDB delivers 10X the throughput, consistent, low single-digit latencies, and significantly reduces the number of database nodes you require and self-optimizes to dynamic workloads and various hardware combinations.
With the release of ScyllaDB Open Source 3.1, we’ve introduced a number of new features that we’ve described in this post.
Support for I3en servers
The Amazon EC2 I3en series, exclusively available on AWS, offers a far higher density of storage than other nodes — up to 60 terabytes on a single server. ScyllaDB has conducted extensive testing on these servers, which are now supported in ScyllaDB Open Source 3.1.
We’ve changed our software packaging to make it easier to build and release. While this should not affect most customer usage, we thought we’d share how we’ve overhauled our software packaging. Rather than building our releases for each operating system distribution, we are making one build per release. This will minimize the dissimilarities between operating systems, increasing reliability and aid in debugging.
Additionally, dependencies will be bundled in the package file, which allows you to download a single file instead of having to collect all the related dependencies.
While this does not yet enable rootless or full offline install modes, it lays the foundation for such capabilities in the future.
You can read more about our quest for a portable Python interpreter here.
SSTable 3.0 enabled by default
SSTable 3.0 format, which is compatible with the Apache Cassandra “mc’ format, was first made available in ScyllaDB Open Source release 3.0. This format can save on disk space by 50% or more. It now be the default format. However, for users who wish to keep the old SSTable format, they can disable this feature in their scylla.yaml by setting the following parameter:
Local Secondary Indexes
ScyllaDB now supports both local and global secondary indexes — the choice is now yours! Global Secondary Indexes have been a production-ready feature since ScyllaDB Open Source 3.0 (whereas they remain an experimental feature in Cassandra). With this release, ScyllaDB users can now also use local secondary indexes, which can make queries more efficient. For greatest flexibility you can even index columns both locally and globally.
Materialized View Improvements
Two changes were made to how ScyllaDB handles materialized views. The first minimizes the number of times a generated view is updated by avoiding updates for unselected columns (see #3819). If only unselected columns change, the materialized view does not need to be updated.
Also, by adding support for local secondary indexes (i.e. when the index table resides on the same partition as base data) we improved performance of an indexed query that also specifies a partition key; in such cases, the index will be queried locally (#4185).
CQL Per Partition Limit
The existing LIMIT feature in
CQL SELECT statements returns a set number of rows. The new per partition limit further allows you to set the number of partitions returned as a result. You can mix both row limits and per partition limits in the same CQL statement.
SELECT * FROM users PARTITION LIMIT 2will return 2 partitions
SELECT * FROM users PARTITION LIMIT 2 LIMIT 5will return 2 partitions and five rows from each
CQL BYPASS CACHE
BYPASS CACHE on
SELECT statements, introduced in ScyllaDB Enterprise 2019.1.1, is now available in ScyllaDB Open Source as of this release. This feature informs the database that the data being read is unlikely to be read again in the near future, and also was unlikely to have been read in the near past; therefore no attempt should be made to read it from the cache or to populate the cache with the data. This is mostly useful for range scans which typically process large amounts of data with no temporal locality and do not benefit from the cache.
SELECT * from heartrate BYPASS CACHE;
If you are using ScyllaDB Monitoring Stack, you can use the Cache section of the ScyllaDB Per Server dashboard, to see the effect of the BYPASS CACHE command on the cache hit and miss ratio.
BYPASS CACHE here.
ALLOW FILTERING Enhancements
A number of filtering enhancements were implemented, so that ALLOW FILTERING now supports:
- Multi-column restrictions (#3574)
- Restricted column not in SELECT clause (#3803)
- CONTAINS restrictions (#3573)
Read more about using the ALLOW FILTERING command in our documentation.
CQL Group Functions Count now works with Bytes Type
Group functions such as count, min or max for a column were not working with various data types such as blob, boolean or ASCII.
create table t (p int, c int, v boolean, primary key (p, c));
select count(v) from t where p = 1 and c = 1;
On Linux 4.19 or higher ScyllaDB will use a new method of waiting for network events — IOCB_CMD_POLL. ScyllaDB sponsored this change to the Linux kernel, which improved performance of the underlying Seastar framework by up to 10%. This highlights ScyllaDB’s commitment to the open source community and our deep understanding of the Linux operating system, and showcases how our expertise led to an improvement that can benefit all other Linux users.
Large Cell / Collection Detector
Large rows or very large cells can hamper ScyllaDB’s performance. We have already put in a significant amount of work to make finding large partitions easier (see the documentation on configuring and viewing the large partitions table), and also to make large partition scans twice as fast. On a more granular basis, it is also vital to find very large rows or large cells, such as blobs or collections. With this release, we have introduced both a large rows and large cells table.
Data from frequently-accessed partitions can be cached to improve performance, but beyond a certain point partitions that are too-frequently accessed can become bottlenecks — so-called “hot partitions.” We’ve discussed before how ScyllaDB generally handle hot partitions better than other databases such as Amazon DynamoDB or Google Cloud Bigtable. But that doesn’t mean the problem completely goes away.
To enable detection of such frequently-accessed data ScyllaDB has implemented nodetool toppartitions. This will report the most active partitions in a specified table for a set time frame, in terms of both reads and writes. You can use this command in conjunction with nodetool getendpoints to find out which node contains the partition.
This command rewrites SSTables for a keyspace/table to the latest ScyllaDB version. You can specify to run this action on a specific keyspace or table, or on all SSTables. Use this command if, for example, you are changing compression or encryption-at-rest options (encrypting or decrypting data), and you wish to rewrite the SSTable in the new format instead of waiting for a compaction.
This command is not required when enabling SSTable 3.0 (“mc”) format, or upgrading to a new version of ScyllaDB. (In those cases, ScyllaDB will write new SSTable, either in memtable flush or compaction, while keeping the old tables in the old format.)
Improved Row-level Repair
Repair is an anti-entropy mechanism in ScyllaDB. Row-level repair is feature that fixes individual rows, as opposed to partition-level repair which was used in ScyllaDB Open Source 3.0 and earlier releases. In the earlier versions of ScyllaDB, the system divides data in 100 partition sub-ranges, and computes checksums against them. If even a single row in any of those 100 partitions needed repair, all of that data needed to be streamed to the master repair node to be analyzed. This led to the situation where a great amount of unneeded data was streamed between nodes.
With ScyllaDB Open Source 3.1, checksums are kept against each row, meaning that repair can work at a far more granular basis. This minimizes both disk reads as well as data transfer over the network. This can significantly improve performance of repairs.
Now that you’ve read all about the new capabilities in ScyllaDB Open Source 3.1, download it now and try it out.
Also if you’d like more details, read the release notes for ScyllaDB Open Source 3.1.0 here.
And don’t forget that ScyllaDB Summit 2019 is just around the corner! If you want to ask our engineers about any of the features they’ve developed, network with your peers, or help influence the direction of ScyllaDB for the future, make sure to attend!