スケールアップファーストのNoSQL、ScyllaDB(スキュラDB)

ScyllaDB User Group Japan.
スケールアップファーストのNoSQL、ScyllaDB(スキュラDB)
高速化とノード縮小の原点に迫る
クリエーションライン株式会社
データエンジニアリングチーム
LEE CHANGHWAN
1

ScyllaDBユーザーグループ
2
https://scylladb-usergroup-jp.connpass.com/
**設立目的**
ScyllaDB(Scylla、スキュラと読む）ユーザーグループは、ScyllaDBに関する情報発信、会
員相互間の情報共有などを目的として設立しています。
https://www.scylladb.com/open-source/

設立
• 2006年1月
事業概要
• クラウドインテグレーション事業
• データ分析サービス事業
• DevOps関連サービス事業
クリエーションラインのホームページ
• https://www.creationline.com
クリエーションライン株式会社
3

自己紹介
李昌桓 (LEE CHANGHWAN, @awk256)
• データエンジニアリングチーム所属
• データベースが大好きなエンジニア。ビックデータ処理基盤のアーキテクトとして活動している。
著書
• グラフデータベースNeo4jの他
4

計算資源をめぐる大変革の時代
• CPUのコア数の暴走
• 高コアのCPUでは
• 高帯域のネットワークでは
• 高スループットのストレージでは
データベースのルネサンス時代
• ScyllaDBのクラスタ―及び読み書き
• ScyllaDB(スキュラDB）とは
• ScyllaDBの高速性に迫る
アゼンダー
5

ScyllaDB User Group Japan. 6
計算資源をめぐる大変革の時代

Slackに1行のメッセージから流れた(from木内)
• 李さん、こんなのがあるらしいよ！
• https://www.scylladb.com/
Topページをみると「The Real Time Big Database」
• Cassandra10倍速い,ノード毎に100万IOPS、オペレーションの99%が1ms、 Shrink
Nodes(1/5~1/10)
• うさん臭いなあ～
7

ホワイトペーパのちょっと読んでみるも
• 高速である理由を説明する各種用語が難しい
• さらに、高速である必要性が理解できない
キーワードを調べながら数カ月が経った
• ScyllaDBは、計算資源をめぐるパラダイムのシフトを的確にとらえている
• 疑心暗鬼のところからある種の信念が芽生え始めた。これは世の中のためになる！
8
https://www.scylladb.com/product/technology/

計算資源をめぐって大変革が起きている
• 高コア数
• ラージメモリ(RAM)
• 高帯域のネットワーク
• 高スループットのストレージ
その理由は
• 計算資源の最大の買い手であるクラウドプロバイダーが求めている
• マルチディア、機械学習、AIなど廉価でリッチな計算資源のニーズが爆発的な増加している
9

Up to 40 Cores and 2TB RAM

10GbE/40GbE

V-NAND SSD 970 PRO 1TB SAMSUNG
Sequential Read 3,500MB/s
Sequential Write 2,700BM/s

別に、それはそれでいいじゃないか?
• 高速にデータ処理が出来て
• 高速に転送出来て
• 高速に保存できるはず
だが、現代的なハイエンドサーバーをデータベースで利用しようとすると
• CPU/ネットワーク/DISK IOなどでボトルネックを引き起こす
13

高コア数/ビックメモリ/高帯域ネットワーク/高スループットのストレージ
専用機器や
OSに任せておけば
よかった時代
サーバーアプリケーションに
改革が求められている
殆どのDBアプリケーションが
対応に乗り遅れている

CPUのコア数の暴走

ちょっと、コンピュータの仕組みを復習しよう
• CPU（Central Processing Unit, 中央演算装置）
• メインメモリ（主記憶装置,一時記憶装置）
• 入出力装置

1978年、T. Hoareの予言的なレポート
• Communication Sequential Processes
http://weblab.cs.uml.edu/~bill/cs515/CSP_Hoare_78.pdf
• CPUは、クロック数を上げることに限界に達する
• 未来のコンピュータは、より多くのコア数を手にする

CPUのクロック周波数とは、0と1のビット演算を何回できるか、つまりCPUの性能
• 1Hz：1秒あたり1回
• 1KHz：1秒あたり1000回
• 1MHz：1秒あたり100万回
• 1GHz：1秒あたり10億回(これが一般的に)
• 1THz：1秒あたり1兆回
18
1971年：Intel 4004 → 108KHz
1976年：Intel 8086 → 5MHz
1989年：Intel i486 → 100MHz
1993年：Intel Pentium → 300MHz
2000年：Intel Pentium 4 → 1.40 ～ 3.80GHz
2008年：Intel Core i7 → 2.66 ～ 3.20GHz
2017年：Intel Core i7 7740X → 4.30 ～ 4.50GHz
2018年：Intel Core i7 8086K → 5.00GHz
インテルがCPUを作り始めて47年で、クロック周波数は46300倍まで進歩

Core(コア)とは、CPUと称する装置のなかの計算ユニットを称するものである?
つまり、CoreとはCPUであり、CPUはCoreである?
現代では、コア数はCPUの性能を称する代名詞になっている。
19
1
シングルコア
1
2 1 2
デュアルコア
2005年頃
Athlon 64 X2
Pentium D
1 2
クアッドコア
2006年頃
Core 2 Quad
Phenom X4

もう、コア数の暴走は止まらなくなっている
20
• 1コア：シングルコア
• 2コア：デュアルコア
• 3コア：トリプルコア
• 4コア：クアッドコア
• 6コア：ヘキサコア
• 8コア：オクタコア
• 10コア：デカコア
もう、数字読みで〇〇コアと呼ぶのが一般化されているのではないか

複数のCPUとメモリが1つのシステムの載せられたアーキテクチャー(トポロジーの変化)
• SMPアーキテクチャーではコア数の暴走により、CPUとメモリが不整合が起きるようになった
• CPUとメモリのIOパスがへ並列化されることで、格段にスループットが上がる
• 仮に14GB/1secのメモリパスを並列化すると、28GB/1secになる
NUMA(Non-uniform memory access)
21
http://frankdenneman.nl/2016/07/07/numa-deep-dive-part-1-uma-numa/

スレッドとは
• 伝統的なコアは、同時に1コアが1つの仕事しかできない
• 現代的なコアは、同時に1コアが複数の仕事をする
• もはや、コンピューターの性能は、コア数とスレッド数

高コア数のCPUでは

CPUの働き方
• 割り込み
割り込みは、CPUとOSでサポートされる機能で、「今やっている処理に割り込んで特別な処理を実行する」こと
CPUに割り込みが生じると、現在実行している処理（命令）を停止して別の処理を実行する
周辺機器からの情報を、他の作業をしながらも取り落とすことなく受け取る、例えば、キーボードの入力とか
それで、CPU資源を有効利用、応答性の向上、例外処理の効率、正確なタイミングの取得
人に例えば、会議中に携帯で業務連格を受け取るとか、特に会議に重大な問題が起きるわけではない
• ロック
複数のプロセス（又はスレッド）が共有メモリを使用してデータ処理をしているときに、
あるプロセスに独占的に使わせるための制御
つまり、データベースのようにデータの不整合を避けるための措置である
24

Linuxにおけるスレッド間の通信
25
ほとんどのアプリケーションは、ロ
ックを使用してスレッド間通信を実
装しています。
この方法は一部のアプリケーション
では効果的ですが、データ集約型の
多数のコアアプリケーションではス
ケーラビリティの問題があります。
ロックを取ったり解放したりするた
めに必要な労力は、サーバーの規模
に応じて大きくなります。
https://www.scylladb.com/2018/02/15/memory-barriers-seastar-linux/

thread-per-connection方式のアプリケーション
これは、接続が増えるとスレット数も比例して増える。
• 同時接続が増える単に実行スレッド数も増える
• スレッド数が増えるとCPUはビージ状態になる
• さらに、スレッドはヘビーなオブジェクトでもあり、それぞれメモリを消費する
結局、大量リソースを消費するために、単純アプリケーションでしが、上手く働かない。
需給のバランスを取ることは非常に難しく、短命で終了！
26

thread poolsのアプリケーション方式
これは、多数の接続が、より少ない数のスレッド（スレッドプール）を共有して処理する。
スレッドの暴走を抑えるために、現在の殆どのアプリケーションで実装している。
• 書き込み可能な共有データが存在する場合、プロセッサーからプロセッサーへのキャッシュデータの移動が必要で
ある。
• あるプロセッサーに割り当てられたデータへ別のプロセッサーからアクセスする必要も出てくる。
• CPUの過剰な働きが制御できない
OSの使命は、CPU使用率を最大化すること。スレッド（Linuxの処理の単位)をちょっと待たせれば、順番が回ってくるところ、
別のCPUに移動させてしまい、結果的にメモリアクセスの再配など遅延を引き起こす
データ集約型処理では、暴走するロックを回避できない、CPUの過剰な働きが制御できないために、十数コアまでが
限界だと言われている。
27

高帯域のネットワークでは

そもそも
• 専用H/Wで処理したものが、クラウドになってからソフトウェア化し、大幅にパフォーマンスが落ちているパターン
• アプリケーションが10GbE以上のNICに対応していないパターン
• ネットワークは高速になっており、コア数は各段に増えているが、どのコアもパケットを処理をする能力をもっていな
い。ハイウェイ(ネットワーク帯域）は出来ているが、陳腐化した物流システムが物流を邪魔しているような状態
29
10GBps のネットワークで
1024Byteのパケットを処理す
る2GHz プロセッサーが、パ
ケットあたりにわずか1670ク
ロックサイクルしかない。
パケットごとに多数のクロック
サイクルが使用可能な場合には、
発想を変えるべきではないか

カーネルで受信パケットカウント処理を実行する場合の処理シーケンス
1. NICがカーネルに割り込みを発生させる
2. カーネルが割り込み処理するために、コンテキストスイッチを発生させる
3. カーネルがNICに対応するドライバー処理を実行する
4. カーネルがネットワークスタック処理を実行する
5. カーネルがパケットカウント処理（アプリケーション）を実行する
2,3,4が特にソフトウェア処理上のオーバヘッドになる
高コア数になって、従来の「割り込み/ロック」という思想の処理方式が崩壊しているのに、パケット処理がさらに状態を悪化させている
30

高スループットのストレージでは

大雑把に言うと
• DISKは、高性能のSSDでも、同時並列に入出力できるIO数に臨界点が存在する。
• 最大同時実行数を超えたIOが発生すると、(IOキューをもっていても) 失速（ストール）を引き起こす。
OS依存の現在のアプリケーションでは制御できないし、OSが制御しているわけでもない。
DISK IO
32

NVMe SSD
33
https://github.com/avikivity/diskplorer
←
まるで糞詰まりのような
現象である
デジタル世界なのに可笑
しいが、現実に起きてい
る

データベースのルネサンス時代

出典：RDB技術者のための
NoSQLガイド,秀和システ
ム,2016
Hadoop
・Apache Hadoop
・Cloudera
・MapR
・Hortonworks
スループット重視
(レポーティング指向）
ターンアラウンドタイプ重視
（オペレーション指向) RDB(OLAP, DWH)
・Oracle Exadata
・Teradata
・Netezza
・Redshift
RDB(OLTP)
・Oracle
・SQL Server
・MySQL*
・PostgreSQL*
グラフDB
・Neo4j
スケールアウトできない
(*シャーディングでスケールアウト可）
スケールアウトできる
KVS
・Redies
・Memcache
ワイドカラム
・Cassandra
・ScyllaDB
ドキュメント
・MongoDB
・Couchbase
NoSQL

キーバリュー、ワイドカラム、ドキュメント、グラフ
36
ドキュメント(JSON) グラフ
001:’aaa’
002.’bbb’
003:’ccc’
001,title : “Amazo EC2”
001:price : 3000
001:Author : aaa
002:title : “Cassandra入門”
002:Price : “2000”
{ _id :001,
title : “Amazo EC2”,
price : 3000,
author : {
name : ‘aaa,
address : ‘xxx’
phone : ‘123-1234’
}
}
writed

区分 NoSQL
データベース KVS ドキュメントDB グラフDB
データモデルキーバリューワイドカラムドキュメントグラフ
OSS ・Redis
・Memcachd
・Riak
・Cassandra
(Datastax)
・ScyllaDB
・HBase(Hdoop)
・MongoDB
・Couchbase
・Neo4j Community
商用製品・Oracle NoSQL DB ・ScyllaDB EE Neo4j EE
Oracle
クラウド・Google Cloud
Databas
・Amazon
ElasticCache
・Azure Redis Cache
・Amazon
Dynamo DB
・Google
BigTable(HBase)
・Azure Cosmos(ド
キュメントAPP)
・IBM Cloudant
・AWS Neptune
・Azure Cosmos Graph
APP
出典：RDB技術者のためのNoSQLガイド,秀和システム,2016

• マスタ―型(MongoDB)
• P2P型(Peer to Peer, マスターレス, ScyllaDB, Cassandra)
クラスタ―のアーキテクチャー
38
M
S S
コピー
01-30
01-30 01-30
01-05 06-10
11-15
16-2021-25
26-30
・ 1台のマスターと、複数レプリカで構成
・キャパシティーの拡張はスケールアップ
・論理的なデータ数制限はない
・スケールアウト（シャーディング)
01-05
06-10
01-05
26-30
06-10
11-15
11-15
16-20
16-20
21-25
21-25
01-05
・ノード間でクロスでN個のレプリカを持つ
・キャパシティの拡張は水平分散スケールアウト
・高可用性と拡張性の両方を満たす構造
・単一障害点(spof)がない
M
S S
M
S S
M
S S
・・・

ScyllaDB

ビックデータ処理PFのツールマッピング
40
Real Time Process
Message Pool
画像/音声
File Store
Near Real Time
Process
Batch Process
Data Store
テキスト
GW
MQTT?
データマート
データレイク
データソース
Data Mart
Service
Queue
画像処理

ScyllaDBのクラスタ―及び読み書き
ー基本的にCassandraと同じー

CAP定理
42
https://www.scylladb.com/2018/08/28/scylla-fault-tolerance/
Scyllaは、次のような可用性とパーティション耐性を一
貫性よりも優先しています。
一貫性と高い可用性をネットワークパーティションで
実現することは不可能です
一貫性を犠牲にすれば、高可用性を実現できます
分散型アーキテクチャーでは、どれも同時に3つを達成することはできない

アベイレビリティ
43

アベイレビリティ
44

• Cassandra → スケルアウトオンリ
• ScyllaDB → スケールアップファースト+スケールアウト
スケーラビリティ
45

マルチデータセンタークラスタ―
• どこで書きこんでも、データセンター間で自動的に複製される
• ユーザーはどこからでも読み書きできる
スケーラビリティ
46
大阪
東京

データモデル
47
ScyllaDB RDB
キースペースデータベース
テーブル(カラムファミリ) テーブル
カラムカラム
Cassandraと同じ、CQL(Cassandra Query Language)を使用
見た目では、RDBのテーブルを殆ど変わらない。

SQLライクなシンタクス
DDLでオブジェクト作成
• CREATE/INSERT/UPDATE/DELETE
GRANT/REVOKE
SELECT * FROM <table name>
• JOINできない
DMLでデータ操作
• INSERT,UPDATE,DELETE
CQL(Cassandra Query Language)
48
CREATE TABLE mykeyspace.book (
id TEXT,
title TEXT,
author TEXT,
price DECIMAL
PRIMARY KEY (id) );
CREATE KEYSPACE mykeyspace WITH WITH REPLICATION
= {'class': 'SimpleStrategy','replication_factor' : 3};
INSERT INTO mykeyspace.book (id, title, author,price)
VALUES (‘1', ‘scylladb', ‘Avi’, 2500);
SELECT id, title, author, price
FROM mykeyspace.book
WHERE id = ‘1’

テーブル内で行を一意的に識別するキー
パーティションキー
• 1番目のカラムがパーティションになり、データをグループ化できる
• 実データがあるサーバーへのルーティングのためのキー
プライマリキー
49
CREATE TABLE table1 (
c1 TEXT,
c2 TEXT,
c3 DECIMAL,
c4 TIMESTAMP,
PRIMARY KEY (c1, c2) );

ScyllaDB(スキュラDB）とは

ScyllaDB(スキュラDB）とは
• リアルタイムビックデータ処理向けのNoSQL
• スケールアップファーストのNoSQL
51
ScyllaDB(スキュラDB）とは、Apache CassandraをJAVAからC++でリプレースし、
Cassandraより10倍以上高速であり、その速さを利用してノード数を「1/5～1/10」に圧
縮できる異次元のデータベースです（スケールアップファーストのクラスター設計思想）。
Cassandraとは、互換性があり、開発はCassandraのドライバ―やCQL、各種コネクター、
CLIなどをそのまま利用できます。

ScyllaDBチームはKVMハイパーバイザーを設計、開発した人達が中心。KVMは、GCP、AWS、OpenStackなど
の多くのクラウド環境でデフォルトのハイパーバイザーである。
ScyllaDBの創始者は、 Avi Kivity氏
52
https://www.scylladb.com/2015/04/20/seastar-meetup/
当初、DockerのようなUnikernelを開発し
ていて、Dockerとは競合していたが最終
的にはDockerの方が広がり、そこで製品
化を断念。このUnikernelの基礎技術を使
って、Hadoop、Cassandra、Kafka等の
ストレージエンジンの高速化に関わって
いた。この時から開発言語として、C++
をベースにし、最終的にCassandraに絞
って製品化したのが、ScyllaDBである。
2015年には、αリリースを出し、現在に
至っている。

• 設立 2015年
• 社名 ScyllaDB, Inc
• 従業員 50人強
• 拠点
United States Headquarters/Israel
Office
53
カリフォルニア州

Investor
54

Users
55

Open Source(GPL v3.0 vs Commercial License)
56
Commercial License →オープソース機能+ {SLA, セキュリティ, 運用}

Open Source Licenses
• Free Software Foundation’s GNU AGPL v3.0
• Current version 2.3, September 19, 2018
Driver Licenses
• Apache Cassandra drivers: Apache License v2.0
Enterprise Licenses
• ScyllaDB Proprietary
• Current version Scylla Enterprise 2018.1.4(Open Source v2.1)
License
57

如何なるCassandraアプリケーションでも、IPが合って入れば接続できる！
Apache Cassandra 2.2のすべて、Apache Cassandra 3.xの一部の機能が備わっている
特に、以下のインターフェースはApache Cassandraと互換性がある。
• すべてのApache Cassandraドライバ
• プロトコル：CQL(Cassandra Query Lanague)、Thrift、JMX
• ツール：cqlsh、nodetool、cassandra-stress、及びすべてのCassandra 2.2ツール
• SSTableフォーマット
Cassandraとの互換性
58
詳細は、こちらを参照要
https://docs.scylladb.com/using-scylla/cassandra-compatibility/

Survey of 1,850 attendees AWS re:Invent 2017

Scylla Beneifts
61
i3.2xlarge,8vCPU,27(EUC),61GiB Memory,1x1900 NVMe SSD,
0.862USD/時間, 東京

Scylla Beneifts
62
i3.2xlarge,8vCPU,27(EUC),61GiB Memory,1x1900 NVMe SSD,
0.862USD/時間, 東京

Scylla Beneifts
63
i3.16xlarge,64vCPU,200(EUC),488GB Memory,8x1900
NVMe SSD,5.856USD/時間,東京

Scylla Beneifts
64
Latency(MS)
Time
High
Low

Scylla Beneifts
65
CassandraをJavaからC++でリプレース
C ++はしばしば1970年代のC言語に根ざした伝統的な命令型言語であると考えられているが、過
去数年間、完全に近代化されており、ラムダ、メタプログラミング、関数型プログラミングなど
の現代的パラダイムに移行している

Scylla Beneifts
66
Cassandraに接続するために何を使用していても、現在の実装を利用し、IPアドレスを
Scyllaクラスタに変更するだけで動作する

Apache Cassandra vs Scylla
67

Scylla vs Other Big Data Product
68

• スループット重視
• シーケンスアクセス又は
粗なランダムIO
• 背景にはGoogle
• Hive, Presto, Pig
• ジョイン、集計処理可能
Hadoopのデータ処理
69

• スループット重視
• 入力はシーケンスアクセス又は
粗なランダムアクセス
• 出力は粗なランダムIO
• DWHエンジン
• ジョイン、集計処理可能（得意）
OLAP系のRDBのデータ処理(DWH)
70

NoSQLのデータ処理
71
• タンアラウンドタイムがRDBより速い
• 超ランダムなIOに強い
• GoogleやFacebook
• Cassandra, DyanmoDB, HBase, MongoDB(ABC順)
• ジョイン、集計処理はできないか(苦手）
• ジョイン、集計処理は、Sparkなどを連携して可能
NoSQL
NoSQL
NoSQL

OLTP系のRDBのデータ処理
72
• タンアラウンドタイム重視
• ランダムなIOに強い
• Oralce, Microsoft, IBM
• Oracle, SQL Server, MySQL, PostgreSQL
• ジョイン、集計処理可能
NoSQL
NoSQL
RDB

IoTに求められるデータ処理の特徴
73
NoSQL
NoSQL
• 短いタンアラウンドタイム＋高スループット
• 粗なランダムなIOに強い
• Scyllaが代替案になる
ソースからダイレク
トではなく、メッセ
ージングツールから
入ってくる
サードパーティーの
Query Engine、アプ
リケーションフレー
ムワークでデータマ
ートを切り出す

ScyllDBの高速性に迫る
• アーキテクチャー
• ネットワーク
• DISK IO
• Cassandraの改善

アーキテクチャー
75
shared-nothing
• コア毎のシャード
• 独自のタスクスケジューラ
• 非同期
thread pools
• 割り込み
• ロック

コア毎のシャード
• マルチコアハードウェアのパワーを極限まで引き出す
• 各シャードは独自のメモリ、ネットワーク、I/O、自分のデータを持つ
• ロックレスのコア間通信
独自のタスクスケジューラ
• タスクは、自分に与えられたデータだけを集中して処理
すべて非同期
• ロックレス、データはすべてCPUにストリーム
• コア間で明示的にデータの受け渡し
76

食事はお行儀よく

高スループットのサーバアプリケーションの開発のためのオープソースフレームワーク(C++)
SeaStarの推奨ハードウェア構成
• CPU あるだけ、マルチコアとNUMAフレンドリ
• NICs 10GB～40GB
• DISK IOPS数の多い高速SSD
• クライアントマシンサーバと異なるマシンで複数実行することをお勧め
Seastarライセンス
• Apache License、Version 2.0
• Data Plane Development Kit(DPDK)バージョン1.8.0以降を使用
Seastar
78
http://seastar.io

DPDK(Data Plane Development Kit)とは、ネットワークの高速化, ネットワーク処理に特化したアプリケーショ
ンを作成するためのソフトウェアライブラリ(C++)
アプリケーションはDPDKが提供するライブラリを使用することで、NICの送受信データとアプリケーション間でダイレクト
にアクセス可能
• 2010年にIntelによって開発
• 2013年にDPDK.orgに設立
• BSD License
DPDK(Data Plane Development Kit)
79
https://www.dpdk.org/

統一キャッシュ―(Unified Cache)
80
Cassandraのキャッシングは複雑である。キーキャッ
シング、行キャッシング、Linuxキャッシング、ヒープ、
オフヒープなど膨大な量のチューニングが求められる。
RAMの半分はmemtablesや
その他のバックエンド要件
に使用される。
Scyllaは残りの半分をキャ
ッシュに使用する。
チューニングは不要である。

• P2P型のクラスタ―では、ノードの追加、ノードの復旧、バランシングで大量のトラフィックが発生する
• カーネルバイパスのためにオーバヘッドが発生しない。アプリケーションで思い描いたデータ通信を行う
• 下記は、コミュニティー版v2.３まで
Scyllaストリーミング
81

v2.4(現在2.3)では、sstableにダイレクトに書き込みを行う
Scyllaストリーミング
82
https://www.scylladb.com/2018/08/14/upcoming-improvements-scylla-streaming/
3.8xlarge,32vCPU,99ECU,244GiB Memory,4x1900 NVMe SSD
1.89TiB,66分,765MiB / 1sec

DISK IOの並列度をScylllaが最適化し、DISK IOでに糞詰まりを起こさず、常に一定のスループットを引き出す。
ディスクの最大同時実行性(max-io-requests)をScyllaがテストして設定する
• /etc/scylla.d/io.conf
SEASTAR_IO="--max-io-requests=33"
Scylla I/Oスケジューラ
83
https://www.scylladb.com/2018/04/19/scylla-i-o-scheduler-3/

ユーザ空間でIOをキューイングし,ディスクの最大同時実行性の範囲で下位層とIOを行う
下位層の糞詰まりを避けることで、安定・最適なIOを維持する
内部キューをもっている最新のSSDさえ、要求をOS/ディスクに任せるだけでは、失速(ストール）などの弊害を引き起こす
ユーザ空間ディスクI/Oスケジューラの設計：Scyllaの例
84
左側では、ユーザ空間のプロセスによって生
成されたリクエストは、カーネルをスルーし、
下にレイヤーに到達します。過負荷の制御は
できません。右側では、ディスクI / Oスケジ
ューラが要求とカーネルの間に配置されるよ
うになりました。これらの要求を意味のある
クラス（AとB）に分類し、バランスを保ち、
下位レイヤが過負荷にならないようにすしま
す。
https://www.scylladb.com/2018/04/19/scylla-i-o-scheduler-3/
https://www.scylladb.com/2017/10/05/io-access-methods-scylla/
従来型 ScyllaDB

自律DB(Autonomous)
85
インストール時には、I / O、RAM、CPU、およびネットワーク用にチューニングされる。ネ
ットワーク、ディスク、CPUに入る5種類のリクエスト(commitlog、memtable、compaction、
query、repair)

• ユーザー処理に負担を掛けないようにCompaction Controllerが自動制御しバックグラウンド実行
• Scyllaは、STCS（Level Tiered Compaction Strategy）、LCS（Leveled Compaction
Strategy）、TWCS（Time Window Compaction Strategy）およびDTCS（Date Tiered
Compaction Strategy）をサポート
Scylla Compatction
86
https://www.scylladb.com/2018/06/12/scylla-leverages-control-theory/
a real-world closed-loop control system

• パーティションキーによる実装
ヒットするとめちゃくちゃ検索効率がいいが、ヒットしないとフールスキャンになる
• マティリアズドビュー(Materialized View)
通常のビューとは違って、クエリの結果をテーブルにキャッシュ―している。ベーステーブルが変更されると、
自動的に変更される。検索には優れているが、ストレージを逼迫する
• Cassandraのセカンダリインデックスは、ローカルインデックス方式
書き込みは良い、読み込みは潜在的にすべてのノードを読む必要性があり、
大規模クラスタ―では、拡張性、有効性に悩む
• ScyllaのSIは、MVに基づくグローバルインデックス方式
各索引に対してマテリアライズド・ビューが作成される。
Scyllaオープンソースリリース2.3ーセカンダリインデックス（SI）
87
https://www.scylladb.com/2017/11/03/secondary/

続き
88
マテリアライズド・ビューでキーには、パーティション・キーおよびクラスタリング・キーが存
在し、検索は、マテリアライズド・ビューを参照し、ダイレクトに行にアクセスする。
フェーズ（1）では、クエリはノード7
に到着し、ノード7はクエリのコーデ
ィネータとして機能する。ノードは、
索引付けされた列を問合せしているた
め、フェーズ（2）で、
「user@example.com」の索引表の行
を持つノード2の索引読取り表を発行
します。クエリは、フェーズ（3）で
使用されてインデックス付きテーブル
の内容を取得するユーザーIDのセット
を返します。

ScyllaDB v2.0からパーティションのサブセットのみをキャッシュ
• パーティション全部を持ってこない
• 読み込みの無駄な増幅を回避
Row-granularity Population
89
https://www.scylladb.com/2018/07/26/how-scylla-data-cache-works/

データはパーティション単位でキャッシュし、パージもパーティション単位
• 伝統的なCassandra実装
• これは遅延を誘発
従来では
90

これでScyllaDBの高速性に関する主な箇所は
説明させて頂きました！
ScyllaDBは、日々進化しています。
次をお楽しみにしてください。

スケールアップファーストのNoSQL、ScyllaDB(スキュラDB)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to スケールアップファーストのNoSQL、ScyllaDB(スキュラDB)

Similar to スケールアップファーストのNoSQL、ScyllaDB(スキュラDB) (20)

More from 昌桓李

More from 昌桓李 (9)