NewSQL その成り立ちとモチベーション

Cd891a89dfec6ca7bd278b5f5bd87c90?s=47 tzkoba
June 25, 2020
3.3k

NewSQL その成り立ちとモチベーション

Cd891a89dfec6ca7bd278b5f5bd87c90?s=128

tzkoba

June 25, 2020
Tweet

Transcript

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

  2. 2 最近やっていること • PGConf.Asia 2019 “Building PostgreSQL as a Service

    with Kubernetes” • NewSQL関連のブログ投稿 “2020年現在のNewSQLについて” “NewSQLコンポーネント詳解” + =∞
  3. 3 1. 複雑化するデータストア 2. NewSQLとは何か 3. NewSQLの構成要素について学ぶ 4. まとめ アジェンダ

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

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

    S Region1 Region2 SQL JSON KVS SQL JSON KVS
  6. 6 1-2.Multiverseは理想郷? • Percona CEOのPeter Zaitsevは前述のような状況を Multiverse と表現。 • OSS-DB、クラウドサービス、Kubernetesなどを組み合わせて、運用負荷を

    軽減。MultiverseはOpsにとっては現実的に。 • では、開発者(Dev)にとっては?
  7. 7 1-3.福音はUniversal Database? • 全てのワークロードを実現する単一DB(≒Universe)はエンジニアの福音。 • かつて、プロプライエタリのDatabaseが歩んできた道。 OSS Universe指向 Multiverse指向

    プロプラ/ クラウド
  8. 8 NewSQLとは何か 2

  9. 9 2-1.Spannerの登場 • Spanner: Google’s Globally Distributed Database(2012) を発表。 •

    SQL準拠、ACIDトランザクションをサポート。 • 地理分散が可能な、分散型SQLデータベース。 • 従来RDBが弱いとされた、Writeもスケールアウトが可能。 • 国内でもスマホゲームや決済アプリのプラットフォームとして利用される。
  10. 10 2-2.NewSQL(Spannerクローン)の成り立ち • NewSQL自体はNoSQLへの対比として生まれ、2011年頃に既に登場。 • VoltDBやNuoDBなど、NoSQLが解決できなかった課題(マルチマスタ・ スケールアウト型のRDB)の解決を目指していた。 • そして、Google Cloud

    Spanner以降、類似実装のOSSクローンが誕生する。 • その特徴は、 • 強い整合性を持ち、 • ACIDトランザクションをサポートする、 • (地球規模に展開可能な)分散SQLデータベース
  11. 11 2-3.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. 12 NewSQLの構成要素について学ぶ 3

  13. 13 Shard2 SQLクエリエンジン 分散Txn Mgr 3.NewSQLのコンポーネント概観 Shard1 SQLクエリエンジン 分散Txn Mgr

    • 拙blogでは分散SQLデータベースのコンポーネントを以下4つに分類。 • データの”整合性を保ち“、”冗長化”し、 ”分散“し、”永続化”する方法を解説 している。 Shard3 SQLクエリエンジン 分散Txn Mgr ① ストレージエンジン 如何にデータをローカルに永続化するか ② Sharding 如何にデータを分散して配置するか ③ Raft 如何にデータを冗長化し、可用性を実現するか ④ 分散トランザクション 如何にデータの整合性を保ちつつ、更新するか
  14. 14 3-①.ストレージエンジン • 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. 15 3-②.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. 16 3-③.Raft Tablet2 Tablet1 Tablet2 Table1 Tablet2 Tablet1 Tablet3 Tablet3

    Tablet3 • etcdなどは単一Raft グループで構成される 分散KVS。Leaderは 当然一つ。 • YugaButeDBなどはマ ルチRaftグループで、 グループ毎にLeader が存在。つまりマルチ マスタの構成となる (hotspot問題はあり)。 • NewSQLのデータ・レプリケーションにはRaft が使われている。 • Multi Raft Groupによりマルチマスタ構成を実現している。
  17. 17 3-④.分散トランザクション • もっとも説明が難しい部分。 • Isolation(同時実行されたトランザクションから他がどう見えるか?)と、 Consistency(同時実行されていないトランザクションの順序性)を、 どう扱うか。※詳しく知りたい方は↓

  18. 18 まとめ • 複雑なマルチデータストア(Multiverse)は、DevOps双方に複雑性を招く。 マネージドなDBサービスでもK8sを使っても、完全には解消できない。 • そうした課題に対して、NewSQLは以下の特徴を持つ。 • 強い整合性を持ち、 •

    ACIDトランザクションをサポートし、 • (地球規模の展開が可能な)分散SQLデータベース • 特にSpannerの成功は、これまでのRDBMSの拡張性・一貫性に対する見方を 大きく変える可能性がある。 • NewSQLの構成要素を見ると、データの ”整合性を保ち“、”冗長化”し、 ”分散“し、”永続化”する という4要素に分解でき、各製品はそれらをどのように組み合わせるかで 最適化を図っている。
  19. 19 Questions? @tzkb @tzkoba