NewSQL その成り立ちとモチベーション Database Lounge Tokyo #6 , 6/25 @tzkb

2 最近やっていること • PGConf.Asia 2019 “Building PostgreSQL as a Service with Kubernetes” • NewSQL関連のブログ投稿 “2020年現在のNewSQLについて” “NewSQLコンポーネント詳解” ＋ ＝∞

3 1. 複雑化するデータストア 2. NewSQLとは何か 3. NewSQLの構成要素について学ぶ 4. まとめ アジェンダ

4 複雑化するデータストア 1

5 １－１．データストアを使い分ける時代 • プロジェクトにおいて、RDB単体で非機能要件を充足できないケースがある。 例：Write性能、可用性など • 結果、RDB＋キャッシュ＋NoSQLという複雑なデータストアが構成される。 Stateless Applications M S Region1 Region2 SQL JSON KVS SQL JSON KVS

6 １－２．Multiverseは理想郷？ • Percona CEOのPeter Zaitsevは前述のような状況を Multiverse と表現。 • OSS-DB、クラウドサービス、Kubernetesなどを組み合わせて、運用負荷を 軽減。MultiverseはOpsにとっては現実的に。 • では、開発者(Dev)にとっては？

7 １－３．福音はUniversal Database？ • 全てのワークロードを実現する単一DB(≒Universe)はエンジニアの福音。 • かつて、プロプライエタリのDatabaseが歩んできた道。 OSS Universe指向 Multiverse指向 プロプラ/ クラウド

8 NewSQLとは何か 2

9 ２－１．Spannerの登場 • Spanner: Google’s Globally Distributed Database(2012) を発表。 • SQL準拠、ACIDトランザクションをサポート。 • 地理分散が可能な、分散型SQLデータベース。 • 従来RDBが弱いとされた、Writeもスケールアウトが可能。 • 国内でもスマホゲームや決済アプリのプラットフォームとして利用される。

10 ２－２．NewSQL（Spannerクローン）の成り立ち • NewSQL自体はNoSQLへの対比として生まれ、2011年頃に既に登場。 • VoltDBやNuoDBなど、NoSQLが解決できなかった課題（マルチマスタ・ スケールアウト型のRDB）の解決を目指していた。 • そして、Google Cloud Spanner以降、類似実装のOSSクローンが誕生する。 • その特徴は、 • 強い整合性を持ち、 • ACIDトランザクションをサポートする、 • （地球規模に展開可能な）分散SQLデータベース

11 ２－３．Universal Databaseを目指す • SQLとCassandra互換(CQL)インターフェースを持つ、分散SQLデータベース。 tablet3 tablet2 tablet1 tablet4 tablet2 tablet1 tablet4 tablet3 tablet1 tablet4 tablet3 tablet2 Distrbuted Txn Mgr Distrbuted Txn Mgr Distrbuted Txn Mgr Distrbuted Txn Mgr syscatalog syscatalog syscatalog • PostgreSQL互換のSQL エンジンを持つ。 • DocDBという分散スト レージを下層に配置。 • データはShardingかつ 冗長化される。 • Kubernetesでのオーケ ストレーションに対応。

12 NewSQLの構成要素について学ぶ 3

13 Shard2 SQLクエリエンジン 分散Txn Mgr ３．NewSQLのコンポーネント概観 Shard1 SQLクエリエンジン 分散Txn Mgr • 拙blogでは分散SQLデータベースのコンポーネントを以下4つに分類。 • データの”整合性を保ち“、”冗長化”し、 ”分散“し、”永続化”する方法を解説 している。 Shard3 SQLクエリエンジン 分散Txn Mgr ① ストレージエンジン 如何にデータをローカルに永続化するか ② Sharding 如何にデータを分散して配置するか ③ Raft 如何にデータを冗長化し、可用性を実現するか ④ 分散トランザクション 如何にデータの整合性を保ちつつ、更新するか

14 ３－①．ストレージエンジン • NewSQLではデータを各ノードに分散配置するが、ノードローカルなデータ 永続化を担当するのがストレージエンジン。 • RDBMSで使われていたB+Treeとは異なり、NewSQLではLSM-Treeを採用。 【特徴】 • TiDB（TiKV）、CockroachDBでは を利用している。 • YugaByteDBは独自開発のDocDBを用いる。 • なお、CockroachDBも独自ストレージエンジン（Pebble）の開発を進めてお り、このレイヤでの競争が激化しているように見える。 Read Efficiency Wrire Efficiency Space Efficiency B+Tree Best LSM Tree(Leveled) Best LSM Tree(Tiered) Best

15 ３－②．Sharding • データを如何に分散配置するかはNewSQLの肝となる部分。 • Hotspotをつくらずに、スケールできるデータ配置が理想。 • 基本戦略はrange（範囲分割）、またはhash（ハッシュ分割）だが、どちら もメリット・デメリットがある。 【各NewSQLのShading方法】 Shardの呼称 Shard最大サイズ Sharding方式 Google Cloud Spanner Split 4GB range CockroachDB Range 64MB range/hash(β) TiDB (TiKV) Region 100MB range YugaByteDB Tablet 制限なし hash/range(β)

16 ３－③．Raft Tablet2 Tablet1 Tablet2 Table1 Tablet2 Tablet1 Tablet3 Tablet3 Tablet3 • etcdなどは単一Raft グループで構成される 分散KVS。Leaderは 当然一つ。 • YugaButeDBなどはマ ルチRaftグループで、 グループ毎にLeader が存在。つまりマルチ マスタの構成となる (hotspot問題はあり)。 • NewSQLのデータ・レプリケーションにはRaft が使われている。 • Multi Raft Groupによりマルチマスタ構成を実現している。

17 ３－④．分散トランザクション • もっとも説明が難しい部分。 • Isolation（同時実行されたトランザクションから他がどう見えるか？）と、 Consistency（同時実行されていないトランザクションの順序性）を、 どう扱うか。※詳しく知りたい方は↓

18 まとめ • 複雑なマルチデータストア（Multiverse）は、DevOps双方に複雑性を招く。 マネージドなDBサービスでもK8sを使っても、完全には解消できない。 • そうした課題に対して、NewSQLは以下の特徴を持つ。 • 強い整合性を持ち、 • ACIDトランザクションをサポートし、 • （地球規模の展開が可能な）分散SQLデータベース • 特にSpannerの成功は、これまでのRDBMSの拡張性・一貫性に対する見方を 大きく変える可能性がある。 • NewSQLの構成要素を見ると、データの ”整合性を保ち“、”冗長化”し、 ”分散“し、”永続化”する という4要素に分解でき、各製品はそれらをどのように組み合わせるかで 最適化を図っている。

19 Questions? @tzkb @tzkoba