No.51
ログどころかファイル操作が終わる前に
応答を返すメモリ型DB（げふんげふん
ログどころかファイル操作が終わる前に
応答を返すメモリ型DB（げふんげふん
【オンメモリ%メモリデータベース【インメモリ】
レス数: 101
概要: 50に激しく同意 ログどころかファイル操作が終わる前に 応答を返すメモリ型DB（げふんげふん
ログどころかファイル操作が終わる前に
応答を返すメモリ型DB（げふんげふん
No.52
そもそも幸っているのはCPU or BUS?
No.53
オンモDB
オンモでぶー
No.54
楽波の志賀の辛崎幸くあれど大宮人の船待ちかねつ
唐崎でなく辛崎であることに注意。
No.55
No.56
No.57
No.58
ブームは終わったのでしょうか？
No.59
富士ソフトABC＆高速屋 VS 富士通BSC&ターボデータのオンメモリDB対決が
みれるよ
No.60
No.61
ティンポウエアにそんな機能あったっけ？
No.62
No.63
No.64
できるな。メモリがジャブジャブあればパフォーマンスは上がる
No.65
・超高速化による、バッチ処理（中間処理）概念の排除、と
・それによる、中間処理結果ファイルの排除（保管量が小さくて済む）
→（ほとんど）全データをメモリ上に押し込む設計力が必要
この利点を上手く生かせる技術者がどれだけ居るのだろうか？
もちろん、Oracle技術を捨てられない技術者には使いこなせない。
日本の技術者は保守的、日本のＩＴ業界では育たない。
（と思う）。
No.66
シリコンバレーにいたころ東京エレクトロンの営業さんからえらくプッシュされたのが懐かしい。
こっちは一介の研修生みたいなもんだったし帰国後転職したから忘れてた。
No.67
No.68
Kairosはどうよ？
No.69
http:
古い記事では、そろそろ新バージョンがでるみたい。
No.70
http:
~knizhnik/fastdb.html
これはどうなんでしょうね。
No.71
軽量なメモリＲＤＢＭＳ？？ソースは複雑では無さそうだが ...．？
No.72
TimesTenはミッションクリティカルな金融系のアプリケーションでは、しっかりシェアを持ってると
お友達の米国人（Stanfordの博士様）が言っておりました。
とても良い製品だけどバカッ高いと。
SQLではないけれど、ODBの生き残りのObjectStoreは、オンメモリーDBです。
実メモリーが沢山あれば、どんどんデータをメモリーにマッピングして、トランザクションも
オンメモリーで行い、その後でトランザクションログファイルに書き込み、そこからさらに
アイドルタイムにDBファイルに転送するという手順で動くため、非常に高速です。
DBサイズの限界は、OSの仮想メモリー空間のサイズにのみ制約されるので、64bitシステムでは
実際上の制限は無いと考えてよいです。
実メモリーサイズを越えるような大きなDBにフルアクセスした場合は、データがページメモリー
にマッピングされていくため、データアクセスでスワップが発生し、スピードが落ちますが
使えなくなる事はありません。
実際に使っていて、最大の特徴はマルチユーザアクセスでのUpdateトランザクションが
非常に高速なところです（当然Readも高速！）。
ロックやトランザクション管理もちゃんとやっていて良いんですけど、問題はSQL無いし
プログラムを全部C++で書かないと駄目なところ。敷居が高すぎて開発者が寄り付かない。
No.73
> 実際に使っていて、最大の特徴はマルチユーザアクセスでのUpdateトランザクションが
> 非常に高速なところです（当然Readも高速！）。
随分前に使ったことあるけど、マルチユーザで共有しているページを
更新するととんでもなく遅かったぞ。
理由は該当ページを共有してる全ユーザ(MVCC除く)がキャッシュを
破棄するのを待たなきゃいけなかったから。
今は改善されたのか？ あのアーキテクチャで改善は無理だと思ったが…
後、トランザクションログのサイズが大きくなると劇的にパフォーマンスが
低下したのも閉口したな。
No.74
> 随分前に使ったことあるけど、マルチユーザで共有しているページを更新するととんでもなく遅かったぞ。
> 理由は該当ページを共有してる全ユーザ(MVCC除く)がキャッシュを
> 破棄するのを待たなきゃいけなかったから。
> 今は改善されたのか？ あのアーキテクチャで改善は無理だと思ったが…
> 後、トランザクションログのサイズが大きくなると劇的にパフォーマンスが
> 低下したのも閉口したな。
それって、プロセス沢山作ってません？
キャッシュはクライアントプロセス毎のリソースなので、マルチスレッドで動かしてやらないと
あちらこちらでキャッシュブレークが発生するのでおそうなりますわな。
後、キャッシュサイズも上手く設定する必要あり。
トランザクションログのサイズは、プロパゲーションのタイミングの調整
で制御できると思います。
今のところ最新バージョンはR6.3で、来年あたりR7が出る予定。
R6の前はR5.1で、R6になるときに大きく変わり、R6.0.4で64bit対応になってます。
R6.0.3以前は、32bitだったので、アドレス空間サイズ4GBの壁があり、キャッシュ
サイズも大きく取れなかったので、キャッシュサイズを超えて、ブレークして
遅くなったりしてた。
No.75
> それって、プロセス沢山作ってません？
もちろん沢山作ってたよ。サーバが沢山あったからね。
> キャッシュはクライアントプロセス毎のリソースなので、マルチスレッドで動かしてやらないと
> あちらこちらでキャッシュブレークが発生するのでおそうなりますわな。
ってことは基本的なところはたいして変わってないんだな。
> 今のところ最新バージョンはR6.3で、来年あたりR7が出る予定。
> R6の前はR5.1で、R6になるときに大きく変わり、R6.0.4で64bit対応になってます。
俺が使ったのはR4の頃。途中でR5が出たけどバージョンはあげなかったな。
No.76
イケてない場合、皆はどんな方法がベストプラクティスと思ってる？
No.77
No.78
No.79
> 俺が使ったのはR4の頃。途中でR5が出たけどバージョンはあげなかったな。
そうでしたか。R6.0でスレッドごとにトランザクションを処理することが出来るように
なって、SolarisのマルチCPU環境では、スレッド使ってキャッシュをシェアする
トランザクションをパラレルに処理できるようになった。
これで、かなり高速化できてます。
昨日、R6.3が届いたので、これから色々試すところ。
No.80
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を採用しながら
メモリを効率的に使うなどの地道な努力を怠って
スワップメモリまで食うようなプロジェクトでは、
結局のろまなソフトしかつくれないでしょ。
いま隣のプロジェクトがそういう火事になってるよ。
No.81
ところでレスポンスはどうなんでしょか？（書き込み速度など）
No.82
No.83
オラクルだって、十分速い。
メモリーも安くなったし、、、、
No.84
聞く前に自分でやってみたの？
No.85
No.86
No.87
No.88
ttp://www.fsi.co.jp/project/k/index.html
No.89
メモリーのみで存在する「ファイル」になる。
.NETのDatasetはデータのメモリ内キャッシュ。
他のソフトとの共有もできるのかどうかは知らないが、目的いかんではオンメモリ
データベースとして使えるのではないか？
No.90
並べるとどうなりますか。
No.91
確かにそうだけど、DataSetは、テーブルとリレーションでしかなく、
それに対してSQLは実行出来ないから不便なところもあるのでは？
No.92
No.93
＞第五には、製品品質の問題が挙げられます。
＞ターボデータの商品は、
＞Student Codingと言われるほど製品品質が悪いようです。
↑
T●Lさんは、Cで作成したエンジンメーカ(ライブラリ)
なので、エンジン以外の周辺Prg、製品は
すべて評価プログラム(サンプル)の位置づけのよう。
使い方が難しいので、
提携組込ベンダー使い方を示すために
メーカ側が仕方なく用意したものを
ついでに製品販売しているだけでしょう。
本来OracleにおけるSQLPlusのように
ユーザさんに買って使ってもらいたいなら
お金をかけてメンテすべきと思うが
「タダのものにはできるだけお金をかけてメンテしたくない」
日本のベンチャーにはありがちな発想が
品質の悪さに拍車をかけてしまっているのだと思われる。
(見せ方が下手で、500倍の処理とか言われている性能も
ちゃちくみえる)
No.94
No.95
1であげたの全部まだ生きて居るんじゃない?
ターボさん今こんな事遣っているよう
http:
http:
http:
あそこ直販してないみたいだから
新機能試せる体験版、何時落とせるんだろうね〜
＜あそこのHPのパンフも全然変わってないから
まだまだ製品化は先なのかも。（苦笑
No.96
No.97
altibaseって新しく出てるよ。
これもメモリデータベースか？？
http:
No.98
使ってみるか。
No.99
いちおうHPに新製品情報でた
体験版はまだ未
No.100
ターボデータって
セック社 とか
いろいろと出資しているところがあるから無理かと思う。
ところでターボデータって儲かっているの？(ココ上場していない？)
セック社の決算報告書だと
研究援助投資という名目で
評価損の原因になっているようだが・・・。
