データベース (DB)¶
データベースとは、何かの目的の目的のために一定の規則に従ってデータを集め編成したもの。例えば名刺を集めて机の上に山盛りにしてあるだけではデータベースと呼ばないけれど、会社別に振り分けて、あいうえお順に並べ替えると立派なデータベースになる。
例えば、個人情報保護法ではデータベースを以下のように定義している。
平成十五年法律第五十七号 個人情報の保護に関する法律 第2条第4項
この法律において「個人情報データベース等」とは、個人情報を含む情報の集合物であって、次に掲げるもの（利用方法からみて個人の権利利益を害するおそれが少ないものとして政令で定めるものを除く。）をいう。
一 特定の個人情報を電子計算機を用いて検索することができるように体系的に構成したもの
二 前号に掲げるもののほか、特定の個人情報を容易に検索することができるように体系的に構成したものとして政令で定めるもの
データベースマネジメントシステム (DBMS)¶
データベースを作成するとして、収録されているデータの量が増えると維持管理は結構大変である。例えば、あいうえお順に並べ替えるとか、データを適切な位置に追加するとか、適切なデータを探し出すとか。CDや本をレコード店や本屋さんで探すときはそれなりに時間がかかるし、店員さんはしょっちゅう本を整理し無ければすぐにごちゃごちゃになってしまう。
こういったデータベースに関する煩雑な操作を主にコンピュータを使ってできるようにしたものがデータベース管理システム（DBMS）だ。
DB と DBMS は本来別のものだが、現在では DB というと Oracle や MySQL などのDBMS 製品を指すことが多いので注意が必要だ。
CRUD 操作¶
DBMS でのデータ操作は、CRUD としてまとめられている。Create(作成)、Read(読み出し)、Update(更新)、Delete(削除)の頭文字をとったものだ。
DBMS以前¶
DBMS以前にもコンピュータは記録や計算が得意なので、データをコンピュータで管理することは行われていた。ただ現在のように便利なミドルウェア製品がなかったころは、例えばファイル編成法と呼ばれるプログラム技法を駆使して、自分でデータを管理する仕組みを作成していた。
ファイルシステムすらなかった時代は、自分でデータを記録した位置を管理し、どこにどのようなデータを記録して、ハッシュ法などインデックス（見出し）をするなどをそれなりに複雑なプログラムをそれぞれ実装していた。
DBM¶
初期の UNIX システムでは、DBM という今でいうところの Key-value ストアのようなライブラリが使用されていた。データはファイルに保存され、C 言語のライブラリとして実装されていて、データはキーと値というとても単純な形式で格納されていた。検索はキーからしか検索できず、今の DBMS から見るととても不便に感じるが、当時としては画期的な製品だった。
ただ後継の Berkeley DB は、オラクルに買収されいまだにメンテナンスされている。
リレーショナルデータベースマネジメントシステム(RDBMS)¶
現在では、DBMS としてリレーショナルデータベースマネジメントシステム(RDBMS)が広く普及している。
RDBMS は行、列をもつ表形式で表現されたデータを管理するのが得意な DBMS だ。データを表形式でまとめることは、Excel の普及ぶりを見てもわかる通り非常にわかりやすく、RDBMS はとてもよく利用されている。
RDBMS では表に対して、さまざまな操作ができる。例えば複数の表から特定の列だけ取り出して新しい表を作ったり、表から特定の行を抜き出したりという操作がとても速くできるように作られている。
表の操作は SQL （Stuructured Query Language）というテーブル操作用の命令セットをつかっておこなわれる。
AWS のサービスでは RDS が筆頭だろう。 MySQL、PostgreSQL、Oracle、Microsoft SQL Server など様々な RDBMS製品を簡単に使うことができる。
DBMS ではデータの管理、特にストレージ容量の設計、見積もりが大変難しい。大抵の場合予想以上の大ヒット商品がでて、ストレージの容量が足りなくなったり、逆に多く見積もりすぎて、無駄にお金を使うことになったりすることもある。 Amazon Aurora ではストレージが自動的に拡張されるため、無駄にストレージを使うこともなくまた、冗長化なども自動的に行ってくれる。
Amazon Aurora Serverless を利用すれば、実際にクエリ（問い合わせ）を実行した量に応じて課金され、スケールアップ、ダウンも自動的に行われる。キャパシティプランニングという問題からかなり自由になる。
SQL を使ってデータを分析するという視点からは、Amazon Redshift や Amazon Athena がある。
通常の RDBMS ではデータの一つのエントリはは行単位で格納、取り出しが得意なように設計されている。そのため列単位でのデータ処理、例えば合計や平均などの処理があまり得意ではない。 Amazon Redshift ではデータの格納方法を工夫することで、こういった集計処理を高速で行うことができる。複数のインスタンスにデータを分散して格納し、大量のデータを高速に行うこともできる。
SQL を利用してデータの取り出しを行うという意味では、Amazon Athena も便利だ。Amazon Athena は S3 に格納した CSV 等のデータに対して直接 SQL 言語を利用してデータの検索などを実行できる。別途 DBMS にデータを格納したり、RDS を設定したりすることなしにデータ検索が実施できるのはとても便利だとおもう。
Amazon EMR では、Presto および Spark がサポートされているので、Hadoop クラスタ上に展開されているデータに対して SQL を利用して、データ解析をすることができる。
NoSQL¶
表というデータ形式を採用した RDBMS は非常に成功した方式だが、表形式が苦手なデータも存在する。
また RDBMS は ACID 原則に基づいて強い整合性を保つように設計されているが、そのためにスケールしにくく、多重実行効率を稼ぐことが難しい場合がある。
そのため、RDBMS以外にもさまざまな方式の DBMS が提案されている。こういった SQL を使わない DBMS を総称して NoSQL という。
Document DB¶
表形式ではなく、XML 形式や JSON 形式など構造化されたドキュメントを格納し検索できるようにした DBMS を Document DB という。Word や HTML のような自由形式の文書を格納し、全文検索を実行するような使い方はできないので注意が必要だ。そのような用途には、Amazon CloudSearch とう別のサービスが提供されている。
AWS ではドキュメントDBとして、Dynamo DB と マネージドで Mongo DB 互換である、Amazon DocumentDB が利用できる。
Amazon Dynamo DB は、完全にサービスとして提供されている DBMS で、RDBMSのように複数の表を結合して、様々な条件を指定するような複雑な問い合わせを実行するのには向かないが、キーに基づいて大量のデータから特定のデータセットを高速に抽出するような用途に向いている。例えば、多数の商品カタログの中から品番に基づいて商品を検出する、同時に大量の申込がある WEBフォームのデータを格納する等の用途に向いている。
Amazon DocumentDB は、Mongo DB 互換なのでこれまで、MongoDB を用いて開発してきた資産が多数ある場合、オンプレミスからの移行などの用途が想定される。
Key-Value ストア¶
Key-Value ストアは RDBMS および SQL のような複雑なデータ構造や複雑な問い合わせに対応することを放棄して、その代わりにデータへの低レイテンシなアクセスを実現する。
データはキーと値の組み合わせという非常に単純な構造で格納する。データ構造が単純なため、レプリケーションや複数のデータベースに分割するシャーディングなどのテクニックを RDBMS と比較して比較的簡単に実装することができる。
AWSでは Amazon ElastiCache が相当する。ElastiCache では、Redis と Memcached の２つのタイプのエンジンが提供されている。どちらもメモリ上にデータを保持して、高速なレスポンスが期待できる。
想定される用途としては、RDBMS へのクエリ(問い合わせ)のキャッシュ、アプリケーションのセッション情報の一時的な保存などに利用する。
台帳型データベース¶
Amazon Quantum Ledger Database で採用されているデータベースの方式。仮想通貨などで利用されている分散台帳と類似しているが、集中管理されている点が異なる。暗号技術を利用して過去の変更履歴がすべて保存されており、改変することができない。
会計や簿記で台帳の記録は基本的に修正されず、もし訂正や修正する場合は直接記録を書き換えるのではなく、修正仕訳として修正内容を追記するようにする。同じように登録されているデータを直接修正するのではなく、修正する内容を記録していく。
過去の登録、修正内容がすべて記録されていて、かつ暗号技術によって記録が改ざんされてないことが確認できるため、記録内容の信頼性、監査可能性が高いが、複雑なクエリや低レンテンシの応答は期待できない。
グラフデータベース¶
グラフ型の構造をもったデータを取り扱うのに適したデータベース。
グラフとはノードとノードをつなぐエッジで表現されるデータのこと。例えば SNS の友達関係、この場合はユーザがノードで友達のつながりがエッジになる。鉄道の路線図であれば駅がノードで線路がエッジになる。購買履歴であれば商品がノードで同時に購入されているという関係がエッジになる。
グラフ型のデータ構造は、表として表現することもできるが、SQLでグラフ型のデータを扱うのはあまり効率が良くないか、煩雑となるため専用のデータベースとクエリ言語が開発された。
AWSでのサービスでは、Amazon Neptune が該当する。
時系列（タイムシリーズ）データベース¶
時系列でのデータ処理に特化したデータベース。現実世界ではデータを時系列で処理することは多くみられる。例えば、株価や為替、気温の変化、自動車の走行距離などいくらでも見受けられる。
古くは MRTG から派生した RRDtool 等がある。
時系列データは基本的に追記が多くまたリードアクセスではシーケンシャルなアクセスが多いなどの特徴に即して、最適化されている。
AWS では、Amazon Timestream が利用できる。
まとめ¶
AWS では、たくさんのデータベースサービスが、提供されてる。今回はデータの表現形式に注目してデータベースサービスを整理してみたが、同じデータであっても、利用方法や利用シーンによって最適な DBMS はことなる。
これまで DBMS は高価で高速なコンピュータ資源を要求され、初期投資、維持のコストが高くついたのでスポットでの利用が難しかった。 AWS をはじめとするクラウドサービスであれば、オンデマンドで利用でき、初期投資や、継続的な保守費用は必要ない。
幸いにも AWS Glue や AWS Data Pipeline など、ETL や データの移動、加工を支援するためのツールも提供されている。特定の DBMS にこだわることなく利用シーンに合わせて最適なデータベースを組み合わせて利用したい。
