oracle berkeley db sql apiとsqlite apiの比較 - 統合 ......oracle berkeley db sql apiとsqlite...

Oracleホワイト・ペーパー

2010年10月

Oracle Berkeley DB SQL APIとSQLite APIの

比較 - 統合、利点、および相違点

Oracle Berkeley DB SQL APIとSQLite APIの比較 - 統合、利点、および相違点

概要 ..................................................................................................................................... 1

Berkeley DBのアーキテクチャ ........................................................................................... 2

Berkeley DBの利点 ............................................................................................................. 3

Berkeley DBの相違点 ......................................................................................................... 5

構成 ................................................................................................................................ 6

競合処理 ........................................................................................................................ 8

チューニング ................................................................................................................. 9

結論 .................................................................................................................................... 11


1

概要

Oracle Berkeley DB 11g Release 2は、SQLiteへの完全な互換性を持つSQL APIを提供することで、

理想的なテクノロジーの組合せを実現しています。この製品は、オープンソースと商用製品のコラ

ボレーションが双方に価値をもたらすことを示す良い例です。Berkeley DBの開発者は、実績ある組

込みSQLエンジンとC APIを使用して、アプリケーション開発をより簡単に実行できるようになりま

す。また、SQLiteユーザーには、高い同時実行性を実現するために、土台から構築され、業界で支

持された強力なストレージ・エンジンを使用する選択肢が提供されます。これには、組込みレプリ

ケーションやホット・バックアップなどの強力な機能が含まれています。これら2つのテクノロジー

を組み合わせることで非常に高い柔軟性が得られるため、組込みアプリケーションから大規模なト

ランザクション処理アプリケーションまでの非常に幅広いアプリケーションで同じSQL APIを使用

できるようになりました。

SQLiteを使用して作成されたコードは、ほとんどの場合、簡単にBerkeley DBのSQL APIを使用する

ように移植できます。ただし、何事もそうであるように、留意すべき技術的な注意事項がいくつか

あります。このホワイト・ペーパーでは、SQLiteを使い慣れており、新しいBerkeley DBの試用を検

討している開発者向けに、Berkeley DBの利点と潜在的な問題に対する考察を提供します。


2

Berkeley DBのアーキテクチャ

最初に考慮すべきは、Berkeley DBのSQLインタフェースが何であるかということです。MySQLを使

用した経験がある開発者なら、MySQLに対するInnoDBのように、この新しい機能がSQLiteに対する

代替のバックエンド・ストレージ・モジュールになると考えたくなるかもしれません。しかし、そ

うではありません。オラクルは、Berkeley DB向けの代替フロントエンドとして、SQLiteと互換性の

あるSQL APIを開発しました。つまり、SQLiteの代替バックエンドが提供されるのではなく、Berkeley

DBの代替フロントエンドが提供されるということです。ここで基準の枠組みとなるのは、Berkeley

DBです。

オラクルはSQLiteのソース・コードを取得し、ストレージ・レイヤーからすべてのコードを抜き出し

てBerkeley DBに移植しました。これはセマンティクスに過ぎないという主張があるかもしれません

が、これら2つのライブラリを組み合わせることで、いくつかの独自機能が提示されています。簡単

に説明すると、オラクルがSQLiteのソース・コードを取得して、あたかもページャとBツリー・レイ

ヤーをBerkeley DBで完全に置換したようなものです。図1 "Berkeley DBの統合"に示します。

図1 Berkeley DBの統合

その結果として、頭の中では同じSQL APIを使用して作業していても、根底ではもう同じデータベー

ス・ファイルを扱ってはいません。ディスク上のデータベース表現は完全に異なり、Berkeley DBデー

タベースに変わっています。新しいデータベース（例："foods.db"）を作成するとすぐに、SQLiteで

は認識されない、完全に別のデータベース・ファイルが作成されます。


3

処理対象になっているのはBerkeley DBデータベースであり、すべての標準Berkeley DBユーティリ

ティ（db_checkpoint、db_hotbackup、db_load、db_dump、db_recoverなど）を使用できます。これら

のユーティリティのほとんどはオプションであり、確実に理解しておく必要のあるユーティリティ

は"dbsql"です。これは、"sqlite"コマンドライン・ユーティリティに相当するBerkeley DBのユーティ

リティであり、Berkeley DBを使用して作成されたSQLデータベース上で使用できます。

Berkeley DBの利点

現在SQLiteを使用している場合、Berkeley DBへの切替えを検討する理由は何でしょうか。その判断

に影響する可能性のある操作上の違いが、2つの製品間には多数存在します。もっとも重要な考慮事

項の1つはパフォーマンスです。多くのユースケースで、Berkeley DBはSQLiteよりも大幅に優れたパ

フォーマンスを実現しています。パフォーマンス・テストでのもっとも一般的な指標は、待機時間

とスループットです。これら2つの指標は次の項目と大いに関連しています。

効率 - 1つのプロセスが特定の処理を実行するためにかかる時間

同時実行性 - 一定の単位時間当たりに実行可能な同時操作の数

SQLiteは、"小さいフットプリントで最大の利便性と簡便性を実現する、移植性の高い効率的なSQL

ストレージ・エンジン"となることを目的として設計されています。一番の目的は、高度な同時実行

性よりもシンプルなストレージにあります。パフォーマンスに影響を与える設計上の最大のトレー

ドオフは、SQLiteがデータベース・レベル・ロックを使用することです。データベース・レベル・ロッ

クでは、書込み操作中にデータベース・ファイルへ同時アクセスできますが、一度にアクティブに

なる書込みは最大でも1つのみです。その結果として、同時接続（スレッド、プロセス、コアあたり

のCPU）数が増えた場合でも、SQLiteのトランザクション速度はほぼ一定の値にとどまります。同時

実行性の高い書込み集中型アプリケーションでのSQLiteのパフォーマンスは、1つのスレッドに限定

されます。

Berkeley DBは最初から処理効率とスケーラビリティを目的に構築されています。重要な要素の1つは

同時実行性であり、特に同時実行性の高い書込み集中型の大規模トランザクション処理アプリケー

ションを対象としています。Berkeley DBは、データベース・レベル・ロックの代わりにきめ細かい

（ページ・レベル）ロックを使用しています。このため、Berkeley DBは1つのデータベースで一度に

複数の同時処理を実行できます（各処理の対象が別々のページである場合）。また、同時実行性を

向上するためのさらなる最適化として、Berkeley DBは"Multi-Version Concurrency Control（MVCC）"

をサポートしています。MVCCを使用しない場合、同じデータベース・ページ上の読取り処理によっ

て書込み処理がブロックされます。MVCCを使用すると、書込みがロックを要求した時点でページ

がコピーされ、読取り処理で一貫性が維持されます。こうすることで、書込み処理は変更をコミッ

トするために読取りトランザクションを待つ必要がなくなります。このような最適化によってス

ループットが向上し、処理上の待機時間が短縮されるため、Berkeley DBのSQLストレージに対する

同時実行性がはるかに高くなります。

このため、アプリケーションで多数の同時接続を使用してデータベースを変更しており、変更処理

を行うスレッド間でのページ競合が比較的少ない場合、Berkeley DBは複数の書込みに対してSQLite

よりも多くのトランザクションを1秒あたりに処理することで、大幅なパフォーマンス向上を実現し

ます。ただし、データがまれにしか（または、まったく）変更されないアプリケーションでは、SQLite

とBerkeley DBのロック・オーバーヘッドは同程度であり、ほぼ同じパフォーマンスになります。


4

より一般的なユースケースは、作成、読取り、更新、および削除という各種操作が同時に実行され

るアプリケーションです。このようなケースでBerkeley DBが持つパフォーマンス上の利点を最大活

用するには、ページ競合の可能性について理解することが重要です。重要な考慮事項の1つは、ペー

ジ競合に対するBerkeley DBのデータベース・ロック統計（dbsqlの".stat"コマンドまたはdb_statコマン

ドライン・ツールから参照可能）です。大半の書込みが同時に同じページに対して実行されている

場合、ロック競合が増加し、スループットは悪化します。基本的に、すべての書込みがまったく同

