Movatterモバイル変換

© 2025 NTT DATA Corporation 5（言葉遊び）もともとNewSQLだったもの達⚫ 「NewSQL」という言葉に違和感を覚える人は多い。⚫ 「いつまでNewなのか」「何に対してNewなのか」「NewSQLより新しいものは？」⚫ 時は遡って2011年、その時のNewSQLは今とは違うものだった。• 分析系でトレンドだったShared-Nothing、さらにインメモリ• VoltDBやNuoDB⚫ クラウドでプラットフォームに最適化されたRDBのクラスタが動けば、Newだった• Amazon RDSやAuroraを指すケースも

© 2025 NTT DATA Corporation 6「2020年現在のNewSQL」⚫ Google Cloud Spannerの登場後に現れた、新しいRDBの特徴を以下のように定義した。✓ 強い整合性を持ち、✓ ACIDトランザクションをサポートする、✓ (地球規模の)分散型のSQLデータベース⚫ 基本的にはNoSQLのカウンターワード。⚫ 2025年現在でも特徴は大きく変わっていないが、ユーザが注目するポイントは少しずつ変わってきている。✓ 書き込みヘビーに対するスケーラビリティは当然重要✓ (ほぼ)ゼロダウンタイム、DBでもローリングアップデートがクラウドユーザに訴求した✓ 地理分散は日本ではあまり必要なかった* https://qiita.com/tzkoba/items/5316c6eac66510233115

© 2025 NTT DATA Corporation 8データベースの分類⚫ クラウド上でのマネージドDB(DBaaS)の利用は一般的になった。⚫ その中でRDBの構成（提供形態）も変化しており、おおよそ以下の6つの種類がある。# 分類代表的なDB・サービス1 単一インスタンス -2 レプリケーション • Amazon RDS• Google Cloud SQL3 双方向レプリケーションによるマルチプライマリ • EDB PostgreSQL Distributed(PGD)• pgactive(RDS for PostgreSQL)4 ログ適用可能なストレージを用いたDB• Amazon Aurora• Google Cloud AlloyDB• Neon5 マネージドシャーディング• Citus• Vitess• Amazon Aurora PostgreSQL Limitless Database6 分散KVS＋SQL• TiDB• YugabyteDB• CockroachDB

© 2025 NTT DATA Corporation 9単一インスタンス⚫ 可用性が低く、スケールアップのみでスケーラビリティの限界値は低い。⚫ とにかくシンプルな構成。⚫ 共有ストレージの利用時も単一インスタンス(アクティブ‐スタンバイ)だが、可用性は向上する。PostgreSQL PostgreSQL• クラウドで仮想化レベルのリカバリーが有効であれば、意外とこれで何とかなることも。• 仮想化レイヤで1つの大きな仮想マシンが作れれば、スケールアップも出来る。（かつてそうした製品もあった）

© 2025 NTT DATA Corporation 10レプリケーション（プライマリ-スタンバイ）⚫ スタンバイサーバを構成して可用性を向上。• 同期レプリケーション：RPO=0• 非同期レプリケーション：RPOは数秒（距離による）• フェイルオーバが発生するため、RTOは1‐3分程度⚫ 読み取りのスケーラビリティが向上可能だが、書き込みは向上しない。PostgreSQL PostgreSQLプライマリスタンバイ書き込み読み取り読み取り• プライマリで読み/書き、スタンバイでは読み取りのみを行う。• スタンバイは1台ではなく、複数台で構成しても良い。

© 2025 NTT DATA Corporation 11双方向レプリケーションによるマルチプライマリ⚫ アクティブ-アクティブ構成でダウンタイムを短縮。⚫ 同じデータに対する異なるサーバからの書き込みで衝突が発生し、別途解決が必要。PostgreSQL PostgreSQLPostgreSQLSQL SQLSQL(非同期)論理レプリケーション• サーバ間で非同期の論理レプリケーションが行われる。• どのサーバからでも、常時書き込み/読み取りが可能だが、競合や読み取りのラグが発生する。• 競合を回避しつつ書き込みを分散させると、水平スケールしない。V=1V=2衝突

