爆速アプリを支えるDBの正体

動画配信サービスを会計システムで作ったらどうなる？

「毎日使っている動画配信サービスや巨大なネット通販サイトが、会社の経理部門が使う会計システムとまったく同じ仕組みで動いていたら、どうなると思いますか？」。動画はこの問いかけから始まります。聞き手の答えは、検索ボタンを押した瞬間に画面が固まって、結果が返るまで何時間も待たされるか、システム全体がダウンする、というものでした。

一瞬で欲しい情報が出てくるのは、裏側で目的の違う「データの保管庫」、つまりデータベース（DB）がオーケストラのように連携しているからです。ITの歴史は、爆発的に増え続けるデータをいかに効率よく処理するかという「格闘の歴史」でもある、と動画は言います。流れは、データの3分類、RDB、そしてNoSQLの6つのモデルです。

データは「構造」で3つに分けられる

種類	動画の説明	例
構造化	事前に定めた構造に整形されたデータ	顧客リスト
半構造化	最初に構造の定義が不要なデータ	動画に例はなし（資料ではXML・JSONなど）
非構造化	音声や動画のように表に収まらないデータ	監視カメラの映像

構造化データは、「この箱には名前だけ、あの箱には日付だけ」と、あらかじめ厳格なルールを決めてからデータを流し込むイメージです。ITの歴史で最も古く、今もビジネスの根幹を支えている、と動画は言います。

（補足：動画の訂正です。動画は半構造化データを「NoSQLのように最初に構造の定義が不要なデータ」と言い、NoSQLとほぼ同じものとして扱っています。しかし資料では別の概念です。半構造化データはXMLやJSONのように、表の構造には従わないものの、タグなどでデータ自身が構造の目印をもつデータ（Wikipedia「半構造化データ」）、NoSQLはRDBMS以外のDBMSをおおまかに指す分類語です（同「NoSQL」）。つまり前者はデータの性質、後者はDBの分類です。ITパスポート・シラバス Ver.6.5には、構造化データ・非構造化データが載っています。）

RDB：表で管理する、基幹システムの王道

RDB（リレーショナルデータベース）は、動画によれば、企業の屋台骨である基幹系ソフトウェアや、1円の狂いも許されない会計系などに使われるDBです。Excelのように行と列で表され、行をロー、列をカラムと呼びます。欲しい情報を取り出す基本操作は次の3つです。

• 射影：列を抽出する。例：メールアドレスの列だけを切り出す。
• 選択：行を抽出する。例：東京都に住む20代の行だけを拾う。
• 結合：共通の列の内容にしたがって表をつなぐ。顧客IDが共通の顧客表と売上表を噛み合わせる。

動画は、結合を最も重要な操作とし、「リレーショナル（関係性）」という名前の由来でもあると言います。結合があるから、データに矛盾を生じさせずに複数の表を連携できる、という説明です。

（補足：図は筆者の設例で、Pythonで確かめました。IPAの基本情報・応用情報シラバスには「関係演算（選択，射影，結合，商，直積）」という用語が並びますが、定義文は載っていません。）

RDBの壁：融通が利かず、結合が重くなる

もう一つは結合です。データが数千万、数億に膨れ上がると、表同士の結合に膨大な時間がかかります。冒頭の「会計システムで動画配信を作るとフリーズする」のは、億単位のユーザー履歴を結合しようとして悲鳴を上げるから、という説明でした。

（補足：「大工事」「悲鳴」は動画の強い言い方です。実際の負荷は表の設計や使い方にも左右されるはずなので、「構造の変更や超大量データの結合には向かない場面がある」という趣旨で受け取るのが無難です。一次資料では確認していません。）

NoSQL：RDB以外をまとめた呼び名

そこで、表に収まらないデータのために生まれたのがNoSQLです。最初に構造の定義が不要で、柔軟性を優先したDBだと動画は説明します。名前は「Not only SQL」、つまり「SQLだけではない」。SQLはRDBを操作する言語ですが、それだけではない、というニュアンスです。動画は、RDB以外のDB管理システム全般を指す用語で、ビッグデータやeビジネスなど、RDBで扱いにくいデータに対応するための技術だと強調します。代表的なモデルは次の6つです。

（補足：動画は6つすべてをNoSQLとして並べていますが、資料の並べ方は少し違います。IPAの応用情報シラバス Ver.7.2のNoSQLの用語例は Cassandra・CouchDB・MongoDB・Redis・Neo4j で、おおむね列指向・ドキュメント指向・キーバリュー・グラフ指向に当たります（Wikipedia「NoSQL」）。オブジェクト指向DBとインメモリDBは、RDBやXMLデータベースなどと並ぶ「データベースの種類」として載っており、NoSQLに含めるかは資料により異なります。）

ドキュメント指向DB：白紙のノートの束

ドキュメント指向DBは、1つのデータを「ドキュメント」と呼び、個々のドキュメントの中にXMLなどの形式で自由にデータを保存できるDBです。Aさんには名前と住所、Bさんには名前と趣味と最近買ったもの、というように、項目がバラバラでも同じ場所に放り込めます。

だから開発の途中で項目を追加したくなっても、システムを止めずに新しい形式のドキュメントを足すだけで済みます。Webサービスが新機能を次々にリリースできる裏には、この柔軟さがある、と動画は言います。

