2

埋め込まれたHSQLDBに約10の平均長の文字列の約1300万行を挿入する必要があるアプリケーションがあります。私は物事を微調整してきました（バッチサイズ、シングルスレッド/マルチスレッド、キャッシュ/非キャッシュテーブル、MVCCトランザクション、log_size /ログなし、への定期的な呼び出しcheckpoint、...）、それでも16コアで7時間かかります、12 GBマシン。

HSQLDBを選択したのは、これらのコアをすべて有効に活用すればパフォーマンスが大幅に向上する可能性があると考えたためですが、自分の決定に真剣に疑問を抱き始めています。

誰かが私に銀の弾丸を見せてもらえますか？

4

4 に答える 4

5

CACHEDテーブルでは、ディスクIOがほとんどの時間を費やしています。同じテーブルに挿入するため、複数のスレッドは必要ありません。パフォーマンスが著しく向上することの1つは、パラメーター化された単一のPreparedStatmentを再利用して、各行挿入のパラメーターを設定することです。

マシンでは、メモリマップドIOに大きなNIO制限を使用することで、IOを大幅に向上させることができます。たとえばSET FILES NIO SIZE 8192。より大きなサイズで効果を得るには、64ビットのJVMが必要です。

http://hsqldb.org/doc/2.0/guide/management-chapt.html

バルクインサートの使用中にIOを削減しSET FILES LOG FALSE、インサートが終了するまでチェックポイントを実行しないようにします。詳細はここで説明されています：

http://hsqldb.org/doc/2.0/guide/deployment-chapt.html#dec_bulk_operations

更新：以下の1600万行の挿入テストでは、1.9ギガバイトの.dataファイルが生成され、平均的な2コアプロセッサと7200RPMディスクでわずか数分かかりました。重要なのは大規模なNIOの割り当てです。

connection time -- 47
complete setup time -- 78 ms
insert time for 16384000 rows -- 384610 ms -- 42598 tps
shutdown time  -- 38109
于 2012-04-24T08:12:08.600 に答える
1

アプリケーションが何をしているかを確認してください。まず、taskmanager（またはOS固有の同等のもの）とvisualvmのリソース使用率を確認します。

悪いパフォーマンスを引き起こすための良い候補：

  • ディスクIO
  • ガベージコレクター
于 2012-04-24T07:29:16.523 に答える
1

H2Databaseは、(構文の互換性を維持しながら) HSQLDB よりもわずかに優れたパフォーマンスを提供する場合があります。

いずれにせよ、ランダム アクセス ディスク I/O を減らすために、ディスクへの同期の遅延を大きくしてみてください。(つまりSET WRITE_DELAY <num>)

INSERT行ごとに 1 つの挿入を行うのではなく、一括ステートメントを実行していることを願っています。そうでない場合は、可能であればそうしてください。

アプリケーションの要件によっては、RDBMS よりもキー値ストアの方が適している場合があります。(定期的に 1.3*10^7 エントリを挿入する必要がありますか?)

主な制限要因は、ディスクへのランダム アクセス操作になります。あなたがしていることはすべて CPU バウンドになるとは思えません。( を見てtop、 と比較してiotopください !)

于 2012-04-24T07:39:13.383 に答える
0

非常に多くのレコードがあるため、NoSQL DB への切り替えを検討できるかもしれません。もちろん、保存する必要があるデータの性質/形式によって異なります。

于 2012-04-24T07:48:38.033 に答える