「データをすべてファイル名扱いにして高速検索を実現?」記事へのコメント

技術というよりは

[Anonymous Coward]

技術と似ているなんか違うもの、という感じがしないでもない。

Re:

[Tsann (15931)]

その理由について庄司副社長は、「現在主流のRDBが限界に近付いているから」と述べる。「RDBを使えばデータを効率よく管理できるが、大量のデータを自由かつ高速検索できるようにするには、膨大なコストと手間がかかるといった短所もある」と指摘する。

VBという言語を悪く言うつもりはないですが、VB使いというのは往々にして他の言語を知らない井の中の蛙的なイメージがあります。たとえばストアドプロシージャ（という別言語）にも手を出せない、とか。そんな中でRDBを使いこなせないレベルの人の視線で見つけた技術と呼べるのかもしれません。

ところで言われているようにRDBって限界なのでしょうか？

Re:技術というよりは

[Ryo.F (3896)]

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

そうなのかなぁ。シャレだと信じたいけど。

ところで言われているようにRDBって限界なのでしょうか？

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

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

Re:

[Anonymous Coward]

SQLで記述するアプリケーションは、やることが抽象的過ぎて実装が複雑になるから、それこそ接尾辞木なりを指定した上でブラックボックス化してくれる枠組みがあればいいんだろうね。結局、チューニングがどうのこうのってのも、そこに尽きるわけで。

だから、単純な検索の為には単純な検索用のアプリケーションを書き起こす、というアプローチは間違っていない。ファイルシステムを選んだところが最悪だっただけで。ハッシュテーブル系は機能の割に敷居が高いのかもね。

いや、700円/時のアルバイトが、実用的なアプリを作れるようになるってのも、立派なブレイクスルーなわけですよ。200万ドキュメントがそれぞれ4kのセクタを潰したとして、8Gあればメモリ上に展開できるわけだから、機械的なコストは大したことが無い。その上で、高級な人材を使わずに済むなら…。