© 2025 NTT DATA Corporation 12（参考）書き込みが衝突した際の解決方法⚫ 行単位または列単位(オプション)で競合を検出。⚫ CRDTs (Conflict-free replicated data types)を使うことも可能。⚫ 検出された競合のタイプ別に解決方法を設定できる。⚫ 以下はEDB Postgres Distributedで検出される競合とその解決方法の例。検出される競合の種類デフォルトの競合解決説明insert_exists update_if_newer insertでキー競合を検知。新しいレコードで更新update_differing update_if_newer update時のキー変更を検知。新しいレコードで更新update_origin_change update_if_newer update時に別ノードで更新を検知。新しいレコードで更新update_missing insert_or_skip 存在しない行の更新を検知。新しい行のinsertまたはスキップupdate_recently_deleted skip 削除行の更新を検知。スキップするupdate_pkey_exists update_if_newer update時にキー重複を検知。新しいレコードで更新delete_missing skip 存在しない行の削除を検知。スキップする…

© 2025 NTT DATA Corporation 13ログ適用可能なストレージを用いたDB⚫ 従来のRDBの構成を見直して、ComputeとStorageを分離。• クラウドプラットフォームに最適な形で再構成されたデータベース。• ストレージへWALを送信し、WAL適用は非同期でストレージ内で行われる。⇒「ログ適用可能なストレージ」が採用されている。• リードレプリカが増やしやすい、クローンがしやすいなど運用のメリットが大きい。⚫ 読み取りスケーラビリティはあるが、ラグは発生する。⚫ 書き込みのスケーラビリティは限定的。⚫ 通常は最大ストレージの制限(Auroraは最大128TB)がある。

© 2025 NTT DATA Corporation 14（参考）AlloyDBの構成⚫ PostgreSQL互換のDBaaSでAuroraに近い構成。⚫ DBに最適化されたIntelligentなストレージが特徴で、 WALを受け取って永続化している。⚫ 更にカラムナエンジンや高速キャッシュの機能も搭載。Intelligent Database Storage Engineプライマリ F/Oレプリカリードプール分散ファイルシステム（Colossus）書込時はWALのみを送信ストレージ側でWALを処理して、耐久性の高いストレージへ書込み

© 2025 NTT DATA Corporation 15マネージドシャーディング⚫ テーブルをシャードに分割して、複数サーバに配置する構成。• サーバを増やすことで、読み取り/書き込みのスケーラビリティが向上。• 大規模アプリケーションで採用されているケースがあるが、一般的な構成とは言えない。⚫ 過去からいくつかの課題が存在する。• クエリの振り分けや集約を行うコーディネータがボトルネックとなりがち。• マルチシャードの処理が遅く、2PCが必要とされる。• 上記を回避するためにデータモデリングとサーバ構成が密結合になりがち。⚫ 近年GAとなったAurora Limitless Databaseが起爆剤となるか？

© 2025 NTT DATA Corporation 16（参考）Aurora Limitless Database⚫ Router/Shardの2種のノードを用いて、2層+Auroraストレージからなる水平スケール可能な分散SQLデータベース（PostgreSQL互換）を実現している。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/limitless-architecture.html• Endpointは1つでクライアントからは1つの大きなDBとして見える。• Routerはメタデータを保持し、SQLを解析後に必要なコマンドをShardに送信する。データの集約も行い、クライアントに応答する。• Routerは複数Shardに跨る分散トランザクションを管理する。• ShardはAurora PostgreSQLのDBインスタンスそのもの。異なるShardには異なるデータセットが格納される。

