SQL Server: インメモリ OLTP と列ストア機能の比較

31
SQL Server: インメモリ OLTP と列ストア機能の比較 テクニカル ホワイト ペーパー 作成者: Jos de Bruijn (マイクロソフト)、Sunil Agarwal (マイクロソフト)、Darmadi Komo (マイクロソフト)、Badal Bordia (ASPL)、Vishal Soni (ASPL) 技術校閲者: Bill Ramos (Indigo Slate) 発行日: 2015 年 5 月 対象製品: Microsoft SQL Server 2016 および SQL Server 2014 概要: Microsoft SQL Server のインメモリ機能は、多くの運用システムで現在実行している多くの完全 な統合ツールを独自に組み合わせたものです。これらのツールは、主にインメモリ オンライントランザ クション処理 (OLTP) およびインメモリ列ストアで構成されています。 インメモリ OLTP は、行ベースのインメモリ データのアクセスおよび変更機能を提供し、主にトランザ クション処理ワークロードで使用されますが、データ ウェアハウジング シナリオで使用されることもあ ります。このテクノロジは、ロックとラッチのないアーキテクチャを使用するので、直線的なスケーリ ングが可能です。インメモリ OLTP にはメモリ最適化データ構造があり、ネイティブなコンパイルが可 能なので、これまでよりも効率的なデータ アクセスとクエリ機能が実現します。このテクノロジは SQL Server データベース エンジンに統合されています。開発者およびデータベース管理者 (DBA) は同じ T-SQL、クライアント スタック、ツーリング、バックアップ、および AlwaysOn 機能を使用することが できるので、総保有コストが削減されます。さらに、同じデータベースでオンディスクとインメモリの 両方の機能を利用できます。インメモリ OLTP では、トランザクション処理ワークロードのスループッ トと待機時間を大幅に向上させ、大幅なパフォーマンスの向上を実現することが可能です。 インメモリ列ストアは、列比較を使用してストレージ フットプリントの削減とクエリ パフォーマンスの 向上を実現します。インメモリ列ストアでは、データの読み込みと分析クエリの実行を同時に行うこと

Transcript of SQL Server: インメモリ OLTP と列ストア機能の比較

Page 1: SQL Server: インメモリ OLTP と列ストア機能の比較

SQL Server: インメモリ OLTP と列ストア機能の比較

テクニカル ホワイト ペーパー

作成者: Jos de Bruijn (マイクロソフト)、Sunil Agarwal (マイクロソフト)、Darmadi Komo

(マイクロソフト)、Badal Bordia (ASPL)、Vishal Soni (ASPL)

技術校閲者: Bill Ramos (Indigo Slate)

発行日: 2015 年 5 月

対象製品: Microsoft SQL Server 2016 および SQL Server 2014

概要: Microsoft SQL Server のインメモリ機能は、多くの運用システムで現在実行している多くの完全

な統合ツールを独自に組み合わせたものです。これらのツールは、主にインメモリ オンライントランザ

クション処理 (OLTP) およびインメモリ列ストアで構成されています。

インメモリ OLTP は、行ベースのインメモリ データのアクセスおよび変更機能を提供し、主にトランザ

クション処理ワークロードで使用されますが、データ ウェアハウジング シナリオで使用されることもあ

ります。このテクノロジは、ロックとラッチのないアーキテクチャを使用するので、直線的なスケーリ

ングが可能です。インメモリ OLTP にはメモリ最適化データ構造があり、ネイティブなコンパイルが可

能なので、これまでよりも効率的なデータ アクセスとクエリ機能が実現します。このテクノロジは SQL

Server データベース エンジンに統合されています。開発者およびデータベース管理者 (DBA) は同じ

T-SQL、クライアント スタック、ツーリング、バックアップ、および AlwaysOn 機能を使用することが

できるので、総保有コストが削減されます。さらに、同じデータベースでオンディスクとインメモリの

両方の機能を利用できます。インメモリ OLTP では、トランザクション処理ワークロードのスループッ

トと待機時間を大幅に向上させ、大幅なパフォーマンスの向上を実現することが可能です。

インメモリ列ストアは、列比較を使用してストレージ フットプリントの削減とクエリ パフォーマンスの

向上を実現します。インメモリ列ストアでは、データの読み込みと分析クエリの実行を同時に行うこと

Page 2: SQL Server: インメモリ OLTP と列ストア機能の比較

2 ページ

ができます。更新可能な列ストアインデックスはメモリ最適化された列指向のインデックスで、主に

データ ウェアハウジング シナリオで使用されますが、運用分析にも使用できます。列ストア インデッ

クスは、クラスター化または非クラスター化の状態で作成できます。列ストア インデックスでは、デー

タは行グループに整理されます。これらの行グループは効率的に圧縮できるので、パフォーマンスが向

上します。列ストア インデックスを利用するクエリは、インメモリ パフォーマンス用に最適化された

バッチ モード処理を使用できます。列ストア インデックスは、メモリ最適化テーブルで特に便利です。

SQL Server のインメモリ ソリューションは、実証済みのデータ プラットフォーム アーキテクチャ上で

のパフォーマンスを劇的に向上させ、これまでよりも高速なトランザクションおよびクエリが実現する

ので、すばやく洞察を得ることができます。このホワイト ペーパーでは、これらのツールの主要なコン

ポーネントについて説明し、その他のプロバイダーが提供するソリューションとの比較を通して、

SQL Server のインメモリ テクノロジが他のソリューションに比べてどれほど優れているかを示します。

Page 3: SQL Server: インメモリ OLTP と列ストア機能の比較

著作権

このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見

解を反映したものです。変化する市場状況に対応する必要があるため、このドキュメントは、記載され

た内容の実現に関するマイクロソフトの確約とはみなされないものとします。また、発行以降に発表さ

れる情報の正確性に関して、マイクロソフトはいかなる保証もいたしません。

このホワイト ペーパーに記載された内容は情報の提供のみを目的としており、明示、黙示または法律の

規定にかかわらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。このド

キュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その

目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう

形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。ただしこれは、著作

権法上のお客様の権利を制限するものではありません。

マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、

またはその他の無体財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の

規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関す

る権利をお客様に許諾するものではありません。

© 2015 Microsoft Corporation. All rights reserved.

Microsoft、Active Directory、Microsoft Azure、Excel、SharePoint、SQL Server、Windows、およ

び Windows Server は、米国 Microsoft およびその関連会社の商標です。

その他のすべての商標は、それぞれの所有者に帰属します。

Page 4: SQL Server: インメモリ OLTP と列ストア機能の比較

4 ページ

目次

SQL Server のインメモリの利点の概要 ............................................................................................ 5

リアルタイムの洞察によるリアルタイムでのビジネス推進 .................................................................... 5

OLTP トランザクション ........................................................................................................................................................ 5

分析クエリ ................................................................................................................................................................................... 6

SQL Server のインメモリ OLTP の概要 ................................................................................................. 6

メモリ最適化テーブル: .......................................................................................................................................................... 6

メモリ最適化テーブル:のインデックス .......................................................................................................................... 7

同時実行の向上 .......................................................................................................................................................................... 7

ネイティブにコンパイルされたストアド プロシージャ: ........................................................................................ 8

インメモリ OLTP に関するお客様の導入事例 ............................................................................................................. 9

SQL Server のインメモリ列ストアの概要 ............................................................................................ 10

クラスター化および非クラスター化された列ストアインデックス ................................................................. 10

バッチ モードのクエリ処理 .............................................................................................................................................. 10

インメモリ列ストアに関するお客様の導入事例 ..................................................................................................... 12

SAP、Oracle、および IBM のインメモリ テクノロジの概要 ........................................................ 13

SAP HANA .............................................................................................................................................. 13

Oracle Database In-Memory ............................................................................................................... 13

IBM DB2 BLU Acceleration .................................................................................................................. 13

機能の比較 .................................................................................................................................................... 14

SAP HANA .............................................................................................................................................. 14

データベース プラットフォームとしての SAP HANA ......................................................................................... 14

SQL Server と HANA 上での SAP の実行 ................................................................................................................ 16

