データベースの使用方法 †
要約 †
明確にするために、少し戻ってデータベースについてとりあげてみよう。特定のデータベースを指してはおらず、リレーショナルかNoSQLなどは気にしない。アプリケーションを構築する際のデータベースの一般的な概念について説明する。
例えば、図5-1に示すようなステレオタイプのWebアプリケーションアーキテクチャを考えてみよう。
図5-1 最も単純なWebアプリケーションアーキテクチャ
Webブラウザやアプリのようなクライアントを持っており、クライアントはサーバシステム（バックエンド）とやりとりを行う。バックエンドは通常、何らかのビジネスロジックを実装し、アクセス制御を行い、入力を受け入れ、出力を生成する。バックエンドが将来のために何かを覚えておく必要がある場合、データをデータベースに格納し、何かを探す必要があるときにデータベースを参照する。これはすべて非常に身近なものである。
こういったアプリケーションを構築する方法は、バックエンドのレイヤーをステートレスにすることである。各リスエストを個別に処理し、特定のリクエストは次のリクエストまで何も覚えていない。これには多くの利点がある：複数のプロセスを並行して実行するだけでバックエンドをスケールアウトでき、リクエストを任意のバックエンドインスタンスにルーティングできる（全てのリクエストを同じように処理できる）ので、複数マシン間でリクエスト負荷を分散しやすい。リクエストを処理するために必要な状態は、各リクエスト時にデータベースからルックアップされる。HTTPがステートレスなプロトコルであるため、うまく機能する。
しかし、状態はどこかに行かなければならないので、データベースに格納する。我々は現在、データベースを一種の巨大な、グローバルな、共有された、変更可能な状態として使用している。これは、全てのアプリケーションサーバー間で共有される永続的なグローバル変数のようなものである。
このデータベースベースのアプリケーションを構築するアプローチは何十年も機能していたので、それほど悪くはない。しかし、時々は使い慣れたものから離れて見る価値があり、潜在的により良い方法でソフトウェアを構築することができる。例えば、関数型プログラミング言語を使用する人は、変数の変更ができないことでより良いソフトウェアを構築し、バグを減らし、コードを推論しやすくするなどの面で役立つ、と言う。データベースバックアップアプリケーションでも同様のことが起こりうるだろうか？
第1章で議論したイベントソーシングのアプローチは、命令的な可変状態の世界から不変な値の関数型の世界へと移行する方法である。第4章では、Unixツールのパイプラインに関数型なフレーバーがあることにも気づいた。しかし、これまでのところこれらのアイデアを使用するシステムを実際に構築する方法についてはあまり明確ではなかった。
今後の方向性を見出すために、データベースが現在行っていること、データベースで我々が行うことの4つの例を見ていきたい。これらの4つの例は、イベントストリームに関するアイデアを構築し、実際にそれらを適用する方法を築くのに役立つ。
担当者のつぶやき †
みんなの突っ込み †
