【オンメモリ%メモリデータベース【インメモリ】

1 ：06/01/27 〜 最終レス ：11/07/28

オンメモリRDBに関するスレッドが無かったので立ててみました。
従来のディスク上にデータを置かず主メモリに置くことで
I/Oコストを減らすアプローチを採用したことから性能面で勝るようです。
今後64bitCPUが広まるにつれ扱えるデータ容量も増えるだろうから
選択肢として気になる所です。
まだまだ認知度も低いですが今後の動向に期待。
以下紙面でよく見かけるオンメモリDB
・Oracle TimesTen In-Memory Database
・MySQL(HEAP table)
・DayDala.Boo
・高速機関
・Kairos

2 ：

いきなりスレタイトル失敗したよ orz
【オンメモリ】%メモリデータベース【インメモリ】
ってしたかったのに。

3 ：

JavaのHSQLやDerbyもそういうモードあったな

4 ：

MySQLってDBマガジンにのってた使い方？
使ったこと無いからよくわからん
実際どうなの？

5 ：

Prologのassert,retract,abolishでやってますが、
データベースシステムでないからだめですか？
600万件を超えてる売上データ(これはPostgresql)以外は、
何台かのマシンに分散させて、Prologインタプリタで
定義節として管理させています。停電に備えて、一分ごとに
全てのマシンでProlog環境のバックアップを取るということが
特徴かな。
同時更新が絶対に起こらない業務体制なので可能ということですが。

6 ：

>>5
ちなみに
assert = INSERT
retract = UPDATE
abolish = DELETE ですね？
いきなり異色なテーマが出てきてびっくりしました。
SQLをサポートしていないオンメモリDBもあるのでPrologもありかと。
確かDayDa.Labooが独自APIでSQLをサポートしていなかった筈。

7 ：

なつかしー。
Windows 2000の発表の頃 "In-Memory Database" IMDB
があったけどポシャったよね。

8 ：

IMSBでぐぐったらインターネットムービーDBが多数hit
IMDBこれかな？
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/jpdndna/htm/page16.asp

9 ：

いやこれこれ。IMDBはボツにしましたって珍しいページ。
What Happened to IMDB?
http://msdn.microsoft.com/library/en-us/dncomser/html/whatimdb.asp

10 ：

>>9
面白いドキュメント読ませていただきましたｗ

11 ：

i-RAM使えばどれでもオンメモリデータベース。

12 ：

Prologをデータベースとする場合の構成だけ述べておきます。
Prologはサーバーとして動作します。他のタスクからPrologへの
接続はTCP/IP経由で定められたポート番号を使います。
一般にサーバーは要求があると子タスクをfork()して、
自らは次の要求を受け入れる準備をするものですが、
私の所のPrologデータベースでは、要求が完結するまでは
次の要求を受け入れません。
ただし、このような、ブロックが必要なのは、データベースの
追加、更新、削除の時だけです。破壊代入がPrologには
存在しないため、それ以外の実行はfork()された子タスクで
あって構いません、副作用は生じません。
したがって、assertzの代わりデータベースアドレス+ポート番号付きの
db_assert、retractの代わりにdb_retractを全ての
Prologシステムに準備して、この述語の実行(副目標という)の時のみ、
サーバーを参照すれように定義しておきます。
db_*** 述語の時のみ、サーバーはfork()なしでデータベースの
更新作業を行う事になります。データベースの参照もまたdb_** で
行わないといけません。他のネットワークノードからのサーバーの
述語定義を利用して実行したい時は子タスクをサーバーはfork()する
のですが、fork()された子タスクのPrologデータベースは
更新前のデータベースをもっていますから、これを参照してしまうと
誤謬を生じます。必ず全て、db_***で呼びださないといけません。
ここら当たりにこのシステムの陥穽があります。
UNIXのようなマルチタスクOSではTelnet接続でいくつかの
Prologが同時に動作することがあります。このような場合でも
原則としては、1システムに1Prologサーバーを用意しておけば、
データベースを通じてこれらのProlog間のデータの同期を取る
ことが可能になります。