SAP HANA と SQL Server の比較 ............................................................................................................................... 17

Oracle ..................................................................................................................................................... 19

Oracle TimesTen: インメモリ OLTP ........................................................................................................................... 19

Oracle と SQL Server のインメモリ OLTP の比較 .............................................................................................. 20

Oracle 12c: インメモリ列ストア .................................................................................................................................. 22

Page 5: SQL Server: インメモリ OLTP と列ストア機能の比較

5 ページ

Oracle と SQL Server のインメモリ列ストアの比較 .......................................................................................... 22

IBM ......................................................................................................................................................... 24

IBM DB2 10.5: BLU Acceleration による分析 ...................................................................................................... 24

IBM DB2 BLU Acceleration と SQL Server インメモリの比較 .................................................................... 25

虚像と現実:SQL Server のインメモリ OLTP とインメモリ ........................................................... 27

ラッチなしのアーキテクチャ ........................................................................................................................................... 27

分離データベース エンジン .............................................................................................................................................. 28

OLTP への適性 ........................................................................................................................................................................ 28

競合企業のインメモリ製品への対応 ............................................................................................................................. 29

古い SQL 機能 DBCC PINTABLE と同等のインメモリ OLTP .......................................................................... 29

結論 .................................................................................................................................................................. 29

主なリソース ................................................................................................................................................ 30

SQL Server のインメモリの利点の概要

リアルタイムの洞察によるリアルタイムでのビジネス推進

Microsoft SQL Server のインメモリ OLTP およびインメモリ列ストアは、OLTP およびデータ ウェアハ

ウジング ソリューションを大きく進化させ、10 ~ 100 倍のパフォーマンス向上を実現します。インメ

モリ OLTP では、組織における従来のアプリケーションを最大 30 倍高速にして、100 倍以上高速なク

エリとレポートですばやい意思決定を行うことができます。一般的な業界ハードウェアで毎秒 10 億行

レベルのスキャン レートを実現するインメモリ列ストア インデックスでは、これまでにない膨大な量の

データをすばやく操作することができます。SQL Server は、ほぼリアルタイムでのデータのトランザク

ションと分析を行う機能でビジネス目標を達成することのできる堅牢なデータ プラットフォーム アーキ

テクチャを提供します。

OLTP トランザクション

インメモリ OLTP は、SQL Server エンジンに統合され、OLTP ワークロードを最適化するメモリ最適化

データベース エンジンです。OLTP エンジンは、ラッチおよびロックのないデータ構造、および複数

Page 6: SQL Server: インメモリ OLTP と列ストア機能の比較

6 ページ

バージョンの同時制御を使用して、非常に高い同時実行レートをサポートするので、データベース トラ

ンザクションの高いスループットに加えて、直線的なスケーリングが可能です。実際のパフォーマンス

向上は多くの要因に左右されますが、一般的に 2 ~ 20 倍のパフォーマンス向上が実現します。実際、

従来のテーブルおよびデータベース エンジンに比べて、最大 30 倍のトランザクション パフォーマンス

が向上することがあります。

分析クエリ

The SQL Server のインメモリ列ストア インデックスは、列ベースのデータ ストレージおよび列ベース

のクエリ処理を使用してデータを格納および管理します。列ストア インデックスでは、一般的なデータ

ウェアハウス クエリ (フィルター、集計、グループ化、スター結合など) の高速なパフォーマンスを

実現することによってユーザーのデータ ウェアハウス エクスペリエンスを刷新することができます。列

ストア インデックスを使用すれば、従来の行ベースのストレージに比べて最高 100 倍のクエリ パ

フォーマンスの向上および共通のデータ パターンの大幅なデータ圧縮 (通常 10 倍) を達成すること

ができます。

SQL Server のインメモリ OLTP の概要

メモリ最適化テーブル:

SQL Server のインメモリ OLTP エンジンでは、既存のリレーショナル データベース内にメモリ最適化

OLTP テーブルを作成できます。“メモリ最適化” テーブルは、(従来の “ディスク ベース” のテーブルと

は異なり) 完全にメモリ内に存在します。 ディスク ベースのテーブルと比較した場合のメモリ最適化

テーブルの主な違いは、メモリ最適化テーブルではデータは行として格納されます。メモリ最適化テー

ブルにアクセスする際、ページをメモリに読み取る必要はありません。データの永続性を目的として、

ディスク ベースのテーブルに使用されるデータ ファイルに似たチェックポイント ファイル (データおよ

びデルタ ファイルのペア) のセットがメモリ最適化ファイル グループに作成されます。しかし、ディス

ク ベースのテーブルに使用されるデータ ファイルとは異なり、これらのチェック ファイルは追加専用

なので、SQL Server でストレージの完全な I/O 帯域幅を活用できます。これらのチェックポイント

ファイルはトランザクション ログと共に完全な永続性を実現するので、再起動時の回復やデータベース

のバックアップ/復元で使用されます。

Page 7: SQL Server: インメモリ OLTP と列ストア機能の比較

7 ページ

メモリ最適化 OLTP テーブルには、SCHEMA_AND_DATA (永続テーブル) と SCHEMA_ONLY (非永続

テーブル) という 2 つの種類があります。.前者は、OLTP ワークロード用のディスク ベースのテーブル

と同様に完全な永続性を保証します。これは、メモリ最適化テーブルを作成する際の既定の設定です。

後者は、テーブルのスキーマを維持しますが、データは維持しません。SCHEMA_ONLY は、OLTP ワー

クロードでデータの永続性が必要ないシナリオ (アプリケーションのセッション状態の管理、ETL シナ

リオでのステージング テーブル、またはテーブル タイプを使用する TempDB の一時テーブルの置き換

えなど) で使用されます。

メモリ最適化テーブル:のインデックス

メモリ最適化テーブルは、ハッシュ インデックスと範囲インデックスという 2 種類の非クラスター化イ

ンデックスをサポートします。ハッシュ インデックスは等価検索で最適なアクセス パスを提供し、範囲

インデックスは、範囲述語を使用するクエリやデータからの順序付けられた抽出を行う場合に使用され

ます。

各メモリ最適化テーブルには、少なくとも 1 つのインデックスが必要です。永続的なメモリ最適化テー

ブルの場合、回復時にトランザクション ログ レコードの変更を処理する際に行を一意に識別するために

一意のインデックスが必要です。インメモリ テーブルのインデックスはメモリ内にのみ存在します。こ

れらのインデックスはチェックポイントに格納されることはなく、インデックスへの変更もログに記録

されません。インデックスは、ディスク ベースのテーブルの B ツリー インデックスと同様に、メモリ

最適化テーブルでのすべての変更操作で自動的に維持されますが、SQL Server が再起動した場合、デー

タがメモリに読み込まれ、メモリ最適化テーブルのインデックスが再構築されます。

同時実行の向上

エンジン レベルの同時実行 (ラッチ競合やブロッキングなど) によってパフォーマンスの影響を受ける

アプリケーションをインメモリ OLTP に移行した場合、そのパフォーマンスは大幅に向上します。メモ

リ最適化テーブルにはページがないのでラッチがなく、したがってラッチ待機もありません。データ

ベース アプリケーションの読み取り操作と書き込み操作の間でブロッキングの問題が発生する場合、

データへのアクセスでオプティミスティックな同時実行制御を使用するインメモリ OLTP によってブ

ロッキングの問題が取り除かれます。オプティミスティックな制御は行バージョンを使用して実装され

ますが、ディスク ベースのテーブルとは異なり、行バージョンはメモリ内に維持されます。

Page 8: SQL Server: インメモリ OLTP と列ストア機能の比較

8 ページ

メモリ最適化テーブルのデータは常にメモリ内に存在するので、I/O パスに起因する待機時間は排除さ

れます。また、ディスクからのデータ読み取りやデータ行のロックによる待機時間も発生しません。

ネイティブにコンパイルされたストアド プロシージャ:

SQL Server は、メモリ最適化テーブルにアクセスするストアド プロシージャをネイティブにコンパイ

ルできます。ネイティブにコンパイルされたストアド プロシージャは、T-SQL 文を最適化して

