【IT知識ゼロからOK】データベースの基本 ― 生成AI時代のアーキテクチャ超入門・基礎編

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ITの基礎知識」編・第3弾として、データベースの基本を解説する記事です。

基礎編の第1弾では、データベースを「レストランの倉庫」として紹介しました。今回はその倉庫の中身がどうなっているのか、もう一段だけ深掘りしていきます。と言っても難しい話はしません。「会員名簿と注文台帳をどう管理するか」という、商店の帳簿の話だと思って読んでもらえれば大丈夫です。

そもそもデータベースとは何か

データベースとは、ざっくり言えば「情報を整理して保管し、必要なときに素早く取り出せるようにした専用の保管庫」のことです。

Webサービスで扱う情報、例えば会員の名前や住所、商品の在庫数、注文の履歴といったものは、全てデータベースに保存されています。ブラウザを閉じても翌日また同じ情報が見られるのは、どこかのサーバーのデータベースにちゃんと記録が残っているからなのです。

第1弾でも触れましたが、「情報を表で管理するならExcelでも良いのでは？」という疑問は筋が良いと思います。実際、データベースの中身は表の集まりで、発想はかなり近いです。ただ、何千人・何万人が同時に読み書きするという条件が加わった瞬間に、Excelでは太刀打ち出来なくなります。データベースはこの条件のために作られた専用品、というのが出発点です。

情報は「表」に分けて管理する

では、倉庫の中がどうなっているのかを見ていきます。

現代のWebサービスで最も広く使われているデータベースは、情報を表（テーブル）の形で管理します。ここで面白いのは、全部の情報を1つの巨大な表に詰め込むのではなく、役割ごとに表を分けるという点です。

例えばネット通販であれば、「会員名簿」の表と「注文台帳」の表を別々に持ちます。

なぜ分けるのかというと、同じ情報を何度も書くと、修正のときに地獄を見るからです。もし注文台帳に毎回「佐藤さん・東京都…」と住所まで書いていたら、佐藤さんが引っ越したとき、過去の注文記録を全部探して書き換える必要が出てしまいます。名簿と台帳を分けて「会員ID」という番号で繋いでおけば、住所の修正は名簿の1箇所だけで済むわけです。

この「表を分けてIDで繋ぐ」という設計の考え方は、本編の「データモデリング」という記事で延々と論じられているテーマの、一番根っこの部分だったりします。

SQLは倉庫係への依頼書

分けて保管した情報を取り出すときには、SQL（エスキューエル）という専用の言葉を使います。

SQLというのは、ざっくり言えば「倉庫係への依頼書の書き方」です。「会員名簿から、東京都に住んでいる人を全員探して」「注文台帳に、この注文を1行追加して」といった依頼を、決まった書式で書きます。プログラム（キッチン）は、この依頼書をデータベース（倉庫）に渡して、返ってきた結果を使って料理を仕上げている、というイメージです。

本編でPostgreSQL（ポストグレスキューエル）やMySQL（マイエスキューエル）という名前が出てきますが、これらはSQLで依頼できるタイプのデータベース製品の名前です。倉庫会社のブランド名のようなものだと思ってもらえれば十分です。

「両方成功か、全部なかったことに」 ― トランザクション

データベースの仕組みの中で、私が一番面白いと思っているのがトランザクションという考え方です。

銀行の振込を考えてみてください。AさんからBさんへ1万円を振り込む処理は、実は「Aさんの残高を1万円減らす」と「Bさんの残高を1万円増やす」という2つの書き込みで出来ています。

ここでもし、Aさんの残高を減らした直後にサーバーが故障したらどうなるでしょうか？Bさんにはお金が届いていないのに、Aさんの残高だけ減っている・・・これは絶対に有ってはならない事故ですよね。

トランザクションは、こうした複数の書き込みを「全部成功するか、全部なかったことにするか」の二択にしてくれる仕組みです。途中で失敗したら、途中までの変更も自動で巻き戻されます。中途半端な状態が残らないことを保証してくれるわけです。

本編でACID（アシッド）という言葉が出てきたら、「この帳簿は中途半端な状態にならないことが保証されているんだな」と読み替えてください。お金や在庫を扱うサービスでは、この保証の有無が製品選びの生命線になります。