13 ：

◆ On Memory（一般にはIn Memory）という言葉に飛びついてはいけません。
学生が実験室で横のものを縦にして、ある特定の条件で性能が高くなると
いう事実を発見したからと言って、実業の分野ですぐ取り入れるのは、
余程の趣味人かその道の研究者でもない限りあり得ないでしょう。
◆ On Memoryはターボデータの場合、縦に情報を捉えて、独自のデータ形式、
独自の集合のアルゴリズム（LFM技術）で処理しているので、習熟した
エンジニアで、かつ特定の条件でなければ期待するパーフォーマンス
は得られません。　このエンジニアの育成には半年以上掛かり、教育投資が
必要になります。この製品を使いこなすコストは無視でない筈です。　
ターボデータのDayDa.Labooエンジンのユーザの約半数は、購入して導入した
ものの現在は使われていないです。
◆ 真偽のほどは分かりませんが、SAPやSUNが富士通BSCの「Oh-Pa1/3」をISV
に認定したとターボデータは言っています。　しかしISVとは、SAPやSUNは
一切責任を取らないという条件付きで、世の中には「こういうものもあり
ます」という紹介程度で、何のオブリゲーションも無いのものです。本当に
優れて実用的なものであれば、明らかに自社製品に採用している筈ですが、
採用したという話は聞いていません。
富士通は、富士通BSCという子会社で販売していますが、本腰を入れたという
訳ではないようですし、日立はRH-BOMという特定のアプリケーションで使用
しただけ。日立もRH-BOMはビジネスにはなっていないようですし、Oracleや
Microsoftは今のところターボデータには見向きもしていないようです。
◆ ターボデータの問題点
第一に使い難さが挙げられます。　プログラミングレス、マウス一つで
出来るというのは？　実際に業務に組み込むことになれば、APIは難解。
Object Orientedには程遠いものです。　CないしはC++の技術を持った
エンジニアが相当作り込まなければなりません。
第二にDayDa.Labooは、例えばSQLのような技術は使えません。　
第三にLIFITというGUIは、プログラミングに相当するMacroのドキュメント性
は全く考慮されていません。
第四に、何よりも特定の条件（SORTなど）でしかパーフォーマンスがでません。　
第五には、製品品質の問題が挙げられます。　ターボデータの商品は、
Student Codingと言われるほど製品品質が悪いようです。加えて製品の
保守や教育のサポート体制は何もありませんし、業務で使うソフトウエア
としてはNGです。
第六に、ターボデータが販売しているBI Tool Likeのパッケージの
「ザ･ターボ」（DayDa.Laboo＋Lifitのシングル・ユーズのWindowsベース
のパッケージ商品）は、クライアント・サーバ型でエンドユーザ・
コンピューティングという昔流行ったコンピューティング・スタイル
ですが、これではクライアントに金ばかり掛かってしまいます。いささか
時代遅れのコンピューティング・スタイルです。
第七に、BI Tool のターボ製品について、例えば32ビットで１Gバイト
のメモリーを搭載したパソコンで20億行もの大量のデータをどんな人が
必要としているのだろう？　　（64ビット4〜16GBでマルチCPU、メモリー
シェア対応のシングル・ユースのターボを開発中で1兆行まで可能だと
発表しています。）　またそれほどの大量のデータを扱うとすれば、セキュ
リティとか別の問題が出てきます。
◆ 確かにOn Memory DBは、時代の流れであることは間違いないでしょう。　
これからもOn Memory DBは次々出てくるでしょう。この完成度の低い特殊な
エンジンがこのままで普及することは有り得ないのでは？と言うのが感想で
すが、他のOn Memory DBはどうなんでしょうか？

14 ：

>>13
LIFITは体験版がダウンロード出来たから試用してみたけど
むちゃくちゃ使いずらかったね。
テーブルにテキストデータをローディングさせたいのに
なんでカラム毎にテキストファイルを分割して
１カラムずつローディングしなきゃならないのか
理解に苦しんだ記憶がある。