Visual C コードに変換し、DLL を生成します。したがって、SQL Server では、従来のストアド プロ

シージャに比べて少ない命令を使用して非常に効率的にストアド プロシージャでビジネス ロジックを実

行できます。SQL 2014 では、OLTP ワークロードで一般的に使用される T-SQL ワークロードをストア

ド プロシージャの内部でネイティブに使用できます。SQL Server チームは、新しいリリースで T-SQL

の対象領域を引き続き拡大しています。

Page 9: SQL Server: インメモリ OLTP と列ストア機能の比較

9 ページ

インメモリ OLTP に関するお客様の導入事例

bwin.party は、トラフィックが非常に多い Web サイトを運営

していた bwin Interactive Entertainment と PartyGaming と

いう 2 つの大手ゲーム企業の統合によって生まれました。2 つの

企業の Web サイトの統合により、bwin.party のインフラスト

ラクチャのオーバーヘッドは増大しました。同社は、このスケー

ラビリティの問題を解決し、ゲーミング Web サイトのパフォー

マンスを向上させてビジネスの成長をサポートしたいと考えてい

ました。

解決作:

SQL Server 2014 に搭載されているマイクロソフトのインメモ

リ OLTP ソリューションを使用することによって、同社のゲーミ

ング システムは毎秒 250,000 のリクエスト (元の負荷の約 20

倍) を処理できるようになり、プレーヤーにより高速でスムーズ

なゲーミング エクスペリエンスを提供しています。

利点:

スケーラビリティ: bwin.party のゲーミング システムは毎

秒 250,000 のリクエストまでスケールできます (約 20 倍

の向上)。

高速でスムーズなゲーミング エクスペリエンス: 標準のシス

テム応答時間は 50 ミリ秒から 2 ~ 3 ミリ秒に向上し、高

速で優れたパフォーマンスが実現しました。

コスト削減と収益増加: bwin.party はインメモリ OLTP を以

前よりも少ないハードウェアで実行し、年間 100,000 ドル

の節約が可能になりました。

詳細については、https://customers.microsoft.com/Pages/CustomerStory.aspx?recid=12362

(英語) を参照してください。

「SQL Server 2014 のインメモ

リ OLTP を使用することによっ

て、当社は、より高速なロー

ディング サイトと高速なえくす

ペリネスを提供しています。プ

レーヤーは、多くのゲームをよ

りスムーズにプレイできます。」

Rick Kutschera 氏

データベース エンジニアリング

部門マネージャー

bwin.party

Page 10: SQL Server: インメモリ OLTP と列ストア機能の比較

10 ページ

SQL Server のインメモリ列ストアの概要

インメモリ列ストアはカラムナ ストレージ形式を使用して、ストレージ フットプリントを一般的に

1/10 に削減し、分析クエリ パフォーマンスを最大 10 倍向上させます。あまり頻繁に参照されない

データを COLUMNSTORE_ARCHIVE で圧縮すると、さらに 30% の圧縮が可能です。カラムナ スト

レージ形式では、各列を個別に格納することによって大幅なデータ圧縮が可能です。1 つの列内のデー

タは類似していて繰り返されることがあるので、非常に高いレベルのデータ圧縮が可能になります。圧

縮率が高いので、小さいインメモリ フットプリントを使用してクエリ パフォーマンスを向上させること

ができます。分析クエリでは、FACT テーブルの数行だけが選択されることがあります。カラムナ スト

レージでは、必要な列だけがメモリに読み込まれるので、すべての列が行の一部としてメモリに読み込

まれる行ベースのストレージ形式とは異なり、I/O がさらに削減されます。

クラスター化および非クラスター化された列ストアインデックス

SQL Server 2014 は、夕ライの行ストア テーブルに置き換わる新しいクラスター化列ストア インデッ

クスをサポートします。クラスター化された列ストア インデックスでは、データ ウェアハウスおよび意

思決定支援システム (DSS) ワークロードでのデータ変更とデータ読み込みを同時に行うことができます。

圧縮形式での述語の適用、可能菜場合のストレージへの述語のプッシュ ダウン、新しいプロセッサ アー

キテクチャの活用、および新しいバッチ実行モードなどの技法で削減された IO と最適化されたクエリ

実行によって、クエリ パフォーマンスの速度が 100 倍向上します。

SQL Server では、主に運用分析の目的 (運用ストアの分析など) で行ストア テーブル上に非クラスター

化列ストア インデックスを作成できます。SQL Server 2016 では、非クラスター化列ストア インデッ

クスを更新することができます。

最適なデータ圧縮を行うために、列ストア インデックスの行は通常 100 万行のセットにグループ化さ

れます。この行のグループは、行グループと呼ばれます。行グループ内では、各列の複数の値が圧縮さ

れ、LOB として格納されます。これらの LOB はセグメントと呼ばれます。列セグメントは、ディスク

とメモリの間の転送の単位です。

バッチ モードのクエリ処理

基本的に、バッチ モードのクエリ処理は、列ストア インデックスに緊密に統合されたベクトル ベース

のクエリ実行メカニズムです。列ストア インデックスをターゲットとするクエリでは、バッチ モードを

Page 11: SQL Server: インメモリ OLTP と列ストア機能の比較

11 ページ

使用して最大 900 の行を一緒に処理できるので、クエリ実行を効率化して、クエリ パフォーマンスを

3 ~ 10 倍向上させることができます。SQL Server では、バッチ モード処理は、列ストア インデック

スの構造とインメモリの機能を最大限に活用するために列ストア インデックス用に最適化されています。

Page 12: SQL Server: インメモリ OLTP と列ストア機能の比較

12 ページ

インメモリ列ストアに関するお客様の導入事例

イスラエルの人口の 60% にヘルスケア サービスを提供する Clalit

Health Services のミッションは、患者への臨床サービスを継続的

に向上させることです。大規模なデータ インフラストラクチャを有

する同社は、より多くのユーザー、より多くのデータ、そしてより

複雑なクエリを管理する必要性に迫られていました。クエリ応答時

間はビジネス分析にとって非常に重要な生産性の要素なので、複雑

なクエリで分析を実行する効率的な方法が必要とされていました。

解決作:

Clalit は、Microsoft SQL Server 2014 の列ストア インデック

ス機能を使用して概念実証を実施し、コードの変更や調整を実装

することなく、各データベース バージョンに “問題クエリ” を

実行することに成功しました。

利点:

高いアナリスト生産性のサポート: クエリ時間が 20 分から

3 秒に短縮され、日常的にデータ ウェアハウスを操作する

300 人のアナリストの生産性が飛躍的に向上しました。

40% のディスク削減: 以前のデータ ソフトウェアに比べ

て、クエリは 40% 少ないディスク容量で実行しました。

深いデータ洞察の提供: アナリストとリサーチャーは少ない

時間で多くの分析を実行するだけでなく、より複雑な分析を

少ない時間で実行できます。

詳細については、https://customers.microsoft.com/Pages/CustomerStory.aspx?recid=4166 (英

語) を参照してください。

「実行に 30 分かかるクエリに

よってレポートが丸 1 日以上遅

れることがります。SQL Server

2014 では、そのようなことは

あり得ません。」

Anatoly Ternov 氏

データベース管理者 兼 ETL

チーム リーダー

Clalit Health Services

Page 13: SQL Server: インメモリ OLTP と列ストア機能の比較

13 ページ

SAP、Oracle、および IBM のインメモリ テクノロジの概要

現在、多くのベンダーがさまざまなタスクを目的としたインメモリ データベースを提供しています。こ

こでは、SAP、Oracle、および IBM のインメモリ テクノロジについて解説します。

SAP HANA

SAP は、同一のプラットフォームで高いトランザクション レートと複雑なクエリ処理の両方を処理する

ことを目的に設計されたインメモリの列指向リレーショナル データベース管理システムとして

SAP HANA を位置付けています。SAP HANA は、リアルタイム分析および多くのベンダー (IBM、HP、

Dell、富士通、Cisco など) またはクラウド プロバイダー (AWS、VMware、SAP など) から提供され

