![](https://uxmeetsdata.com/wp-content/uploads/2019/03/xmd_bq_sql.png)
RDBとNoSQL。
BigQueryの準備が整ったところで、ビッグデータ分析のためのSQLの実践を進めていきましょう。なお、BigQueryの準備は「BigQueryではじめるSQL #01」を参照してください。
とはいえ、データベース(Database:DB)やクエリ(Query)の基本概念を理解していないと、ただサンプルどおりにSQLを実行するだけになってしまうので、簡単におさらいしておきます。
蓄積や検索をしやすいように整理されたデータの集まりのことDBといい、蓄積や検索の指示を行うことをクエリといいます。また、単にDBというと関係データベース(Relational Database:RDB)のことをさします。RDBは、データを複数のテーブル(Table)として管理し、テーブル間の関係を定義することで、複雑なデータの関連性を扱えるようにしたもので、企業の基幹システムのような大規模なものから、個人のブログのような小規模なものまで、データ管理の領域で幅広く利用されています。
DBを管理するシステムのことをデータベース管理システム(Database Management System:DBMS)といいますが、とりわけRDBによるものをRDBMS(Relational Database Management System)といい、代表的なものにPostgreSQLなどがあります。GCP(Google Cloud Platform)ではCloud SQL、AWS(Amazon Web Services)ではAmazon RDSがそれにあたります。
一方でRDBは、データ構造が複雑化したり、データ量が膨大化すると、整合性の確保のために処理速度が遅くなるという問題を抱えています。そこでNoSQLという概念が登場しました。NoSQLは「Not only SQL」の略とされる、RDB以外のDBを示す大まかな分類であり、特定のデータ管理方式を示すものではありません。代表的な方式としてキーバリュー型があり、GCPではCloud Bigtable、AWSではAmazon DynamoDBがそれにあたります。
RDBとNoSQLは、どちらが優れているかということではなく、用途により使い分けることが重要です。NoSQLの登場前は、これらを考慮することなく無条件にRDBを採択していたことが問題であったわけで、RDBが劣るということではありません。RDBとNoSQLの比較表は以下のとおりで、ざっくり言うと、顧客ランクのような日々更新されるマスタデータの管理はRDB、購買履歴のような日々追加されるトランザクションデータの管理はNoSQLが、それぞれ得意領域としています。
RDB | NoSQL | |
データの整合性の確保 | 得意 | 苦手 |
登録済みデータの更新 | 得意 | 苦手 |
大量データの処理 | 苦手 | 得意 |
データの多様性への対応 | 苦手 | 得意 |
なお、Google BigQueryやAmazon Redshiftはカラムストア型と呼ばれ、RDBではないためにNoSQLに区分されますが、RDBと同じテーブルの概念を持ち、SQLによるデータ操作を可能としつつも、列指向にデータを蓄積することで処理速度を高速化させる方式となります。この列指向について詳しく見ていきます。
行指向と列指向。
テーブル型のDBには大きく、行指向DBと列指向DBの二つの方式があります。もともと行指向という概念や言葉は存在しませんでしたが、列指向の登場後、従来のRDBはそれと区別するために行指向と呼ばれるようになりました。
データの蓄積と検索を、行指向DBでは行単位、列指向DBでは列単位で行います。この方式の違いが、以下のような特徴の違いを生みます。
行指向 | 列指向 | |
データの蓄積単位 | 行 | 列 |
多数の列への検索 | 得意 | 苦手 |
多数の行への検索 | 苦手 | 得意 |
1行に対する処理速度 | 速い | 遅い |
1列に対する処理速度 | 遅い | 速い |
代表的なDB | Oracle Database, MySQL, PostgreSQL | Google BigQuery, Amazon Redshift |
つまり列指向DBは、大量データの特定の列に対する集計処理が得意であり、ビッグデータ分析に向いているといえます。一方で、1行に対する計算処理が苦手なため、1行をまるごと更新する処理(SQLでいうとUPDATE)は推奨されません。またデータの抽出を行う際も、すべての列を指定するような処理(SQLでいうとSELECT *)も非効率であるため避けるべきです。なお、BigQueryはクエリ課金(クエリ時のデータスキャン量による従量課金)であるため、コスト面においても指定する列を必要最小限に抑えることは重要です。
正規化と非正規化。
DBの基本概念でもうひとつ重要なのが、正規化と非正規化です。これをきちんと理解することで、用途に対して効率的なDBを設計することが可能となります。
正規化(Normalization)とはデータの重複を排除することであり、これによりデータの追加・更新・削除における処理の冗長化が抑制され、メンテナンスが効率化されます。この正規化を簡単に実現できるように考えられたのがRDBです。
正規化をするほど冗長化が抑制され、メンテナンス効率が上がる一方で、テーブルの分割によりデータ構造が複雑化し、処理速度が遅くなるという欠点があります。そこで、処理速度を重視する場合には、あえて非正規化(Denormalization)を行います。非正規化を前提として処理速度の高速化を追求したのがNoSQLであるともいえます。
正規化と非正規化の特徴を整理すると、このようになります。
正規化 | 非正規化 | |
データの重複 | なし | あり |
メンテナンス効率 | 効率的 | 非効率的 |
処理速度 | 遅い | 速い |
前提とするDB方式 | RDB | NoSQL |
この正規化と非正規化も、どちらが優れているかということではなく、用途に合わせて選択する、あるいは併用することが重要です。典型的な併用方法として、マスターとなるDBを正規化して管理し、メンテナンスを効率化させつつ、個別の分析用途に合わせて非正規化かつ高速化したDBを出力するという構造化手法がよく用いられます。その出力されたDBをデータマート(Data Mart)といいます。また、正規化と非正規化に用いられるSQLの構文がGROUP BY句とJOINk句で、SQLを利用したデータ分析の主役となります。
次回は検索の基本構文であるSELECT文と、集計と正規化の基本構文であるGROUP BY句を中心に見ていきましょう。
関連する記事
![Atsushi Sugawa](https://uxmeetsdata.com/wp-content/uploads/2019/07/xmd-prof-sugawa.png)
須川 敦史
UX&データスペシャリスト
クロスハック 代表 / uxmeetsdata.com 編集長