15 ：

どこも吸収されたり別会社が別の製品にまとめあげて販売してるけど
DBエンジン単体では品質に問題ありって事かな？
◆Oracle Times-ten陣営
(Times-ten) 吸収
↓
(Oracle) http://www.oracle.co.jp/news_owa/NEWS/news.news_detail?p_news_code=1473
◆DayDa.Laboo陣営
(DayDa.Laboo) http://www.turbo-data.co.jp/
↓
(Oh-Pa 1/3) http://www.bsc.fujitsu.com/
◆高速機関陣営
(高速機関) http://www.kousokuya.co.jp/
↓
(FSSQL) http://www.fsi.co.jp/

16 ：

たいていのRDBMSは、十分なメモリがあれば、トランザクションログ以外は
オンメモリも同然じゃないの？
バッチ処理で連続長時間の負荷をかける場合でないと
役に立たないんでない？

17 ：

追伸
高速機関のサイトを昔見たら、i-RAMみたいなものを
トランザクションログ用に作ってて、やはりここがボトルネックか、
と思った。

18 ：

>>13
LFM技術ってどんんな処理方式なんでしょう？
知ってたら教えてください。

19 ：

あ、
MySQLのHEAP TABLEを使ってみた事がありますが
シャットダウンさせるとデータ消えるんですね。
正常にシャットダウンしたんだから再起動したら
データ復元してくれてもよさそうなのに。。。

20 ：

TinesTenと同じでターボデータも富士通BSCの子会社になるってのが自然な流れだろうね。
それでピリオドでしょう。　でもOh-Pa1/3は3000万するんだって。　これでは売れないよ。

21 ：

以前に高速屋の高速機関とターボデータのDayDa.Labooを比較したけど、
DayDa.Labooは、MemoryにLoadingするのはメッチャ遅かったね。

22 ：

>>21
kwsk

23 ：

>>20-21
IDが同じですよ。
そんなにターボデータを貶めたいんですか？
高速屋の関係者ですか、そうですか。
富士ソフトあべしの子会社化する不安でいっぱいなんですね。

24 ：

ブハハハハッ！
いやぁ、ターボは面白いソフトだよ。　Oh-Paは知らないけど。
アルゴリズムで成功したことがない世界にチャレンジしているのだから。
どんどん使ったらいいんじゃない。世の中変わるかも。

25 ：

製品やテクノロジーに関する話を聞きたい。
会社同士のしがらみとか正直どうでもいい。

26 ：

NECは製品ないのですか、そうでつか。

27 ：

使ったことないから語ることも無い。
でも興味はある。
雑誌を見ると結構使われているイメージがあるけど
実は全然マイナーな世界で誰も使ったことが無い？とか

28 ：

>26
あるっぽい
ＮＥＣと数理技研、メモリーＤＢを利用した流通業向けソリューション事業で提携
ttp://it.nikkei.co.jp/business/news/release.aspx?i=124281
従来のＲＤＢ（リレーショナルデータベース）を利用したシステムに比べて５０〜５０００倍の高速なデータ処理を可能とするメモリＤＢ
だそうです

29 ：

うーん。何を対比してるのか全く意味不明なのに50〜5000倍、ってのがポイントかも。

30 ：

ＮＥＣは、はんばいするだけで、製造はしないのか。

31 ：

日経システムインテグレーション 2006/3月号に
Times-Tes, Kairos, FSSQL, DayDa.Laboo の特集（10P)が掲載されています。
お近くに雑誌がある方は確認してみてください。
ちょっと裏事情っぽい話も出てて笑えます。

32 ：

>>30 開発失敗

33 ：

>>18
www.amazon.co.jp/exec/obidos/ASIN/4902721015
ただし買う価値なし。アマゾンのレビューは関係者？
横浜に住んでいるか横浜の職場/学校に通勤/通学している人は市立図書館で借りて済ませましょう。
>>1
SQLite in-memory も追加。

