インメモリ処理のバックエンドストレージを考える
「NVDIMM」はなぜインメモリデータベースの“相棒”になり切れないのか?
高速なデータ処理を可能にする「インメモリデータベース」は、電源を切るとデータを保持できないのが一般的だ。そのためバックエンドのストレージシステムが重要になるが、技術選定は容易ではない。
インメモリ処理を活用すると、HDDやSDD(ソリッドステートドライブ)のストレージ処理で発生するデータ転送のレイテンシ(遅延)を回避できる。ただしバックエンドに、どのようなストレージを使用するかを考える必要がある。
データベースをメインメモリ内に保持する「インメモリデータベース」は、ストレージに保持する「オンディスクデータベース」の一次キャッシュメモリより、ずっと多くのメリットをもたらす。インメモリデータベースはほとんどの場合、キャッシュメモリやその他のプロセス用の不要なI/O処理を全てなくし、データベースそのものを更新できる。データを正しく記録したかどうかを確認する「リードアフターライト」の検証処理も非常に高速だ。データベース処理を大幅に高速化し、複数のサーバでデータベースを構成する「データベースクラスタ」に必要なサーバの数も削減できる。
NVDIMMの登場
インメモリデータベースの採用には課題もある。全てをDRAMで処理すればパフォーマンスが向上する半面、サーバの障害発生時にはDRAMの内容が空になってしまい、データを失うことになる。電源が失われてもデータベースの一部または全部を保持する永続性を確保できれば、インメモリデータベースの用途は広がる。その場合は、バックエンドにどのようなストレージを使うべきかを考えなければならない。
これまでであれば、ストレージ接続規格NVMeに準拠したSSDや、PCI Express(PCIe)カードにフラッシュメモリを搭載した「PCIeフラッシュカード」に保存することを推奨していた。DRAMから永続的にデータを保持可能なストレージ(以下、永続的ストレージ)へデータを移すには、それが最も速かったからだ。
現在は永続的ストレージの要素技術として、不揮発性メモリ規格「NVDIMM」も選択肢に入ってきた。NVDIMMは、一般的なメモリモジュール規格「DIMM」のフォームファクタ(形状や仕様)に、DRAMやNANDフラッシュメモリをまとめたメモリ規格だ。
NVDIMMは高速なバスとメモリI/O方式を使用しており、SSDと比べて非常に高速に動作する。これをDRAMと組み合わせて使うと、インメモリデータベースにシームレスかつ大容量のメモリ領域を利用でき、データを複数のサーバに分散する「シャーディング」の問題を避けることができる。
ただしNVDIMMは、そのサイズの小ささからSSDよりも一般的に容量制限が厳しく、ビッグデータの処理には問題がある。センサーから連続的に取得するストリームデータや、大部分はアクセスすることのない非常に大きなサイズのデータを処理するには、どうしたらよいか。
代替策は2つある。
1つはNVMe準拠のSSDを使用してネットワークストレージを作成する方法。もう1つは、それより遅いSSDを多数使用する方法だ。後者の場合、パフォーマンスはNVMe準拠SSDよりも劣るが、ずっと安価で並列性が高い。どちらを選ぶかはユースケース次第だ。
インメモリ処理では、高いデータ転送速度を実現する接続インタフェースが非常に有効だ。イーサネットを介して、異なるコンピュータのメモリへのデータ転送(RDMA: Remote Direct Memory Access)を可能にする「RoCE」(RDMA over Converged Ethernet)を使って、メモリベースのシステム間でデータを共有したり、それを一般的なドライブベースのストレージシステムに拡張したりすることができる。
インフラストラクチャの進化
インメモリ処理のインフラストラクチャは急速に進化している。特にNVDIMMとCPUのアーキテクチャで興味深い変革が進行中だ。
例えばIntelの不揮発性メモリモジュール「Intel Optane Memory」は「バイトアドレス指定」を可能にする計画だ。バイトアドレス指定とは、CPUが1バイト単位でアドレスを指定して、データの書き込みができるようにすることを指す。一般的にNANDフラッシュメモリと同様の4KBブロック単位のI/O方式を取るNVDIMMよりも、はるかに高速だ。
バイトアドレス指定を実現するには、システムのコードを全面的に書き直さなければならない。それでも従来のモノリシック(一枚岩)なアプリケーションに適用するよりは、データベースエンジンに適用する方がずっと簡単なので、まずはこの分野で実現することになるだろう。
ビッグデータ環境では、ネットワークとローカルストレージのデータ転送速度が、パフォーマンスのボトルネックとなる可能性がある。その解決策はデータ圧縮だ。圧縮の程度はデータによって異なるが、5分の1が一般的である。CPU側では、サーバ内でメモリ、GPU(画像処理プロセッサ)、CPU、ドライブベースのストレージをフラットかつ超高速に結ぶファブリック型のトポロジーに注目すべきだ。
CPUとメモリの連携を密にすることによって、DRAM容量の増大とパフォーマンスの向上を目指す動きもある。複数のプロジェクトがベースにしているのが、次世代DRAM「Hybrid Memory Cube」のコンセプトだ。これらのプロジェクトは、テラバイト毎秒のデータ転送速度、メモリの省電力化、メモリとCPUのモジュールアーキテクチャ構築などを目標としており、インメモリ処理の大幅な高速化を目指す。
こうしたプロジェクトは、それぞれ別の道を進んでいるとしても、大幅なパフォーマンス向上を目指していることには変わりがない。これによってインメモリシステムと、それを活用したストレージおよびストレージシステムの活用機会も拡大していくだろう。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
2
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
5
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
6
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
7
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
10
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー