パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

メモリデータベースでコスト削減」記事へのコメント

  • by Anonymous Coward on 2006年02月22日 10時55分 (#887952)
    勿論、うまいことやってると思うのですが。

    メモリに展開されたデータに障害が出た場合って、
    ちゃんとリカバリできるんですかね?
    • by bayside (23181) on 2006年02月22日 11時41分 (#887984) ホームページ 日記
      SQL互換性向上で浮上するオンメモリーDB [nikkeibp.co.jp] より。

      ただし、トランザクション・ログはディスクで管理し、万一の際のデータの消失を防ぐ。

      ということなので、参照系は大幅スピードアップでしょうが、登録系は参照系ほどは早くならないでしょう。

      親コメント
      • by 1024 (15403) on 2006年02月22日 12時03分 (#888001)
        In-Memory DB では、確かに更新系よりも参照系の方が享受する恩恵が大きいですよね。
        上記記事でも、参照系に注力する In-Memory DB メーカーのことが挙げられていますし。

        とはいえ、通常の DBMS(メモリ上の更新データをディスク上のデータファイルの該当箇所に書き込んでいかなければならず、バッファ管理やディスクシークのオーバーヘッドが発生する)に比べれば、トランザクション・ログをシーケンシャルに書き込んでいくだけで良い In-Memory DB の方が「更新系でも有利」と言えるかと。
        親コメント
        • by nim (10479) on 2006年02月23日 10時09分 (#888458)
          付け加えるなら、トランザクションログはリカバリ用にしか使用しないわけですから、(リカバリの際の手間は増えますが)データをディスパッチして複数のディスクにラウンドロビンで振り分けて書き込んでいくようにすればかなり性能は稼げますね。
          親コメント
    • by SteppingWind (2654) on 2006年02月22日 11時46分 (#887987)

      リカバリを考慮せずにすむ記憶領域専用と考えた方が良いでしょう. 例えばread onlyなマスタデータとか, あるいは索引領域みたいなものが対象ってことで. そうでなければトランザクションを不揮発記憶に書き込むことが必要になり, メモリを使う旨味が無くなりますから.

      と言うか, 最近の大規模OSとかRDBMSではメモリとディスクを一体的に管理するのが普通ですから, 大抵の場合は単純にメモリやバッファ領域を増やすだけで効果が出る場合がほとんどです. メモリRDBMSと言っても効果がある場合は

      • データ入出力の統計を完全に把握した上での自動化できない部分のチューニング
      • 32bitプログラムのRDBMSがOSの機能を使って2GB以上の主記憶を有効活用

      ぐらいでしょうか. 前者は継続的な運用を考えるとあまり勧められませんし(もちろん最後の手段としてはありですが), 後者はIA32のアーキテクチャとメモリ容量のバランスが崩れた現在に限った一過性のものだと思います.

      親コメント
      • by ginga (20279) on 2006年02月22日 14時01分 (#888078)
        それこそ巨大キャッシュ + Battery Backup Unit(BBU; 停止時にキャッシュメモリの記憶保持する)な RAID ディスク上に DB 作るってのではダメなんでしょうか?

        cache の BBU を信用して良いなら,書き込みキャッシュも write back で有効に すれば読みだけでなく書出しも高速化できそうですけど. それとも disk I/O インタフェースが遅くて memory I/O のバンド幅じゃないと対応出来ない? (そこまでは行かないですよね?)
        親コメント
        • 確かに磁気ディスクの転送速度がコンピュータ内のバスに追随できないくらいバスの方が速くなっていますから、一つの解ではあると思います。
          しかし、RAM上に大規模なデータを長時間置くというのは信頼性としてはあまりいい部類では無いし、バッテリーバックアップも高が知れているので、当然別のストレージにも並行してバックアップをしていかないといけないでしょうね。

          どっちかというと、BBUと磁気ディスクのRAIDアレイでRAID1作るとか、磁気ディスクの方と同期を頻繁に取るとか普通よりも多い頻度で磁気ディスクなどにバックアップするとか、安全策はとらないとまずいかと…
          親コメント
      • DBバッファに限りますが、VLMを使えば2Gの壁は越えられるようです。 最大64Gまでいけるそうで。
    • by Anonymous Coward on 2006年02月22日 11時57分 (#887996)
      たれ込みのリンク先に

      「カブボード ® 」、「個別銘柄詳細(四季報)」等の、銘柄情報、時価情報を従来のデータベースからメモリアクセスに変更する事により、従来と比較し約20倍の高速化および約25%の負荷軽減を実現。

      とありますんで、カブドットコム証券としてはリカバリの必要の無いデータに適用しているんじゃないですかね。
      親コメント
    • by rootbear (25827) on 2006年02月22日 17時22分 (#888130)
      大事なデータを扱う場合には、CPUもサーバもネットワークも電源もみんな冗長化して、データセンターが爆撃でもされない限りシステム全体が死なないような構成にしているはずです。 # それでもバックアップはきちんと取りましょう。
      親コメント
    • メモリなので、電源が供給されなくなったらあぼーんでしょうね。
    • by Anonymous Coward
      フラッシュメモリ。

      # 余計ダメか>回数制限

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson

処理中...