第26回「インメモリー・コンピューティングの現状と将来」(2013/05/23 on...

© 2013 IBM CorporationSmarter Computing

しすなま！第26回

「インメモリー・コンピューティングの現状と将来」

© 2013 IBM Corporation2

System xSmarter Computing

アナリティック分野は、2013年

インメモリーコンピューティングの競争が激化！

2013年 3月にHANA 2.0発表 5月GA予定OLAPに加え、OLTP処理へのHANA対応

2013年 4月にDB2 BLU Acceleration発表

既存インスタンス内にインメモリー機能を包含

2012年 12月にSQL Server SSD Appliance発表すべてのデータをDRAM、SSD内に格納

2012年 10月にOracle EXADATA X3発表すべてのアクティブデータをDRAM、SSD内に格納

メジャーRDBベンダーのインメモリー対応完了！これからはインメモリー時代へ！



市場調査会社の意見 http://www.gartner.com/newsroom/id/2405315

インメモリー市場は2016年までに1000億円の市場になると予測されている

テクノロジー先行型の金融・通信・ゲーム・物流から、一般のユーザーへインメモリーコンピューティングが広がっていく

インメモリーコンピューティングの適用分野は数多い



まずは、データベース分野でのインメモリー化が進みそう

Why?• RDBはシステムの中心

• 現在のシステムではRDBは必要不可欠な存在

• 大抵のシステムではRDBが導入されている

• 高速化によるメリットが大きい• RDBは比較的性能要件が把握しやすいため、効果算定がしやすい

• すでにバッチ時間・データロード時間などで困っていることが多い

• RDBMSベンダーのサポート• すでに大手RDBベンダーはインメモリーをサポート



インメモリーデータベースの各社製品おおまかに理解

フラッシュを活用IBM ISASMS SQL ServerOracle ExadataTeradata

DRAMを活用SAP HANAIBM DB2 BLUOracle ExalyticsIBM SolidDB

独自型IBM PureData forAnalytics(Netezza)

広義のインメモリーデータベース

狭義のインメモリーデータベース



インメモリーDBの普及64ビットCPUの登場～普及

• 1991年 MIPS R4000

• 1992年 DEC Alpha

:

• 2001年インテル Itanium

• 2002年 IBM POWER4

• 2002年インテル Itanium 2

• 2003年 AMD Opteron

:

インメモリーDBの登場～普及• 2010年12月インメモリソフトウェア「SAP High-Performance

Analytic Appliance」（SAP HANA）の提供を開始

• 2011年11月 BIソフトウェアのSAP NetWeaver Business

Warehouse への対応を発表

• 2013年3月 SAP Business Suite powered by SAP HANA製品発表

:

H/W

S/W

Application

H/W S/W Application



インメモリー”コンピューティング”SAP HANA

インメモリーDB

+ アルファアプリケーション

他、システムインメモリーDB （１）

（２）

（３）



（１）インメモリーDB

インメモリーDB、HANAの仕組みは？

(System x 基本構成)

トランザクションログの書き込み

データの書き込み(定期的な保管)

メモリー

HANAデータベース

IBM : 内蔵ストレージのみ他社 : 外部ストレージ利用



（１）インメモリーDB

インメモリーDB、HANAの仕組みは？

(*)

OLTP(SAP ERP

の例)OLAP

列(カラム)型行(レコード)型

HANAデータベース

(*) 共存、及び変換を共にサポート

変換&圧縮



（２）アプリケーション

アプリケーションは？

アプリケーション処理 DB処理

アプリケーション処理

アプリケーション処理 DB処理

DB処理

△

○ プッシュダウン



（３）他、システム

他、システムとの連携？

△

○

夜間バッチ転送

ニアリアルタイム転送(*)

(*) SAP Landscape Transformation (SLT) の利用

SAP ERP 他、主要なDBMS



System x 高可用性構成IBM : 内蔵ストレージのみで2重化実現他社 : 外部ストレージの2重化が追加で必要

高価な外部ストレージ、及びその複製ソリューションの

追加投資が必要

外部ストレージ無しで堅牢な高可用環境を実現



Oracleソリューション分野でも大容量メモリ/半導体メモリ(Flash SSD)の活用が大幅に増加している

・データベースの肥大化によるパフォーマンス課題解決。・経営統合、グローバル化による性能向上への要望。・アプリケーション修正による性能向上が困難

【背景/課題】

【活用の広がり】

・メモリ大容量化、メモリ/Flash SSD単価の低下

・高速化ソリューションへの注目度の高まり・インメモリソフトウェア機能の浸透

近年100GB~数百GBメモリを搭載したデータベースサーバー出荷が増加。ハードウェア機能を活用してシンプルに性能を上げたいという要望が強い



Oracle製品分野でも大容量メモリ/SSDFlashの活用が大幅増。

SAN

DB Server 層DB Server 層

AP Server 層AP Server 層

Oracle Database

Oracle Coherence

インメモリデータグリッド基盤

大容量メモリ搭載データベース基盤

Oracle Times-ten

大容量メモリ搭載サーバー導入の多くがOracle Database基盤の高速化が目的



大容量メモリ/Flash SSDを活用した高速化事例

x18倍高速化

基幹系システム:バッチ処理大量メモリ、最新ストレージで高速化

情報系システム:各種SQL処理時間を最新HW+大量メモリで高速化

12分

3時間40分高負荷SQL

平均5~6時間の応答時間

平均3.7分

x102倍高速化

最新H/Wの活用+大量メモリを活用したチューニングで大幅な高速化を実現



メモリ/ Flash SSDの効果の有無はまずOracle AWR/Statspackで確認する。

• 処理時間中のCPU使用割合は20%程度• IO待ち時間が処理の大部分を占めている。(db file sequential read 53%)• 処理時間の平均 I/O待ち時間 5.0 ms• トップ5の内、3つがread IO Waitで占められている

例) Oracle AWR レポート Top 5 Timed Event

