Comments
Transcript
超並列−DB2 UDBの可能性 （DB2 UDB EEE: エンタープライズ拡張エディション) 目次
超並列−DB2 UDBの可能性 （DB2 UDB EEE: エンタープライズ拡張エディション) ２００１年５月２２日 日本アイ・ビー・エム株式会社 ソフトウェア事業部 データマネジメント事業推進 中坪 宏明 目次 DB2 UDB EEE のしくみ DB2 UDB EE の基本動作 DB2 UDB EEE の基本動作 並列処理 データ分割・配置 SQL処理 ＤＳＳシステムでの処理 ＯＬＴＰシステムでの処理 高可用性 サポート・プラットフォーム ベンチマーク・データ まとめ Copyright IBM Co. 2001 IBM Software 1-2 DB2 UDB EEEのしくみ 解説: DB2 UDB EEEのしくみ 当セミナーは、DB2 UDBの並列データベースである、DB2 UDB EEE(DB2 UDB エンタープライズ拡張エディション) の基本的な機能説明と、パフォーマンスデータ等から適用可能領域およびシステム規模の感覚を理解していただ くことを目的としています。 資料内には、DB2 UDB EEEを使用したことがなく、並列DB設計をしたことがない方でも理解できるように、基本的 なポイントを含めています。 Copyright IBM Co. 2000 IBM Software 3-4 DB2 UDBの基本動作 − 区画内並列処理 (1/2) 区画内並列処理（SMP並列処理） １ＳＱＬ処理を1区画(ノード/Quad)内で並列に実行 DB2 UDBの全製品で実装 SMP(Symmetrical Multiple Processors)パラレル DB2 コーディネーター エージェント SELECT * FROM T1 並列SQL処 理 DB2 サブエージェント バッファープール DB2 ディスク プリフェッチャー／ クリーナー 並列Ｉ／Ｏ Copyright IBM Co. 2001 IBM Software 解説: DB2 UDBの基本動作 − 区画内並列処理 (1/2) まず最初に、並列DBの説明をする前に、通常の一台のUNIXあるいはPCのマシンで、CPUが1個ないしは2、4、8個 のマシンで、DB2が動くときの基本的な仕組みについて説明します。 この図は、実際にDB2 UDBが稼動している際のプログラム(プロセス)、メモリー、ディスク等を表しています。 ユーザーが接続すると、DB2コーディネーター・エージェントというプロセスがあがります。そして、後続のSQLを処 理することを目的として存在し続けます。 この例では、ユーザーからSELECT * FROM T1というSQLが発行された場合のDB2の動きについて説明します。 まず、SQLが発行されると、DB2 UDBはいわゆるオプティマイズ（最適化）の処理をして、どう実行するかを考えま す。それが、決まりますと、下に書いてあるサブ・エージェントと呼ばれる（この図では、4つのエージェントがありま す）4つのプロセスが自動的にあがり(4という数も自動的に判断されます）、4並列でそのSQLを処理しようとします。 一般的にDB2 UDBに限らずRDBでは、通常IOを司るプログラム(プロセス)サーバーというのは別にあります。 サブエージョント、あるいはコーディネーター・エージェントが直接IOを行う場合もありますが、一般的にはディスク に対してIOサーバーがおり、RDBが持っているIOのキャッシュ（DB2ではバッファープール)を介して一見非同期に IOしているように見えます。 この例では、4つ並列にあがって4人で分担して処理しようと思うのですが、実際にはリクエストがIOサーバーにあ がり、ディスクが6個なので、ディスクにIOを行うプロセスが6個あがり、6並列でディスクIOを行ないます。 IOの結果はどんどんIOのキャッシュ(バッファープール)に溜まって行き、溜まったデータを4人で分けて処理をしま す。それぞれの結果を、またコーディネーター・エージェントが束ねて結果を返します。 以上のような処理の流れになります。 Copyright IBM Co. 2000 IBM Software 5-6 DB2 UDBの基本動作 − 区画内並列処理 (2/2) オプティマイザーが区画内並列(SMP並列)処理を効果的に活用 SQL処理の並列度はオプティマイザーが自動的に設定 そのためSMPパラレル処理を意識した運用、コーディングは不要 CPU追加による処理時間短縮が極めて容易に実現可能 LOADなどのユーティリティもSMP並列処理 プログラム SMPパラレルは意味が 無いから止めよう！ このSQLは並列度4で 実行させよう！ SELECT ＊ FROM ．．． オプティマイザー オプティマイザー 複数CPUマシン (4CPUモデル） 単一CPUマシン ☆ オプティマイザーがSQL の内容に応じて並列度を選 択します。 Copyright IBM Co. 2001 IBM Software 解説: DB2 UDBの基本動作 − 区画内並列処理 (2/2) ここで、DB2 UDBならではのポイントが2つあります。 一つは、この4という数字が、論理設計/物理設計に全く関係なく、動的にわかれることができる、しかもオプティマ イザーが最適だと思う数にしてくれる点です。 もう一つは、このCPU並列処理の4という数に対してIO処理の6という数ですが、IOの並列は、完全にCPUの4つの 並列とは独立して行われます。IO並列が完全に独立、かつCPU並列も完全に独立して行われることが、DB2 UDB の特長です。 4CPUのようなSMPマシンで1つのSQLを並列に処理する仕組みを使う時に、パーティショニング・オプションといっ た特別なものは一切必要ではありません。並列処理をすることを意識する必要もなく普通に論理設計・物理設計を して動かすと、自動的に並列処理が行われます。 言い換えると、動的に4つにパーティショニングしているというのが、DB2 UDBエンタープライズ・エディションおよび ワークグループ･エディションの特長です。 CPUの並列処理はいくつがよいかといった事はオプティマイザーが最適なものを選んでくれます。 例えば顧客番号を指定して、インデックスを使って1件だけ持ってくるような場合は、わざわざ4つに分割するとむし ろ遅いので、分けずに1つだけで処理をします。あるいは、前述の例のように、ある程度表スキャンが発生するよう な場合には、複数（４つ）に処理分割したほうがよいであろうという場合は、4並列処理を行ないます。 この例ではSELECTでSQLの処理ですが、例えばデータのロードをするユーティリティーに関しても、オプティマイズ の処理が働いて自動的に4並列又は3並列等で動きます。 ここで重要なことは、区画内並列処理が行われる時に、論理設計/物理設計が関係ないというところが大きなポイ ントです。 Copyright IBM Co. 2000 IBM Software 7-8 DB2 UDBの基本動作 − ディスク関連 (1/2) 効率のよい並列I/O処理で最適な区画内並列(SMP並列)処理を実現 SQL処理自体のプログラミング・モデルがうまくできていても、並列 I/O を効率よく行い 処理データを適切に処理プログラムに渡さなければ意味がない。両者がうまくいって、初 めて、全体としてSMP並列処理性能が向上する。 DB2 UDBによるストライピング 非同期データ読み込み ラウンド・ロビン方式でコンテナーを均等に使 用し、コンテナーごとに並列にＩ／Ｏを行う 複数のI/O用プロセスが非同期に入出力 バッファープール I/O プロセス コンテナー1 エクステント DEPT表 I/O プロセス コンテナー２ I/O プロセス コンテナー３ ページ: 1ページのサイズは 4KB、8KB、16K、32K のいずれか エクステント: PROJECT DEPT DEPT EMPLOYEE EMPLOYEE EMPLOYEE DEPT 表スペース ページの集まり、デフォルト32ページ、表ス ペース単位で設定 コンテナー: 表スペースを構成する単位、表スペースの タイプによって、ディレクトリー、ファイル、デ バイスとなる Copyright IBM Co. 2001 IBM Software 解説: DB2 UDBの基本動作 − ディスク関連 (1/2) 並列処理を実現している裏の仕組みとしてディスクのデータ格納の仕組みを説明します。 この例では、表スペースが3つの物理ディスクからなっていて、そこに表のデータを格納する時に、DB2は 格納の方法としてエクステントと呼ばれる単位毎に、一個ずつラウンドロビンでデータを書いて行きます。 IOサーバーはこの表を3並列で読みますが、一度に読むとIOサーバーは１，２，３と読めます。次に４，５，６と読ん でいきます。つまり、3並列で読んでいるのですが、結果的にはシーケンシャルに頭から読んでいることと同じ効果 が得られます。 一般的に並列処理が難しいのは、バラバラに読んでしまうと、後でデータの並び順をどう整えようかという点です が、DB2 UDBは最初から3パラ４パラ5パラでどのように読んでも、きちんと頭からシーケンシャルに読んでいること になります。 このようなデータの格納方式をDB2 UDBがとっているのが実は裏に隠れたポイントです。 これは、いわゆるストライピングと呼ばれるデータ格納方法です。ストライピングはOSやあるいはハードウェアでス トライピングすることができるのですが、何故DB2自身が行っているかという説明は、次のページです。 Copyright IBM Co. 2000 IBM Software 9-10 DB2 UDBの基本動作 − ディスク関連 (2/2) ディスク追加時にも簡単に並列I/O処理の利点を享受できる ディスク(コンテナー)追加すると、表スペースのデータ量を自動的に再調整（自 動再配置） 再調整中も表スペースへのアクセス可能です 自動再配置機能がないと．．． ストライピングを外部ストレージ・システムに任せる場合、通常は、そのディスク・アレ イを再構成する必要があるため、オンラインでディスク追加はできない。さらには、その アレイ上のデータをバックアップ/リストアする必要がある。 ディスク・アレイを再構成せずにテーブルスペースを拡張する場合(コンテナーの追加)、RDBMS自体にスト アクセス ライピング機能および自動再配置機能がないとディスク追加後、効率的なディスク・アクセスができな アクセス アクセス アクセス アクセス い。 並列Ｉ／Ｏ 並列Ｉ／Ｏ コンテナー追加 (ALTER TABLESPACE) コンテナー コンテナー コンテナー コンテナー コンテナー コンテナー ＋ 表スペース 表スペース Copyright IBM Co. 2001 IBM Software 解説: DB2 UDBの基本動作 − ディスク関連 (2/2) ディスクが一杯になってくるとディスクの追加を行います。 OSやハードウェアのストライピングを利用している場合では、通常はバックアップをとり、ストライピングを構成し直 して、またリストアするという作業が必要になります。 ところが、DB2 UDBの場合には、自分でストライピングしているため、一杯になってきて追加のディスクを足すとき は、そのテーブルスペースの構成を変えるDDLを流します。(ALTER TABLESPACE ADD <この入れ物>) そうすると、このコマンド自体は一瞬で終了し、バックグラウンドで、あたかも最初から3つのディスクを使ってデータ を格納していたかのように、データを再配置します。 再配置が終ると、きれいに3並列で読めるようになります。 つまり、2並列で読んでいて、ディスクを追加すると、往々にして他社のRDBではIOが遅くなりますが、DB2 UDBの 場合は、最初から3並列であったかのようにきれいに読んでくれます。 このようなディスクの追加がオンラインでできるということが1つの大きなポイントです。 24時間稼動でピーク時にディスクの追加は避けて欲しいのですが、空いている時間や緊急時にオンラインでディス ク追加等の作業を可能にするため、DB2 UDB自身でストライピングを行っています。 Copyright IBM Co. 2000 IBM Software 11-12 DB2 UDBの基本動作 − メモリー関連 (1/1) バッファープール（I/O Cache) DB2 UDBでは、DB2自身で管理しているI/O Cacheメモリーをバッファープールと 呼ぶ。 バッファープールは、テーブルスペースと関連づけて複数定義できる（１：Ｎの 関係） これにより、表および表アクセスの特徴に応じて効果的な I/O Cache処理を実現できる。 例： バッファープール 一般表用 一般表 特殊要件はないので、通常のDB2 のメモリー管理に任せてよい。 バッファープール マスター表用 マスター表 バッファープール 大規模表 データ用 バッファープール 大規模表 インデックス用 大規模表 データ 頻繁にアクセスするので メモリーに常駐させたい 大規模表 インデックス データは大容量なのでメモリー消費を 制限したい。しかしインデックスは頻繁 に使うのでメモリーに常駐させたい。 Copyright IBM Co. 2001 IBM Software 解説: DB2 UDBの基本動作 − メモリー関連 (1/1) CPUの並列、ディスクへのデータ格納の説明をしてきましたので、基本的な動作として最後にメモリー、特にIO キャッシュ、バッファープールについて簡単にご説明します。 DB2はバッファープールをテーブルスペース毎に独立して定義することが可能です。(独立して定義してもいいです し、何も指定しないとデフォルトの1つのバッファープールが使用されます。） 従って、IO特性の違うものを、テーブルスペースを分けてキャッシュヒット率を上げられるようにキャッシュもグルー プ化することが可能です。 この例では、マスター表は比較的小さくてよくアクセスされるので、表スペースをわけ、専用のキャッシュもわけて、 常にメモリーに置きます。 大規模な表の場合は、その表に対してのキャッシュ･ヒットがまず期待できないので、そのような場合には、表を読 む部分に関しては表スキャンが問題なく動く程度の小さなキャッシュにします。 また、大規模表でもインデックスは常にメモリーに置いておきたいのであれば、インデックスだけは表スペースをわ けて専用のキャッシュを設け、その他の表は１個でまとめておくとか、といったような管理ができます。 ここまでが、DB2 UDBエンタープライズ・エディション、単体のUNIXマシンあるいはPCで動く、基本的な並列処理の 仕組みのご説明でした。 Copyright IBM Co. 2000 IBM Software 13-14 DB2 UDB EEEの基本動作 − 区画間並列処理 (1/3) 区画間並列処理(MPP並列処理） データベースを複数の区画から構成し、区画間で並列処理を行う ユーザーからはあくまでもシングル表(データベース）イメージ オプティマイザーが１つのＳＱＬを区画（ノード）間でパラレルに実行 DB2 UDBエンタープライズ拡張エディション（EEE)で実装 SELECT COUNT (*) FROM '社員表’ WHERE name='山田' SQL SQL SQL SQL コーディネーター・ノード SQLを全ノード へ配布 結果をコーディネーター ノードへ返す 区画（ノード） SQLの処理 SQLの処理 SQLの処理 結果をコーディネーター ノードへ返す 全ノードの結果を集 計 区画（ノード） 区画（ノード） アンサーセット SQLの処理 結果をコーディネーター ノードへ返す 区画（ノード） アンサーセット アンサーセット ディスク1 ディスク ディスク1 ディスク ディスク1 ディスク ディスク1 ディスク Copyright IBM Co. 2001 IBM Software 解説: DB2 UDB EEEの基本動作 − 区画間並列処理 (1/3) このページより、並列データベース、DB2 EEEの並列処理に関してご説明します。 まず、並列処理を行うためのハードウェアは、一つ一つがUNIXマシン、あるいは、PCになります。 この例では、4台のUNIXサーバーあるいは4台のPCサーバーという構成です。 それぞれのマシンは通常ギガビット・イーサネット以上の性能を持った高速なネットワークで結ばれています。 RDBとしては全体で一つのシステム、DBではインスタンスといいますが、全体で1つのインスタンスになっていま す。物理的には4台あるが、使用者からみるとどこに接続しても同じ処理になり、データは常に同じ結果になりま す。 この例では、2番目のノードにクライアントが接続しています。 SQL処理の前にまず接続すると、コーディネーター・エージェントと呼ばれるものがこのノード上に上がります。 そして、後続のSQL処理を行ないますが、SQLを発行すると、DB2 UDB EEでの動きと同様に、そのSQLをどう処理 したらよいかというオプティマイズの処理をします。 この例では、名前｢山田｣さんが社員表に何人いるか数えなさい、という処理をします。 社員表が全部のノードにまたがっているとすると全部のノードに山田さんは何人ですかと照会します。逆に全部の ノードに照会しないと意味はありません。それぞれのノードで数え上げて、結果が2番目のノードに返ってきて最後 に合計します。そして、結果が返るといった処理が、並列DBの非常に基本的な処理です。 クライアントから見ると、ネットワークはTCP/IPですので、IPアドレスは全ノード違います。 従って、クライアントから見れば、IPアドレスが違う受け口が違うサーバーが4つ存在しているように見えるのです が、どこに接続してもSQLの結果は同一のものが返ってきます。 Copyright IBM Co. 2000 IBM Software 15-16 DB2 UDB EEEの基本動作 − 区画間並列処理 (2/3) 区画と物理的なマシン形態との関係 区画はマシン内に複数作成可能。 区画を論理ノードとも呼ぶ 全体で 区画間の 並列処理 各区画(ノード）でSMP並列処理が行われる クラスター構成 SMPマシン 内で区画内 と共用メモ リー経由で の区画間の 並列処理 大規模SMPマシン 通信機能 各マシン 内で区画 UNIX マシン/ PC 内の並列 処理 (EE ﾃﾞｰﾀﾍﾞｰｽ区画1 と同等) プロセッサ プロセッサ 通信機能(共用メモリー) UNIX マシン/ PC ﾃﾞｰﾀﾍﾞｰｽ区画2 UNIX マシン/ PC ﾃﾞｰﾀﾍﾞｰｽ区画N プロセッサ プロセッサ プロセッサ プロセッサ プロセッサ プロセッサ プロセッサ プロセッサ メモリ メモリ メモリ ディスク ディスク ディスク ディスク ディスク ディスク ディスク ディスク ディスク プロセッサ プロセッサ ﾃﾞｰﾀﾍﾞｰｽ区画1 ﾃﾞｰﾀﾍﾞｰｽ区画2 プロセッサ プロセッサ プロセッサ プロセッサ プロセッサ プロセッサ プロセッサ プロセッサ メモリ メモリ ディスク ディスク ディスク ディスク ディスク ディスク Copyright IBM Co. 2001 IBM Software 解説: DB2 UDB EEEの基本動作 − 区画間並列処理 (2/3) 並列DBの世界では、構成しているマシンをノードといいます。一つ一つのマシンは独立していますが、全体のシス テムから見て、一つのマシンを1つのノードという呼び方をします。 あるノードで、山田さんが何人いるかという処理があると、同じSQLが別のノードでも処理されます。各ノードでの SQLの処理は、DB2 UDBエンタープライズ・エディションでの区画内並列処理になります。 各ノード上で、DB2 UDBエンタープライズ・エディションでの区画内並列処理をして、さらに、マシン間で並列処理を 行うのが、DB2 UDBの並列DBの仕組みになります。 左図は、複数のUNIXマシンまたはPCでクラスター構成され全体で並列マシンになっています。各マシンは複数 CPUがあり、SQLを処理する時には、区画内並列処理を行ないます。さらに、各ノード間で高速なネットワークを介 して通信を行い、結果をまとめて返すといった処理を行ないます。 右図は、数十CPUあるマシンの場合の構成です。区画内並列処理は、数十までCPU数が増えてくると並列処理し た際の処理性能効率が落ちてきますので、内部的に区画をわけたほうが性能が出るケースがあります。 例えば、8CPU や12CPUの場合、4CPUや6CPUあたりに1つの区画（区画というのは、DB2エンタープライズ・エディ ション1個相当）にわけて処理をします。この場合は一つの筐体なので、左図と違って、ネットワーク経由も可能です が、Shared Memory経由(TCPIPではなく）の高速通信を使って、処理をするといった形態も可能です。 Copyright IBM Co. 2000 IBM Software 17-18 DB2 UDB EEEの基本動作 − 区画間並列処理 (3/3) ノード ノード Locks Locks ノード ノード Locks シェアード･ナッシング(Shared Nothing) ユーザーからはシングルデータベースイメージだが、ディス クは非共有。 スケーラビリティを制限する共有リソースが少ない MPPハードウェア・アーキテクチャーとより良く適合 １社を除くすべてのRDBMSベンダーでの採用方式 DB2 ＵＤＢ ＥＥＥの機能と適合 DBMSとしてはディスク非共有だが、OSレベルでのディスク 共有が可能 Locks シングル･データベース･イメージ データC ノード データB ノード データＡ データD ノード シェアード･ディスク(Shared Disk) ノード 整合性維持のために分散ロック・マネージャが必要 共有リソースがスケーラビリティを制限するようなボト ルネックとなっている。そのため、同期コストを最小 限に抑えるようなアプリケーション設計が必要にな ることが多い。 Distributed Lock Manager(分散ロック管理) ストレージ管理製品によるディスク共有 シングル･データベース･イメージ データC データB データD ストレージ管理製品 データＡ Copyright IBM Co. 2001 IBM Software 解説: DB2 UDB EEEの基本動作 − 区画間並列処理 (3/3) 次に、区画間並列処理を行うアーキテクチャーに関する説明をします。 DB2 UDB EEEは、ハードウェアとしてはマシンを連ねていわゆるシェアード・ナッシング(クラスター・システム、 MPP、超並列と言われることもあります）のアーキテクチャーを使用しています。 すなわち各機械は、メモリーやCPU、IOのバス等はすべて独立しています。その間を高速なネットワークでつない だアーキテクチャーになっています。シェアするものがほとんどないので（ネットワークのところはシェアしますが）、 シェアード・ナッシングと読んでいます。 (弊社のメインフレームで並列DBを実現するSYSPLEX等はこのような構成にはなっていません。ハードウェア・OS としてシェアする仕組みを提供しています。）ところが、UNIXやPCは、既存のハードウェアを複数連ねてコストパ フォーマンスを上げるという発想になっていますので、シェアード･ナッシングのアーキテクチャーです。DB2 UDBの 並列データベースも同様にシェアード・ナッシングの考え方で、RDBの持っている様々なリソースをシェアしません。 つまり、IOのキャッシュはシェアード・ディスクでも現在はシェアできないのですが、それ以外にロック情報、あるい はトランザクション・ログなど全てシェアしないようになっています。ほとんどのSQL処理が、各ノード(単体マシン）の 中で完結しますので、1台で処理していたものを2台にすれば、ほぼ2倍になります。4台にすれば、ほぼ4倍になり ます。スケーラビリティーが簡単に得やすいような形になっています。(考慮点は後で述べます。） 一方シェアード・ディスクのほうは、ディスクをシェアしている関係上、ロック情報をシェアしたり、いくつかのRDBのリ ソースをシェアしなければなりません。シェアするということは、CPU、メモリーは実際には独立していますので、 ノード間の通信をしながらうまく連携して動くということになります。 どのノードからでも全てのデータが参照できるので一見設計は楽ですが、実際はノード間通信がかなり必要になる ため、スケーラビリティーが一般的に得がたいと言われています。 シェアード・ナッシングの場合は、シェアするものがほとんどないので、スケーラビリティーが得やすいということにな ります。 Copyright IBM Co. 2000 IBM Software 19-20 DB2 UDB EE/EEE 並列処理まとめ MPP SMP Query, Load, Utilities CPU CPU CPU CPU CPU CPU データベース 区画 データベース 区画 区画内並列処理 Query, Load, Utilities データベース 区画 区画間並列処理 SMP / MPP Query, Load, Utilities Copyright IBM Co. 2001 CPU CPU CPU CPU CPU CPU CPU CPU 区画内・区画間 並列処理 データベース 区画 データベース 区画 IBM Software 解説: DB2 UDB EE/EEE 並列処理まとめ 今までのご説明を簡単にまとめます。 まず、SMPの区画内並列処理です。コーディネーター・エージェントで、SQLが来たら動的にいつくかにわけて処理 をします。この区画内並列処理はDB2エンタープライズ・エディションでできます。 次に区画間並列処理、ノード間での並列処理というものがあります。 コーディネーター・エージェントはどこかの ノードに存在しますが、そこにSQLを発行すると、後は必要なノードにSQLを転送して、ノード毎に別々に処理をしま す。 実際にはDB2 UDB EEEの場合、区画1つ1つがこのエンタープライズ・エディションの区画内並列処理をしますの で、区画内･区画間並列処理を行ないます。 1つのSQLをハードウェアのリソースを大量に使って高速に処理するという処理には非常に向いています。 特にSQL処理として全表スキャンをするようないわゆる情報系の処理においては他社DBと比較しても相当に性能 が出るしかけになっています。 Copyright IBM Co. 2000 IBM Software 21-22 DB2 UDB EEEでのデータ分割・配置 ： ハッシュ・パーティショニング 実環境に即したデータの均等分割が可能 IBM独自のハッシング関数に基づくデータ分割 DB2のユーティリ ティーでユー ザー・データを分 析して、データが できるだけ均等 に分割されるよう な区分化マップ を生成すること ができる 実データに即する区分化マップ(パーティション･マップ)を生成可能 全体のノード数は任意 分割するノード数も任意 会員番号 氏名 居住地 Toronto Jim Stittle 123-456-789 この区分キーのハッシュ値は 8 区分化マップ (Partition Map) Vector Position 0 1 2 3 4 5 6 7 8 9 10 11 12 13 ... Node Assignment 1 2 3 1 2 3 1 2 3 1 2 3 1 2 ... DB2 DB2 ノードグループA DB2 DB2 ノードグループB Copyright IBM Co. 2001 IBM Software 解説: DB2 UDB EEEでのデータ分割・配置 ： ハッシュ・パーティショニング 次に、データをどうわけて置くかという説明をします。 DB2 UDB EEEでは、データの分割方式として、ハッシュ・パーティショニング方式を使っています。 具体的な例を見てみましょう。ある表が会員番号と氏名、居住地という3つのカラムからなっていて、会員番号の値 によってデータを分けることにします。内部的な動きとしては、会員番号に対してDB2が持っているハッシュ関数に 従って計算します。この例のデータの場合には8になりました。ここに区分化マップが用意されており、8に対しては ノード3を割り当てます。この計算をするハッシュ関数はDB2 UDB EEEが自分で用意しています。公開されておら ず、変更することもできません。 区分化マップに関しては、変更することができます。デフォルトではノード番号が繰り返し並びます。 DB2 UDB EEEのユーティリティーには、実データを読み込んでデータ分布を分析し、最も均等になるようにマップを 作成するユーティリティーがあります。従って、データ分布が固定的な場合は、そのユーティリティーを使ってマップ を作成することが可能です。これで作成した新しいマップを使ってデータを配置することを考えてみましょう。 Copyright IBM Co. 2000 IBM Software 23-24 DB2 UDB/EEEのＳＱＬ処理 (1/2) T1 理想的なノード別処理に分割 され並列処理を実現。 ノード間の通信は必要最低限 に抑えている。 DB2 UDB/EEE データアクセス要求 必要に応じて区画内並列処理 ﾉｰﾄﾞ1 ﾉｰﾄﾞ2 ﾉｰﾄﾞ3 ﾉｰﾄﾞ4 コーディネーター･ エージェント パラレル･ エージェント バッファープール パラレル･ エージェント パラレル･ エージェント パラレル･ エージェント バッファープール バッファープール バッファープール ロック情報 ロック情報 ロック情報 ロック情報 *ﾛｯｸ、ﾃﾞｰﾀﾊﾞｯﾌｧｰはノード単位に 独立。 1. SQLの処理のリクエストを受けたコーディ ネータ・エージェントがSQLを全ノードに配 布。 2. 各ノードにて、パラレル・エージェントがSQL 処理をノード内でローカル処理。 3. 結果をコーディネータ・エージェントの方へ 返す。 4. コーディネータ・エージェントにて必要に応 じて最終の集約処理（ソート・計算)を行い、 結果をクライアントに返す。 Copyright IBM Co. 2001 IBM Software 解説: DB2 UDB/EEEのＳＱＬ処理 (1/2) ハッシュ・パーティショニングを頭において、もう一度SQL処理を確認してみましょう。 例えば｢山田｣さんが何人いるかというSQL処理で、パーティショング・キーとして会員番号のようなものを使用して いるとします。 このようなSQLの場合、山田さんのいるノードを特定することはできません。従って、全部のノードでSQL処理をして 結果が返ることになります。 Copyright IBM Co. 2000 IBM Software 25-26 DB2 UDB/EEEのＳＱＬ処理 (2/2) T2 T1 区分キーを指定したアクセス など、処理がその単一区画内 に限られる場合、処理は完全 にそのデータの存在する単一 区画内で実行される DB2 UDB/EEE データ1へのアクセス 要求 データ2へのアクセス 要求 ﾉｰﾄﾞ1 ﾉｰﾄﾞ2 コーディネーター･ エージェント ﾉｰﾄﾞ3 ﾉｰﾄﾞ4 コーディネーター･ エージェント パラレル･ エージェント サブ･ エージェント バッファープール バッファープール ロック情報 ロック情報 バッファープール バッファープール ロック情報 ロック情報 1. SQLの処理のリクエストを受けたコーディ ネータ・エージェントがSQLをデータの存在 する特定ノードに配布。 2. ノードにて、エージェントがSQL処理をノー ド内でローカル処理。 3. 結果をコーディネータ・エージェントへ返 す。 4. コーディネータ・エージェントにて必要に応 じて最終の集約処理（ソート・計算)を行い、 結果をクライアントに返す。 データ2 データ1 Copyright IBM Co. 2001 IBM Software 解説: DB2 UDB/EEEのＳＱＬ処理 (2/2) 一方、SQLが、「山田さんが何人いますか」ではなくて、「会員番号1番の人はどのような人ですか」といった内容の SQL処理だったとします。会員番号1番の人がノードの1番にいると仮定しますと、そのSQLはそのままノード1で処 理をして結果が返ります。 例えば、会員番号3の人のデータが、仮にノード3番にあるとします。クライアントは、ノードの2番に接続しました。 この場合、ノード2番からIOに行くのではなくて、ノード3番にSQL自身（メッセージ）を飛ばして、3番のデータを返す という動きになります。 Oracleの場合は、ノード２番から3番のデータをとりに行きます。 DB2 UDBの場合は、会員番号3とわかったら、必ずノード3番に存在することが事前にわかるため、ノード3番にSQL を送り処理をする、という動きになります。逆にいうと、あるノードに分割して入ったデータをアクセスするためには、 必ずその処理のSQLはそのノードで処理されるということです。3番のデータを見るためには、かならずノード3番に リクエストが来て、SQL処理をして返すという動きになります。 従って、ORACLE OPSでパフォーマンスが出ない1つのパターンとして、どこかのノードに集中しているというがある かもしれませんが、DB2の場合はデータを分散している関係上そういうケースは起き難く、どちらかというとノード間 でのメッセージが多くパフォーマンスがあまり出ないというパターンがDB2の特徴になります。 Copyright IBM Co. 2000 IBM Software 27-28 (補足)キーレンジ・パーティションニング DB2 UDBはキーレンジ・パーティショニングを提供していません。 しかし、以下のような方法で、実現可能です。 ハッシュ値が１となるような値を追加 例えば最上位桁により 分割する例を考える 区分化マップ (Partition Map) DB2 会員番号 氏名 居住地 分割番号 3712 Toronto Jim Stittle 123-456-789 Vector Position 0 1 2 3 4 5 6 7 8 9 10 11 12 13 ... Node Assignment 0 1 2 3 4 5 6 7 8 9 0 1 2 3 ... DB2 DB2 DB2 ノードグループB ノードグループA Copyright IBM Co. 2001 IBM Software 解説: (補足)キーレンジ・パーティションニング DB2 UDB EEEはハッシュ・パーティショニングという形式をとっています。 キーレンジ・パーティショニングは、現時点でサポートしておりません。 しかし、カラムを1つ追加する方法で、キーレンジ・パーティショニングと似たような方法をとることができます。 例えば、会員番号の上1桁の値で、0から9までの10個の区画に分けたいとします。追加するカラムにどのような値 を入れればどの区画に入るのかということが事前に関数等があり、計算することができます。この関数を使用し て、事前にカラムを生成し、データを挿入する際に、この値を決めておけばキーレンジ・パーティショニングと似たこ とを実現することが可能です。 Copyright IBM Co. 2000 IBM Software 29-30 ＤＳＳシステムでの処理 (1/2) DSSシステムでの表の結合処理を各ノード内で処理するように設計す ることがポイント T1 DB2 UDB/EEE データアクセス要求 必要に応じて区画内並列処理 ﾉｰﾄﾞ1 ﾉｰﾄﾞ3 ﾉｰﾄﾞ2 ﾉｰﾄﾞ4 コーディネーター･ エージェント パラレル･ エージェント パラレル･ エージェント パラレル･ エージェント パラレル･ エージェント ２つの表の結合(JOIN)処理が ある場合、２つの表の区分 キーをそろえることにより、結 合処理が各区画内で完結し、 理想的な並列処理を実現。 結合処理のためのノード間の 通信は発生しない。 表Ａ JOIN JOIN 表Ｂ JOIN JOIN Copyright IBM Co. 2001 IBM Software 解説: ＤＳＳシステムでの処理 (1/2) DSSとはDecision Support Systemの略で、一般的な情報系という意味でDSSと書いています。 これから、DSSシステムでの特徴と、OLTP、トランザクション系のシステムでの特徴の2つに分けてご説明します。 最初にDSSシステムの特徴ですが、(OLTPもそうなのですが）JOINの処理が非常に重いということがあるかと思い ます。この例では、DB2 UDBの並列DBを使って、DSSシステムで表A表Bともに非常に大きい 両方とも何千万件 何億件という表が2つあります。それを常時JOIN(結合）する必要があるといった状況の場合の考慮点をご説明しま す。 データを分割して配置する区分キーを、表A表Bとも揃えるということです。 別の言い方をすると、それぞれの表をJOINするキーで、それぞれを区分化するということになります。 仮に両方とも顧客番号を含んでいる表で、顧客番号がJOINのキーとした場合、SQLとしては表Aと表Bからデータ を取得しますが、条件指定のところで表Aの顧客番号=表Bの顧客番号を指定することになります。 そのSQL処理が全ノードで処理されるわけですが、JOINの処理が、顧客番号で両表ともハッシュしていますので、 同じ顧客番号のデータは同じノードにあります。従って、全ノードにSQLは飛んでいきますが、そのJOINの処理は そのノードで完結します。きれいに完結して結果が返ってきます。 このように設計ができれば、ノードが2倍になれば性能も約2倍、3倍になれば3倍とスケールしていきます。 逆にこのような設計ができない場合、結合するためにデータが全然合わないので、どちらかのデータを、高速とは いってもネットワークを介してどちらかのノードに送り込んで結合JOINの処理をする必要があります。 この処理はノードローカルで処理が簡潔するケースと比べると性能はよくありません。 従って、（すべてがこのような設計が出来るとは限りませんが）特に性能的に重要なところは、このような設計がで きないと並列化しても効果がありません。 逆に言うとこういった設計ができれば並列化に非常に向いていて、データが増えたり、あるいはトランザクションが 増えた時も、マシンを追加していけば、同じ論理設計・物理設計で、何も変更することなく性能が伸びていく、ス ケールするといっところが、DB2の特長です。 Copyright IBM Co. 2000 IBM Software 31-32 ＤＳＳシステムでの処理 (2/2) : サマリー表 同じような集計処理やJoin処理を行うSQLが多数ある場合、 →サマリー表があれば計算済の結果を再利用できて高速 →サマリー表の使用はオプティマイザーが判断するためSQLの書き換えは不要 ５月１日∼2日の日ごとの合計売上金額と客単価を店舗ごとに見たい！ SELECT SUM(売上金額), AVG(売上金額) FROM 売上表 GROUP BY 店舗番号, 売上日 WHERE 売上日 BETWEEN 0501 AND 0502 サマリー表がなければ、 基礎表をアクセス サマリー表があれば、 サマリー表をアクセス オプティマイザーがSQLを 書き換え SELECT 売上日計, 売上日計/客数 FROM 売上サマリー表 WHERE 売上 日 BETWEEN 0501 AND 0502 売上明細表 売上サマリー表 (基礎表) レシート番号 店舗番 号 売上金額 売上日 0312778 6478123 1278945 1237811 0245789 3324651 0398712 5421762 2479543 10 10 20 10 20 30 50 10 50 2560 398 4890 10520 3560 1124 1350 9870 1050 0501 0501 0501 0502 0502 0501 0503 0501 0501 (サマリー表) サマリー表を作成しておく 店舗番号＋売上日ごとに金額を集計し、 客数(レシート数）を計算 CREATE SUMMARY TABLE 売上サマリー表 AS SELECT店舗番号,売上日,SUM(売上金額) AS 売上日計, COUNT(*) AS 客数 FROM 売上表 GROUP BY ( 店舗番 号,売上日) DATA INITIALLY DEFFERED REFRESH DEFERRED 店舗番号 売上日 売上日 計 客数 10 10 10 20 20 20 0501 0502 0503 0501 0502 0503 321054 472598 458210 253680 185420 321658 1230 1680 2230 4210 3210 3580 Copyright IBM Co. 2001 IBM Software 解説: ＤＳＳシステムでの処理 (2/2) : サマリー表 もう一つ、DSSシステムの特長では、DB2ではサマリー表というものがあります。 ORACLEでいう、マテリアライズド・ビューというものです。 よくある集約のパターンが共通であった場合、必ず営業マンの方が地域コードでGROUP BYをかけますという場 合、事前に部分的に集約したものを作っておくことができ、SQLとしては明細の表を見に行くのですが、DB2が自動 的に適用できる場合はそのサマリーした表を見に行くといったことができます。 この例では、売上日の5/1から5/2の間で、日時バッチが終わった後で、2日分の集約したサマリー表を作っておき ます。 売上日の5/1から5/2のデータを検索した段階で2日分の集約表を見に行きます。 営業マンは明細表に対してSQLを発行しているのですが、SQL文の条件式の中のBETWEEN 0501 AND 0502をオ プティマイザーが見た段階で、サマリー表があればサマリー表を照会します。 サマリー表は、一般的に基本表にくらべて何十分の1または何百分の１といった非常に小さいサイズなので表ス キャンになったとしても高速です。このようなパターンがあるような場合には、このようなテクニックが使えます。 これは、情報系では特によく使われるものです。 Copyright IBM Co. 2000 IBM Software 33-34 ＯＬＴＰシステムでの処理(1/6) ： ローカル・バイパス処理 OLTPシステムでの処理では、ローカル・バイパス処理となるように 設計する 処理は完全に単一区画内で実行される 他の区画での処理はなし ２フェーズ・コミットもなし 下図で、T1 の処理がローカル・バイパス処理である Transactions T1 Local T2 T3 non-collocated Non local DB2 UDB EEE where partition_key = xx とすると必ず単一区画内処 理となる Copyright IBM Co. 2001 T1 Coordinator Partition 1 T2 Coordinator Partition 2 T3 Subagent T2 Subagent Partition 3 T3 Coordinator T3 Subagent Partition 4 IBM Software 解説: ＯＬＴＰシステムでの処理(1/6) ： ローカル・バイパス処理 続きまして、OLTPシステムでの処理です。 OLTPのシステムの処理においても、表のJOINの処理はありますので、先ほどのDSSシステムの場合と同じように JOINするキーが同じでハッシュするデータ分割するというデザインにしておくことを考慮する必要があります。 その上で、以下のようなことを考えます。 ＜基本方針は、ローカル・バイパス処理＞ あるトランザクション(SQL)が区画１に接続して、区画1にデータがあるので、そのまま完結しました。 あるトランザクションは区画2に来たら区画3にデータがあるので行ってしまいました。あるいは、トランザクション3番 目はその条件から両方の区画のデータを見なければならないということで、区画3と区画4で処理をして、それを最 終的にまとめて返すとします。この時、2番目と3番目のトランザクションではノード間通信が発生しています。 1番目のトランザクションのように接続したノードで処理が完結することを、DB2の用語でローカル・バイパス処理と 呼びます。OLTPの処理は、もちろん他のパターンもありますが、ローカル･バイパス処理で終るパターンがかなり 多いはずです。従って、ロカールバイパス処理で済むものはローカルバイパス処理にしましょうというのが基本方 針です。 例えば、登録処理のINSERT処理がある場合、INSERT処理は接続した区画だけで実行すると1ミリ秒かかるかどう かですが、他のノードの処理が必要になると、ネットワークのオーバーヘッドがかかりますので、数ミリ秒かかること があります。つまり、他ノードに行くだけで相当遅延します。そのためローカル・バイパスパターンにしましょうという ことです。 ＜2フェーズ･コミット＞ 2フェーズ･コミットもなしとありますが、DB2 UDB EEEはすべて各区画毎にDBがわかれているようなイメージですの で、ノードをまたがってINSERTをすると、実は内部のDB間は2フェーズ･コミットになっています。 アプリケーションはまったく意識しませんが、実際はそのようになっています。このような動きも、ローカル･バイパス 処理にすることでなくなるので、コミット時の負荷も下がります。 Copyright IBM Co. 2000 IBM Software 35-36 ＯＬＴＰシステムでの処理(2/6) :アプリケーション設計 アプリケーションは、事前にローカル・バイパス処理となるよう に、データが存在している区画を認知できる API get_table_partition -- パーティション・マップ取得 get_row_partition -- パーティション・キーから区画番号の取得 処理手順 1. get_table_partition により、マップを初期化(クライアント側に保存) 2. get_row_partition により区画番号を取得(これはクライアント側だけの処理） 入力: partitioning key 出力: 区画番号 データベースへのアクセスは不要 3. 該当区画へ接続し、処理を実行 Copyright IBM Co. 2001 IBM Software 解説: ＯＬＴＰシステムでの処理(2/6) :アプリケーション設計 ローカル･バイパス処理を実現するために内部的に関数が用意されています。 パーティション情報を取得する関数と、区分キーから区画番号を知るという関数があります。 これにより、パーティション情報をもとに、顧客番号わかっていたらそのデータがどのノードにあるか知ることもでき ます。 例えば、3層のシステムで、アプリケーション･サーバーが初期化でセッションをはった状態で、パーティション情報を 取得します。その後後続SQL処理で会員番号何番のデータ取得の場合、どのノードにあるかを得て、該当ノードへ セッションをはってSQL処理をすると、完全にローカル・バイパス処理になります。 Copyright IBM Co. 2000 IBM Software 37-38 ＯＬＴＰシステムでの処理(3/6) : WebベースのOLTPシステム例 Personal Edition 2. Response Browser cookie 認証用データベース Userids Passwords 区分化マップ Web Server 1. Initial connection Authorization 3. Subsequent interactions Direct connection using a cookie DB2 UDB EEE Partition 1 Partition 2 Partition 3 Partition 4 Copyright IBM Co. 2001 IBM Software 解説: ＯＬＴＰシステムでの処理(3/6) : WebベースのOLTPシステム例 この例では、Webから個人の情報が入っているDBがあり、その個人からアクセスが来ました。そこには、その人の 認証用の情報や、区分化の情報が入っているとします。 まずWebからリクエストが来ると、Cookieから認証情報と共に区分化情報もこのアプリケーションサーバーに返しま す。どこのノードにあるかという情報も入れておいてそれがノード4とかわれば、Webアプリケーション･サーバーか ら、ノード４にはってあるセッションを使って処理すれば、必ずローカル･バイパス処理にすることができます。 もちろんこのような形にしなくてもリクエスト毎にこの中で完結するような形で作っておいても結構です。 Copyright IBM Co. 2000 IBM Software 39-40 ＯＬＴＰシステムでの処理(4/6) : レプリケート表：単一区画内処理の実現 ある表が 同じキーで区画分割できない サイズが適当（通常、数万件から数十（百？）万件） 読み取り専用 である場合に、レプリケート表を適用し、単一区画内処理を実現 DSSシステムでも利用可能 CREATE TABLE R_ITEM AS (SELECT * FROM ITEM) DATA INITIALLY DEFERRED REFRESH IMMEDIATE REPLICATED DB2 DB2 DB2 DB2 区画内での結合 Primary Table Replicas Copyright IBM Co. 2001 IBM Software 解説: ＯＬＴＰシステムでの処理(4/6) : レプリケート表：単一区画内処理の実現 JOINする表は同じハッシング・キーを持ち、ノード内での完結処理が基本方針ですが、様々なマスターがあります ので、マスターキーを統一することはできません。 そのため、マスターは1ノードに配置して、その複製を各ノードに置くという、マスターを全部各ノードのローカルに置 くことができます。 SQLとしては、図の紫色の各ノードにまたがっている表と、マスター表をJOINするようなJOINのSQLをローカル・ ノード内で行うようにDB2のほうで処理をかえてくれるということができます。 マスター表が小さい時は、動的に、マスターが各ノードにネットワークを通じてコピーされます。コピーされてJOINさ れます。表が小さい時は早いです。 ただし、数十万件から数百万件のマスターになった場合は、複製を置くというこのような機能を使わないと性能が 得られずらいということがあります。このようなテクニックもよく使われます。 Copyright IBM Co. 2000 IBM Software 41-42 ＯＬＴＰシステムでの処理(5/6) : OLTP Performance Measurements Transactional Throughput Transactions per Minute (TPM) 21,918 25,000 20,000 1 node 2 nodes 4 nodes 11,311 15,000 7,428 10,000 5,000 0 # of nodes Copyright IBM Co. 2001 IBM Software 解説: ＯＬＴＰシステムでの処理(5/6) : OLTP Performance Measurements TPCという業界モデルベンチマークがありますが、これは、トロント研究所で実際にそれを使って、ノードが1つの 時、2個のとき、4個の時に性能がどうなるかというのを測定したものです。 1ノードあたりCPUが4つあるケースです。 1つから2つに移るときはあまりスケールしていませんが、これは、単一システムが並列に移るだけで、オーバー ヘッドが少し違うためです。2から4になる時は、ほぼ2倍に近いスケーラビリティーが得られていることがわかりま す。 Copyright IBM Co. 2000 IBM Software 43-44 ＯＬＴＰシステムでの処理(6/6) : OLTP スケーラビリティ 100% 4 81% Scaling Factor Ideal (100% scalability) No remote transactions TPC-C scalability (local and remote) Randomly distributed transactions 74% 3 100% 2 81% 76% 1 18% 34% 0 1 node 2 nodes 4 nodes Copyright IBM Co. 2001 IBM Software 解説: ＯＬＴＰシステムでの処理(6/6) : OLTP スケーラビリティ 表のJOINはローカルに行うように配置する、それからOLTPの場合には、データがあるノードにSQLを投げると それぞれがどのくらい守られているかで、結果がどうなるかを示しています。 1ノード、2ノード、4ノードで、ピンクのグラフが理想です。それぞれ2倍、4倍になっています。 次に黄色の部分が、データはローカルに置き、かつ別のノードにSQLは飛ばないという形では、80%位のスケーラビ リティーが得られます。 このデータの見方は、4ノードで80%ということは、1ノードの3.2倍です。これは、OLTPではかなり良い値であると思 います。 緑色のTPC−Cのケース、データは1つのマスター表を除いてきれいに配置されています。 トランザクションもなるべくSQLの特性として全ノードに飛んでいくものが数%から数十%入っています。他のノードに も飛びますが、理想的に近いケースがTPC-Cのケースです。その場合で、75%前後です。 何も考慮しないケースが、青のケースです。4ノードにして、1ノードよりも下がります。1台の時よりも悪くなっていま す。何も考えないで並列処理をするとこうなります。 並列DBを選ぶ時には考慮が必要ですが、表のJOINとOLTPであればローカル・バイパスを守るだけでかなりス ケールすることが判ります。 Copyright IBM Co. 2000 IBM Software 45-46 高可用性(1/2) : スタンバイ構成 稼動中 スタンバイ アダプター アダプター 稼動中 スタンバイ アダプター アダプター DB2 UDB EE (オンライン) RS232C 稼動中 アダプター DB2 UDB EE (オフライン) DB2 UDB EE (オフライン) 共有 ディスク RS232C 稼動中 アダプター DB2 UDB EE (オンライン) 共有 ディスク スタンバイ構成 外部のclustering S/Wが前提 IPアドレス引継ぎ ディスク引継ぎ データベース・リカバリー(どのデータベースでも必要） アプリケーション(再)起動 ディスク共有 ディスク共有用S/Wによる、OSレベルでのディスク・シェア。これによりディ スク引継ぎが不要。 DB２ UDB V6.1以上でのサポート Copyright IBM Co. 2001 IBM Software 解説: 高可用性(1/2) : スタンバイ構成 可用性のご説明をします。 オフラインとは、OSは上がっているけれども、RDBは止まっている状態です。 オンラインが障害時には、サービス機からスタンバイ機へ以下のことが行われます。 IPアドレスの引継ぎ ディスクの引継ぎ RDBをあげて、データベース・リカバリー (どのデータベースでも必要） アプリケーション(再)起動 ディスクの引継ぎは、ストレージ管理製品を使えばゼロにすることも可能です。 多くの場合、データベースの引継ぎがリカバリーの時間を決めます。 DB2 UDB EEEの場合、RDBとしてはシェアード・ナッシングですので、絶対に異なるノードのディスクを見に行きま せん。しかし、OSとしては、両方見に行くことができるようにしておく設定（シェアードディスク）ことができます。 これにより、ディスクのテイク・オーバーの時間をゼロにすることができます。 シェアード・ナッシングの場合は高可用性が難しいという話もありますが、リカバリー時間についてはシェアード・ ディスク構成と変わりません。 Copyright IBM Co. 2000 IBM Software 47-48 高可用性(2/2) : 相互引継ぎ構成 稼動中 スタンバイ アダプター アダプター 稼動中 スタンバイ アダプター アダプター DB2 UDB EEE (ノード１） RS232C 共有 ディスク 稼動中 アダプター DB2 UDB EEE (ノード２) DB2 UDB EEE (ノード１） 共有 ディスク RS232C 共有 ディスク 相互引継ぎ構成 外部のclustering S/Wが前提 稼動中 アダプター DB2 UDB EEE (ノード１） (ノード２) 共有 ディスク IPアドレス引継ぎ ディスク引継ぎ データベース・リカバリー(どのデータベースでも必要） アプリケーション(再)起動 ノード１、ノード２とも稼動している効率的なシステム（シングル・イメージ） ディスク共有 ディスク共有用S/Wによる、OSレベルでのディスク・シェア。これによりディスク引継ぎが不要。 DB2 UDBの設計はあくまでも、シェアード・ナッシング。 DB２ UDB V6.1以上でのサポート Copyright IBM Co. 2001 IBM Software 解説: 高可用性(2/2) : 相互引継ぎ構成 相互引継ぎ構成の場合、通常は各ノードでそれぞれサービスをしており、 ノード１障害時は、ノード２内へ引継ぎを行ない縮退運転をし、ノード２障害時はノード１へ引継ぎを行ないます。 通常時は両方のノードでサービスを行っている為、効率的なシステムですが、 障害時は１ノードで２ノード分のサービスを行うので、制約などが発生し縮退運転となります。 Copyright IBM Co. 2000 IBM Software 49-50 DB2 UDB EEE : サポート・プラットフォーム 各ＯＳでのサポート・レベルは以下のとおりです。 AIX Solaris HP_UX Linux WindowsNT Windows2000 Dynix/ptx 32bit版 V4.2.1以降 V5.0以降 (PPC) V2.6以降 V10, 11i以降 Kernel 2.2.12, 2.4.0 以降 V4 SP4以降 とくに条件なし 4.5.1以降 64bit版 V4.3.3以降 V5.7以降 V10, 11i以降 − − − − Copyright IBM Co. 2001 IBM Software 解説: DB2 UDB EEE : サポート・プラットフォーム DB2 UDB EEEのサポート・プラットフォームは表のとおりです。 64ビット版に関しては、現時点では、AIX、Solaris、HP-UXです。 Copyright IBM Co. 2000 IBM Software 51-52 ベンチマーク・データ DB2 Performance Leadership - TPC Benchmark Kind #1 #2 #3 TPC-H* 100GB DB2 on Linux SQL Server SQL Server TPC-H* 300GB DB2 on NUMA-Q DB2 on NUMA-Q Informix TPC-H* 1TB Teradata DB2 on RS/6000 SP Informix TPC-W* 100K items DB2 on xSeries DB2 on xSeries n/a TPC-C* V5 SQL Server DB2 on xSeries SQL Server As of 05/11/01 *Copyright TPC Copyright IBM Co. 2001 www.tpc.org Source: IBM Software 53-54 解説: DB2 Performance Leadership - TPC ベンチマーク・データ TPCｰCは、いわゆるトランザクション系のベンチマークです。 TPC-R RはReportingで、フル・チューン可、 TPC-H AD-HOCのHで、チューニング不可、 インデックスはJOINするキーのみ、その他のインデックスは作成できません。サマリー表の使用もできません。 ハードウェアとRDBのオプティマイズの性能だけで勝負するものです。 TPC-W Webのトランザクション･ベンチマークで、DBだけではなく、Webページのリード等、全体的に性能を測るも のです。 DB2のベンチマーク結果を見ると、TPC-Hはデータのサイズで何種類かありますが、100GBではDB2 Linux(4CPU*4ノード）SGI上が現在一番速くなっています。 TPC-Hの300GBですと、NUMA-Q 1TBはつい最近TERADATAに抜かれましたが1年以上一位でした。 TPC-WはDB2 EEEを使用していません。 TPC-Cは、EEEを使用して、現在2位です。 Copyright IBM Co. 2000 IBM Software DB2 Performance Leadership - ISV ISV Benchmark #1 #2 #3 SAP 3-tier ATO DB2 on RS/6000 S80 DB2 on Bull-Escala Oracle SAP 2-tier ATO Oracle Oracle DB2 on pSeries 680 SAP BW 1.2 DB2 on RS/6000 S80 SQL Server n/a SAP 2-tier SD (4-way Intel) DB2 on xSeries DB2 on xSeries Oracle Peoplesoft HRMS 7.5 DB2 on RS/6000 M80 SQL Server Oracle Peoplesoft FTP DB2 on RS/6000 S80 Oracle n/a Peoplesoft GL Batch DB2 on RS/6000 S80 Oracle Oracle Baan ERP 2-tier DB2 on pSeries 680 DB2 on RS/6000 S80 Oracle Baan ERP 3-tier DB2 on RS/6000 S80 Oracle DB2 on iSeries 400 Copyright IBM Co. 2001 IBM Software As of 05/11/01 55-56 解説: DB2 Performance Leadership - ISV このページは、ERPベンチマークです。 この中でEEEを使用しているのは、SAP BW1.2のケースです。 DB2 UDBがオープンなベンチマークでよい結果を出していることがおわかりいただけると思います。 Copyright IBM Co. 2000 IBM Software TPC-H 100GB : DB2 UDB EEE on Linux Leadership 100GB TPC-H 3500 3000 3128.8 2733.7 2500 2415.2 2388.6 2000 1699.8 1500 1196.3 1000 500 0 QppH QthH QphH DB2 UDB on Linux (4x4x700 MHz SGI) SQL Server on Win2000 (8x700 MHz Compaq) TPC Benchmark and TPC-H are trademarks of the Transaction Processing Performance Council DB2 UDB: 2733.7 QphH@100GB, $347/QphH@100GB, Availability Date 10/31/01 SQL Server: 1699 QphH@100GB, $161/QphH@100GB, Availability Date 8/01/00 Results are as of May 11, 2001 Copyright IBM Co. 2001 Benchmark includes Linux 2.4.3 running DB2 UDB V7.2 on an SGI 1450 server vs. other OEMs' hardware running Windows 2000 and MS SQL Server 2000 The Linux, IBM and SGI platform processed 2,733 queries per hour The Microsoft and Compaq offering processed 1,699 queries per hour 57-58 IBM Software 解説: TPC-H 100GB : DB2 UDB EEE on Linux このベンチマーク結果では、DB2 EEEがLinuxでも使えることを示しています。 様々なお客様で、Linuxで使用したいという声はますます高くなっています。 このような値が出ておりますので、WebのバックエンドDBもありますが、情報系という可能性も高いです。 Copyright IBM Co. 2000 IBM Software Case Study by Merrill Lynch 4-node DB2 UDB EEE for Windows (1+ TB) Front-end Web clients & transaction mgmt. Results: 320 tps (19,200 tpm) Copyright IBM Co. 2001 IBM Software 59-60 解説: Case Study by Merrill Lynch これは、Merrill Lynch様のケースで、トランザクション系のシステムです。 4ノード4Way リアルなトランザクションで320トランザクション/秒という値を出しています。 Copyright IBM Co. 2000 IBM Software TPC-C: Showcase OLTP Scalability Single DB2 UDB EEE for Windows database with 32 nodes DB2 DB2 DB2 Copyright IBM Co. 2001 DB2 IBM Software 61-62 解説: TPC-C: Showcase OLTP Scalability これは、TPC-Cの構成で、実際にはWindowsマシンを32台並べた構成です。クライアントが96台です。 Copyright IBM Co. 2000 IBM Software TPC-C Benchmark - DB2 UDB EEE V7.1 DB2 UDB EEE V7.1 32 x 4 Netfinity Servers, Windows 2000 700 mhz Pentium III 21 billion records 3.2 TB raw data 1.2 TB log space 0.6TB index Hundreds of Thousands of users! 96 Client machines, 2way pentium 600mhz Each simulating approx. 3,840 tpc-c users Copyright IBM Co. 2001 IBM Software 63-64 解説: TPC-C Benchmark - DB2 UDB EEE V7.1 生データが3.2TBです。 100万ユーザーで1台あたり約3万件/分トランザクションが出ています。 Copyright IBM Co. 2000 IBM Software DB2 UDB EEE on pSeries (1/3) ほぼリニアなスケーラビティ 24 way １ノードあたり５００ＧＢユーザ・データ ２ノード（１ＴＢ）で同じテストを実行 スケーラビリティ > 95% 256 同時ユーザー 500GB 24 way 500GB Query Performance Database Build 1200 600 508 507 500 1000 404 400 800 Time (s) Time (mins) 438 500 GB 1 TB 300 200 400 173 177 83 100 500GB 1 TB 600 84 200 0 0 Load Runstats Create Index Build ASTs Query Copyright IBM Co. 2001 IBM Software 65-66 解説: DB2 UDB EEE on pSeries (1/3) 実績としては、pSeriesを使用した構成で、数百万件/秒のトランザクションが実際に稼動しています。 このベンチマークはそれとは違いますが、24CPUのUNIXマシンを1台でスケーラビリティを計測した結果です。 片方のノードだけで生データが500GB 2ノードの構成の時は、1TB 結果としてはスケーラビリティーが95%以上出ています。 Load 173秒ということは、1時間に165GBくらいのロードができると読み取ることができます。 この表では、DB構築系のユーティリティーと実際のSQLを実行しています。 Copyright IBM Co. 2000 IBM Software DB2 UDB EEE on pSeries (2/3) : Rolling Windows: Results 500 GB Delete 17m10s 289M 行 % .6 281k 行/sec 5 0 1 150 - 170 MB/sec 1 TB 16m16s 598M 行 613k 行/sec 150 - 170 MB/sec Insert 33m 288M 行 145k 行/sec 2% 98. 90 - 100 MB/sec 33m36s 596M 行 295k 行/sec 90 - 100 MB/sec 12 同時実行(Insert/Delete) 全体の10%のデータを更新 インデックスは、１つのクラスタ・インデックスのみ Copyright IBM Co. 2001 IBM Software 67-68 解説: DB2 UDB EEE on pSeries (2/3) : Rolling Windows: Results Rolling Windowsとは、いわゆる月次バッチ処理です。 1ヶ月分削除して、1ヶ月分挿入するというようなバッチを想定しいます。 2億8千9百万行をDeleteするのに17分です。秒あたり28万1千行となります。 これは、アプリケーションを12並列で実行し、条件を分けて実行しています。 INSERTは下図のとおりの値です。 この場合は24Wayでの結果ですが、最近のUNIXのハイエンドの小さな構成でこのくらいの性能がでることを見て取 れると思います。 Copyright IBM Co. 2000 IBM Software DB2 UDB EEE on pSeries (3/3) : System Overview - 1TB: Enterprise Storage Server 1.0 (Sharks) 6x 160Mb/Sec Ultra SCSI Ultra SCSI 3x8x 40Mb/Sec 3x8x 40Mb/Sec S80 S80 Gigabit Ethernet Copyright IBM Co. 2001 2x 100Mb/Sec 69-70 IBM Software 解説: DB2 UDB EEE on pSeries (3/3) : System Overview - 1TB: 全体の構成図です。S80と、ESSディスクが1台のUNIXに対して3台ずつついている構成です。 Copyright IBM Co. 2000 IBM Software DB2 UDB EEE on Sun Copyright IBM Co. 2001 IBM Software 71-72 解説: DB2 UDB EEE on Sun 弊社以外のプラットフォームでもテストをしています。 公開できるものとしては、Sun Fireの構成でスケーラビリティーのテストをしています。 CPUとして、8の時と、16の時と、24の時で、ほぼ100%のスケーラビリティーが出ています。これは、1つの表のアプ リケーションで、GROUP BY等をしているケースです。 もう一つのJOINするケースがありますが、このケースでは90%位のスケーラビリテイーが出ています。 Copyright IBM Co. 2000 IBM Software まとめ 73-74 DB2 UDB EEE : まとめ DSSタイプにも、OLTPタイプにも対応可能 従来のDSSタイプの処理 データウェアハスス、データマート 今後は、OLTPタイプの処理の増加が期待される WebバックエンドＤＢ Active Data Warehouse = OLTP + DWH としても期待される 実証された性能、スケーラビリティ プラットフォームは、Windowsから主要Unixまで幅広く対応 WindowsNT/2000, Linux, AIX, Solaris, HP_UX, Dynix/ptx ＭＰＰおよび大規模ＳＭＰどちらにも対応 Copyright IBM Co. 2001 IBM Software 解説: DB2 UDB EEE : まとめ DB2 UDB EEEはもともとは情報系で発展してきましたが、OLTPでも上手く使えば非常にスケールする製品です。 かなりリアルタイムに分析したいという要望がどんどん高まってくる中、DB2 UDBの並列DBを用いたシステムも検 討していただければと思います。 性能およびスケーラビリティーについては、実証されています。プラットフォームは、Linuxから、Solaris HP-UX もち ろんAIX等で動きます。 MPP型の多数のマシンを並べる形にも対応しますし、大きなSMP（弊社のpSeriesやSUN社のStarFire)のどちらにも 対応しています。 データ、トランザクションがどんどん増えていく場合には、あらかじめ大きなシステムにしておくという場合もあります が、並列の場合は、４倍にすればあらかじめ3.X倍出るとわかっていれば、事業計画を立てる時にも、成長に合わ せたシステム増強計画が立てやすくなります。 Copyright IBM Co. 2000 IBM Software 75-76