The industry’s most performant NoSQL database just got better. Scylla Open Source 3.0 introduces much-anticipated new features for more efficient querying, reduced storage requirements, lower repair times, and better overall database performance. It includes production-ready capabilities beyond those available with Apache Cassandra or any other NoSQL database. Join ScyllaDB CEO and co-founder Dor Laor and vice president of field engineering Glauber Costa for a technical overview of the new features and capabilities in Scylla Open Source 3.0, including: - Materialized Views - Global Secondary Indexes - New storage format: SSTable 3.0 - Hinted Handoff - Streaming Improvements - Full scan improvements

1. Introducing Scylla Open Source 3.0
Materialized Views, Secondary Indexes,
Filtering, and more
Dor Laor - CEO, ScyllaDB
Glauber Costa - VP of Field Engineering, ScyllaDB
WEBINAR

2. Presenters
2
Dor Laor
Dor is Scylla’s CEO, co-founder, avid engineer and a
snowboarder. Previously, Dor was part of the founding
team of the KVM hypervisor under Qumranet, which was
acquired by Red Hat.
Glauber Costa
Glauber is the VP of Field Engineering at ScyllaDB. He
shares his time between the engineering department
working on upcoming Scylla features and helping
customers succeed.

3. 3
+ The Real-Time Big Data Database
+ Drop-in replacement for Cassandra
+ 10X the performance & low tail latency
+ New: Scylla Cloud, DBaaS
+ Open source and enterprise editions
+ Founded by the creators of KVM hypervisor
+ HQs: Palo Alto, CA; Herzelia, Israel
About ScyllaDB

4. + Materialized Views
+ Global Secondary Indexes
+ Allow Filtering
+ Range scan improvements
Agenda: New with Scylla Open Source 3.0
+ New file format
+ Streaming improvements
+ Hinted Handoff
+ What’s coming next

5. Materialized Views: What Are They?
5
CREATE TABLE buildings (
name text,
city text,
built int,
feet int,
PRIMARY KEY (name)
);
CREATE MATERIALIZED VIEW building_by_city AS
SELECT * FROM buildings
WHERE city IS NOT NULL
PRIMARY KEY(city, name);
Also see: https://www.scylladb.com/tech-talk/materialized-views-secondary-indexes-scylla/

6. Materialized Views: What Are They?
6
Name City Built Feet
Empire State
Building
New York 1934 1250
WTC New York 2015 1776
Salesforce Tower San Francisco 2017 1070
Azrieli Sarona
Tower
Tel Aviv 2017 781
City Name Built Feet
New York
Empire State
Building
1934 1250
San Francisco Salesforce Tower 2017 1070
Tel Aviv
Azrieli Sarona
Tower
2017 781
SELECT city, name, built, feet from building_by_city LIMIT 1;

7. Materialized Views: How writes work?
7
View replicaBase replica
View update
Base write View reads
+ Consistency level guarantees applied in the base replica
+ View updates are asynchronous
+ This guarantees that view replica won’t impact availability

8. Materialized Views: automatic flow control?
8
+ If base replica write rate higher than view replica capacity, memory exhaustion can happen
+ Scylla will delay the responses automatically so that base and view rates are in sync

9. 9
Secondary Index
CREATE TABLE buildings (
name text,
city text,
built int,
feet int,
PRIMARY KEY (name)
);
CREATE INDEX ON buildings (city);
Also see: https://www.scylladb.com/tech-talk/materialized-views-secondary-indexes-scylla/

10. 10
Secondary Index under the hood
CREATE TABLE buildings (
name text,
city text,
built int,
feet int,
PRIMARY KEY (name)
);
CREATE INDEX ON buildings (city);
CREATE MATERIALIZED VIEW building_by_city AS
SELECT * FROM buildings
WHERE city IS NOT NULL
PRIMARY KEY(city, name);
Also see: https://www.scylladb.com/tech-talk/materialized-views-secondary-indexes-scylla/

11. 11
Scylla Global Secondary Indexes
A
B
C
(view
replica)
D
(base
replica)
E
F
SELECT * from buildings where city = ‘New York’1
2
3
+ Global Indexes know where
the data for ‘New York’ is and
only act on those nodes.
+ Scalable with the size of the
cluster.
SELECT * from buildings_by_city
where city = ‘New York’
SELECT
*
from
buildings
where
name
in
(...)

12. 12
Scylla Secondary Indexes vs Local Indexing
SELECT * from buildings where city = ‘New York’
A
B
C
D
E
F
A
B
C
D
E
F
Global Local

13. 13
Secondary Indexes and Materialized Views
Materialized Views: Secondary Indexes:
More powerful, can create flexible layouts
Queries for view data in a single step
Integrates transparently with queries,
no need to specify a second table
Two-step query allows for seamless
integration with base table
Can be used with Allow Filtering

14. 14
Allow Filtering
CREATE TABLE buildings (
name text,
city text,
built int,
feet int,
PRIMARY KEY (name)
);
SELECT * FROM buildings WHERE city = ‘New York’ and built = 1934 ALLOW FILTERING;
• Full table scan. All partitions are scanned, looking for matching city, and built.
• Allowed, but use with caution.
Also see: https://www.scylladb.com/2018/08/16/upcoming-enhancements-filtering-implementation/

15. 15
Allow Filtering with Secondary Indexes
CREATE TABLE buildings (
name text,
city text,
built int,
feet int,
PRIMARY KEY (name)
);
CREATE INDEX ON buildings (city);
SELECT * FROM buildings WHERE city = ‘New York’ and built = 1934 ALLOW FILTERING;
• Extract rows using index on city.
• Scan space is reduced to only those partitions.

