The Unbundled Database †
- 興味深いパターンです。派生したデータ構造（索引、マテリアライズド・ビュー）は、従来、モノリシック・データベース内で内部的に実装されていましたが、ストリーム処理ツールを使用して、アプリケーション・レベルで類似の構造が次第に導入されています。
- この傾向は、既存のデータベースがすでに十分にうまくいっていれば、誰も生産システムでこれらの機能を再実装する必要はありません。データベースに似た機能を構築するのは難しい：バグを導入するのは簡単で、多くのストレージシステムは高い信頼性の要求を持っている。リード・スルー・キャッシュの議論では、アプリケーション・レベルでのデータ管理が非常に乱雑になる可能性があります。
- しかし、この傾向は良くなったり悪くなったりしています。我々はそれを判断するつもりはない。私たちはこれを理解し、過去数十年のデータベースとオペレーティングシステムの作業から学んだことを学ぶだけです。
- この章の前半（図5-2）では、データベースの複製ログが、イベントソーシングに使用するイベントログと非常によく似ていることがわかりました。大きな違いは、イベントログはアプリケーションレベルの構造であるのに対して、レプリケーションログは伝統的にデータベースの実装の詳細とみなされる点です（図5-21）。
- SQLクエリとレスポンスは、伝統的にデータベースのパブリックインターフェイスです。レプリケーションログは、その抽象化によって隠されている側面です。 （変更データの取り込みは、しばしば改造され、実際にはパブリックインターフェイスの一部ではありません。）
ストリーム処理を解釈する1つの方法は、データベースを裏返しにすることです。コミットログまたはレプリケーションログは、実装の詳細にはなりません。 むしろ、それはアプリケーションのアーキテクチャの一流の市民になっています。 これをログ中心のアーキテクチャと呼ぶことができます。面白いことに、巨大な分散データベースのように見え始めます。
- さまざまなNoSQLデータベース、グラフデータベース、時系列データベース、およびフルテキスト検索サーバーは、異なるインデックスタイプであると考えることができます。リレーショナルデータベースのように、Bツリー、Rツリー、ハッシュインデックスなどを選択できるように、異なるアクセスパターンを効率的に処理するために、データシステムが複数の異なるデータストアにデータを書き込む場合があります。
- ビジネス・インテリジェンスを提供するために、同じデータをHadoop、データ・ウェアハウス、またはアナリティック・データベースに簡単にロードできます（イベント・ストリームはすでにアナリティクス・フレンドリであるため、複雑なETLプロセスは不要です）。
- SamafaなどのKafka Streamsライブラリおよびストリーム処理フレームワークは、トリガ、ストアドプロシージャ、マテリアライズドビューメンテナンスルーチンのスケーラブルな実装です。
- MesosやYARNなどのデータセンターリソースマネージャは、物理マシンの障害からスケジューリング、リソース割り当て、および回復を提供します。
- Avro、Protocol Buffers、Thriftなどのシリアライゼーションライブラリは、ネットワーク上およびディスク上のデータのエンコーディングを処理します。また、スキーマの進化（スキーマを互換性を失うことなく時間をかけて変更できるようにする）も処理します。
- Apache KafkaやApache BookKeeper?などのログサービスは、データベースのコミットログとレプリケーションログに似ています。耐久性、書き込みの順序付け、コンシューマの障害からの回復を提供します。 （実際には、カフカをトランザクション/レプリケーションログとして使用するデータベースを既に作成しています.8）
従来のデータベースでは、これらの機能はすべて単一のモノリシックアプリケーションで実装されています。ログ中心のアーキテクチャでは、各機能は別のソフトウェアによって提供されます。結果は、データベースと少し似ていますが、個々のコンポーネントは「アンバンドル」されています（図5-22）。
- アンバンドルされたアプローチでは、各コンポーネントは個別に開発されたプロジェクトであり、その多くはオープンソースです。各コンポーネントは特化されています。ログ実装では、ランダムアクセス読み取りと書き込みのインデックスを提供しようとしません。そのサービスは他のコンポーネントによって提供されます。したがってログは本当に良いログになるようにその努力を集中することができます：それは1つのことをうまく行います（図4-3参照）。システムの他の部分についても同様の議論があります。
- このアプローチの利点は、各コンポーネントを独立して開発し、拡張することができ、汎用ハードウェアに大きな柔軟性とスケーラビリティを提供できることです.9これは基本的にUnixの哲学をデータベースにもたらします。特殊なツールは複雑なサービスを提供するアプリケーションで構成されます。
- 欠点は、今、学び、配備し、操作する多くの異なる部分があることです。実際の多くの詳細を把握する必要があります。これらのさまざまなコンポーネントをどのように配備し、監視するか、さまざまな障害に対してシステムを堅牢にするにはどうすればよいでしょうか？ ）？
- 多くのコンポーネントは独立して設計されているため、統合性は念頭に置かれていないため、統合は期待通りのものではありません（たとえば、データキャプチャの変更を参照）。 また、ログ中心のシステムやマテリアライズド・ビューでは、データフローを簡潔に記述するための高水準言語であるSQLやUnixシェルと同等の説得力がありません。 要するに、これらのシステムは、単一のベンダーのモノリシックデータベースと同じくらいエレガントに統合されていません。
- しかし、希望があります。 LinuxディストリビューションとHadoopディストリビューションは、多くの異なるグループの人々によって書かれた小さな部分から集められていますが、それにもかかわらず、合理的に一貫した製品のように感じられます。 ストリームデータプラットフォームでも同じことが予想されます。
- マテリアライズド・ビューを提供するためにデータベースが依然として必要であるため、アプリケーションのためのこのログ中心のアーキテクチャは、データベースを置き換えることはありません。 また、データウェアハウスと分析データベースは、アドホックで探索的なクエリに答えるために重要な存在です。
- ストリーム処理とデータベースアーキテクチャの比較は、ここで何が起きているのかを明確にするのに役立ちます。つまり、単一のツールですべてのユースケースを満たすことはできないため、さまざまなツールセットを統合するための良いパターンを見つける必要があります。 単一のシステムです。 データベースのアーキテクチャは、良いパターンを提供します。
担当者のつぶやき †
みんなの突っ込み †