© 2025 NTT DATA Corporation 17（参考）AWSのPostgreSQL互換DBにおける位置づけ⚫ RDS、Aurora、そしてマネージドシャーディングとしてLimitless DBがラインアップされた。⚫ 更にマルチリージョンでマルチプライマリが可能なDSQLが登場。プライマリスタンバイプライマリリードレプリカRDS（単一インスタンス）*リードレプリカも可Limitless Database（マネージドシャーディング）トランザクションルータ(コーディネータ)...シャードAurora（ログ適用可能なストレージ）ストレージレイヤの同期レプリケーションクラウドに最適化されたストレージを利用し、基礎性能や可用性を向上

© 2025 NTT DATA Corporation 18分散KVS＋SQL⚫ TiDBやYugabyteDB、CockroachDBなどNewSQLが採用しているアーキテクチャ。⚫ シャーディングで水平スケールを実現、Raft(合意プロトコル)でレプリケーションを行う。クエリエンジンKVS KVS KVSクエリエンジン • SQLを扱うComputeレイヤはステートレス• Storageレイヤは分散KVSで、トランザクションやレプリケーションを担当する。• コンポーネントが多く、レイテンシーが劣化しやすい。スループットは向上する。ComputeStorageSQL SQLKey-Value Key-Value

© 2025 NTT DATA Corporation 20Google Cloud Spanner⚫ 2012年「Spanner: Google’s Globally Distributed Database」の論文が発表されている。⚫ 2025年現在は「実質的に無制限のスケーリングを備えた、常時稼働のデータベース」⚫ マルチI/Fなデータベースへ進化を続けている（Graph、Cassandra対応などもプレビュー中）。Span ServerSplitComputeStorage(Colossus)Google SQL PostgreSQLSpan Server Span ServerSplit Split Split Split Split Split Split Split• データをSplitに分割。• Span Serverは一定範囲のSplitを管理。• マルチSplitのトランザクションにはPaxosを用いる。• 分散ストレージとしてColossusが利用されている（KVSではない）。• マルチリージョン対応が可能。Region① Region② Region③

© 2025 NTT DATA Corporation 21Google Cloud Spannerの注目すべきリリース デュアルリージョン• 通常は3地域が必要なマルチリージョンを、2リージョンで構成。日本(東阪)で最適。• RF=6、Paxosの合意には4ノードが必要。• RPO=0だがRTO≠0、障害時は手動でローカルリージョンへ再構成。 Data Boost• OLTPとは別に分析用のComputeリソース。Colossusは共有する。* https://cloud.google.com/blog/ja/products/databases/spanner-dual-region-configurations-for-data-residency* https://cloud.google.com/blog/ja/products/databases/understanding-cloud-spanner-data-boost?hl=en

© 2025 NTT DATA Corporation 22Aurora DSQL⚫ AWSが公開した（現在プレビュー）のマネージドDB。⚫ 「常に利用可能なアプリケーション向けの最速のサーバーレス分散SQLデータベース」⚫ PostgreSQL互換としているが、通常Auroraと比較して互換性は低い。JournalQueryProcessorSQLQueryProcessorRegion① Region② Region③AdjudicatorStorageAdjudicatorStorageJournalSQLReadWrite• マルチリージョンでマルチプライマリ。• 楽観的同時実行制御(OCC)が行われ、コミット時にAdjudicatorが他リージョンで更新がないかを確認して調停。• 問題なければ、Journalにログを書き出してクライアントへ応答。• JournalからStorageへの適用は非同期。

© 2025 NTT DATA Corporation 23TiDB⚫ PingCAPが開発している、MySQL互換のNewSQL。⚫ 書き込みヘビーなワークロードの移行先として、国内でも注目される。• 下記のコンポーネントから構成される。• PD• メタデータ管理やグローバルタイムスタンプの発行• TiDB• ステートレスなクエリエンジン• TiKV• 行ストア用途の分散KVS• ACIDなトランザクションに対応• TiFlash• 列ストア用途のストレージエンジン• 同期更新ではないが、読み取り時に一貫性を確保* https://docs.pingcap.com/ja/tidbcloud/tidb-architecture/

