DB技術の限界を超える新発想の高速検索技術ISSEI

1 ：08/01/21 〜 最終レス ：10/09/19

http://itpro.nikkeibp.co.jp/article/COLUMN/20080104/290425/
●既存のDB技術と一線を画すデータ検索技術を生み出す
●ゼロベースで発想しOSの基本機能に着目
●ストップウオッチ片手に高速化を追求
次世代Web基盤技術として特許出願中ｗ
「次はOSメーカーと共同開発し、ISSEIをOSの標準機能として盛り込みたい。
　最終的にはISSEI専用チップをメーカーと開発するのが目標だ」
庄司副社長の妄想は尽きない。

2 ：

すっげーーーーー
俺が編集長ならこの記事書いた記者はクビ

3 ：

別にこういうのがあってもいいとは思うが、コレって「検索だけが」早そうで、
集計とか分析とか更新とか超絶トロいんじゃねーの？
どんなクエリで抽出できるのかしらんけどサ。
たとえばそこそこに安い鯖&RDBMSだと1000万件くらいの銀行の科目毎の残高情報をGROUP BYしながら
集計しても30秒もかからないし。
そこらの10万くらいのPCでこれくらいの処理能力があるなら確かにバカ売れするとは思うけどどーなんだろ？

4 ：

>>3
> そこらの10万くらいのPCでこれくらいの処理能力があるなら
そういう問題じゃないと思う

5 ：

妄想は尽きないw

6 ：

>>3
その３０秒というのは、しっかりとストップウォッチで計測したのか？

7 ：

「OSの基本機能であるため、ファイル名の検索速度は速い。」
の意味がさっぱりわからないんだが。
ＯＳのファイル名検索なんて別に早くする必要あまりないし。

8 ：

