トップページ⇒tech
120コメント30KB

Webに向いた新しいファイル構造を考える

■ このスレッドは過去ログ倉庫に格納されています
00011NGNG
HTMLや画像ファイルを1つ1つファイル化するのが一般的な現行の
ファイル構造は、確かに構造が単純で更新が容易ですが、
大量のファイルを伝送したりファイル処理する際には、
ファイルサイズが小さい故にオーバーヘッドが大きく
処理効率が悪くなってしまいます。
また、例えば、検索システムにおいてはWWWロボットが世界中の
数十億というHTMLファイルを収集するので、i-node不足が
課題となります。

だからといって、データベースで一括管理するのでは、
直接ファイルを取得する場合よりも遥かにサーバ負荷が
高くなりますし、応答時間も長くなりがちです。

これらの問題を解決するような研究は無いのでしょうか?
0076デフォルトの名無しさんNGNG
>>66
プロクシで圧縮して送るという方法もあるな。
0077デフォルトの名無しさんNGNG
>>76
ウェブサーバーとプロクシサーバーの間は圧縮していないデータが通るから変わらないのでは?
0078デフォルトの名無しさんNGNG
>>75 ごめん。ファイルシステムとファイル構造を読み違えてた。
0079デフォルトの名無しさんNGNG
たくさんのファイルにバラけてるのは、キャッシュを有効に活用できるから。
同じ画像を違うページから参照すること、良くあるからねぇ。
たしかに、用途によっては1つのファイルにまとめるのが便利ってこともあるが。

小さいファイルが山ほどあるとオーバーヘッドが、という話は、
これがhttpリクエストを何度も送らなきゃならない/そのたびに
TCP接続のハンドシェークが起きる、というような話であるなら、
Keep-Aliveとパイプラインで解決だ。

ところで、i-node不足ってことは、サーバのファイルシステムを
考え直せ、ってことかいな? Webの構造とは関係ない次元だと思う
のだが?
0080デフォルトの名無しさんNGNG
今時の鯖マシンならメモリー2Gとか平気で詰めるから
RAMディスクでマウントすればいい。
CGIはC/C++で書いてmmap。dbは使用しない。
0081デフォルトの名無しさんNGNG
>>79 そうそう、これって「ファイルシステム」の話なのか、
「ファイル構造」の話なのか、どっちよ?
0082>79NGNG
Webに公開するときにFTPで転送するけど
FTPにはkeep-aliveに相当するものは無いと思う。
0083デフォルトの名無しさんNGNG
>>80
1 の話からすると webarchive や google クラスを想定してそうだ。
google のキャッシュって何GB?それともTB行ってるんだっけか?
0084 NGNG
           
0085デフォルトの名無しさんNGNG
1Gページ * 10kB/ページ = 10TB
0086デフォルトの名無しさんNGNG
>>82
NOOPとか。
0087デフォルトの名無しさんNGNG
>>82
ではFTPの代わりにscpを。
0088デフォルトの名無しさんNGNG
sage厨房に言っても無駄かもしれないけど
コネクション張った状態でも取得回数分の通信遅延は避けられないと
思うんですけどー
0089デフォルトの名無しさんNGNG
>>88
いやだから、パイプライン使えばいいじゃん、って。

HTMLの構造的な問題に着眼するなら、ファイルをバラバラに
取得するのは欠点というより、キャッシュを有効に活用する
ための利点である、というふうに思うのだが、間違いかな?
0090でもNGNG
>89
実装が面倒だから自分でコード書くときは逐次処理しちゃうよね
0091デフォルトの名無しさんNGNG
うん
0092 NGNG
    
0093デフォルトの名無しさんNGNG
ち
0094デフォルトの名無しさんNGNG
ハミングバードっていうファイルシステム イイ
0095デフォルトの名無しさんNGNG
Love Wing 〜
0096デフォルトの名無しさんNGNG
っていうか、監視されたりして何でもアリではなくなってきたので、
独自プロトコルと独自ファイルフォーマットで比較的Closedな
環境キボン。
2CH/IPと、2CTプロトコル、2ctファイル形式。