る構成済み SUSE Linux ベース アプリケーション用のプラットフォームです。SAP のインメモリ コン

ピューティングは、SAP HANA プラットフォームの基盤となるコア テクノロジですが、アプラインスに

は、データ モデリング、データ管理、およびセキュリティに加えて、トリガー ベースおよび ETL ベー

スのレプリケーション用のツールも含まれています。SAP HANA は、インメモリ OLTP とインメモリ列

ストアの両方を提供します。

Oracle Database In-Memory

Oracle Database In-Memory は、SAP HANA の対抗機能として設計された Oracle データベース 12c

の新しいオプションです。これは、Oracle Database 12c のアドオンで、オラクルの旗艦リレーショナ

ル ソフトウェアをインメモリ データベースとして機能させます。Oracle Database In-Memory は、

Oracle Database 12c を実行する任意のプラットフォームで機能します。インメモリ OLTP を使用する

には、Oracle TimesTen という別の製品が必要ですが、この製品は Oracle のメイン データベースに完

全に統合されていません。

IBM DB2 BLU Acceleration

IBM 基礎研究所で開発された IBM DB2 BLU Accelerationは、IBM DB2 10.5.に統合する新しいイン

メモリ機能です。この製品は、従来の DB2 と同じストレージとメモリ コンストラクト (ストレージ グ

ループ、テーブル スペース、バッファ プールなど)、SQL 言語インターフェイス、および管理ツールを

使用します。IBM DB2 BLU Acceleration は、データ ウェアハウスおよび分析アプリケーションに適し

たインメモリ列ストア実装です。

Page 14: SQL Server: インメモリ OLTP と列ストア機能の比較

14 ページ

機能の比較

SAP HANA

データベース プラットフォームとしての SAP HANA

SAP は、データベース プラットフォームおよび分析アプライアンスとして HANA を提供しています。

現在、SAP は、HANA メッセージを使用してマーケティングを展開している広範な製品に HANA のブ

ランドとメッセージを使用しています。

OLTP および分析における SAP HANA の列ストア

SAP HANA の主な目標は、データベース内の同じテーブルで OLTP と分析を実行することです。HANA

はデータの同じインスタンス上で両方のアプリケーションを同時にサポートします。従来のシステムで

は、データベースに OLTP テーブ、正規化されたスキーマ、および ETL ワークロードとプロセスがあり

ますが、これらのテーブルは分析の実行に最適化されていません。分析に関連する操作では、ユーザー

は、これらの OLTP テーブルを別のスキーマ (STAR スキーマなど) に変換して、分析に最適化された

データ ウェアハウスとして保持する必要があります。このプロセスは複雑さだけでなく、必要なデータ

ウェアハウスの作成と管理の労力も増大させます。また、データの待機時間も発生するので、ユーザー

は、これらの従来のシステムを使用してリアルタイムのビジネス洞察を得ることができません。

このような問題にフォーカスした SAP は、同じテーブルで OLTP と分析を実行するという約束を掲げて

HANA をリリースしました。OLTP に列ストアを使用するために、SAP は、同じシステムで分析も実行

できるような方法でメインの OLTP システムを最適化しました。その鍵となるのが、分析で適切に実行

し、OLTP ワークロードを処理できる列ストアです。このソリューションを使用すると、インメモリ テ

クノロジ上で列ストア データベースに対して OLTP を実行できます。SAP は、OLTP でのパフォーマン

スを向上させるために HANA にいくつかの最適化を実装ました。たとえば、データは列ストア形式その

ものに格納され、プライマリ キー制約は列ストア形式に適用されます。しかし、HANA は従来の B ツ

リー テーブルと適切に連動しません。従来の SQL Server B ツリー テーブルは、OLTP の操作で引き続

き優れたパフォーマンスを発揮します。したがって、HANA のパフォーマンスは OLTP と分析の両方で

損なわれています。

Page 15: SQL Server: インメモリ OLTP と列ストア機能の比較

15 ページ

SQL Server のパフォーマンスは OLTP でも分析でも損なわれることはありません。マイクロソフトは、

それぞれの種類のワークロードで優れたパフォーマンスを実現する列ストア インデックスを使用するメ

モリ最適化テーブルおよび最適な分析ソリューションを使用して、OLTP ワークロード向けの最適なイ

ンメモリ ソリューションを提供します。SQL Server では、更新可能なクラスター化列ストア インデッ

クスを提供するために、分析用にインメモリ列ストアが拡張されています。その結果、クエリ速度が最

大 100 倍向上し、ストレージ コストが 1/10 に削減されます。一般的なデータ分析プラットフォーム

では、インメモリ OLTP は、メモリ最適化が行われ、従来のデータベースで発生していた同時実行アク

ティビティにおけるロックとラッチによるボトルネックのない新しいエンジンで既存の DBMS を拡張し

ます。

SQL Server 2016 は、これらのテクノロジを組み合わせて、メモリ最適化テーブルまたは従来のディス

ク ベースのテーブルのいずれかで実行する運用データのリアルタイム分析を実現しています。

SAP HANA のスケール アウトのサポート

SAP HANA は、複数のマシンにわたってデータベースをスケール アウトできます。SAP HANA の列ス

トア テーブルは完全にメモリに格納される必要があります。HANA には、一部の列をディスクにフラッ

シュするオプションがありますが、ほとんどのデータはメモリ内に存在する必要があります。HANA

サーバーでは使用できるメモリは 2 TB または 4 TB です。データはメモリ内に存在する必要があるの

で、大規模なデータベースの場合はメモリをスケール アウトする必要があります。その結果、OLTP ス

ケール アウト構成で基本的なパフォーマンスの問題が発生することがあります。たとえば、複数のテー

ブルにわたる結合があり、クエリを実行するために複数の異なるテーブル間でデータを移動する必要が

ある場合、パフォーマンスは低下します。

SQL Server では、すべての列ストア インデックスをメモリに格納する必要はありません。列ストア イ

ンデックスはディスク上に存在し、必要なデータだけが必要に応じてクエリ実行の一部としてメモリに

読み込まれます。したがって、2 TB のサーバー上で 40 TB のデータを実行するといった非常に大規模

なデータウェアハウス構成を行うことが可能です。ほとんどの場合、この構成で適切に実行します。ペ

タバイト レベルの大量のデータ ウェアハウス データに対応するために、マイクロソフトは Analytics

Platform System (APS) および Azure SQL Data Warehouse (近日リリース予定) を提供します。

Page 16: SQL Server: インメモリ OLTP と列ストア機能の比較

16 ページ

SAP HANA の分析機能

SAP HANA は、データベース エンジンに組み込まれた R 統合などの高度な分析機能をサポートします。

SQL Server 2016 も R 統合をサポートします。

SQL Server と HANA 上での SAP の実行

アプリケーションとデータベースの両方を所有する SAP

SAP には、SAP ERP や SAP CRM などのエンタープライズ グレードのアプリケーションに加えて、そ

れをサポートするデータベース (最近開発された SAP HANA データベース) があります。SAP HANA

データベースは、SAP アプリケーションと連動することを目的に設計されていて、SAP アプリケーショ

ンは HANA データベースに合わせて変更されています。

しかし、マクロソフトには、SQL Server 上で SAP を実行できるという利点があります。マイクロソフ

トは、SAP アプリケーションを実行するデータベースに関する実績があり、この事実は、マイクロソフ

ト プラットフォーム上での SAP 展開の拡大に反映されています。事実、SAP アプリケーションがマイ

クロソフト プラットフォーム上で適切に機能するよう、マイクロソフトと SAP は緊密に協力していま

す。SQL Server の SAP 認定は、この共同の取り組みに関する技術的な証明です。現在、65,000 以上

の SAP インストールが Windows Server プラットフォーム上で実行しています。これは、既存の SAP

インストールの 57% に相当します。また、これらの SAP インストールの 30,000 以上が SQL Server

上で実行しています。これらのテクノロジに精通し、SAP 用に SQL Server を使用するデータベース

アーキテクトと開発者の数は、世界中で増えています。SQL Server は SAP 用に実証されたエンタープ

