論文紹介: In-Memory OLAP データベースシステムにおいて、現代のストレージハードウェア上にあるメモリよりも大きなサイズのデータをどのように管理するのか
※これは システム系論文紹介 Advent Calendar 2016: ADVENTAR 1 日目の記事です。
昨今話題に事欠かない In-Memory DBMS ですが、暇に任せて Hekaton 関連で何か（←忘れました）を調べていたときに出くわした論文がこちらです。タイトルは
Larger-than-Memory Data Management on Modern Storage Hardware for In-Memory OLTP Database Systems
一応和訳しておくと In-Memory OLAP データベースシステムにおいて、現代のストレージハードウェア上にあるメモリよりも大きなサイズのデータをどのように管理するのか、という感じでしょうか。
先に結論を言うと後述する通り、今日では HDD だけではない、さまざまなストレージ技術を利用したストレージデバイスが利用可能で、それらをメモリの外の二次ストレージとして利用するときには、それぞれのストレージにとって最適な利用方法があり、その方法いかんでパフォーマンスが何倍にも向上したり、逆にかなり落ち込んだりします、ということを検証、考察したのが本論文の主な内容になります。
知っておくとよい予備知識
ご覧の通り、知っておくとよい予備知識を並べただけで読まないといけない文章（英語論文含む）が積もってしまって大変なことになってしまうのですが、これらの知識なしに上述のような論文に記述されている結論を読んでも「ふーん、まぁそうだよね…。」ぐらいの感想しか出てこないかと思うので、背景まで含めて読んでいただくとよりよいかと思います。
ストレージ関連で言うと、メモリのサイズを上回るデータを退避させる対象の二次ストレージとして、おなじみの HDD や NAND ベースの SSD の他に、次のようなストレージが本論文中で挙げられています。あと、NVRAM は non-volatile RAM、つまり不揮発性ランダムアクセスメモリについても言及があります。
ストレージ関連
- 10TBの大容量HDDを実現した「SMR技術」登場の背景
- なぜ3D XpointベースのSSDは期待通りの性能が出ないのか
- 新メモリ技術「3D XPoint」が準備段階に
- 相変化メモリ技術が大きく進化、書き換え電流を5分の1に低減
- 製品化されたスピン注入メモリの技術概要をEverspinが公表
- 極小のメモリスタ論理回路を設計、ナノコンピュータの実現目指す - UCSB
一方、in-memory DBMS に関しては以下の DBMS が言及されています。最初に MongoDB のリンクを置いたのは、1章で仮想メモリにアクセスした際にアクセス対象のデータが物理メモリ上になくページフォールトが発生し、トランザクションのパフォーマンスに影響が出る最近の例として挙げられていたためです。具体的に言うとメモリ管理に MMAPv1 を使っている Ver. 3.0 以前の MongoDB です（Ver. 3.0 以降は Storage Engine として WiredTiger を選択できるため改善が可能です）。
DBMS 関連
- FAQ: MongoDB Storage
- H-Store
- SQL Server's Memory-Optimized OLTP Engine
- Trekking Through Siberia: Managing Cold Data in a Memory - Optimized Database
- Apache Geode (Incubating) Documentation: How Eviction Works
- Enabling Efficient OS Paging for Main-Memory OLTP Databases
- SYSTEMS AND APPLICATIONS FOR PERSISTENT MEMORY
その他
- Yahoo Cloud Serving Benchmark
- count-min sketch & its applications
- “Anti-Caching”-based Elastic Memory Management for Big Data
- インメモリーDBで広がるリアルタイム処理の可能性（下）
論文の概要
in-memory DBMS は OLTP のワークロードの処理において、従来のディスクストレージの利用を前提とした DBMS よりも遥かに優れた性能を発揮しますが、それは現状扱う対象のデータベースのサイズが物理メモリよりも小さい場合に限られています。その制約がボトルネックになることを回避するための方法として、アクセス頻度の低いデータをメモリに留めておくのではなく、二次ストレージに退避させることで、物理メモリをアクセス頻度がより高いデータの処理により多く割り当てようという考え方があります。
この論文では、では具体的にどういった方法でデータを二次ストレージに退避させるのか、退避させたデータをどのようにメモリに戻すのかということ、それに加えて HDD やそれ以外のストレージデバイスを二次ストレージとして利用するときにそれらがパフォーマンスにどのような影響を与えるのか、そういった包括的なデザインをどのように決定し構成すればいいのかということを５つの異なるストレージテクノロジーを採用したストレージデバイスを用いることで評価しています。
評価の対象ストレージデバイス
in-memory DBMS の一つである H-Store DBMS に対して以下の５つの異なるパフォーマンス特性を持つストレージデバイスを二次ストレージとして利用します。
- HDD、いわゆる従来型の磁気記憶装置。昨今は SMR（後述） や PMR（Perpendicular Magnetic Recording, 垂直磁気記録方式） 特別するために CMR（Conventional Magnetic Recording） と呼ばれることもあるようです
- SMR HDD、瓦記録あるいはシングル時期記録方式と呼ばれる記録方式を採用した HDD
- NAND ベース SSD、いわゆる普通の SSD
- 3D-XPoint、２層のクロスポイント構造を用いた大容量メモリ。今回はそれと同様の技術を用いたエミュレーター利用します
- NVRAM、不揮発性ランダムアクセスメモリのこと。これには PCM（相変化メモリ）、メモリスター、STT-MRAM（スピン注入磁気反転型磁気メモリ）を含んでいます
DBMS 側のコールドデータの扱い方に関する方針（ポリシー）の説明
まず、ホットではないデータを二次ストレージに退避させるために、DBMS が何らかの指標をもとに退避させるデータを特定する必要があります。本論文中ではその方法として H-Store DBMS や Apache Geode が採用しているオンラインのアプローチと Siberia や VoltDB が採用しているオフラインのアプローチの2つについて説明しています。簡単に言うと、オンラインのアプローチでは LRU (Least Recently Used) アルゴリズムに基づいたリストを管理し、もっともアクセス頻度が少ないデータを二次ストレージに退避させます。一方オフラインのアプローチでは、データへのアクセスをログに残し、別の専用スレッドでこのログからアクセス頻度を解析し、どのデータがコールドなのかを特定します。
次にデータを退避したという情報をどういう手段でメモリに保持しておくのかという問題に対し、H-Store DBMS、Hekaton、および VoltDB が採用しているそれぞれの方法について説明していますが、詳しくは H-Store に関しては H-Store 公式のアンチキャッシュに関するドキュメント、Hekaton については、すでに紹介済みの Trekking Through Siberia: Managing Cold Data in a Memory - Optimized Database あたりを確認しておくとよいと思います。
二次ストレージへのアクセス方法とその方針（ポリシー）の説明
次の章ではコールドデータストレージに採用されているテクノロジーに密接にかかわるポリシーとしてコールドストレージへのアクセス方法とその方針について大きく以下の３つの観点から説明しています。
- コールドな状態のデータをどのように取得するのか
- どのような状況でコールドデータをメモリにマージするのか
- ブロック単位でのアクセスとバイト単位でのアクセス
より具体的な手法については、その次の実験解析の章でそれぞれのストレージデバイスに対していくつかの条件ごとのパフォーマンスを計測するという形でこれらのポリシーの決定がパフォーマンスに及ぼす影響について検証を行っています。
実験解析
H-Store DBMS が構成された dual socket の Intel Xeon E5-4620 2.60GHz（ソケットあたり 8 コア）の CPU と 432GB の DDR2 RAM を搭載しているマシンに各種二次ストレージを接続し、それぞれ前項の観点からパフォーマンスを計測しています。詳細は論文を見ていただいたほうがいいかと思いますが、取得するデータブロックのサイズや取得方法、アクセスパターン分布の違いが各ストレージデバイスの特性を露わにし、特性に応じたパフォーマンスを出していることがわかるかと思います。また TPC-C を利用したベンチマーク結果の他に Voter や TATP といったベンチマークの結果を見ていると、NVRAM のパフォーマンスが DRAM に迫っている様子が見られます。一方で、処理内容に対して適切な構成を行わずにただレイテンシーの低いストレージを使っても、それこそ最適化された HDD ほどにもパフォーマンスが出ない状況もある、ということがわかります。
関連する研究
今回実験をするにあたって利用した H-Store DMBS が採用しているアンチキャッシュというアーキテクチャですが、これはメモリ上にあるデータをディスク上にキャッシュすることに反する、つまりより多くのデータをメモリに最適化された状態でメモリ上に保持しつつ、ディスクをデータのホストとしてではなく、アクセス頻度がほとんどなくなったコールドデータ用の拡張ストレージとして利用するアーキテクチャです。他方、キャッシュするということは一般的に、パフォーマンスを向上させるためにディスクのデータをメモリ上にキャッシュするという意味になります。このアーキテクチャは OS における仮想メモリのスワップと同じような考え方にもとづいて実装されているとのこと。
本論文では、H-Store DBMS を利用していたためか、上記の実際の動作について多くの説明がこの章でなされていますが、同じ in-memory DBMS でも Microsoft の Siberia や VoltDB (EPFL のカスタマイズ済み)、Apache Geode、MemSQL 等それぞれ異なったポリシーのもとに異なった実装でコールドデータを扱っていることにも触れており、それぞれがどのように違うのかという興味をそそられます。
結論
実験の結果として、採用しているストレージ技術が異なったハードウェアデバイスを利用する場合にはそれぞれに適した構成を DBMS 側で実施することで、いわゆる既定値のような構成でデータ処理を行った場合と比べて３倍以上のパフォーマンスの改善が見られるということがわかったと結論づけています。あと、私が個人的に実験解析の章で NVRAM のパフォーマンスが DRAM のパフォーマンスに迫っている状況を見て驚いたのですが、それは執筆者も同じだったようで、論文のくくりとしてそのことに言及していました。
感想
たまたまこの論文を見つけたときにはなかなか面白い論文だなと思っていたのですが、参考文献を読んだり同じようなキーワードで検索したりすると同じような研究があちこちでされており、ある意味でホットな話題なんだなという印象を受けました。論文の内容自体もそうですが、予備知識の方で列挙した内容についても極めてハードウェアと関連した事が多いです。DBMS のチューニングはするが DBMS が利用するストレージで採用されている技術のことなど知らない、と言うことは簡単ですがその結果、単にそのことを考慮しないだけで安易にデータ処理のパフォーマンスを1/3以下にしてしまうことになりかねないということを今後の DBMS の設計に関して言えばよく理解しておく必要があるなと思います。
余談で本論文では話題になりませんでしたが、in-memory DBMS といえば他に Oracle の TimesTen や SAP HANA、MIT の Silo、CWI の MonetDB などがありますし、包括的に現状を理解するのであればこれらに関しても同じように学習しておく必要がありますね。