じページをめぐって競合するようなBerkeley DBデータベースでは、ページ・レベル・ロックによる

メリットが得られないため、SQLiteと同等のパフォーマンスになります。全員が同時に同じデータに

アクセスするため、アクセスを順番に実行する必要があるからです。一般には、データベース・ファ

イルのサイズが大きくなると、含まれる個別ページの数も増えるため、ページ競合の可能性は低下

します。このため、1秒あたりの最大トランザクション数（TPS）も同時接続（スレッドやプロセス）

数とともに増加します。

同時実行性が向上するにつれて、次に直面する可能性があるボトルネックはメモリ・アクセスであ

り、キャッシュ効率が次の制約要因になります。

次の簡単なテスト・シナリオは、このようなパフォーマンスの問題を示すものです。SQLiteとBerkeley

DBのスループットを観察する間に、書込み処理の数は10から100へと変化します。トランザクション

は非常に単純であり、次のようなレコードのランダムUPDATEで構成されています。

BEGIN IMMEDIATE;

UPDATE test SET x=random() where id=ABS(random(10000));

COMMIT;

このトランザクションの目的はロック競合とオーバーヘッドを測定することにあるため、単純なSQL

であるほどこのテストに適しており、もっとも単純なUPDATEで十分です。

さらに、このテストでは、それぞれの書込みが理論上は異なるページに対して処理を行う（したがっ

て、Berkeley DBではページ競合がほとんど、またはまったく発生しない）ように設計されています。

このため、"test"という名前のダミー表を作成し、1つのBerkeley DBデータベース・ページとほぼ同

じサイズのレコードを10,000レコード挿入しました。各レコード（または行）に個別のデータベース・

ページが必要になるため、2つの書込みが同じタイミングでランダムに同じレコードを選択または更

新する（同じページをロックする）確率は非常に低くなります（10,000分の1）。

このテストの結果から、このような条件の下で、20以上の同時接続に対して、Berkeley DBは常に

SQLiteの約8倍（800%）の速度で処理を実行することが分かりました（図2 "ワークロードと同時接続

数の比較"を参照）。


5

図2 ワークロードと同時接続数の比較

この理由は、このケースがBerkeley DBにとって最適なケースであるためです。それぞれの行が個別

のページ上にあるため、データベース内のすべての書込みが異なるページを変更しています。これ

は実質的に、行レベル・ロックによく似ています。ここでは8倍のパフォーマンス向上が達成されま

したが、テスト・ケースとして最高条件のシナリオが作成されているため、これは理論上の上限値

として認識する必要があります。現実には、アプリケーションはしばしば小さなデータのサブセッ

トに対して処理を実行し、"ホット・スポット"を形成する傾向があるため、上記の結果が常にあては

まるとは限りません。このような競合ホット・スポットが発生すると、パフォーマンスは最善のケー

スから下がり始め、書込み処理同士がホット・スポット内の同一ページを争う割合に応じて低下し

ます。これらのホット・スポットが更新処理の60～70%を占めるとすると、同時実行性の高い書込み

集中型アプリケーションのパフォーマンスは平均でSQLiteの2～3倍となると考えられるかもしれま

せん。実際のパフォーマンスは、アプリケーション内に競合を引き起こすデータ・レイアウトやデー

タ・アクセス・パターンによって異なります。しかし、同時負荷のかかるほとんどのケースで、Berkeley

DBの書込みスケーラビリティがSQLiteを上回ることは明らかです。アプリケーションごとにベンチ

マーク評価を実施することを推奨します。

Berkeley DBの相違点

Berkeley DBのSQL APIはSQLiteに対する互換性を持っており、SQLiteのドロップイン置換品として利

用できます。具体的には、1つのヘッダー・ファイルを追加（既存のsqlite3.hに加えてdb.hを追加）し、

SQLiteライブラリではなくBerkeley DBライブラリ（db-5およびdb_sql-5）に関連付けます。コンパイ

ルとリンクを再実行すれば完了です。SQLiteを使用していたアプリケーションが移植され、Berkeley

DBを使用するようになります。

しかし、SQLiteの代わりにBerkeley DBを使用するようにコードを移植することは簡単でも、いくつ

