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

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

  • by Anonymous Coward
    勿論、うまいことやってると思うのですが。

    メモリに展開されたデータに障害が出た場合って、
    ちゃんとリカバリできるんですかね?
    • 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までいけるそうで。

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

処理中...