5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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

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

これらの問題を解決するような研究は無いのでしょうか?


2 :デフォルトの名無しさん:02/05/05 14:18
2get?

3 :デフォルトの名無しさん:02/05/05 14:30
B+-Treeが最高。


終了
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

4 :デフォルトの名無しさん:02/05/05 14:32
3E 3E 01 20 A8 AF C3 D6 BC
> > 1   イ ッ テ ヨ シ

5 :デフォルトの名無しさん:02/05/05 14:32
欧米でよく使われている携帯電話用Webフォーマット HDML って、
そんな感じじゃなかったっけ。

身近な所では、Windowsの圧縮htmlヘルプ(.httだっけ?)とか、
Javaのjarヘルプも、そんな感じで使われている。


6 :デフォルトの名無しさん:02/05/05 14:37

























7 :デフォルトの名無しさん:02/05/05 14:41
http://pc.2ch.net/test/read.cgi/hp/1018053359/l50

ここで新ファイルフォーマットの議論が一回決着してる。

8 :デフォルトの名無しさん:02/05/05 14:55
>>7
議論になっていないと思う。

9 :デフォルトの名無しさん:02/05/05 14:59
1999年当時の2chと違って、最近の2chはすっかり議論できない所に
成り下がってしまったなあ。有名サイトの宿命だろうが凄く残念でならない(´ー`)


10 :デフォルトの名無しさん:02/05/05 15:00
>>9
じゃあこなければ?

11 :デフォルトの名無しさん:02/05/05 15:29
.mht

12 :デフォルトの名無しさん:02/05/05 16:06
>>1
まあ、言いたいことはある程度理解できる。確かに一回しか使わない画像
なんかだと、MIME かなんかでその場に組み込めれてもいいと思う。
でも、世の中画像を表示できないブラウザもあるから、そう言うブラウザ
にとっては迷惑なだけだよね。

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

なんか誤解してない ?

>>7-8
>>8 の言う通りやろ。第一議題が違うし。バカ >>1 が騒いでいただけだ
し。

>>9
そう思ったら、自分がちゃんとした議論すればいいだけ。2ch の仕組みは
変わっていないぞ。

13 :デフォルトの名無しさん:02/05/05 16:10
テキストにエンコードするのは駄目だろ。

14 :デフォルトの名無しさん:02/05/05 16:18
2chもログが膨大にあるのに、1スレッドあたり1ファイルを割り当てて
いるから、全ログを収集しようとするとHTTPリクエストの発行回数が
凄いことになりそう。

15 :デフォルトの名無しさん:02/05/05 16:28
>>13
一々そんな細かいとこに突っ込むなよ。話の本筋と違うだろ。
もっといい方法があるならそう言うのをお前が提案しろ。

16 :13:02/05/05 16:35
TAD


17 :デフォルトの名無しさん:02/05/05 16:36
>>1
keep-alive と pipelining ではダメだってことか?

18 :デフォルトの名無しさん:02/05/05 16:40
TADかよっ!

19 :12:02/05/05 16:45
>>16
ハイハイ。がんばって普及させてね。

20 :デフォルトの名無しさん:02/05/05 16:47
12 も文句だけだな。

21 :12:02/05/05 16:50
>>20
はぁ ? 少なくとも俺は、画像ファイルを別にする意味はあるってことを
示してるぜ。それとも理解できなかったのか ?

22 :デフォルトの名無しさん:02/05/05 16:53
>>1
ネットに適した file system の研究なんて腐るほど行われてる。
とりあえず検索してみ。

23 :デフォルトの名無しさん:02/05/05 16:54
ヘッダにサイズが書いてあるチャンク構造にして有れば、
Webサーバ側で、画像チャンクを飛ばして送信すれば
いいんじゃないの?

24 :!20:02/05/05 16:54
>>21
別に新しいことでもなんでもないじゃん。


25 :デフォルトの名無しさん:02/05/05 17:07
1 のいう処理効率のオーバーヘッドが具体的に
OS、httpd、回線のどこに生じるものなのか分からん。
何だか OS 側の話のようだが、
どの程度のスケールのウェブサービスでどの程度の無駄が生じてるか
想像じゃなくて実際のデータはないのか?

26 :デフォルトの名無しさん:02/05/05 17:09
クライアント側でリクエストをまとめてデータとして送信する。
サーバ側でそれ解析して、必要なデータを最適化して固めて送る。


27 :20:02/05/05 17:12
>>23
サーバー側で、選択するってことね。良いかも知れんけど、2ch みたいな
忙しいサーバーだと負荷が辛いかも。やっぱクライアント側で、分散処
理って言う方が良いんじゃないのかなぁ。

>>24
そだよ。新しいことは書いてないけど (思いつかねーからな)、今の方法を
とる理由は示してるだろ。>>13 見たく単にダメだだけ書いててなんか
楽しい ?

28 :デフォルトの名無しさん:02/05/05 17:16
では、TCP/IP と HTTP と NTFS/ext2 を捨てるところから始めよう。

29 :デフォルトの名無しさん:02/05/05 17:19
じゃあ、NFSでファイル転送しよう。

30 :デフォルトの名無しさん:02/05/05 17:20
>>27
分散させるとサーバ側の帯域消費なんかは軽くなるだろうけど
全体では無駄が出てくるし、どうしても遅延が出てくる。
トレードオフやね。

31 :デフォルトの名無しさん:02/05/05 17:25
100万ファイル(1M個)収集するのに、回線遅延が1要求あたり
100msecかかるとして、0.1Msec=10万秒=28時間のロスだね。
もったいない、もったいない

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

時間は有効に使いましょう。


32 :デフォルトの名無しさん:02/05/05 17:29
TCPが良くない。UDPで十分だろ。

33 :デフォルトの名無しさん:02/05/05 17:31
>>32
おい正気か ? 化け化けのページしか表示できないブラウザが続出すると
思われ...。

34 :デフォルトの名無しさん:02/05/05 17:31
>>32
っていうかトランスポート層いらない。

35 :デフォルトの名無しさん:02/05/05 17:32
もったいなーい
もったいなーい

36 :デフォルトの名無しさん:02/05/05 17:34
画像ファイルは、多少化けてても気付かないだろ?

37 :デフォルトの名無しさん:02/05/05 17:37
>>36
ヘッダが化けたら、ぐしゃぐしゃになるぞ。

38 :デフォルトの名無しさん:02/05/05 17:39
ヘッダ部分だけは、CRCとかでチェックして再送させるに決まってるだろ。
そこまで言わせるなよ。

39 :デフォルトの名無しさん:02/05/05 17:47
lynxで。

40 :デフォルトの名無しさん:02/05/05 17:48
>>38
なんだ、ネタかよ。バカは、あっち行ってろ。
でかい画像の本体部なら TCP でもお前らが作るへぼルーチンよりまともな
速度が出てると思うぞ。

41 :デフォルトの名無しさん:02/05/05 17:49
そうだな、予めlynxでレンダリングしたテキストで送れば
サイズが少なくて済む。

42 :デフォルトの名無しさん:02/05/05 18:03
>>41
おいおい、お前ら大丈夫かよ。ページ内の画像がクライアントから
要求されることは知ってるよな。それとも、タグの分だけ少なくなると
言いたいのか ?

43 :デフォルトの名無しさん:02/05/05 18:36
lynxは画像要求しないだろ…

44 :デフォルトの名無しさん:02/05/05 18:59
>>43
ライントレーサでAA化w

さぁ。みんなでRFCに行こう!

45 :デフォルトの名無しさん:02/05/05 19:14
>>43
ああ、やっぱりそう言う知識しかないわけね...。ちなみに IE でも画像
要求しないように設定できることも知らないのか ?

>>43
> ライントレーサでAA化w
変換プログラムがそれなりだったら良いかもしれん。2ch で plug-in
作るか...。

46 :デフォルトの名無しさん:02/05/05 19:16
45 はネタしか書かんのか?

47 :デフォルトの名無しさん:02/05/05 19:24
>>45
ぷぷっ、それしか言えないのか ? ちなみに、Lynx でも plug-in 入れた
ら、画像も要求するぞ。バカは、とっとと帰ってね。

まあ、後半はネタと言われればそうだがな。

48 :デフォルトの名無しさん:02/05/05 22:50
ああ、後付けクンか。 とか、Linxのレンダリングの話だろ…

49 :デフォルトの名無しさん:02/05/05 22:50
とか…

50 :デフォルトの名無しさん:02/05/05 22:50
lynxだった。

51 :デフォルトの名無しさん:02/05/05 23:06
>>48
Linx って言う Typo を直す前に、ちゃんとした日本語にしろよ。

52 :デフォルトの名無しさん:02/05/05 23:24
画像にフォーカスした既存技術には、転送時リサイズ・減色があるな。
モノクロ画像にしてくれる delegate サーバがどっかにあった。
intel あたりも転送時圧縮について研究してたはず。

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

つうかファイル構造じゃないやん。

53 ::02/05/05 23:45
>>12
Netscape 4.0 mailの登場前後に、MIMEタイプ multipart/related を使って、
ページとインライン要素 (リンク含む)を1つのファイルにまとめる技術はあった。

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

これって、obsolateな技術なんでしょかね?


54 ::02/05/05 23:47
↑訂正
○【例】Content-ID: <part1.33833388.2ECC9355@netscape.com>
×【例】Content-ID: multipart/related<part1.33833388.2ECC9355@netscape.com>


55 :デフォルトの名無しさん:02/05/05 23:51
>>43 ライントレーサでAA化
って、そーゆープログラムあるの?

HTTPの要求ヘッダー "accept-type"かなんかで、
表示可能なコンテンツの種類を指定できるから、
画像を欲しがらないブラウザを判別して、
サーバ側でテキスト代替表現を送る事は可能だと思われ。
(漏れはnetpbmの濃淡画像表現くらいしか思い付かなかったけど(w)

56 : :02/05/06 00:00
         

57 :デフォルトの名無しさん:02/05/06 00:13
ファイル1つ1つに,メモ欄付きのファイルシステムがあればなぁ…
テキスト以外のファイルの検索性が上げれる気が.

58 :デフォルトの名無しさん:02/05/06 00:14
>>54
RDF


59 :デフォルトの名無しさん:02/05/06 00:15
まつがえた
>>57
ってやりたかったんだ->RDF


60 :デフォルトの名無しさん:02/05/06 00:27
>>51
ぼやいてるだけなのに、ちゃんとした日本語もなにもないだろ。

61 :デフォルトの名無しさん:02/05/06 00:30
<img src="data:AHUEHBeubdeybouiBEbYURDB;image/gif">
とかできるようになるスキームがW3Cとかで提案されてなかったっけ?


62 :デフォルトの名無しさん:02/05/06 00:37
提案企業と実装系次第...
って、IE(かJava)で採用しないと、普及しにくいんだろーな。


63 :デフォルトの名無しさん:02/05/06 00:48
検索システムがもってるキャッシュって、単一ファイルじゃないの??

64 :デフォルトの名無しさん:02/05/06 01:33
ページ内のHTMLと画像ファイル等を単一ファイルにまとめるよりも、
全ページのHTMLを単一ファイルにまとめるほうが効果的だと思うけど。
通常は1ページ内に画像ファイルはせいぜい数十個程度しかないでしょ。


65 :デフォルトの名無しさん:02/05/06 01:42
>>57
Macintosh HFS


66 :デフォルトの名無しさん:02/05/06 01:54
なぁ、htmlをサーバーで圧縮してから転送してクライアントで
復元することでデータの転送量を減らすっていうのはないの?
ちゃんとしたxhtmlなんかは結構圧縮できそうなんだけど。

67 :デフォルトの名無しさん:02/05/06 01:58
それは2ちゃんの2001/8/22危機で導入済みのgzip圧縮。
gzip圧縮指定に必要なヘッダの名前は忘れた...

68 :デフォルトの名無しさん:02/05/06 02:06
ほぅ。そういうのがあるのか。
それって普通のブラウザ・普通のWebサーバでつかえるの?

69 :デフォルトの名無しさん:02/05/06 02:18
>>66
mod_gzip。
http://www.planet-green.com/linux/mod_gzip.html

最近のWWWブラウザはたいがいgzip圧縮に対応している(Accept-Encoding: gzipを
送ってくる)ので、サーバ側の負荷よりも回線容量を重視したい場合には有効。

70 :デフォルトの名無しさん:02/05/06 02:35
あっ本当だ。今見たら2ちゃんねるちゃんと圧縮されてるじゃん。
調べがたりんかったスマソ。そして>>67 >>69ありがと。

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

# うちのプロバイダで使えるのだろうか?

71 :デフォルトの名無しさん:02/05/06 02:52
>>70
HTMLファイルじゃないがftp://ftp.turbolinux.co.jp/pub/TurboLinux/にその例がある。

72 :デフォルトの名無しさん:02/05/06 03:57
1 はどこいったんだ?
このままだとおそらくサーバ側の話にならないぞ。

73 :デフォルトの名無しさん:02/05/06 20:23
sageでの質問はネタ


74 :デフォルトの名無しさん:02/05/06 20:42
>>57 NTFS もそうだよ。

>>1 の疑問に素直に答えるならば、i-nodeが足らないなら増やせばいいし、
オーバーヘッドは問題にならない(なると思うのならその理由を示してくれ)し、
だとしてもそれはOSでキャッシュもったり先読み&遅延書き込みしたり、
でいいじゃん。っていうか、DBにしたところで速くならないよ。

75 :デフォルトの名無しさん:02/05/06 21:02
ディスクアクセス分のオーバーヘッドでしょ
10000ファイルを一つ一つ処理するより、1ファイルにまとめて処理したほうが
ディスクのシーク時間が節約できる・・・はず

76 :デフォルトの名無しさん:02/05/06 21:08
>>66
プロクシで圧縮して送るという方法もあるな。

77 :デフォルトの名無しさん:02/05/06 21:32
>>76
ウェブサーバーとプロクシサーバーの間は圧縮していないデータが通るから変わらないのでは?

78 :デフォルトの名無しさん:02/05/06 21:45
>>75 ごめん。ファイルシステムとファイル構造を読み違えてた。

79 :デフォルトの名無しさん:02/05/06 22:05
たくさんのファイルにバラけてるのは、キャッシュを有効に活用できるから。
同じ画像を違うページから参照すること、良くあるからねぇ。
たしかに、用途によっては1つのファイルにまとめるのが便利ってこともあるが。

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

ところで、i-node不足ってことは、サーバのファイルシステムを
考え直せ、ってことかいな? Webの構造とは関係ない次元だと思う
のだが?

80 :デフォルトの名無しさん:02/05/06 22:11
今時の鯖マシンならメモリー2Gとか平気で詰めるから
RAMディスクでマウントすればいい。
CGIはC/C++で書いてmmap。dbは使用しない。


81 :デフォルトの名無しさん:02/05/06 22:13
>>79 そうそう、これって「ファイルシステム」の話なのか、
「ファイル構造」の話なのか、どっちよ?

82 :>79:02/05/06 22:26
Webに公開するときにFTPで転送するけど
FTPにはkeep-aliveに相当するものは無いと思う。

83 :デフォルトの名無しさん:02/05/06 23:33
>>80
1 の話からすると webarchive や google クラスを想定してそうだ。
google のキャッシュって何GB?それともTB行ってるんだっけか?

84 : :02/05/07 00:00
           

85 :デフォルトの名無しさん:02/05/07 00:28
1Gページ * 10kB/ページ = 10TB


86 :デフォルトの名無しさん:02/05/07 01:48
>>82
NOOPとか。

87 :デフォルトの名無しさん:02/05/07 10:40
>>82
ではFTPの代わりにscpを。

88 :デフォルトの名無しさん:02/05/07 11:05
sage厨房に言っても無駄かもしれないけど
コネクション張った状態でも取得回数分の通信遅延は避けられないと
思うんですけどー

89 :デフォルトの名無しさん:02/05/07 14:36
>>88
いやだから、パイプライン使えばいいじゃん、って。

HTMLの構造的な問題に着眼するなら、ファイルをバラバラに
取得するのは欠点というより、キャッシュを有効に活用する
ための利点である、というふうに思うのだが、間違いかな?

90 :でも:02/05/07 15:32
>89
実装が面倒だから自分でコード書くときは逐次処理しちゃうよね


91 :デフォルトの名無しさん:02/05/07 17:38
うん

92 : :02/05/08 00:00
    

93 :デフォルトの名無しさん:02/05/08 00:04


94 :デフォルトの名無しさん:02/05/08 00:18
ハミングバードっていうファイルシステム イイ

95 :デフォルトの名無しさん:02/05/08 00:41
Love Wing 〜

96 :デフォルトの名無しさん:02/05/08 01:42
っていうか、監視されたりして何でもアリではなくなってきたので、
独自プロトコルと独自ファイルフォーマットで比較的Closedな
環境キボン。
2CH/IPと、2CTプロトコル、2ctファイル形式。

定義は頼んだ。

97 :デフォルトの名無しさん:02/05/08 04:17
>>96
HTTP(TCPまでも?)を使わない独自プロトコルの2chもどきシステムで、
匿名性とデータ転送の効率をアップさせたいと言うのは面白い考えだと思う。
だが、一言言わせてもらうと、それはスレ違いだ。

98 :デフォルトの名無しさん:02/05/08 08:45
単にGETをPICKとかにしてポートも変えれば妙に互換性の高いHTTPとは違ったプロトコルが閑静だw

99 : :02/05/09 00:00
       

100 :デフォルトの名無しさん:02/05/09 00:43
>>97
おもしろそうだがクライアントアプリの開発が難しくなるんじゃない
誰かが一緒に部品も提供すればいいのか。

101 :デフォルトの名無しさん:02/05/09 00:57
やり方が MS ちっくだな(w

102 : :02/05/10 00:00
         

103 :デフォルトの名無しさん:02/05/10 00:04
>>97

TCPまでもってのは難しいのでTTCPを使うとかは?
単なるミーハー?


104 :デフォルトの名無しさん:02/05/10 07:19
>>96
変換プロキシかませばいいんじゃない。
サーバーとローカルで。
さらに盗聴されても大丈夫なように画像とかに偽造する。

105 :デフォルトの名無しさん:02/05/10 07:43
×いいんじゃない。
○いいんじゃない?


106 :テスト:02/05/10 09:28
テキストは圧縮して送受信してもコストが見合うと思うが、
すでに圧縮されている画像や動画を圧縮してもしょうがない。

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

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


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

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

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

自殺したプログラマの何割かは、日本語コードのせい。


107 :デフォルトの名無しさん:02/05/10 09:47
>>106
>画像は画像だけ、動画は動画だけの
その画像なり動画なりも特定の形式のみサポートでしょ?(特定の形式のみに最適化しないとそのプロトコルはただのバイナリ転送プロトコル)

技術の発展を遅らせる。

108 :デフォルトの名無しさん:02/05/10 10:42
>>106
つーか逆に単純なしくみで全てをまかなえるほうが理想だと思うが。

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

クライアントを作るだけなら全ての仕様を使う必要がないから
まだいいが
まともに仕様を満たすサーバーやプロクシを作ろうとすると
死ぬ思いをする。
これは外部に開かれたCGIやWebアプリも同様。

109 : :02/05/11 00:00
   

110 : :02/05/12 00:00
      

111 :デフォルトの名無しさん:02/05/12 06:34
そういやbモバのproxyは画像の画質落として速度稼いでたな。
なんか不安定みたいだけど。

112 : :02/05/13 00:00
         

113 :デフォルトの名無しさん:02/05/13 06:48
MIMEタイプとかいらないよな。

114 : :02/05/14 00:00
      

115 :デフォルトの名無しさん:02/05/14 01:57
最初に GIF ファイルフォーマットの仕様を見たとき、なるほど
これがネットワークでやり取りされるデータの構造なんだ、と感動した。

116 : :02/05/15 00:00
          

117 :デフォルトの名無しさん:02/05/15 00:02
え?

118 : :02/05/16 00:00
          

119 :デフォルトの名無しさん:02/05/16 00:02
自動ageスクリプトの練習かよ。
規制ゆるくなった?

120 :デフォルトの名無しさん:02/07/02 21:31
GIFはコンピュサーブ出身です。

24 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)