5

私はデータベースを作成しており、最初にプロトタイピングとベンチマークを行っています。私は、オープンソースで商用無料の組み込み可能なリレーショナル Java データベースである H2 を使用しています。現在、どの列にもインデックスを作成していません。

データベースが約 5GB に拡大した後、バッチ書き込み速度は 2 倍になりました (書き込み速度は元の速度の 2 倍に低下しました)。私は新鮮でクリーンなデータベースでミリ秒あたり約 25 行を書き込んでいましたが、現在は 7GB で約 7 行/ミリ秒を書き込んでいます。私の行は、short、int、float、および byte[5] で構成されています。

データベースの内部構造や、H2 がどのようにプログラムされているかについても、私はあまり知りません。また、これは私がテストした他の DBMS の問題であるため、H2 を悪口を言っているわけではありません。

インデックス作成のオーバーヘッドがない場合、このようにデータベースの速度を低下させる要因は何ですか? 主にファイルシステム構造と関係がありますか? 私の結果から、Windows XP と ntfs がファイルを処理する方法により、ファイルが大きくなるにつれてファイルの末尾にデータを追加するのが遅くなると思います。

4

9 に答える 9

2

これはほぼ正しいように聞こえます。通常、データベースのパフォーマンスは大幅に低下します。これは、データをメモリに保持できなくなり、操作がディスク バウンドになるためです。通常の挿入操作を使用していて、大幅なパフォーマンスの向上が必要な場合は、H2 がサポートしている場合は何らかのバルク ロード API を使用することをお勧めします (Oracle sqlldr、Sybase BCP、Mysql 'load data infile' など)。このタイプの API は、多くのデータベース サブシステムをバイパスして、データをデータ ファイルに直接書き込みます。

于 2008-10-11T16:26:40.020 に答える
2

データベースが大きくなるにつれて挿入が複雑になる要因の 1 つは、テーブル上のインデックスの数と、インデックスが B ツリーなどである場合のインデックスの深さです。やるべきことは他にもあります。インデックス ノードを分割している可能性があります。または、たとえば、5 レベルの B ツリーから 6 レベルの B ツリーに移動しただけである可能性があります (または、より一般的には、 N から N+1 レベルまで)。

別の要因として、ディスク容量の使用が考えられます。クックド ファイルを使用している場合 (ほとんどの場合、これはほとんどの人にとって通常の種類です。一部の DBMS は Unix で「生ファイル」を使用しますが、組み込みシステムがそうする可能性は低いです。そうするように指示する必要があるため、そうなったかどうかはわかります)、より大きなテーブルがディスク全体で断片化され、パフォーマンスが低下している可能性があります。

問題が SELECT のパフォーマンスにある場合は、システムのパフォーマンスに影響を与える他の多くの要因が存在する可能性があります。

于 2008-10-10T22:15:24.013 に答える
1

ほとんどのデータベースでは、データベースファイルへの追加は、ファイルを事前に拡張してから行を追加するよりも明らかに時間がかかります。H2がファイルの事前拡張をサポートしているかどうかを確認します。

于 2008-10-10T21:47:24.990 に答える
1

これは、可変幅フィールドが原因である可能性が最も高いです。H2 がこれを許可するかどうかはわかりませんが、MySQL では、すべての固定幅フィールドでテーブルを作成し、それを固定幅フィールド テーブルとして明示的に宣言する必要があります。これにより、MySQL は挿入を行うためにデータベース ファイル内のどこに移動する必要があるかを正確に計算できます。固定幅のテーブルを使用していない場合は、テーブル全体を読み取って最後の行の終わりを見つける必要があります。

データの追加 (正しく行われた場合) は O(n) 操作です。ここで、n は書き込まれるデータの長さです。ファイルの長さに依存しません。それを簡単にスキップするためのシーク操作があります。

于 2008-10-10T21:34:21.053 に答える
0

もう 1 つの原因は、データベース全体がメモリに保持されているか、またはレコードを格納する場所を見つけるために OS が多くのディスク スワッピングを行う必要があるかどうかです。

于 2008-10-10T21:42:43.440 に答える
0

特に、通常のハードディスクを備えた通常のPCでデータベースを実行している場合（つまり、超高速ハードドライブを備えたサーバーなどではないことを意味します）、I / Oのせいにします。

于 2008-10-10T21:46:02.903 に答える
0

7G データファイルに H2 を使用することは、技術的な観点からは間違った選択です。あなたが言ったように、埋め込み可能です。非常に多くのデータを保存する必要がある場合、どのような「組み込み」アプリケーションがありますか。

于 2009-10-06T20:03:54.847 に答える
0

多くのデータベース エンジンは、更新ごとに暗黙的な整数の主キーを作成するため、インデックスを宣言していなくても、テーブルにはインデックスが作成されます。これが要因かもしれません。

于 2008-10-11T22:00:00.567 に答える
0

増分コミットを実行していますか? H2 は ACID 準拠のデータベースであるため、インクリメンタル コミットを実行していない場合は、なんらかの偶発的な障害 (停電など) またはロールバックが発生した場合に削除をロールバックできるように、ある種の REDO ログが存在します。

その場合、REDO ログが大きくなり、メモリ バッファがオーバーフローし、REDO ログと実際のデータをディスクに書き出す必要が生じ、I/O オーバーヘッドが増える可能性があります。

于 2013-01-03T03:03:41.947 に答える