AWS のデータベースサービスはなぜ複数存在するのか
丸本 健二郎 (AWS Data HERO)
データベースの歴史
1960 年頃 : データベースの誕生
コンピューターを用いてデータ処理を行うようになった当初はデータとプログラムは一体化しており、まだデータベースという概念が存在していません。
データベースの概念は 1959 年に W.C.MaGee 氏が発表した「電子データ処理を成功させる秘訣」という論文が起源と言われます。ここでデータをデータファイルとして独立させ、プログラムと分離させることによりデータ重複の回避とシステム保守・拡張を容易にする考え方が提唱されました。
1963 年にこの考え方を取り入れた階層型データベース (HDB) や網型データベース (NDB) が生まれます。この NDB の標準仕様を取り込んだのが有名な COBOL です。
1970 年頃 : RDB の誕生
HDB や NDB はデータベース設計時に処理を含めて考えねばならず、データ領域の扱いにおいて拡張性に課題がありました。こちらの課題を解決するべく、1970 年に IBM のコッドが「大規模共有データバンクのためのデータ関係モデル」という論文で RDB を提唱します。こちらは、
- データをハードウェアから独立させて格納するべき
- 非手続き言語を使用してデータにアクセスするべき
- データは行と列からなるテーブル構造に収めるべき
という考え方を示しました。一般的には、RDB の最大の特徴は ACID 特性と理解してよいと思います。ACID 特性とは、
- A : Atomic (原子性)
- C : Consistency (一貫性)
- I : Isolation (独立性)
- D : Durability (永続性)
を指します。RDB は SQL を用いて操作することが可能で、データを動的に結合させることを可能としました。
2000 年頃 : NoSQL の誕生
RDB はとても優れたアーキテクチャであり、データベースのデファクトとなりました。しかしながら RDB も完璧ではありません。大量のデータ処理を行いたい際、ひとつのコンピューターでは限界があるため、複数のコンピューターで処理をしようという分散処理の考え方がありますが、ACID 特性のうち、C : Consistency (一貫性)、I : Isolation (独立性) は言葉のとおり、分散処理と相性が悪く、大量処理を行うことが苦手でした。
この分散処理の特性として、可用性や性能を重視した BASE という考え方がでてきました。この BASE とは、BA : Basically Available (可用性が基本コンセプト)、S : Soft-state (状態が常に完璧として捉えない)、E : Eventual Consistency (結果は整合性がとれている) を指します。
このように ACID 特性を生かした RDB を使わずに、別の考え方で物事を解決しようという考え方から NoSQL という言葉が生まれ、研究が進みます。
2010 年頃 : NoSQL の拡大
2000 年代に生まれた NoSQL のデータベースが次々とプロダクトとして出てきます。
まず、列思考データベースです。RDB はテーブルの行をレコードとして格納し、データを取得する際に行すべてのデータを取得するイメージとすると、列思考では指定した列のデータのみを操作することで処理効率をあげます。またデータ検索をする際に必要のないデータを検索しないようにデータを昇順などで並べておくことで、必要なデータのみを検索し、最低限のデータをスキャンすることで処理を高速化させることができます。
つぎに、キーバリューストアです。高可用性、高拡張性を実現しますが、さまざまな結合が可能な SQL 操作が可能な RDB と異なり、キー操作しかできず、複雑な SQL はかけません。
そして、時系列データベースです。時間の変化に注目したデータを保存し、時間の推移でなにがどのように状態変化しているかを解析するのが得意なデータベースです。
さらに、台帳データベースです。中央集中型の台帳機能に特化したデータベースです。データの変更を履歴で管理し、履歴を変更・削除できないよう制御されています。また、データが意図しない内容に変更されていないか、チェックする機能が提供されています。
そして、グラフ指向データベースです。「ノード」「リレーション」「プロパティ」の3要素によってノード間の「関係性」を表現する「グラフ型のデータモデル」を持ち、データ構造はネットワーク状になっており、格納しているデータそのものではなく、データの関係性に注力しています。
最後に、ドキュメント型データベースです。JSON や XML で書かれた不定形なデータを管理するデータベースであり複雑なデータモデリングが可能です。
AWS のデータサービスのご紹介
これまでの歴史を振り返ると、AWS のデータサービスがなぜ 9 種類もあるのか、その答えは一つの仕組みでは全ての要件を叶えることは難しいからであるということがわかると思います。
さて、それでは 9 もある AWS サービスの特性をそれぞれ説明し、使い分けができるように理解をすすめましょう。
Amazon RDS
Amazon Relational Database Service (Amazon RDS) は、6 つのデータベースエンジンから選べるリレーショナルデータベースサービスです。
- Amazon Aurora
- PostgreSQL
- MySQL
- MariaDB
- Oracle Database
- Microsoft SQL Server
Amazon Redshift
Amazon Redshift は高速なクラウド向けデータウェアハウスサービスです。Amazon Redshift ではペタバイト規模の蓄積されたデータの中から、構造化および半構造化データを高速に分析し、インサイトを得ることができます。そのため、製薬会社や飲食サービスなど幅広い業界でデータ分析に利用されています。
Amazon ElastiCache
Amazon ElastiCache は、キーバリューストアのインメモリデータストアサービスです。キーバリューストアは Redis、または Memcached から選択できます。また、データベースの管理タスクは AWS が行うため、ユーザーは行う必要がありません。
Amazon ElastiCache の主な利用用途は RDBMS などのインメモリキャッシュや、ゲームなどのセッションストアです。
Amazon DynamoDB
Amazon DynamoDB は、AWS がフルマネージドするキーバリューストアです。システムの規模にかかわらず、自動的にスケールアップ・スケールダウンを調整し、高速で一貫したパフォーマンスを提供しています。
Amazon DynamoDB は、リアルタイム入札やゲーム、在庫追跡など、様々な所で利用されています。
Amazon Keyspaces (Apache Cassandra 向け)
Amazon Keyspaces (Apache Cassandra 向け) は、Apache Cassandra と互換性のあるマネージドデータベースサービスです。サーバーレスで AWS 側のサーバの管理を行うため、ユーザーはサーバの管理を行う必要はありません。
また、Amazon Keyspaces はシステムの規模にかかわらず、安定的に 1 桁ミリ秒の応答時間を提供できるよう、AWS がサーバの利用状況に応じて自動でスケーリングします。産業用機器のメンテナンス、ルートの最適化などで利用されることを想定しています。
Amazon DocumentDB (MongoDB 互換)
Amazon DocumentDB (MongoDB 互換) は、MongoDB と互換性がある堅牢かつ高速なドキュメント型データベースサービスです。AWS 側でスケーリングやバックアップの管理タスクを行うため、ユーザーがデータベースの管理タスクを気にする必要はありません。
Amazon DocumentDB の主な利用用途はショッピングサイトなどのカタログ管理や、ユーザーのプロファイル管理などがあります。
Amazon Neptune
Amazon Neptune は、クラウド向けの高速なグラフ指向データベースサービスです。Gremlin と SPARQL 向けのオープングラフ API をサポートしています。また、ナレッジグラフやデータの不正検出などで利用されることを想定しています。
Amazon Timestream
Amazon Timestream は、高速な時系列データベースサービスです。サーバーレスなので、サーバーの管理が必要なく、サーバーの容量は AWS が自動的に容量をスケールし、調整します。
IoT アプリケーションや機器のモニタリング、Web システムのトラフィックの分析などで利用されています。
Amazon QLDB
Amazon Quantum Ledger Database (QLDB) は、AWS がフルマネージドする台帳データベースサービスです。また、Amazon QLDB では AWS が提供する SQL 互換クエリ言語が利用できるため、SQL の演算子でデータの検索、管理、更新が簡単に行えます。
Amazon QLDB の主な利用用途は銀行取引の履歴追跡、サプライチェーンでの商品の追跡などがあります。
まとめ
複数のデータベースサービスが存在する理由をデータベースの歴史を振り返ることで説明してみました。データ量がおおいのか、データの同時アクセスが多いのか、即座に処理をしたいのか、何がやりたいのかによって、採用するデータベースは異なります。
筆者プロフィール
丸本健二郎
オプターク合同会社 代表
AWS Data HERO | BigData-JAWS 運営メンバー
1980 年、広島県東広島市生まれ。2005 年、大学の情報学部を卒業し大阪の SIer に就職。人事パッケージの導入支援コンサルティングに携わる。2008 年、日本オラクルに移り大手企業を対象とした人事給与システムなどの構築に従事。2011 年、広島の大型プロジェクトをきっかけに帰郷し、翌年、同市に本社を置く大創産業の情報システム部門に転職。入社後はシステムの内製化を推進し、AWS を採用した発注システムやAmazon Redshift を用いた自動発注システムを構築に尽力。その後も AWS のサーバーレス環境により 5,000 店舗 × 7 万アイテムのデータを処理する POS データ集中処理システム構築や BI 環境の整備などを通じて、クラウドシフトに取り組む。AWS Cloud Roadshow 2017 広島での登壇を機に、 JAWS-UG 広島支部の運営にかかわるようになり、2018 年、AWS Samurai に選出される。2019 年、オプターク合同会社を創業。2020 年、県立広島大学大学院経営管理研究科を修了。同年 3 月から専業に。
BigData-JAWS は 4 半期に 1 度、RedShift/EMR/Athena といった分析集計、DaynamoDB に代表される分散 KVS、QuickSight といったビジネスインテリジェンスなどに関連する勉強会を開催しています。ぜひ こちらから登録メンバー となって勉強会に参加ください。
AWS を無料でお試しいただけます