ライズ対応ソリューションで、低価格設定、管理オーバーヘッドの削減、組み込みの高可用性、および

スケーラビリティによる最も低いデータベース プラットフォーム総保有コスト (TCO) で業界をリード

しています。

SAP HANA 上の SAP Business Warehouse と SQL Server 2014 のクラスター化列ストアの比較

SAP は、同社の Business Warehouse (BW) が SAP HANA Database で適切に機能すると主張してい

ます。SAP BW は、SAP HANA のインメモリ機能と適切に実行する多くの新しい機能を追加します。

Microsoft SQL Server のインメモリ機能も SAP BW のパフォーマンス向上に役立ちます。SQL Server

の列指向ストアは大量のデータの集計に最適化されていて、BW 集計に使用することができます。

SQL Server 2014 のクラスター化列ストアは SAP BW と非常に適切に連動し、SAP HANA と同様の

Page 17: SQL Server: インメモリ OLTP と列ストア機能の比較

17 ページ

パフォーマンスを実現します。列指向ストアは大量の履歴データの集計に最適化されていて、一般的な

データ ウェアハウス クエリ (フィルター、集計、グループ化、スター結合など) の高速なパフォーマ

ンスを実現します。SQL Server ではデータをメモリに常駐させる必要がないので TCO を削減すること

ができます。したがって、単一の SQL Server 展開上に大規模な SAP BW を展開することができます。

SAP HANA と SQL Server 2014 上の SAP Business Suite の比較

SAP は、SAP Business Suite は SAP HANA と連動するように最適化されていて、単一のインメモリ

プラットフォーム上で多くのリアルタイム アプリケーションを実行することができると主張しています。

また、SAP Business Suite には、ビジネス要件に合わせた複数の展開オプション (オンプレミス、クラ

ウド、またはハイブリッド) があります。

Microsoft SQL Server 2014 は、ミッション クリティカル環境を実現する最適なデータベースで、あら

ゆるサイズの SAP ERP アプリケーションでの可用性とパフォーマンスを低い TCO で実現します。

Microsoft SQL Server 2014 上で SAP を実行する顧客は、包括的なデータ管理機能 (高可用性、管理性、

ストレージ、バックアップの圧縮、テーブルのパーティション分割、監査、およびセキュリティ機能) を

活用できます。SQL Server の AlwaysOn テクノロジは高可用性と障害復旧機能を組み合わせて、SAP

の構成およびアーキテクチャを管理する場合に高い柔軟性を発揮します。SAP の顧客は、透過的なデー

タ暗号化を使用して、アプリケーションを変更することなく、データベース全体、データ ファイル、お

よびログ ファイルを暗号化することができます。

また、クラウドのリソースをオンデマンドで提供することにより、Microsoft Azure 上で SAP ソリュー

ションを実行することもできます。Microsoft Azure は、高い信頼性とセキュリティを備えたクラウド

インフラストラクチャ プラットフォームで、ビジネスがクラウドに SAP ソリューションをすばやく展

開することを可能にします。また、障害復旧 (DR) サイトを Azure 上に作成することもできるので、高

い可用性が保証されます。

SAP HANA と SQL Server の比較

SQL Server と SAP HANA の機能の比較を表 1 に示します。

機能 SAP HANA SQL Server 2014 SQL Server 2016

Page 18: SQL Server: インメモリ OLTP と列ストア機能の比較

18 ページ

分析ワークロード用の

列ストア最適化

あり あり あり

OLTP ワークロード用の

インメモリ最適化

なし あり あり

サイズの大きい列ストア

テーブルのディスクへの

自動フラッシュ

なし あり あり

データ ウェアハウスの

スケール アウト

あり あり (APS と

Azure SQL DW)

あり (APS と

Azure SQL DW)

OLTP のスケール アウト 制限あり 読み取りのスケール

アウト

(AlwaysOn RS)

読み取りのスケール

アウト

(AlwaysOn RS)

リアルタイム分析 あり なし あり (ディスク

ベースおよびメモリ

最適化)

R の統合 あり なし あり

表 1: SAP HANA と SQL Server の機能の比較

• 分析ワークロード用の列ストア最適化: SAP HANA と SQL Server は両方とも分析での列ストア最適

化をサポートします。

• OLTP ワークロード用の列ストア最適化: SAP HANA は分析と OLTP の両方で同じソリューションを

使用します。SAP は、OLTP でのパフォーマンスを向上させるために HANA にいくつかの最適化を

実装ました。たとえば、データは列ストア形式そのものに格納され、プライマリ キー制約は列ストア

形式に適用されます。しかし、HANA は従来の B ツリー テーブルと適切に連動しません。マイクロ

ソフトは、それぞれの種類のワークロードで優れたパフォーマンスを実現する列ストア インデックス

を使用するメモリ最適化テーブルおよび最適な分析ソリューションを使用して、OLTP ワークロード

向けの最適なインメモリ ソリューションを提供します。

• サイズの大きい列ストア テーブルのディスクへの自動フラッシュ: SAP HANA の列ストア テーブル

は完全にメモリに格納される必要があります。HANA には、一部の列をディスクにフラッシュするオ

Page 19: SQL Server: インメモリ OLTP と列ストア機能の比較

19 ページ

プションがありますが、ほとんどのデータはメモリ内に存在する必要があります。SQL Server では、

すべての列ストア インデックスをメモリに格納する必要はありません。列ストア インデックスは

ディスク上に存在し、必要なデータだけが必要に応じてクエリ実行の一部としてメモリに読み込まれ

ます。

• データ ウェアハウスのスケール アウト: SQL Server にはデータ ウェアハウス用の汎用スケール ア

ウト ソリューションがありませんが、読み取り可能な AlwaysOn セカンダリによる読み取りのス

ケール アウトが可能です。ペタバイト レベルの大量のデータ ウェアハウス データに対応するために、

マイクロソフトは Analytics Platform System (APS) および Azure SQL Data Warehouse (近日リ

リース予定) を提供します。

• OLTP のスケール アウト: SAP HANA では、データはメモリ内に存在する必要があるので、大規模

なデータベースの場合はメモリをスケール アウトする必要があります。その結果、OLTP スケール

アウト構成で基本的なパフォーマンスの問題が発生することがあります。SQL Server では、読み取

り可能な AlwaysOn セカンダリによる読み取りのスケール アウトが可能です。

• リアルタイム分析: SAP HANA はリアルタイム分析をサポートします。この機能は、

SQL Server 2016 においてディスク ベースのテーブルとメモリ最適化テーブルの両方でサポートさ

れるようになりました。

• R の統合: SAP HANA は R の統合をサポートします。この機能も SQL Server 2016 でサポートさ

れるようになりました。

Oracle

現時点では、Oracle Database は OLTP ワークロードに対するインメモリ機能のネイティブ サポートを

提供していませんが、分析ワークロード用に Oracle Database 12c のオプション アドオンとしてイン

メモリを提供しています。オラクルは、"TimesTen” という個別の製品でスタンドアロンのインメモリ機

能を提供しています。この製品は Oracle Database と統合しますが、2 つの異なる製品を個別にインス

トールおよび管理する必要があります。

Oracle TimesTen: インメモリ OLTP

インメモリ リレーショナル データベース システムである TimesTen は、1995 年に HP のリサーチ プ

ロジェクトとして始まり、後に別の企業に移されました。TimesTen は 2015 年に Oracle に買収され

Page 20: SQL Server: インメモリ OLTP と列ストア機能の比較

20 ページ

た後、Oracle スタック (PL/SQL や OCI など) および Oracle の MAAN (Max Availability

Architecture) との統合が行われています。

TimesTen は以下の方法で展開できます。

• クライアント/サーバー インターフェイス: 従来のクライアント/サーバー インターフェイスがサ

ポートされ、多くのアプリケーション層プラットフォームの共通インメモリ データベースのレポート

やアクセスなどのシナリオに対応できます。

• 直接リンクされたアプリケーション: アプリケーションを TimesTen アドレス空間に直接リンクして、

IPC オーバーヘッドを排除してクエリ処理を効率化し、最適なクエリ パフォーマンスを実現できます。

