See all blog posts

ScyllaDB release: version 1.3

release

The ScyllaDB team is pleased to announce the release of ScyllaDB 1.3, a production-ready ScyllaDB minor release. ScyllaDB is an open source NoSQL database compatible with Apache Cassandra, with superior performance and consistent low latency. From now on, only critical bugs (showstoppers) will be fixed in release series. We will continue to fix bugs and add features on the master branch toward 1.4 and beyond. In parallel, we are already working on ScyllaDB 2.0, with many new goodies.

New features

  • Thrift support. Many Cassandra users are still using Thrift, and they can now continue doing so while benefiting from ScyllaDB’s performance. Built on top of ScyllaDB CQL internal implementation, ScyllaDB Thrift provides similar throughput and latency to ScyllaDB CQL. Users of projects like KairosDB and Titan can now migrate to ScyllaDB while maintaining full protocol compatibility .
    Read more about using ScyllaDB with Thrift.
  • Date Tiered Compaction Strategy (DTCS) is now supported in ScyllaDB. DTCS tries to keep data written chronologically in the same SSTable, reducing the number of SSTables in the read path, and improving performance. Use cases like time series are a good fit for DTCS. (Yes, we are going to do Time Window Compaction Strategy next )
    Read more about using ScyllaDB with DTCS.
  • Improved Large Partitions Support. Large Partitions were a thorn in the side for many ScyllaDB users so far. When the size of a partition becomes too big to handle in memory, compaction may fail, with not much users can do about it. Handling of large partitions was significantly improved in ScyllaDB 1.3. More on Large Partitions Support
  • CQL Tracing is a very useful tool when analyzing system latency issues. ScyllaDB now supports CQL TRACING ON/OFF command, as well as nodetool settraceprobability. Read more about tracing
  • Improved Docker support. Many users are running ScyllaDB in containers, either as part of a Docker base system, Mesos deployment or locally. In ScyllaDB 1.3 Docker has a relaxed polling mode and is less aggressive on resource consumption. As a result, one can safely run many ScyllaDB containers on one machine (overcommit).
  • ByteOrderedPartitioner. ByteOrderedPartitioner (BOP) is a legacy partitioner. BOP is added to ScyllaDB for users who already use BOP and wish to continue using it. For new deployments, we recommend using the default Murmur3Partitioner. To use BOP update the partitioner value in scylla.yaml. See an example of using BOP here.

Noteworthy updates in this release are

  • Enable internode compression – use LZ4 compression for internode communication. Use scylla.yaml, Internode_compression: all | dc | none
    • all – All traffic is compressed.
    • dc – Traffic between datacenters is compressed.
    • none – No compression (default)
  • Support for CQL 3.2.1 – CQL 3.2.1 syntax and semantic was already supported in ScyllaDB 1.2. In ScyllaDB 1.3 the CQL version is reported to the driver.
  • scylla-housekeeping, periodically check for the latest version of ScyllaDB, and notify the user when its deployment is out of date.
  • A new REST API to dynamically enable and disable metrics. Examples:
    • disabling all collectd metrics that plugin “cache” curl -X POST "http://localhost:10000/collectd/cache?instance=.*&type=.*&type_instance=.*&enable=false"
    • disabling all collectd metrics with “write” in their type_instance part curl -X POST "http://localhost:10000/collectd/.*?instance=.*&type=.*&type_instance=.*write.*&enable=false"
    • Enabling all collectd metrics that plugin “cache” curl -X POST "http://localhost:10000/collectd/cache?instance=.*&type=.*&type_instance=.*&enable=true"
    • Get the status of all metrics status in JSON format curl -X GET "http://localhost:10000/collectd/"

    Note that REST API is currently only available locally, from the host itself.

New metrics added in ScyllaDB 1.3

New Cache metrics

  • cache-0/total_operations-evictions – entries removed from the cache due to memory pressure
  • cache-0/total_operations-removals – entries removed from the cache usually due to errors or when streaming new data