34 ：

>>33
１８です。
情報ありがとう。探してみる

35 ：

こんなテーマに興味もってるって、
みんな、昼間は何してる人なの？　ﾋｯｷｰ？

36 ：

昼間はオンメモリデータベースの開発、販売に携わっています

37 ：

いまＤＤＲ２−２Ｇ−ＥＣＣ付きが６万円程度、１Ｇ＝３万円。
１００Ｇ積めるシステムはあるから、メモリだけなら３００万円ですむ。
データの重複は排除する方式なら通常のＲＤＢの３倍はデータが乗る。
１レコード１ｋとして１００Ｍ件＝１億件×３で３億件は大丈夫。
速度は１００倍ぐらいは軽いらしい。この程度の容量ならばＤＩＳＫも
フラシュメモリで置き換えられそう。

38 ：

株式＠2ch
★★★自動売買ソフトを作ろうぜ★★★　Part3
http://live19.2ch.net/test/read.cgi/stock/1141718486/l50

39 ：

Sysytem i5(iSeries/400 AS/400 S/38) は、OSそのものがこういう発想。
ハードディスクはあくまでもメモりの延長線上で不揮発性の特性を持つ領域という発想になってる。
まぁ３０年前から実装されてる事なんだが。

40 ：

25-6年前にIBMのSEからこのマシンの説明を受けたときには
停電対策が課題ということだったが、現在、この問題は
どうなってますか。

41 ：

UPSでの延命措置も間に合わなかった場合は
内部バッテリーでメモリの中身をHDに退避してから自己シャットダウン

42 ：

は〜
だめだな、この手のＤＢ

43 ：

>>42
kwsk

44 ：

>>40
参照専門でデータがいつ飛んでもいい用途に使えば良いじゃん

45 ：

>>40
解決済み。
ＵＰＳなしで、いきなり停電してもデータ不整合は起きないよ。
起動に数時間かかることになるけど。
41の手順が動いたときは起動がそれより速くなる。
実際復旧作業は「入力しかけのデータ入れ直し」だけで、あとはひたすら待つだけだった。
最近Oracleで同じ事があったとき、DB破損、oracle再導入＆データバックアップから
復旧ってのには驚いた。

46 ：

>>44
参照専用でいいなら、そんなん普通のDBをちょっとチューニングすりゃ済む話
>>45
Oracleが飛ぶ＆リカバリ不能なのはハードやOSが飛んだ場合。汎用機ならともかく
UNIX系ならいつかは止まるのも致しかたない

47 ：

というか止まるの前提で運用設計するよな。

48 ：

するよな
と
するなよ
で180度違うなｗ

49 ：

最近メモリアクセスは急激に高速化されたけど、一般的なＤＢは
相変わらずログを書き終わらないとコミットを返せないというのが
インメモリタイプに注目が集まってる主因かな？

50 ：

>相変わらずログを書き終わらないとコミットを返せないというのが
返しちゃマズいものは返さねーよ

51 ：

50に激しく同意
ログどころかファイル操作が終わる前に
応答を返すメモリ型DB（げふんげふん

52 ：

オンメモDB用に仮想記憶を捨てようって方向はどうかな？
そもそも幸っているのはCPU or BUS?

53 ：

↑の書き込みを見て唐突に略称を思いついてしまった。
オンモDB
オンモでぶー

54 ：

唐突に私も思いついた。
楽波の志賀の辛崎幸くあれど大宮人の船待ちかねつ
唐崎でなく辛崎であることに注意。

55 ：

楽波 -> 楽浪 だな

56 ：

Times-Tenって導入してるところどれくらいあるんだろう？

57 ：

日本じゃ売れてないと思われる

58 ：

最近オンメオリデータベースの話をさっぱり聞かなくなったが
ブームは終わったのでしょうか？

59 ：

