アグリゲートオリエンテッドデータベース

「NoSQL蒸留」に取り組んでいる私たちが最初に思い浮かべたトピックの1つは、NoSQLデータベースはリレーショナルモデルとは異なるデータモデルを使用するというものでした。私が参照したほとんどの情報源では、キーバリュー、ドキュメント、カラムファミリー、グラフの4つのグループのデータモデルについて言及されています。このリストを見ると、最初の3つに大きな類似性があることがわかります。どちらも、密接に関連したデータの豊かな構造である基本的なストレージユニットを持っています。キーバリューストアの場合は値、ドキュメントストアの場合はドキュメント、カラムファミリーストアの場合はカラムファミリーです。DDDに関して、このデータグループはDDD_Aggregateです。

NoSQLデータベースの台頭は、主にGoogleやAmazonが使用しているセットアップなどの大規模なクラスターにデータを効果的に保存したいという願望によって促進されてきました。リレーショナルデータベースはクラスターを念頭に置いて設計されていなかったため、人々は代替案を求めてきました。アグリゲートを基本単位として格納することは、クラスター上で実行する場合に非常に理にかなっています。アグリゲートは、一緒にアクセスされることが期待される大量のデータを処理するため、シャディングなどの分散戦略に適しています。

アグリゲートは、アプリケーションプログラマーにとっても非常に理にかなっています。画面いっぱいの情報をキャプチャしてリレーショナルデータベースに格納する場合は、その情報を保存する前に行に分解する必要があります。

アグリゲートは、はるかに単純なマッピングを作成します。その結果、NoSQLデータベースの初期の採用者の多くが、より簡単なプログラミングモデルであると報告しています。

プログラミングモデルと分散モデルのこの相乗効果は非常に貴重です。アプリケーションプログラマーがデータをどのようにクラスタリングするかについての知識をデータベースが使用して、クラスター全体のパフォーマンスに役立てることができます。

重大な欠点は、データアクセスがアグリゲートと一致する場合に全手法が非常にうまく機能するものの、データを別の方法で見たい場合にはどうなるかという点です。注文の入力は自然に注文をアグリゲートとして格納しますが、製品の販売を分析するとアグリゲート構造に影響します。データベースでアグリゲート構造を使用しない利点は、異なる対象者にデータをさまざまな方法でスライスアンドダイスできることです。

そのため、アグリゲート指向ストアではマップリデュースについて非常に多く語られています。これは、クラスター上で実行するのに適したプログラミングパターンです。マップリデュースジョブは、さまざまなリーダーに対してデータをさまざまなグループに再編成できます。つまり、多くの人がマテリアライズドビューと呼んでいます。ただし、これはリレーショナルモデルを使用するよりも多くの作業が必要になります。

これはポリグロット永続性の議論の1つです。明確なアグリゲートを操作する場合（特にクラスター上で実行している場合）はアグリゲート指向データベースを使用し、データをさまざまな方法で操作する場合（リレーショナルデータベースまたはグラフデータベース）はリレーショナルデータベースを使用します。