© 2025 NTT DATA Corporation 24TiDBの注目すべきリリース TiProxy• TiDBへの接続を分散し、プーリングする。 リソース制御• TiDBクラスターにリソースグループを設定し、グループごとに利用可能なリソース量を設定。• マルチテナントの環境で、特定グループにリソースが占有されるような状況を防止。* https://docs.pingcap.com/ja/tidb/stable/tiproxy-overview/OLTP バッチ向け分析リソースグループリソースユーザ①ユーザ②バッチPGM帳票②帳票①CPU IO

© 2025 NTT DATA Corporation 25YugabyteDB⚫ Yugabyte社が開発しているNewSQL。PostgreSQL/Cassandra互換のインターフェースを持つ。⚫ PostgreSQLとの互換性はかなり高く、スケールアウト構成への移行先として魅力的。* https://github.com/yugabyte/yugabyte-db/blob/master/README.md• ユーザデータを扱うyb-tseverと、メタデータを扱うyb-masterが各サーバに配置される。

© 2025 NTT DATA Corporation 26YugabyteDBの注目すべきリリース コネクションマネージャ• ノード内のコネクションをプーリング。• クライアントの接続には専用ドライバを利用。 xCluster• クラスター間の非同期レプリケーション• 災害対応での利用を想定。* https://docs.yugabyte.com/preview/explore/going-beyond-sql/connection-mgr-ysql/ * https://docs.yugabyte.com/preview/architecture/docdb-replication/async-replication/#active-active-single-master

© 2025 NTT DATA Corporation 27CockroachDB⚫ PostgreSQL互換のNewSQL、名前のインパクトが大きい。⚫ グローバルレベルの地理分散機能に強みを持つ。* https://github.com/cockroachdb/cockroach/blob/master/docs/design.md• クエリエンジンと分散KVSがそれぞれのノードに配置される。• YugabyteDBに近い構成を持つ。• PostgreSQLバージョンへの追従は比較的遅く、機能別の対応に方針を変えたように見える。

© 2025 NTT DATA Corporation 28CockroachDBの注目すべきリリース 物理クラスターレプリケーション(PCR)• アクティブ‐スタンバイでPostgreSQLのStreaming Replicationに近い。 論理データレプリケーション(LDR)• アクティブ‐アクティブも可能で、PostgreSQLのLogical Replicationに近い。* https://www.cockroachlabs.com/blog/isaster-recovery-cockroachdb-surviving-failures/

© 2025 NTT DATA Corporation 29（参考）NewSQLでクラスター間レプリケーションが必要？⚫ NewSQLは地理分散に向くのは事実だが、障害時の構成を検討すると色々と課題がある。⚫ リージョン障害に耐えるために3リージョンが必要で、それぞれに配置するサーバ数も性能に大きく影響する。⚫ 詳しく知りたい方は「マルチクラウドデータベースの教科書」がおすすめ。Region① Region② Region① Region② Region③【2リージョンのストレッチクラスター】【3リージョンのストレッチクラスター】Region① Region②※①の障害でDB継続不可 ※①の障害でもDB継続【2リージョンのクラスター間レプリケーション】※①の障害でも切り替えてDB継続

© 2025 NTT DATA Corporation 31NewSQLのコンポーネント⚫ NewSQLのアーキテクチャを①-④のコンポーネントに分解して解説する。クエリエンジン分散Txn MgrComputeStorageShard1 Shard2 Shard3クエリエンジンクエリエンジン分散Txn Mgr 分散Txn Mgr①ストレージエンジン書き込み重視でデータを格納。②シャーディングスケーリングのためにデータを分散。③Raft高可用性のためにデータを冗長化。④トランザクションデータをどのように見せるか/更新するか。

