RDB vs NoSQL vsNewSQL
まとめ
- データベースシステムは大きくRDB，NoSQL，NewSQLがある（2025/4現在）
- データベースの性能や特徴を表す指標として，ACID特性，CAP定理，スケーラビリティがある．
- データベースシステムは，計算機の性能向上・低価格化・クラウド化などの歴史に伴って変化している
前提知識
RDB
Relational Database．複数の表形式のテーブルからなるDB．SQL言語でクエリを記述し，データを取得する．ACID特性が保証されており，ACIDに対するDBMSの責務が大きい．一方，デメリットはスケーラビリティが低いこと． MySQL,PostgreSQL etc...
NoSQL
Not Only SQL．key-value型/KVS（Redis，DynamoDB），ドキュメント型（MongoDB，Google Firestore）など． エントリやドキュメント（JSON風の構造化データ）単位で，それぞれは互いに独立しているので，シャーディングが簡単．従ってスケールアウトしやすい．一方で，ACID特性が保証されない（複雑なトランザクションは諦めるか，アプリケーション側のロジックで限定的に対応）
NewSQL
RDBのACID特性を維持しつつも，水平スケーラビリティを高め，分散システムでの運用を便利にしたデータベースシステム． テーブルを分割して各マシンに置く（シャーディング）．ACID特性などは，数学的・アルゴリズム的な呪術（Raftなど）によって保証されている．
Google Spanner，TiDB，CockroachDBなど．
トランザクション
CRUD処理（DB操作の最小単位）を組み合わせた意味のある処理の単位．トランザクションの完了はコミット，失敗した場合は元にトランザクションの開始前にロールバックされる．
ACID特性
- Atomicity（原子性）：トランザクションは０（失敗）か１（成功）のどちらか．中途半端な状態はない
- Consistency（一貫性）：データが一貫して正当な状態であること
- Isolation（独立性）：複数のトランザクションが独立して実行されること．
- Durability（永続性）：トランザクションがコミットされた時点で，その結果は永続しなくてはならない．
CAP定理
www.ibm.com 分散システムにおけるデータの持つべき特性．
- Consistency（一貫性）：どのノードへアクセスしても同じデータが返ってくること
- Availability（可用性）：あるノードの障害によって，別のノードの機能性が損なわれず，応答を返してくれる．（単一障害点となるノードが無い，全体としては常に稼働している）
- Partition tolerance（分断耐性）：ネットワークの一部が切断されても，稼働し続ける
上記の３項目のうち，同時に満たせるのは２つまでであるという定理．データベースシステムのトレードオフ性．
スケールアウト
データベースサーバの数を増やすスケーリング．データベース，特にRDBのスケールアウトは，複数サーバー間でACID特性を満足する必要があり難しい．（そもそも，RDBは単一サーバでの稼働を前提に考えられている） 一方，NoSQLはシャーディングが簡単なので，スケールアウトしやすい （スケールアップ：マシン自体の性能を高めるスケーリング）
シャーディング
データベースの水平分割．
RDB vs NoSQL vs NewSQL
- トランザクション，複雑なDB処理などに対するデータの整合性が重要，ACIDが重要→RDB
- データ構造やクエリ自体はそこまで複雑にならないが，拡張性，柔軟性が欲しい→ NoSQL
- RDBのACID特性＋NoSQLの拡張性・柔軟性が両方欲しい→NewSQL（ただし，技術的な要求は高い）
という結論になりそう
終わりに
データベースシステムの変遷には以下のような歴史があるみたい
- 初期：データベースシステムとしてのRDB．高性能な一つのマシンをDBサーバとして使用するのが最良．
- 中期：マシンの低価格，高スペック化．OSSの成熟，クラウドコンピューティングの普及などにより，廉価な複数のマシンによる水平スケーリングが台頭
- 最近：水平スケーラビリティの高く，柔軟性，変更性の高いNoSQLは，移り変わりや成長の激しいtoCサービス（SNS）などに最良の選択．また，NewSQLなど，スケーラビリティとACIDの両立を目指す技術も出てくる．