かの微妙な違いがあることを本番アプリケーションへの配置前に知っておく必要があります。両方

のシステムで使用されるAPIは同じですが、操作上の大きな違いがいくつかあります。根本的に

SQLiteを使用していないことを認識する必要があります。APIの互換性は、通信プロトコルのみを対

象としています。実際に使用しているのはSQLiteライブラリではなくBerkeley DBライブラリであり、

まったく別物です。


6

したがって、考え方を少し変えてBerkeley DBの要素を考慮に入れ、類似点と相違点に留意する必要

があります。若干の知識が必要になる3つの領域は、次のとおりです。

構成

競合処理

チューニング

構成

前述のとおり、処理対象となるディスク上のデータベース・ファイルは同じではありません。SQLite

とはいくつかの大きな違いがあります。SQLiteが稼働する際、1つのデータベース・ファイル（例：

foods.db）と2番目のジャーナル・ファイル（例：foods.db-journal）（トランザクションがオープンし

ている間）が使用されます。Berkeley DBは、1つのデータベース・ファイル（SQLiteとはまったく異

なるバイナリ形式）と"環境"ディレクトリと呼ばれるものを使用します。次に、Berkeley DB SQL API

ドキュメントから抜粋した内容を記載します。

リソース（データ、共有キャッシュ、ロック、トランザクション・ログ）を管理するため、Berkeley

DBは通常、Berkeley DB環境と呼ばれるディレクトリを使用します。Berkeley DBのSQLインタフェー

スと一緒に使用すると、共有キャッシュやきめ細かいロックの実装に必要な情報やログ・ファイル

が環境内に格納されます。

一定の類似性を維持するため、Berkeley DBは環境ディレクトリの名前としてSQLiteのジャーナル・

ファイル名を使用します。このため、Berkeley DBバージョンのfoods.dbに対して、foods.db-journalと

いう名前の環境ディレクトリ（ファイルではありません）が関連付けられます。一時的なSQLiteジャー

ナルとは異なり、永続性を持つBerkeley DB環境はデータベースにとって不可欠な部分です。データ

ベースをバックアップする際も、関連付けられた環境をバックアップする必要があります。実際、

もっとも良い方法はdb_hotbackupユーティリティを使用することです（またはBerkeley DB

Programmer's Reference GuideのDatabase and log file archivalの項を参照）。これは構成設定のためだけ

でなく、データベース・リカバリのために不可欠です。環境について言えることは数多くあります

が、言及すべきもっとも重要な事項はおそらく、ログ・ファイルとオプションのデータベース構成

ファイルの2つでしょう。ログ・ファイルは単純なものであり、コミットされたすべてのトランザク

ションのレコードが格納されています。壊滅的な障害（例：システム・クラッシュ）が発生した場

合、ログ・ファイルを使用することでデータベースを一貫した状態に戻すことができます。リカバ

リを実行する場合は、次のとおりにdb_recoverユーティリティを使用します。

$ db_recover -h <some-path-to-foods.db-journal>

または、環境ディレクトリ内から引数なしでdb_recoverを実行しても、同じ処理が実行されます

（"foods.db"データベース・ファイルと"foods.db-journal"の両方が同じディレクトリにある場合）。

それぞれのデータベースに対して、環境ディレクトリ内にDB_CONFIGという構成ファイルを任意で

作成できます。上記例では、"foods.db-journal/DB_CONFIG"というファイル名になります。このファ

イルを使用すると、特定の設定を調整したり、データベースをチューニングしたりすることができ

ます。指定できる設定は数多くありますが、必要になるのはごく少数でしょう。次に示すのは、負

荷が高い場合に有効な設定です。


7

# Don't set these, use SQLite PRAGMA's

# set_flags DB_TXN_WRITE_NOSYNC

# set_cachesize 0 2147483648 1

mutex_set_max 1000000

set_tx_max 500000

set_lg_regionmax 524288

set_lg_bsize 4194304

set_lg_max 20971520

set_lk_max_locks 10000

set_lk_max_lockers 10000

set_lk_max_objects 10000

set_lg_xxxパラメータはログ・ファイルの設定に関連しており、set_lk_xxxパラメータはロック・サブ