© 2025 NTT DATA Corporation 32① ストレージエンジン⚫ ストレージエンジン：物理的にデータを格納する役割を持つ。⚫ 評価するポイントとして、Read/Write/Spaceの効率性がある。• B-Tree ：従来RDBで利用、コピーが1つでReadが得意。書き込みはIn-place、Write Amplificationが起きやすく効率は悪い。更新用にブロックの空きを保持する必要があり、Space効率も悪くなりがち。⚫ NewSQLでは、書き込みを重視してLog-Structured Merge Tree(LSM-Tree)が使われる。• LSM-Tree：追記型のデータ構造。Writeがシーケンシャルになり効率的。Readは複数バージョンから調停するので効率は悪い。圧縮プロセスもあり、Space効率は高くなる。• 追記型の書き込みはSSDと相性が良い。In-placeではSSDの劣化が早くなりがち。

© 2025 NTT DATA Corporation 34①-1 LSM-Treeの実装：RocksDB⚫ Facebookが開発した組み込みのKey-Valueストア。* https://github.com/facebook/rocksdb/wiki/RocksDB-Overview• LSM-Treeでは、まずメモリ上の構造(Memtable)にデータが書き込まれる。• RocksDBではオプションでMemtableの書き込み時にWALを書いて、リカバリに利用できる。• Memtableが一杯になると、ディスク上のSST(Sorted String Table)ファイルへフラッシュされる。この際はシーケンシャルな書き込み。• SSTファイルはCompactionプロセスで、マージと圧縮が行われる。この際、不要データも削除される。

© 2025 NTT DATA Corporation 35（参考）具体的なRocksDBの利用例⚫ TiDBではストレージエンジンとして、RocksDBと独自エンジンの両方が利用されている。• RocksDB ：ユーザデータの書き込み先（Raft Logの適用先）RocksDBのインスタンスを複数にする、Partitioned Raft KVの機能を開発中。• Raft-engine：Raft Logの書込み先となる独自エンジン(過去にはRocksDBを利用)。ログ書込みに最適化されており、RocksDBから不要な機能を削除。Raft Log ユーザデータRaft-engineRocksDBTiKVノードRaft Log ユーザデータRaft-engineRocksDBTiKVノードRaft Log ユーザデータRaft-engineRocksDBTiKVノードレプリケーション

© 2025 NTT DATA Corporation 36（参考）RocksDBでIOを削減する工夫⚫ RocksDBでは1レコードのサイズが大きくなると、CompactionプロセスでIOが増大する。⚫ TiKVでは、大きなレコードはSSTファイル外で管理するTitanという機能が実装されている。• Titanでは、Memtableのフラッシュまでは通常のRocksDBで取り扱う。• Compactionのプロセスで閾値を超えたレコードから、値を分離してBlobに格納。• RocksDBとの互換性を重視した機能だが、ReadとSpaceの効率が劣化するため、利用には注意が必要。* https://docs.pingcap.com/tidb/v8.1/titan-overview/

© 2025 NTT DATA Corporation 37①-2 LSM-Treeの実装：DocDB⚫ YugabyteDB内で使われている、RocksDBベースのストレージエンジン。⚫ DocDBではクエリエンジンからPush Downされた処理に対応し、ストレージエンジン側で効率的なスキャンやフィルタリングを行う。• 例）Seq Scan時のリモートフィルタなど• DocDBでは、シャード(tablet)ごとにRocksDBのインスタンスを管理する構成。• この構成により、シャードをノード間で移動させたり、テーブル削除する際の処理が効率化される。• Raftで書き込みの永続化が保証されるため、RocksDBのWAL機能はOffにして効率化している。

© 2025 NTT DATA Corporation 38② シャーディング⚫ テーブルをシャードに分割して、複数サーバに配置する。⚫ 以下の観点で各DBのシャードに関する考え方が概観できる。• どんな方法（アルゴリズム）でシャーディングを行うか。• マルチシャードの処理を効率化できるか。• システム規模や負荷に応じて、自動シャーディングが可能か。DB名シャード名アルゴリズムマルチシャードサイズ/シャード自動シャーディングSpanner Split レンジインターリーブ 4GB サイズ/負荷、結合/分割TiDB Region レンジ 96MB サイズ/負荷、結合/分割YugabyteDB Tablet レンジ/ハッシュコロケーション 128MB/1GB/100GB サイズ、分割CockroachDB Range レンジ 128-512MB サイズ/負荷、結合/分割

