高度な信頼性を実現するデータベース技術 Database Engineering Meetup (DBEM) #3 2024/6/24 山田浩之 

© 2024 Scalar, inc. 自己紹介 ● 山田浩之 ● Scalar, Inc. CTO兼co-CEO ● これまでの研究テーマ ○ 並列クエリ処理、分散トランザクション、ビザンチン故障検知、テキストデータベース等 ● 最近の主著論文: ○ [ICDE’24 Special Track] LakeHarbor: Making Structures First-Class Citizens in Data Lakes （並列クエリ処理） ○ [VLDB’23 Industrial Track] ScalarDB: Universal Transaction Manager for Polystores （分散トランザクション） ○ [ICDE’23 Special Track] Nested Loop Revisited Again（並列クエリ処理） ○ [VLDB’22 Research Track] Scalar DL: Scalable and Practical Byzantine Fault Detection for Transactional Database Systems（ビザンチン故障検知+分散トランザク ション） 2 

© 2024 Scalar, inc. https://github.com/scalar-labs/scalardb https://github.com/scalar-labs/scalardl 3 

© 2024 Scalar, inc. Scalarにおける研究開発の方向性 既存のデータベースが できること 既存のデータベースが できること Scalarと組み合わせると できること 

© 2024 Scalar, inc. VLDB’22 (Research) VLDB’23 (Industrial) 

© 2024 Scalar, inc. ScalarDB (VLDB’23) 

© 2024 Scalar, inc. ScalarDB: 分散トランザクションマネージャ ● 異種のデータベースを跨ったトランザクション（グローバルトランザク ション）においてACIDを保証 ○ 現在はHTAPエンジンとして進化 Relational databases NoSQLs 7 

