はじめに
データベースのパフォーマンスは、大部分のアプリケーションの最も重要な特性の1つであり、開発者やDBAにとっては、通常はデータの取得速度に依存します。このため、パフォーマンスの最適化やチューニングに関する多くの書籍は、クエリを高速化する方法について説明しています。RDBMSメーカーでさえも、高速なデータ取得の必要性を理解しており、これを促進するためのさまざまなツール（インデックス、構成オプションなど）が用意されています。しかし、データベースのパフォーマンスは、データ取得の速度で常に表されるわけではありません。場合によっては、データ挿入の速度に依存します。
例えば、測定結果や調査結果をデータベースに格納する制御測定システムまたは調査サイトを設計する必要があるものとします。比較的単純な作業のように思われますが、その仕様を詳しく見ていくと、必ずしも思っているほど簡単ではありません。
- 受け取った非常に大量のトランザクションを処理してデータベースに挿入する必要があります。
- 24時間×7日間に渡って使用可能でなければなりません。
- テーブルに格納する必要があるフィールド（パラメータ）数は、それぞれ大きく異なります。例えば、質問数は調査ごとに異なります（つまり、Webページ上のコントロールや要素の数が異なります）。また、制御測定システム内のプロセスごとに、検出器や測定装置の数も異なります。
- アプリケーションは、データの挿入だけでなく、少ないとはいえデータの取得でも使用されます（詳細な分析ではOLAPシステムを作成できますが、それは別の問題です）。
このシナリオに対して考えられるすべてのソリューションを総合的に分析することは、本稿の範囲を超えています。しかし、別の角度から要件に汎用的に取り組むことはできます。例えば、次に示すオプションのすべてまたは一部を使用できます。
- 高速なインターネットおよび高速ネットワーク
- 高速なCPUと多くのRAMを搭載した強力なサーバー
- 高速なディスクとパフォーマンスに優れたRAID
- Webサーバーの負荷分散
- データベースサーバーのフェールオーバークラスタリング
- テーブルのパーティション分割
- 大量のストレージ容量（SAN）など
パーティション分割を除く上記のすべてのソリューションは、非常にコストがかかります。たとえコスト的な問題がなかったとしても、依然としていくつかの難問を解決する必要があります。例えば、どんなデータベースでも定期的な保守が必要であり、インデックス、バックアップ、旧データの削除、断片化などに関する保守作業を行わなければなりません。データをアプリケーション（Web）サーバーからデータベースに直接供給する場合は、データベースの保守を行っている間に、挿入用のデータが失われたり、アプリケーションサーバー（またはデータベースサーバー）がクラッシュすることがあります。このため、データベースサーバー上でリソースを大量に使用している間（言い換えれば低速な挿入を行っている間）に、データを一時的に保持する一種のバッファを用意する必要があります。もちろん、複数のデータベースサーバーを追加しておけば、保守時間を十分に確保することができます。しかし、この場合は、異なるサーバー上のデータを1つのデータベースに統合するという別の問題が生じます。
Berkeley DBは、バッファに適しています。反復的な静的クエリが非常に効率的に行われ、データがキー/値ペアで格納されます（調査サイトや制御測定システムの例では、データをコントロール（要素）の名前/値ペア、または検出器の位置/値ペアとして送信することに注意してください）。しかし、無限に増大するバッファなどはなく、標準のデータベースに十分に早くデータを送信できなければ、サーバーは結局クラッシュしてしまいます。
このように、挿入の速度は、サンプルアプリケーションにとって、重大な要因の一つになります。
データの格納方法
データベースの設計は、挿入のパフォーマンスに大きく影響します。そのため、データベース（ストレージ）構造を選択する場合は、十分な注意が必要です。例えば、データをXMLとして保存することも可能です。この方法は非常に魅力的ですが、前述の調査サイトまたは制御測定システムなどの例では、挿入の速度が低下し、多くのストレージ容量が占有されます。また、非常に伝統的なデータベース設計でデータベースを構築することもできます。この場合は、各テーブルが現実の世界のオブジェクトを再現し、テーブル内の各列がオブジェクトのプロパティに対応します。しかし、調査サイトや制御測定システムなどの例では、プロパティ（列）の数は動的です。10～1000の範囲で変動するため、伝統的な設計には適しません。
そこで、おそらく次のソリューションを選ぶことになるでしょう。それは、データを名前/値のペアで格納する方法です。これは、HTMLコントロール（要素）の名前/値ペア、およびBerkeley DBのフィールド/値ペアに完全に対応します。大部分の調査（制御装置）データ値は整数として解釈できるため、データを型で分けると便利でしょう。例えば、「tbl_integerData」と「tbl_textData」という2つのテーブルを作成します。両方のテーブルの構造は、value列のデータ型を除けば、まったく同じです。value列のデータ型は、前者のテーブルでは整数型、後者のテーブルではテキスト（varchar）型です。