• Oracle Database のキャッシュ (TimesTen キャッシュ): ワークロード専用の Oracle データベー

スが既に存在する場合、TimesTen は、アプリケーションと Oracle データベースの間のキャッシュ

データベースの追加層として展開することができます。この中間層のキャッシュ テーブルは、読み取

り専用または更新可能にすることができます。アプリケーションは、標準の SQL インスタンスを使

用して TimesTen キャッシュ テーブルにアクセスできます。これらのキャッシュ テーブルと Oracle

データベースの間の同期は自動的に実行されます。

Oracle と SQL Server のインメモリ OLTP の比較

Oracle TimesTen は比較的古い製品です。それとは対照的に、SQL Server のインメモリ OLTP では、多くの

最新テクノロジを活用して、優れたツールセットとして機能します。Oracle TimesTen と SQL Server 2014

のインメモリ OLTP および SQL Server 2016 のインメモリ OLTP の比較を表 2 に示します (後者ではネイ

ティブ コンパイルと追加の永続性機能の面で SQL 言語の対象領域が拡張されています)。

機能 TimesTen SQL Server 2014 SQL Server 2016

SQL 言語 ほとんどの PL/SQL (DW

を含む) をサポート

InterOp がほどんどの

OLTP をサポート

T-SQL 対象領域の拡張

ネイティブ コンパイル なし あり。OLTP ワークロー

ドをターゲットとした

T-SQL 対象領域

T-SQL 対象領域の拡張

ロック ベース あり。行、テーブル、

データベースをロック

なし。オプティミス

ティックな同時実行制御

新しい変更なし

Page 21: SQL Server: インメモリ OLTP と列ストア機能の比較

21 ページ

(接続レベルで選択) を使用

統合 Oracle Database との

緩やかな結合

SQL との完全な結合 新しい変更なし

永続性 データベース レベ

ル (永続および一

時データベース)

テーブル レベル。

すべてのテーブルは既定

で永続的。個々のテーブ

ルを非永続的としてマー

クすることが可能)。

2 TB のデータベースの永

続メモリ最適化テーブル

セキュリティ テーブルへのアクセス

および管理操作を制御

する監査および権限

透過的なデータ暗号化

表 2: インメモリ OLTP: Oracle TimesTen と. SQL Server の比較

• SQL 言語: TimesTen と TimesTen Cache は両方とも PL/SQL をサポートします (データ ウェアハ

ウスを含む)。この機能の主な利点は、Oracle サーバー上で実行する PL/SQL アプリケーションをほ

とんど変更することなく TimesTen に容易に統合することができることです。同様に、InterOp モー

ドの SQL Server は、ほとんどの OLTP をサポートします。

• ネイティブ コンパイル: インメモリ OLTP のネイティブ コンパイルは、Oracle TimesTen でサポー

トされていません。SQL Server では、操作 (ストアド プロシージャ) をインメモリ OLTP テーブル

上でネイティブにコンパイルして、最大のビジネス処理パフォーマンスを実現できます。

SQL Server の将来のリリースでは、対象領域が拡張され、ネイティブ コンパイル機能がさらに拡張

される予定です。

• ロック ベース: Oracle は、行、テーブル、およびデータベース レベルでのロック メカニズムを提供

します。このロック メカニズムは接続時に構成できます。この方法では、同時実行のボトルネックが

発生することがあります。SQL Server はオプティミスティックな同時実行を提供するので、ロック

はありません。したがって、干渉のないスケール アップが可能です。

• 統合: Oracle TimesTen は個別の製品なので、Oracle Database に統合するためのメカニズムが必要

です。マイクロソフトのインメモリ OLTP は個別の製品ではなく、SQL Server の一部なので、バッ

Page 22: SQL Server: インメモリ OLTP と列ストア機能の比較

22 ページ

クアップ、復元、および管理の件で非常に効率的です。また、SQL Server のインメモリ OLTP は

データベースに統合されているので、最もパフォーマンス クリティカルなテーブルだけをメモリ最適

化テーブルに移行することができます。SQL Server には、メモリ最適化テーブルに移行することが

推奨されるテーブルを識別するために役立ついくつかのレポートが含まれています。

• 永続性: Oracle では、永続性はデータベース レベルで制御されます。SQL Server の永続性はテーブ

ル レベルで制御されるので、アプリケーション内でテーブルを適切に構成する柔軟性があります。た

とえば、データのステージングを行う非永続的なメモリ最適化テーブルを作成できます。

Oracle 12c: インメモリ列ストア

Oracle は、Oracle Database 12c のオプション アドオンとしてインメモリ列ストアを提供しています。

このオプションをテーブルまたはテーブルスペースに対して有効にすると、Oracle の内部でデータのサ

ブセットのコピーがカラムナ ストレージ形式で作成されるので、データベース管理者は、最もパフォー

マンス クリティカルなデータだけを選択してメモリに読み込むことによって分析の速度を向上させるこ

とができます。インメモリ データへの変更は非永続的なので、Oracle DB を再起動した場合は再構築す

る必要があります。Oracle のインメモリは、アプリケーションとツールに対して透過的になるよう設計

されています (図 1)。

図 1: Oracle のデュアル形式アーキテクチャ

Oracle と SQL Server のインメモリ列ストアの比較

Oracle 12c のインメモリ列ストアと SQL Server のインメモリ列ストアの比較を表 3 に示します。

機能 Oracle 12c SQL Server 2014 SQL Server 2016

Page 23: SQL Server: インメモリ OLTP と列ストア機能の比較

23 ページ

列ストアの永続性 なし あり あり

集計関数プッシュダウン あり なし あり

セカンダリ レプリカへのクエリ なし なし あり

列ストアによって具体化された

ビュー

あり なし なし

インメモリ OLTP の統合 なし なし あり

バッチ処理 なし あり あり

R の統合 あり なし あり

構成および操作 構成および操作を非

常に複雑にする多く

のノブを提供

列ストア インデッ

クスの作成後に完全

に自動化

列ストア インデッ

クスの作成後に完全

に自動化

(削除済み行の管理

を含む)

表 3: インメモリ: Oracle 12c と. SQL Server の比較

• 列ストアの永続性: 一般的にデータ ウェアハウスは巨大なので、すべての項目をメモリ内に常に格納

しておくことはできません。Oracle Database を再起動した場合、列ストア インデックス内にデー

タは含まれず、バックグラウンドでインデックスが構築されます。カラムナ ストレージは、インデッ

クスが構築されるまで分析クエリで利用できません。SQL Server では列ストア インデックスが維持

されるので、インデックスを再構築する必要や、メモリ内に格納するためにメモリをプロビジョニン

グする必要はありません。SQL Server では、クエリ実行に基づいてメモリに対するデータの読み込

みと取り出しが行われます。

• 集計関数プッシュダウン: これは、データベース値の計算前の集計 (合計や平均など) をストレージ層

にプッシュダウンすることを意味します。Oracle 12c は集約関数プッシュダウンをサポートします。

SQL Server 2014 では、合計と集計は実行層のストレージ エンジンの外部で計算されます。次期リ

リースの SQL Server では、ストレージ層へのプッシュダウンが行われ、最大 4 倍以上のパフォー

マンス向上が実現します。

Page 24: SQL Server: インメモリ OLTP と列ストア機能の比較

24 ページ

• セカンダリ レプリカへのクエリ: 次期リリースの SQL Server では、セカンダリ レプリカにデータ

ウェアハウス クエリを実行できるようになります。Oracle には AlwaysOn に似た構成が含まれてい

ますが、セカンダリ レプリカへのデータ ウェアハウス クエリを実行することはできません。データ

ウェアハウス ワークロードはミッション クリティカルで、高可用性を目的に構成されるので、この

点において SQL Server は非常に優れています。

• 列ストアによって具体化されたビュー: 具体化されたビューには非常に代わった使用ケースがありま

す。具体化されたビューを OLTP テーブル上で作成し、そのビューを列ストア形式で格納した場合、

キューブのような機能を利用できます。OLTP のように常に最新の状態に維持される集計前のデータ

