In-Memoryの真実をご紹介します。後編となる今回は、検索の性能だけでなく更新系の性能や圧縮率なども取り上げます。In-Memoryには6種類の圧縮タイプが用意されています。CAPACITY」というように、適切な圧縮タイプは目的によって変わってきます。In-Memoryで選択可能な6つの圧縮タイプ圧縮タイプごとの性能差については前回ご紹介しましたので、今回は圧縮率がどの程度異なるのかを比較していきます。Benchmarkのスキーマです。ファクト表には6億行のレコードがあり、列内に同じ値(数字)が多く含まれているのが特徴です。結果を見ると、圧縮タイプによって最大で3倍ほど圧縮率が異なっています。QUERYなど他の圧縮タイプと比べてより多くのデータをメモリ上に格納できます。Compression(HCC)と比べてみましょう。その結果が以下のグラフです。In-Memoryの方が高い圧縮率になっています。従来の圧縮はデータブロック内にある重複値をシンボル表にコピーするという形で行われていますが、データを行単位で格納しているため、圧縮率はそれほど高くなりません。In-Memoryのほうが仕組み上有利です。HCCには及ばないものの、圧縮率としてはかなり優れていることが分かります。In-Memoryの圧縮が適用されます。In-Memoryの圧縮率をもとに行う必要があります。Advisorを使えば必要な領域を試算できるので、サイジングの際に活用すると良いでしょう。In-Memoryは分析処理だけに特化した機能であり、更新処理を高速化するような仕組みは持っていません。「OLTPの高速化」という表現を見かけますが、それは表をインメモリにして分析用の索引を削除すれば、索引の更新が不要になる分OLTPの高速化に繋がるという意味です。更新は従来どおりバッファ・キャッシュを使って行われるため、索引を削除しない限り非インメモリと同等の性能になるはずです。実際にSwingbenchを用いたテストを行ってみたのが以下のグラフです。ポピュレーションしておいた表に対して、100から500までセッション数を変化させて検証しています。In-Memoryを使用しない構成)を基準に比べてみると、100~300セッションの間ではほとんど性能に変化がないことが分かります。DMLを選択しておけばその影響も軽微です。In-Memoryは、OLTPと分析処理をリアルタイムに融合するというコンセプトを掲げています。非インメモリと同等の更新性能が維持できれば、更新されたデータをその場で分析するというリアルタイムな情報活用が可能になるはずです。In-MemoryでUPDATE文を発行すると、以下のようにまずバッファ・キャッシュ内で該当のデータが更新され、そのあとインメモリ・カラムストア内にあるデータが無効化されます。更新処理の動作もしこの状態でSELECT文が発行されたとしても、バッファ・キャッシュとインメモリ・カラムストアの内容をマージして結果を返してくれます。インメモリのクエリだけ古い値を返してしまうことはありませんし、SELECT文の書き換えも一切必要ありません。いつまでも両方のメモリ領域を見に行くのは効率が悪いため、更新されたデータは一定間隔で再ポピュレーションされます。read)が伴うため、対象となるデータが多いか少ないかによって、負荷が違ってきます。トランザクション中に再ポピュレーションを発生させた時の影響を検証したのが以下のグラフです。Swingbenchを実行している最中に更新系のバッチ処理を行い、TPSがどう変化するかを確認しています。再ポピュレーションの量が少ない小規模なバッチ処理では、裏で動いているトランザクションに全く影響が出ていませんが、大規模なバッチ処理では目に見えてTPSが落ち込んでいます。readによって大量のI/Oが発生するだけでなく、列フォーマットへの変換や圧縮も同時に行われるためCPUリソースを大量に消費します。大規模なバッチ処理を実行する場合は、できる限り他の処理が動いていない時間帯を選ぶなど運用面での考慮が必要です。In-Memoryには、ポピュレーションを実行するバックグラウンド・プロセス数を制御するための初期化パラメータ「inmemory_max_populate_servers」が用意されています。この初期化パラメータを調整することでポピュレーションを可能な限り速く終わらせたり、あるいは意図的にプロセス数を減らして負荷を抑えることができます。以下のグラフは、inmemory_max_populate_serversの設定によるポピュレーション時間の違いです。4から32まで変化させて検証したところ、プロセス数に応じてポピュレーション時間が短くなっています。プロセス数によるポピュレーション時間の違い今回の環境では12あたりでI/O待ちが発生して頭打ちになっていますが、限界点はサーバやストレージの性能に依存します。この初期化パラメータは動的に変更でき、0にするとポピュレーションが停止します。ポピュレーションの時間は圧縮タイプによっても大きく違ってくるため、検証フェーズにおいて実際のデータをもとにポピュレーション時間を試算してみることをお薦めします。CPUネックになるため拡張を見据えた設計が必要これまでデータベースのボトルネックと言えばディスクI/Oというのが定番でしたが、インメモリの表に対するクエリではその心配がありません。心配すべきなのはCPUへの負荷です。In-MemoryではCPUの性能が処理速度を大きく左右します。CPUのコア数によって、クエリの性能がどの程度違うのか見てみましょう。Benchmarkのクエリを2~32までコア数を変えながらパラレル処理で実行した結果です。コア数によって性能が大きく異なっていることが分かります。CAPACITYを選択するとクエリ実行時に解凍処理が必要になります。QUERYと比べてより多くのCPUを消費してしまうため、コア数が少ない環境で使用するのは避けたほうが良いでしょう。HIGHであっても性能向上が期待できますので、あくまでCPUコア数が少ない環境では選択しにくいというだけです。CPUのサイジングを行う際には、性能目標がどこにあるのかが非常に重要です。確かにCPUを増やせばそれだけ性能は上がりますが、例えば0.1秒の処理が0.05秒に短縮できてもビジネス的なメリットがなければ意味がありません。過剰投資にならないためにも、できるだけPoCを実施して適切なCPUのサイジングを行うことをお薦めします。ユーザ数やデータ量が増加した場合に備えて、CPUの拡張ができる設計にしておくことも重要です。In-MemoryはRACにも対応しているので、スケールアウトの構成をとることもできます。ApplianceがCapacity-On-Demand(システム規模に応じた支払い)に対応しています。少ないコアを課金対象としてスモールスタートし、必要に応じて残りの搭載コアを有効にしていくことができるため、運用開始後のリソース不足にも柔軟に対応できます。In-Memoryの可用性を高める機能が提供されているので、次回はOracleのアプライアンスにスポットをあてて解説していきます。俊洋ビジネスインフラ技術本部2006年入社。データベース・システムの構築や運用トラブルの解決といった業務を経験し、その後新製品の検証やソリューションの立ち上げを経てエバンジェリストへ。2016年にクラウド事業を立ち上げ、現在はクラウドとデータベースの二足の草鞋を履いている。最後までご覧いただきありがとうございました。本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。2019の様子を紹介します。SQLを拡張したプログラミング言語であるPL/SQLを理解し、活用していくための実践講座です。Databaseで発生するトラブルを「どんな方法で」「どのように」解決していくか。データベースの運用管理において、より円滑に業務を進めるために必要なノウハウを紹介していきます。