個人的にNewSQLに注目しているポイント/What I personally find interesting about NewSQL

Transcript

1. 個人的にNewSQLに注目している ポイント
2. この資料について 自分がNewSQLの何を面白いと思っているかを、ざっくり紹介する 時系列やその理解についての学術的な正確性は特にない。あくまで個人的な観点で の面白さの理解やコンテキスト話すためのもの。デタラメな時系列になっている可能 性がある。全ページに”※個人の感想”という注釈が入っていると思って欲しい。
3. “New”SQL: web業界からの理解 RDBMS ↓ NoSQL ↓ SQL冬の時代 ↓ “Spanner” ↓ NewSQL
4. “New”SQL: web業界からの理解 RDBMS ↓ NoSQL ↓ SQL冬の時代 ↓ “Spanner” ↓ NewSQL Pros. • ACID特性 • 高い信頼性 • 圧倒的実績 Cons. • スケーラビリティが往々にして低い • スキーマ変更が難しい • パフォーマンス的に難しい点がある
5. “New”SQL: web業界からの理解 RDBMS ↓ NoSQL ↓ SQL冬の時代 ↓ “Spanner” ↓ NewSQL BigTable, Dynamo, Cassandraなど。 Pros. • 高いスケーラビリティ • 大量のアクセスでも高いパフォーマンス • 非構造化データ Cons. • ACID特性を保証してくれず、一貫性に関 する考慮が必要 • データ型のチェックが往々にして弱い
6. “New”SQL: web業界からの理解 RDBMS ↓ NoSQL ↓ SQL冬の時代 ↓ “Spanner” ↓ NewSQL やはりRDBMSのメリットを享受したい、かっちりした スキーマで一貫性のあるDBを使いたいが...。 • Vitess, Citus: 本物のRDBMSを水平分割して スケールさせ、アプリ側では(できるだけ)意識せず に使えるようにしたい ◦ ただやはり様々難点はある • VoltDB: パフォーマンスとしてNoSQL対抗する、 SQLが使えるインメモリDB。すべてストアドだった り、インメモリだったりの制約が大きい
7. “New”SQL: web業界からの理解 RDBMS ↓ NoSQL ↓ SQL冬の時代 ↓ “Spanner” ↓ NewSQL ↓ “CloudNative-architecture“ 2012: “Spanner: Google’s Globally-Distributed Database” • 原子時計を用いたアプローチが注目された • TrueTime APIでskewを評価することで、commit waitを短く して、external consistencyを満たすアルゴリズム ◦ やばノードは排除する、最大/最小の時刻がわかる 2017: Google Cloud 上でのSpannerサービスGA • 一貫性のあるスケール可能なSQLを使えるDB ◦ レイテンシ的なペナルティは存在する(NewSQL全般同じ。夢 のDBはない) • インターリーブなどの設計上の癖があるのは否めない
8. “New”SQL: web業界からの理解 RDBMS ↓ NoSQL ↓ SQL冬の時代 ↓ “Spanner” ↓ NewSQL ↓ “CloudNative-architecture“ Google Spanner inspiredたち。レイテンシや癖があるのは同じ。 • YugaByte DB • CockroachDB • TiDB • AWS Aurora Limitless DB(たぶんNewSQLに分類される と思うが、まだあんまり知らない) ※ Spanner vs Calvin という文脈の話もあり、FaunaDBが有名 (SQLではなくFQL)
9. 実装観点での困難と個人的おもしろポイント 以下を両立したいとする。 • 一貫性を担保する • 水平スケーラビリティを確保する 1つのテーブルをシャードに区切って、それを複数ノードで持ち、いい感じに Read/Writeを分散させることを考える。
10. 実装観点での困難と個人的おもしろポイント shardのWrite操作は、Paxos/Raftなどの分散合意アルゴリズムでやる。shard をまたぐ場合は、2 phase commitする。 paxos/raft グループ
11. 実装観点での困難と個人的おもしろポイント Readのときにもわざわざ2 phase lockをしてやりたいのか? めっちゃ遅いけど。 →すべてにtimestampをつけて、ある時刻以前にcommitされたものを読む形式にすれば 良いのでは? →この道具立てがSpanner論文であり、external consistencyの話 Spanner #ポエム - Qiita に図も含めてわかりやすい説明があるので割愛。
12. Spannerを踏まえたNewSQL クラウドの外でもSpannerみたいなものを使いたい。でも、世の中に原子時計を運用できる組 織がどれだけあるのか? (最近はクラウド上だと精度の良いclockがある。AWSだとPTPも使える がうるう秒は自分で 対応が必要。あとClockBoundというのも公開されている) 原子時計がなくても、(それなりのパフォーマンスで) 似たシナリオを実装できる！というのが、 Spanner inspiredなNewSQLたち。
13. TiDBのアーキテクチャ TiDBを例にとって見てみる コンポーネントとして • PD • TiDB • TiKV • (TiFlash) ◦ Optionalな存在なので一旦忘れる
14. TiDBのアーキテクチャ TiDBはSQLを受け取って、PDにどのKV に聞くべきか問い合わせ、SQLを変換して TiKVにリクエストしたり、結果を集めて集 計して返したりする。 TiKV というのが、リージョン(テーブルを) ごとにmuti-raftして、データを保持する Key-Value storage。内部にRocksDB というLSM-tree storage engineを持 つ。Percolator-likeな分散トランザクショ ン制御をする。 PDが超重要コンポーネントで、 placementやメタデータの管理、TiKVの スケジュールなどはもちろんや TimeStamp Oracleも提供する。
15. TimeStamp Oracle TiDBのTSO(timestamp oracle)は46bitの物理クロックと、18bitの論理クロックを合わせて、 64bitの集中管理されたHLCを提供。単調に増加することを保証。 TSOから得た時刻でトランザクションを行うことで、すべてのトランザクションを順序付けできる。 SPOFになりがちだし、ボトルネックにもなる可能性もある。またデータ更新などではTSOへのアクセ スが2回必要なので、レイテンシが大きいとパフォーマンス影響がすぐに起きる。(ので地理分散が難 しい) 参考: • Time Synchronization in Distributed Systems: TiDB's Timestamp Oracle • TimeStamp Oracle (TSO) in TiDB TSOやその他のクロックの比較については、 • Tick or Tock? Keeping Time and Order in Distributed Databases • In-depth Analysis on HLC-based Distributed Transaction Processing - Alibaba Cloud Community
16. まとまっていないまとめ Spannerは1つの金字塔だと思う。 スケールするRDBが欲しいと思っていた人がWebやゲーム業界にはいたはずだが、新しい観点で実 現した。Cassandraを生んだDynamo: Amazon’s Highly Available Key-value Storeに 近いレベルで新しいスタイルを提案したような気がする。(個人の感想) 一方でSpanner inspiredなやつらも、TrueTime APIの置き換え以外も含め、昨今のソフトウェ アの発展を踏まえた内部実装になっている感があり、非常によく考えられたシステムになっているの で面白い。 (AuroraやらのCompute/Storageの分離だとか触れていない話題もあるが、うまく入れ込めな かった)
17. 参考資料 • 地理分散DBについて • Spannerはなぜ原子時計が必要だったのか？ (1) • Spanner #ポエム - Qiita • Percolator - tikv.org