web-dev-qa-db-ja.com

SQLiteと比較してBerkeley DB SQLはどれくらい速いですか?

Oracleは最近リリースした SQLiteへのBerkeley DBバックエンド です。 「パフォーマンス、同時実行性、スケーラビリティ、および信頼性の向上」のメリットを十分に享受できる数百メガバイトのSQLiteデータベースを使用していますが、Oracleのサイトには測定値がないようですの改善。ここで誰かがいくつかのベンチマークを行いましたか?

44
dan04

私はBDB SQLiteコードのベータ評価に参加しましたが、ハンドルを取得しようとしたのはパフォーマンスの違いでした。この時点では、少なくとも1人がコードを評価し、テストを実行して、得られた数値を確認する(実行中)まで、見つけたものを正確に公開することはできません。ただし、ここで一般化して、BDBはSQLiteよりもパフォーマンスが大幅に向上する場合があると言うことができます。特に、書き込みの同時実行を伴う重い負荷の処理の分野ではそうです。

一般に、「高速」の正しい基準は2つあります。(1)効率:単一プロセスがXYZを実行するのにかかる時間と(2)同時実行性:多くのプロセスが単位時間あたりXYZを実行できる回数。 BDBが対処する主な問題は、同時実行性、つまり大規模なトランザクション処理です。したがって、データベースの内容への書き込みやデータベースの内容の変更を行う多くの同時接続について考えます。

SQLiteは設計上、データベースレベルのロックを使用しているため、一度にデータベースで作業できるライターは最大1人です。したがって、SQLiteのトランザクションレートは同時接続数に応じてほぼ一定に保たれるため、書き込み集中型アプリケーションのスケーラビリティは実際にはその効率によって測定されます(1)。

一方、BDBはページレベルのロックを使用します。これにより、複数のライターがデータベースで同時に作業できるようになります(ただし、別々のページで作業している場合)。したがって、BDBのレートは接続の数とともに増加する可能性があるため、そのスケーラビリティは効率(1)と同時実行性(2)の両方の問題であり、これらは合計することができます。

主に要約すると、(書き込み)同時実行性です。 BDBは、複数のライターがSQLiteよりも多くのTPSをプッシュできます。トランザクションとは、データベースを変更するものを意味します(読み取り専用操作の実際の助けとなるものは何ですか?)。つまり、読み取りの同時実行性(主にSELECTを実行するアプリ)の場合、SQLiteはBDBと直接対決できます。ロックはもはや重要な問題ではないからです。

データセットのサイズについてはわかりません。まだ調べていません。最終的には、どちらもストレージにBツリーを使用します。それぞれの実装に考慮すべき要素があるかもしれませんが、私はそれを調査していません。 SQLiteがデータセットを数百MBと2桁のGBに正常に処理できることを知っています(おそらく、ダーティページマップの実装が変更されたため)。

したがって、特定のデータベースを変更する多くの接続を使用するアプリケーションがあり、ページの競合が比較的低い場合、BDBはパフォーマンスを大幅に向上させることができます。しかし、ページの競合は重要な変数です。制限では、データが単一のページで構成されているBDBデータベースがある場合、ページレベルのロックはデータベースレベルのロックと同等に効果的に縮退するため、そのパフォーマンスはすべてのケースでSQLiteのパフォーマンスと一致します。ひとこと。ただし、BDBのページ数が増えると(そしてページの競合が減るので)、同時接続の数とともに最大TPSが増加し始めます。その時点から、メモリが次の制限要因になります。しかし、それは別の話です。

ところで、私はSQLiteから来た人のためのBDBの使用についての記事を書いている最中です。

記事のリンク:

Oracle Berkeley DB SQL API対SQLite API –技術評価

Oracle Berkeley DB SQL API対SQLite API –統合、利点、違い

56
Mike Owens

それはちょっとロードされた質問です。結果は、ディスクアクセス速度、メモリ内のキャッシュのサイズ、挿入と読み取りの数、ページ分割、同時実行性などによって大きく異なります。

全体として、BerkeleyDBは非常に高速である可能性があります-私は最近、1秒間に40kの挿入を8で実行できる雇用者向けに構築されたデータ分析プラットフォームを設計しましたコアx86システム(同時に、毎秒数千回の読み取りを実行します)、30G範囲のデータセット。これは完全なトランザクション保護を備えていました。

ただし、これは最良のケースでした。受信データと現在バークレーに格納されているものによっては、挿入が毎秒2kまで低下する場合がありました。ディスクI/Oが遅く、キャッシュヒット率が低い場合、または常にDBを拡張していると、ページ分割が発生する場合は、パフォーマンスが大幅に低下します。特定のデータセットのパフォーマンスを向上させるために行うことができる膨大な量のチューニングもあります。

全体としては優れたシステムですが、ドキュメントと知識はかなりスリムです。私は The BerkeleyDB Book を、おそらく現在入手可能な最良のリファレンスとしてお勧めします。

11
Brian Roach

Brianが言及しているBerkeley DB Bookに加えて、次のリソースも役立ちます。

  • Berkeley DBオンラインフォーラムは、ユーザーと製品の開発者の両方から多くの提案を提供できます。 Berkeley DBフォーラム を参照してください。
  • here にあるBerkeley DBのドキュメントセット。特に、リファレンスガイドには、チューニング、パフォーマンス、スループットに関するいくつかのセクションがあります。
7
David Segleau