システムに関連するパラメータです。set_lg_bsizeパラメータはパフォーマンスに影響を与えるパラ

メータであり、ログ・データを格納するメモリ領域を定義します。この値が大きければ大きいほど、

事前書込みロギング（WAL）データをディスクに書き込まなくても、トランザクションをより長く

実行できます。前述のテストではこのテクニックが使用されており、set_lg_bsizeの値を10倍に増や

し、ログ・バッファ・サイズを4倍にすることで、ロック設定が調整されています。

よく使用されるもう1つの重要なパラメータはset_tx_maxであり、ドキュメントでは次のように定義

されています。

環境でサポートされるアクティブ・トランザクションの最大数を設定します。この値によって、基

盤となる共有メモリ領域のサイズが制限されます。最終的な親トランザクションがコミットまたは

強制終了されるまで、子トランザクションもアクティブとして数える必要があります。

75から100の同時接続が全面的に実行されている場合、この値をデフォルトよりも大幅に高く設定す

る必要があります。ほとんどのアプリケーションでは、デフォルト値で十分です。データベースの

負荷が高い場合は、DB_CONFIGファイルのリファレンスを読み、データベースのチューニング方法

について学習することを推奨します。

注：一部のパラメータを有効にするには、環境を再作成する必要があります。実行するには、アプ

リケーションを停止してdb_recoverを実行します。


8

競合処理

SQLiteに関する重要かつ複雑なトピックに、複数の接続を処理する際のロック・モデルとトランザク

ションの正しい開始方法があります。このトピックだけで独立した記事が作成できますが、ここで

は大まかな動作の要点を説明します。SQLiteでは、同じデータベース上で複数の接続（プロセスやス

レッドなど）を処理する場合、処理内容に応じて、BEGIN IMMEDIATEやBEGIN EXCLUSIVEなどの

トランザクション・セマンティクスに注意を払う必要があります。これらに注意しない場合、デッ

ドロックが発生する可能性があります。

Berkeley DBでは、処理はずっと簡単です。あらゆるケースで必要になるのはBEGINのみです。デッ

ドロックの検出はBerkeley DBによって自動的に実行されます。接続がデッドロックに陥ると、

Berkeley DBからSQLITE_LOCKEDが返されるため、問合せを再実行するだけで済みます。しかし、

このような簡単さにはトレードオフがつきまといます。

さまざまな面で、Berkeley DBの動作モードはSQLiteの"共有キャッシュ・モード"によく似ています

が、このモードは、デフォルトのトランザクションおよびロック・セマンティクスから大きく逸脱

しています。しかし、それでもまだSQLiteの動作を正確に表してはいません。一番の違いは、Berkeley

DBがデータベース競合を処理する方法にあります。SQLiteは設計上、非同期/ノンブロッキング動作

に適していますが、Berkeley DBはその正反対です。SQLiteで非同期やノンブロッキングとなりがち

な動作が、Berkeley DBではそうならない可能性があります。SQLiteで問合せを実行すると、実行で

きるかどうかがすぐに分かります。データベースがブロックされている場合は"ビジー"が返され、操

作を再試行するよう通知されます。次の例について考えてみましょう。

sql = "update foods set name='JujyFruit' where name like 'Jujy%'";

sqlite3_prepare(db, sql, (int)strlen(sql), &stmt, &tail);

rc = sqlite3_step(stmt);

if(rc != SQLITE_DONE)

{

fprintf(stderr, "Error¥n");

}

sqlite3_finalize(stmt);

sqlite3_finalize(stmt);SQLiteでは、 "rc"としてSQLITE_BUSYが返される可能性はありますが、

sqlite3_step()コールがブロックされることはありません。データベース・レベルのロックによってア

クセスがシリアライズされない限り、このコールは成功します。ロックがある場合はすぐに通知が

返され、そこから何を実行するかはユーザー次第です。

反対に、Berkeley DBでSQLITE_BUSYが返されることはありません。SQLITE_BUSYが返されないだ

けでなく、ビジー・ハンドラが実行されることもありません（あらかじめ登録してある場合）。Berkeley

