Oracle は最近、SQLite への Berkeley DB バックエンドをリリースしました。私はたまたま数百メガバイトの SQLite データベースを持っており、「パフォーマンス、同時実行性、スケーラビリティ、および信頼性の向上」の恩恵を受けることができますが、Oracle のサイトには改善の測定値がないようです。ここでベンチマークを行った人はいますか?
3 に答える
私は BDB SQLite コードのベータ評価に参加しましたが、把握しようとしたことの 1 つはパフォーマンスの違いでした。この時点で、少なくとも 1 人の他の人が私のコードを評価し、テストを実行し、得られた数値を確認するまで、私が見つけたものを正確に公開することはできません (これは行われています)。ただし、ここで一般化して、BDB が SQLite よりもパフォーマンスを大幅に向上させるケースがあると言えます。特に、同時書き込みを伴う重い負荷を処理する領域で顕著です。
一般に、「高速」の正しさには 2 つの尺度があります。(1) 効率: 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 を使用することについての記事を書いているところです。
記事リンク:
それはちょっと負荷の高い質問です。結果は、ディスクのアクセス速度、メモリ内のキャッシュのサイズ、挿入と読み取りの数、ページ分割、同時実行などによって劇的に異なります。
全体として、BerkeleyDBは非常に高速です。私は最近、8 コア x86 システムで 1 秒あたり 40k の挿入を実行できる (同時に、1 秒あたり数千回の読み取りを実行できる) 雇用主向けのデータ分析プラットフォームを設計しました。 30G 範囲のデータセット。これは完全なトランザクション保護を備えていました。
ただし、これが最良のケースでした。受信データと現在 Berkeley に保存されている内容によっては、挿入が 1 秒あたり 2k まで低下する場合がありました。ディスク I/O が遅く、キャッシュ ヒット率が低い場合、または DB を常に拡張しているためにページ分割が発生している場合、パフォーマンスが大幅に低下します。特定のデータセットのパフォーマンスを向上させるために実行できる膨大な量のチューニングもあります。
全体的には優れたシステムですが、ドキュメントと知識はかなり貧弱です。The BerkeleyDB Bookは、おそらく現在入手できる最良のリファレンスとしてお勧めします。
Brian が言及している Berkeley DB Book に加えて、次のリソースも役立つ場合があります。
- Berkeley DB オンライン フォーラムでは、製品のユーザーと開発者の両方から多くの提案を得ることができます。Berkeley DB フォーラムを参照してください。
- Berkeley DB ドキュメント セットは、ここにあります。特に、リファレンス ガイドには、チューニング、パフォーマンス、およびスループットをカバーするセクションがいくつかあります。