16. 16
Filtering with and without Indexes
SELECT * FROM buildings WHERE city = ‘New York’ and built = 1934 ALLOW FILTERING;
Indexes:
real 0m0.950s
user 0m0.375s
sys 0m0.036s
No Indexes:
real 11m41.701s
user 0m1.564s
sys 0m0.351s

17. 17
Range Scans Improvements
CLIENT SCYLLA
Save Query State
Look-up Query State
Query Key
Paging State Cookie
Create Query State
Destroy Query State
LEGEND
Also see: https://www.scylladb.com/2018/11/01/more-efficient-range-scan-paging-with-scylla-3-0/

18. 18
Range Scans Improvements (Under the hood)
Also see: https://www.scylladb.com/2018/11/01/more-efficient-range-scan-paging-with-scylla-3-0/
Before

19. 19
Range Scans Improvements (Under the hood)
Also see: https://www.scylladb.com/2018/11/01/more-efficient-range-scan-paging-with-scylla-3-0/
Before After

20. 20
Range Scans Improvements (Under the Chassis)
Also see: https://www.scylladb.com/2018/11/01/more-efficient-range-scan-paging-with-scylla-3-0/

21. 21
Results (Normalized)

22. 22
A New File Format
+ Scylla Open Source 3.0 adopts the Cassandra 3.x
SSTable file format
+ Unlike Cassandra, there is no need to run upgradesstables
+ Scylla is able to read all its previous file formats
+ The new format is disabled by default in this release and
can be enabled with a flag.

23. 23
The Older SStable format layout
Old formats, ‘kX’ and ‘lX’, are identical in how they store data:
Partition
Cell Cell Cell
Cell
Cell == <clustering key value>:<column name> + <column value>

24. 24
The New SStable format layout
Cell
Partition
Row
Cell Cell Cell
Row
Cell Cell Cell

25. 25
Why a New File Format?
The new file format has:
+ Better alignment with CQL, with native support for rows
+ Variable-sized integers
+ Delta-based timestamp encoding
+ Column metadata stored out of the Data file

26. 26
Why a New File Format?
… which allows us to:
+ Provide significant space savings
+ Process data faster
+ Use backup and restore tools independently of the schema
+ Import Cassandra 3.x files directly

27. 27
Space Savings: How Much?
CREATE TABLE kvexample (
key text,
val text,
PRIMARY KEY (key)
) WITH compression = {};

28. 28
Space Savings: How Much?
CREATE TABLE iotexample (
sensor uuid,
temperature int,
humidity int,
pressure float,
weathersource text,
timestamp timestamp,
PRIMARY KEY (sensor, timestamp)
) WITH compression = {};

29. 29
Faster Streaming
Before

30. 30
Faster Streaming
Before
After

31. 31
Faster Streaming
Scylla Open Source 2.3 Scylla Open Source 3.0 Difference
Decommission a Node, Cluster idle 895 seconds 695 seconds 22%
Add a Node, Cluster idle 1472 seconds 1236 seconds 16%
Add a node, during load 1834 seconds 1592 seconds 13%
* Cluster had 2.8TB split in 3 nodes. Details in the blog
Also see: https://www.scylladb.com/2018/08/14/upcoming-improvements-scylla-streaming/ and
https://www.scylladb.com/2019/01/22/improved-performance-in-scylla-open-source-3-0-streaming-hinted-handoffs/

32. Production-Ready Hinted Handoff
Based on the replication factor (RF), the co-ordinator
attempts to write to RF nodes.

33. Production-Ready Hinted Handoff
If one node is down, acknowledgments are only returned
from two nodes.
Based on the replication factor (RF), the co-ordinator
attempts to write to RF nodes.

34. Production-Ready Hinted Handoff
If one node is down, acknowledgments are only returned
from two nodes.
Based on the replication factor (RF), the co-ordinator
attempts to write to RF nodes.
The co-ordinator will write and store a hint
for the missing node

35. Production-Ready Hinted Handoff
If one node is down, acknowledgments are only returned
from two nodes.
Based on the replication factor (RF), the co-ordinator
attempts to write to RF nodes.
Once the down node comes up, the co-ordinator will replay
the hint for that node. After the coordinator receives an
acknowledgement of the write, the hint is deleted.
The co-ordinator will write and store a hint
for the missing node

36. 36
read-time synchronous repair after a
node upgrade
Scylla 2.3 (No Hinted Handoff)
Scylla 3.0 (With Hinted Handoff)
Production-Ready Hinted Handoff

37. 37
Latency Scylla Open Source 2.3 Scylla Open Source 3.0 Difference
95th percentile 5 ms 2 ms 60%
99th percentile 12 ms 4.5 ms 62%
99.9th percentile 38 ms 34 ms 10%
read-only QUORUM reads workload
Also see: https://www.scylladb.com/2019/01/22/improved-performance-in-scylla-open-source-3-0-streaming-hinted-handoffs/
Production-Ready Hinted Handoff

38. + Enterprise release 2019.1, based on Scylla Open Source 3.0
+ End of March
+ Encryption at rest
+ Per-user-SLA
+ Incremental Compaction Strategy
+ OSS 3.1
+ LWT
+ Scylla Manager 1.4
+ Scylla drivers
+ Scylla Cloud (now!)
What’s Coming Next?

39. Q&A
Stay in touch
glauber@scylladb.com @glcst
dor@scylladb.com @dorlaor
@ScyllaDB

40. United States
1900 Embarcadero Road
Palo Alto, CA 94303
Israel
11 Galgalei Haplada
Herzelia, Israel
www.scylladb.com
@scylladb
Thank You!