データベース VS Linuxのファイル管理 低負荷なのはどちらでしょ

質問

データベース　VS　Linuxのファイル管理　低負荷なのはどちらでしょうか？

良く、電話番号や郵便番号を例にとってデータベースの利用例がありますが、このくらいであればLinuxのファイル管理をそのまま利用した方が良いのではないかと思うのですが実際どうなのでしょうか？
最近レンタルサーバを使い始めたのですが、My SQLよりも、Linuxのファイル管理（内部ではデータベース化してる？）がかなり優秀なことに気づきました。
そこで思ったのですが、
例えば、
03-1234-***8　Aさん
03-1234-***9　Bさん
以下、5000万程度続く
この場合、
ファイル名を、「03-1234-***8」として、ファイルの中を「Aさん」
同様に、「03-1234-***9」として、ファイルの中を「Bさん」
以下5000万ファイル作成
このようにしたらいかがでしょうか？
また、名前から電話番号を調べられるように、逆パターンも用意する。

これであれば、わざわざデータベースにログインなどせずすぐに呼び出せますが、サーバ負荷など考えるとどちらが良いのでしょうか？
5000万が多すぎれば、500万、50万などの場合・・・
どの程度であれば、データベースよりもサーバ上だけで行うのが低負荷でしょうかね？

回答No.4

Tacosan · ベストアンサー

XFS の場合, デフォルトでは
・inode は最初の 1 TB に格納される
・inode の大きさは 1個あたり 256 B
なので, inode は全部で 4 G個くらいでしょうか＞#3.
もっとも, ACL の都合上 512 B/inode にすべしという話はあるし, inode64 オプションというのもあってこいつを使うと事実上無制限だと思われます.
他は調べてないので知らない.

お礼

回答いただきありがとうございます。
難しい話でよく分かりませんが、DB並？それ以上に使えると言うことでしょうか？
とりあえず、35万ファイルほど行ってみたのですが、レスポンスは良好なようで、とりあえず、この程度であれば問題無いのかもしれませんね。
実用上何ファイル程度おけるのか、また、DB代わりに使うことが可能なのか気になっています。

回答No.9

oktuburero

>再度考え直し構築するという感じです。
それが無駄。

>if($html !~ m/OK/) で判定を行い、OKを含まないレスポンスは全てエラーとして処理する為だから何?
2ファイルで1セット。
1つ目のデータが正常に更新され2つ目のデータの更新が失敗した場合に
1つ目のファイルをロールバックさせないと1つ目と2つ目のファイルで矛盾が生じてデータの整合性が
取れなくなる。
それに対する処理がまったく抜けているだろって事だよ。

>サーバサイドでは特にエラー処理はしていません。
それ意味ない。アップロードが別処理なら
アップロード処理でも実際にデータが置かれるサーバサイドでデータがアップされたときの整合性を確認する必要がある。
で正常にアップロードできなければロールバックする処理を書く必要がある。

>そう書いたと思うのですが・・・
さくらマニュアルすら読めない日本語素人とは思ってはいませんでした。

>どのような目に遭うのか教えて頂けると幸いです。
無駄な負荷によりサーバを追い出されます。

>玄人が素人を馬鹿にしているようにすら感じます。
屁理屈だけで人の意見を聞くことすらしないから
しかも質問者自身もう答えが出ているのに無駄な質問をするから
何人もの人ががDBがいいと説明しているのに屁理屈を並べて聞く耳を持たない。
俺もそろそろ愛想が尽きたからこれを最後の説明としておくよ。もう勝手にやってくれ。

補足

レス頂きありがとうございます。
屁理屈を並べるので、無駄な質問とのことですが、屁理屈のつもりではありません。
DBが使えないor不安定な環境でも、DBに近いことができれば画期的なことではないでしょうか？

>それに対する処理がまったく抜けているだろって事だよ。
ローカルで、OKのマッチがとれなければ、何度かリトライさせる予定です。
万が一、それでも無理な場合、エラーとして記録しておき、あとで手動で訂正するという感じです。
DBでも落ちていて使えないことがあるようですので、このくらいのエラー処理は仕方がないと思っています。

＞アップロードの整合性について
zipでアップする為、壊れていれば解凍できないと思っていますが、
念のため、CRC16などハッシュ値をチェックをして解凍すれば大丈夫かと思います。

＞無駄な負荷によりサーバを追い出されます。
了解いたしました。ただ、ファイル数が多いだけですので、データベースを使う場合と比べどの程度サーバスペースを消費するのか分かりません。
また、これはよく分かりませんが、inodeは共有スペースにあると思いますので、消費しすぎて追い出されると言うことはあるかもしれませんね。
しかし、多くのファイルをアップロードする人はいますので、どこに閾値があるのかはよく分かりません。

