目次
はじめに
今回も、応用情報技術者試験の過去問を解いていきます。
今回のテーマは、ビッグデータの基盤技術として利用されるNoSQLデータベースです。
IoTやSNS、Webサービスなどの発展によって、現在では大量かつ多様なデータが生成されています。
また、大規模なWebサービスでは、大量のアクセスに対応したり、多数のサーバーへデータを分散して処理したりする必要もあります。
こうした要求に対応するため、従来のリレーショナルデータベース（RDB）とは異なる特徴を持つNoSQLデータベースが広く利用されるようになりました。
今回は、NoSQLとは何なのかも含めて問題を見ていきます。
問題
ビッグデータの基盤技術として利用されるNoSQLに分類されるデータベースはどれか。
| 選択肢 | 内容 |
|---|---|
| ア | 関係データモデルをオブジェクト指向データモデルに拡張し，操作の定義や型の継承関係の定義を可能にしたデータベース |
| イ | 経営者の意思決定を支援するために，ある主題に基づくデータを現在の情報とともに過去の情報も蓄積したデータベース |
| ウ | 様々な形式のデータを一つのキーに対応付けて管理するキーバリュー型データベース |
| エ | データ項目の名称，形式など，データそのものの特性を表すメタ情報を管理するデータベース |
解答
正解は「ウ」です。
様々な形式のデータを一つのキーに対応付けて管理するキーバリュー型データベースは、NoSQLの代表的なデータモデルの一つです。
解説
NoSQLとは、従来のRDBとは異なるデータモデルや設計思想を採用する、主に非リレーショナルなデータベース技術群の総称です。
代表的なものとして、
- キーバリュー型
- ドキュメント型
- カラムファミリー型
- グラフ型
などがあります。
今回の問題で登場しているのは、この中のキーバリュー型です。
基本的な構造は非常にシンプルです。
Key → Value例えば、
user001 → ユーザーAの情報
user002 → ユーザーBの情報
product001 → 商品Aの情報というように、KeyとValueを対応付けてデータを管理します。
したがって、選択肢ウが正解です。
NoSQLはなぜ広まったのでしょうか
ここで少し背景を見てみます。
以前から企業システムでは、RDBが広く利用されてきました。
例えば顧客情報なら、次のような表を作ります。
| 顧客ID | 氏名 | 年齢 | 住所 |
| 001 | 田中 | 30 | 東京 |
| 002 | 佐藤 | 40 | 大阪 |
注文情報を別のテーブルにすれば、
| 注文ID | 顧客ID | 商品 |
| A001 | 001 | パソコン |
| A002 | 001 | マウス |
| A003 | 002 | キーボード |
顧客IDを利用して顧客と注文を関連付けることができます。
顧客テーブル
田中（001）
│
├── パソコン
└── マウス
佐藤（002）
│
└── キーボードRDBは、このようにデータを表形式で整理し、SQLによって検索したり、複数のテーブルをJOINしたりすることを得意としています。
ところが、インターネットサービスが巨大化すると状況が変わってきます。
従来
販売データ
顧客データ
在庫データ
↓
RDB
Webサービスの巨大化
SNS投稿 ────── ┐
画像 ─────────┤
動画 ─────────┤
アクセスログ ── ┤
位置情報 ────── ┤
IoTデータ ───── ┤
↓
大量・多様なデータデータ量だけでなく、世界中からの大量アクセスにも対応しなければならなくなりました。
そこで重要になってきたのが、複数のサーバーを利用して処理能力を拡張する「スケールアウト」という考え方です。
1台のサーバーを強化する
↓
┌────────┐
│ DB │
└────────┘
だけではなく
複数サーバーに分散する
┌────┐ ┌────┐ ┌────┐
│ DB │ │ DB │ │ DB │
└────┘ └────┘ └────┘こうした大規模な分散環境で利用しやすいデータストアが発展していきました。
代表的な流れとして、Googleは2006年にBigtable、Amazonは2007年にDynamoについて論文を発表しています。
その後、2000年代後半には、RDBとは異なるデータモデルを持つさまざまなデータベースがNoSQLとして広く注目されるようになりました。
流れを簡単にまとめると次のようになります。
Webサービスが巨大化
↓
大量のデータ
＋
大量アクセス
＋
多様なデータ
↓
複数サーバーに
分散して処理したい
↓
RDBとは異なる特徴を持つ
データベースも利用される
↓
NoSQLただし、
「RDBが古くなったのでNoSQLに置き換わった」
という意味ではありません。
RDBとNoSQLは現在でも用途に応じて使い分けられています。
RDBとNoSQLの違い
両者を大まかに比較すると次のようになります。
| 項目 | RDB | NoSQL |
| 主なデータモデル | 表（行・列） | Key-Value、文書、グラフなど |
| スキーマ | 明示的に定義するのが基本 | 柔軟なものが多い |
| JOIN | 標準的に利用できます | JOINを前提としない製品も多いです |
| トランザクション | 強力な機能を持つ製品が多いです | 製品によって異なります |
| 水平分散 | 対応可能です | 水平分散を重視した製品が多いです |
| 得意な用途 | 複雑な検索、関係性、取引処理など | 大規模分散、特定のアクセスパターンなど |
NoSQLだから必ずRDBより速い、あるいはRDBだから必ずNoSQLより整合性が高い、と単純に分けられるものではありません。
製品や設計によって特徴は異なります。
重要なのは、
「RDBとNoSQLにはそれぞれ得意な用途がある」
ということです。
RDBにも「キー」があるのに何が違うのか
キーバリュー型という名前を見ると、一つ疑問があります。
RDBにも、
- 主キー
- 外部キー
があります。
では、RDBのキーとキーバリュー型のKeyは何が違うのでしょうか。
RDBの場合、主キーはテーブルの行を一意に識別するために使用します。
また、外部キーによって別のテーブルとの関係を表すこともできます。
【顧客テーブル】
顧客ID
001 田中
↑
│
│ 関連付け
│
↓
【注文テーブル】
注文ID 顧客ID
A001 001
A002 001つまりRDBでは、
テーブルという基本構造があり、その中でキーを利用しています。
一方、キーバリュー型では、
Key → Valueという対応そのものがデータモデルの基本です。
user001 → 田中さんのデータ
user002 → 佐藤さんのデータ
user003 → 鈴木さんのデータ例えば、
user001というKeyを指定すると、
{
名前：田中,
年齢：30,
住所：東京
}というValueを取得する、といった使い方をします。
つまり、
「NoSQLではキーを使う」ことが特徴なのではありません。
RDBにもキーは存在します。
キーバリュー型の特徴は、
「KeyとValueの対応そのものが基本的なデータ構造になっている」
という点です。
キーバリュー型はロッカーで考えると分かりやすいです
キーバリュー型は、巨大なロッカーをイメージすると分かりやすいです。
┌────────────────┐
│ user001 │ → 田中さんのデータ
├────────────────┤
│ user002 │ → 佐藤さんのデータ
├────────────────┤
│ product001 │ → 商品データ
├────────────────┤
│ session12345 │ → セッション情報
└────────────────┘ロッカー番号がKey。
ロッカーの中身がValueです。
欲しいデータのKeyが分かっていれば、
user001
↓
データベース
↓
田中さんのデータという形でデータを取得できます。
このような単純なアクセスパターンによって、高速な読み書きを実現しやすく、水平分割やスケールアウトを重視した製品も多く存在します。
各選択肢の解説
ア：オブジェクト指向データベース
関係データモデルをオブジェクト指向データモデルに拡張し、操作の定義や型の継承関係の定義を可能にしたデータベース
これはオブジェクト指向データベース（OODB）について説明しています。
オブジェクト指向プログラミングで利用される、
- オブジェクト
- クラス
- 継承
などの概念を利用してデータを扱います。
クラス
│
├─ 属性
└─ 操作
│
↓
継承今回問われているキーバリュー型NoSQLではないため、不正解です。
イ：データウェアハウス（DWH）
経営者の意思決定を支援するために、ある主題に基づくデータを現在の情報とともに過去の情報も蓄積したデータベース
これはデータウェアハウス（DWH）の説明です。
データウェアハウスは、様々な業務システムからデータを集め、分析や意思決定に活用するためのデータ基盤です。
販売システム ─┐
在庫システム ─┤
顧客システム ─┤
↓
データウェアハウス
↓
分析・BI
↓
意思決定特徴を整理すると次のようになります。
| 項目 | 内容 |
| 目的 | 分析・意思決定支援 |
| データ | 現在および過去のデータを蓄積 |
| 用途 | BI、集計、分析など |
問題文の、
「意思決定を支援」
「過去の情報も蓄積」
が見分けるポイントです。
NoSQLの説明ではないため、不正解です。
ウ：キーバリュー型データベース【正解】
様々な形式のデータを一つのキーに対応付けて管理するキーバリュー型データベース
これはキーバリュー型NoSQLデータベースの説明です。
基本構造は、
Key → Valueです。
例えば、
| Key | Value |
| user001 | ユーザー情報 |
| user002 | ユーザー情報 |
| product001 | 商品情報 |
というようにデータを管理します。
代表的な製品・サービスとして、
- Redis
- Amazon DynamoDB
などがあります。
キーバリュー型は、キーによる単純な読み書きを高速に処理しやすく、大規模なデータや大量アクセスを扱う用途でも利用されています。
したがって、ウが正解です。
エ：データディクショナリ・リポジトリ
データ項目の名称、形式など、データそのものの特性を表すメタ情報を管理するデータベース
これはメタデータを管理する仕組みについて説明しています。
メタデータとは、
「データについてのデータ」
です。
例えば次のようなものがあります。
| データ項目 | メタデータの例 |
| 氏名 | 文字列 |
| 年齢 | 数値 |
| 登録日 | 日付型 |
例えば、
データ：顧客情報
そのデータについての情報
・項目名
・データ型
・桁数
・意味
・格納場所といった情報がメタデータです。
こうしたメタデータを管理する仕組みとして、データディクショナリやリポジトリがあります。
NoSQLの説明ではないため、不正解です。
問題の用語解説
NoSQL
NoSQLとは、RDBとは異なるデータモデルや設計思想を採用する、主に非リレーショナルなデータベース技術群の総称です。
代表的な種類には次のものがあります。
| 種類 | 特徴 |
| キーバリュー型 | KeyとValueのペアで管理 |
| ドキュメント型 | JSONなどの文書単位で管理 |
| カラムファミリー型 | 行キーと列の集合などを利用して柔軟に管理 |
| グラフ型 | ノードとエッジによってデータ同士の関係を表現 |
キーバリュー型
KeyとValueの組み合わせでデータを管理する方式です。
Key → Valueという非常にシンプルな構造が基本です。
ドキュメント型
JSONなどに代表される、文書形式のデータを単位として管理します。
例えば、
{
"name": "田中",
"age": 30,
"address": "東京"
}といったデータを一つのドキュメントとして扱います。
カラムファミリー型
行キーと列の集合などを利用してデータを管理する方式です。
「列単位で保存するデータベース」とだけ覚えると、分析系の列指向データベースと混同しやすいため注意が必要です。
グラフ型
データをノード、データ同士の関係をエッジとして表現するデータベースです。
田中
│
│ 友人
↓
佐藤
│
│ 勤務先
↓
会社ASNSの人間関係など、データ同士のつながりを扱う処理に向いています。
体系的位置づけ
今回の問題をデータベース分野の中で整理すると、次のようになります。
データベース
│
├─ RDB
│ │
│ ├─ テーブル
│ ├─ 主キー
│ ├─ 外部キー
│ ├─ SQL
│ └─ JOIN
│
└─ NoSQL
│
├─ キーバリュー型 ← 今回
├─ ドキュメント型
├─ カラムファミリー型
└─ グラフ型さらにNoSQLが広まった背景まで含めると、
RDBが広く利用される
↓
Webサービスが巨大化
↓
大量データ
大量アクセス
データの多様化
↓
分散処理・スケールアウトの
必要性が高まる
↓
RDBとは異なる特徴を持つ
データベースも広く利用される
↓
NoSQL
↓
その代表的な方式の一つ
↓
キーバリュー型という流れになります。
今回の問題の重要ポイント
今回、押さえておきたいポイントは3つあります。
1．NoSQLはRDBの後継ではない
NoSQLが登場したからといって、RDBが不要になったわけではありません。
RDBとNoSQLにはそれぞれ得意な用途があり、現在でも用途に応じて使い分けられています。
2．キーバリュー型は「Key → Value」が基本
キーバリュー型では、
Key → Valueという対応そのものが基本的なデータ構造です。
一方、RDBではテーブルが基本構造であり、主キーや外部キーは行を識別したりテーブル同士を関連付けたりするために利用します。
同じ「キー」という言葉が出てきますが、データモデルの中での役割が異なります。
3．「ビッグデータ」という言葉だけでNoSQLと判断しないようにする
ビッグデータに関連する技術には、NoSQL以外にも様々なものがあります。
そのため、
「ビッグデータだからNoSQL」
と判断するのではなく、
今回の問題であれば、
「一つのキーに対応付けて管理する」
という表現から、
Key → Value
↓
キーバリュー型
↓
NoSQLと判断することが重要です。
まとめ
今回の問題では、NoSQLに分類されるデータベースが問われました。
正解は、
ウ：キーバリュー型データベース
です。
キーバリュー型では、
Key → Valueというシンプルな構造でデータを管理します。
ここで注意したいのは、
「NoSQLだからキーを使う」わけではない
ということです。
RDBにも主キーや外部キーがあります。
違いは、
RDB
テーブルが基本
↓
キーを使って
行を識別したり
表同士を関連付けたりする
キーバリュー型
Key → Value
↑
この対応そのものが
基本的なデータ構造という点です。
また、NoSQLについては、
Webサービスの巨大化
↓
大量データ・大量アクセス
↓
分散処理やスケールアウトの
重要性が高まる
↓
RDBとは異なる特徴を持つ
データベースも利用される
↓
NoSQLという背景まで理解しておくと、単なる用語暗記よりも記憶に残りやすくなります。
今回の問題では、
「一つのキーに対応付けて管理」→「キーバリュー型」→「NoSQL」
という流れを押さえておきたいです。
コメント