> ISSEIはマイクロソフトの「VisualBasic」で開発した。
>>2 に同意。
http://www.hows-corp.jp/company/20071113.html
| コクヨ株式会社 RDIセンター
| センター長 塚正 勉 氏
| コクヨ株式会社の研究･開発部門である当RDIセンターは、
| 株式会社HOWSがその理論と技術を確立し製品化する
| 「ISSEI」を高く評価しています。
|
| 株式会社日立製作所　産業・制御ソリューションセンタ
| 担当部長 根本 弘幸様
| “ISSEI”はWeb2.0的システム構成において、ビジネス
| インテリジェンスを構成する重要なキーコンポーネント
| になると期待しています。
バカだね (w

9 ：

>>7
> ＯＳのファイル名検索なんて別に早くする必要あまりないし。
いや、それはそれなりに早くないと困るよ。
OS 起動時には、かなりの数のファイルを読込むから、ファイル名
検索の時間もバカにはできないし、技術的にも色々工夫されてる。
でも、その手の技術は RDBMS でも使ってるから。

10 ：

＞現行のRDBシステムで検索効率を高めるには、あらかじめ特定のデータ項目をインデックス化する必要がある。
どんだけ認識が古いんだよwww

11 ：

開発時のルールで「JOIN禁止」とか、そんなんだったんだろうな。

12 ：

？？？ ？？？？？？ ？？？？？ ？？？？？？？ ？？
きく ？？？ ？？？？？-？？？？？ ？？？？-？？？？？ ？？？？？
？？？？ ？？？？ ？？？？？ ？？？？？ ？？？？ ？？？？？

13 ：

↓被害者
究極のデータベースソフトを見た - 片貝孝夫の　IT最前線
http://blog.goo.ne.jp/katakait/e/957a40199c4a276ac0e59434a52f9006
スラッシュドットでボロクソ
http://slashdot.jp/developers/08/01/20/2052246.shtml

14 ：

なんというか…はずかしいな

15 ：

レガシーな障壁があってRDB導入できない場合用、とかかなあ。具体例が思いつかないけど。

16 ：

良く使われる技法じゃないの?
Webキャッシュがみんなこの方法で実装されているっしょ

17 ：

キャッシュならいいけど、RDBを超えるものって感じの書き方がよくなかったw

18 ：

超えるって言うか…ぶっちゃけRDB以下の機能/性能しか出せない気もするのは気の所為か？

19 ：

まあ用途によってはRDBより速いケースはあるだろうけど、
「CacheはRDBより速い」ってのと同レベルの話だな。

20 ：

RDBで遅い場合でもキャッシュ使うでしょ、というすぐ突っ込みがｗ

21 ：

web cacheでもsquidなんかだと、こんな感じのからCOSSっていうのに移ってきてるけど。

22 ：

squidはマップを作るでしょ。
delegateがDNSのキャッシュにこの方法を使っていたと思った。
あと、Netscape cacheもこの方法じゃなかったか? 商用だったので
詳しくは知らんが。

23 ：

>>22
そのマップ部分はOSのファイルシステム上のインデックスなんじゃないかな

24 ：

WINFS(SQL鯖によるファイルシステム)が、
まともなパフォーマンスが出ないため開発中止になったことから
思いついたんだろうな…

25 ：

>>24
そこまで調査能力があるとは思えないが。

26 ：

これって昔からありそうな手法だけど、本気で特許取れると思ってるのかな。
だとしたらかなり痛い。
ところで、ISSEIを基幹系システムに導入しちゃう予定の大手製造業は大丈夫なの？
たった110万件のデータ検索に1秒って遅すぎでしょ。
PostgreSQLとかMySQLでもインデックス貼ってりゃ数千万件のテーブルでも1秒かからねーだろ。
ストップウォッチで計測って所で技術力の低さが滲み出てるね。
あと、本気で専用チップとか作れると思ってるのかな？
データをBASE62エンコードとかする以外はOSのAPI呼んでるだけでしょ？
VBアクセラレータチップとか？？
突っ込みどころが多すぎｗ

27 ：

>>26
> これって昔からありそうな手法だけど、本気で特許取れると思ってるのかな。
> だとしたらかなり痛い。
この世界は、弓矢や車輪の特許が成立してしまう世界でもあるんだ。
双方向線形リストの特許が成立してしまう世界でもあるんだ。
ぶらんこの横漕ぎの特許が成立してしまう世界でもあるんだ。
笑って済ましていてはいけないんだモナ。

28 ：

そんな特許成立してたか？
出願と成立をごっちゃにしてないか？
まあ、出願されて放置しとくとほんとに成立するから、
笑って済ませていてはいけないのは事実だが。

29 ：

最近、特許成立したものだと、パスワードを記録するソフトだな。
それで公開停止に追い込まれたのがあったなあ。
具体的に条項みたわけでないんで詳しくは知らないのだが

30 ：

>>2
なんで？

31 ：

>>26
ＤＢ超初心者でよく分からないけどシステム系の超高速ＤＢを作るなら何が今最高なの？
誰か教えてくれ。

32 ：

そこまで分かってないレベルだと、Oracle とか SQL-Server 使っとけよ。
性能出るかどうかは知らんけど、でない場合でもとりあえずメーカーのせい
にしとけば客が納得する率が高い。

33 ：

商品DBみたいなマスタテーブルものがメインなら、
MySQLでオンメモリにしちゃえばいいんじゃない？かなり早いよ。
更新はInnoDBの別表領域作ってレプリケーションすればいいだけ。

34 ：

>>31
ファイルシステムを利用したDBじゃないかな？

35 ：

特許あるな。特開2004-145787　これじゃね？
で、これか？http://www.datacom.jp/d3/gallery/20100309/detail/DSC00842.jpg

36 ：

この会社ほんとにこれで食ってるの？

37 ：

>> 副社長の妄想は尽きない。

38 ：

>>37
社長だ。
http://www.hows-corp.jp/
出世している。
しかし異常だなあ　これ
「某」会社ってのが大杉
このＤＢというか仕組みも
沖縄の会社と揉めたらしいし。
沖縄の会社はＳのつくアメリカの会社に泣きついたらしいな。

39 ：

> このＤＢというか仕組みも沖縄の会社と揉めたらしいし。
KWSK
揉める要素が見当たらんのだが...。

40 ：

これってgoogle検索より早いっての？
てか、すでにgoogleあるのに使い道あるの？　googleはすでに検索ワードから如何に曖昧検索で
ヒット率上げるのかまで考えてるよ。

41 ：

google ?
曖昧検索なんて全然書いてないんだが...
>>40 みたいな奴がこういう記事に飛びつくんだろうな。

42 ：

そもそも、どっからgoogleが出てきたのかさえ疑問。

43 ：

正規表現とかワイルドカード使った一部一致で検索するということではなく、
例えば、serverと検索かけると、日本語のサーバーしか書いてない文章も検索対象になっているということ。

44 ：10/09/19

> serverと検索かけると、日本語のサーバーしか書いてない文章も検索対象に
いや、そんなことは俺の親父でも知ってる (このまえ、すごいなコレとか言っ
てた) が、この自称「高速検索技術」とやらになんか関係あるのか？