SQLiteの適切な用途[公式ドキュメントの和訳]

Situations Where SQLite Works Well

• 組み込みデバイスと「モノのインターネット」(Embedded devices and the internet of things)

  SQLiteのデータベースは、管理を必要としないため、専門家によるサポートなしで動作する必要があるデバイスでうまく機能します。SQLiteは、携帯電話、セットトップ ボックス、テレビ、ゲーム コンソール、カメラ、時計、キッチン家電、サーモスタット、自動車、工作機械、飛行機、リモート センサー、ドローン、医療機器、およびロボットでの使用に適しています：「モノのインターネット」。

  クライアント/サーバー・データベース・エンジンは、ネットワークの中心にある、入念に管理されたデータセンター内に存在するように設計されています。SQLiteは、そこでも動作しますが、SQLiteは、ネットワークの最先端でも成功しており、高速で信頼性の高いデータ・サービスをアプリケーションに提供しながら、自己防衛し、それ以外の場合は、危険な接続になります。

• アプリケーションのファイル形式(Application file format)

  SQLiteは、バージョン管理システム、財務分析ツール、メディア・カタログと編集スイート、CADパッケージ、記録管理プログラムなどのような、デスクトップ・アプリケーションのディスク上のファイル形式としてよく使用されます。従来のFile/Open操作は、データベース・ファイルにアタッチするために、sqlite3_open()を呼び出します。アプリケーションのコンテンツが改訂されると更新が自動的に行われるため、File/Save_Asメニュー・オプションは、不要になります。File/Save_Asメニュー・オプションは、バックアップAPIを使用して実装できます。

  このアプローチには、パフォーマンスの向上、コストと複雑さの軽減、信頼性の向上など、多くの利点があります。詳細については、テクニカル・ノート"aff_short.html"と"appfileformat.html"と"fasterthanfs.html"を参照してください。この使用例は、以下のデータ転送形式とデータ・コンテナの使用例と密接に関連しています。