© 2025 NTT DATA Corporation 39②-1 2種類のシャーディング レンジ・シャーディング• 範囲クエリに強い。• HotSpotが発生しやすい。• 格納時にハッシュ化することは容易。 ハッシュ・シャーディング• 均等分散するため、HotSpotが発生しづらい。• 範囲クエリがマルチシャードとなりがち。• レンジ化はできない。* https://www.yugabyte.com/tech/database-sharding/

© 2025 NTT DATA Corporation 40②-2 自動シャーディング⚫ NewSQLでは、スケーリングに関わる重要な技術となっている。⚫ 「サイズ」ベース• シャードのサイズが大きくなると、自動で分割• シャードのサイズが小さい場合、自動で結合⚫ 「負荷」ベース• シャードでQPSやCPU利用量・トラフィック等が高くなると、自動で分割• シャードで一定期間の利用量が少ないと、自動で結合⚫ 自動シャーディングの注意点• パフォーマンス・性能特性が予期しないタイミングで変わる可能性がある• 事前に負荷増が予想できる場合は、手動シャード分割やウォームアップが必要になる

© 2025 NTT DATA Corporation 41②-3 インターリーブ⚫ Spannerでサポートされている、関連テーブルを同一シャードで扱う設定。⚫ 良くJOINされるテーブル間で、同じキーのレコードが同じSplitに配置されるので、マルチシャードのクエリで通信量を削減できる。⚫ 現在ではSpanner以外で実装しているNewSQLはない。親テーブルpkey colA colB001 AAA XXX002 BBB YYYfkey key1 colQ001 100 nnnn子テーブル002 200 mmmm002 300 oooo【インターリーブの論理構造】Split(1)親テーブルpkey colA colB001 AAA XXXfkey key1 colQ001 100 nnnn子テーブルSplit(2)002 BBB YYY002 200 mmmm002 300 oooo【インターリーブによるSplitへの配置】

© 2025 NTT DATA Corporation 42③ Raft⚫ NewSQLでは可用性を高めるために、分割されたシャードをRaft(合意プロトコル)を用いてレプリケーションしている。⚫ Raftには各ノードの役割としてLeader/Follower/Candidateがあり、以下2つの機能を持つ。⚫ Leader選出• 1つの期間(Term)で、1人のLeaderが選出される。• 他の参加者はFollowerになる。• 2人以上がLeaderに選ばれることはなく、データの破損が起きない。⚫ ログ複製• 合意済みのデータは、Leaderが変更されても巻き戻ることはない。• ⇒コミットされたデータは、必要なノード数を満たした上で必ず永続化される。* https://raft.github.io

© 2025 NTT DATA Corporation 43③-1 Leader選出⚫ RaftはLeaderの役割が大きく、レプリケーションや読み取りもLeaderが主導する。⚫ Leaderはハートビートを送信し続けて、自身の状態をFollowerに伝える。⚫ ハートビートが途絶えると、次のTermのLeader選出が以下の流れで行われる。LeaderFollowerFollowerCandidate（選出フェーズ）Term(2)Term(1)Leader①②③④FollowerLeader（通常フェーズ）（Leader選出の流れ）① 前TermのLeaderで障害、ハートビートが停止。② タイムアウトによりFollowerがCandidateとなり、次のTermで選出フェーズを開始。③ Candidateは自身に投票後、他ノードへ投票リクエストを送る。④ 過半数の投票を得ると、CandidateがLeaderになる。

© 2025 NTT DATA Corporation 44③-2 何のためのログ複製？⚫ 「同じ開始状態から、同じ順序でコマンドを与えれば、同じ状態に達する」⇒ State Machine Replication⚫ コマンド＝Raftのログであり、同じ順序でログを適用し続けることで、各ノードのデータを同じ状態に保つ。ソースv=10v=20v=100v=5ターゲット2v=10v=20ターゲット1v=10v=20v=100v=5• ログを複製し、ソースと同じ順序でターゲットに適用。• 課題が2つ発生する。• コマンド順序は入れ替わらないか？• 必要な数だけ確実に複製されたか？• これを合意により保証するのがRaft。

