|
|
| ■■■ jnudev
> プロポーザル > Search
Engine Back End For a Real-Time File sharing Infrastructure |
| ■■■ここでは、gPulpで出されたプロポーザル及び、Jnutellaが独自に出した、今後出していくプロポーザルを記載していく。 |
 gPulpで出されたプロポーザルの翻訳はカワサキが主に行った．不具合はカワサキまで
カワサキ
kawasaki@jnutella.org
XXXXxxxxx． |
|
リアルタイムでのファイル共有に必要となるインフラストラクチャのための、サーチエンジンのバックエンドについて
著者：Ian Hall-Beyer, LANgistiX
予備ドラフト：2000年4月16日,翻訳完了日：2000年6月17日
抜粋
インターネットのコミュニティに対してGnutellaの最近の紹介文は、ちらっとしか、リアルタイムの検索技術に関しては我々に提供してくれません。多くの問題は、現状の検索技術の具体化をしつこく悩ましています、しかし実際にはそれは実験の中では、技術のデモンストレーターとして、改善すべきコンセプトと同時にリアルタイムでの検索技術のインフラについても提示してくれています。仕事をしやすくするであろうこの鍵は、少し荒っぽく、確実で、拡張性がある結果とデータへのアクセスを提供してくれる方法です。
このデザインの主要な目的は、ターゲットとなるホストが使うシステムをインデックス化するのがどんなタイプであるかに関わらず、エンドユーザーが分かりやすく、首尾一貫して、データと文書を探すプロセスを作ることです。次の目的としては、可能な限り柔軟なバックエンドを作り出すことです、その結果、公にされるべきではないデータを保護していく限りは、コンテンツ提供者は、エンドユーザーに対してデータを提供する最も効率的な方法を使うかもしれません。
サーバサイド
データベース／インデクサー：索引作成者(Indexer)
システムの最初の鍵となる要素というのは、そのシステム自信のデータベースです。インデクサーは、実際にインターネットにでて、ファイルを掘り出すものであり、ポインターとディスクリプタ‐を持つこのデータベースに存在しています。もし証明が必要とされる必要があるときに、もしそういった場合には、メソッドやＡＣＬがどのように使われているかをそれが旗と同じくらい、確かなものであるというように、このインデクサーは、特定のファイル又はディレクトリ構造を見渡せるように、構成すべきです。データベースに存在することで、それは、互いの文書に対してのハッシュの数種類と同じように、ローカルに一意の文書の識別の名前を指定します。データベースの中の文書にインデックスを付ける主な目的は、検索要求が来るたびの毎回のシステムの負担を減らすということです。
それはここに記載されるべきです、そのインデクサー／データベースのコンビネーションは、Windows 2000やMacOSのSherlockのようなインデクサ−のようなOSをベースとした何かにもなりえます
サーチエンジン
いったん定住すると、データベースは実際のサーチエンジンを手に入れやすくなります。このポイントでは、LDAPのような標準的な何かを使うということは、アクションを取る際に 最善の方法のように見えます。しかし、適切なデザインをもって、これは、現実的にはいかなるデータベースにもなりうりますし、そしていかようにも展開できます。内部的に、サーチエンジンに対しての、様々なタイプのクエリーのための多様なパーサーは存在します。
以下のようなものが例として挙げられます：
自然言語クエリー
論理演算キーワードクエリー（Boolean Keyword Query）
正規表現クエリー
あいまいクエリー（Wildcard query）
。。。
いったん検索が結果を返すと、検索結果はその際にシステム内のHTTPサーバから与えられたXML文書の中にその結果を挿入します。その時に何が起こったかという、この技術はのちに議論されることになるでしょう。
通信層（Communications Layer）
この部分はネットワーク上の様々なホスト間でのすべての通信を処理して、検索クエリーを受け取り、そして検索エンジン層への検索クエリーを通過します。通信プロトコルのこの実際の技術については、この文書の範囲を超えてしまいますので、ここでは議論を行うことはしません。
HTTPサーバ
リクエストをした人に対してファイルや文書を提供するために、内部のHTTPサーバは、システムのすべての文書交換とクエリー結果を提供する処理を行っています。
どのように検索は働くのか
クライアントのユーザーが持つリクエストは、生態学の有害動物の取り扱いについて示した論文のような文書を検索しています。彼らは検索のクエリーを入力し、クエリータイプを選択します。クライアントは、その際にローカルで一意の識別名を指定し、ネットワークを通じてリクエストしているシステムに、世界的に一意な識別名を添えてそれを送ります。システムがこの検索を受け取ると、検索はサーチエンジンの層を通過し、その検索はその役割を果たします。
検索のマッチングを見つけることで、検索エンジンはそのデスクリプター、ハッシュ、確認者と共に、その際にHTTPサーバから送られたXML文書の中に、すべてのマッチングを打ち出します。パケットは、その際にリクエストを出したクライアントに送り返され、そして、その検索結果が成功したことを知らせています。その結果は以下のアドレスにあります；
http://10.11.12.13:9362/results/GUID/SearchID.xml
リクエストをするシステムは、それから、この文書を（これは理論上安全に行われます）取り戻し、それを解析します。
 そのリクエストを出したマシンのクライアントは互いのクエリーへ一意の検索IDを割り当てるために、その結果としてのXML文書は、クライアントによって回収のため、のちにそれがキャッシュされます。クライアントがシステムからこれらのXML文書を引き出すときに、それはこれらを解析し、そしてそれらを、１ページに組み立て、その際ユーザーに対してそれは表示されえます。ここでハッシュを使う利点は、このページが同一のハッシュを共に分類でき、かつ、そこで得ることができた特定のファイルや文書に関する多様なリンクのリストをユーザーに見せることができるということです。かわるがわるに、これらのリンクは隠されつづけることが可能で、クライアントは、最も手に入りやすいソースからファイルを得ようとすることができます。このクライアントも、使いやすい種類に基づいたファイルを集めるかもしれません。
