
RDBの信頼性とNoSQLのスケーラビリティを兼ね備えたNe
第1章 序 論 ――なぜいまNewSQLが注目されているのか
1.1 RDB vs NoSQLの対立と「解決策」としてのNewSQLの登場
1.2 NewSQLがいま注目されている理由 ――RDBとNoSQLのいいとこどり
1.3 NewSQLの登場
1.3.1 障害とは何か
1.3.2 中央集権的コーディネータの不在
column 結果整合性
1.4 NewSQLの課題
1.5 代表的なNewSQL製品
1.5.1 Google Cloud Spanner
1.5.2 TiDB
1.5.3 YugabyteDB
1.5.4 CockroachDB
1.5.5 Amazon Aurora DSQL
1.6 NewSQLの今後の展望
1.6.1 AI関連機能の充実
1.6.2 クラウドネイティブ化とマルチクラウド対応
1.7 NewSQLに関する12の疑問
Q.1 クラウドでしか使えないの?
Q.2 なぜ分散合意アルゴリズムが使われるの?
Q.3 既存のデータベースとどの程度互換性があるの?
Q.4 スケーラビリティがあるという話だけど、ノードのオートスケール機能はあるの?
Q.5 使っているユーザーはたくさんいるの?
Q.6 ダウンタイムなしで運用できるの?
Q.7 日本で使えるNewSQL製品は何があるの?
Q.8 無料で試せるの?
Q.9 アプリケーションから見るとRDBに見えるの?
Q.10 スケーラビリティはそれほど求めていないけど、スモールスタートはできるの?
Q.11 原子時計を使うデータベースのことではないの?
Q.12 どの程度SQLをサポートしているの?
column 二つの分散システム ――ブロックチェーンとNewSQL
1.8 まとめ
第2章 アーキテクチャから見るNewSQLへの進化
2.1 データベースの分類
2.2 単一インスタンス
column Oracle RACをどう考えるか
2.3 レプリケーション
column 可用性の尺度としてのRPOとRTO
2.4 双方向レプリケーションによるマルチプライマリ
colum EDBにおける競合検出と解決の手法
2.5 マネージドシャーディング
colum Aurora Limitless DatabaseとAtomic Visibility
2.6 ログ適用可能なストレージを用いたDB
2.7 分散ストレージ+SQL
2.8 まとめ
第3章 NewSQL製品ごとのアーキテクチャと機能
3.1 Google Cloud Spanner
3.1.1 Spannerのアーキテクチャ
3.1.2 PostgreSQL互換のSQLインターフェース
3.1.3 デュアルリージョン構成
3.1.4 Data Boost
3.2 Amazon Aurora DSQL
3.2.1 DSQLのアーキテクチャ
3.2.2 DSQLのユースケース
column DSQLにおける双方向レプリケーションとの類似性
3.3 TiDB
3.3.1 マルチテナントへの対応
3.3.2 TiProxy
3.3.3 LTSへの対応
3.4 YugabyteDB
3.4.1 PostgreSQL互換性の強化
3.4.2 スマートクライアントドライバーとコネクションマネージャ
3.4.3 xCluster
column NewSQLではクラスター間レプリケーションが必要?
3.5 CockroachDB
3.5.1 クラスター間レプリケーションの強化
3.5.2 PostgreSQLアプリケーションとの互換性向上
3.5.3 ライセンスの変更
3.6 まとめ
第4章 NewSQLの要素技術
4.1 ストレージエンジン
4.1.1 LSM-Treeの概要
column デバイスの変化とLSM-Tree
4.1.2 LSM-Treeの実装
4.2 シャーディング
4.2.1 シャーディングとは
4.2.2 シャーディングの種類
column パーティショニング
4.2.3 自動シャーディング
4.2.4 インターリーブ
4.3 Raft
4.3.1 Raftとは
4.3.2 マルチRaft
4.3.3 Raftにおける読み取り最適化
4.3.4 Learner
4.3.5 RaftとPaxosの違い
4.4 まとめ
第5章 NewSQLにおける分散トランザクション
5.1 トランザクション分離レベルの定義と一貫性アノマリー
5.1.1 古典的なトランザクション分離レベル
5.1.2 重要なのはREAD COMMITTEDとREPEATABLE READ
5.2 NewSQLのトランザクション分離レベルの特徴
5.2.1 READ COMMITTEDのサポート拡充
5.2.2 REPEATABLE READとSNAPSHOT ISOLATIONの違い
5.3 データの同時更新を防ぐための同時実行制御
5.3.1 悲観的同時実行制御と楽観的同時実行制御
5.3.2 悲観的同時実行制御 ――データ整合性を重視
5.3.3 楽観的同時実行制御 ――パフォーマンスを重視
5.4 分散トランザクション
5.4.1 分散トランザクションにおけるクロックスキュー
5.4.2 TrueTimeによる分散トランザクションの整合性担保
5.4.3 原子時計とGPSはNewSQLにとって必須なのか?
5.4.4 線形化可能性と直列化可能性の違い
5.4.5 タイムスタンプベースの同時実行制御
5.5 まとめ
第6章 NewSQLの標準SQLへの対応状況
6.1 主キー ――連番 vs ランダムな値
6.1.1 UUID ――分散データベースの主キー候補
6.1.2 ORMとNewSQLの相性の悪さ
6.1.3 UUIDの欠点
6.1.4 ハッシュ分散による主キーのランダム化
6.2 データ型
6.3 参照整合性制約 ――外部キー
6.4 結合 ――JOIN
6.4.1 内部結合
6.4.1 Spannerのインターリーブ機能
6.4.2 反結合と3値論理の落とし穴
6.5 条件分岐 ――CASE式
6.6 ウィンドウ関数 ――ループの代用
6.7 HAVING句 ――集合に対する条件
6.8 サブクエリ
6.9 ビュー
6.10 再帰共通表式
6.11 LIMIT句
6.12 集合演算
6.12.1 UNION
6.12.2 INTERSECT
6.12.3 EXCEPT
6.13 JSON
6.13.1 TiDBにおけるJSON
6.13.2 YugabyteDBにおけるJSON
6.13.3 CockroachDBにおけるJSON
6.13.4 SpannerにおけるJSON
6.13.5 DSQLにおけるJSON
6.13.6 GINインデックス
6.13.7 JSONに関するまとめ
6.14 インデックス
6.15 プロシージャとトリガー
6.16 ベクトル型
6.16.1 TiDBにおけるベクトル型
6.16.2 CockroachDBにおけるベクトル型
6.16.3 YugabyteDBにおけるベクトル型
6.16.4 Spannerにおけるベクトル型
6.16.5 DSQLにおけるベクトル型
6.17 まとめ
第7章 NewSQLのユースケース
7.1 スケーラブルRDBという夢の実現
7.1.1 Uber EatsのライバルDoorDashの超高速配送を支えるデータベース
7.1.2 インド最大のECサイトFlipkartの高負荷対応
7.1.3 世界最大の画像共有プラットフォームPinterestの挑戦
7.2 分散と統合の螺旋 ――マルチテナント
7.2.1 レバテックによるマイクロサービスの再統合
7.2.2 DMM.comによる異種混合データベースの統合
7.2.3 Atlassianによる300万個のテーブルのマイクロサービスアーキテクチャ
7.3 マルチクラウド・データベース
7.3.1 Form3によるマルチクラウド対応 ――クラウドネイティブデータベースとしてのNewSQL
7.3.2 もしAWSに障害が起きたらどうすればいい?
7.3.3 クラウドネイティブデータベースとしてのNewSQL
7.3.4 マルチクラウドに関する今後の展望
7.4 高可用性データベースとしてのNewSQL
7.4.1 みんなの銀行における高可用性マルチリージョン構成
7.4.2 LUSHのグローバル在庫管理 ――地理分散の応用
7.4.3 Netflixのグローバルサービスを支える「ゴキブリ」なみのしぶとさ
7.5 まとめ