明日(今日）から開催されるDWH&CRMexpo
富士ソフトABC＆高速屋　VS　富士通BSC&ターボデータのオンメモリDB対決が
みれるよ

60 ：

不治痛のティンポもオンメモリ化可能だYO

61 ：

>>60
ティンポウエアにそんな機能あったっけ？

62 ：

オンメモリ可能とオンメモリに最適化されてるのは違うお

63 ：

MySQL cluster どうよ？

64 ：

>>61
できるな。メモリがジャブジャブあればパフォーマンスは上がる

65 ：

メモリ（ＤＢ）空間活用のポイントは、
・超高速化による、バッチ処理（中間処理）概念の排除、と
・それによる、中間処理結果ファイルの排除（保管量が小さくて済む）
　→（ほとんど）全データをメモリ上に押し込む設計力が必要
この利点を上手く生かせる技術者がどれだけ居るのだろうか？
もちろん、Oracle技術を捨てられない技術者には使いこなせない。
日本の技術者は保守的、日本のＩＴ業界では育たない。
（と思う）。

66 ：

Times TenってOracleに吸収されちったのか。
シリコンバレーにいたころ東京エレクトロンの営業さんからえらくュされたのが懐かしい。
こっちは一介の研修生みたいなもんだったし帰国後転職したから忘れてた。

67 ：

http://kairos.science-arts.com/index.html

68 ：

TimesTen売れているのですか？
Kairosはどうよ？

69 ：

TimesTen
http://www.atmarkit.co.jp/news/200607/29/timesten.html
古い記事では、そろそろ新バージョンがでるみたい。

70 ：

FastDB
http://www.ispras.ru/~knizhnik/fastdb.html
これはどうなんでしょうね。

71 ：

>>70
軽量なメモリＲＤＢＭＳ？？ソースは複雑では無さそうだが ...．？

72 ：

>>68
TimesTenはミッションクリティカルな金融系のアプリケーションでは、しっかりシェアを持ってると
お友達の米国人（Stanfordの博士様）が言っておりました。
とても良い製品だけどバカッ高いと。
SQLではないけれど、ODBの生き残りのObjectStoreは、オンメモリーDBです。
実メモリーが沢山あれば、どんどんデータをメモリーにマッピングして、トランザクションも
オンメモリーで行い、その後でトランザクションログファイルに書き込み、そこからさらに
アイドルタイムにDBファイルに転送するという手順で動くため、非常に高速です。
DBサイズの限界は、OSの仮想メモリー空間のサイズにのみ制約されるので、64bitシステムでは
実際上の制限は無いと考えてよいです。
実メモリーサイズを越えるような大きなDBにフルアクセスした場合は、データがページメモリー
にマッピングされていくため、データアクセスでスワップが発生し、スピードが落ちますが
使えなくなる事はありません。
実際に使っていて、最大の特徴はマルチユーザアクセスでのUpdateトランザクションが
非常に高速なところです（当然Readも高速！）。
ロックやトランザクション管理もちゃんとやっていて良いんですけど、問題はSQL無いし
プログラムを全部C++で書かないと駄目なところ。敷居が高すぎて開発者が寄り付かない。

73 ：

>>72
> 実際に使っていて、最大の特徴はマルチユーザアクセスでのUpdateトランザクションが
> 非常に高速なところです（当然Readも高速！）。
随分前に使ったことあるけど、マルチユーザで共有しているページを
更新するととんでもなく遅かったぞ。
理由は該当ページを共有してる全ユーザ(MVCC除く)がキャッシュを
破棄するのを待たなきゃいけなかったから。
今は改善されたのか？ あのアーキテクチャで改善は無理だと思ったが…
後、トランザクションログのサイズが大きくなると劇的にパフォーマンスが
低下したのも閉口したな。

74 ：

>>73
> 随分前に使ったことあるけど、マルチユーザで共有しているページを更新するととんでもなく遅かったぞ。
> 理由は該当ページを共有してる全ユーザ(MVCC除く)がキャッシュを
> 破棄するのを待たなきゃいけなかったから。
> 今は改善されたのか？ あのアーキテクチャで改善は無理だと思ったが…
> 後、トランザクションログのサイズが大きくなると劇的にパフォーマンスが
> 低下したのも閉口したな。
それって、プロセス沢山作ってません？
キャッシュはクライアントプロセス毎のリソースなので、マルチスレッドで動かしてやらないと
あちらこちらでキャッシュブレークが発生するのでおそうなりますわな。
後、キャッシュサイズも上手く設定する必要あり。
トランザクションログのサイズは、プロパゲーションのタイミングの調整
で制御できると思います。
今のところ最新バージョンはR6.3で、来年あたりR7が出る予定。
R6の前はR5.1で、R6になるときに大きく変わり、R6.0.4で64bit対応になってます。
R6.0.3以前は、32bitだったので、アドレス空間サイズ4GBの壁があり、キャッシュ
サイズも大きく取れなかったので、キャッシュサイズを超えて、ブレークして
遅くなったりしてた。

75 ：

>>74
> それって、プロセス沢山作ってません？
もちろん沢山作ってたよ。サーバが沢山あったからね。
> キャッシュはクライアントプロセス毎のリソースなので、マルチスレッドで動かしてやらないと
> あちらこちらでキャッシュブレークが発生するのでおそうなりますわな。
ってことは基本的なところはたいして変わってないんだな。
> 今のところ最新バージョンはR6.3で、来年あたりR7が出る予定。
> R6の前はR5.1で、R6になるときに大きく変わり、R6.0.4で64bit対応になってます。
俺が使ったのはR4の頃。途中でR5が出たけどバージョンはあげなかったな。

76 ：

オンメモリDBを社内LAN全体のMutex代わりに使うのってイケてる？
イケてない場合、皆はどんな方法がベストプラクティスと思ってる？

77 ：

そもそも何の排他に使いたいの？

78 ：

LANを排他するにはvlan tagを設定するのが簡単だと思う。

79 ：

>>75
> 俺が使ったのはR4の頃。途中でR5が出たけどバージョンはあげなかったな。
そうでしたか。R6.0でスレッドごとにトランザクションを処理することが出来るように
なって、SolarisのマルチCPU環境では、スレッド使ってキャッシュをシェアする
トランザクションをパラレルに処理できるようになった。
これで、かなり高速化できてます。
昨日、R6.3が届いたので、これから色々試すところ。

80 ：

>>70
FastDB
えーと、マニュアルをちまちま日本語に翻訳したのを
公開してるから探してみて。
ある案件で採用しようと目論んで調べてたんだが
いまいち調べ切れなかった。あと、類似のオンメモリDBとか
オブジェクトDBとか仕事で使ったことないので
比較はよくわかりません。ごめんね。
で、FastDBは
C++でクラスを定義して、マクロをちょっと書き足すと
それがテーブル定義っつーかスキーマになる。なので
データを使う側(プログラム)とスキーマが食い違いにくい。
クラスオブジェクト同士のリンク(1:1、1:N、N:M)
を格納できる仕組みが整ってる。
データ操作はSQLの簡易版みたいなクエリ文を使う。
クエリは事前解釈&パラメータ埋めるだけにもできるポ。
selectの結果は行の集合ではなくオブジェクトの集合。
ロックの範囲が広い。データベース全体をロックのみ。
ロックのオーバヘッドを減らすから、細かくロックする
(なるべく短時間で離す)ように使ってホスィ、とのこと。
あと、1DBに対して複数プロセスがアクセスするとして
1 Writer-N Reader の使い方には強いが、
複数のプロセスが交互に書き込むのは苦手。
レプリケーション（レプリカ造る）のようなモデル
（マイクロソフト風に言うとパブリケーション？）
にはいい。
1プロセスが複数DBを使うのはもちろんOK。
なので、2 Writerにしたいならむしろ2DBで
双方向のレプリケーションにしたほうがいいかもと思った。
マルチスレッドは、posixスレッドかWin32スレッドが使えるが、
作者が作ったラッパー経由でないとだめ。
こんな情報で役に立ったかな？
結構使い方に工夫が要る。まぁでも、オンメモリのDBを使おうと
してる開発ターゲットなら、何を使うにしても工夫は必要だわ。
オンメモリDBを採用しながら
メモリを効率的に使うなどの地道な努力を怠って
スワップメモリまで食うようなプロジェクトでは、
結局のろまなソフトしかつくれないでしょ。
いま隣のプロジェクトがそういう火事になってるよ。

81 ：

>>80
ところでレスポンスはどうなんでしょか？（書き込み速度など）

82 ：

傍から聞くとO/Rマッピングの組み込みに失敗しましたって読めるのが怖いｗ

83 ：

オンメモリーＤＢ、、、なんていらないんじゃない。
オラクルだって、十分速い。
メモリーも安くなったし、、、、

84 ：

>>81
聞く前に自分でやってみたの？

85 ：

オンメモリDBってExcelのこと？

86 ：

販売してたから良く知っている。

87 ：

kairosって？

88 ：

FSSQLがひっそりと終了したみたいです。
ttp://www.fsi.co.jp/project/k/index.html

89 ：

windows でテンポラリファイルを作って、クローズ時に残さない設定にすると
メモリーのみで存在する「ファイル」になる。
.NETのDatasetはデータのメモリ内キャッシュ。
他のソフトとの共有もできるのかどうかは知らないが、目的いかんではオンメモリ
データベースとして使えるのではないか？

90 ：

高価という印象が強いのですが、価格は小さい順に
並べるとどうなりますか。

91 ：

>>89
確かにそうだけど、DataSetは、テーブルとリレーションでしかなく、
それに対してSQLは実行出来ないから不便なところもあるのでは？

92 ：

みて

93 ：

＞◆ ターボデータの問題点
＞第五には、製品品質の問題が挙げられます。　
＞ターボデータの商品は、
＞Student Codingと言われるほど製品品質が悪いようです。
　　　↑
　　T●Lさんは、Cで作成したエンジンメーカ(ライブラリ)
　なので、エンジン以外の周辺Prg、製品は
　すべて評価プログラム(サンプル)の位置づけのよう。
　　使い方が難しいので、
　提携組込ベンダー使い方を示すために
　メーカ側が仕方なく用意したものを
　ついでに製品販売しているだけでしょう。
　
　　本来OracleにおけるSQLPlusのように
　ユーザさんに買って使ってもらいたいなら
　お金をかけてメンテすべきと思うが
　「タダのものにはできるだけお金をかけてメンテしたくない」
　日本のベンチャーにはありがちな発想が
　品質の悪さに拍車をかけてしまっているのだと思われる。
　(見せ方が下手で、500倍の処理とか言われている性能も
　 ちゃちくみえる)

94 ：

現在生き残っているIMDBのリスト作ってくれ

95 ：

>>94
1であげたの全部まだ生きて居るんじゃない?
　ターボさん今こんな事遣っているよう
http://www.nextq.jp/com/document.htm
http://www.nextq.jp/com/070609/090609_6-3-1.pdf
http://www.nextq.jp/com/070609/090609_6-3-2.pdf
　あそこ直販してないみたいだから
新機能試せる体験版、何時落とせるんだろうね〜
＜あそこのHPのパンフも全然変わってないから
　まだまだ製品化は先なのかも。（苦笑

96 ：

Kairos死亡。。。

97 ：

>>94
altibaseって新しく出てるよ。
これもメモリデータベースか？？
http://altibase.jp/

98 ：

おっ、altibaseはトライアル版ダウンロードできるよ。
使ってみるか。

99 ：

>>95
いちおうHPに新製品情報でた
体験版はまだ未

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
・　次のスレ
71: 頼むから正規化しろよ　第二正規形 (281)
72: データウェアハウス作ってる人いませんか？ (83)
73: 【PureJava】 Derby 1 【OpenSource】 (129)
74: データベース技術を勉強したいのですが… (124)