© 2025 NTT DATA Corporation 45③-3 ログ複製⚫ Raftでは安定したLeader-Follower構成を前提にログ複製が行われる。⚫ Leaderが出来るのはログの追記のみで、並び替えや削除は出来ない。⚫ 以下の流れで複製されたログは、次のTermのLeaderにも必ず含まれることが保証される。Leader av=10Follower1v=10Follower1v=10②①②③④⑤（ログ複製の流れ）① 更新リクエストを受信して、Leaderのログに追記。まだコミットはしない。② ログ複製後にFollowerへ送信、応答を待つ。③ Followerの過半数から応答を受けて、Leaderはログをコミットする。④ 更新リクエストの完了を通知。⑤ コミット済みログを適用。

© 2025 NTT DATA Corporation 46③-4 マルチRaft⚫ NewSQLでは単一ではなく、複数のRaft Groupを用いてスケーラビリティを確保する。⚫ Raft GroupごとにLeaderを分散配置することで、マルチプライマリの構成を実現している。⚫ Etcdのような単一Raft GroupのDBも存在する。Shard1Shard2Shard3Raft Group#1Raft Group#2Raft Group#3• 基本的に1Shard=1Raft Group。• 但し、Raft Groupごとにハートビートなどの管理用通信も増えるため、リソース消費の増加に繋がる。• Shardを増やしつつ、Raft関連の通信を最適化する工夫が各DBで検討されている。

© 2025 NTT DATA Corporation 47③-5 Raftでの読み取り最適化 - Lease Read -⚫ Raftで強い整合性の読み取り(最新データの読み取り)はLeaderの役割、かつコストが高い。⚫ 効率化のために、NewSQLではLease Readという仕組みが取り入れられている。LeaderFollowerFollower①Read②Leaderの確認(合意)③ReplyLeaderFollowerFollower①ReadLeaseの期限内であれば、Leaderの確認を省略②Reply【通常のRaft Log Read】【Lease Read】Lease(期限付き)• Leaseは書き込み可能な1ノードのみが持つ。• Leaseの期限は通常時は更新され、Followerにも通知される。• FollowerはLeaderに昇格しても、前Leaseの期限内は新Leaseの取得が出来ない。• 期限後に新LeaderがLeaseを取得、書き込みが可能となる。• 障害時に書き込み不可となる時間があるが、通常の読み取りが高速になる。

© 2025 NTT DATA Corporation 48③-5 Raftでの読み取り最適化 - Follower Read -⚫ Raftでは基本的にLeaderが読み取りを行うが、古い(Stale)データでも良ければ、Followerが読み取りを行うこともできる。⚫ 読み取り負荷分散のために、Follower ReadやStale Readと呼ばれる仕組みが実現されている。LeaderFollowerFollower過去データを問い合わせFollower ReadRead/Lease Read最新ログが送信/適用されていない可能性がある• 過去のタイムスタンプでFollowerに読み取りを行う。• Follower Readの利点として、アプリケーションの近傍(AZやリージョン)からデータを読み取れる点がある。• また、Read-Onlyのトランザクションとなり、更新系トランザクションに影響を与えない。• 但し、TiDBのFollower Readは仕組みが異なり、強い整合性の読み取りを提供する(Stale Readも提供されている)。

© 2025 NTT DATA Corporation 49Proposer③-6 RaftとPaxosの違い⚫ 分散SQLデータベースでは、RaftではなくPaxosを用いて実装されているものも存在する。⚫ 両プロトコルの大きな違いはコンポーネントを分割できるかどうか。⚫ OSSのNeonではMultiPaxosを採用、ログ複製とデータ格納のノードを分離した構成を取る。【Raftの状態遷移】【Neonのノード構成とMutilPaxosのマッピング】* https://raft.github.io/raft.pdfDistinguishedProposerAccpetorProposer AccpetorAccpetorLearnerProposerDistinguishedProposerAccpetorLearner* https://neon.tech/docs/introduction/architecture-overviewをベースに追記

