UJP - 旧ブログ

Life is fun and easy!

不正IP報告数

Okan Sensor
 
メイン
ログイン
ブログ カテゴリ一覧


2008 年 3 月
      1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31      


Search
ファイルの保存先
2008-03-14
 7〜8年前の小規模サイトだと,rsyncとかその類似ソフトによって,複数台のサーバへデータをシンクロしていました. この時代はサイト管理者が素材をアップロードしてユーザがダウンロードするという利用方法なので,ユーザが利用する時間を管理者がコントロールでき,シンクロナイズが完了するまで時間がかかっても良いものでした.
 そのうちこれはファイル数が多いと破綻するとか,フロントのWebサーバが増えてくるとこれも内部転送トラフィックが破綻する仕組みです.

 次のフェーズでは,ファイルサーバにファイルを置きました. そうするとサイト規模が大きくなるとWebサーバ側からマウントをするだけで良いので楽です.
 これもある程度は良いのですが,大規模サイトになってくるとファイルサーバに負荷が集中することになり,スケーラブルでは無くなります.
 あまりにも大規模だと,CDNを利用して運用するというのもありますが,タイムラグとコストについてよく調べる必要があります.

 最近みたシステムでは,データベース内に画像ファイルを格納していました. 確かに,これも在処なと思える様になりました.

 数年前,データベースメーカの人たちと話をしたのですが,あるメーカはファイルのようなバイナリデータも,全てデータベース本体に格納する方針でした. もう1つのメーカでは,ファイルはファイルシステム上に格納し,インデックス(ファイルパス)をデータベースに格納するというアーキテクチャでした. 

 当時はデータベースのバックアップ時間とかパフォーマンスとかを考えるとファイルシステム上に置く方が説得力があったのですが,たしかに最近はデータベースでも良いかもしれません.

1.サーバ負荷対策としレプリケーションでスケールアウトが適用できる.
2.データベースキャッシュ等の技術も適用可能
3.バックアップもレプリケーション先で行えば良い.
4.データベースも安い.

 数KBくらいのデータファイルだったら,逆にデータベースの方がメリットが多いかもしれません.

Back

広告スペース
Google