SQLiteの適切な使い方

以下は、 ２０１６年１２月現在の sqlite 文書、Appropriate Uses For SQLite 、SQLite の適切な使い方、の、kanda.motohiro@gmail.com による訳です。以下の条件で、公開します。

The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this code under copyright law.

SQLite を、MySQL, Oracle, PostgreSQL, あるいは SQL Server のような、クライアント／サーバ SQL データベースエンジンと直接比較することはできません。SQLite は、異なる問題を解決しようとしているからです。

クライアント／サーバ SQL データベースエンジンは、エンタープライズデータの、共用リポジトリを実装しようと努力しています。それらは、スケーラビリティ、並列同時実行性、中央集権化、そして、制御を重視します。SQLite は、個々のアプリケーションとデバイスのための、ローカルなデータ記憶域を提供しようと努力します。SQLite は、経済性、効率、信頼性、独立性、そして、単純さを重視します。

SQLite は、クライアント／サーバデータベースと競っているのではありません。SQLite は、fopen() と競っているのです。

SQLite がうまくはたらく状況

・ 組み込みデバイスと、internet of things

SQLite データベースは、管理がいりません。このため、熟練した人間のサポートがなくても動作しなくてはいけないデバイスでうまくはたらきます。SQLite は、携帯電話、セットトップボックス、テレビ、ゲームコンソール、カメラ、時計、台所用品、温度計、自動車、機械道具、飛行機、遠隔センサ、ドローン、医療機器、そしてロボット、すなわち、"internet of things" での使用に適しています

クライアント／サーバデータベースエンジンは、ネットワークの中心にある、人が好んで接するデータセンターの中に住むように設計されています。SQLite はそこでもはたらきます。しかし、SQLite はネットワークの端っこでも生き延びます。自分を守りながら、SQLite なしでは不安定な接続性しか得られないであろうアプリケーションのために、高速で安定したデータサービスを提供します。

・ アプリケーションファイル形式

SQLite はしばしば、バージョン管理システム、金融解析ツール、メディアカタログと編集スイート、CAD パッケージ、記録保持プログラムなどのデスクトップアプリケーションのためのディスク上ファイル形式として使われます。伝統的な、File/Open 操作は、データベースファイルにアタッチするために、sqlite3_open() を呼びます。更新は、アプリケーションの内容が変更された時に自動で行われますので、File/Save メニューオプションは、不要になります。File/Save_As メニューオプションは、バックアップ API を使って実装することができます。

このアプローチには、多くの利点があります。それには、アプリケーション性能の向上、コストと複雑さの軽減、そして信頼性の改善が含まれます。詳しくは、ここ と ここ にある、技術メモを参照ください。

・ ウェブサイト

SQLite は、ほとんどの、負荷が低いあるいは中くらいのウェブサイト（それはつまり、ほとんどのウェブサイトです）のためのデータベースエンジンとして、素晴らしくうまくはたらきます。SQLite が扱うことのできるウェブ負荷は、そのウェブサイトが、自分のデータベースをどのくらいヘビーに使うかに依存します。一般的に言って、100K ヒット／日以下を得るサイトならどれでも、SQLite でうまくいくはずです。100K ヒット／日という数字は、保守的な見積もりであり、厳格な上限値ではありません。SQLite はその１０倍の負荷の下でうまくはたらくことを示してきました。

