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

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

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

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

これらの問題を解決するような研究は無いのでしょうか?
001613NGNG
TAD
0017デフォルトの名無しさんNGNG
>>1
keep-alive と pipelining ではダメだってことか?
0018デフォルトの名無しさんNGNG
TADかよっ!
001912NGNG
>>16
ハイハイ。がんばって普及させてね。
0020デフォルトの名無しさんNGNG
12 も文句だけだな。
002112NGNG
>>20
はぁ ? 少なくとも俺は、画像ファイルを別にする意味はあるってことを
示してるぜ。それとも理解できなかったのか ?
0022デフォルトの名無しさんNGNG
>>1
ネットに適した file system の研究なんて腐るほど行われてる。
とりあえず検索してみ。
0023デフォルトの名無しさんNGNG
ヘッダにサイズが書いてあるチャンク構造にして有れば、
Webサーバ側で、画像チャンクを飛ばして送信すれば
いいんじゃないの?
0024!20NGNG
>>21
別に新しいことでもなんでもないじゃん。
0025デフォルトの名無しさんNGNG
1 のいう処理効率のオーバーヘッドが具体的に
OS、httpd、回線のどこに生じるものなのか分からん。
何だか OS 側の話のようだが、
どの程度のスケールのウェブサービスでどの程度の無駄が生じてるか
想像じゃなくて実際のデータはないのか?
0026デフォルトの名無しさんNGNG
クライアント側でリクエストをまとめてデータとして送信する。
サーバ側でそれ解析して、必要なデータを最適化して固めて送る。
002720NGNG
>>23
サーバー側で、選択するってことね。良いかも知れんけど、2ch みたいな
忙しいサーバーだと負荷が辛いかも。やっぱクライアント側で、分散処
理って言う方が良いんじゃないのかなぁ。

>>24
そだよ。新しいことは書いてないけど (思いつかねーからな)、今の方法を
とる理由は示してるだろ。>>13 見たく単にダメだだけ書いててなんか
楽しい ?
0028デフォルトの名無しさんNGNG
では、TCP/IP と HTTP と NTFS/ext2 を捨てるところから始めよう。
0029デフォルトの名無しさんNGNG
じゃあ、NFSでファイル転送しよう。
0030デフォルトの名無しさんNGNG
>>27
分散させるとサーバ側の帯域消費なんかは軽くなるだろうけど
全体では無駄が出てくるし、どうしても遅延が出てくる。
トレードオフやね。
0031デフォルトの名無しさんNGNG
100万ファイル(1M個)収集するのに、回線遅延が1要求あたり
100msecかかるとして、0.1Msec=10万秒=28時間のロスだね。
もったいない、もったいない

1万ファイルのHTMLをEUCに変換するとして、
1ファイルあたりfile read,encode,file saveに100msecかかるとして
1000秒=17分のロスだね。
もったいない、もったいない

時間は有効に使いましょう。
0032デフォルトの名無しさんNGNG
TCPが良くない。UDPで十分だろ。
0033デフォルトの名無しさんNGNG
>>32
おい正気か ? 化け化けのページしか表示できないブラウザが続出すると
思われ...。
0034デフォルトの名無しさんNGNG
>>32
っていうかトランスポート層いらない。
0035デフォルトの名無しさんNGNG
もったいなーい
もったいなーい
0036デフォルトの名無しさんNGNG
画像ファイルは、多少化けてても気付かないだろ?
0037デフォルトの名無しさんNGNG
>>36
ヘッダが化けたら、ぐしゃぐしゃになるぞ。
0038デフォルトの名無しさんNGNG
ヘッダ部分だけは、CRCとかでチェックして再送させるに決まってるだろ。
そこまで言わせるなよ。
0039デフォルトの名無しさんNGNG
lynxで。
0040デフォルトの名無しさんNGNG
>>38
なんだ、ネタかよ。バカは、あっち行ってろ。
でかい画像の本体部なら TCP でもお前らが作るへぼルーチンよりまともな
速度が出てると思うぞ。
0041デフォルトの名無しさんNGNG
そうだな、予めlynxでレンダリングしたテキストで送れば
サイズが少なくて済む。
0042デフォルトの名無しさんNGNG
>>41
おいおい、お前ら大丈夫かよ。ページ内の画像がクライアントから
要求されることは知ってるよな。それとも、タグの分だけ少なくなると
言いたいのか ?
0043デフォルトの名無しさんNGNG
lynxは画像要求しないだろ…
0044デフォルトの名無しさんNGNG
>>43
ライントレーサでAA化w

さぁ。みんなでRFCに行こう!
0045デフォルトの名無しさんNGNG
>>43
ああ、やっぱりそう言う知識しかないわけね...。ちなみに IE でも画像
要求しないように設定できることも知らないのか ?

>>43
> ライントレーサでAA化w
変換プログラムがそれなりだったら良いかもしれん。2ch で plug-in
作るか...。
0046デフォルトの名無しさんNGNG
45 はネタしか書かんのか?
0047デフォルトの名無しさんNGNG
>>45
ぷぷっ、それしか言えないのか ? ちなみに、Lynx でも plug-in 入れた
ら、画像も要求するぞ。バカは、とっとと帰ってね。

まあ、後半はネタと言われればそうだがな。
0048デフォルトの名無しさんNGNG
ああ、後付けクンか。 とか、Linxのレンダリングの話だろ…
0049デフォルトの名無しさんNGNG
とか…
0050デフォルトの名無しさんNGNG
lynxだった。
0051デフォルトの名無しさんNGNG
>>48
Linx って言う Typo を直す前に、ちゃんとした日本語にしろよ。
0052デフォルトの名無しさんNGNG
画像にフォーカスした既存技術には、転送時リサイズ・減色があるな。
モノクロ画像にしてくれる delegate サーバがどっかにあった。
intel あたりも転送時圧縮について研究してたはず。