New database metrics

  • database-0/queue_length-active_reads – the number of partition reads currently accessing the disk, for keyspaces other than the system keyspace; this gauge shows how loaded the disk is
  • database-0/queue_length-active_reads_system_keyspace – the number of partition reads currently accessing the disk, for the system keyspace; this gauge shows how loaded the disk is
  • database-0/queue_length-queued_reads – the number of partition reads that are queued, and not currently accessing the disk, for keyspaces other than the system keyspace; this gauge shows how loaded the disk is
  • database-0/queue_length-queued_reads_system_keyspace – the number of partition that are queued, and not currently accessing the disk, for the system keyspace; this gauge shows how loaded the disk is
  • database-0/total_operations-sstable_read_queue_overloads – a counter for the number of times a disk read had to be rejected because otherwise, the queue would grow too large

New IO Queue metrics

Each IO Queue metric includes two numbers, representing the IO queue and shard correspondingly. For example io_queue-X/delay-query-Y, stands for the delay of IO queue X in sharde Y. More below.

  • io_queue-0/delay-query-0 – time spent in the queue before being accepted for processing. (does not include disk time). units: seconds.
  • io_queue-0/derive-query-0 – bandwidth driven by this class. units: bytes / second
  • io_queue-0/queue_length-query-0 – the number of requests sitting at the queue waiting for processing. units: requests
  • io_queue-0/total_operations-query-0 – rate in which requests are being accepted for processing. units: requests / second

New CQL Trace metrics

  • tracing-0/queue_length-active_sessions – number of currently active trace sessions
  • tracing-0/queue_length-flushing_sessions – number of trace sessions that are being written to the I/O backend right now
  • tracing-0/queue_length-pending_for_flush_sessions – number of trace sessions that are pending to be written to the storage
  • tracing-0/total_operations-max_sessions_threshold_hits – rate with which we hit the maximum number of session limit – we don’t allow a total amount of active and pending sessions to bypass 2000 per single shard (this limit is going to be removed in the next release)
  • tracing-0/total_operations-max_traces_threshold_hits – a rate with which we hit a maximum number of trace entries per session limit – we allow not more than 30 trace entries per session (this limit is going to be removed in the next release)
  • tracing-0/total_operations-trace_events_count – a rate of generation of trace events
  • tracing_keyspace_helper-0/total_operations-bad_column_family_errors – a rate of “bad column family” errors generation while writing trace records (should remain zero in a normal situation)
  • tracing_keyspace_helper-0/total_operations-tracing_errors – rate of general errors generated during writing trace records (should remain zero in a normal situation)

New Thrift Metrics

  • thrift-0/connections-thrift-connections – Total number of connections accepted by the specified CPU
  • thrift-0/current_connections-current – Current number of connections currently active in the specified CPU
  • thrift-0/total_requests-served – Total number of requests served by the specified CPU

Update Metrics in ScyllaDB 1.3

  • reactor/queued-io-requests will only be avilable in coordinator shards. see Seastar #177 for more.

Known issues

  • CQLSh does not work with the default Python version delivered with Ubuntu 16. To by pass this issue downgrade Python to 2.7.11 #1515

ScyllaDB Roadmap at the ScyllaDB Summit

ScyllaDB future release is one of many topics to be covered at the upcoming ScyllaDB Summit. Come to ScyllaDB Summit on September 6th, in San Jose, California, to learn more about Thrift and other new and upcoming ScyllaDB features—along with info on how companies like IBM, Outbrain, Samsung SDS, Appnexus, Hulu, and Mogujie are using ScyllaDB for better performance and faster development. Meet ScyllaDB developers and DevOps users who will cover ScyllaDB design, best practices, advanced tooling and future roadmap items.

Going to Cassandra Summit? Add another day of NoSQL ScyllaDB Summit takes place the day before Cassandra Summit begins and takes place at the Hilton San Jose, adjacent to the San Jose convention Center. Lunch and refreshments are provided.

Register for ScyllaDB Summit

About ScyllaDB Team

ScyllaDB is the world’s fastest wide-column store database: the functionality of Apache Cassandra with the speed of a light key/value store.