があります。しかし、このデータを維持するには非常に大きなコストが発生する上に、OLTP および

データ読み込みのパフォーマンスが損なわれます。

• インメモリ OLTP の統合: 現時点では、SQL Server 2014 と Oracle 12c のいずれもインメモリ

OLTP の統合はサポートしていません。しかし、SQL Server 2016 では、列ストア インデックスと

OLTP ワークロードが透過的に統合します。これは、更新可能な列ストア インデックスが OLTP ワー

クリード内の 1 つまたは複数のテーブル上に作成されることによって実現します。.列ストアは更新

可能なので、ユーザーは、テーブル上で OLTP ワークロードを実行し、同じテーブル上でクエリを実

行できます。

• バッチ モード処理: SQL Server 2014 のもう 1 つの主な利点は、クエリ パフォーマンスを大幅に向

上させるバッチ モード処理です (一般的に 3 ~ 10 倍向上)。現在、Oracle には、そのようなテクノ

ロジはありません。

IBM

IBM DB2 10.5: BLU Acceleration による分析

IBM DB2 BLU Acceleration は、IBM DB2 10.5 と統合したインメモリ コンピューティング ソリュー

ションとしてリリースされました。この製品にはいくつかの最適化がありますが、データのコピーをカ

ラムナ ストレージに格納する “シャドウ テーブル” という概念に基づいています。朗報のテーブルは自

動的に同期状態を維持します。OLTP トランザクションはリレーショナル テーブル上で直接実行されま

すが、これらのテーブル上の分析クエリは、高速な分析処理が可能な列ベースのシャドウ テーブルにリ

ダイレクトされます。

Page 25: SQL Server: インメモリ OLTP と列ストア機能の比較

25 ページ

IBM DB2 BLU Acceleration は、“セブン ビッグ アイデア” を主要な機能としてカプセル化します。

• シンプルな使用: IBM は、この機能は、有効にするとすぐに使用できると主張しています。ユーザー

が行う必要のある操作は、データとクエリを読み込むことだけです。その他のインデックスや微調整

は必要ありません。読み取り、バックアップ、および復元などの関連する操作もシンプルになってい

ます。

• 対処可能な圧縮: 最適化された圧縮メカニズムの使用に加えて、IBM は、圧縮されたデータ上で直接

操作を行うことができるとも主張しています。事実、BLU Acceleration は、最初にデータの圧縮を

解除する必要なく、結合や集計などを実行でき、圧縮されたデータに直接述語を適用できます。

• 増倍された CPU パワー: IBM は、SIMD (Single Instruction Multiple Datasets) という新しい概念

を使用して、単一の命令を複数のデータ要素に適用します。SIMD を使用することにより、多くの

ルーチンを同時に実行して、高速なクエリ実行を実現できます。

• コア フレンドリーな並列処理: IBM は、ワークロードがマルチコア マシン上で実行している場合、

すべての処理能力を活用してプロセスを並列処理すると主張しています。これは、マルチコアを活用

するためにソフトウェアがゼロから記述されたことによって実現しています。

• カラムナストレージ: データは列として最適化されているので、効率的なストレージ、高速のクエリ

パフォーマンス、シンプルになった微調整などの利点が実現します。

• スキャン フレンドリーなキャッシュ: IBM は、最適化されたメモリと OLTP およびデータ ウェアハ

ウス ワークロード用に個別に最適化されたキャッシュ管理技法を使用していると主張しています。

IBM は、スキャン フレンドリーなキャッシュを使用することによって、I/O パフォーマンスへの影

響を最小限に抑えることができると主張しています。

• データ スキップ: データ スキップでは、クエリの対象とならないデータの大きいセグメントが無視

されます。この機能によって、CPU、RAM、および I/O レベルでパフォーマンスが向上し、微調整

なしで高速のクエリが可能になります。データ スキップは、SQL Server のセグメント排除の概念と

同じメカニズムです。

IBM DB2 BLU Acceleration と SQL Server インメモリの比較

IBM DB2 BLU と SQL Server の機能の比較を表 4 に示します。

機能 DB2 BLU SQL Server 2014 SQL Server 2016

Page 26: SQL Server: インメモリ OLTP と列ストア機能の比較

26 ページ

Acceleration

“セブン ビッグ アイデア” あり あり (マイレージは異なる) あり (マイレージは異なる)

クエリ パフォーマンス あり あり (バッチ モード) あり (バッチ モード、集計

関数プッシュダウン、ルッ

クアップ/ショートレンジ

クエリ)

並列 DML なし あり あり (行レベルのロックと

ブロックなしの読み取りに

よる同時実行の向上)

自動インデックス

メンテナンス

あり なし あり

運用分析 あり (シャドウ

テーブルを使用)

なし (CCI への手動移動

によって実現可能)

あり (完全に統合)

表 4: インメモリ: IBM DB2 BLU Acceleration と SQL Server の比較

• “セブン ビッグ アイデア”: IBM DB2 BLU Acceleration は、“セブン ビッグ アイデア” を軸として構

築されています。これには、列ストア テーブル、データ圧縮、ハードウェア レベルの処理に関連す

る最適化、メモリおよびキャッシュ管理などの概念とテクノロジが含まれます。マイクロソフトも同

じ概念とテクノロジを使用しますが、実装のレベルが異なります。次期バージョンの SQL Server に

も同じアイデアが実装されています。

• クエリ パフォーマンス: IBM DB2 BLU Acceleration には、分析のクエリ パフォーマンスを向上さ

せるメカニズムが実装されています。マイクロソフトでも、パフォーマンスを向上させるバッチ モー

ドどいう特別なモードとして同様のメカニズムが実装されています。DB2 にはバッチ モードはあり

ません。次期バージョンの SQL Server では、バッチ モード実行はより多くの演算子で使用できま

す。たとえば、SQL Server 2014 では ORDER BY クエリをバッチ モードで実行することはできま

せんが、次期バージョンでは可能になります。マイクロソフトではバッチ モードに多くの投資を行っ

ているので、より多くのデータ ウェアハウス クエリが今よりも高速になると予測されます。

Page 27: SQL Server: インメモリ OLTP と列ストア機能の比較

27 ページ

• 並列 DML: ブロックに関連する問題が原因で、IBM DB2 BLU Acceleration ワークロードは並列

DML と適切に動作しません。SQL Server 2014 では利用できませんが、次期バージョンの SQL

Server には、行レベルのブロックにおいて列ストア上で並列 DML の実行が実装されます。この実装

により DML 操作の点において同時実行性が向上します。

• 自動インデックス メンテナンス: IBM DB2 BLU Acceleration では、自動インデックス メンテナン

スが可能です。一般的に、データを削除すると、対応する行はクラスター化された列ストア インデッ

クスから直ちに削除されません。これらの行は、削除する行を指定する削除ラベルまたはフラグで

マークされます。多くの行が削除された後でも、これらの行は列ストア内の容量を占領します。これ

らの削除済み行は、一定期間の後にインデックスを再構築することによって削除できます。DB2 に

は、削除済みの行をインデックスから自動的に削除する自動インデックス メンテナンス機能がありま

す。この機能は SQL Server 2014 では使用できませんが、次期バージョンの SQL Server では利用

可能になります。

• 運用分析: DB2 は、既存のリレーショナル テーブルに基づいて列ストア テーブルを新規作成する

シャドウ テーブルの概念を使用します。アプリケーションの観点から、ユーザーには OLTP テーブ

ルとそれにリンクされたシャドウ テーブルが提供されます。ユーザーは OLTP テーブル上でワーク

ロードを実行することができ、分析クエリは自動的にシャドウ テーブルにリダイレクトされます。

SQL Server 2014 では、このような処理は手動で行う必要があります、次期バージョンの SQL

Server では、ユーザーは、非クラスター化列インデックスを作成できます。このインデックスを使

用して OLTP と分析を同じテーブルで実行できます。この場合、シャドウ テーブルはありませんが、

更新可能なインデックスが使用されます。

虚像と現実:SQL Server のインメモリ OLTP とインメモリ

ラッチなしのアーキテクチャ

