パスワードを忘れた? アカウント作成
18395 story
ニュース

データをすべてファイル名扱いにして高速検索を実現? 187

ストーリー by mhatta
memcachedとかtmpfsとか… 部門より

backslashdot 曰く、

ITproに、「既存のDB技術と一線を画し、高速検索を実現する」というふれこみのデータ検索技術が紹介されている。 HOWSという企業が開発した「ISSEI」というVisualBasicで開発されたシステムらしいのだが、 高速検索性を最優先とするために、OSの基本機能であるファイル名検索に目を付け、 そこで検索対象となるファイルに含まれるデータそのものを全て「ファイル名」として管理することにしたということだ。 ファイルに含まれるデータそのものを、62進数(アルファベット大小文字+数字で26*2+10=62ということか?)の文字列に変換し、それらをファイル名の集合体として別途管理するらしい。 確かにこの方法であれば、HDDのファイル本体にはアクセスすることがないとも言えるわけだが、 記事の最後にあるように「次はOSメーカーと共同開発し、ISSEIをOSの標準機能として盛り込みたい。最終的にはISSEI専用チップをメーカーと開発するのが目標だ」という方向が望まれるような、画期的技術と言ってよいものだろうか。

ちなみに、この手法を応用(?)してどんなデータも圧縮率100%のファイル圧縮ツールを作った人もいます。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by virtual (15806) on 2008年01月21日 8時00分 (#1283757)
    ダウンロードしたことになるのですね。
  • 笑いどころ (スコア:5, おもしろおかしい)

    by Anonymous Coward on 2008年01月21日 8時53分 (#1283769)
    >ストップウオッチを片手に
    なんという手作業

    >ISSEIはマイクロソフトの「VisualBasic」で開発した。
    (中略)
    >処理の高速性を最優先し
    (;`・ω・)

    >最終的にはISSEI専用チップをメーカーと開発するのが目標だ
    そこまでするなら、この手法を取っている意味が無くなるのでは・・・?
  • 一方MSは・・・ (スコア:5, おもしろおかしい)

    by Anonymous Coward on 2008年01月21日 9時58分 (#1283796)
    ファイルシステムをDBにした。 [wikipedia.org]

    ・・・いや、しようとした。
  • それはCAS (スコア:5, 興味深い)

    by okky (2487) on 2008年01月21日 11時47分 (#1283852) ホームページ 日記
    Content-addressable storage
    ahref=http://en.wikipedia.org/wiki/Content-addressable_storagerel=url2html-10207 [slashdot.jp]http://en.wikipedia.org/wiki/Content-addressable_storage>

    そのものでございますな。『オブジェクト』と言う名のバイト列を見つけ出すのに、そいつが保持しているデータそのものを利用する、という。

    # 普通は高速に検索するために「ファイル名」に相当する部分には
    # ハッシュ値を使い、ファイル名そのものにデータを乗っけたりは
    # しないものですが…

    EMC の Centera とか、Tivoli Storage managerとか、
    Linus の git とかも CAS の一種です。

    CAS のいい所は、一度書いたら「データを変更できない」事。
    データを変更しようとすると「別のファイル名」になってしまう。

    …と言うわけで。多分この特許は通らないか、通るとしたらよほど
    審査官が間抜けだと思います。日本語版にはまだ無いとはいえ、
    ほぼ同案が Wikipedia に載っているんですから。
    --
    fjの教祖様
  • いっそのこと (スコア:4, 参考になる)

    by Anonymous Coward on 2008年01月21日 8時53分 (#1283768)
    ファイルシステムなんかなくしちゃえ!
    なんて論議もありましたっけ。

    論者曰く、現在のCPUが直接管理できるメモリアドレスは十分に広大であるので、それをカバーできる大きさの、かつ速く不揮発の主記憶装置さえあれば、ファイルシステムなど不要であるという論議です。

    # さて、現実性は。
    • by kicchy (4711) on 2008年01月21日 10時08分 (#1283807)
      >論者曰く、現在のCPUが直接管理できるメモリアドレスは十分に広大であるので、
      >それをカバーできる大きさの、かつ速く不揮発の主記憶装置さえあれば、ファイルシステムなど不要であるという論議です。

      ファイルの便利なところは、情報にシステム上で一意な名前がつけられるところだと思うのです。
      現在のOSのまま、ファイルシステムがなくなっちゃうとデータのやり取り手段を
      なんとかしなくてはいけなくなりますね・・・・

      # 名前の管理サービスみたいなものになるのかね?
      親コメント
  • by Stealth (5277) on 2008年01月21日 9時47分 (#1283790)

    Visual Basic 製と言う事は NTFS 上で利用する事になると思うのですが……。

    肥大化した MFT によりディスク領域が圧迫され、しかも別途デフラグソフトを購入しないとデフラグが出来ない (OS 標準のデフラグは MFT の整理をしない) 物が出来上がったと言う事ですか。

    RDB でもフルテキストインデックスとか、今時サポートしていない方がレアだと思うんですけどねぇ。

    NTFS なら小さなファイルなら MFT に突っ込んじゃうのだし、それこそ Windows Desktop Search や Google Desktop Search と連動させてデータを小さなファイルとして保持させ、検索自体は WDS や GDS とかに任せた方が効率的なんじゃないかと思う。

    多少データが増えたところで、単なるミラーリング & インデックス再生成程度で環境移行も出来ちゃうし。

    つーかこれ、書庫ファイルでバックアップ取ろうにも zip とかじゃファイル名は圧縮されないから tar + gzip/bzip2 とかじゃないと悲惨だよね。NTFS 上に Unicode ファイル名で記録すると約 32,000 文字とか使えちゃうから、下手な fs 上じゃ展開できないんじゃない?

    # 説明されたのに金を出した客の方がすごいと思う。

  • NTFS (スコア:4, 興味深い)

    by sayuporn (33927) on 2008年01月21日 14時58分 (#1283950) 日記
    このCTOがWindowsしかしらなくて、MySQLとかSQLiteとか使いたくなかった、
    苦肉の策なんじゃないかなあ(私なら50万円くらいでごにゃごにゃ)。

    NTFSは検索は速いですけど追加と削除が遅いですね。
    NTFSでハードリンク張りまくってバックアップとって、
    いざ削除しようとしたら100万ファイルくらいの削除に2ヶ月かかりました。
    マジで。
  • by Anonymous Coward on 2008年01月21日 7時36分 (#1283753)
    RFC1776 [imasy.or.jp] (アドレスにデータが全部入ってる)と
    RFC1924 [ocn.ne.jp] (IPv6アドレスを文字で短く表現)の合わせ技で同じことが出来るかな?

    どちらも4月1日発行モノ。
    • by Anonymous Coward on 2008年01月21日 8時34分 (#1283762)
      大昔 TSSを使っていた頃 ディスク容量の割り当てを突破するのにファイルの内容自体は空でいっぱいファイルを作ってそのカタログで情報を記憶させるというネタを思い出したよ。
      この記事もプログラムの改修を最小限に押さえて高速化を図るのにOSが持っている効率的なアルゴリズムを活用したとかいう話ならわかるけど、何と言うかCTOがアルゴリズムとか知らない頭悪い人に見えてしまう。
      親コメント
    • The "data" URL scheme [ietf.org]
      よーし,これですべてのデータがブックマークに入るぞ!
      いや,ジョークRFCではなくて,これはちゃんと機能するものです.念のため.
      --
      屍体メモ [windy.cx]
      親コメント
  • by Anonymous Coward on 2008年01月21日 8時34分 (#1283763)
    増井 俊之さんの
    Unix Magazine「インターフェイスの街角」
    1999年11月号 「シグナチャを用いた超お手軽検索システム」
    と根本的思想は一緒?なのかしら?
  • ストップウオッチ… (スコア:2, すばらしい洞察)

    by kcg (26566) on 2008年01月21日 8時47分 (#1283766) ホームページ 日記
    詐欺にしちゃ100万円程度しか集められなかったようですが、技術的な優位性や先進性があると本気で思っているのだとしたら情けない話です。
    開発するほうも、それで満足してしまう顧客も、日経の記者も。

    これで高速化できてしまうような質の社内システムとやらがはびこっているのが現実と言うことですか。

  • Web2.0時代の技術らしい (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2008年01月21日 10時07分 (#1283806)
    「Web2.0時代を迎え、今後企業はさまざまなチャネルから、データを大量に収集・蓄積しなくてはならない。データがあっても、それらを素早く検索・抽出して業務に役立てなければ意味がない。」(HOWS「ISSEI(イッセイ)」:ITproより)

    #素早く考えすぎたのだろう.
  • 62進数… (スコア:2, 興味深い)

    by taka2 (14791) on 2008年01月21日 11時51分 (#1283857) ホームページ 日記
    MIMEのBase64のように、あと2文字足して64進数にした方が便利だと思うんだが、それすら思いつかなかったでしょうか?

    実際には、Base64は A-Za-z0-9+/を使うため、/をファイル名に使えないので、ファイル名への符号化には使えないんだが、
    Imap4ではメールボックス名をファイル名に使っても問題ないように、
    メールボックス名は/の代わりに,を使うUTF-7(UnicodeをBase64で表現する方式)の修正版 [www.lins.jp]で表現する仕様になってます。

    #パスワード(というか復活の呪文的なもの)に「lとIと1」「Oとo」「9とQ」といった紛らわしい文字を使わないようにした37進数での符号化を使ったことがありますが、コードが無駄に複雑になってしまいました。
    #もうちょっと減らして32進数にしとけばよかったと気付いた時のは後の祭り…
  • 62進数エンコード (スコア:2, すばらしい洞察)

    by lynnlynn (15967) on 2008年01月21日 12時15分 (#1283869)
    attrib を使えばあと2bit容易に足せたのに...
  • quickHackとしては上出来なような気がする。顧客も満足してるみたいだし。
    # 技術的には自慢できるようなもんはないがな。
  • by Anonymous Coward on 2008年01月21日 13時43分 (#1283917)
    画像データを集めるのが趣味なので、膨大なファイルの中から同じ画像がすでにあるかどうかを探すのに、画像ファイルすべてのMD5値のリストを作って、それを検索してチェックしています。中身が同じなのに名前が違ったりして、ファイル名が役に立たないことが多いから。

    #さすがに、見た目同じでデータ的に違うものは無理だけど。JPEGで再圧縮かけたやつとか。

    あと、そのファイルの中から壁紙として使うものを、別のディレクトリにシンボリックリンクで集めたりしてますが、そのシンボリック名にMD5値を使っています。こっちは異なるディレクトリに中身の違う同名のファイルがあった場合への対策ですが。

    ファイル名にファイルの内容を直接反映させたり結びつけたりなんて、普通にみんなやってることじゃないんですか?
  • by Anonymous Coward on 2008年01月21日 8時35分 (#1283764)
    技術と似ているなんか違うもの、という感じがしないでもない。
    • by Tsann (15931) on 2008年01月21日 11時28分 (#1283845)

      その理由について庄司副社長は、「現在主流のRDBが限界に近付いているから」と述べる。「RDBを使えばデータを効率よく管理できるが、大量のデータを自由かつ高速検索できるようにするには、膨大なコストと手間がかかるといった短所もある」と指摘する。
      VBという言語を悪く言うつもりはないですが、VB使いというのは往々にして他の言語を知らない井の中の蛙的なイメージがあります。たとえばストアドプロシージャ(という別言語)にも手を出せない、とか。そんな中でRDBを使いこなせないレベルの人の視線で見つけた技術と呼べるのかもしれません。

      ところで言われているようにRDBって限界なのでしょうか?
      親コメント
      • by Ryo.F (3896) on 2008年01月21日 14時54分 (#1283947) 日記

        そんな中でRDBを使いこなせないレベルの人の視線で見つけた技術と呼べるのかもしれません。
        そうなのかなぁ。シャレだと信じたいけど。

        ところで言われているようにRDBって限界なのでしょうか?
        限界、っつーか、元々向き不向きがあるよね、ってだけだと思います。
        そもそも、構造化不十分な(あるいは、まったく構造化されていない)テキストデータを扱うような場合、それを二次元の表に格納しても、ほとんど得はありません。テキストファイルの中身をMS-Excelに貼り付けるようなもの。
        たとえば、全文検索が目的なら、RDBより接尾辞木に格納した方がマシ。元々データ構造の目的が違うんだから。

        ただ、既成のRDB製品はたくさんあって、RDB技術者がたくさんいるので、目的外使用だけどRBDが使われていて、それでも性能は上げなきゃいけないから、RDBにいろんなデータ構造(インデックス)をくっつけて誤魔化しています。
        まあ、その誤魔化しは、そこそこ巧く行ってるので、まだまだRDBは限界とは言えないんじゃないかな。
        親コメント
    • Re:技術というよりは (スコア:2, おもしろおかしい)

      by vn (10720) on 2008年01月21日 8時47分 (#1283765) 日記
      擬術。
      親コメント
  • 20年くらい前に (スコア:1, 参考になる)

    by Anonymous Coward on 2008年01月21日 9時07分 (#1283772)
    Ah!Ski か ascii.net で見かけたネタのようだ。

  • オンメモリデータベースの出来損ないってことですかね?

    ディスクの管理領域はメモリにキャッシュされている率が高く、そこをストレージ領域に使った場合は確かに高速にアクセスできるでしょう。オンメモリデータベースで難しい、不揮発性メモリとの同期の部分をOS任せにできるので実装も楽になるかな?でも、人に自慢げに話せる実装ではなく、恥ずかしくて人に言えない類の実装だと思うんだけどねぇ。
    • Re:一言で説明すると (スコア:3, すばらしい洞察)

      by tnk (13707) on 2008年01月21日 16時57分 (#1284016)
      >オンメモリデータベースの出来損ないってことですかね?

      いや,WindowsのIndex Serviceを使用していると,ファイル名による検索が
      高速化されることに気がついて,それをRDBのかわりにつかった検索システムを
      構築した,ということではないかと。

      問題は,そのIndex Serviceの内部で使われている技術がRDBの技術そのもので
      あることを知らずに,「DB技術の限界を超える」とかいってしまっているところ。
      親コメント
  • by 127.0.0.1 (33105) on 2008年01月21日 9時31分 (#1283783) 日記
    何かこんな話ついこの前あったような。
typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

読み込み中...