データベースって何？ストレージとの関係は？①
RESTをはじめとした最近のフレームワークや実装では、データベース(DB)やストレージはシステムの中の実装オプションの一例というレベルではなく非常に存在感を増した技術になってきている。一方で、DBやストレージはデータを破損させないように非常に多岐に渡る技術が蓄積されているため、なかなか理解するのにハードルが高い。そこでDBとストレージを勉強する上での入り口になるように概要を説明してみたい。厳密には正しくない部分があるが、分かりやすさ重視のため、その点はご了承頂きたい。
システム開発のフレームワークとデータの関係
突き詰めるとプログラムとは何か？システムとは何か？というと、与えられた情報を元に、定められたロジックによって、問題を解決するもの、である。最初は暗号解読や天気予報など特定の問題を解決するために使われてきたが、段々プログラム言語が開発されプログラムが汎用化されたり、ハードウェアの性能が上がって問題解決のパワーが増したことで、解決できる問題のバリエーションも量も激増してきた。その結果、システム開発の定石(フレームワーク)も変わってきた。
システム開発のフレームワークには様々な評価軸があるが、ここでは問題解決のスケールとして、データ量と処理量に着目してみたい。初期のプログラムはテープにデータとルーティン処理が記録された専用計算機だったものが、プログラムの汎用化とハードウェアの高性能化によって、①扱うデータが増えたことでデータベース化する流れと、②処理量が増えたことに対するマルチプロセス化という2つの流れができる。その結果、一昔前の典型的なフレームワークとしては、データは全てストレージ＋データーベスへ格納しデータの管理に特化したプログラムと、そのデータを加工する処理ロジックに特化したプログラムに分離する流れができた。
しかし、このアーキテクチャは、ストレージのサイズやDBの性能にボトルネックが来たり、処理ロジックが変更になった時に他のロジックへの影響も含めて見直しが必要だったりして、問題(＝要件)の変化に追従し続けるメンテナンスも大変だった。特にデータ量を拡張したり処理量を拡張する場合は、大型サーバのスケールアップ(CPUやメモリやディスクを増やす)が主な方法となっておりコストも増加した。そこで、データとロジックを一つのオブジェクトとして隠蔽し、オブジェクトを複数作成(分散オブジェクト)することでデータ量も処理量も拡張できるフレームワークが出来てきた。これにより、性能が足りなければハードウェアを追加(スケールアウト)したり、影響があるオブジェクトのみを局所的に修正したりということができるようになった。ただし、分散オブジェクトは異常時の複雑性が増しプログラムの難易度が高いのと、オブジェクトを跨いだ多量のデータの相関関係を分析するようなことには工夫が必要であった。
その後、Hadoopのような分散ファイルシステムや分散DBができたことで、元のデータを保存するDB＋ストレージ(正しくDBもストレージもそれぞれスケールアウト可能)と、それらを操作するサービス(こちらもVMやコンテナとしてスケールアウト可能)に分離するようになった。その後そのスケーラビリティをベースにビッグデータやクラウドなどが流行し今に至る。
このフレームワークの進化によって、データを管理する要件も変わってきており、大きく3種類のデータベースが存在する。- ストレージ＋DBによる高信頼(障害発生時もデータ保護)＆データ同士も矛盾が無いような厳密なデータ管理 → Relational DataBase (RDB) + SQL
- メディアデータのような大容量＆高パフォーマンス(データ間の関係性は疎)のデータ管理 → Not Only SQL (NoSQL)
- SNSなどのような処理量は膨大だが、ほとんどのリアルタイムデータは生成後数時間以内に利用するようなデータの管理(障害発生時はやり直し) → Streaming DB
データベースのお仕事
ここではRDBを参考にデータベースのお仕事を説明したい。システム開発のフレームワークで話した通り、データとロジックを分離し、そのデータをまとめて管理することで高信頼かつ高性能なデータ保護機能と、各データ間の関係性を厳密に管理する必要が出てきた。当然ながらデータを制御するプロセスは多数存在しそれらが同時にアクセスしたり、データを多数保存しているので常時どこかのDiskが壊れたりしている中で、データの消失やデータ矛盾から保護しるなければならない。共有しているExcelシートを何十人で同時に修正するところをイメージして欲しい。例えば帳簿データとかだとすると、1人目と2人目の処理によって残金が正しく計算されなければならないが、同時に2人が変更することで後発で上書きしてしまっては困る。また、何十本と挿さっているDiskの1本が壊れただけでExcelファイルが壊れてしまっても困る。
そこでデータベースとしては、このような要件から高信頼(ACID)＆高性能＆高スケーラビリティが求められる。
- 多数のクライアント(ユーザプロセス)から同時にアクセスされても特定の時間内で＆矛盾の無い(Atomicity/Consistency/Isolation/Durability)データ処理を完了する
- どの物理装置が壊れたとしてもデータが保護される
- 物理装置の制約を受けず大量のデータを長期間保存できる
- 外部記憶装置への書き込みは遅延させてまとめて行い、基本的にはメモリ上でデータ処理する。
- 処理が終わった後にデータを外部記憶装置に書き込むとデータを欠損する可能性があるため、SQL文だけをログ先行書込として保存しておき、最悪ログからデータを復旧できるようにしておく。
- メモリに残すデータを選別するためにデータアクセスの統計情報を保持しており、統計情報に基づいて利用頻度の高いデータを残す。
- データ容量が増えてファイル数が膨大になってくることを想定し、よく使うデータはIndexという形で、該当データの格納ファイルのマッピングを保持しておく。これによって、Index内のデータであれば仮にメモリ上に無いデータだったとしてもピンポイントでファイルを読み込めるので高速化できる。
- Indexや統計情報をもとに具体的なデータ操作をするためのデータアクセスの文法(SQL)によってクライアントはDBMS上でデータを操作する。SQL実行中は他のクライアントのSQLの影響を受けずに独立して実行でき、最後に“Commit“することでデータが反映される(データが間違っていればRollbackする)ため、データの競合や矛盾が起きないようにする。
- SQLを処理するExecutorはプロセスとしてCPUコア数に応じて起動することでクライアントからの同時に大量のSQLを処理可能となる。
- 先行書込ログを分散配備させることで、Standbyサーバやバックアップサーバ、拠点間冗長などを行う。
このような構成によって、データベースは高信頼かつ高性能を実現してきた。しかしながら、メディアデータのようなデータ間のチェック機構などが必要なものや、1レコードが膨大なデータサイズには、DBの各種機能はオーバースペックである。もちろんDBMSも様々な進化をしているので、様々なデータ特性にあった機能を配備しているものもあるので、ここでは考え方だけ理解して貰いたい。
テキストのデータからメディアデータのようなデータが操作対象データになってきたことで、NoSQLというデータベースも現れてきた。こちらはメディアデータの場合、データ自体の加工や矛盾性のチェック機構は不要で、高速にまとまったデータの格納と取り出しが要件となる。そこで、RDBMSのようなSQL文のACIDを保証するような仕組みを取らず、イベント＋ポーリング方式で大量のデータを格納＆読み込みできるようにしている。これによって、RDBMSと比較して圧倒的な高分散かつ高性能化を実現している。
データベースは様々な技術を駆使することで、高性能かつ高信頼を実現している。RDBMSだけでもPostgreSQL、MySQL、Oracleと様々あり、それぞれ性能向上のための工夫も異なり、得意とするデータの特性も異なる。しかしながら、5000万〜1億という膨大なデータを矛盾なく一定の速度で管理し続けたRDBMSは技術の粋が詰まっていたと言えるだろう。
一方で、ハードウェアや分散技術が進化し、足りないデータ量や処理量は多数のハードウェアでスケールアウトすれば良いという分散ファイルシステムや分散ストレージの発想は、RDBMSで管理していたデータの考え方を大きく変えた。Big Dataとして一気にデータを分析したり、テキスト以外の様々なメディアデータを格納できるようになった。そして最近ではSreaming DBなど新しい形態のデータ管理手法が生み出されている。データの特性や自チームの既存資産(スキル、開発＆商用環境、関連システム等)に合わせてDBの選択やハードウェアの設計が必要な時代となっている。
コメント
コメントを投稿