ユーザーがファイルを選択した際に、リクエストはHTTPまたはHTTPSを通じたファイルを似ているフォームの中にホストするシステムを通過されています：
http://10.15.192.63:9362/documents/DocumentID
そのサーバはその時、共に適当なMIME情報を付けたファイルをユーザーに返します。次にそのユーザーのクライアントは、それをレンダリングしたり、表示したり、セーブしたり、ストリーミングしたりなどしてMIMEの種類に従ってファイルを処理します。もしその文書が実際にターゲットボックスにあるメインのウェブサーバにあるページならば、検索メカニズムの中のHTTPサーバは実際にその文書にリダイレクトします。
もしユーザーがのちにそれらの検索を再び訪れることを望んでいるならば、ローカルな一意の検索識別名を持つことで、クライアントが結果をキャッシュすることも許します。
すでにあるインフラストラクチャ
私が受けた質問の返答としては、少し変わった方法を用いて、存在するgnutellaプロトコルのこの作動をさせることは理論的には可能です。最初は、ということです、検索がすでにある論理演算（ダイオウとストロベリー）といった方法の検索クエリーフィールドへと要約され、そしてその際にシンプルな結果フィールドとしての検索結果を含んでいるXML文書を返してきます。
デザインの考慮すべきこと
このデザインは次のような目標を達成するためのものです；
拡張性（Scalability）
このシステムは、標準クライアント内ではライト級のサーバから大きなデータベース群にいたるまで、そこから送られてくるものを表現することができます。
検索の強化
このデザインは、ユーザーたちがクエリーのタイプのバラエティで彼らが探していることを見つけるため、また普通のユーザーからヘビーユーザーまですべての人を満足させるために、ユーザーたちの能力を最大化しようと努力しています。
ネットワーク上の負荷の減少
小さな結果のパケットを送ることで、相互通信層での全体的な負荷が、大きく減少します。 いったん結果が返されると、すべてのそれ以上の通信は標準的なHTTPを経由することになります。
セキュリティ
このデザインもまた、現実の検索結果振り分けのためのセキュリティのある通信層の導入を考慮にいれています。
c 2000 Ian Hall-Beyer. All Rights Reserved.
<manuka@nerdherd.net>
|
|
|
