オンメモリRDBに関するスレッドが無かったので立ててみました。
従来のディスク上にデータを置かず主メモリに置くことで
I/Oコストを減らすアプローチを採用したことから性能面で勝るようです。
今後64bitCPUが広まるにつれ扱えるデータ容量も増えるだろうから
選択肢として気になる所です。
まだまだ認知度も低いですが今後の動向に期待。
以下紙面でよく見かけるオンメモリDB
・Oracle TimesTen In-Memory Database
・MySQL(HEAP table)
・DayDala.Boo
・高速機関
・Kairos いきなりスレタイトル失敗したよ orz
【オンメモリ】%メモリデータベース【インメモリ】
ってしたかったのに。 JavaのHSQLやDerbyもそういうモードあったな MySQLってDBマガジンにのってた使い方？
使ったこと無いからよくわからん
実際どうなの？ Prologのassert,retract,abolishでやってますが、
データベースシステムでないからだめですか？
600万件を超えてる売上データ(これはPostgresql)以外は、
何台かのマシンに分散させて、Prologインタプリタで
定義節として管理させています。停電に備えて、一分ごとに
全てのマシンでProlog環境のバックアップを取るということが
特徴かな。
同時更新が絶対に起こらない業務体制なので可能ということですが。 >>5
ちなみに
assert = INSERT
retract = UPDATE
abolish = DELETE ですね？
いきなり異色なテーマが出てきてびっくりしました。
SQLをサポートしていないオンメモリDBもあるのでPrologもありかと。
確かDayDa.Labooが独自APIでSQLをサポートしていなかった筈。 なつかしー。
Windows 2000の発表の頃 "In-Memory Database" IMDB
があったけどポシャったよね。 >>9
面白いドキュメント読ませていただきましたｗ 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間のデータの同期を取る
ことが可能になります。 ◆ 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はどうなんでしょうか？ >>13
LIFITは体験版がダウンロード出来たから試用してみたけど
むちゃくちゃ使いずらかったね。
テーブルにテキストデータをローディングさせたいのに
なんでカラム毎にテキストファイルを分割して
１カラムずつローディングしなきゃならないのか
理解に苦しんだ記憶がある。 どこも吸収されたり別会社が別の製品にまとめあげて販売してるけど
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/ たいていのRDBMSは、十分なメモリがあれば、トランザクションログ以外は
オンメモリも同然じゃないの？
バッチ処理で連続長時間の負荷をかける場合でないと
役に立たないんでない？ 追伸
高速機関のサイトを昔見たら、i-RAMみたいなものを
トランザクションログ用に作ってて、やはりここがボトルネックか、
と思った。 >>13
LFM技術ってどんんな処理方式なんでしょう？
知ってたら教えてください。 あ、
MySQLのHEAP TABLEを使ってみた事がありますが
シャットダウンさせるとデータ消えるんですね。
正常にシャットダウンしたんだから再起動したら
データ復元してくれてもよさそうなのに。。。 TinesTenと同じでターボデータも富士通BSCの子会社になるってのが自然な流れだろうね。
それでピリオドでしょう。 でもOh-Pa1/3は3000万するんだって。 これでは売れないよ。 以前に高速屋の高速機関とターボデータのDayDa.Labooを比較したけど、
DayDa.Labooは、MemoryにLoadingするのはメッチャ遅かったね。 >>20-21
IDが同じですよ。
そんなにターボデータを貶めたいんですか？
高速屋の関係者ですか、そうですか。
富士ソフトあべしの子会社化する不安でいっぱいなんですね。 ブハハハハッ！
いやぁ、ターボは面白いソフトだよ。 Oh-Paは知らないけど。
アルゴリズムで成功したことがない世界にチャレンジしているのだから。
どんどん使ったらいいんじゃない。世の中変わるかも。 製品やテクノロジーに関する話を聞きたい。
会社同士のしがらみとか正直どうでもいい。 使ったことないから語ることも無い。
でも興味はある。
雑誌を見ると結構使われているイメージがあるけど
実は全然マイナーな世界で誰も使ったことが無い？とか >26
あるっぽい
ＮＥＣと数理技研、メモリーＤＢを利用した流通業向けソリューション事業で提携
ttp://it.nikkei.co.jp/business/news/release.aspx?i=124281
従来のＲＤＢ（リレーショナルデータベース）を利用したシステムに比べて５０〜５０００倍の高速なデータ処理を可能とするメモリＤＢ
だそうです うーん。何を対比してるのか全く意味不明なのに50〜5000倍、ってのがポイントかも。 日経システムインテグレーション 2006/3月号に
Times-Tes, Kairos, FSSQL, DayDa.Laboo の特集（10P)が掲載されています。
お近くに雑誌がある方は確認してみてください。
ちょっと裏事情っぽい話も出てて笑えます。 >>18
www.amazon.co.jp/exec/obidos/ASIN/4902721015
ただし買う価値なし。アマゾンのレビューは関係者？
横浜に住んでいるか横浜の職場/学校に通勤/通学している人は市立図書館で借りて済ませましょう。
>>1
SQLite in-memory も追加。 こんなテーマに興味もってるって、
みんな、昼間は何してる人なの？ ﾋｯｷｰ？ 昼間はオンメモリデータベースの開発、販売に携わっています いまＤＤＲ２−２Ｇ−ＥＣＣ付きが６万円程度、１Ｇ＝３万円。
１００Ｇ積めるシステムはあるから、メモリだけなら３００万円ですむ。
データの重複は排除する方式なら通常のＲＤＢの３倍はデータが乗る。
１レコード１ｋとして１００Ｍ件＝１億件×３で３億件は大丈夫。
速度は１００倍ぐらいは軽いらしい。この程度の容量ならばＤＩＳＫも
フラシュメモリで置き換えられそう。 Sysytem i5(iSeries/400 AS/400 S/38) は、OSそのものがこういう発想。
ハードディスクはあくまでもメモりの延長線上で不揮発性の特性を持つ領域という発想になってる。
まぁ３０年前から実装されてる事なんだが。 25-6年前にIBMのSEからこのマシンの説明を受けたときには
停電対策が課題ということだったが、現在、この問題は
どうなってますか。 UPSでの延命措置も間に合わなかった場合は
内部バッテリーでメモリの中身をHDに退避してから自己シャットダウン >>40
参照専門でデータがいつ飛んでもいい用途に使えば良いじゃん >>40
解決済み。
ＵＰＳなしで、いきなり停電してもデータ不整合は起きないよ。
起動に数時間かかることになるけど。
41の手順が動いたときは起動がそれより速くなる。
実際復旧作業は「入力しかけのデータ入れ直し」だけで、あとはひたすら待つだけだった。
最近Oracleで同じ事があったとき、DB破損、oracle再導入＆データバックアップから
復旧ってのには驚いた。 >>44
参照専用でいいなら、そんなん普通のDBをちょっとチューニングすりゃ済む話
>>45
Oracleが飛ぶ＆リカバリ不能なのはハードやOSが飛んだ場合。汎用機ならともかく
UNIX系ならいつかは止まるのも致しかたない 最近メモリアクセスは急激に高速化されたけど、一般的なＤＢは
相変わらずログを書き終わらないとコミットを返せないというのが
インメモリタイプに注目が集まってる主因かな？ >相変わらずログを書き終わらないとコミットを返せないというのが
返しちゃマズいものは返さねーよ 
