Upgrade to Pro — share decks privately, control downloads, hide ads and more …

変化と挑戦:NoSQLとNewSQL Serverless Databaseの技術革新とマルチ...

変化と挑戦:NoSQLとNewSQL Serverless Databaseの技術革新とマルチテナンシーの秘密

yoshitaka KOITABASHI

June 14, 2024
Tweet

More Decks by yoshitaka KOITABASHI

Other Decks in Technology

Transcript

  1. “The best way to predict the future is to invent

    it.” ~未来を予測する最良の方法は、それを発明すること~ Alan Kay 2
  2. アジェンダ • データベース技術の変遷 • NoSQL / NewSQL • e.g., NoSQL

    Service Architecture • e.g., NewSQL Service Architecture • Conclusions 3
  3. 4

  4. スケーラビリティが求められる背景 • 1990年以降、インターネット人口が急増 • 書き込みの負荷に対しマシン性能が必要 => 誕生したのがNoSQL • 2006年にGoogleが論文を発表 ”A

    Distributed Storage System for Structured Data” => カラム指向DB: “BigTable” • 2008年にFacebookが”Cassandra”を発表 • 2012年にAWSが”DynamoDB”をLaunch 6 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h10/html/98wp2-3-1f.html
  5. データベース技術の発展 8 データモデル リレーショナル オブジェクト Key-Value ドキュメント グラフ 分散技術 共有ディスク

    オブジェクトストア Primary - Replica パーティショニング シャーディング 分散ストリーム Quorum 分散合意 高精度時刻同期 https://speakerdeck.com/frsyuki/dbakitekutiyanobi-jiao-toxuan-ze データ構造 B+Tree LSM Tree Bitcask Hash Table Bitmap Index AVL Tree Graph ストレージ HDD SSD NVMe
  6. RDBMS / NoSQL 12 Product Database Products Videos Actor Videos

    Albums Tracks Books ID Type Price ID Autor Title ID Artist Title ID Title Category ActorID VideoID ID AlbumID Title A1 (Partition Key) A1 (Partition Key) A1 (Partition Key) A2 (Sort Key) A2 (Sort Key) A2 (Sort Key) A3 Value A4 Value A5 Value A3 Value A4 Value A6 Value Primary Key Table Items Product Table Partition key ProductId = bob ProductId = fred Attributes ProductType = videos, Price=$200 ProductType = Book, Price=$200
  7. Sharding 14 Key Name Stock LastOrdered ARC1 Arc welder 10

    2013-08-18 03:26:28 BRK8 Bracket 23 2013-08-18 03:26:28 BRK9 Bracket 56 2013-08-18 03:26:28 HOS8 Hose 48 2013-08-18 03:26:28 WGT1 Widget 12 2013-08-18 03:26:28 WGT5 Widget 2 2013-08-18 03:26:28 Key Name Stock LastOrdered ARC1 Arc welder 10 2013-08-18 03:26:28 BRK8 Bracket 23 2013-08-18 03:26:28 BRK9 Bracket 56 2013-08-18 03:26:28 Key Name Stock LastOrdered HOS8 Hose 48 2013-08-18 03:26:28 WGT1 Widget 12 2013-08-18 03:26:28 WGT5 Widget 2 2013-08-18 03:26:28
  8. パフォーマンス低下に繋がる恐れ • RDBMSにおいてテーブルの正規化を実施 • 複数テーブルにまたがりレコードの操作(JOIN等)が発生 • テーブル結合がストレージをまたぐ場合、パフォーマンス低下が発生 16 shard_id company_id

    1 1 1 2 2 3 2 4 company_id name 1 company A 2 company B company_id name 3 company C 4 company D company_id invoce_id 1 6100 2 6200 2 6200 company_id invoce_id 3 6300 3 6300 4 6400 ストレージノード 1 ストレージノード 2
  9. ②: NoSQLのデータモデル 18 Key-Value • データをキーとバリューのペアで保存 • Partition Key +

    Sort Keyを組み合わせて一意のPrimary Keyを形成できる • 水平方向に拡張。データをサーバー全体に自動的に分散し、単一サーバーの障害を軽減 ドキュメント • データを JSON オブジェクトのようなドキュメントとして格納 • 直感的なI/Fに加えて水平方向の拡張が可 グラフ • グラフ理論に基づき、”ノード”を使用してデータオブジェクトを格納し、 エッジはノード間のリレーションシップを格納 • データとリレーション、関係性に対するクエリで威力を発揮
  10. データモデルと課題 19 • RDBMSは一般的に静的なテーブル構造を持つ • スキーマの変更が保存データ全体に影響を与える可能性がある • NoSQLでは構造化データを表現しやすくしている (現在では、RDBMSもJSON対応したことで柔軟な設計も可能) •

    SQLのボトルネック 1: 一貫性を重視し、ストレージを共有する設計 2: クエリ次第で性能が大きく変わる (どうしても複雑に組み上げられSubQueryによって高負荷がかかるケースも珍しくない)
  11. 分散データベースにおける整合性 • 分散ストレージが流行ったことに伴いWriteを対象とした 水平分散、シャーディングが注目 => システムのスケーラビリティとパフォーマンスが向上 • 書き込みの分散観点で重要なのは”一貫性” 21 強整合性

    データベースシステムが任意の クライアントから見た時に常に 最新のデータを提供することを保証 結果整合性 データベースシステムが 時間の経過とともに最終的に 一貫した状態になることを保証
  12. CAP定理とConsistent hashing • NoSQL: スケーラビリティとのトレードオフの”一貫性” => スケーラビリティを高めるために一貫性を諦めた • ACIDに対抗しBASEや、CAP定理においてAとPを、CとPと採用みたいな 22

    CAP定理 一貫性 (Consistency) 全てのノードが同じデータを保持し、 参照できる 可用性 (Availability) 常にデータの読み書きが可能 分断耐性 (Partition Tolerance) ネットワーク分断が発生しても システムが動作し続ける 3 75 55 25 Consistent hashing (ハッシュ関数を使いながら データとノードのIDを マッピング) ・Memcached ・Dynamo (パーティショニング コンポーネントで利用 )
  13. Replication - 分散システムにおける負荷分散 24 App Read / Write ‧‧‧ Read

    Only Primary Read Replica よくある構性: Primary/replica PrimaryからReplicaに対するレプリケーション方法 • 同期レプリケーション (強整合性) • Primaryのデータと同じものが得られる(冗長性) • Replicaに問題が発生したり、ネットワーク分断が起きると 同期できなくなる • 非同期レプリケーション (結果整合性) • Replicaの問題やネットワーク分断に関係なく、データ更新可 • Primaryに障害が起きると同期できなくなる • 準同期レプリケーション (結果整合性) 特定のFollowerにデータを同期レプリケーションし、 他のnodeに対しては非同期レプリケーション 同じデータを複数のストレージノードに保持
  14. Sharding - 分散システムにおける負荷分散 25 Consistent Hash Sharding Range Sharding DynamoDB,

    Cassandra, etc… Google Spanner, Apache HBase, TiDB, etc… 3 75 55 25 TxnID Paint Color Amount 1324 3024 $500 1567 2023 $20 1598 1022 $33 1621 1022 $1961 1765 2023 $70 TxnID Paint Color Amount 1598 1022 $33 1621 1022 $1961 TxnID Paint Color Amount 1567 2023 $20 1765 2023 $70 TxnID Paint Color Amount 1324 3024 $500 1000~1999 2000~2999 3000~3999
  15. 分散合意形成アルゴリズムと一貫性 分散データベース: Consensus(合意)形成は重要 • 与える命令の順序を制御し、 異なるReplicaを作り出さないようにする • リーダーの決定や分散トランザクションに利用 一貫性を保つ合意アルゴリズム •

    Paxos • Raft 26 https://lamport.azurewebsites.net/pubs/lamport-paxos.pdf https://research.google/pubs/paxos-made-live-an-engineering-perspective-2006-invited-talk/ https://raft.github.io/ 札幌! 沖縄! 福岡! 仙台! 京都! 石川! どれか1つに 旅行どこ行く?
  16. NewSQL 歴史 • 2012年にGoogle Cloud Spannerの論文が公開 • その後、生まれたのがTiDB、CockroachDB、YugaByteDB 特徴 •

    SQLインターフェースを持つ • 強整合性 • スケーラビリティ 29 https://research.google/pubs/spanner-googles-globally-distributed-database/
  17. NewSQL Architecture 31 Product Database Products Videos Actor Videos Albums

    Tracks Books ID Type Price ID Autor Title ID Artist Title ID Title Category ActorID VideoID ID AlbumID Title App Leader: Read/ Write Follower: backup Role Read / Write Node A Computing Nodes Node B Node C [Table Design] [Architecture Design]
  18. Amazon DynamoDB SimpleDB(AmazonのNoSQL) + Dynamoを組み合わせたNoSQL 34 https://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html Id: 1 Title:

    “AAA” Category: “horror” Id: 2 Title: “BBB” Category: “comedy” Id: 3 Title: “CCC” Category: “action” Partition Key Hash(1) = 7B Hash(2) = 48 Hash(3) = CD DynamoDB テーブル構成 (Videos) Hash.MIN = 0 Hash.MAX = FF Partition A Partition B Partition C 00 55 AA FF
  19. Replication 35 Id: 1 Title: “AAA” Category: “horror” 3多重なReplication •

    常に3AZ(Availability Zorn)でReplication • I/Oも3AZで実行 Hash(1) = 7B Hash(1) = 7B Availability Zone 1 Availability Zone 2 Availability Zone 3 Host 1 Host 2 Host 3 Host 4 Host 5 Host 6 Host 7 Host 8 Host 9
  20. Architecture 36 https://www.usenix.org/system/files/atc22-elhemali.pdf User Network Request Router Global Admission Control

    Authentication System Partition Metadata System Storage Node (AZ1) Storage Node (AZ2) Storage Node (AZ3) SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD
  21. System Management 37 Partition Metadata System Auto Admin SSD SSD

    SSD SSD SSD SSD B+Tree Storage Node Put Put Put Delete ・・・ Replication log SSD SSD SSD SSD SSD SSD B+Tree Storage Node Put Put Put Delete ・・・ Replication log SSD SSD SSD SSD SSD SSD B+Tree Storage Node Put Put Put Delete ・・・ Replication log ・テーブルとインデックスの作成 ・テーブルとインデックスのプロビジョニング ・パーティションの分割 ・パーティションの修復
  22. TiDB Serverless 42 数十秒で起動し、自動でスケールする 従量課金のサーバレスデータベース サーバの管理不要 拡張が自動 ⾃動拡張 Pay as

    you go 従量課⾦ 自動フェイルオーバーと自 己回復 ゼロ ダウンタイム + HTAP機能も使用可能 リアルタイム分析 パフォーマンス改善 日本語によるSQL 生成支援 AI アシスタント MySQL driverやORM ツールからも利⽤可能 MySQL互換 https://aws.amazon.com/jp/blogs/storage/how-pingcap-transformed-tidb-into-a-serverless-dbaas-using-amazon-s3-and-amazon-ebs/
  23. Architecture 44 • 全体としてマルチテナントアーキテクチャ • 負荷に応じて専⽤のTiDBがアサイン Shared Gateway Isolated SQL

    Layer Shared Storage Layer Gateway Gateway Gateway Virtual Cluster - Tenant 1 TiDB MPP Row Engine Row Engine Row Engine Virtual Cluster - Tenant 2 Resource Pool TiDB TiDB MPP Worker Columnar Engine Columnar Engine Columnar Engine TiDB MPP Virtual Cluster - Tenant n TiDB MPP MPP MPP TiDB ・・・ EBS EBS EBS EBS EBS EBS Shared Storage Pool Amazon S3 Shared Service Compaction Checksum Analyze Coprocessor Import Export DDL PD TSO Scheduling API Server
  24. Amazon S3 / Amazon EBS オブジェクトストレージ: (Amazon S3) • 転送されたデータによるパフォーマンスの干渉を回避を目的に、

    ノード間の共有ストレージとして採用 • TiKVとTiFlashのストレージ レイヤーを Amazon S3 に直接書き込む => スケールアウト時に新ノードは、Amazon S3 に接続するだけで済む 永続的なSSDストレージ(Amazon EBS) • Raftアルゴリズムにも対応でき、低レイテンシーの パフォーマンスプロファイルを備えた永続的なSSDストレージが必要 • メタデータやWALなど、レイテンシの影響を受けやすい情報を保存 49
  25. 各コンポーネントの使い分け 1. データファイル(WAL/メタデータを除く) を 揮発性ブロックストレージ(EC2インスタンスストア)にキャッシュ 2. メタデータや WAL などを永続的なSSDストレージ(EBS)に保存 ・各トランザクションの読み取りおよび書き込み操作に優れたパフォーマンスを発揮

    ・ インスタンス障害に対する永続性も担保 3. データ永続性のレイヤーにオブジェクトストレージ(S3)を利用 ・ 耐久性と、事実上無制限のスケーラビリティおよび読み取り/書き込み帯域幅を享受 50
  26. Storage architecture data workflow 51 1. TiDBノードがTiKVへプッシュダウン 2. 最初にリーダーレプリカが存在するノードのEBSに WALとRaft

    ログが書き込まれる 3. Raft ログが残りのフォロワーレプリカに伝播 4. データをEC2インスタンスストアに キャッシュした後、TiDBは変更を S3に非同期的に書き込み 5. TiDB は他の2つのフォロワーレプリカに データ読み込み信号を送信し、 信号を受信すると、フォロワーレプリカは S3からデータを読み込み、 マルチレプリカレプリケーションが完了 Leader EBS TiKV Follower EBS TiKV Follower EBS TiKV Amazon S3 1: Write Data 2: Write log / Metadata 3: Sync Raft Logs 4: Upload Data 5: Download Data New TiKV New TiKV New TiKV DDL Compaction Fast Scale-out off-Loaded Operations