2

私は単純なバッチ フェッチを使用して、couchdb で更新します。

    int batchSize = 5000;
    String startKey = "";
    List<FrontLineWorker> frontLineWorkers;

    while (true) {
        frontLineWorkers = allFrontLineWorkers.getMsisdnsFrom(startKey, batchSize);

        if (frontLineWorkers.size() < batchSize) break;

        for (FrontLineWorker frontLineWorker : frontLineWorkers) {
            // process record, only updates record
        }

        startKey = frontLineWorkers.get(frontLineWorkers.size() - 1).getMsisdn();
    }

getMsisdnsFrom はカウチ クエリであり、数回後にタイムアウトし始めます。ソファは読み取りが完了したときにのみビューをインデックス付けすることを知っていますが、レコードを更新するだけなので、インデックスには影響しません。また、これは予想される使用法であり、レコードのセットを取得し、次のセットを変更して取得するため、タイムアウトすることはないと思います。

バッチ時間 1000 と 5000 の両方で試しました。

例外メッセージは次のとおりです: スレッド「メイン」での例外 org.ektorp.DbAccessException: java.net.SocketTimeoutException: 読み取りタイムアウト

編集:バッチサイズを100に減らした後は機能しましたが、バッチサイズを大きくした方がよかったでしょう。

4

2 に答える 2

1

これjava.net.SocketTimeoutExceptionはかなり低レベルの例外であり、Javaが読み取りの完了を待機するように、ソケットタイムアウト値を増やす必要があるように思われます。

djcも正しいです。すべての更新により、影響を受けるノードのインデックスが再作成されますが、バッチサイズ100でタイムアウトを回避できるという事実は、インデックスの再作成が重大な問題を引き起こしていないことを意味します。

問題は、バッチサイズがソケットタイムアウトに対して大きすぎるか、最初のサイズを減らすか、2番目のサイズを増やすことです。

于 2012-07-17T16:54:52.157 に答える
0

ドキュメントを更新すると、ドキュメントのインデックスが再作成されます。

于 2012-07-17T12:27:05.357 に答える