DBには（少なくとも、デフォルトの動作モードでは）ビジーという概念がありません。なぜなら、

SQLiteにおける"ビジー"はデータベースがロックされていることを意味するためです。したがって、

sqlite3_step()メソッドはどのような場合も常に最後まで実行され、例外的にデッドロックが発生した

場合はSQLITE_LOCKEDが返されます。


9

SQLiteでは、ロックによって邪魔された場合でもコールの実行は続けられます。Berkeley DBでの違

いはこのコールがブロックされることです。これには良い面と悪い面があります。良い面は、コー

ルが実行されるため、すでに指摘されたようなデッドロックについて心配する必要がないことです。

悪い面は、ユーザーが望んでいるかどうかに関係なく、ロックの解除と問合せの完了にどれだけ時

間がかかっても、スレッドがこれを待ってしまうことです。つまり、別のことを実行するという選

択肢は提示されていないため、問合せが完了するまでこの処理にかかりっきりになります。優先順

位によって異なるスレッドや動作がある場合も、優先順位の低い処理を強制終了することはできま

せん。また、優先順位の高い処理が、優先順位の低い処理や長時間処理の実行を待たざるを得ない

可能性もあります。ただし、データベース・レベルでデータベースの動作を変える方法はあります。

DB_CONFIGファイルを使用して、次のようにDB_TXN_NOWAITフラグを設定します。

set_flags DB_TXN_NOWAIT 1

こうすることで、APIコールがブロックされずにSQLITE_BUSYが返され、SQLiteの動作が正確に再

現されます。

チューニング

パフォーマンスと永続性の間には、常に微妙なバランスがあります。すべてのオプションを理解す

ると、アプリケーションに両方の利点をもたらすことができます。SQLiteまたはBerkeley DBのいず

れかを使用する場合に知っておくべき重要なキャッシュ関連の構成変数が2つあります。それは、

キャッシュ・サイズと同期設定です。

Berkeley DBでは、既存のSQLiteプラグマを類似したBerkeley DB設定に関連付けることで、（通常は

DB_CONFIGファイル内で設定される）多数の構成パラメータをSQLから設定できるようにしていま

す。もっとも重要な2つのパラメータであるキャッシュ・サイズと同期設定は、CACHE_SIZEプラグ

マとSYNCHRONOUSプラグマを使用して設定できます。

Berkeley DBのキャッシュはSQLiteと非常によく似ており、最近読み取られたページと、トランザク

ションで使用されて変更された（ダーティ）ページをキャッシュするために使用されるメモリ領域

です。トランザクションによってデータが変更されると、影響を受けたページがキャッシュに格納

されます。トランザクションが完了した（コミット）時点で、ダーティ・ページへの変更はログ・

ファイルに書き込まれ、後からチェックポイント中にデータベースに書き込まれます。キャッシュ

が小さすぎるとダーティ・ページでいっぱいになり、ディスク・ストレージに移動しなければなら

なくなります。この処理には非常に時間がかかります。このため、すべての変更されたページと、

よく読み取られるページ（作業セット）を格納するために十分な大きさのキャッシュを構成するこ

とが、パフォーマンスの最適化につながります。

注：キャッシュ・サイズはDB_CONFIGファイルとプラグマの両方で設定できますが、DB_CONFIG

での設定はバイト単位で定義される一方で、プラグマでの設定はページ単位で定義されていること

を認識する必要があります。

同期設定フラグは、トランザクションがコミットされた時点でのログ・バッファ内のログ・レコー

ドの処理方法を制御します。ログ・バッファは、データベースを変更する際に最初に変更がコミッ

トされる場所であり、一番のボトルネックはディスクI/Oを伴うことです。同期設定フラグには、

DB_TXN_WRITE_NOSYNCとDB_TXN_NOSYNCの2つの任意設定があります。


10

デフォルト設定はもっとも慎重な設定であり、完全な永続性が提供されます（上記テストで使用さ

れたものと同じ設定、DB_TXN_SYNC）。ここで、ログ・バッファはログ・ファイルに書き込まれ、

ログ・ファイルは"fsync"（または同等の機能）を使用してフラッシュされます。オペレーティング・

