メモリデータベースでコスト削減 74
ストーリー by mhatta
結局ボトルネックは… 部門より
結局ボトルネックは… 部門より
あるAnonymous Coward曰く、"カブドットコム証券のプレスリリースによると、メモリRDBMSの導入により約20倍の高速化および約25%の負荷軽減を実現した、とのことです。
タレコミ者は今まで存在を知らなかったのですが、磁気ディスクではなくメモリ上にデータベースを展開するメモリRDBMSが以前から存在し、
主にバッチ処理の高速化に利用されてきたものをカスタマイズしてオンライン業務に利用できるようにしたようです。
このことによりデータベース処理の負荷が軽減され、最終的にシステムコストの削減になったとのことです。
ただ、これが東証のシステムの崩壊につながらなければいいのですが・・・"
カブドットコムは Windows (スコア:5, 参考になる)
http://itpro.nikkeibp.co.jp/article/Windows/20060111/227109/
http://www.microsoft.com/japan/communities/mvp/mvpinsider/mvpins200509.mspx
Re:カブドットコムは Windows (スコア:3, 興味深い)
参考： Wikipediaよりカブドットコム証券 [wikipedia.org]
そのためカブドットコム証券でもマイクロソフトの影響力が大きく、64-bit 版 Windows, SQL Server の早期導入やその支援などでマイクロソフトも大変な努力を払っていた…と聞いたことがあります。
現在の両社の関係については不明ですが、過去のこういった経緯からも SQL Server と Kairos とは併用されていくんだろうな、と推測しています。
Re:カブドットコムは Windows (スコア:1)
使用したRDBMSも、SQLserverと言うことか。
Re:カブドットコムは Windows (スコア:4, 参考になる)
**やっぱりITやるか。しょうがない。**
残り2%(弱?)はなんだろう (スコア:1, 興味深い)
Re:残り2%(弱?)はなんだろう (スコア:1)
Re:残り2%(弱?)はなんだろう (スコア:1)
Re:残り2%(弱?)はなんだろう (スコア:1)
証券会社は、大手証券を除いてフロント系システムは自前でもバックオフィス系はASPサービスを利用するか、アウトソーシングパッケージを使うのが普通ですが、カブドットコムはバック系や開発、運用、果てはコールセンターの運用まで自社で抱え込んでいます。ほぼすべてのシステムをWindows Serverで構成していますが、顧客の預かり金や証券などの口座データを管理する勘定系だけが、HPQのSuperdome(UP-UX11i on IA64,Oracle9i RAC)で稼働してます
RAMディスクを使うのと何が違う? (スコア:4, 興味深い)
普通のDBMSでもデータを置く場所をRAMディスクに変えれば同じことだと思うのですが、一体何が違うんです?
# 不揮発性のディスクにデータを退避するとか、
# そういう細かい点は無視するとして。
Re:RAMディスクを使うのと何が違う? (スコア:5, 参考になる)
TimesTenアーキテクチャー詳細 [tel.co.jp] (TimesTen 総代理店であった東京エレクトロンのページです)
今のところ Kairos のページ [science-arts.com] よりも充実しています。
因みに、この TimesTen は「Oracle より 10倍速い！」という意味を込めて名付けられた名称です。
と言ってたら、Oracle に買収されてしまいました。 [oracle.co.jp]
まぁ、TimesTen は Oracle の置き換えを狙っていたのではなく併用によるスループット向上を謳っていたので、この買収は恐らく双方にとってプラスだとは思いますが。
カブドットコム証券での Kairos 導入も、SQL Server との併用が前提と想像しています。プレスリリースの図だと完全置き換えにも見えますが。
Re:RAMディスクを使うのと何が違う? (スコア:3, 興味深い)
データを置く場所をディスクからRAMディスクへ単純に変更した場合，RAMディスクのキャッシュにRAMを使うことになりそう．
他にも書き込み順の最適化とか，インデックスの形式とかオーバーヘッドになりそうな部分がいくつかあります．
Re:RAMディスクを使うのと何が違う? (スコア:2, 興味深い)
主なオンメモリデータベース (スコア:4, 参考になる)
主なオンメモリデータベースは大体こんな感じでした。
Oracle TimesTen In-Memory Database
MySQL
Kairos
FSSQL
DBISAM
p*time
eXtremeDB
DayDa.Laboo
Caché
データベースの定義が曖昧でメモリ上にデータを持てば
「オンメモリデータベース」と主張する製品も
いくつか見受けられます。
SQLが使えないデータベースと聞いたら
多くの方は失笑されるかもしれませんが
中にはSQLが使えない製品もあったりします。
（この場合独自APIでデータ処理を行います）
RDB(リレーショナル・データベース)とは言ってないので
間違いではないのですが、一般的な認知からは外れるでしょう。
##
思いっきり関係者なのでac
Re:主なオンメモリデータベース (スコア:1)
RDBMS (スコア:3, 興味深い)
SQLserverはどうなんでしょうか？
試された方います？
データのリカバリは？ (スコア:2, 興味深い)
メモリに展開されたデータに障害が出た場合って、
ちゃんとリカバリできるんですかね？
Re:データのリカバリは？ (スコア:3, 参考になる)
ただし、トランザクション・ログはディスクで管理し、万一の際のデータの消失を防ぐ。
ということなので、参照系は大幅スピードアップでしょうが、登録系は参照系ほどは早くならないでしょう。
Re:データのリカバリは？ (スコア:2, 興味深い)
上記記事でも、参照系に注力する In-Memory DB メーカーのことが挙げられていますし。
とはいえ、通常の DBMS（メモリ上の更新データをディスク上のデータファイルの該当箇所に書き込んでいかなければならず、バッファ管理やディスクシークのオーバーヘッドが発生する）に比べれば、トランザクション・ログをシーケンシャルに書き込んでいくだけで良い In-Memory DB の方が「更新系でも有利」と言えるかと。
Re:データのリカバリは？ (スコア:2, 参考になる)
Re:データのリカバリは？ (スコア:2, 参考になる)
リカバリを考慮せずにすむ記憶領域専用と考えた方が良いでしょう. 例えばread onlyなマスタデータとか, あるいは索引領域みたいなものが対象ってことで. そうでなければトランザクションを不揮発記憶に書き込むことが必要になり, メモリを使う旨味が無くなりますから.
と言うか, 最近の大規模OSとかRDBMSではメモリとディスクを一体的に管理するのが普通ですから, 大抵の場合は単純にメモリやバッファ領域を増やすだけで効果が出る場合がほとんどです. メモリRDBMSと言っても効果がある場合は
ぐらいでしょうか. 前者は継続的な運用を考えるとあまり勧められませんし(もちろん最後の手段としてはありですが), 後者はIA32のアーキテクチャとメモリ容量のバランスが崩れた現在に限った一過性のものだと思います.
Re:データのリカバリは？ (スコア:1)
cache の BBU を信用して良いなら，書き込みキャッシュも write back で有効に すれば読みだけでなく書出しも高速化できそうですけど． それとも disk I/O インタフェースが遅くて memory I/O のバンド幅じゃないと対応出来ない? (そこまでは行かないですよね?)
Re:データのリカバリは？ (スコア:1)
しかし、RAM上に大規模なデータを長時間置くというのは信頼性としてはあまりいい部類では無いし、バッテリーバックアップも高が知れているので、当然別のストレージにも並行してバックアップをしていかないといけないでしょうね。
どっちかというと、BBUと磁気ディスクのRAIDアレイでRAID1作るとか、磁気ディスクの方と同期を頻繁に取るとか普通よりも多い頻度で磁気ディスクなどにバックアップするとか、安全策はとらないとまずいかと…
Re:データのリカバリは？ (スコア:2, 参考になる)
とありますんで、カブドットコム証券としてはリカバリの必要の無いデータに適用しているんじゃないですかね。
Re:データのリカバリは？ (スコア:2, 参考になる)
Re:データのリカバリは？ (スコア:0)
東証がどーたら (スコア:2, 興味深い)
東証の処理システム強化にメモリＤＢ導入→メモリＤＢ独特のトラブル発生→東証炎上ってこと？
タレコミ末尾の｢東証のシステムの崩壊につながらなければいいのですが…｣の意味するとこがよく分からんですな。
風が吹けば (スコア:5, おもしろおかしい)
↓
より取引に集中できる環境になる
↓
個人投資家がヒートアップ
↓
人体から発する熱で地球温暖化
↓
スギ花粉が爆発的増大
↓
各地で花粉症が重篤化
↓
東証の掃除のおばちゃんのくしゃみ回数増大＆集中力低下
↓
電源ケーブルに躓く
↓
東証システム崩壊
風が吹けば[後編] (スコア:2, おもしろおかしい)
↓
SE泊まり込みで作業
↓
「汗かいたなぁ」
↓
風呂屋繁盛
↓
桶が足りない!!
↓
桶屋が儲かる
Re:風が吹けば[末期編] (スコア:2, おもしろおかしい)
↓
デスマ
↓
デスマ
↓
デスマ
↓
デスマ
↓
●桶屋が儲かる
#不謹慎なのでAC
Re:風が吹けば (スコア:1)
Re:東証がどーたら (スコア:2)
> カブドットコム証券の処理量が増加→東証のシステム負担拡大→あぼーんってこと？
と，理解しました。
たしか，東証のこの間のトラブルは，ネット証券経由の個人売買の増加に加えて，ライブドア・ショックに伴う負荷急増に耐え切れなかったためだったですよね。
Re:ども、タレコミ人です (スコア:1)
と、教わりませんでしたか？
#私は多分、妹の少女まんがで知りました。
Re:ども、タレコミ人です (スコア:1)
そんなとき、
心に棚を作れ！
と、島本和彦のまんがで学びました。
技術者として (スコア:2, すばらしい洞察)
Re:技術者として (スコア:2, おもしろおかしい)
インメモリって領域によっては結構メジャーな気がする。 (スコア:2, 参考になる)
注目を集めているんですけども、インメモリって、たと
えばPure JavaのRDBMSで有名なHSQLDBは、特にメモリー
モードで起動するとすごい爆速ということで有名だったり
しますよね。
いまはHSQLDBだけじゃなく、もとのHypersonicの後継で
あるH2なんてのもあったりする。
IMS (スコア:1, 参考になる)
I/O処理を考えると納得の結果 (スコア:1)
管理している管理者の多くはI/O処理の効率化に頭を悩ませていると思います。
メモリベースという事を考えると激的な処理能力向上は納得ですが
停電時のデータ保全は大丈夫？なのか心配になっみたり。
消えても問題ないデータが入っている場所に使っているのかな？謎々。。。
Re:I/O処理を考えると納得の結果 (スコア:2, 参考になる)
Kairosでは、トランザクションログやチェックポイントファイルはディスクに保存されます。
障害の後、システムリスタート時には、Kairosはトランザクションログや
チェックポイントファイルを利用しリカバリーします。
ってことで、ある程度は考えて作ってるようです＜当たり前
＃ふつーのRDBMSもΔt的にはオンメモリーだしね
Re:I/O処理を考えると納得の結果 (スコア:1)
無理な期間で性能向上を迫られたら使おう^^
Re:I/O処理を考えると納得の結果 (スコア:2, 参考になる)
一般的な停電なら全く問題ありませんです。
メモリ上とはいえ、レコードの追加や仕様の変更で
だんだん非効率になってくるので、システムの物理構成
よりもむしろ、しっかり管理ができる物理体制を敷く
のが課題だったりします…
Re:I/O処理を考えると納得の結果 (スコア:2, 興味深い)
ホットスタンバイの機器破損したし。
# もちろんAC
Re:I/O処理を考えると納得の結果 (スコア:1, おもしろおかしい)
Re:I/O処理を考えると納得の結果 (スコア:1, 興味深い)
非常にアンニュイだった某データセンター。
ちなみに中に入るのに30分ぐらいかかる。
Re:I/O処理を考えると納得の結果 (スコア:1)
オンメモリDB (スコア:1, 参考になる)
これからトレンドになっていったりするのかな？
富士通BSCのプレスリリース(2005/7/27) [fujitsu.com]
ソリッドHDD (スコア:1)
停電時のバックアップ時間60秒が短いのなら、こいつの電源専用UPSを入れれば安心なんじゃないかなあ。
〜◍
飛び火 (スコア:0)
なぜ東証に飛び火するんでしょうか？
カブドットコムがトラブル見舞われても、東証は問題ないですよね。
また処理速度があがっても、カブドットコム経由の注文数が増えるわけでもないですよね。
誤発注に対するフェイルセーフがなされていない、というようなシステムの不備が市場混乱に繋がる例はわかりますが、市場が混乱するのであってシステムが崩壊するわけではないですよね。
どゆこと？
Re:一輪車だろ？ (スコア:1, すばらしい洞察)
Re:一輪車だろ？ (スコア:1, 参考になる)
こーゆーやつ [nou.co.jp]。
ねこ車というのは、同じような形ながら、者を乗せる部分が骨組みだけではなく深い底（バケット）があり、コンクリートなど泥状のものなどを運ぶ車だ。
こーゆーやつ [kissin.fte.jp]。
もともとねこ車というのは二輪だしね。
さらに台車との違いは、タイヤの大きさ、空気の有無なんかで言うみたい。
#と、言うのは建築業界やその周辺だけで通用する方言（業界用語というほどのもんでもない）ということを知っているのでAC