列指向DB：必要な列だけを読む

聞き手が「RDBにもカラムがありましたよね」と指摘します。講師は、RDBも列は持つが、データは基本的に行単位でディスクに書き込まれると答えます。顧客のID・名前・年齢・住所という1件分が一まとまりなので、全員の平均年齢を出すには、関係のない名前や住所まで読み込んでから年齢だけを取り出すことになり、数億件では致命的なタイムロスです。

列指向DB（カラムナ）は、大量データの集計など、列を単位とする処理が効率的になるよう設計されたDBです。年齢の列だけをまとめて別の場所に保存しておくので、平均年齢は年齢の塊を一気に読めば済みます。講師は、数億件のデータから傾向を見つけるビッグデータの解析などに用いられると説明します。聞き手は、「過去10年分の特定商品の売上推移をすぐ出せ」という経営会議の無茶ぶりにすぐ応えられるのはこのおかげだと受けます。

設例です（筆者の設例で、Pythonで検算しました）。顧客1億件、1件分をID 8・名前 40・年齢 4・住所 80の計132バイトとすると、行単位では平均年齢のために約13.2GB、年齢の列だけなら約0.4GBで、読む量は33分の1です。圧縮・索引・キャッシュは無視した単純な数字です。

（補足：行か列かは保存の仕方の話で、NoSQL専用ではありません。行指向は業務処理（OLTP）、列指向は分析処理（OLAP）で多く使われ、BigQuery・Amazon Redshift・Snowflake は列指向の形式を使います（Wikipedia「Data orientation」）。Oracle Database の In-Memory 列ストアのように、関係DBが列形式を使う例もあります。）

キーバリューストア：出し入れに全振りしたスペシャリスト

キーバリューストアは、1つのキーに1つの値を結びつけるだけの、非常にシンプルなDBです。シンプルだから高速に動作させられます。

そこで、Aさんの現在のセッションIDをキー、カートの中身を値にして、組み合わせだけを保存します。

構造が極限までシンプルなので、サーバーを何千台と並べて分散処理しても速度を保てます。聞き手は「複雑なことができるのが常に正義ではないんですね」と感想を述べています。

グラフ指向DB：つながりそのものを保存する

ここでの「グラフ」は折れ線グラフではなく、点と線でつながれたネットワークです。グラフ指向DBは、データの構造が表ではなくネットワーク状になっているDBで、データ自体が最初から蜘蛛の巣のようにつながっているイメージです。

動画の例はSNSです。AさんはBさんと友達で、Bさんはある映画が好き、というつながりをRDBの結合でたどろうとすると、計算量が爆発してパンクする、と動画は言います。グラフ指向DBなら、Aさんの点から線をなぞるだけで、友達が好きな映画を一瞬で見つけられます。「あなたへのおすすめ」や「知り合いかも」向きです。

（補足：IPAのシラバスにも、データモデルの用語例として「グラフ型のデータモデル（プロパティグラフ，トリプルストア）」が載っています。）

オブジェクト指向DB：データと操作をセットで持つ

動画の説明では、オブジェクト指向DBは、関係データモデルをオブジェクト指向データモデルに拡張し、操作の定義や型の継承関係の定義を可能としたDBです。オブジェクト指向とは、データと手続きを1つのまとまり（オブジェクト）と考えて組み合わせ、システムを構築する考え方だと動画は言います。

通常はデータを保存するだけで、処理はプログラム側が毎回考えます。オブジェクト指向DBは、データ自身に「自分をどう扱うか」という操作の定義をくっつけて保存します。図形のデータなら、自分の面積を計算する方法も一緒にカプセル化して入れておくのです。

（補足：定義の文面は資料により異なります。Wikipedia（日本語版）は、オブジェクトデータベースをオブジェクトの形のまま格納するDBとし、関係DBにカプセル化や継承を足したものは「オブジェクト関係データベース」と区別しており、動画の言い方はこちらに近いとも読めます。この定義文の出典は確認できませんでした。）

インメモリDB：資料を作業デスクの上に広げっぱなし

インメモリDBは、データをすべてメインメモリ上に格納する方式のDBです。ディスクにアクセスしないので、応答時間を短くできます。

ただしスペースには限界があり、コストも高く、電源を切ると消える性質（揮発性）への対策も要る、と聞き手は心配します。動画もそれを認めたうえで、近年のメモリの進化で実用的になり、ミリ秒単位の遅れが命取りになる金融のリアルタイム取引などで不可欠だと言います。

（補足：インメモリは「データを置く場所」の分類なので、関係DBにも例があります（Oracle Database In-Memory）。揮発性への対策には、スナップショット、トランザクションログ、不揮発性メモリ、レプリケーションなどがあります（Wikipedia「インメモリデータベース」）。なお、Redisの「RDB」はスナップショット形式の名前で、リレーショナルDBのRDBとは別物です。）

画面の向こう側で起きていること

動画の締めくくりは、アプリを開く場面の想像です。検索に文字を打つと、キーバリューストアがセッションをつなぎ止め、グラフ指向DBがおすすめを一瞬で導き、行動はビッグデータとして列指向DBに吸い込まれる。裏側の基幹システムでは、RDBが1円の狂いもなく売上を刻んでいるかもしれません。

まとめ