• Webサイト(Websites)

  SQLiteは、ほとんどの低から中程度のトラフィックのWeb サイト (つまり、ほとんどの Web サイト) のデータベース エンジンとして最適に機能します。SQLiteが処理できるWebトラフィックの量は、Webサイトがデータベースを使用する頻度によって異なります。一般的に言えば、1 日あたりのヒット数が、100K未満のサイトであれば、SQLiteで問題なく動作するはずです。1 日あたり 10 万ヒットという数値は、控えめな見積もりであり、厳密な上限ではありません。SQLiteは、その10倍の量のトラフィックで動作することが実証されています。

  もちろん、SQLiteのWebサイト (https://www.sqlite.org/) は、SQLite自体を使用しており、この記事の執筆時点 (2015 年) では、1日あたり約40万から50万のHTTPリクエストを処理しています。その約15～20%は、データベースに接続する動的ページです。動的コンテンツは、Webページごとに、約200のSQL文を使用します。このセットアップは、物理サーバーを23台の他のサーバーと共有する単一のVMで実行されますが、ほとんどの場合、負荷平均は 0.1 未満に保たれます。

  こちらもご覧ください:Hacker 2022-12-13 からの新しいディスカッション。

• データ解析(Data analysis)

  SQLを理解している人は、sqlite3コマンドライン・シェル (または、さまざまなサードパーティのSQLiteアクセス・プログラム) を使用して、大規模なデータセットを分析できます。生データは、CSVファイルからインポートすることができます。次に、そのデータを細かく分割して、無数の要約レポートを生成できます。（どちらにも、SQLiteが組み込まれている）Tcl、あるいは、Pythonで記述された単純なスクリプトを使用して、あるいは、すぐに利用できるアダプターを使用して、R、あるいは、その他の言語で、より複雑な分析を実行できます。考えられる用途には、Webサイトのログ分析、スポーツ統計分析、プログラミング・メトリクスの編集、実験結果の分析などがあります。多くのバイオインフォマティクス研究者は、このように、SQLiteを使用しています。

  もちろん、エンタープライズ・クライアント/サーバー・データベースでも同じことができます。SQLiteの利点は、インストールと使用が簡単であり、作成されたデータベースが単一のファイルになり、USBメモリ・スティックに書き込んだり、同僚に電子メールで送信したりできることです。

• エンタープライズ・データのキャッシュ(Cache for enterprise data)

  多くのアプリケーションは、エンタープライズのRDBMSからの関連コンテンツのキャッシュとして、SQLiteを使用します。これにより、レイテンシーが短縮され、ほとんどのクエリが、ローカル・キャッシュに対して発生するようになったため、そして、ネットワークの往復を避けます。また、ネットワークと中央データベース・サーバーの負荷も軽減されます。そして、多くの場合、これは、クライアント側のアプリケーションが、ネットワークの停止中にも動作し続けることができることを意味します。

• サーバー側のデータベース(Server-side database)

  システム設計者は、データセンターで実行されているサーバー・アプリケーションのデータ ストアとしてSQLiteを使用すること、つまりアプリケーション固有のデータベース・サーバーの基盤となるストレージ・エンジンとして、SQLite を使用することに成功したと報告しています。

  このパターンでは、全体システムは、依然としてクライアント/サーバーです：クライアントは、サーバーに要求を送信し、ネットワーク経由で応答を返します。ただし、一般的なSQLを送信して生のテーブルのコンテンツを取得する代わりに、クライアントの要求とサーバーの応答は、高レベルでアプリケーション固有です。サーバーは、リクエストを複数のSQLクエリに変換し、結果を収集し、後処理、フィルタリング、分析を行い、次に、重要な情報のみを含む高レベルの応答を作成します。

  開発者は、このシナリオでは、SQLiteが、クライアント/サーバーSQLデータベース・エンジンよりも高速であることが多いと報告しています。データベース要求は、サーバーによってシリアル化されるため、並行性は、問題ではありません。並列化は、"データベース・シャーディング"によっても、改善されます：異なるサブドメインに別々のデータベース・ファイルを使用します。たとえば、サーバーには、ユーザーごとに個別のSQLiteデータベースがある場合があるため、サーバーは、何百または何千もの同時接続を処理することができますが、それぞれのSQLiteデータベースは、1つの接続だけで使用されます。

• データ転送形式(Data transfer format)

  SQLiteデータベースは、明確に定義されたクロスプラットフォーム形式の単一のコンパクトなファイルであるため、あるシステムから別のシステムにコンテンツを転送するためのコンテナとしてよく使用されます。送信者は、コンテンツをSQLiteデータベース・ファイルに収集し、その1つのファイルを受信者に転送し、次に、受信者は、必要に応じて、コンテンツを解凍するために、SQLを使用します。

  SQLiteデータベースは、エンドポイントのワード・サイズやバイト・オーダーが異なる場合でも、システム間のデータ転送を容易にします。データは、大きなバイナリ・ブロブ、テキスト、そして、小さな数値、あるいは、ブール値の複雑な組み合わせである可能性があります。従来の受信機を壊すことなく、新しいテーブルや列を追加することで、データ形式を簡単に拡張できます。SQLクエリ言語は、受信者が、転送全体を一度に解析する必要がないことを示していますが、代わりに、必要に応じて受信したコンテンツを照会できます。データ形式は、（複数のベンダーからの）さまざまな普遍的に利用できるオープンソース・ツールを使用して、人間が見るために簡単にデコードでき、ある意味で、"透明"です。

• ファイル・アーカイブやデータ・コンテナ(File archive and/or data container)

  SQLiteアーカイブのアイデアは、SQLiteをZIPアーカイブやTarballの代わりとして、どのように使用するかを示しています。SQLiteに格納されたファイルのアーカイブは、ほんのわずかに大きくなります。そして、場合によっては、実際には、同等のZIP アーカイブよりも小さくなります。そして、SQLiteのアーカイブは、徐々に追加さる細かな更新と、より豊富なメタデータを保存する機能を備えています。

  Fossilバージョン2.5以降では、ダウンロード形式として、従来のtarballとZIPアーカイブに加えて、SQLiteアーカイブ・ファイルが提供されます。sqlite3.exeコマンドライン・シェル・バージョン3.22.0以降では、.archive コマンドを使用して SQL アーカイブを作成、一覧表示、解凍します。

  SQLiteは、ネットワーク経由で出荷するために、さまざまなコンテンツを自己完結型の自己記述型パッケージにバンドルする必要があるあらゆる状況に適したソリューションです。コンテンツは、明確に定義されたクロスプラットフォームの安定したファイル形式でエンコードされます。エンコーディングは、効率的で、受信者は、ファイル全体を読み取って解析する必要なく、コンテンツの小さなサブセットを解凍できます。

  SQLアーカイブは、多くのクライアントにばらまかれるソフトウェアまたはコンテンツの更新の配布形式として役立ちます。たとえば、テレビ番組ガイドをセットトップボックスに送信する、車載ナビゲーション システムに無線で更新情報を送信する、アイデアのバリエーションが、使用されます。

• 特別なディスク・ファイルの置き換え(Replacement for ad hoc disk files)

  多くのプログラムは、fopen()、fread()、fwrite() を使用して、独自の形式でデータのファイルを作成および管理します。SQLiteは、これらの特別なデータ・ファイルの代わりとして、特にうまく機能します。直観に反して、SQLiteは、コンテンツをディスクに読み書きするためのファイルシステムよりも高速です。

• 内部、あるいは、一時的なデータベース(Internal or temporary databases)

  大量のデータを持つプログラムでは、さまざまな方法で選別し、並び変える必要があります。データをメモリ内のSQLiteデータベースにデータをロードし、結合と ORDER BY 句を使用してクエリを使用して、同じ操作を手動でコーディングするよりも、必要な形式と順序でデータを抽出する方が簡単かつ迅速です。すべてのクエリを再コーディングすることなく、新しい列とインデックスを追加できるため、SQLデータベースを内部的に使用すると、プログラムの柔軟性も向上します。

• デモ、あるいは、テスト中のエンタープライズ データベースの代替(Stand-in for an enterprise database during demos or testing)

  クライアント・アプリケーションは、通常、さまざまなSQLデータベース・エンジンに接続できる汎用データベース・インターフェイスを使用します。サポートされているデータベースの組み合わせに、SQLiteを含め、SQLiteエンジンをクライアントに静的にリンクすることは理にかなっています。こうすることで、テストやデモンストレーションのためにクライアント・プログラムを SQLiteデータ・ファイルと一緒にスタンドアロンで使用できます。

• 教育とトレーニング(Education and Training)

  設定と使用が簡単であるため、（インストールは簡単です: sqlite3 または sqlite3.exe 実行可能ファイルをターゲット マシンにコピーして実行するだけです）SQLiteは、SQLを教えるための優れたデータベース エンジンです。学生は、好きなだけデータベースを簡単に作成できます。そして、コメントや採点のためにデータベースを講師にメールで送信できます。RDBMSを、どのように実装するかに興味のある更に高度な学生のために、モジュール化され、十分にコメントされ、文書化されたSQLiteコードは、優れた基盤として機能します。

• 実験的なSQL言語拡張機能(Experimental SQL language extensions)

  SQLiteの単純な、モジュラー・デザインは、新しい実験的なデータベース言語の機能やアイデアのプロトタイプを作成するための優れたプラットフォームです。

Situations Where A Client/Server RDBMS May Work Better

• クライアント/サーバー・アプリケーション(Client/Server Applications)

  ネットワークを介して同じデータベースに、SQLを送信するクライアント・プログラムが多数ある場合、次に、SQLiteの代わりに、クライアント/サーバー・データベース・エンジンを使用します。SQLiteは、ネットワークファイルシステム上で動作しますが、ほとんどのネットワーク・ファイルシステムに関連する遅延のため、性能は、良くありません。また、多くのネットワーク・ファイルシステムの実装 (Unix と Windows の両方) では、ファイル・ロック・ロジックにバグがあります。ファイル・ロッキングが正しく動作しない場合、2 つ以上のクライアントが、同じデータベースの同じ部分を同時に変更しようとする可能性があります。その結果、破損が発生します。この問題は、基盤となるファイルシステムの実装のバグに起因するため、それを防ぐために、SQLiteができることは何もありません。

  経験則として、ネットワークを介して多数のコンピュータから同時に、（介在するアプリケーション サーバーなしで）同じデータベースに直接アクセスする状況によっては、SQLiteを使用しないことです。

• 大量のウェブサイト(High-volume Websites)

  SQLiteは、通常、Web サイトへのデータベース・バックエンドとして正常に機能します。しかし、Webサイトの書き込みが多い、あるいは、それが複数サーバを必要とするように忙しい場合、次に、SQLiteの代わりに、エンタープライズ・クラスのクライアント/サーバー・データベース・エンジンを使用することを検討してください。

• 非常に大規模なデータセット(Very large datasets)

  SQLiteデータベースの大きさは、281 テラバイト (248 バイト、256 ティビバイト) に制限されています。そして、より大きなデータベースを処理できたとしても、SQLiteは、全データベースを一つのディスク・ファイルに格納し、多くのファイルシステムは、ファイルの最大サイズをこれよりも小さいサイズに制限しています。そのため、あなたが、この規模のデータベースを検討している場合、あなたが、コンテンツを複数のディスク ファイルに分散し、そして、おそらく複数ボリュームにまたがって配置する、クライアント/サーバー データベース エンジンの使用を検討することをお勧めします。

• 高い並列化(High Concurrency)

  SQLiteは、無制限の数の同時リーダーをサポートしますが、任意の時点で許可されるライターは 1 つだけです。多くの状況では、これは、問題ではありません。ライターが並んでいます。それぞれのアプリケーションはデータベースの作業を迅速に行い、先に進みます。そして、数十ミリ秒以上続くロックはありません。ただし、より多くの同時実行性を必要とするアプリケーションもあります。そして、これらのアプリケーションでは、別のソリューションを探す必要がある場合があります。

Checklist For Choosing The Right Database Engine

1. データは、ネットワークによってアプリケーションから分離されていますか?→クライアント/サーバーを選択する

   リレーショナル・データベース・エンジンは、帯域幅を削減するデータ・フィルタとして機能します。そのため、同じ物理デバイスに、データベース・エンジンとデータを保持することが最善であるため、高帯域幅のエンジンからディスクへのリンクは、ネットワークを横断する必要はなく、低帯域幅のアプリケーションからエンジンへのリンクのみネットワークを横断します。

   しかし、SQLiteは、アプリケーションにビルドされます。そのため、データが、アプリケーションとは別のデバイスにある場合、エンジンからディスクへ、より高い帯域幅のリンクが、ネットワーク上に存在する必要があります。これは機能しますが、最適ではありません。したがって、データが、アプリケーションとは別のデバイスにある場合、通常は、クライアント/サーバー・データベース・エンジンを選択することをお勧めします。

   注意：このルールでは、"アプリケーション"とは、SQLステートメントを発行するコードを意味します。"アプリケーション"が、アプリケーション・サーバーである場合、そして、コンテンツが、アプリケーション・サーバーと同じ物理マシンに存在する場合、次に、エンド・ユーザーが、別のネットワーク・ホップから離れている場合でも、SQLiteが適切な場合があります。

2. 同時平行で入力者が多くいる？→ クライアント/サーバーを選択する

   多くのスレッドやプロセスが、同時にデータベースに書き込む必要がある（そして、それらは、列に並んで交代することはできない）場合、次に、その機能をサポートするデータベース・エンジンを選択することをお勧めします。それは、常に、クライアント/サーバー・データベース・エンジンを意味します。

   SQLiteは、データベース・ファイルごとに、一度に、1つのライターだけをサポートします。しかし、ほとんどの場合、書き込みトランザクションは、ミリ秒しかかからないため、複数のライターが簡単に交代できます。SQLiteは、多くの人が思っているよりも多くの書き込み同時実行を処理します。それでも、クライアント/サーバー データベース システムは、アクセスを調整するために手元に長時間実行されるサーバー プロセスがあるため、通常、SQLite よりもはるかに多くの同時書き込みを処理できます。

3. 大きいデータ？→クライアント/サーバーを選択する

   データが、1つのディスク・ファイルに収まらない、あるいは、収まらないサイズにまで大きくなる場合、次に、あなたは、SQLite以外のソリューションを選択する必要があります。あなたが、281 テラバイトのファイルをサポートするディスク・ドライブとファイル・システムを見つけることができると仮定すると、SQLiteは、最大 281 テラバイトのサイズのデータベースをサポートします。それでも、コンテンツのサイズが、テラバイトの範囲に忍び寄るように見える場合、集中化されたクライアント/サーバー データベースを検討することをお勧めします。

4. それ以外の場合、→SQLiteを選択してください！

   ライターの同時実行性が低く、コンテンツが、1テラバイト未満のデバイス ローカル・ストレージの場合、ほとんどの場合、SQLiteの方が、優れたソリューションです。SQLiteは、高速で信頼性が高く、構成やメンテナンスは不要です。それは、物事をシンプルに保ちます。SQLiteは、「動作する」だけです。