トップページ⇒db
44コメント13KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001NAME IS NULL2008/01/21(月) 20:20:28ID:???
http://itpro.nikkeibp.co.jp/article/COLUMN/20080104/290425/

●既存のDB技術と一線を画すデータ検索技術を生み出す
●ゼロベースで発想しOSの基本機能に着目
●ストップウオッチ片手に高速化を追求

次世代Web基盤技術として特許出願中ｗ

「次はOSメーカーと共同開発し、ISSEIをOSの標準機能として盛り込みたい。
　最終的にはISSEI専用チップをメーカーと開発するのが目標だ」
庄司副社長の妄想は尽きない。
0002NAME IS NULL2008/01/21(月) 20:36:50ID:???
すっげーーーーー
俺が編集長ならこの記事書いた記者はクビ
0003NAME IS NULL2008/01/22(火) 00:22:19ID:???
別にこういうのがあってもいいとは思うが、コレって「検索だけが」早そうで、
集計とか分析とか更新とか超絶トロいんじゃねーの？

どんなクエリで抽出できるのかしらんけどサ。

たとえばそこそこに安い鯖&RDBMSだと1000万件くらいの銀行の科目毎の残高情報をGROUP BYしながら
集計しても30秒もかからないし。

そこらの10万くらいのPCでこれくらいの処理能力があるなら確かにバカ売れするとは思うけどどーなんだろ？
0004NAME IS NULL2008/01/22(火) 00:31:25ID:???
>>3
> そこらの10万くらいのPCでこれくらいの処理能力があるなら

そういう問題じゃないと思う
0005NAME IS NULL2008/01/22(火) 00:36:47ID:???
妄想は尽きないw
0006NAME IS NULL2008/01/22(火) 00:53:48ID:???
>>3
その３０秒というのは、しっかりとストップウォッチで計測したのか？
0007NAME IS NULL2008/01/22(火) 01:02:30ID:jOMCNxux
「OSの基本機能であるため、ファイル名の検索速度は速い。」
の意味がさっぱりわからないんだが。

ＯＳのファイル名検索なんて別に早くする必要あまりないし。
0008Visual Basic をバカにするわけじゃないけど...2008/01/22(火) 01:15:15ID:???
> ISSEIはマイクロソフトの「VisualBasic」で開発した。

>>2 に同意。

http://www.hows-corp.jp/company/20071113.html

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

