データベースを製品の1つに統合する必要がありますが、どちらがニーズに適しているのでしょうか（自動展開が簡単、管理が不要、パフォーマンスが優れている）。sqliteは優れたソリューションのようです。問題は、データベースが高い同時実行性の問題に直面する可能性があることです。データベースが実行されているサーバーにクライアントが接続するたびに、PHP（Apache）を介してアクセスされます。1つのクライアントが約10秒ごとにサーバーに接続（およびINSERTクエリを実行）し、100を超えるクライアントが実行されている可能性があります。
INSERTクエリを実行すると、sqliteは特定の時間に特定の期間データベース全体をロックします。その期間を計算する方法はありますか？これが不可能な場合でも、sqlite（v3.3.7）は上記の条件に適合していると思いますか？
私は感情的な返信や誇張を避けようとしますが、このページに表示されているsqliteに関する知識が不足していることに本当に驚いています。さまざまなデータベース実装がさまざまなニーズに対応し、提供する運用仕様から、sqlite3はニーズに理想的であるように思われます。詳細に：
sqlite3は完全にACIDに準拠しています。つまり、アトミックコミットが保証されます。これは、MySQL（それが良いかもしれません）でもOracleでも自慢できないことです。詳細はこちら
また、sqlite3には、ファイルロックと同時実行のドキュメントで説明されているように、最大の同時実行性（スレッドセーフでもあります）を保証するための一見シンプルなメカニズムがあります。
彼らの（sqlite3開発者の）独自の見積もりによると、sqlite3は1秒あたり最大50,000のINSERTが可能です。これは理論上の最大値であり、ディスクの回転速度によって制限されます。ACID準拠では、データベースコミットがディスクに書き込まれたことを確認するためにsqlite3が必要です。したがって、INSERT、UPDATE、またはDELETEトランザクションではディスク全体を2回ローテーションする必要があります。これにより、7200rpmディスクドライブでのトランザクション数が実質的に60/sに削減されます。これは、別の回答にリンクされているsqlite FAQで概説されており、この事実から、本番環境でのエンジンのデータスループット機能についてある程度のアイデアが得られます。しかし、同時読み取りと書き込みはどうですか？
以前にリンクされたファイルロックと同時実行のドキュメントでは、sqlite3が「ライターの起動」を回避する方法について説明しています。これは、データベースの読み取りアクセスが多いため、データベースへの書き込みを試みるプロセス/スレッドがロックを取得できない状態です。ロック状態のSHAREDからPENDING、EXCLUSIVEへのエスカレーションは、sqlite3がINSERT（またはUPDATEまたはDELETE）ステートメントに遭遇し、次にCOMMITに遭遇したときに発生します。つまり、完全なデータベースロックは、実際の書き込みが実行される前の最後の瞬間に遅延します。ファイルロックを処理するためのsqliteの巧妙なメカニズムの結果は、ライターがキューに参加した場合（PENDINGロック）、既存の読み取り（SHAREDロック）が完了し、ライタープロセスにEXCLUSIVEロックを付与してから、読み取りを再開することを意味します。これには数ミリ秒しかかかりませんが、
EXCLUSIVEロックでのデフォルトのsqlite3WAITは3秒だと思います。したがって、1秒あたり60トランザクションが妥当な予想であり、平均して10秒に1回データベースに書き込もうとしているという事実を考えると、sqlite3は適切だと思います。タスクまでは、トラフィックが500倍に増加した場合にのみ、クラスタリングの導入が必要になります。
悪くはなく、要件に最適です。
SQLiteがこれらの要件に適したソリューションになるとは思いません。SQLiteは、ローカルで軽量な使用のみを目的として設計されており、何百ものリクエストを処理することはできません。
たとえばMySQL、またはなどPostgreSQL、他の解決策をお勧めします。どちらも非常にうまくスクリプト化できます。ですから、もし私があなたなら、セットアップのスクリプティングに力を注ぐでしょう。
SQLiteの信者と嫌悪者の間の炎上戦争を避けるために、よく参照されるSQLiteの使用時ドキュメントに注意を向けさせてください（信頼できる情報源と見なされていると思います）。ここで彼らは次のように述べています。
クライアント/サーバーRDBMSがより適切に機能する可能性がある状況
高い同時実行性
SQLiteは無制限の数の同時リーダーをサポートしますが、一度に1人のライターしか許可しません。多くの場合、これは問題ではありません。ライターがキューに入れられます。各アプリケーションはデータベースの動作を迅速に実行して先に進み、ロックは数十ミリ秒以上持続しません。ただし、より多くの同時実行性を必要とするアプリケーションがいくつかあり、それらのアプリケーションは別のソリューションを探す必要がある場合があります。
参照された質問には多くの書き込みが含まれていると思います。OPがSQLiteに対応する場合、拡張性のないソリューションになります。
SQLiteの適切な使用法についてSQLiteが述べていることは次のとおりです。http ：//www.sqlite.org/whentouse.html特に、そのページには、SQLiteはトラフィックの少ないサイト、まさにあなたが使用している種類のアプリケーションに適していると書かれています。再熟考。
大幅な成長を期待しない限り、SQLiteが機能するようです。各リクエストで何をするかに応じて、1秒あたり0.17クエリのクエリレートがSQLiteの機能の範囲内であると予想されます。
優れたユーザーエクスペリエンスを得るには、単一のリクエストを処理するために必要なクエリが約200ミリ秒かかるようにサイトを設計する必要があります。これを実現するには、結果セットが数行を超えるスコア行に触れないようにする必要があります。全表スキャンではなく、インディーズに依存する必要があります。これに当たると、1秒あたり5つのクエリを処理するのに十分なヘッドルームがあります（ピーク時）。これは、質問で述べる要件の30倍です。
SQLite FAQはこのトピックをカバーしています：http ：//www.sqlite.org/faq.html （「（5）複数のアプリケーションまたは同じアプリケーションの複数のインスタンスが同時に単一のデータベースファイルにアクセスできますか？」を参照）
ただし、特定の用途では、ストレステストを実行して、ニーズが満たされることを確認することをお勧めします。SQLiteの場合、100人の同時ユーザーは少し多いかもしれません。
よくある質問を読みましたが、SQLiteは並行性をかなり適切にサポートしているようですが、うまくいくように するにはトランザクションを使用する必要があるかもしれません。
Apacheの同時実行性に関する上記のコメントは正しいです。1つのApacheサーバーが複数のリクエストを処理でき、その数は実行されているプロセスの数によって異なります。私が実行しているサーバーのほとんどは、3〜5プロセスに設定されていますが、大規模なインストールでは20に達する可能性があります。ここでのポイントは、SQLiteは数千の挿入を実行できるため、小規模から中規模のトラフィックのWebサイトを処理できるということです。 2番目。
現在のプロジェクトでSQLiteを使用する予定ですが、安全のために、書き込みや同時実行性に敏感な部分にはBEGINTRANSACTIONとCOMMITを使用するつもりです。
結論として、いつものように、マニュアルを読んでください。
sqlite3に関する上記の説明に加えて、sqlite v 3.7.0で導入されたもう1つの優れた機能は、WALモードです。このモードでは、複数のプロセスから読み取り、同時に1つのプロセスで書き込むことができます。