＞何人もの人ががDBがいいと説明しているのに屁理屈を並べて聞く耳を持たない。
私にとっては屁理屈などではなく、真面目に考えて書いているつもりです。
書き方が悪く誤解させていましたら、申し訳ありません。
先の解答にinodeの容量について説明がありましたが、かなり大きな領域がありDBとしても成立するのではないかと思っています。違うのでしょうか？
また、今本契約しているサーバ（ライト）ではDBが使えませんので、何とか代用する方法を模索しているというのもあります。お小遣いが少なく、正直スタンダードを維持し続けるのはきついところがあります。

回答No.8

oktuburero

>仮に書き換える必要がある場合、サーバに書き換えの為のCGIスクリプトを用意しておき(例えば、下記のような感じです)、
>ローカルPCから書き換えたいクエリーを送り、サーバ上のCGIで受け取り、書き換えと同一かチェックしその結果をHTML表示で返すという感じです。
>クエリーの送信も、何を送信して、どういった結果が返ってきたのか保存しておきます。
ソース読んだけどopenに対する例外処理が書かれてない。
2ファイル一セットなのに片方が更新されてももう片方が更新エラーが出た場合の処理が不透明。

>045-0024を検索した場合、その答えは、「北海道 岩内郡岩内町 野束」のみですので1件1データと考えています。
曖昧検索は絶対にないと言うことですね。
後から必要になって拡張する可能性は絶対にゼロですね。

>DBの場合、ここまで簡単なデータの引き出しでもログイン作業などもありサーバ上で行う事と比較するとオーバーヘッドが発生しないでしょうかね？
SQLさえ送信すればDB側はバイナリの実行ファイル上で動きます。
すべてスクリプト言語で処理するよりはデータ処理は高速です。
それとDBに接続してSQLを発行してDBを閉じる処理をしなければDBと接続され放しになるので
それほどオーバーヘッドは気にする必要は無いでしょう。

>サーバ上で長時間プロセスが動くとサーバの仕様だと思いますがkillされてしまったことがあります。
まさかと思うけどphpmyadminで大量のデータをSQLでインポートしようとしてないね?
PHPのタイムアウト時間やメモリサイズによっては自動でプロセス終了させられるぞ。
コンソールからインポートしましょう。

あっそれとサーバはさくらっていっていたけど共有サーバ?それともVPSや専用サーバ?
VPSや専用サーバならOSを選べるからLinuxも選択できるけど
共有サーバの場合さくらはLinuxではなくてFreeBSDだからね。
それとさくらの場合、共有サーバでもSQLiteも利用できるからね。
VPSや専用なら自分でインストールすればすむ問題。

質問者はサーバ仕様すら理解できてないほどの素人さんのみたいですね。
ファイルシステムで構築して痛い目を見ないと素人さんは理解できないようなのでもうなにも言うことは
ありませんからがんばってね。

補足

＞曖昧検索は絶対にないと言うことですね。
＞後から必要になって拡張する可能性は絶対にゼロですね。
その通りです。もしあった場合は、ローカル環境に全てのデータがありますので、再度考え直し構築するという感じです。

＞ソース読んだけどopenに対する例外処理が書かれてない。
＞2ファイル一セットなのに片方が更新されてももう片方が更新エラーが出た場合の処理が不透明。
これは、ロカール環境のCGIで処理します。
＞ローカルPCから書き換えたいクエリーを送り、サーバ上のCGIで受け取り、書き換えと同一かチェックしその結果をHTML表示で返すという感じです。
＞クエリーの送信も、何を送信して、どういった結果が返ってきたのか保存しておきます。
もう少し詳しく書きますと、ローカル環境のCGIでは、lwpで結果を取得して、 if($html !~ m/OK/) で判定を行い、OKを含まないレスポンスは全てエラーとして処理する為、サーバサイドでは特にエラー処理はしていません。

＞SQL
＞コンソールからインポートしましょう。
killされた原因はこれかもしれません。
cgiでSQLに接続して追加するプログラムを書いてやった記憶があります。
次行うときは気をつけます。

＞共有サーバの場合さくらはLinuxではなくてFreeBSDだからね。
＞それとさくらの場合、共有サーバでもSQLiteも利用できるからね。
ずっと、Linux系だと思っていました。また、SQLite もいけるんですね。
気づきませんでした。

>質問者はサーバ仕様すら理解できてないほどの素人さんのみたいですね。
そう書いたと思うのですが・・・
また、レスから感じ取って頂いていたものとばかり思っていました。
分からない単語はネットで調べてレスしています。