システム、ファイル・システム、およびI/Oチャネルに対するサポートが保証されている場合、コミッ

ト後に電源障害やハードウェア・クラッシュが発生してもログ・レコードは保持されます。データ

ベースを回復すると（db_recoverを使用）、コミットされたトランザクションは維持されており、デー

タベースに適用することでデータベースを一貫した状態に戻すことができます。

DB_TXN_WRITE_NOSYNCフラグが指定されている場合、Berkeley DBは、トランザクションのコ

ミット時にログ・ファイルへとログ・バッファを書き込みますが、"fsync"は使用しません。ログ・

レコードはファイル・システムのバッファに残り、プログラムのクラッシュ時には保持されますが、

システム・クラッシュの場合は保持されない可能性があります（クラッシュ中にOSがログ・ファイ

ルの一部をメモリ内にキャッシュしている可能性があるため）。

DB_TXN_NOSYNCフラグが指定されている場合、ログ・バッファがいっぱいになった時点でのみロ

グ・ファイルへの書込みが行われます。したがって、プロセスがクラッシュした場合、コミット済

みトランザクションのうちログ・ファイルにフラッシュされていないものは、データベースのリカ

バリ時にロールバックされます。

この設定に関係なく、キャッシュからデータベース・ファイルへとダーティ・ページを書き込む際、

Berkeley DBは常に、このページに対するすべてのログ・レコードがログ・ファイルにフラッシュさ

れるようにします（"fsync"を含む）。このため、リカバリによって常にデータベースが一貫した状

態に戻るようにするため、事前書込みロギングが維持されます。これらのフラグによって、ロール

バックされるトランザクションの時間枠の大きさが制御され、さまざまなパフォーマンス特性が提

供されますが、いずれの場合もデータが破損することはありません。


11

結論

このホワイト・ペーパーではおもな機能と相違点について説明しましたが、これはBerkeley DB全体

にとってはほんの一部にすぎません。実際には、SQLiteユーザーが習得できる内容が他に数多くあり

ます。Berkeley DBにはレプリケーションやホット・バックアップなどの機能が搭載されています。

これらの機能は将来的に、SQLiteレイヤーに対してより深く統合され（おそらくはユーザー定義関数

を介して）、アプリケーションからより簡単に利用できるようになるでしょう。その第一歩がAPI

の完成と正しい動作です。

概して、SQLiteとBerkeley DBの組合せは強力なソリューションであると言えます。これを利用する

ことで、オープンかつ単一のC APIとSQL言語を使用して、はるかに広範なアプリケーションに対応

できるようになります。現在、大規模なトランザクション処理からスマートカード内で稼働するご

く小さい組込み環境までにわたるアプリケーションに対して、このAPIを使用できます。要件に応じ

て特定の実装を選択するだけで良いのです。

Oracle Berkeley DBは次のWebサイトからダウンロードできます。

http://www.oracle.com/technetwork/jp/database/berkeleydb/downloads/index.html

コメントや質問は、Oracle Technology Network（OTN）のOracle Berkeley DBフォーラムまでお寄せく

ださい。

http://forums.oracle.com/forums/forum.jspa?forumID=271

販売およびサポート情報については、[email protected]までお問い合わせください。

[email protected]に電子メールを送信すると、新しい製品リリース情報が届きます。

http://www.oracle.com/technetwork/jp/database/berkeleydb/downloads/index.html

http://forums.oracle.com/forums/forum.jspa?forumID=271

mailto:[email protected]

mailto:[email protected]

Oracle Berkeley DB SQL APIと

SQLite APIの比較 - 統合、利点、

および相違点

2010年10月

著者：Mike Owens

共著者：David Segleau

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores,

CA 94065

U.S.A.

海外からのお問い合わせ窓口：

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

www.oracle.com

Copyright © 2010, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載さ

れる内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による明

示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の保証

や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的ま

たは間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる

目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。

OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。IntelおよびIntel Xeon

はIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International, Inc.

の商標または登録商標です。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。0110

oracle berkeley db sql apiとsqlite apiの比較 - 統合 ......oracle berkeley db sql apiとsqlite...

Documents