Oracle DBMSバージョン12.1.0.2の重要な革新の1つは、インメモリオプションです。 その主なアイデアは、選択したテーブルに対して、ディスクにデータを保存するためのOracle DB行単位形式とRAMのバッチ形式の標準を組み合わせたデュアル形式モードを簡単にアクティブにできることです。
対応するデータのメモリへの変換と複製は自動的に行われます。 個人的には、これは素晴らしいニュースでした。データウェアハウジング（DWH）を開発しており、ストレージおよび分析用に設計された列指向のDBMS Sybase IQおよびHP Verticaの経験があります。 また、OracleはColumn Store、In-Memory、およびお気に入りのDBMSのすべての機能を提供しました！ 実際、このソリューションにより、Oracleは分析インメモリデータベースの市場に参入しました（読んでいない人なら誰でも、このクラスのデータベースを比較したHabréの優れた
記事をお勧めします）。 Oracleのアイデアは非常に有望ですが、実際
には 、残念ながら
私のテストケースの結果は印象的ではありませんでした。 それは去年だったので、テクノロジーが改善されるまで待つことにしました。 In-Memory Optionが改善された次のパッチのリリース後、私はこの質問に戻りました。 記事に対してより客観的なテストが選択され、読者は必要に応じて繰り返すことができます。
ベンチマークに進む前に、いくつかのリンクを示します。 OracleブログのHabré
に関する記事で、In-Memory Optionとその素晴らしい結果の詳細な説明。 同じブログの別の
記事では、パフォーマンステストが提供されていますが、2つのテーブルといくつかの簡単なクエリのみが使用されています。
TPC-Hベンチマーク
パフォーマンステストでは、分析システムとデータウェアハウスのパフォーマンスを比較するために使用される
tpc-hベンチマークを使用しました。 このベンチマークは、DBMSとサーバーハードウェアの多くのメーカーで使用されています。 tpc-h
ページには多くの結果があります。公開するには、136ページで仕様のすべての要件を満たす必要があります。 私は自分のテストを公式に公開するつもりはなかったので、すべての規則を厳密には守っていませんでした。 また、テストプロセスを簡素化するために、
データベース用の
Benchmark Factoryの無料バージョンを使用しました。
TPC-Hでは、指定されたスケールファクターパラメーターを使用して8つのテーブルのデータを生成できます。これにより、ギガバイト単位のデータのおおよその量が決まります。 Benchmark Factoryの無料バージョンでは許可されなくなったため、2 GBに制限しました。 テーブル内の行の総数：
| テーブル | 行数 |
|---|
| H_LINEITEM | 11,996,782 |
| H_ORDER | 3,000,000 |
| H_PARTSUPP | 1,600,000 |
| H_PART | 400,000 |
| H_CUSTOMER | 300,000 |
| H_SUPPLIER | 20,000 |
| H_NATION | 25 |
| H_REGION | 5 |
テストには、さまざまな複雑さの22のSQLクエリが含まれます。 インメモリを使用した場合と使用しない場合のランタイムを比較しました。 次の負荷が生成されました。8人の仮想ユーザーが同時に3回輪になって、22のリクエストをすべて実行します。 その結果、528個のSQLクエリの実行時間が推定されました。
このテストがそれほど難しくないと思う人のために、最近の別のベンチマーク
-TPC-DSに注意することをお勧めします。 より多くのテーブルと大幅に多くのクエリがあります-99。
試験台
次の機能を備えたラップトップ：
-Intel Core i5-4210 CPU 1.70GHz-4コア; DDR3 16 Gb; SSDディスク。
OS：
-MS Windows 8.1 x64
DBMS：
-Oracle Database 12c EE 12.1.0.2.0
-個別パッチ（1）：「WINDOWS DB BUNDLE PATCH 12.1.0.2.160531（64bit）：23179016」
DBメモリ構成：
-memory_target = 10G;
-sga_target = 8G;
-inmemory_size = 3G;
インメモリ（IM）設定の設定
データベースパラメータ
inmemory_sizeの設定に加えて、IMキャッシュで複製するテーブルまたはその部分のデータを指定するだけで十分です。残りはOracleが自動的に行います。 したがって、十分なRAMがあれば、既存のデータベースをIMに簡単に転送できます。 何も書き換える必要はありません; IMテーブルに必要のないインデックスのみを削除できます。 また、安定した動作に注意します。IMに関連する単一のバグは発生していません。
私のテストでは、すべてのテーブルが完全にIMになりました。
ALTER TABLE MY_TABLE_NAME INMEMORY MEMCOMPRESS FOR QUERY HIGH PRIORITY CRITICAL;
- MEMCOMPRESS FOR QUERY HIGHは、クエリのパフォーマンスとメモリを節約するために最適化されたオプションです（ドキュメントには、さらに5つのオプションがあります）。
- PRIORITY CRITICAL -IMキャッシュへのレプリケーションの優先度を決定します。
もう1つの重要なニュアンスは、列のデータが適切に圧縮されることです。これがOracleの機能です。 次のクエリは、ディスク上のデータ量（IM単位）と圧縮率を示しています。
select SEGMENT_NAME, ROUND(SUM(BYTES)/1024/1024/1024,2) "ORIG SIZE, Gb", ROUND(SUM(INMEMORY_SIZE)/1024/1024/1024,2) "IM SIZE, Gb", ROUND(SUM(BYTES)/SUM(INMEMORY_SIZE),2) "COMPRESS RATIO" from V$IM_SEGMENTS group by SEGMENT_NAME order by 2 desc;
SEGMENT_NAME
| 元のサイズ、GB
| IMサイズ、GB
| 圧縮比
|
|---|
H_LINEITEM
| 1.74
| 0.67
| 2.62
|
H_ORDER
| 0.39
| 0.35
| 1,1
|
H_PARTSUPP
| 0.12
| 0.08
| 1,58
|
H_PART
| 0.06
| 0.02
| 2.96
|
H_CUSTOMER
| 0.04
| 0,03
| 1.42
|
H_NATION
| 0
| 0
| 0.22
|
H_SUPPLIER
| 0
| 0
| 0.89
|
H_REGION
| 0
| 0
| 0.22
|
試験結果
| ＃1インメモリなし | ＃2インメモリ |
|---|
| 経過時間 | 7分 23秒 | 6分 26秒 |
| 平均 応答時間（秒） | 5.617 | 4.712 |
結論として
いずれかのテストの結果からカテゴリカルな結論を引き出すことはできないと思います。 結果は、データのモデルとボリューム、クエリの詳細、DBMSパラメーターの構成、およびハードウェアによって大きく異なります。 別の例として、OracleがOracle IM（Exadata + Exalogic上）とSAP HANAのパフォーマンスを比較した、かつてのセンセーショナルなベンチマークへの
リンクを示します。 SAP BW-EMLベンチマークを使用。 このテストでは、Oracleのハードウェアおよびソフトウェアシステムが最高の状態でした。
Oracle In-Memoryの使用経験がある場合は、コメントでお読みください。