表以外の保管庫もある

ここまで説明してきた「表で管理するデータベース」は、正式にはリレーショナルデータベース（略してRDB）と呼ばれています。現代の主流はこのRDBなのですが、実は表以外の形で保管するタイプも有ります。

本編でNoSQL（ノーエスキューエル）という言葉が出てきますが、これは「表形式にこだわらない、それ以外の保管方式の総称」です。大量のデータを超高速でさばくことに特化したものなど、用途特化型の倉庫だと思ってください。ただ、本編でも繰り返し出てくる結論を先に言ってしまうと、大抵のサービスはまずRDBを選んでおけば間違い有りません。特化型の倉庫は、本当に必要になってから足すものです。

なぜ何万件あっても一瞬で探せるのか ― 索引という工夫

ところで、会員が100万人いる名簿から佐藤さんを探すとして、1行目から順番に見ていったら大変な時間がかかりますよね。それなのに、実際のWebサービスの検索は一瞬で終わります。これはコンピュータの性能が良いから・・・だけでは有りません。

種明かしをすると、データベースはインデックス（索引）という仕組みを持っています。分厚い辞書に五十音順の索引が付いているのと同じで、「この名前の会員はだいたいこの辺り」という案内を別に用意しておくのです。索引が有れば、100万件の中からでも数回の絞り込みで目的の行に辿り着けます。

逆に言うと、索引を付け忘れた項目での検索は、1行目から全部めくる総当たりの探し方になってしまいます。データが少ないうちは気付かないのですが、データが増えてくるとある日突然「検索が異常に遅い」という問題になって表面化します。本編で「インデックスを張る」「フルスキャンになっている」といった表現が出てきたら、「索引が有るか、総当たりになっているか」の話をしているのだと読み替えてください。

データベースのよくある勘違い

ここで、初心者の方が持ちやすい勘違いをいくつか整理しておきます。

まず「削除ボタンを押したらデータは消える」という感覚です。実際のサービスでは、データを本当に消してしまうことは意外と少なく、「削除済み」という印を付けて見えなくするだけ（論理削除と言います）の設計がよく使われます。誤操作からの復元やトラブル調査のためですね。加えて、倉庫全体の写し（バックアップ）も定期的に取られています。退会したサービスのデータがすぐには完全消去されないのは、こういう事情だったりします。

次に「データベースはサービスに1つ」という思い込みです。実際には、日々の営業用の帳簿（今回説明したRDB）とは別に、売上分析専用の倉庫や、よく使う情報だけ手元に置いておく棚（キャッシュと言います）を併用するのが普通です。営業中のレジ横で決算の集計作業をやると営業の邪魔になるので、分析は別室でやる、というイメージです。本編の「データ基盤」関連の記事は、まさにこの別室の作り方の話です。

そして「とにかく高性能なデータベースを選べば安心」という発想です。ここまで読んでいただいた方なら想像がつくと思いますが、実際の性能は表の分け方や索引の張り方といった設計の質で大きく決まります。どんなに立派な倉庫を借りても、棚の整理がぐちゃぐちゃなら探し物は遅いのです。

本編用語との対応表

今回の帳簿の例えと、本編で実際に使われる用語の対応を一覧にしておきます。

本編との繋がり

データベースの話は、本編では主に「データアーキテクチャ」カテゴリで扱われています。どの製品を選ぶか、表をどう設計するか、分析用の倉庫をどう分けるか、といった話が続きますが、今回の「帳簿の管理方法」の延長線上に有る話ばかりです。

概要 ― AI時代の前提となるデータ整備 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-data-overview/

この記事に関連する記事

まとめ

本記事はデータベースの基本について、会員名簿と注文台帳の例えで解説しました。如何だったでしょうか。

データベースは大勢が同時に読み書きしても壊れない専用の帳簿で、情報は役割ごとの表に分けてIDで繋ぐのが基本形です。そして、お金のように失敗が許されない処理は、トランザクションという「全部成功か、全部なかったことに」の仕組みで守られています。この3点が分かっていれば、本編のデータベース関連の話はかなり読みやすくなるはずです。

次回の基礎編では、キッチンの中身にあたる「プログラムとAPIの基本」を解説していく予定です。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。