3

Spring MVC アプリケーションの動作を再考しています。データベースからデータをプルする(Java8 ストリーム) か、データベースにデータをプッシュ(リアクティブ/オブザーバブル) させ、バックプレッシャーを使用して量を制御する方がよいかどうかです。

現在の状況：

  1. User最新の 30 件の記事をリクエストする
  2. Serviceデータベース クエリを実行し、30 個の結果をList
  3. Jacksonを繰り返し処理しList、JSON 応答を生成します

なぜ実装を切り替えるのですか？

これらの 30 個のオブジェクトを常にメモリに保持しているため、かなりメモリを消費します。アプリケーションは一度に 1 つのオブジェクトを処理するため、これは必要ありません。ただし、アプリケーションは1 つのオブジェクトを取得して処理し、破棄して次のオブジェクトを取得できる必要があります。

Java8 ストリーム? （引く）

これjava.util.Streamは非常に簡単です。は、バックグラウンドでデータベース カーソルを使用する をService作成します。の 1 つの要素の JSON 文字列を書き込むStreamたびに、次の要素を要求し、データベース カーソルをトリガーして次のエントリを返します。JacksonStream

RxJava / リアクティブ / オブザーバブル? （押す）

ここでは逆のシナリオがあります。データベースはエントリごとにプッシュする必要があり、メソッドが呼び出されるJacksonまで各要素の JSON 文字列を作成する必要があります。onComplete

つまり、Controllerは にService:をくださいObservable<Article>。次にJackson、処理できる限り多くのデータベース エントリを要求できます。

相違点と懸念事項:

次のデータベース エントリを要求してから取得/処理するまでにStreamsは、常に多少の遅延があります。これにより、ネットワーク接続が遅い場合、または応答を満たすために大量のデータベース要求を行う必要がある場合、JSON 応答時間が遅くなる可能性があります。

そこを使用RxJavaすると、常に処理可能なデータが必要になります。また、それが多すぎる場合は、バックプレッシャーを使用して、データベースからアプリケーションへのデータ転送を遅くすることができます。最悪のシナリオでは、バッファ/キューには要求されたすべてのデータベース エントリが含まれます。次に、メモリ消費量は、List.

なぜ私は尋ねているのですか / 私は何を求めているのですか?

  • 私は何を取りこぼしたか？他に長所/短所はありますか？

  • 各データベース要求/応答間に常に (短い) 遅延がある場合、(特に) Spring Data TeamStreamがデータベースからの応答をサポートするように API を拡張したのはなぜですか? これにより、要求されたエントリが大量になると、顕著な遅延が発生する可能性があります。

  • RxJavaこのシナリオでは (または他のリアクティブな実装) を使用することをお勧めしますか? または、欠点を見逃しましたか？

4

1 に答える 1

2

基礎となるデータベース エンジンのフェッチ サイズについて話しているようです。

1つに減らすと（一度に1行ずつフェッチして処理する）、はい、リクエスト時にスペースを節約できます...

しかし、通常は適切なチャンク サイズを設定することは理にかなっています。小さすぎると、高価なネットワーク ラウンドトリップが大量に発生します。チャンク サイズが大きすぎると、メモリが不足したり、フェッチごとに遅延が発生したりするリスクがあります。したがって、これは妥協であり、適切なチャンク/フェッチ サイズは特定のユース ケースによって異なります。

リアクティブなアプローチかどうかについては、関係ないと思います。RxJava や Cassandra と同様に、非同期の結果セットから Observable を作成できます。一度にいくつのアイテムをフェッチしてプッシュするかは、クエリ (構成) 次第です。

于 2016-06-17T23:27:30.093 に答える