© 2025 NTT DATA Corporation 50④ トランザクション⚫ NewSQLは、Serializable等の高いトランザクション分離レベルを前提に開発されてきた。⚫ 最近では互換性向上のために、Read Committedの採用が増えてきている。DB名 Read Committed Repetable Read SerializableSpanner (preview)Aurora DSQLTiDBYugabyteDB (early access) SnapshotCockroachDB⚫ 但し、同じ名称の分離レベルでもDBごとに実装が少しずつ異なっている場合がある。• CockroachDBのRCはPostgreSQLの改善版になっていて、動作が異なる。• TiDBのRCはPCCで利用可能。ギャップロックがない等、MySQLと異なる。

© 2025 NTT DATA Corporation 51④-1 Spannerのマルチシャード・トランザクション⚫ Spannerのマルチシャード（分散）トランザクションは以下の特徴を持つ。• トランザクションログのレプリケーションのためにPaxosを使用• マルチシャードのトランザクションに2PCを使用• トランザクションの順序付けにTrueTime API(原子時計を用いた高精度な時刻同期)を使用「詳説データベース」【ロック型読み取り書き込みトランザクションの流れ】1. 必要なロックを取得し、commit_tsを取得2. PaxosでProposalを送り、過半数の応答を待つ3. commit waitを行う※この際の待ち時間がTrueTimeに依存4. Paxosでコミット完了を通知する5. ロックを解除する

© 2025 NTT DATA Corporation 52④-2 TiDBの楽観的／悲観的同時実行制御⚫ TiDBは、悲観的同時実行制御(PCC)と楽観的同時実行制御(OCC)を切り替え可能。⚫ TiDBでは、トランザクションの順序付けにPDが発行するTSO(TimeStamp Oracle)を利用する。【TiDBのPCCの流れ】beginget start_tsread with start_tsget for_update_tsacquire lockscommitprewrite with start_tsget commit_tscommit with commit_tssuccessTiDB PD2PCTiKV【TiDBのOCCの流れ】beginget start_tsread with start_tscommitprewrite with start_tsget commit_tscommit with commit_tssuccess/abortTiDB PD2PCTiKVacquire lockswrite in cachewrite in cacherelease locks release locks

© 2025 NTT DATA Corporation 53④-3 YugabyteDBのマルチシャードトランザクション⚫ YugabyteDBでは、Provisional Recordを利用してトランザクションの処理を進めている。⚫ トランザクションのステータスもRaftで複製されるレコードとして管理される。Txn StatusTabletTxn Mgr User DataTablet_1User DataTablet_2write requestcommitsuccess/abortcreate status recordwrite provisional record for Tablet_1write provisional record for Tablet_2change status to commitasync apply provisional recordasync apply provisional record

© 2025 NTT DATA Corporation 55「2025年現在のNewSQL」⚫ NewSQLに分類されるデータベースは一層進化し、成熟度を増している。⚫ 書き込みヘビーだったり、ダウンタイムゼロを求めるワークロードも増加している。⚫ 今日説明したように、NewSQLで使われている技術は新しいものばかりではなく、以前からデータベースで利用されていた技術の組み合わせで成り立っている。（例：レプリケーション、シャーディング、2PC）⚫ 今後、日本最大クラスでなくても、小規模にスタートするサービスでNewSQLを利用する事例は増えていくと考えられる。⚫ その際に、今までの技術と連続性を意識しながら比較を行い、採用を検討する必要がある。

記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。

Movatterモバイル変換

Change Language

2025年現在のNewSQL (最強DB講義 #36 発表資料)

Embed presentation

Recommended

More Related Content

What's hot

Similar to 2025年現在のNewSQL (最強DB講義 #36 発表資料)

More from NTT DATA Technology & Innovation

2025年現在のNewSQL (最強DB講義 #36 発表資料)