第10章 NoSQL・クラウドDBと次のステップ

10.1 NoSQLの4分類

NoSQL(Not only SQL)は「RDB以外のデータベース」の総称で、中身は一枚岩ではありません。大きく4つに分類され、それぞれRDBの何かを諦める代わりに、何かを得るという設計になっています。

たとえばRedisは「セッション情報やランキングを、ミリ秒以下で読み書きしたい」場面の定番です。JOINも集計もできませんが、そもそもそれが不要な用途に絞ることで速度を得ています。MongoDBは「項目が頻繁に増減するデータ」に強い一方、第6章で学んだ正規化やJOINの世界とは別の設計作法が必要になります。

10.2 使い分けの判断軸

では、どう選べばよいのでしょうか。実務でよく使われる判断軸を挙げます。

• お金や在庫のように、一瞬でも矛盾してはいけないデータ → RDB。第5章で学んだトランザクションと制約の出番です。
• 超高速に読み書きしたい一時データ(セッション、キャッシュ、ランキング)→ キーバリュー(Redis)。消えても再生成できるデータが向きます。
• 項目が頻繁に変わる・行ごとにバラバラ(商品ごとに属性が違うカタログ、ログ)→ ドキュメント(MongoDB)。
• 世界規模の書き込みをさばきたい → ワイドカラム(Cassandra)。ここまで来るのは大規模サービスだけです。
• 関係そのものが主役(SNSのつながり、不正取引の追跡)→ グラフ(Neo4j)。

背景にある理屈を一言だけ補うと、CAP定理という有名な定理があります。乱暴に要約すれば「多数のサーバーに分散したデータベースは、整合性(どこから読んでも同じ値)と可用性(いつでも応答)を、障害時に両立できない——どちらかを選ぶことになる」という話です。NoSQLの多く(特にワイドカラム)は、整合性を少し緩めることで可用性と拡張性を取りました。SNSの「いいね」の数が数秒ずれても誰も困りませんが、銀行残高がずれたら大事件です。データの性質が選択を決めます。

10.3 クラウドのマネージドデータベース

ここまで「自分でDBMSをインストールして動かす」前提で話してきましたが、実務の新規システムではクラウドのマネージドデータベースを使うことが多くなりました。代表格は次のとおりです。

「マネージド」の意味は、面倒で重要な運用作業をクラウド側が引き受けてくれることです。具体的には、DBMSへのセキュリティパッチ適用、自動バックアップ、ハードウェア故障時の切り替え(冗長化)、ストレージの拡張など——第9章で学んだ防御の一部を「買う」ことができるわけです。

ただし、すべてお任せにはなりません。クラウドには責任共有モデルという考え方があります。基盤側(ハードウェア、DBMS本体のパッチ)はクラウド事業者の責任、しかしその上の設定と使い方は利用者の責任です。具体的には——

• 公開設定 — DBをインターネットに公開するか、どのIPアドレスから接続を許すか
• 認証情報の管理 — アカウント・パスワード・接続文字列(第8章のseccolで学んだ内容)
• 権限設計 — 最小権限の原則(第9章)はマネージドでも丸ごと利用者の仕事
• 入れるデータの管理 — 何を保存し、誰に見せるか

「クラウドだから安全」でも「クラウドだから危険」でもなく、責任の境界線がどこにあるかを知って使うのがプロの態度です。

10.4 データベース運用の実務

データベースは「作って終わり」ではなく、動き続ける限り面倒を見る対象です。IT部門で働くうえで知っておくべき運用の柱を4つ挙げます。

① バックアップ設計

第9章の3-2-1ルールとリストア訓練が土台です。運用ではさらに「毎日何時に取るか」「何世代残すか」「何時間前まで戻れる必要があるか(目標復旧時点)」「復旧に何時間かけられるか(目標復旧時間)」を業務側と合意して文書化します。マネージドDBなら自動バックアップの保持期間と、削除保護の設定を確認します。

② 監視

障害は「気づいた時点の早さ」で被害が決まります。最低限の監視項目は次の3つです。

• 接続数 — 上限に達すると新しい接続が全部エラーになります。接続を閉じ忘れるバグ(第8章の close() 忘れ)の検出にもなります。
• 遅いクエリ — 「実行に1秒以上かかったSQL」を記録するスロークエリログを有効にし、定期的に眺めます。第7章のインデックスとEXPLAINの知識がそのまま武器になります。
• ディスク使用量 — DBはデータが増える一方の装置です。満杯になると書き込みが止まり、最悪DBが壊れます。「残り20%で警告」のようなしきい値を設けます。