© 2024 Scalar, inc. Motivation: 複数の異種データベースがあふれる世界 ● “One size does not fit all”な世界 (e.g., AWSにおけるデータベース製品） ● マイクロサービス化によるサービスごとのデータベース分離 ● エンタープライズにおけるデータベースのサイロ化 ScalarDBのゴール: 複数のデータベースを扱う複雑性を軽減したい 8 Complex and inconsistent Simplified and consistent 

© 2024 Scalar, inc. ScalarDBの設計目標 ● データベース非依存性（Database Agnoticism） ○ グローバルトランザクションが様々なデータベースに対して動作 ○ これを最も重要なゴールとして位置付け ● 強い正確性（Strong Correctness） ○ グローバルトランザクションがACIDかつStrict Serializabilityを保証* ● 妥当な性能（Reasonable Performance） ○ グローバルトランザクションの調停が性能のボトルネックにならない ● 高いスケーラビリティ（High Scalability） ○ グローバルトランザクションの性能が下位データベースの性能に基づきスケール ● 高い可用性（High Availability） ○ グローバルトランザクションの調停において高い可用性を実現可能 * AnalyticsはRead-Committedを保証 9 

© 2024 Scalar, inc. ScalarDBの技術的選択 10 Multi-level Transaction Management (e.g., Oracle Tuxedo, Atomikos, Seata XA) Single-level Transaction Management (e.g., Deuteronomy [CIDR’11], Cherry Garcia [ICDE’15]) Pros: XAなどの既存製品がある Pros: 性能を上げやすい Cons: データベース依存度が高い Cons: アプローチが 侵襲的 Pros: データベース依存度が低い Pros: アプローチが侵襲的でない Cons: 弱い分離性 Cons: 性能が上げにくい TM (Coordinator) Abstraction Abstraction TM Abstraction TM DB1 Global Transactions Local Transactions DB2 TM: Transaction Manager TM (Coordinator) Abstraction DB1 Global Transactions Local Transactions DB2 CC: Concurrency Control No CC is required No CC is required 

© 2024 Scalar, inc. ScalarDBの技術的選択 11 Pros: XAなどの既存製品がある Pros: 性能を上げやすい Cons: データベース依存度が高い Cons: アプローチが 侵襲的 Pros: データベース依存度が低い Pros: アプローチが侵襲的でない Cons: 弱い分離性 Cons: 性能が上げにくい ScalarDB のアプローチ ScalarDBが解決 Multi-level Transaction Management (e.g., Oracle Tuxedo, Atomikos, Seata XA) Single-level Transaction Management (e.g., Deuteronomy [CIDR’11], Cherry Garcia [ICDE’15]) TM (Coordinator) Abstraction Abstraction TM Abstraction TM DB1 Global Transactions Local Transactions DB2 TM: Transaction Manager TM (Coordinator) Abstraction DB1 Global Transactions Local Transactions DB2 CC: Concurrency Control No CC is required No CC is required 

© 2024 Scalar, inc. Challenges: ScalarDB が解決する課題 ● Single-TM アプローチを用いて設計目標を達成 ○ データベース非依存性を実現 (Single-TM アプローチにより達成） ○ 高い可用性とスケーラビリティを達成しつつ、並行性制御を拡張し、高い正確 性（Strict Serializability）の保証を実現 ○ 正確性を保証しつつ、性能の改善を実現 ● Single-TM アプローチの製品化における種々の課題を解決 ○ 異種のデータベースに対する一貫性を有するバックアップの取得 ○ トランザクションマネージャ間のスケーラブルなルーティング ○ 分析問い合わせへの対応 

© 2024 Scalar, inc. ScalarDBアーキテクチャ ● データベース抽象化層の上で、トランザクションと分析問合せを実行 ○ データベースを跨るトランザクションと分析問合せが可能に … Transaction Manager Database Abstraction DB1 Shim App App App TM TM TM App App App TM TM TM DB1 DB2 DB3 DB1 DB2 DB3 CRUD Interface SQL GraphQL DB2 Shim DB3 Shim DB-specific Protocols gRPC (HTTP/2) gRPC (HTTP/2) DB-specific Protocols TxID TxID ScalarDB ScalarDB core component (Apache 2) Note: You can directly use ScalarDB core through its library. Analytics SQL 13 

© 2024 Scalar, inc. ScalarDBのトランザクションプロトコル概要（１） ● Cherry Garcia [ICDE’15] をベースに拡張 ○ 下位データベースへの条件： ■ レコードの読み書きがLinearizableにできること ■ レコードにメタデータを付与できること ● コミットプロトコル：二相コミットの亜種 ○ Prepareフェーズ -> Commitフェーズ1 -> Commitフェーズ2 ○ 分散WAL（Write Ahead Logging）により多様なデータベースに対応（後述） ● 並行性制御：楽観的並行性制御（OCC） ○ Linearizableな条件付き書き込みにより競合を検出 ○ Cherry Garciaを改善し、Strict Serializababilityを保証（後述） 14 

© 2024 Scalar, inc. ScalarDBのトランザクションプロトコル概要（２） ● 分散WAL（Write Ahead Logging）により多様なデータベースに対応 ○ ログをレコードに分散させ、一つのレコードを一つのデータベースに見立てる ○ CoordinatorテーブルをPaxos等で複製を管理するDBで保管すればPaxos Commit のような形態も可能 ● 異種のデータベースに対しても同じ抽象化を実施することによりデータ ベース間の差異を吸収 Version TxID Before Col Before Version Before TxID Before Image TxStatus Before TxStatus Col PK After Image TxID Metadata TxStatus アプリケーションが 管理するデータ ScalarDBが管理す るメタデータ User-defined Table Coordinator Table 15 

© 2024 Scalar, inc. トランザクションを Strict Serializable へ（１） ● ScalarDBのベースとなるCherry GarciaプロトコルはTrueTime依存 ● ScalarDBにおいては、高い適用性とスケーラビリティを考慮して、 TrueTime等の信頼できるクロックへの依存を排除 ○ 1バージョンOCCのみを提供（Cherry Garciaは、2バージョンOCC/MVCC） ○ 排除するだけでは、弱い分離性のみを保証（read-committed SI / RCSI） ● HLC（ハイブリッド論理クロック）は不使用 ○ ScalarDBでHLCを実装するには、オペレーションの前後関係 （happened-before relation）を管理するために追加でデータベースへの書き 込みが必要なため 16 

© 2024 Scalar, inc. トランザクションを Strict Serializable へ（２） ● 基本戦略：反依存 (anti-dependency) を暗に追跡 ○ ScalarDBは、明に反依存を追跡する方法 (e.g., SSI [SIGMOD’08], SSN [VLDBJ’15]) との相性が悪い ○ SSI/SSNより保守的だが、ScalarDBアーキテクチャとの相性を重視 TM TM R/W sets R-set ScalarDBのクライアントベース のプロトコルと相性が悪い TM TM R/W sets Write R-set 多数のDB読み書きが発生 R-set Read R/W sets Re-read R-set 多数のDB読み書きなしに 効率的に実行可能 ScalarDBのアプローチ 17 

© 2024 Scalar, inc. 性能最適化 W(X) W(Y) P(X) P(Y) C C(X) C(Y) Prepare フェーズ Commit フェーズ1 Commit フェーズ2 並列 Commit 非同期 Commit W(X) W(Y) P(X) P(Y) C C(X) C(Y) W(X) W(Y) P(X) P(Y) C C(X) C(Y) ● 並列Commit: レコードのPrepare処理とCommit処理を並列に実行 ● 非同期Commit: レコードのCommit処理を非同期に実行 この時点で クライアントに返却 18 

© 2024 Scalar, inc. 製品化への取組み: トランザクション一貫性を保持したバックアップ ● ScalarDBサーバを一時停止してアクティブなトランザクションが存在しない状態 （静止状態）を作成 ● データベース固有のバックアップ機構によりバックアップを取得 ● 楽観的並行性制御の手法を応用して、静止状態が壊れていないことを確認して、 バックアップ成功を応答 Pod (container) 自動修復や自動スケールにより新 しいPodが作られる可能性あり ・・・ 1. ScalarDBサーバ群を特定. 2. アクティブなトラン ザクションを終了した 後一時停止 3. バックアップを取得 4. ScalarDBサーバ群を再度チェックし、状 態等（Pod数やPodの状態）に変更がない かを確認 Kubernetes cluster 19 

© 2024 Scalar, inc. ScalarDBの性能特性 ● 各DBインスタンス: AWS. c5d.9xlarge (18 cores, 72GB DRAM, NVMe SSD) ● クライアント: c5.4xlarge ● ワークロード: YCSB (1000B x 100M records), TPC-C (200-1000 warehouse) ● 比較対象: Atomikos (XA), Seata (XA), ScalarDB C* DL … C* DL C* DL Clients Cassandraを使用 DB DB DB PostgreSQL Scalar DL PostgreSQL Scalar DL Clients PostgreSQLおよびMariaDBを使用 ScalarDB ScalarDB PostgreSQL Scalar DL Clients PostgreSQL & Cassandra を使用 ScalarDB C* DL … C* DL C* DL DB DB DB 20 

© 2024 Scalar, inc. YCSB Workload F MariaDB x 2 MariaDB & PostgreSQL PostgreSQL & Cassandra 低いオーバーヘッドでデータベース非依存性なグローバルトランザクションを実現 グローバルトランザクションのスループット (YCSB) 21 

© 2024 Scalar, inc. Strict Serializable 化のオーバーヘッド 低いオーバーヘッドでStrict Serializabilityを保証 TPC-C MariaDB PostgreSQL 15% slowdown at most 11% slowdown at most 22 

© 2024 Scalar, inc. スケーラビリティ (TPC-C) 下位データベースのノード数の増加に比例してスループットがほぼ線形に増加 23 

© 2024 Scalar, inc. ScalarDL (VLDB’22) 

© 2024 Scalar, inc. ScalarDLとは ● データベースにおけるビザンチン故障検知ミドルウェア ○ ビザンチン故障: 任意の故障（改ざん、悪意のある攻撃、バグ） ● これまでの分散データベースではクラッシュ故障までにのみ対応 Transaction Database System ビザンチン故障の検知を保証 

© 2024 Scalar, inc. Motivation: データ社会においてはデータの正しさが重要 ● データ中心の社会においてはデータの正しさ（真正性）が重要 ● データを保存するデータベースが正しく動作することが肝要 ● データベースの正しさを保証するための一つの方法として、ビザンチン故 障への対処がある データベースにおいて実用的かつスケーラブルにビザンチン故障に対処したい DB Process1 Process2 

© 2024 Scalar, inc. ● 基本原理：レプリカ間の差異を検出 ● ビザンチン故障のマスキング (BFT: Byzantine Fault Tolerance) ○ N > 3f, N: レプリカの数, f: ビザンチン故障の数 ● ビザンチン故障の検知（BFD: Byzantine fault detection (BFD)) ○ N > f, N: レプリカの数, f: ビザンチン故障の数 AD-1 AD-2 AD-3 AD-4 1つのビザンチン故障をマスクするために 4管理ドメイン（AD）が必要 2つのADで1つの ビザンチン故障を検知可能 AD-1 AD-2 BFT BFD ScalarDLのアプローチ ビザンチン故障の対処方法 

© 2024 Scalar, inc. BFT (Byzantine Fault Tolerance) N > 3f, マスキング BFD (Byzantine Fault Detection) N > f, 検知 SMR トランザクション を逐次実行 DB トランザクション を並列実行 BFT SMR PBFT [OSDI’99], BFT-SMaRt [DNS’14], HotStuff [PODC’19] BFD SMR PeerReview [SOSP’07] BFT DB HRDB [SOSP’07], Byzantium [EuroSys’11], Hyperledger Fabric [EuroSys’17], Basil [SOSP’21] ？ Challenges: スケーラブルな BFD アプローチ 

© 2024 Scalar, inc. BFT DB を拡張して BFD DB が実現可能であるか？ ● レプリカを２つの管理組織（AD）に分離すればOK? => NO ● 1レプリカにおけるビザンチン故障により保証条件が不成立 N=4, f=2 => N>3f BFT DB を拡張して BFD DB を実現する のは困難 AD-1 AD-2 

© 2024 Scalar, inc. BFD SMR を拡張して BFD DB が実現可能であるか？ ● BFD SMR でトランザクションを並列実行可能か？ => 部分的にYes ○ プライマリ側でのみ並列実行可能 ● 正しさを保証するには、セカンダリ側ではハッシュチェーンベースのログ を逐次的に実行する必要あり ○ セカンダリ側で並列実行するとタイムトラベル異常が発生 AD-1 AD-2 T1 T2 T2 T1 hash-chained log プライマリ セカンダリ（Witness） 逐次実行が必要 

© 2024 Scalar, inc. BFT (Byzantine Fault Tolerance) N > 3f, マスキング BFD (Byzantine Fault Detection) N > f, 検知 SMR トランザクション を逐次実行 DB トランザクション を並列実行 BFT SMR PBFT [OSDI’99], BFT-SMaRt [DNS’14], HotStuff [PODC’19] BFD SMR PeerReview [SOSP’07] BFT DB HRDB [SOSP’07], Byzantium [EuroSys’11], Hyperledger Fabric [EuroSys’17], Basil [SOSP’21] BFD DB ScalarDL [VLDB’22] Challenges: スケーラブルな BFD アプローチ 

© 2024 Scalar, inc. ● 厳密な直列化可能性を保証しつつ、トランザクションを並列に実行 ● DBのAPIだけを用いることでデータベース非依存かつ非侵襲に実現 Primary Secondary Scalar DL Primary Servers Primary Database AD1 Scalar DL Clients Applications Scalar DL Secondary Servers Secondary Database AD2 Database System ScalarDL: スケーラブルかつ実用的なBFDアプローチ 

© 2024 Scalar, inc. ● トランザクションの半順序を分権したまま並列に合意 ○ プライマリとセカンダリが、トランザクション実行順序を明に共有することな く同じ結果になるようにオペレーション列の送信順序を制御 ○ メッセージ認証（HMAC）を利用して、プロトコルを強制 ● 3フェーズのプロトコル: Ordering -> Commit -> Validation. ● 詳細は後述の論文を参照ください Client Secondary Primary Ordering Commit Validation ScalarDLの基本アイデア 

© 2024 Scalar, inc. ● 2PLの亜種を用いてトランザクションを Strict Serializable に順序付け ○ トランザクションを仮実行し、R/W セットを取得 ○ 下位の DB の Linearizable なオペレーションを用いて R/W ロックを取得 ○ トランザクション ID に対するメッセージ認証をクライアントに返却 ● 明に順序を共有しないことから、プライマリとセカンダリは異なる Version Order になりうるため、Multi-version の活用は困難 Primary key Version Lock count Lock mode Lock holders (TxIDs) Input dependencies Lock entry: のセット Client Secondary Primary Ordering Commit Validation トランザクショ ンの半順序関係 ScalarDL BFD プロトコル - Ordering フェーズ 

© 2024 Scalar, inc. ● クライアントとセカンダリからのメッセージ認証を検証 ○ セカンダリを通っていないリクエストはアボート ● トランザクションを任意の順序で ACID に実行 ○ を DB にログとして書き込み（リカバリ用） ○ 書けた時点でコミットが確定 ● 実際に書かれた R/W セット（Proof）とそのメッセージ認証と実行結果 を返却 Primary key Version TxID Input dependencies MAC Proof entry: Client Secondary Primary Ordering Commit Validation トランザクション の半順序関係 ScalarDL BFD プロトコル - Commit フェーズ 

© 2024 Scalar, inc. ● プライマリからのメッセージ認証を検証 ● 半順序関係を比較（Lock entry と Proof entry を比較） ● セカンダリ側でトランザクションを再実行 ● クライアントでプライマリとセカンダリの実行結果と Proof を比較 ○ 異なるならビザンチン故障と判断 Primary Secondary Result Proofs Result Proofs 2. Commit phase 3. Validation phase Compare =? Compare lock table =? Pre-validation Client Client Secondary Primary Ordering Commit Validation ScalarDL BFD プロトコル - Validation フェーズ 

© 2024 Scalar, inc. 評価実験 ● 各DBインスタンス: AWS. c5d.4xlarge (8 cores, 32GB DRAM, NVMe SSD) ● クライアント: c5.9xlarge ● ワークロード: YCSB (100B x 100M records), TPC-C (1000 warehouse) ● 比較対象: PeerReviewTX（PeerReviewの拡張）、ScalarDL PostgreSQL Scalar DL C* DL … PostgreSQL Scalar DL C* DL C* DL C* DL … C* DL C* DL Clients Clients AD AD AD AD 

© 2024 Scalar, inc. PostgreSQL環境での評価実験結果 YCSB-F TPC-C (NP) ScalarDLは並行性制御により、スレッド数の増加に伴い性能がスケール （PeerReviewTxは4スレッドで頭打ち） 

© 2024 Scalar, inc. Cassandra環境での評価実験結果 YCSB-F TPC-C (NP) Cassandraでの同様の傾向（データベース非依存性の実現を確認） 

© 2024 Scalar, inc. スケーラビリティ (TPC-C) ADごとのノード数の増加に比例してスループットがほぼ線形に増加 

© 2024 Scalar, inc. まとめ ● Scalarは、既存のDBではうまく扱えない信頼性の課題の解決に挑戦 ● ScalarDBは、複数のヘテロなDBにおいてACIDトランザクションを実現 ○ Core部分のソースコード・ドキュメントはApache 2.0の元で公開 ○ 詳細は論文を参照ください “ScalarDB: Universal Transaction Manager for Polystores” @VLDB’23 ● ScalarDLは、DBにおいてビザンチン故障をスケーラブルかつ実用的に検知 ○ 詳細は論文を参照ください “Scalar DL: Scalable and Practical Byzantine Fault Detection for Transactional Database Systems” @VLDB’22