2016-04-22 19 views
3

外部キー制約のあるテーブルに接続されているキャッシュでライトビハインドを使用しようとすると、問題が発生します。一見すると、write-behindメカニズムは決定的な順序で更新/挿入を実行するのではなく、各キャッシュごとに収集されたすべての変更を未知の順序で連続的にプッシュしようとしています。しかし、テーブルに外部キーがあるので、操作の順序は重要です。そのため、親オブジェクトは最初に挿入/更新し、それ以降は子を挿入する必要があります(それ以外の場合は外部キー違反がDBからスローされます)。Apache Igniteで外部キーを使用してWrite-behindを使用する方法

現行の実装では試行錯誤的にこの問題を回避しようとしています(org.apache.ignite.cache.store.jdbc.CacheAbstractJdbcStore:888)。これは定期的にキャッシュの変更を繰り返し再試行することを意味します。制約違反が発生しました。したがって、「親」キャッシュが最初にフラッシュされるまで、「子」キャッシュは定期的にフラッシュを再試行します。これにより最終的にはデータがDBに取り込まれますが、複雑な階層テーブルの場合は、正しい順序が見つかるまで失敗します。その結果、パフォーマンスが低下し、DBが不必要に砲撃されます。

この問題を回避する方法についてご意見はありますか?

CacheAbstractJdbcStoreは一見各挿入/更新操作のための新しいプリペアドステートメントを開いているので、最初は、私はライトスルーにしようとしていたが、それは非常に悪いパフォーマンスとなった。)ため、後書きで

答えて

2

各ノードが独立して非同期に書き込むため、ストアの更新は未定義です。外部キーの制約がある場合は、ライトスルーを使用する必要があります。

ライトスルーパフォーマンスに関しては、CacheAbstractJdbcStoreは設定可能なDataSourceで動作するため、毎回新しい接続を開くかどうかは実装に依存します。いくつかのプールされたバージョンを使用する場合、これは起こりません。

関連する問題