私たちは小売ネットワークの技術開発部門です。 ある日、経営陣は Apache Ignite を MSSQL と組み合わせて使用することで大規模な計算を高速化するという課題を設定し、美しいイラストと Java コードの例を掲載した Web サイトを公開しました。 すぐにそのサイトが気に入った この説明は奇跡を約束します。グリッド内の各ノードに Java または Scala コードを手動でデプロイし、変更されるたびに再デプロイする必要がありません。 作業が進むにつれて、Zero Deployment には特定の用途があることが判明したので、その機能を共有したいと思います。 カットの下には、考えと実装の詳細が記載されています。
1 問題ステートメント
問題の本質は次のとおりです。 SalesPoint 販売ポイント ディレクトリと Sku (在庫管理単位) 製品ディレクトリがあります。 POS には、「小規模」と「大規模」の値を持つ「店舗タイプ」属性があります。 品揃え (販売時点の製品リスト) が各販売時点 (DBMS からロード) に接続され、指定された日付から指定された製品が販売されたという情報が提供されます。
品揃えから除外されるか、品揃えに追加されます。
POS のパーティション化されたキャッシュを整理し、接続されている製品に関する情報を XNUMX か月前に保存する必要があります。 戦闘システムとの互換性を確保するには、Ignite クライアント ノードがデータをロードし、フォームの集計 (店舗タイプ、製品コード、日、販売ポイント数) を計算し、それを DBMS にアップロードし直す必要があります。
2. 文学の研究
まだ経験がないので、ストーブの上から踊り始めています。 つまり、出版物のレビューからです。
2016年の記事 Apache Ignite プロジェクトのドキュメントへのリンクが含まれていると同時に、このドキュメントの曖昧さに対する非難も含まれています。 何度か読み返しましたが、はっきりとはわかりません。 公式チュートリアルを参考にさせていただきました どちら
「すぐに使い始められるよ！」と楽観的に約束します。 XNUMX つの Apache Ignite Essentials ビデオを見ながら環境変数の設定を理解していますが、これらは私の特定のタスクにはあまり役に立ちませんでした。 標準ファイル「example-ignite.xml」を使用してコマンド ラインから Ignite を正常に起動し、最初のアプリケーションを構築しました。 Mavenを使用して。 アプリケーションは動作し、Zero Deployment を使用しています。なんと素晴らしいことでしょう。
さらに読んでみると、この例では (SQL クエリを通じて以前に作成された) affinityKey がすぐに使用されており、さらに謎の BinaryObject も使用されています。
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); 読んだ : バイナリ形式 - 名前によってオブジェクトのフィールドにアクセスする、リフレクションのようなもの。 オブジェクトを完全に逆シリアル化せずにフィールドの値を読み取ることができます (メモリを節約)。 しかし、ゼロ デプロイメントがあるのに、なぜ person の代わりに BinaryObject が使用されるのでしょうか? IgniteCache を使用する理由IgniteCache に転送? それはまだ明らかではありません。
私の場合に合わせてコンピューティングアプリケーションを作り直しています。 MSSQL の POS ディレクトリの主キーは [id] [int] NOT NULL として定義されています。同様にキャッシュを作成します。
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")XML 構成では、キャッシュがパーティション化されていることを示します
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>POS によるパーティショニングでは、各クラスター ノードで利用可能な salesPointCache レコードに対して必要な集計が構築され、その後クライアント ノードが最終的な合計を実行することを前提としています。
チュートリアルを読んでいます , 類推してやってます。 各クラスター ノードで、次のような IgniteRunnable() を実行します。
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}集計とアップロードのロジックを追加し、テスト データ セットで実行します。 すべては開発サーバー上でローカルに動作します。
XNUMX つの CentOs テスト サーバーを起動し、default-config.xml で IP アドレスを指定し、それぞれで実行します。
./bin/ignite.sh config/default-config.xml両方の Ignite ノードが実行されており、相互に認識できます。 クライアント アプリケーションの XML 構成で必要なアドレスを指定すると、アプリケーションが起動し、トポロジに XNUMX 番目のノードが追加され、すぐに XNUMX つのノードが再び存在します。 ログの行に「ClassNotFoundException: model.SalesPoint」と表示されます。
SalesPoint sp=salesPointCache.get(spId);StackOverflow によると、エラーの理由は、CentOs サーバーにカスタム SalesPoint クラスが存在しないことです。 到着しました。 「各ノードに Java コードを手動でデプロイする必要はありません」などについてはどうでしょうか? それとも、「あなたの Java コード」は SalesPoint に関するものではないのでしょうか?
おそらく何かを見逃したので、もう一度検索を開始し、読んでは検索を繰り返します。 しばらくすると、そのトピックに関するすべてを読み終えたように感じられ、もう新しいことは何もありません。 検索していたら、興味深いコメントを見つけました。
、GridGain Systems のリードアーキテクト、 StackOverflow、2016 年 XNUMX 月:
Model classes are not peer deployed, but you can use withKeepBinary() flag
on the cache and query BinaryObjects. This way you will avoid deserialization
on the server side and will not get ClassNotFoundException.もう一つの信頼できる意見は次のとおりです。 , GridGain Systems 社製品管理ディレクター。
ハブレに関する記事 Denis Magda による XNUMX つの記事を参照しています。 , , 2016年から2017年。 XNUMX 番目の記事で、Denis は、MaintenanceServiceNodeStartup.jar を介してクラスター ノードを開始することを提案しています。 XML 構成およびコマンド ラインで起動を使用することもできますが、その場合は、デプロイされた各クラスター ノードにカスタム クラスを手動で配置する必要があります。
That's it. Start (..) node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.確かに、それだけです。 ここで、この謎のバイナリ形式がなぜだったのかがわかりました。
3.シングルジャー
私の個人的な評価では、Denis が XNUMX 位でした。私見では、入手可能なチュートリアルの中で最も役立つチュートリアルです。 彼の中で Github には、追加のスクワッティングなしでコンパイルできる、クラスター ノードをセットアップする完全に既製のサンプルが含まれています。
同じ方法で実行し、コマンド ライン引数に応じて「データ ノード」または「クライアント ノード」を起動する単一の jar ファイルを取得します。 アセンブリが開始され、動作します。 ゼロデプロイメントは敗北しました。
メガバイトのテスト データから数十ギガバイトの戦闘データへの移行は、バイナリ形式が存在する理由があることを示しました。 ノード上のメモリ消費を最適化する必要があり、ここで BinaryObject が非常に役立つことがわかりました。
4 結論
Apache Ignite プロジェクト ドキュメントの曖昧さに関して最初に受けた非難は正当であることが判明し、2016 年からほとんど変わっていません。 初心者にとって、Web サイトやリポジトリに基づいて機能するプロトタイプを組み立てるのは簡単ではありません。
実行された作業の結果に基づくと、Zero Deployment は機能しますが、それはシステム レベルでのみ機能するという印象でした。 次のようなものです: BinaryObject は、リモート クラスター ノードにカスタム クラスを操作するよう教えるために使用されます。 ゼロ展開 - 内部メカニズム
Apache Ignite 自体がクラスター全体にシステム オブジェクトを配布します。
私の経験が新しい Apache Ignite ユーザーに役立つことを願っています。
出所： habr.com