＞ファイルシステムで構築して痛い目を見ないと素人さんは理解できないようなので
＞もうなにも言うことはありませんからがんばってね。
どのような目に遭うのか教えて頂けると幸いです。
素人なりに考えて書いてはいるのですが、なぜ、ここまで言われなければならないのか
よく分かりません。文章だけですので勘違いですと申し訳ありませんが、
玄人が素人を馬鹿にしているようにすら感じます。

回答No.7

oktuburero

>仮に、間違っていたり、エラーが返れば何度かリトライ。それでもダメならエラーログとして保存し、原因を考えて手動で書き換える感じです。もしくは、書き換えたものを、FTPでそのフォルダーに直接入れても良いと思います。
だからね、その書き換えのエラーがあったかどうかのチェックはどうやるの?
2ファイルで一組として処理するのに片方だけが書き換えできてないかどうかを
数百万のファイルを人海戦術で確認していくのか?

>MySQLなどDBは素晴らしいと思うのですが（ほとんど使ったことはありませんが）、初心者には敷居が高く、
SQLiteでも使っておけ。
フリーの定番のDBだと難易度的には
PosrgreSQL > MySQL > SQLite
の順番ですね。

それと後からのメンテナンスについて考えているのか?
さらに言うとデータを一件一件表示するなら良いけど
複数のデータを一度に表示する場合、
1.ファイルオープン→2.ファイルの中身を取得→3.ファイルクローズ→1へ戻る。
って感じでものすごいオーバーヘッドが発生しますね。

>書き換えたものを、FTPでそのフォルダーに直接入れても良いと思います。
>なお、こういった作業も、DBの場合、DBサーバへログインしたり時間が掛かりますが、これですと、非常に単純なシステムができると思うのですが・・・
ファイル数分アップロードするのと
SQLで一つのファイルにまとめてあるのをアップロードしてSQL文で一気にデータを流し込むのとでも
どっちが効率良いと思いますか?

お礼

回答いただきありがとうございます。

＞だからね、その書き換えのエラーがあったかどうかのチェックはどうやるの?
＞2ファイルで一組として処理するのに片方だけが書き換えできてないかどうかを
＞数百万のファイルを人海戦術で確認していくのか?
今回の場合、データの更新はほとんどありませんのであまり念頭に置いていないところがあります。
仮に書き換える必要がある場合、サーバに書き換えの為のCGIスクリプトを用意しておき(例えば、下記のような感じです)、
ローカルPCから書き換えたいクエリーを送り、サーバ上のCGIで受け取り、書き換えと同一かチェックしその結果をHTML表示で返すという感じです。
クエリーの送信も、何を送信して、どういった結果が返ってきたのか保存しておきます。

サーバ上に設置するCGIの例
例えば、クエリが、
045-0024.html<>%E5%8C%97%E6%B5%B7%E9%81%93%20%E5%B2%A9%E5%86%85%E9%83%A1%E5%B2%A9%E5%86%85%E7%94%BA%20%E9%87%8E%E6%9D%9F.html
であった場合、

($postalnumber,$address) =split(/<>/,$query);