もちろん、SQLite ウェブサイト (https://www.sqlite.org/) 自身が、 SQLite を使っています。そして、これを書いている今(2015) それは、一日に 400K から 500K の HTTP 要求を扱います。その15-20% は、データベースをさわる、ダイナミックなページです。ダイナミックなコンテンツは、一つのウェブページごとに、約 200 の SQL 文 を使います。この構成は、２３台の他の仮想マシンと物理サーバを共有する、単一の仮想マシンで動作しています。そしてそれでも、ほとんどの時間で、負荷は 0.1 以下のままです。

・ データ分析

SQL を理解する人々は、sqlite3 コマンドラインシェル (あるいは多くの、サードパーティーの SQLite アクセスプログラム)を使って、大きなデータセットを解析することができます。生のデータは、CSV ファイルからインポートできます。そして、そのデータを切り刻んで、いろいろなサマリー報告を生成することができます。Tcl あるいは Python （いずれも、SQLite ビルトインにあります）で書かれた単純なスクリプトを使って、より複雑な解析もできます。あるいは、すぐに使用可能なアダプタを使って、 R 、あるいは他の言語も使えます。ウェブサイトのログ解析、スポーツ統計解析、プログラムメトリックの統合、そして実験結果の解析などに使えます。多くの生物情報学の研究者は、SQLite をこのように使います。

もちろん、エンタープライズクライアント／サーバデータベースを使っても同じことができます。SQLite の利点は、それはインストールと使用がより簡単なことと、結果となるデータベースが単一のファイルであり、USB メモリスティックに書いたり、同僚に電子メールで送ることができることです。

・ エンタープライズデータのキャッシュ

多くのアプリケーションは、SQLite を、エンタープライズ RDBMS の内容の対応するキャッシュとして使います。これは、遅延を減らします。多くの問い合わせが、ローカルキャッシュに対して行われるようになり、ネットワークラウンドトリップを必要としないからです。それはまた、ネットワークと、中央データベースサーバの負荷を減らします。そして多くの場合、これは、クライアント側のアプリケーションが、ネットワークが切れた状態でも動作を続けられることを意味します。

・ サーバ側データベース

SQLite を、データセンタで動くサーバアプリケーションのデータストアに使った成功例を報告するシステム設計者がいます。あるいは言葉を代えて言えば、SQLite を、アプリケーション固有のデータベースサーバのための、元となるストレージエンジンとして使ったものです。

このパターンにおいて、システム全体は、クライアント／サーバのままです。クライアントは、要求をサーバに投げて、ネットワークを経由して応答を得ます。しかし、汎用 SQL を投げて、生のテーブル内容を得る代わりに、クライアントの要求とサーバの応答は、高レベルでアプリケーション固有になります。サーバは、要求を複数の SQL 問い合わせに変換し、結果を集め、後処理をして、フィルタリングと解析をします。そして、重要な情報だけを含む、高レベルの応答を作成します。

このシナリオにおいて、SQLite はしばしば、クライアント／サーバデータベースエンジンよりも速いと報告する開発者がいます。データベース問い合わせは、サーバによってシリアライズされますから、同時実行性は問題とはなりません。同時実行性は、または、「データベースシャーディング」によって改善できます。それは、異なるサブドメインごとに、別のデータベースファイルを使います。例えば、サーバはユーザごとに別々の SQLite データベースを持つかもしれません。そうすれば、サーバは、数百数千の同時コネクションを扱うことができ、しかし、それぞれの SQLite データベースは一つのコネクションでだけ使われます。

・ ファイルアーカイブ

SQLite アーカイバ プロジェクトは、SQLite が ZIP アーカイブやターボールの代わりとして使えることを示します。SQLite に格納されたファイルのアーカイブは、同等の ZIP アーカイブに比べてわずかにより大きくなります。場合によっては実際により小さくなることもあります。そして、SQLite アーカイブは、インクリメンタルでアトミックな更新を特徴とし、より豊富なメタデータを格納する能力もあります。

SQLite アーカイブは、多くのクライアントにブロードキャストされるソフトウェアや、コンテンツの更新の配布形式として便利です。この概念の変種は例えば、セットトップボックスにテレビ番組のガイドを送信したり、車両ナビゲーションシステムの更新を無線で送るために使われます。

・ アドホックのディスクファイルの代わり

多くのプログラムは、 fopen(), fread(), そして fwrite() を使って、自作の形式のデータのファイルを作成し、管理します。SQLite はこれらのアドホックなデータファイルの代わりとして、特にうまくはたらきます。

・ 内部的あるいは一時的なデータベース

多くのデータをいろいろな方法でふるいにかけ、ソートする必要のあるプログラムにとって、そのデータを、メモリ上の SQLite データベースにロードして、ジョインと ORDER BY 節を含む問い合わせを使って、データを必要な形式と順序で抜き出すほうが、同じ操作を手作業でコードしようとするよりも簡単で速いことがしばしばあります。このように SQL データベースを内部的に使うことは、そのプログラムにより柔軟性を与えます。新しいカラムとインデックスを追加するために、全ての問い合わせを書き直す必要はないからです。

・ デモあるいはテストの間、エンタープライズデータベースの代わりとなる

クライアントアプリケーションは典型的には、汎用データベースインタフェースを使い、それはいろいろなデータベースエンジンへの接続を可能とします。SQLite をサポートされるデータベースの一つに加えて、SQLite エンジンをクライアントに静的にリンクするのは意味のあることです。そうすればクライアントプログラムは、テストあるいはデモのために、SQLite データファイルとともにスタンドアロンで使うことができます。

・ 教育とトレーニング

セットアップと使用が簡単なので（インストールは自明です。単純に、sqlite3 あるいは sqlite3.exe 実行形式を目的マシンにコピーして実行するだけです。）SQLite は、SQL を教えるために使うことのできる良いデータベースエンジンとなります。生徒は自分の好きなだけ多くのデータベースを容易に作ることができ、先生にデータベースを電子メールで送って、コメントあるいは成績を求めることができます。RDBMS がどのように実装されているかを学習することに興味のあるより進んだ生徒は、モジュラーで、コメントがきちんとされ、文書化されている SQLite コードは、良い基本となるでしょう。

・ 実験的な、SQL 言語拡張

単純でモジュラーな SQLite の設計は、実験的なデータベース言語機能とアイディアをプロトタイプするためのよいプラットフォームとなるでしょう。

クライアント／サーバ RDBMS がよりうまくはたらくことのある状況

・ クライアント／サーバアプリケーション

ネットワークを通して、同じデータベースに SQL を投げるクライアントプログラムがたくさんあるならば、SQLite でなくてクライアント／サーバデータベースエンジンを使いましょう。SQLite は、ネットワークファイルシステムの上でもはたらきますが、ほとんどのネットワークファイルシステムに伴う遅延のために、性能はあまり良くありません。また、多くのネットワークファイルシステム実装(Unix でも Windows でも)では、ファイルロック論理にバグがあります。ファイルロックが正しく働かないならば、二つ以上のクライアントが同時に同じデータベースの同じ部分を更新しようとするかもしれません。それは、破壊につながります。この問題は、元となるファイルシステム実装のバグが原因なので、それを防ぐために SQLite ができることはありません。

正しいおおまかな規則は、同じデータベースがネットワークを通して、多くの計算機から直接に（アプリケーションサーバが途中に入ることなく）、同時に、アクセスされるならば、SQLite を使うのを避けることです。

・ 高ボリュームのウェブサイト

SQLite はウェブサイトのバックエンドとして、通常はうまくはたらきます。しかし、そのウェブサイトがライトが頻繁だったり、あまりに忙しいので複数のサーバを必要とする場合は、SQLite ではなく、エンタープライズ級のクライアント／サーバデータベースエンジンを使うことを考えましょう。

・ とても大きなデータセット

SQLite データベースは、大きさが 140 terabytes (247 bytes, 128 tibibytes) に限られます。そしてもしそれがより大きなデータベースを扱うことができるとしても、SQLite はデータベース全体を一つのディスクファイルに格納します。そして、多くのファイルシステムはファイルの最大長を、これよりもいくらか小さな値に制限します。なので、もしあなたがこのくらいの大きさのデータベースを考えているならば、コンテンツを複数のディスクファイル、そしてもしかすると複数のボリュームに分散するクライアント／サーバデータベースエンジンを使うことを考えるのがよいでしょう。

・ 高い並列同時実行性

SQLite は、無限個数の同時のリーダーをサポートします。しかし、ある時間のいずれの時でも一つのライターしか許しません。多くの状況でこれは問題ではありません。ライターは、キューにつながります。それぞれのアプリケーションは自分のデータベースの仕事を素早く行って進んでいきます。そしてロックは数十ミリ秒以上続くことはありません。しかしアプリケーションによってはこれ以上の同時実行性を必要とするものがあります。そのようなアプリケーションは異なるソリューションを探す必要があるかもしれません。

正しいデータベースエンジンを選ぶためのチェックリスト

１． データは、アプリケーションと、ネットワークによって分離していますか？ → クライアント／サーバを選びましょう。

関係データベースは、バンド幅を減らすデータフィルタとしてはたらきます。なので、データベースエンジンとデータは同じ物理デバイスに置くのが最適です。そうすれば、高バンド幅のエンジンからディスクへの経路はネットワークを通りません。低バンド幅のアプリケーションからエンジンの経路だけが通ります。

しかし SQLite は、アプリケーションにビルトインされています。なので、もしデータがアプリケーションとは別のデバイスにあるならば、高バンド幅のエンジンからディスクへの経路はネットワークを通らなくてはいけません。これは動きますが、最適ではありません。なので、データがアプリケーションとは別のデバイスにあるならば、クライアント／サーバデータベースエンジンを選ぶのが通常はよいでしょう。

注意：この規則では、「アプリケーション」は、SQL 文を発行するコードを意味します。もし「アプリケーション」が、アプリケーションサーバであり、コンテンツがアプリケーションサーバと同じ物理マシンにあるならば、エンドユーザがネットワークホップのもう一つ向こう側にいても、SQLite は適当です。

２． 多くの同時実行ライター？ → クライアント／サーバを選びましょう。

もし多くのスレッドそして／あるいはプロセスが同時にデータベースに書く必要がある（それらはキューに入って順番を待つことができない）場合、その能力をサポートするデータベースエンジンを選ぶのが最適です。それは常に、クライアント／サーバデータベースエンジンを意味します。

SQLite は、データベースごとに、一度に一人のライターしかサポートしません。しかしほとんどの場合、ライタートランザクションは数ミリ秒しかかかりませんから、複数のライターは単純に順番を待つことができます。SQLite は、多くの人が疑うほどのより多くのライト同時実行性を扱えるようになるかもしれません。しかし、クライアント／サーバデータベースシステムでは、手元に、長く走るサーバプロセスがあって、アクセスを調整できますから、通常は SQLite がどんなにがんばっても到達できないほどのライト同時実行性を扱うことができるでしょう。

３． ビッグデータ → クライアント／サーバを選びましょう。

もしあなたのデータが、単一のディスクファイルに入れるのに不安、あるいは不可能、なほどに大きくなるならば、SQLite 以外のソリューションを選ぶべきです。SQLite は１４０テラバイトまでの大きさのデータベースをサポートします。あなたが１４０テラバイトのファイルをサポートするディスクドライブとファイルシステムを見つけられるとして。そうであっても、コンテンツの大きさが、テラバイト領域に忍び寄るかもしれないならば、中央集権的な、クライアント／サーバデータベースを考えるのがよいでしょう。

４． それ以外 → SQLite を選びましょう！

デバイスローカルの記憶域で、ライト同時実行性が低く、コンテンツがテラバイト以内ならば、SQLite はほとんど常により優れたソリューションです。SQLite は高速で高信頼で、設定もメンテナンスもいりません。それは、ものごとを単純にします。SQLite は「単に動きます」。

以上