ただ、ユーザが見た目のきれいさを求める方向にある以上、
利用される機会は少なそうだ。
ユーザとしては広告画像だけ選択的に適用したいところだが、
サーバ側としてはオリジナルで見せなきゃいけないものだしなあ。

つうかファイル構造じゃないやん。
00535NGNG
>>12
Netscape 4.0 mailの登場前後に、MIMEタイプ multipart/related を使って、
ページとインライン要素 (リンク含む)を1つのファイルにまとめる技術はあった。

MIME multipart/relatedの、コンテンツ-リンクの表現は、こんな感じ。
 コンテンツ側:Content-IDヘッダーで、コンテンツ内ユニークなIDを付ける
     【例】Content-ID: multipart/related<[email protected]>
 参照側:擬似プロトコル名 cid: を使って、コンテンツのユニークIDを参照
     【例】<BODY BACKGROUND="cid:[email protected]">

これって、obsolateな技術なんでしょかね?
00545NGNG
↑訂正
○【例】Content-ID: <[email protected]>
×【例】Content-ID: multipart/related<[email protected]>
0055デフォルトの名無しさんNGNG
>>43 ライントレーサでAA化
って、そーゆープログラムあるの?

HTTPの要求ヘッダー "accept-type"かなんかで、
表示可能なコンテンツの種類を指定できるから、
画像を欲しがらないブラウザを判別して、
サーバ側でテキスト代替表現を送る事は可能だと思われ。
(漏れはnetpbmの濃淡画像表現くらいしか思い付かなかったけど(w)
0056 NGNG
         
0057デフォルトの名無しさんNGNG
ファイル1つ1つに,メモ欄付きのファイルシステムがあればなぁ…
テキスト以外のファイルの検索性が上げれる気が.
0058デフォルトの名無しさんNGNG
>>54
RDF
0059デフォルトの名無しさんNGNG
まつがえた
>>57
ってやりたかったんだ->RDF
0060デフォルトの名無しさんNGNG
>>51
ぼやいてるだけなのに、ちゃんとした日本語もなにもないだろ。
0061デフォルトの名無しさんNGNG
<img src="data:AHUEHBeubdeybouiBEbYURDB;image/gif">
とかできるようになるスキームがW3Cとかで提案されてなかったっけ?
0062デフォルトの名無しさんNGNG
提案企業と実装系次第...
って、IE(かJava)で採用しないと、普及しにくいんだろーな。
0063デフォルトの名無しさんNGNG
検索システムがもってるキャッシュって、単一ファイルじゃないの??
0064デフォルトの名無しさんNGNG
ページ内のHTMLと画像ファイル等を単一ファイルにまとめるよりも、
全ページのHTMLを単一ファイルにまとめるほうが効果的だと思うけど。
通常は1ページ内に画像ファイルはせいぜい数十個程度しかないでしょ。
0065デフォルトの名無しさんNGNG
>>57
Macintosh HFS
0066デフォルトの名無しさんNGNG
なぁ、htmlをサーバーで圧縮してから転送してクライアントで
復元することでデータの転送量を減らすっていうのはないの?
ちゃんとしたxhtmlなんかは結構圧縮できそうなんだけど。
0067デフォルトの名無しさんNGNG
それは2ちゃんの2001/8/22危機で導入済みのgzip圧縮。
gzip圧縮指定に必要なヘッダの名前は忘れた...
0068デフォルトの名無しさんNGNG
ほぅ。そういうのがあるのか。
それって普通のブラウザ・普通のWebサーバでつかえるの?
0069デフォルトの名無しさんNGNG
>>66
mod_gzip。
http://www.planet-green.com/linux/mod_gzip.html

最近のWWWブラウザはたいがいgzip圧縮に対応している(Accept-Encoding: gzipを
送ってくる)ので、サーバ側の負荷よりも回線容量を重視したい場合には有効。
0070デフォルトの名無しさんNGNG
あっ本当だ。今見たら2ちゃんねるちゃんと圧縮されてるじゃん。
調べがたりんかったスマソ。そして>>67 >>69ありがと。

これって要求のたびに圧縮してるのかな。
静的なhtmlなら一度だけ圧縮しておけばCPU不可はほとんどかからないんじゃ?
そういうオプションもあるのかな? もうすこし調べてみるわ。

# うちのプロバイダで使えるのだろうか?
0071デフォルトの名無しさんNGNG
>>70
HTMLファイルじゃないがftp://ftp.turbolinux.co.jp/pub/TurboLinux/にその例がある。
0072デフォルトの名無しさんNGNG
1 はどこいったんだ?
このままだとおそらくサーバ側の話にならないぞ。
0073デフォルトの名無しさんNGNG
sageでの質問はネタ
0074デフォルトの名無しさんNGNG
>>57 NTFS もそうだよ。

>>1 の疑問に素直に答えるならば、i-nodeが足らないなら増やせばいいし、
オーバーヘッドは問題にならない(なると思うのならその理由を示してくれ)し、
だとしてもそれはOSでキャッシュもったり先読み&遅延書き込みしたり、
でいいじゃん。っていうか、DBにしたところで速くならないよ。
0075デフォルトの名無しさんNGNG
ディスクアクセス分のオーバーヘッドでしょ
10000ファイルを一つ一つ処理するより、1ファイルにまとめて処理したほうが
ディスクのシーク時間が節約できる・・・はず
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
          
■ このスレッドは過去ログ倉庫に格納されています