In-Memory DB では、確かに更新系よりも参照系の方が享受する恩恵が大きいですよね。
上記記事でも、参照系に注力する In-Memory DB メーカーのことが挙げられていますし。
とはいえ、通常の DBMS（メモリ上の更新データをディスク上のデータファイルの該当箇所に書き込んでいかなければならず、バッファ管理やディスクシークのオーバーヘッドが発生する）に比べれば、トランザクション・ログをシーケンシャルに書き込んでいくだけで良い In-Memory DB の方が「更新系でも有利」と言えるかと。
データのリカバリは？ (スコア: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:データのリカバリは？ (スコア:0)
Re:データのリカバリは？ (スコア:2, 参考になる)
とありますんで、カブドットコム証券としてはリカバリの必要の無いデータに適用しているんじゃないですかね。
Re:データのリカバリは？ (スコア:2, 参考になる)
Re:データのリカバリは？ (スコア:0)
メモリメモリ (スコア:0)
# 余計ダメか＞回数制限
Re:メモリメモリ (スコア:0)