問題タブ [geode]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
172 参照

apache - Apache Geode REST ドキュメントがありません

Apache Geode REST API の使用に興味がありますが、これに関するドキュメントが見つかりません。

Github ( Geode REST )のリンクをたどろうとしましたが、うまくいかないようです。

ドキュメントまたは実行例を提供できますか?

0 投票する
1 に答える
78 参照

geode - GEODE ​​を設定してメモリ使用量を減らす方法

4.5M (150Mb) のキーを保存しようとしていますが、GEODE ​​サーバーは既に ~3.5Gb の RAM を消費しています。

0 投票する
2 に答える
337 参照

spring - Spring in Memory データ グリッド アプリケーション

インメモリ データ グリッド ベースのアプリケーションのサーバー側で Spring を使用することは賢明ですか?

私の直感では、低遅延の高性能システムではナンセンスだと思います。私の同僚は、Spring を含めることを主張しています。そのような包含の長所と短所は何ですか?

私の立場は、Spring はクライアントで使用しても問題ありませんが、サーバーには重すぎて、依存関係が多すぎて、考えるにはもう 1 つの漏れやすい抽象化であるということです。

0 投票する
1 に答える
1067 参照

gemfire - GEODE ​​を使用したデータ モデル設計ガイドライン

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

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

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

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

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

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

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

錯乱:

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

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

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

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

ありがとう、ダーラム

0 投票する
1 に答える
854 参照

java - Apache Geode - 結合でのクエリ パフォーマンス

キャッシュ ソリューションとして Apache Geode を使用しています。2 つの異なるリージョン内にデータを保存し、単純な結合クエリでそれらを取得する必要があります。

レプリケートされたリージョンとパーティション化されたリージョンの両方を試しましたが、クエリが結果を返すのに時間がかかることがわかりました。両方のリージョンにもインデックスを追加しました。これによりパフォーマンスは向上しましたが、まだ十分な速度ではありません。このクエリのパフォーマンスを向上させる方法について誰か助けてください。

これが私が試したことです

例 1 - 分割されたリージョン

キャッシュから約 7300 件のレコードを取得するのにかかった時間は 36 秒でした

cache.xml での構成

クエリ関数

関数の実行

例 2 - レプリケートされたリージョン

キャッシュから約 7300 レコードを取得するのにかかった時間は 29 秒でした

cache.xml での構成

クエリ

0 投票する
1 に答える
432 参照

configuration - アパッチ ジオードの構成

Linux で Apache Geode (v1.0.0-incubating.M2) を実行しようとして問題が発生しました。

問題はgfsh start server --name=server1、ドキュメントからサンプルコマンドを実行しようとしたときに、次のエラーが発生したことです。

Exception in thread "main" com.gemstone.gemfire.InternalGemFireError: Cannot resolve local host name to an IP address.

0 投票する
1 に答える
528 参照

gemfire - Gemfire のレプリケートされたリージョンで並列非同期イベント キューを構成する

レプリケートされたリージョンで非同期イベント キューを使用するために、Gemfire/Geode を構成しようとしていますparallel=true。ただし、起動時に次の例外が発生します。

これ (つまり、レプリケートされたリージョンでの並列キューを防止するため) は設計上の決定のようですが、なぜそうなのか理解できません。
見つけたすべてのドキュメント (主にhttp://gemfire.docs.pivotal.io/docs-gemfire/latest/reference/book_intro.htmlおよび関連ドキュメント) を読み、あらゆる種類の参照を検索しました。この例外はインターネット上にありますが、レプリケートされたリージョンをホストしている各メンバーにイベント リスナーを設定できない理由について明確な説明が見つかりませんでした。
私の結論は、レプリケートされたリージョンや並列キューに関するいくつかの基本的な概念が欠けているに違いないということですが、自分で適切なドキュメントを見つけることができないため、説明や適切なリソースへのポインタを求めています読んだ。

前もって感謝します。

編集:質問を文脈に入れましょう。
パフォーマンスを最大化するためにノード間で負荷分散される REST サービスを使用してアプリケーションにデータを送信する外部システムがあります。各ノードは同じリージョンをホストします (AB と C という名前の 3 つのリージョンとしましょう)。データは、これらすべての領域 (A から B から C) を通過し、途中で処理されます。つまり、リージョン A は受信したばかりのデータをホストし、リージョン B は部分的に処理されたデータをホストし、リージョン C は処理が完了したデータをホストします。
イベント リスナーを使用してデータを処理し、リージョンからリージョンに移動します。リージョン C のリスナーの場合は、別の外部システムにエクスポートします。
すべてのリスナーはトランザクション対応でなければなりません (繰り返しますが、そうしなければなりません)。
また、水平方向のスケーラビリティ (つまり、スループットを向上させるためにオンザフライでノードを追加すること) と、達成可能な最大量のデータ複製も必要です。
さらに、すべてのノードを同じ gemfire 構成で実行したいと考えています。

私はすでに分割された領域を使用しようとしましたが、簡潔にするためにここでは説明しない多くの理由により、それらは私のニーズに適合しません (ただ、私を信じてください、現在は不可能です)。

そのため、すべてのノードでレプリケートされたリージョンをホストすることが有効であると考えましたが、すべてのノードでイベントを個別に処理し、後でアクティブ/アクティブ シナリオでリージョンの同期を実行できるようにする必要があります。これにはイベント キューを並列にする必要があることは理解していますが、(設計上) 可能ではないようです。

したがって、(更新された)質問は次のとおりです。このシナリオは可能ですか?もしそうなら、どうすればそれを達成できますか?説明および/またはドキュメント、例、リソース、またはその他のものは大歓迎です。

繰り返しますが、事前に感謝します。