定義は頼んだ。
0097デフォルトの名無しさんNGNG
>>96
HTTP(TCPまでも?)を使わない独自プロトコルの2chもどきシステムで、
匿名性とデータ転送の効率をアップさせたいと言うのは面白い考えだと思う。
だが、一言言わせてもらうと、それはスレ違いだ。
0098デフォルトの名無しさんNGNG
単にGETをPICKとかにしてポートも変えれば妙に互換性の高いHTTPとは違ったプロトコルが閑静だw
0099 NGNG
       
0100デフォルトの名無しさんNGNG
>>97
おもしろそうだがクライアントアプリの開発が難しくなるんじゃない
誰かが一緒に部品も提供すればいいのか。
0101デフォルトの名無しさんNGNG
やり方が MS ちっくだな(w
0102 NGNG
         
0103デフォルトの名無しさんNGNG
>>97

TCPまでもってのは難しいのでTTCPを使うとかは?
単なるミーハー?
0104デフォルトの名無しさんNGNG
>>96
変換プロキシかませばいいんじゃない。
サーバーとローカルで。
さらに盗聴されても大丈夫なように画像とかに偽造する。
0105デフォルトの名無しさんNGNG
×いいんじゃない。
○いいんじゃない?
0106テストNGNG
テキストは圧縮して送受信してもコストが見合うと思うが、
すでに圧縮されている画像や動画を圧縮してもしょうがない。

新しいプロトコルを作るなら、
テキストはテキストだけ、画像は画像だけ、動画は動画だけのプロトコルを作って欲しい。

そもそも、画像とテキストが同じ http プロトコルというのが嫌い。
汎用性持たせ過ぎは嫌い。


日本語も表示できるようにしてしまったため、
文字コード処理がめんどうくさくなった。

欧米人もちゃんとした英語使えないんだから、英語だけでいい。

日本語表示したいなら、特定コード以外は、
エラーとしてはじくようなプロトコルを作って欲しい。

自殺したプログラマの何割かは、日本語コードのせい。
0107デフォルトの名無しさんNGNG
>>106
>画像は画像だけ、動画は動画だけの
その画像なり動画なりも特定の形式のみサポートでしょ?(特定の形式のみに最適化しないとそのプロトコルはただのバイナリ転送プロトコル)

技術の発展を遅らせる。
0108デフォルトの名無しさんNGNG
>>106
つーか逆に単純なしくみで全てをまかなえるほうが理想だと思うが。

HTTPは無計画にオプションを追加しまくった形跡ありありで
機能の重複も多いし
すでにお世辞にも単純なプロトコルとは言い難い。

クライアントを作るだけなら全ての仕様を使う必要がないから
まだいいが
まともに仕様を満たすサーバーやプロクシを作ろうとすると
死ぬ思いをする。
これは外部に開かれたCGIやWebアプリも同様。
0109 NGNG
   
0110 NGNG
      
0111デフォルトの名無しさんNGNG
そういやbモバのproxyは画像の画質落として速度稼いでたな。
なんか不安定みたいだけど。
0112 NGNG
         
0113デフォルトの名無しさんNGNG
MIMEタイプとかいらないよな。
0114 NGNG
      
0115デフォルトの名無しさんNGNG
最初に GIF ファイルフォーマットの仕様を見たとき、なるほど
これがネットワークでやり取りされるデータの構造なんだ、と感動した。
0116 NGNG
          
0117デフォルトの名無しさんNGNG
え?
0118 NGNG
          
0119デフォルトの名無しさんNGNG
自動ageスクリプトの練習かよ。
規制ゆるくなった?
0120デフォルトの名無しさんNGNG
GIFはコンピュサーブ出身です。
■ このスレッドは過去ログ倉庫に格納されています