Oracle Database In-Memory
Oracle Databaseはデータをデータ・ブロックという単位に区切り、内部的には行指向レイアウトで格納しています。ストレージ上のデータファイルはデータ・ブロックの集合であり、1個のデータ・ブロックを単位としてDRAMにキャッシュします。
Oracle Database In-MemoryはDRAM上に行指向アクセス用のキャッシュ領域と並列して列指向アクセス用の領域を確保します。1台のサーバー上にキャッシュ領域とインメモリー領域の両方を持ちます。この列指向アクセス用領域にインメモリーのアーキテクチャを採用しています。ストレージ上では行指向レイアウトで格納されているデータ・ブロックをDRAM上に載せるときに列指向レイアウトに変換します。
SQL実行エンジンはSQLの性質によって行指向レイアウトのキャッシュを使用するか、列指向レイアウトのインメモリーを使用するかを自動判断します。
![1台のサーバーがキャッシュ領域とインメモリー領域の両方を持つOracle Database In-Memory](http://cz-cdn.shoeisha.jp/static/images/article/15804/15804_005.png)
ここで、インメモリー領域に載せるデータの粒度がポイントです。データベースの全データをインメモリー領域に載せる必要はなく、アクセス対象である一部分しか載せないことでDRAMの容量上限の制限を緩和することができます。インメモリー領域に載せるデータは列指向アクセス用であり、分析・集計処理を想定しています。第6回で説明したように、分析・集計処理の性質は多数の行の少数の列にアクセスします。表のすべての列をメモリーに載せておく必要はなく、処理対象の列のみを列指向レイアウトでインメモリー領域に載せておけばSQLは結果を返すことが可能です。そのため、インメモリー領域に載せない列を指定できるようになっています。また、分析・集計処理はレンジ・パーティションが使用される傾向があると第3回で説明しました。レンジ・パーティションで時間を区切ることで、分析・集計処理対象のパーティションのみにアクセスします。Oracle Database In-Memoryがインメモリー領域に載せるデータの最小粒度は特定のパーティションの特定の列になっています。
さらに、インメモリー領域に載せるデータは置換可能になっており、容量制限の厳しいDRAMであってもSQLがアクセスする対象の列の特定パーティションのデータさえ載せることができればインメモリーで処理ができるようになっています。
物理的にDRAMの容量を増設するには共有ストレージ・共有メモリー型クラスタであるOracle Real Application Clustersを使用することができます。複数ノードに分散したインメモリー領域にまたがって1つのSQL処理を並列化することが可能です。Oracle Database In-Memoryは1台のサーバー内でキャッシュとインメモリーの両方の領域を用意するため、1台当たりのインメモリー領域のサイズがキャッシュ領域の分だけ小さくなりますが、Oracle Real Application Clustersはオンライン・トランザクション処理と分析・集計処理の両方をスケールアウトさせることが可能です。
MySQL HeatWave
MySQL HeatWaveはInnoDBストレージ・エンジンを持つ1台のサーバー・ノードに、分析・集計処理に特化した複数台の物理サーバーのクラスタ・ノードを追加したアーキテクチャです。
InnoDBはストレージ上もキャッシュ領域も行指向レイアウトで格納されています。HeatWaveはこれに列指向レイアウトで格納するインメモリー・アーキテクチャのノードを複数追加します。
![1台のキャッシュ領域サーバーと複数台のインメモリー領域サーバーのクラスタ構成を取るMySQL HeatWave](http://cz-cdn.shoeisha.jp/static/images/article/15804/15804_006.png)
MySQL HeatWaveのSQL実行エンジンもOracle Database In-Memoryと同様に、SQLのデータ・アクセスの性質によって行指向レイアウトのキャッシュ領域か、列指向レイアウトのインメモリー領域を使用するかを自動判断します。オンライン・トランザクション処理の少数のデータにアクセスするSQLは行指向レイアウトで格納されている1台のキャッシュ・アーキテクチャのInnoDBノードで処理されますが、分析・集計処理の大量のデータにアクセスするSQLは列指向レイアウトで格納されているインメモリー・アーキテクチャのクラスタ・ノードで並列処理されます。
MySQL HeatWaveがインメモリー領域に領域に載せるデータはデータベース全体である必要はありません。インメモリー領域に載せる表を指定し、そこからインメモリー領域に載せない列を指定することができます。MySQL HeatWaveはOracle Database In-Memoryとは異なり、インメモリーの分析・集計処理用のノードはインメモリー領域専用です。トランザクション系処理用のInnoDBノードは1ノードですが、分析・集計処理用のインメモリー領域ノードはクラスタ構成を取ることでDRAMの容量とCPUの並列度をスケールアウトすることが可能です。
データベース・アーキテクチャと用途
Oracle Database In-MemoryとMySQL HeatWaveはともにキャッシュ領域は行指向レイアウトでオンライン・トランザクション処理用に使用し、インメモリー領域は列指向レイアウトで分析・集計処理用という使い分けをしています。これは単に分析・集計処理を高速にするというアーキテクチャではなく、オンライン・トランザクション処理で発生したデータを別のデータベースに移し替えることなく分析・集計処理にかけることができるということを意図しています。
インメモリー・データベースが登場した背景には1台のサーバーに搭載できるDRAMの容量が大きくなったという一因があります。2022年現在においては1Uサイズの筐体でも1TBを超えるDRAMを搭載できるものもあります。パブリック・クラウドで用意されているサーバーには数100GBのDRAMが搭載されています。そしてこのような大物量サーバーでクラスタが構成できるという現実的な選択肢があります。
オンライン・トランザクション処理にしか向いていないDBMSから分析・集計処理に特化したDBMSに大量のデータを移動させるのではなく、両方の用途に対応したDBMSを使用することでデータの移動やインテグレーションにかかる追加のハードウェアや人的工数を省略するという選択肢を取ることも可能になりました。
まとめ
今回はDBMSのメモリー管理アーキテクチャを扱いました。サーバー1台に搭載できるDRAMの容量よりもデータベースのサイズは大きいため、ストレージに格納されたデータの一部をメモリーにキャッシュすることで高速化かつDRAM容量よりも大きなデータベースを扱うことができます。
これに対しDRAMの搭載可能容量が大きくなることでデータベースの全データをあらかじめメモリーに格納できるようになり、ソフトウェアによるキャッシュ管理を省略することで高速化をはかるインメモリー・データベースが登場しました。しかしインメモリー・データベースの「DRAM容量がデータベースのサイズを制限する」という本質的な構造が実用上大きな問題になります。
そこで、データベースの一部のデータだけインメモリー領域に格納し、キャッシュと組み合わせることでお互いの利点と欠点を補完しあうアーキテクチャのDBMSが現れました。Oracle Database In-MemoryとMySQL HeatWaveはともに、行指向レイアウトのデータをキャッシュ領域に格納してオンライン・トランザクション処理に使用し、列指向レイアウトのデータをインメモリー領域に格納して分析・集計処理に使用します。
データへのアクセスの傾向が異なる処理を1つのDBMSで扱えるようにすることで、複数のデータベース間で大量のデータを移動させることなく分析・集計処理までできるようになります。これは大物量サーバーでクラスタ構成が用意できる2022年現在において現実的な選択肢として存在します。
本連載の第2回から第7回まではDBMSがデータへのアクセスの性質が異なる処理を扱うための実装について説明してきました。性質が異なる処理を1つのデータベースで扱うマルチ・ワークロードに対応するには高度な実装が必要です。
次回からはデータ・モデルの違いについて説明します。第1回でSQLはインターフェースであり実装とは別であると説明しました。そのためリレーショナル・モデルとは異なるデータ・モデルもSQLで扱うDBMSがあります。単一のデータ・モデルしか扱えないDBMSとマルチ・モデルを扱えるDBMSではシステム設計が変わってきます。