内部使用Webサイト：SQLiteに対して説得力のある事例はありますか？

FlaskやDjangoなどの多くのWebフレームワークは、デフォルトのデータベースとしてSQLiteを使用します。 SQLiteはPythonに含まれており、管理オーバーヘッドが非常に低いため、魅力的です。

ただし、トラフィックの多い公共の本番サイトのほとんどは、mySQL、Oracle、またはpostgresqlなどのより重いデータベースを使用しています。

質問：

仮定：

• サイトのトラフィックは中程度であり、データベースへの同時読み取り/書き込みアクセスが発生します
• SQLite書き込みロックでSQLAlchemyを使用します（ただし、このコメントは少し緊張しますが）
• データベースにはおそらく60,000レコードが含まれます
• データ構造は、より重いデータベースにある高度な機能を必要としません

中程度のトラフィックの社内企業ツールとして機能するWebサイトで、SQLiteの同時実行に対して説得力のある事例はありますか？もしそうなら、どのような条件がSQLiteに並行性の問題を引き起こしますか？

一般的な恐怖/根拠のない指差しではなく、既知の特定の根本原因を探しています。

あなたの質問に対する公式の回答、SQLiteの適切な使用を読むことをお勧めします。具体的には、「別のRDBMSがより適切に機能する状況」では、SQLiteは同時書き込みをサポートしていないと警告しています。

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

適切性の観点から、SQLiteはSQLクエリをサポートする非常に洗練されたファイル形式と見なす傾向があります。データベースをWebアプリケーションから分離したい場合、SQLiteはこの場合に最適化されていないため、SQLiteを避ける傾向があります。要するに、SQLiteはいくつかのシナリオで使用するには拡張性が不十分であるため、いつか普及することを望んでいるWebサイトを運営している人は、SQLiteを使用して後で切り替えを余儀なくされるのではなく、拡張性のあるものから始める方が良いかもしれません。

そうは言っても、SQLiteはおそらくほとんどの内部Webサイトに適しています。通常、内部Webサイトは、同じレベルの同時実行性とスケーラビリティを必要としません。

ITディレクターの帽子をかぶって、ここにいくつかの禁止事項があります。

• データ破損のリスク。おそらく本物よりも理解しているかもしれませんが、これは非トランザクションファイルタイプのDBであり、最近のバックアップがあるかどうかを尋ねる以外に、悪い書き込みに頼る必要はほとんどありません。そういえば。。。
• このことをどのようにバックアップしますか？ある方法で、私は良いコピーを持っていることを知っています。できればアプリをオフラインにせずに。
• DBへのアクセスを保護するにはどうすればよいですか？私の一般的な理解は、SQL liteにはファイルシステムへのアクセス以外には何もありません。これはまともな開始ですが、すべてではありません。特に、DBAよりも多くの段階的な権限が必要なWebアプリの場合、または何もありません。

開発者の観点から、なぜSqlLiteがデフォルトであるのかを知ることは重要だと思います。それは、それが簡単であり、うまくデモできるからです。新しい開発者にプラットフォームを「販売」している場合、最小限の手間で実用的なWebアプリを起動できることが重要です。そして、立ち上がってデータベースサーバーを適切に構成する必要があるのは、回避すべき大きな障害です。