Event Waits Time(s) Avg wait (ms) % DB time Wait Class

db file sequential read 6,523,409 32,886 5 53.1 User I/O

DB CPU 12,384 20.32

enq:TX = row lock contention 566 1,140 2046 1.9 Application

db file scattered read 315,009 960 3 1.54 User I/O

db file parallel read 29,210 350 13 0.6 User I/O

上記のような場合、高負荷データをメモリ/半導体メモリ(Flash)に乗せれば、IO応答時間は1msec以下 (マイクロミリ秒)まで改善が見込めます。

劇的なIO応答時間の改善によりアプリケーション応答時間も大幅な改善が見込めます。



表/索引Ａ

表/索引Ｂ

表Ｃ

表/索引Ｄ

表Ｅ

表/索引Ｆ

表/索引Ｇ

表/索引Ｈ

表/索引Ｉ

表Ｊ

・

・

・

・

合計

X.X TB

※0.XX TB/年増加

表/索引Ａ

表/索引Ｄ

表/索引Ｆ

表/索引Ｇ

表/索引Ｈ

表/索引Ｂ

表 /索引Ｉ

アクセス頻度が高い表、索引を抽出

例：0.5 TB

DBサーバ

外部ストレージ

DBバッファ or ＫＥＥＰバッファ

Flash SSD

ストレージキャッシュ

ＨＤＤTEMP表領域

大量メモリ/ Flash SSD/HDDを活用したILMソリューション例

高負荷データを大量メモリ/SSD Flash領域に配置することでIO応答時間の

劇的な改善を図ることが可能。



全てのDBデータをメモリ/Flash SSDに格納する

IBM System x 大容量メモリサーバ & オールフラッシュストレージ FlashSystemメモリ高速化ソリューションによりIOパフォーマンス課題を劇的に改善します。

■ 超高速な応答時間

100マイクロ秒

