ScyllaDB Enterprise Release 2018.1.7

The ScyllaDB team is pleased to announce the release of ScyllaDB Enterprise 2018.1.7, a production-ready ScyllaDB Enterprise minor release. ScyllaDB Enterprise 2018.1.7 is a feature and bug fix release for the 2018.1 branch, the latest stable branch of ScyllaDB Enterprise. More about ScyllaDB Enterprise here.

ScyllaDB Enterprise 2018.1.7 introduces in-memory tables. The new feature, exclusive to the ScyllaDB Enterprise release, allows a ScyllaDB Enterprise developer to define a table as in-memory. In-memory tables use both RAM and persistent storage to store SSTables, thus providing lower, more consistent read latency compared to on-disk storage.

Developers should use in-memory tables only for mostly-read workloads, where read latency is critical, and the size of the data is small. Workloads which require frequent writes or updates are not a use case for an in-memory table. If in doubt, contact the ScyllaDB support team for more information.

In-memory tables use a new, proprietary compaction strategy optimized for RAM storage. Also note, every in-memory table is mirrored to disk, providing the same level of HA and persistence as on-disk tables.

To use this feature, you need to enable In-memory storage in scylla.yaml, and then use the CREATE or ALTER CQL commands to create a new in-memory table, or update an existing table’s properties.

  • More on enabling and using in-memory tables here.
  • Presentation from ScyllaDB Summit 2018 in-memory session here.

ScyllaDB Enterprise customers are encouraged to upgrade to ScyllaDB Enterprise 2018.1.7 in coordination with the ScyllaDB support team.

Related Links

Monitoring

New metrics introduced in 2018.1.7:

  • in_memory_store_total_memory
  • in_memory_store_used_memory

In-memory metrics are available in the latest Monitoring Stack, in the per server dashboard of ScyllaDB 2018.1

Bug fix

Additional fixed issue in this release, with open source references:

  • Gossip: non zero shards may have stale (old) values of gossiper application states for some time #3798. This can create an issue with schema change propagation, for example, TRUNCATE TABLE #3694