③ バージョンアップ計画

DBMSにもサポート期限があります。期限切れのバージョンはセキュリティパッチが出なくなるため、「動いているから触らない」は徐々に危険になっていきます。年に一度はバージョンと期限を棚卸しし、検証環境でテストしてから上げる——地味ですが重要な仕事です。マネージドDBでは古いバージョンが強制アップグレードされることもあるため、放置はどのみちできません。

④ キャパシティ計画

データ量とアクセス数の増加傾向を記録し、「このペースなら1年後にディスクが足りない」「接続数の上限に近づいている」を先回りして手当てします。監視データを月次で眺めるだけでも、突然の「もう限界です」を防げます。

10.5 学習ロードマップ — この先へ

このコースで、あなたはSQLの読み書き(第3〜5章)、テーブル設計(第6章)、性能(第7章)、Python連携(第8章)、セキュリティ(第9章)まで、データベースの背骨を一通り手に入れました。次の一歩の候補を挙げます。

次に触るべきもの

• PostgreSQLをDockerで動かす — SQLiteで学んだSQLがどこまで通じるか(そして権限管理など、SQLiteになかった世界がどう見えるか)を体験する最短ルートです。docker run 1行で起動でき、壊しても捨てて作り直せます。

# PostgreSQLをDockerで起動して接続してみる(パスワードは環境変数で渡す例)
$ docker run --name pg-study -e POSTGRES_PASSWORD=$PG_PASS -d -p 5432:5432 postgres:16
$ docker exec -it pg-study psql -U postgres
postgres=# CREATE TABLE hello (id INTEGER, message TEXT);
CREATE TABLE
postgres=# SELECT version();
 PostgreSQL 16.3 ...

第1章の sqlite3 practice.db と見比べてください。プロンプトこそ違いますが、打っているSQLは同じです——あなたの学びは製品をまたいで通用します。

• 実データで集計練習 — 政府統計や公開データセットのCSVを第8章の方法で取り込み、GROUP BYとJOINで「問い」に答える練習をしてください。SQLは自分の問いを持ったときに一番伸びます。
• Webアプリ開発へ — FlaskのようなWebフレームワーク+SQLiteで小さなアプリ(第8章の問い合わせ管理のWeb版など)を作り、育ったらPostgreSQLに載せ替える。データベースが「Webアプリの記憶装置」として働く全体像がつかめます。

資格でマイルストーンを作る

セキュリティに軸足を置きたい人は、セキュリティ中級・上級コースへ進んでWAFやログ分析を深掘りするのも良い流れです。第9章で学んだDBの防御が、より大きな防御体系の一部として見えてくるはずです。

最後にひとつだけ。データベースの学習で最も大切なのは、道具の名前を増やすことではなく、「このデータは誰のもので、どう持つのが正しいか」を考える習慣です。それは第1章の「Excelの4つの壁」から今日まで、一貫して問い続けてきたことでもあります。おつかれさまでした——ここから先は、実データと実務があなたの教科書です。

まとめ

• NoSQLはキーバリュー(Redis)・ドキュメント(MongoDB)・ワイドカラム(Cassandra)・グラフ(Neo4j)の4分類。いずれも「RDBの何かを諦めて何かを得る」特化型
• 使い分けの定石は「まずRDB、測定に基づく明確な理由があればNoSQLを併用」。整合性が命のデータはRDB、消えてよい高速データはKVS
• クラウドのマネージドDB(RDS/Aurora・Cloud SQL・Azure SQL Database)はパッチ・バックアップ・冗長化を肩代わりするが、責任共有モデルにより公開設定・認証情報・権限設計は利用者の責任
• クラウドDBの公開設定ミスは漏えいの頻出原因。デフォルト拒否・接続元IP制限・認証必須の三原則を守る
• 運用の柱はバックアップ設計・監視(接続数/遅いクエリ/ディスク)・バージョンアップ計画・キャパシティ計画
• 次の一歩はDockerでPostgreSQL、実データでの集計練習、Flask+SQLiteでのWebアプリ。資格は基本情報→OSS-DB Silver→データベーススペシャリストの順が目安

練習問題