■ FlashSystem 1台(1U)

実効容量20TB

IBM System x3750 M4IBM FlashSystem 820

オールフラッシュストレージ(1台あたり20TB/1U)

大容量メモリ搭載サーバー(1台あたり最大1.5TBメモリ)

1U1U 2U2U

■ 最大Read性能(1U)

50万IOPS

データ配置に関して余計なチューニングは一切不要。全てのデータをメモリ/Flash SSDに格納することで100% IO高速化



SQL Server 2012のインメモリー的機能 - 1

• xVelocity 列(カラム)ストアインデックス機能

• SQL Server 2012の新機能として追加

• 特定の列でインデックスを圧縮して作り、メモリー上に展開する

• 数倍から100倍までの性能向上が見込める

http://www.microsoft.com/ja-jp/sqlserver/2012/technology/self-learning.aspxより抜粋

http://download.microsoft.com/download/7/2/E/72E63D2D-9F73-42BB-890F-C1CA0931511C/SQL_Server_2012_xVelocityBenchmark_DatasheetMar2012.pdfより抜粋



SQL Server 2012のインメモリー的機能 - 2• Analysis Service インメモリーBI

• SQL Server 2012の新機能として追加

• Analysis Service上で表形式モードを選択する

ことでインメモリー機能が使用できる

http://download.microsoft.com/download/9/C/3/9C3F2150-8109-44E7-A22F-1E39A5DD7359/SQL_Server_Analysis_Services_Datasheet_Apr2012.pdfより抜粋



SQL Server 2012でのオンメモリー的機能

http://www.microsoft.com/global/ja-jp/sqlserver/2012/RichMedia/ssd-appliance/download.html

• SQL Server SSDアプライアンス

• データ領域・ログ領域をフラッシュメモリーストレージに配置することで高速化

• 厳密にはアプライアンスではなく、各サーバーベンダーの検証済み構成が掲載

• カラムストアインデックスのインメモリー機能も活用することで、インメモリー+オンメモリーの

ハイブリッド



次世代 SQL Serverのインメモリー機能

• 次世代 SQL Server Hekaton• 数年以内に登場?• レガシーデータベースエンジンとインメモリー

データベースエンジンのハイブリッド※

※ http://enterprisezine.jp/dbonline/detail/4654より

SQL Server Hekaton

LegacyDatabaseEngine

In MemoryDatabaseEngine

Hekaton is Greek for “hundreds,” and it was given this name for its ability to speed up database function 100x (possibly). It certainly increases application speed by 10x and nearly 50x for new, optimized applications.

Some eagle-eyed readers will see that this is very similar to other products that are currently available – like Oracle, xVelocity, or even Microsoft’s own PowerPivot and Power View. However, the biggest difference is that Hekaton is built directly into SQL Server, so that there are no extensions, downloads, or interfaces that can slow down the very program meant to help increase your speed.

http://blog.sqlauthority.com/2012/12/23/sql-server-what-is-hekaton-simple-words-explanation/



これからのインメモリーデータベースは?

インメモリーデータベースは、これまでのデータベースエンジンとアルゴリズムが異なるWhy?

これまでのデータベースは、データがHDD上にあることを前提として作られ

ているため、インメモリーでは無駄な処理となることB-Treeなどの索引検索

インメモリーデータベースでは、カラム型データ処理が使われていることが多いWhy?

圧縮率が高い縦方向の集計がしやすい

カラム型データ処理のデメリットは？行追加、更新処理が複雑となる

結果としてDWH、BI向けとなっていることが多い

データベースエンジンのインメモリーへの最適化カラム型データ処理のトランザクション対応が必要となる

データベースエンジンのインメモリーへの最適化カラム型データ処理のトランザクション対応が必要となる

第26回「インメモリー・コンピューティングの現状と将来」(2013/05/23 on...

Technology

Transcript of 第26回「インメモリー・コンピューティングの現状と将来」(2013/05/23 on...