虚像: SQL Server のインメモリ OLTP にはロックやラッチがないので、不一貫性およびデータ破損が発

生することがある。

現実: SQL Server のインメモリ OLTP には完全な ACID サポートがあり、データの原子性 (Atomicity)、

一貫性 (Consistency)、分離 (Isolation)、および永続性 (Durability) が保証されます。インメモリのオ

Page 28: SQL Server: インメモリ OLTP と列ストア機能の比較

28 ページ

プティミスティック同時実行制御を使用する革新的なロックなしアーキテクチャでは、ロックを解除す

る必要性を排除し (ロック マネージャーなし)、ブロックを取り除くことによって干渉のないスケールを

可能にすることによってパフォーマンスが向上します。インデックスと行バージョンの間のリンクが破

損することを防止するために、SQL Server は、システム内のすべてのプロセッサにわたって操作が原子

的であることを保証する ATS (Atomic Test/Set) 命令を使用します。

トランザクション ロックによって SQL Server 内のデータの永続性が保証されます。メモリ最適化テー

ブルの永続性を保証するために、トランザクションは、そのログがディスクにフラッシュされた後にの

みコミット済みとマークされます。メモリ最適化テーブルのロックは非常に効率的で、生成されるログ

データの量は最小限です。

分離データベース エンジン

虚像: SQL のインメモリ OLTP は個別の製品なので、データベースの再設計または再構築が必要である。

現実: 現在入手可能なその他の主なインメモリ データベース製品とは異なり、インメモリ OLTP は

SQL Server に完全に統合されています。したがって、別途インストールする必要はなく、別のツール

の使用方法を学習する必要もありません。また、増分投資の戦略もサポートされるので、選択したテー

ブルをデータ (テーブルによって表されます) に最も適切なストレージに移動できます。インメモリ

OLTP はコア SQL Server に組み込まれているので、その他の SQL Server 機能も活用できます。

SQL Server は、OLTP 用に最適化された統合インメモリ ソリューションを装備した唯一のメインスト

リーム DBMS です。Oracle TimesTen は個別の製品であり、SAP HANA は分析に最適化されています。

OLTP への適性

虚像: SQL Server 2014 の列ストアは OLTP に適していない。

現実: SQL Server 2014 のクラスター化列ストアは、OLTP ではなくデータ ウェアハウス テクノロジと

して位置付けられています。SQL Server 2014 は、クラスター化および非クラスター化列ストア イン

デックスのオプションを追加します。クラスター化列ストア インデックスでは、データの変更および一

括読み込み操作が可能です。SQL Server の将来のリリースでは、メモリ最適化テーブルおよびディスク

ベースのテーブルの両方で運用ワークロードのリアルタイム分析に更新可能な非クラスター化列ストア

を使用できるようになります。

Page 29: SQL Server: インメモリ OLTP と列ストア機能の比較

29 ページ

競合企業のインメモリ製品への対応

虚像: インメモリ OLTP は競合企業のインメモリ製品に対抗するために設計された。

現実: コード名 “Hekaton” というプロジェクトは、ビジネスおよびハードウェアのトレンドに対応する

ために 5 年前に開始されました。マイクロソフトは、Microsoft Research とのパートナーシップでイ

ンキュベーション プロジェクトを開始し、今日のハードウェアの現実に合わせてデータベース エンジン

をゼロから設計し直しました。インメモリ OLTP 機能は、このインキュベーションの成果です。

古い SQL 機能 DBCC PINTABLE と同等のインメモリ OLTP

虚像: インメモリ OLTP は、メモリ内でのバッファ プール ページやテーブルのピン留めを可能にする古

い SQL 7.0 の機能である DBCC PINTABLE と同じである。

現実: インメモリ OLTP は、ゼロから構築されたまったく新しい設計を使用して、効率的なデータ操作

のための最適化を行います。メモリ最適化テーブル内のデータはページで整理されず、バッファ プール

も使用しません。ディスクとメモリの間のデータのサブセットのページングを効率化することを目的と

したデータ構造とその他のインフラストラクチャによる設計の OLTP は、データ エンジンの本質的な特

性を維持したまま、非常に効率的なデータ エンジンを実現します。

結論

メモリ コストの低下、マルチコア プロセッサ、CPU クロック速度の向上などのハードウェア トレンド

により、インメモリ コンピューティングのアーキテクチャ設計が促進されました。インメモリ コン

ピューティングは、テクノロジ業界で最も急速に成長しているトレンドの 1 つです。マイクロソフト、

SAP、IBM、および Oracle を始めとするほとんどのテクノロジ ベンダーは、クエリ パフォーマンスを

向上させるインメモリ ソリューションを提供しています。

SQL Server 2014 に組み込まれたマイクロソフトのインメモリ処理機能は、ビジネスを加速する新しい

トランザクション シナリオを実現する画期的なパフォーマンスを提供します。マイクロソフトは、

OLTP、データ ウェアハウス、および分析を対象とした包括的なインメモリ テクノロジを SQL Server

に直接組み込んで提供しています。SQL Server 2016 でも、機能とパフォーマンスが大きく向上させる

インメモリ テクノロジの強化が継続されます。

Page 30: SQL Server: インメモリ OLTP と列ストア機能の比較

30 ページ

マイクロソフトのインメモリ OLTP ソリューションは、単にトランザクションを加速するだけでなく同

時実行も向上させるので、データベース全体をメモリに読み込む必要なく、真のスケール アップを実現

することができます。同様に、そのデータ ウェアハウス用のインメモリ列ストア ソリューションもクエ

リの処理速度を向上させ、高いデータ圧縮でストレージ コストを大幅に削減します。

唯一 OLTP に最適化された組み込みのインメモリ テクノロジを装備しているのは SQL Server だけで

す。その結果、高速なトランザクションが実現しています。加えて、強化されたインメモリ列ストアに

よって、総保有コストを最小限に抑えながら、クエリの処理速度を向上させ、洞察をすばやく取得する

ことが可能になります。たとえば、SQL Server のインメモリ テクノロジを使用した大手ゲーミング企

業の bwin.party は、パフォーマンスを 17 倍向上させることに成功しました。同社のクエリ処理速度

は 340 倍も向上しました。

SQL Server のインメモリ設計では、ロックとラッチのないテーブル アーキテクチャによってデータ

ベースの制限が取り除かれ、100% のデータの永続性が維持されます。このような機能は、Oracle、

IBM、または SAP HANA のいずれでも提供されていません。SQL Server では、すべてのコンピュー

ティング リソースを多くの同時実行ユーザー向けに活用することができます。その他の製品とは異なり、

SQL Server は組み込みのインメモリ機能を提供するので、新しい開発ツールや API を学習する必要は

ありません。最後に、Oracle や IBM のようにインメモリ OLTP 機能を使用するための追加コストは発

生しません。

主なリソース

詳細については、以下を参照してください。

Microsoft SQL Server 2016

http://www.microsoft.com/ja-jp/server-cloud/products/sql-server-2016/

Microsoft SQL Server のインメモリ

www.microsoft.com/en-us/server-cloud/solutions/in-memory.aspx (英語)

インメモリ OLTP に関するドキュメント

https://technet.microsoft.com/ja-jp/library/dn133186(v=sql.120).aspx

Page 31: SQL Server: インメモリ OLTP と列ストア機能の比較

31 ページ

Windows Server 2014 のダウンロードおよび評価

https://www.microsoft.com/ja-jp/server-cloud/products-SQL-Server-2014.aspx

フィードバック

このホワイト ペーパーはお役に立ちましたか。1 (まったく役に立たなかった) ~ 5 (非常に役に立った)

の数字でお答えください。このホワイト ペーパーをどのように評価しますか。また、なぜそのように評

価しましたか。

• 高い評価は、適切な例、良好なスクリーン ショット、明確な説明、または別の理由によるものですか。

• 低い評価は、不適切な例、不鮮明なスクリーン ショット、または不明確な説明によるものですか。

このフィードバックは、リリースされるホワイト ペーパーの品質改善に役立ちます。

フィードバックは [email protected] までお送りください。