oepn(F,">./file/$postalnumber);
print F $address;
close(F);

oepn(F,"<./file/$postalnumber);
$address_c = shift <F>;
close(F);

if($address_c ne $address){ print "ERR_compare"; exit;}

oepn(F,">./file/$address);
print F $postalnumber;
close(F);

oepn(F,"<./file/$address);
$postalnumber_c = shift <F>;
close(F);

if($postalnumber ne $postalnumber_c){ print "ERR_compare"; exit;}

print "OK";

exit;

＞SQLiteでも使っておけ。
単純なことしかしませんので、ほんとに簡単なもので良いのでが、さくらの場合MySQLしか対応がないようです。できれば、ライトプランでDBもないプランで済ませたいと思っています。また、DBが落ちていたり、レスポンスが遅れたりすることが多いようで、通常のレンタルサーバスペースの方がエラーが起こりにくいように感じています。

それと後からのメンテナンスについて考えているのか?
＞さらに言うとデータを一件一件表示するなら良いけど
今回は本当に単純な為（DBを使うのが無駄なくらい）、一件一データで、更新も滅多にないためあまり深くは考えていません。
データそのものはローカルにありますので、必要であれば、削除や上書きすれば良いと思っています。
なお、045-0024を検索した場合、その答えは、「北海道 岩内郡岩内町 野束」のみですので1件1データと考えています。
DBの場合、ここまで簡単なデータの引き出しでもログイン作業などもありサーバ上で行う事と比較するとオーバーヘッドが発生しないでしょうかね？

＞ファイル数分アップロードするのと、
＞SQLで一つのファイルにまとめてあるのをアップロードして
＞SQL文で一気にデータを流し込むのとでもどっちが効率良いと思いますか?
ローカル環境で大量のファイルをZIP圧縮してアップロード、その後Unzipであればいかがでしょうかね？
ちなみに、SQLへデータを入れる場合、サーバ上で長時間プロセスが動くとサーバの仕様だと思いますがkillされてしまったことがあります。

回答No.6

SaKaKashi

ま、そこまで詳しく考えているのならやってみてください。
実際の性能をご自身で確認してください。

お礼

回答いただきありがとうございます。
単純なファイル（35万ファイル程度）で試してみたところサーバエラーなども起こらず表示されました。
ちなみに、DBを使ったものは、時間帯によってつながらなくなることがあり、安定性がいまいちに感じています。あたりの悪いサーバだった可能性もあります。
限られた予算の中最大限のパフォーマンスを引き出すにはLinuxのファイルシステムはDB並に効率的ではないかと思い始めているのですがいかがでしょうかね？

回答No.5

noyuo

私も、ファイルシステムでデータベースの代用は無理があると思います。

１）バックアップのことは考えてますか？（大量のファイルをバックアップするのはたいへんですよ）

２）データの追加／削除を繰り返す内に、ファイルシステムだと無駄な領域が散らばったり、
ハードディスクのあちこちにアクセスするようになり、段々処理性能がダウンする可能性があります。（途中のinodeが満杯になると、ハードディスク上の遠く離れたところに新しいinodeが作られます。（inode内のソートもいちいち発生するのかな？）

３）ファイルの中にどんな情報を入れるのかわかりませんが、情報の項目追加などがのちのち発生する可能性はないの？・・・・あったら大変ですよね。

補足

回答いただきありがとうございます。

今回のように限られた用途の場合、

1）＞サーバ上でバックアップはせず、ローカル環境にあるデータしか使いませんのでバックアップは不要です。

2）＞追加削除によりパフォーマンスが落ちるのは問題ですね。ただ、どの程度で発生するのかは非常に気になるところです。

3）＞これらがほとんど無い情報ですのでDBよりも更新不要なホームページや固定画像に近い性質です。とりあえず、追加の予定はありません。もしあるとすれば、新たに、./file2/等作り対応するかもしれません。

テストで、35万程度作成してみたところ、特に問題無く動作しました。
更新がほとんど不要な場合、時間帯によってはデータベースよりもレスポンスが良いような気がします。
こんなものなのでしょうかね？

回答No.3

oktuburero

>また、名前から電話番号を調べられるように、逆パターンも用意する。
これって変更があった場合の整合性を取るにも処理を考えないと駄目だよね。
定番だと片方の更新はうまくいっても一方の更新でなにかしらのエラーで更新されなかった場合に
整合性が取れなくなりデータに矛盾が発生するよね。
そのような例外処理をどうするかも考える必要があるね。
ついでにデータが5000万件ならファイル数は1億必要って事ですね。

ファイルシステム毎にi-nodeっていくつだろう?

補足

回答いただきありがとうございます。

SaKaKashiさんの補足にも記載させて頂いたのですが、レンタルサーバに問い合わせたところ、上限は500万ファイルとのことでしたので、データ数は250万、余裕を見て200万くらいと考えています。

例えば、書き込み時に
----045-0024.htmlファイル内容----
北海道 岩内郡岩内町 野束
---------------------------------
ファイル名は、UTF8でURLエンコードしたものです。
----%E5%8C%97%E6%B5%B7%E9%81%93%20%E5%B2%A9%E5%86%85%E9%83%A1%E5%B2%A9%E5%86%85%E7%94%BA%20%E9%87%8E%E6%9D%9F.htmlファイル内容----
045-0024
----
と2ファイルになります。

書き換えや追加では、2ファイルを、書き込んだ後、両方のファイルを開き、単純に中身を比べるだけですので簡単に思います。
ちなみに、書き換えは、サーバ管理者一人が、上書きモードでする為、排他制御も不要だと思っています。それでも、サーバエラーなどで書き換えができないこともあると思いますが、仮に、間違っていたり、エラーが返れば何度かリトライ。それでもダメならエラーログとして保存し、原因を考えて手動で書き換える感じです。もしくは、書き換えたものを、FTPでそのフォルダーに直接入れても良いと思います。
なお、こういった作業も、DBの場合、DBサーバへログインしたり時間が掛かりますが、これですと、非常に単純なシステムができると思うのですが・・・
もちろん、MySQLなどDBは素晴らしいと思うのですが（ほとんど使ったことはありませんが）、初心者には敷居が高く、安い共有では動作も不安定とも聞き、wordpressなどもDBエラーで良く落ちているサイトを見かけますし、安価レンタルサーバのDBの安定性には疑問を持っています。この場合、こういった方法もありではないかと思っていますがいかがでしょうかね？
inodeはよく分かりませんが（wikiを見ますとDBのIndexみたいなもの？）、MySQLのように難しい作業をしなくても、利用者が気にしなくても、サーバ上のOSが勝手に作ってくれるのであれば、下手にDBを使うよりも安定しているのではないかと思います。

回答No.2

SaKaKashi

まず、5000万のファイルをどう配置するかです。
全てを1つのディレクトリ配下に置くとすると、ディレクトリ配下のファイル数が多すぎでしょうね。
RHELではたぶん配置できないでしょう。
仮に配置できたとして、ファイルの追加や、更新、削除の度にディレクトリの更新が行われるので
ものすごい負荷です。
検索を考えると、５，０００万件のファイルを探すと単純平均で２，５００万のファイルを検索することになります。
1件探すのに２，５００万件のファイルの検索ですか。

データベースだと、ファイルはせいぜい実態のデータと索引を電話番号と名前に付けても、
ファイルは３個ですみます。ファイルは大きいですけどね。
検索を考えると、索引の形式は通常、B-Tree格納ですから５，０００万件でも２６回索引を検索すればいいですね。

この２つの平均検索回数を比較するとどちらが負荷が低いのかわかりますよね。
２，５００万対２６

補足

回答いただきありがとうございます。
せっかく回答頂いたのですが、当方の書き方が悪く、言いたいことが伝わっていないようですので、もう少し詳しく説明させて頂きます。

例えば、レンタルサーバで使う場合。

>まず、5000万のファイルをどう配置するかです。
>全てを1つのディレクトリ配下に置くとすると、ディレクトリ配下のファイル数が多すぎでしょうね。
こちらについては、CSVファイルをCGIで分解したり、ローカルで作成してZipでまとめたものを解凍するとできると思います。
#CGIを使い（perlの場合）
while(@csv){
($postal_number,$address) = split(/\,/,$_);
open(F,">./file/$postal_number.html");
print $address;
close(F);
}

ファイルの内容は、
----045-0024.htmlファイル内容----
北海道 岩内郡岩内町 野束
---------------------------------

----049-1103.htmlファイル内容----
北海道 上磯郡知内町 重内
---------------------------------

設置場所は、例えば、レンタルサーバの場合、fileフォルダを作成してこの中に、1ファイルの中に一つの情報を入れたものを作ります。
./file/045-0024.html
./file/049-1103.html
OKWEBの仕様のようで、記述の一部がアスタリスクになっている場合がありますが実際は数字です。
以下500万ファイルほど続く
※5000万はサーバの上限に達する為無理らしいですが500万ファイルですとできるところが多いようです。

>検索を考えると、５，０００万件のファイルを探すと
>単純平均で２，５００万のファイルを検索することになります。
>1件探すのに２，５００万件のファイルの検索ですか。
これは、ファイルの中身を探す場合だと思います。

例えば、perlで呼び出す場合、
open(F , "<./file/03-1234-***9.html");
print <F>;
close(F);
これですと低回数（Linuxのファイル構造はDBになってるから実質数回？）で呼び出せないでしょうか？

または、普通にネットから、
http://dommain/file/03-1234-***9.html
とドメインの横に郵便番号+.htmlを記述するだけでDBなど使わなくてもすぐに呼び出すこともできます。

これであれば、DBを使わない為、速いように思いますがどうなのでしょうか？

回答No.1

Tacosan

「Linux のファイル管理」ではどうにも判断のしようがありません.
ext と xfs だって全然違うんだから.
いずれにしても「1つのディレクトリにファイルを 50万も作る」のはアホだと思う.

補足

回答いただきありがとうございます。

当方初心者の為、ファイルシステムの詳しい違いまで分かりませんが、（自宅サーバも無理なレベルでレンタルサーバをレベルです）
SaKaKashiさんの補足にて記載させて頂きましたが、こういった場合どうなのでしょうか？

＞いずれにしても「1つのディレクトリにファイルを 50万も作る」のはアホだと思う
なぜ、アホなのかよく分かりませんが、WindowsXPの場合、一つのフォルダーに大量のファイルを保存しても特に問題無かったりします。フォルダーを開くと流石に重いですが、ファイル名を指定して直接開くとすぐに開きます。