バカだね (w
0009Visual Basic をバカにするわけじゃないけど...2008/01/22(火) 01:24:12ID:???
>>7
> ＯＳのファイル名検索なんて別に早くする必要あまりないし。

いや、それはそれなりに早くないと困るよ。

OS 起動時には、かなりの数のファイルを読込むから、ファイル名
検索の時間もバカにはできないし、技術的にも色々工夫されてる。

でも、その手の技術は RDBMS でも使ってるから。
0010NAME IS NULL2008/01/22(火) 01:47:05ID:???
＞現行のRDBシステムで検索効率を高めるには、あらかじめ特定のデータ項目をインデックス化する必要がある。
どんだけ認識が古いんだよwww
0011NAME IS NULL2008/01/22(火) 02:41:24ID:???
開発時のルールで「JOIN禁止」とか、そんなんだったんだろうな。
0012KD125029147227.ppp-bb.dion.ne.jp2008/01/22(火) 03:21:31ID:???
？？？ ？？？？？？ ？？？？？ ？？？？？？？ ？？
きく ？？？ ？？？？？-？？？？？ ？？？？-？？？？？ ？？？？？
？？？？ ？？？？ ？？？？？ ？？？？？ ？？？？ ？？？？？
0013NAME IS NULL2008/01/22(火) 03:37:55ID:FJFO8Ke7
↓被害者
究極のデータベースソフトを見た - 片貝孝夫の　IT最前線
http://blog.goo.ne.jp/katakait/e/957a40199c4a276ac0e59434a52f9006

スラッシュドットでボロクソ
http://slashdot.jp/developers/08/01/20/2052246.shtml
0014NAME IS NULL2008/01/22(火) 12:42:42ID:???
なんというか…はずかしいな
0015NAME IS NULL2008/01/23(水) 17:14:23ID:aAQGSWeF
レガシーな障壁があってRDB導入できない場合用、とかかなあ。具体例が思いつかないけど。
0016NAME IS NULL2008/01/23(水) 20:35:10ID:???
良く使われる技法じゃないの?
Webキャッシュがみんなこの方法で実装されているっしょ
0017NAME IS NULL2008/01/23(水) 20:38:43ID:???
キャッシュならいいけど、RDBを超えるものって感じの書き方がよくなかったw
0018NAME IS NULL2008/01/23(水) 23:16:18ID:???
超えるって言うか…ぶっちゃけRDB以下の機能/性能しか出せない気もするのは気の所為か？
0019NAME IS NULL2008/01/23(水) 23:58:26ID:???
まあ用途によってはRDBより速いケースはあるだろうけど、
「CacheはRDBより速い」ってのと同レベルの話だな。
0020NAME IS NULL2008/01/24(木) 04:24:08ID:ZYuZFvrq
RDBで遅い場合でもキャッシュ使うでしょ、というすぐ突っ込みがｗ
0021NAME IS NULL2008/01/24(木) 13:25:04ID:???
web cacheでもsquidなんかだと、こんな感じのからCOSSっていうのに移ってきてるけど。
0022NAME IS NULL2008/01/24(木) 14:09:09ID:???
squidはマップを作るでしょ。
delegateがDNSのキャッシュにこの方法を使っていたと思った。
あと、Netscape cacheもこの方法じゃなかったか? 商用だったので
詳しくは知らんが。
0023NAME IS NULL2008/01/26(土) 17:44:07ID:???
>>22
そのマップ部分はOSのファイルシステム上のインデックスなんじゃないかな
0024NAME IS NULL2008/01/27(日) 11:59:37ID:???
WINFS(SQL鯖によるファイルシステム)が、
まともなパフォーマンスが出ないため開発中止になったことから
思いついたんだろうな…
0025NAME IS NULL2008/01/28(月) 10:46:42ID:???
>>24
そこまで調査能力があるとは思えないが。
0026NAME IS NULL2008/02/16(土) 01:11:08ID:???
これって昔からありそうな手法だけど、本気で特許取れると思ってるのかな。
だとしたらかなり痛い。

ところで、ISSEIを基幹系システムに導入しちゃう予定の大手製造業は大丈夫なの？
たった110万件のデータ検索に1秒って遅すぎでしょ。
PostgreSQLとかMySQLでもインデックス貼ってりゃ数千万件のテーブルでも1秒かからねーだろ。

ストップウォッチで計測って所で技術力の低さが滲み出てるね。

あと、本気で専用チップとか作れると思ってるのかな？
データをBASE62エンコードとかする以外はOSのAPI呼んでるだけでしょ？
VBアクセラレータチップとか？？

突っ込みどころが多すぎｗ
0027NAME IS NULL2008/02/16(土) 15:44:48ID:2TWo9aFY
>>26
> これって昔からありそうな手法だけど、本気で特許取れると思ってるのかな。
> だとしたらかなり痛い。

この世界は、弓矢や車輪の特許が成立してしまう世界でもあるんだ。

双方向線形リストの特許が成立してしまう世界でもあるんだ。

ぶらんこの横漕ぎの特許が成立してしまう世界でもあるんだ。

笑って済ましていてはいけないんだモナ。
0028NAME IS NULL2008/02/16(土) 17:07:46ID:???
そんな特許成立してたか？

出願と成立をごっちゃにしてないか？

まあ、出願されて放置しとくとほんとに成立するから、
笑って済ませていてはいけないのは事実だが。
0029NAME IS NULL2008/02/16(土) 22:23:32ID:???
最近、特許成立したものだと、パスワードを記録するソフトだな。
それで公開停止に追い込まれたのがあったなあ。
具体的に条項みたわけでないんで詳しくは知らないのだが
0030NAME IS NULL2008/06/26(木) 22:34:16ID:???
>>2
なんで？
0031NAME IS NULL2008/06/26(木) 22:39:23ID:???
>>26
ＤＢ超初心者でよく分からないけどシステム系の超高速ＤＢを作るなら何が今最高なの？
誰か教えてくれ。
0032NAME IS NULL2008/06/26(木) 23:59:57ID:???
そこまで分かってないレベルだと、Oracle とか SQL-Server 使っとけよ。

性能出るかどうかは知らんけど、でない場合でもとりあえずメーカーのせい
にしとけば客が納得する率が高い。
0033NAME IS NULL2008/07/01(火) 20:50:53ID:???
商品DBみたいなマスタテーブルものがメインなら、
MySQLでオンメモリにしちゃえばいいんじゃない？かなり早いよ。
更新はInnoDBの別表領域作ってレプリケーションすればいいだけ。
0034NAME IS NULL2008/07/06(日) 08:21:54ID:???
>>31
ファイルシステムを利用したDBじゃないかな？
0035NAME IS NULL2010/03/18(木) 16:38:57ID:n4pB8QtB
特許あるな。特開2004-145787　これじゃね？
で、これか？http://www.datacom.jp/d3/gallery/20100309/detail/DSC00842.jpg
0036NAME IS NULL2010/03/20(土) 21:31:41ID:meYlYmqY
この会社ほんとにこれで食ってるの？
0037NAME IS NULL2010/03/22(月) 09:48:03ID:???
>> 副社長の妄想は尽きない。
0038NAME IS NULL2010/05/26(水) 21:49:02ID:xCTl8aF5
>>37

社長だ。
http://www.hows-corp.jp/
出世している。

しかし異常だなあ　これ
「某」会社ってのが大杉

このＤＢというか仕組みも
沖縄の会社と揉めたらしいし。
沖縄の会社はＳのつくアメリカの会社に泣きついたらしいな。
0039NAME IS NULL2010/06/06(日) 10:11:44ID:???
> このＤＢというか仕組みも沖縄の会社と揉めたらしいし。

KWSK

揉める要素が見当たらんのだが...。
0040NAME IS NULL2010/06/09(水) 18:38:49ID:???
これってgoogle検索より早いっての？
てか、すでにgoogleあるのに使い道あるの？　googleはすでに検索ワードから如何に曖昧検索で
ヒット率上げるのかまで考えてるよ。
0041NAME IS NULL2010/06/12(土) 21:45:08ID:???
google ?

曖昧検索なんて全然書いてないんだが...
>>40 みたいな奴がこういう記事に飛びつくんだろうな。
0042NAME IS NULL2010/06/14(月) 15:04:10ID:???
そもそも、どっからgoogleが出てきたのかさえ疑問。
0043NAME IS NULL2010/06/18(金) 11:25:13ID:???
正規表現とかワイルドカード使った一部一致で検索するということではなく、
例えば、serverと検索かけると、日本語のサーバーしか書いてない文章も検索対象になっているということ。
0044NAME IS NULL2010/09/19(日) 22:00:48ID:???
> serverと検索かけると、日本語のサーバーしか書いてない文章も検索対象に

いや、そんなことは俺の親父でも知ってる (このまえ、すごいなコレとか言っ
てた) が、この自称「高速検索技術」とやらになんか関係あるのか？
■ このスレッドは過去ログ倉庫に格納されています