MySQLではなくsqlite3を使おうと思っていますが、あまり大規模サイトで使われている事例を聞かないので不安です。sqlite3でも問題ない、または問題あるという意見を聞かせて下さい。
組み込みに向けたSQLiteの多くの利点がWEBサービスのバックエンドとしては逆に欠点となります
(1)パスワードによる保護が無い
SQLite3にはユーザー管理という概念がなく難なく情報を持って行かれる可能性がある
(2)ファイル単位ロック
SQLite3の排他制御はファイル単位で行われるため、複数ユーザーがアクセスしてくるWEBサービスなどではタイムアウトが頻発するといったような致命傷となる場合もある
(3)拡張性は無い
1つのファイルですべて完結しているので一見すると楽そうにも思えるけれど、逆に拡張性は無い
組み込み関数やストアドを比較点としてあげている人がいるけれど、その意味がわからない
MySQLにストアドが搭載されたのは5.0以降であり、4.xも比較的最近まで使われていたのだから、それは理由にはならない
組み込み関数についてもおおよそ代用することが可能なので、それが理由にはならない
使い方にもよるのですが、MySQLからSQLiteへの以降で注意すべき点としては、以下のようなものがあります。
これらを事前にクリアしておかないと、かえってレスポンスが悪いRDBMSになってしまうのでご注意を。
要するに、大規模なシステムで最適化に使う手法がSQLiteには通用しないので、大規模システムで敬遠されていると言うことです。(大規模システムで絶対に使えないというわけではありません)
組み込みに向けたSQLiteの多くの利点がWEBサービスのバックエンドとしては逆に欠点となります
(1)パスワードによる保護が無い
SQLite3にはユーザー管理という概念がなく難なく情報を持って行かれる可能性がある
(2)ファイル単位ロック
SQLite3の排他制御はファイル単位で行われるため、複数ユーザーがアクセスしてくるWEBサービスなどではタイムアウトが頻発するといったような致命傷となる場合もある
(3)拡張性は無い
1つのファイルですべて完結しているので一見すると楽そうにも思えるけれど、逆に拡張性は無い
組み込み関数やストアドを比較点としてあげている人がいるけれど、その意味がわからない
MySQLにストアドが搭載されたのは5.0以降であり、4.xも比較的最近まで使われていたのだから、それは理由にはならない
組み込み関数についてもおおよそ代用することが可能なので、それが理由にはならない
サポートしているデータ型や SQL が少ないことも問題になるかもしれませんね。
アクセス数ももちろん判断材料になると思うのですが、
データ件数や更新の頻度なども重要ですね。
例えば、大量のデータを扱うのに sqlite はチョット怖いですね。
簡単にメモリ不足になりそう。
逆に、データ件数や更新の頻度が少ない場合は sqlite でも十分だと思います。
コメント(1件)
うんそうおもいます