1

GEODE参照データに関しては、すぐに何かを開始する予定です。同じガイドラインをいくつか取得したいと思います。

ご存知のように、金融参照データの世界では、3NF としてデータベースで利用できる可能性のある、商品、口座、顧客などのさまざまな参照データ エンティティ間に複雑な関係が存在します。

テーブル (2 ～ 5 テーブル) 間の結合を必要とするクエリのほとんどが読み取り集中型である場合、メモリ グリッドで同じことを処理する最善の方法は何ですか?

ケース 1 : データベース内のすべてのテーブルの領域を分離し、OQL を使用してデータベースと同様の結合を行いますか?

その場合でも、関連するエンティティが常に同じパーティション内に配置されるように十分に注意して設計する必要があります。

オブジェクトグラフを使用して1対多および多対多の関係をモデル化しますか?

ケース 2 : 結合クエリがどのように見えるかがわかっている場合は、等結合特性を持つ結合クエリごとにビュー モデルを作成します。

錯乱：

(1) emp.deptId = dept.deptId を使用して Employee,Department を必要とする 1 つの結合クエリがあります [そのようなビュー モデルを持つ素晴らしい 1 つのリージョンが存在します]

(2) 別の結合クエリがあり、別の要件に対応するために、従業員、部門、給与、住所の結合が必要です。

したがって、(1) と同様の従業員と部門のデータを含む (2) に対処するビュー モデルを作成する必要があります。これはすぐにメモリのしきい値に達する可能性があります。

データベースの変更は引き続きイベント リスナーによって管理できますが、そのための推奨事項は何ですか?

ありがとう、ダーラム

4

1 に答える 1

1

あなたの一般的な質問はかなり広いと思います。すべての UC (主に、アプリケーションで必要とされるデータのすべての分析ビュー/モデル) をカバーするための推奨されるアプローチは 1 つだけではありません。

このような質問には、個々のデータ要素のサイズ、データの量、1 つまたは複数のアプリケーションから発生するアクセスまたはアクセス パターンの頻度、情報のタイムリーな配信、必要なデータの精度、サイズなど、多くの要因が含まれます。クラスターのリソース、各 (仮想) マシンの物理リソースなど。したがって、特定のアプローチでは、間違いなくアプリケーションのチューニング、それに応じた GemFire のチューニング、およびデータ モデルに関係なく JVM のチューニングが必要になります。それでも、慎重に作成されたデータ モデルは、そのような調整の範囲を決定できます。

具体的には、GemFire では、このような調整には、データ管理ポリシー、エビクション(オーバーフロー) および有効期限(LRU、またはおそらくカスタム) 設定などのさまざまな構成が含まれますが、これらに限定されず、さまざまなエビクション/有効期限しきい値とともに、データをOff-ヒープ メモリ、さまざまなパーティション戦略 ( PartitionResolver ) の採用など。

たとえば、 Address 情報が比較的静的で不変 (つまり、実際の「参照」データ) である場合、 Address データをREPLICATE Regionに格納することを検討できます。頻繁に書き込まれるデータ (通常は「トランザクション」データ) は、PARTITION Regionの方が適しています。

もちろん、ご存じのように、 (OQL を使用して) クエリで「結合」する (別のRegionPARTITIONで管理される) データはすべてコロケーションする必要があります。GemFire/Geode は現在、分散結合をサポートしていません。

さらに、特定のノードが特定のリージョンをホストする可能性があるため、クラスターを「トランザクション」ノードと「分析」ノードに分割し、分析ベースのノードがトランザクション ノードのリージョンCacheListenersから更新されます (これに注意してください)。AsyncEventListeners で AEQ を非同期的に使用します。AEQ は、可用性と耐久性を高めるために個別に作成することもできます。このトランザクションと分析のアプローチがCQRSの基礎です。

データのサイズは、データが保存される形式 (つまり、シリアライズされているか、シリアライズされていないか) によっても影響を受けます。GemFire 独自のシリアライゼーション形式 (PDX) は、Java シリアライゼーションと比較して非常に最適です。それはすべて、データに必要な「移植性」と、データをシリアル化された形式で保持できるかどうかによって異なります。

また、オンザフライでデータを結合するのにどれだけコストがかかるかを検討することもできます。つまり、実行時に比較的安価にデータを集約、変換、強化できる場合 (コンピューティングとメモリ/ストレージの比較)、GemFire の関数実行サービスを使用して、データをロジックにではなく、ロジックをデータに変換することを検討できます ( MapReduceの基本的な基礎)。

GemFire は Key-Value ストアであるため、複雑なオブジェクト グラフを個別のリージョンにマッピングすることは簡単な問題ではありません。オブジェクトを参照 (特に多対多) で分割し、それらを熱心にロードするか遅延ロードするかを正確に把握することは、特に一貫性と可用性のトレードオフが存在する GemFire などの分散型複製データ ストアでは、過負荷の問題です。

GemFire での永続化とクエリを簡素化するためのさまざまな API とフレームワークがあります。注目すべきアプローチの 1 つは、Spring Data Commons Repository 抽象化の Spring Data GemFire の 拡張です。

また、ジョブに適切なデータ モデルを使用することも問題になる場合があります。非常に複雑なデータ関係がある場合は、おそらくグラフ データベース (Neo4j など) を使用して分析モデルを作成する方が簡単なオプションです。 Springは、Neo4j チームが率いる Neo4j の優れたサポートも提供します。

どのデザインを選択する場合でも、間違いなくハイブリッド アプローチが必要になることは間違いありません。多くの場合、パスは実際に「依存」する (つまり、アプリケーションやデータ アクセス パターン、負荷などすべてに依存する) ため、明確ではありません。

ただし、1 つ確かなことは、基盤となるデータ ストアとそのデータ管理機能について、特に一貫性と可用性に関連するため、大雑把な知識と理解があることです。

また、GemFire slack チャネルとApache DEV メーリング リストもあり、このアーキテクチャ設計を進めていく際により具体的な問題が発生した場合は、GemFire の専門家や (上級) GemFire/Geode ユーザーのコミュニティに連絡するために使用できます。道。

于 2016-06-20T20:13:44.937 に答える