HP ブレード・サーバーと Intel Oracle Database 11g DICOM 画...HP...

HP ブレード・サーバーと Intelプロセッサを使用した Oracle Database 11g のストレージ・パ

フォーマンス評価と DICOM 画

像コンテンツの取得 Oracle ホワイト・ペーパー

2008 年 7 月

HP ブレード・サーバーと Intel プロセッサを使用した Oracle Database 11g のストレージ・パフォーマンス評価と DICOM 画像コンテンツの取得

2

Oracle Corporation 発行「A Performance Evaluation of Storage and Retrieval of DICOM Content in Oracle Database 11g Using HP Blade Servers and Intel Processors」の翻訳版です。

HP ブレード・サーバーと Intel プロセッサを使用した

Oracle Database 11g のストレージ・パフォーマンス評価と DICOM 画像コンテンツの取得

概要 ...................................................................................................................... 3 取得パフォーマンス ..................................................................................... 3 書込みパフォーマンス ................................................................................. 3 使用ハードウェア ......................................................................................... 3

背景 ...................................................................................................................... 4 Oracle Multimedia での DICOM 形式のサポート....................................... 4 Oracle SecureFiles .......................................................................................... 4 Oracle Database への医用画像およびライフサイエンス画像の保存 ...... 5

目的 ...................................................................................................................... 5 医用画像のワークロード ............................................................................. 5 データのモデリング ..................................................................................... 6 操作のモデリング ......................................................................................... 7

検査取得 ................................................................................................... 7 検査挿入 ................................................................................................... 7

システム構成 ...................................................................................................... 8 データベース・サーバー ............................................................................. 8 データベース・ストレージ ......................................................................... 9 クライアント・システム ............................................................................. 9

単一インスタンス構成でのパフォーマンス結果 ......................................... 11 単一インスタンス構成でのモダリティ別検査取得パフォーマンス ... 12 単一インスタンス構成でのモダリティ別検査挿入パフォーマンス ... 14

デュアル・インスタンス構成でのパフォーマンス結果 ............................. 16 デュアル・インスタンス構成でのモダリティ別検査取得パフォーマンス

....................................................................................................................... 16 デュアル・インスタンス構成での検査取得パフォーマンス - 全モダリティを一度に実行 ....................................................................... 18 デュアル・インスタンス構成での心臓 CT の同時取得および挿入 .... 19

付録 - ワークロードの実装 ........................................................................... 21 データベース・ストレージ ....................................................................... 21 表設計 ........................................................................................................... 21 アプリケーション設計 ............................................................................... 24 ネットワーク構成 ....................................................................................... 24

謝辞 .................................................................................................................... 24


3


HP ブレード・サーバーと Intel プロセッサを使用した

Oracle Database 11g のストレージ・パフォーマンス評価と DICOM 画像コンテンツの取得

概要

世界有数の PACS ベンダーが、Oracle Database に保存された DICOM 画像の取得要

件として、1 秒当たり 300 画像を実現するよう課題を提示してきました。この課

題に対応するため、オラクルでは、主要な PACS ベンダーやモダリティ・ベンダー、

病院、ライフサイエンス分野の研究者、および製薬会社からの情報をもとに代表

的なワークロードを定義し、このワークロードを使用して、Linux OS と Oracle Database がインストールされた HP や Intel の汎用ハードウェアで DICOM ベンチ

マークを実施しました。

結果は、課題であった数値のほぼ 3 倍となり、最大画像取得速度は 852 画像/秒に

達しました。

これと比較して、他社のデータベースは DICOM がサポートされていないため、

いずれのデータベースでもオラクルと同等の結果を得ることはできません。

取得パフォーマンス

Oracle Multimedia では、Linux OS に Intel チップを搭載した HP のデュアル CPU コ

ンピュータ 1 台で、心臓 CT 画像の 850 画像/秒以上の読取り速度を維持できるこ

とが判明しました（各心臓 CT 画像は 512KB です）。同じボックスの 2 ノード RACクラスタでは、取得速度が 1,550 画像/秒以上となりました。マンモグラフィ画像

（平均 26MB）の読取りスピードは、単一ノード構成で 500MB/秒以上、2 ノード

RAC クラスタ構成で 1GB/秒以上を実現しました。

書込みパフォーマンス

Oracle Multimedia では、Linux OS に Intel チップを搭載した HP のデュアル CPU コ

ンピュータ 1 台で、心臓 CT 画像の 550 画像/秒を超える書込み速度を維持できる

ことが判明しました。これは、心臓 CT 画像の 950 画像/時間以上の取得速度にあ

たり、1TB の画像が 65 分未満でロードできます。マンモグラフィ画像の書込み速

度は、単一ノード構成で 440MB/秒を超えました。

使用ハードウェア

ベンチマークは以下のハードウェアで実施しました。

サーバー：2 台の HP BL480c ブレード・サーバー

2 基の 3.2 GHz Intel Xeon X5640 クアッドコア・プロセッサ（搭載メモリ 48GB）

ストレージ：2 基の HP StorageWorks EVA 8100（146GB FC 15k HDDx112）


4


背景

Oracle Database 11g Release 1 では、Oracle Database で管理と保護をおこなう大容量

かつ高パフォーマンスの医療およびライフサイエンス・コンテンツにおいて、リ

ポジトリとアーカイブを構築するための 2 つの新機能が導入されました。

Oracle Multimedia での DICOM 形式のサポート

Oracle Database 11g Release 1（11.1）により、Oracle Multimedia では医用画像の標

準として広く認識されている DICOM（Digital Imaging and Communications in Medicine）形式を完全サポートしています。そのため、アプリケーションで Oracle Multimediaの DICOM Javaと PL/SQL APIを使用して、DICOM コンテンツの保存、

管理、操作を実行できます。

Oracle Multimedia での DICOM のサポートは、次の機能を対象としています。

• ORDDicom オブジェクト型

• DICOM メタデータの抽出

• DICOM 適合性検証

• DICOM 画像処理および画像圧縮

• DICOM コンテンツの匿名化

• 画像やメタデータからのコンテンツの作成

• 実行時に更新可能な DICOM データ・モデル

• 標準 DICOM モデルへのユーザー定義拡張機能

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

http://www.oracle.com/technology/products/intermedia/index.html

Oracle SecureFiles

Oracle Database 11g の新機能である Oracle SecureFiles は、Oracle データベース・ス

トレージの利点を維持しながら、従来のファイル・システムに匹敵する高いパ

フォーマンスとスケーラビリティをファイル・データ保存時に実現するように設

計されています。

Oracle SecureFiles には、パフォーマンス、スケーラビリティ、ストレージ効率、

および管理性を大幅に向上させるためのアーキテクチャ上の拡張機能が多数導入

されています。Oracle SecureFiles の機能には、次のようなものがあります。

• 暗号化

• インテリジェント・プリフェッチ

• 新規ネットワーク・レイヤー

• ファイル・システムと同様のロギング

• 非重複


5


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

http://www.oracle.com/technology/products/database/securefiles/index.html

Oracle Database への医用画像およびライフサイエンス画像の保存

Oracle Database を使用した大容量で高パフォーマンスの医療およびライフサイエ

ンスのコンテンツ・リポジトリとアーカイブを構築するメリットには、次のよう

なものがあります。

• 医用画像と患者データの統合により、異機種システム全体で患者を一元

管理する健康記録の分散を防止

• インフラストラクチャをカスタム構築することなく、医療およびライフ

サイエンスのコンテンツをデータ転送し、データ共有を実行

• 全アーカイブ・コンテンツにプライバシ・ポリシーとセキュリティ・ポ

リシーを一貫して実施

• アプリケーションの変更や停止時間を伴わず、進化する DICOM アーカイ

ブを管理（新規モダリティや新規 DICOM 規格の組込み）

目的

このベンチマークの目的は、DICOM 対応の Oracle Database 11g が、医用画像およ

びライフサイエンス画像の大容量のリポジトリとアーカイブに適した、高パ

フォーマンスかつ低コストの完全機能を搭載したプラットフォームであることを

証明することです。これは、HP 製のコンピュータとストレージ、Intel プロセッサ

を使用して証明されました。

もう 1 つの目的は、PACS ベンダーやモダリティ・ベンダー、病院、ライフサイ

エンス分野の研究者、および製薬会社からの情報をもとに代表的なワークロード

を作成し、その結果を生成して公開した際に、そのワークロードが明確かつ使用

可能な状態にすることです。

要求されていたのは心臓 CT 画像（512KB）に関するレポートですが、ベンチマー

クではさらに 5 つのモダリティを追加しました。データベース・サイズは 2TB で、

240 万画像で構成しました。独自のメタデータと多様な画像コンテンツを含む新

規 DICOM ファイルを作成し、各検査に固有の検査インスタンス UID、シリーズ・

インスタンス UID、および患者名を設定しました。患者名の後ろには、米国勢調

査局の名前分布が付加されており、各画像には固有のメディア・ストレージ SOPインスタンスが設定されています。

このベンチマークでは、Oracle Database への画像の挿入速度と取得速度を測定し

ました。

医用画像のワークロード

このベンチマークでは、DICOM 画像のデータセット・モデルと、データで実行す

る操作セットの 2 つの主要コンポーネントをもつワークロードを定義します。こ

の 2 つのコンポーネントについては、以下の各項で説明します。定義が明確なた

め、ここでは医用画像のモダリティが使用されていますが、ライフサイエンス・

アプリケーションについても、画像サイズを医用モダリティと簡単に関連づけて


6


パフォーマンスを予測できます。

データのモデリング

診断医用画像デバイスによって、デジタル画像グループ（検査）が生成されます。

検査に含まれる各画像のサイズと画像数は、臨床検査の目的や各種画像デバイス

によって異なります。検査を構成する画像は、通常、1 つのグループとして保存、

取得、および処理されます。

このベンチマークでは、表 1 に示したデータセット・モデルを使用して、医用画

像の 6 つの一般的なモダリティのシミュレーションを実施しました。ただしこの

データセット・モデルは、特定の医療機器を表しているわけではありません。モ

ダリティ・モデルは、1 検査当たりの画像ファイル数と各ファイルのサイズにつ

いて、実際のモダリティを大別する目的で作成されています。こうしたディメン

ションに沿って、モダリティ・モデルの範囲を M02（1～100MB のファイル 1 つ

のみを含むもの）から M03（平均画像サイズ 5MB の画像を最大 4,096 画像含むも

の）までに設定しています。こうしてファイル数とファイル・サイズのバリエー

ションを設定することで、幅広いデータセットのストレージおよび取得パフォー

マンスを調査できます。

表 1：DICOM 画像のデータセット・モデル

タイプモダリティ・モデル

1 検査当たりの画像数各画像サイズ（MB）平均検査サイズ（MB）

最小最大平均最小最大平均

M01 MR/CT 16 1024 64 .06 4.2 .36 22

M02 超音波 1 1 1 1 108 28 28

M03 心臓 CT 128 4096 2051 .5 5 .5 1031

M04 可視光線 1 64 16 .02 4 1.6 25

M05 マンモグラフィ 4 4 4 13.6 44 26 106

M06 病理 4 4 4 644 2086 1319 5276

合計 2TB の約 240 万の画像をもつ 20,080 の検査のデータセットを、モデルの特性

に合わせて構成しました。このデータセットは、Oracle Multimedia の DICOM 画像

とメタデータ操作機能を使用して、本物の DICOM データの一部を拡張したもの

です。独自のメタデータと多様な画像コンテンツを含む新規 DICOM ファイルを

作成し、各検査に固有の検査インスタンス UID、シリーズ・インスタンス UID、

および患者名を設定しました。患者名の後ろには、米国勢調査局の名前分布が付

加されており、各画像には固有のメディア・ストレージ SOP インスタンスが設定

されています。


7


表 2：2TB の DICOM データセット

タイプ検査数画像数画像割合（%）サイズ（GB）合計サイズ（%）

M01 3000 191360 7.92% 64 3%

M02 4000 4000 0.17% 108 5%

M03 1000 2051328 84.94% 1006 49%

M04 10000 160000 6.63% 248 12%

M05 2000 8000 0.33% 206 10%

M06 80 320 0.01% 412 20%

Total 20080 2415008 2044

操作のモデリング

このベンチマークでは、医用画像アプリケーションで発生する一般的な操作をモ

デリングする 2 つのタスクを定義しました。この 2 つの操作とは、検査取得と検

査挿入です。

検査取得

検査取得の操作では、放射線医師がワークステーションで検査を表示する場合に

発生する操作がモデリングされています。画像一式は、一元管理されているデー

タベースから取得されます。

このワークロードの検査は、特定のモダリティ用のデータベースに保存されてい

る全検査から等確率で任意に選択されたものです。検査を特定すると、その検査

の全画像がデータベースから取得されてクライアントに送信されます。画像の取

得は並列処理されます。全画像を取得すると、その検査のスループットや応答時

間などのパフォーマンス統計が計算されます。

検査挿入

検査挿入の操作では、画像デバイスで新規検査が作成され、画像がリポジトリに

アップロードされる際に発生する操作がモデリングされています。

このワークロードの検査は、特定のモダリティ用に事前選択された検査候補から

等確率で任意に選択されたものです。この検査候補はファイル・システムにあり、

クライアント・マシンからのみアクセスできます。検査が特定されると、新規検

査レコードがデータベースに作成されます。次に、検査の各画像の新規画像レコー

ドが作成され、画像がファイル・システムからデータベースにアップロードされ

ます。画像の挿入は並列処理されます。全画像が挿入されると、その検査のスルー

プットや応答時間などのパフォーマンス統計が計算されます。


8


システム構成

このベンチマークは、2 組のクライアント/サーバー・システムを使用して実行し

ました。単一インスタンス・テストでは、1 組のクライアント/サーバーのみを使

用しました。デュアル・インスタンス・テストでは、2 組のクライアント/サーバー

を使用しました。この項では、これらのテストを実行する際に使用したハードウェ

アとソフトウェアについて説明します。

データベース・サーバー

データベース・サーバー・システムは、2 台の HP BL480c Server Blade を使用して

構成しました。各サーバーで使用したおもなハードウェア・コンポーネントを表

3 に示しています。各サーバーでは、デュアル・ポート 4 ギガビット（Gb）Fibre Channel HBA をストレージ・システムとの接続に使用しました。これにより、各

サーバーのストレージ・システムへのスループットは最大 8Gb となっています。

さらに、各サーバーには、クライアント・マシンとの接続用に 5 つの 1 ギガビッ

ト・イーサネット（GigE）のネットワーク・ポートを搭載しました。これにより、

各サーバーからクライアント・アプリケーションへの 500MB/秒以上のネットワー

ク帯域幅が提供されます。

表 3：データベース・サーバー・システム - 2 台の HP BL480c

コンポーネント説明

CPU 2 基の 3.2 GHz Intel Xeon X5640 クアッドコア・プロセッサ（サーバー

当たりの総コア数 8）

メモリ 48GB

I/O コントローラ QLogic QMH2462 4Gb のデュアル・ポート FC HBA

ネットワーク 5GigE ポート

オペレーティング・システム

Oracle Enterprise Linux 5.1

カーネル・パラメータ /dev/shm 33GB

kernel.shmmax 68719476736

kernel.shmall 4294967296

kernel.sem 500 32000 256 256

net.ipv4.ip.local_port_range 1024 65000

net.core.rmem.default 4194304

net.core.rmem.max 4194304

net.core.wmem.default 4194304

net.core.wmem.max 4194304

データベース Oracle Database 11g Release 1（11.1.0.6）Enterprise Edition


9


オプション Oracle Real Application Clusters のパーティション化

パッチ bug 6277860 bug 6991044

データベース・パラメータ

db_block_size 8192

memory_target 34628173824

db_writer_processes 1

SDU 32768

TDU 32768

SEND_BUF_SIZE 1048576

RECV_BUF_SIZE 1048576

データベース・ストレージ

データベースのストレージには HP StorageWorks EVA 8100 を使用し、Oracle Automatic Storage Management（Oracle ASM）で管理しました。112 個のディスクはす

べて 1 つの EVA ディスク・グループ内に構成し、さらにこのディスク・グループを

8 個の VRaid1 LUN で構成しました。この 8 個の LUN は、すべて 1 つの ASM ディス

ク・グループ内に 8TBのデータベース・ストレージを提供するよう構成しています。

ストレージの冗長性は、VRaid1 を使用して Oracle ASM の外部に確保しました。また、

I/O が全ファイバー・チャネル・リンクに均等に分散されるように、手動パス分散

を採用しました。ストレージ・システムの詳細を表 4 に示します。

表 4：データベース・ストレージ –HP StorageWorks EVA 8100


ディスク・ドライブ 112 台の 146GB FC 15k RPM HDD

キャッシュ 8GB の自動割当て管理（読取り/書込み）

ホスト・インタフェース 8 つの 4Gb FC ポート

ドライブ・インタフェース 8 つの 2Gb FC ポート

クライアント・システム

2 台の HP BL465c ブレード・サーバーをクライアント・システムとして使用して、

テストを進めました。各サーバーには、サーバー・マシンとの接続用に 5 つの 1GigEのネットワーク・ポートを搭載しました。これにより、各クライアント・マシン

にデータベース・システムへの約 500MB/秒のネットワーク帯域幅が提供されます。

クライアント・システムのストレージには、2 基の HP StorageWorks MSA1000 Arrayを使用しました。各アレイには 14.72 GB のドライブが搭載されており、約 2TB の

ストレージを使用することが可能です。このストレージは、検査挿入テストで使

用する DICOM 画像の保存に使用しました。


10


クライアント・システムの詳細を表 5 に示します。

表 5：クライアント・システム - 2 台の HP BL465c


CPU 2 基の 2.8GHz クアッドコア・プロセッサ

クライアント当たりの総コア数 8

メモリ 64GB

I/O コントローラ QLogic QM2462 デュアル・ポート FC HBA

ネットワーク 5GigE ポート

オペレーティング・システム

Oracle Enterprise Linux 5.1

図 1 は、検査取得のアプリケーション実装の概略図です。アプリケーションは、

マルチスレッドの Java プログラムとして実装されています。プライマリ・アプリ

ケーション・コンポーネントは、検査リーダーとなります。各検査リーダーには、

データベースから画像コンテンツをフェッチする際に使用する独立型画像リー

ダーのプールが備わっています。検査リーダーを使用すれば、各検査で画像の並

列読取りが可能です。検査リーダーにより、特定のモダリティ用のデータベース

に保存されている全検査から、検査が等確率で任意に選択されます。検査が特定

されると、その検査の全画像がデータベースから取得されます。複数の検査リー

ダーがインスタンス化されている場合は、複数の検査を並列取得できます。

図 1：検査取得のアプリケーション実装


11


単一インスタンス構成でのパフォーマンス結果

この項では、単一インスタンスのデータベースの検査取得と検査挿入のパフォー

マンス・テストの結果を提示します。単一インスタンスのデータベースには、2万件の検査と、2TB の画像データから成る 240 万の画像が保存されています（表

2 を参照）。この結果を得るため、各モダリティにつき 6 つの検査リーダーをイ

ンスタンス化しました。各モダリティのパフォーマンスは、独立してテストして

います。

使用した主要パフォーマンス・メトリックは 2 種類です。1 つ目のメトリックは、

データベースからの画像取得時やデータベースへの画像書込み時の平均速度の測

定です。測定単位は、1 秒当たりの画像数（画像/秒）を使用します。平均画像サ

イズが小さいモダリティは、画像サイズが大きいモダリティよりも画像速度が速

くなります。2 つ目のメトリックは、取得および挿入操作での平均データ量の測

定です。測定単位は、1 秒当たりのメガバイト数（MB/秒）を使用します。

ただし、これらのメトリックは、システム全体のスループット速度を取得するも

のであり、個々の検査リーダーやライターのプロセスを取得するものではありま

せん。


12


単一インスタンス構成でのモダリティ別検査取得パフォーマンス

図 2 は、単一ノードのデータベース・インスタンスの持続的な画像取得速度を示

しています。このメトリックは、平均画像サイズに大きく影響を受けることに注

意してください。MR/CT（MOD1）、心臓 CT（MOD3）、可視光線（MOD4）は

比較的小さい画像サイズのモダリティのため、速い画像取得速度を達成できます。

超音波（MOD2）、マンモグラフィ（MOD5）、病理（MOD6）は平均画像サイズ

の大きいモダリティのため、このメトリックでは比較的遅い値となっています。

852 画像/秒の平均速度で Oracle Database から 1 時間に取得できる心臓 CT 検査数

は、約 1,497 件でした。

図 2：単一インスタンス構成での検査取得 – スループット（画像/秒）


13


図 3 は、データ量のメトリック（MB/秒）を使用して同じテストを実施した結果

を示しています。1 つのモダリティを除いて、400MB/秒以上の持続速度を達成し

ています。MOD1 は、平均画像サイズが非常に小さい（360KB）モダリティです。

個々の画像を検出して転送を開始するのにかかる時間は、平均画像サイズの大き

いほかのモダリティに比べ、比例的非常に大きいオーバーヘッドとなっています。

画像サイズの大きいモダリティ（MOD5）では、非常に高速のスループット速度

を達成できます。画像が検出されて転送が開始されると、データがデータベース

からクライアントに、ネットワークを飽和させる速度でストリーミングされます。

ここで、病理モダリティ（MOD6）のパフォーマンスが予測していたよりも低い

理由について説明します。このモダリティの各検査は、サイズの大きい 4 つの画

像で構成されています。パフォーマンスが低い理由は、1 検査内の画像サイズに

ばらつきがあるためです。最小画像は 644MB で、最大画像はその 3 倍以上の

2,086MB です。スループット統計は検査レベルで計算され、検査の応答時間は最

後の画像の取得完了時に記録されます。つまり、検査取得パフォーマンスは、1つの大容量画像を取得するパフォーマンスによって制約を受けます。アプリケー

ションでは複数の画像を並列取得できますが、1 つの画像につき 1 つの順次操作

で取得されます。

図 3：単一インスタンス構成での検査取得 – スループット（MB/秒）


14


単一インスタンス構成でのモダリティ別検査挿入パフォーマンス

図 4 は、単一ノードのデータベース・インスタンスの持続的な画像挿入速度を示

しています。このメトリックは、平均画像サイズに大きく影響を受けることに注

意してください。MR/CT（MOD1）、心臓 CT（MOD3）、可視光線（MOD4）は

比較的小さい画像サイズのモダリティのため、速い画像挿入速度を達成できます。

超音波（MOD2）、マンモグラフィ（MOD5）、病理（MOD6）は平均画像サイズ

の大きいモダリティのため、このメトリックでは比較的遅い値となっています。

554 画像/秒の平均速度で Oracle Database に 1 時間で挿入できる新規心臓 CT 検査

数は、約 970 件でした。

図 4：単一インスタンス構成での検査挿入 – スループット（ファイル/秒）


15


図 5 は、データ量のメトリック（MB/秒）を使用して同じテストを実施した結果

を示しています。画像サイズが非常に大きいモダリティで、450MB/秒以上の持続

速度を達成しています。

図 5：単一インスタンス構成での検査挿入 – スループット（MB/秒）


16


デュアル・インスタンス構成でのパフォーマンス結果

2 つ目のサーバーと 2 つ目のクライアント・ノードを追加して、システムを 2 ノー

ド RAC クラスタに拡張します。これでデータベース・サイズは 2 倍になり、アー

カイブの総容量は 40,000 検査、480 万画像（4TB の画像データ）となります。

デュアル・インスタンス構成でのモダリティ別検査取得パフォーマンス

図 6 は、2 ノードのデータベース・システムの持続的な画像取得速度を示してい

ます。1,575 画像/秒の平均速度で Oracle Database から 1 時間に取得できる心臓 CT検査数は、約 2,768 件でした。

図 6：デュアル・インスタンス構成での検査取得 – スループット（ファイル/秒）


17


図 7 は、デュアル・インスタンスの読取り結果をデータ量のスループットで示し

たものです。マンモグラフィ画像（MOD5）の読取りで、1GB/秒以上のスループッ

トを実現しています。

図 7：デュアル・インスタンス構成での検査取得 – スループット（MB/秒）7


18


デュアル・インスタンス構成での検査取得パフォーマンス - 全モダリティを一度に実行

図 8 は、データベースから全モダリティ・タイプの読取りを実行したテスト結果

を示しています。各モダリティの検査リーダーは、各クライアント・マシンでイ

ンスタンス化されています。特定のモダリティのパフォーマンスの調整はおこ

なっていません。

累積スループット・パフォーマンスは 900MB/秒以上、心臓 CT（MOD3）からの

データは 10%以上を達成しています。これは、Oracle Database が複合ワークロー

ドに対して非常に高いパフォーマンスを達成できることを確実に証明しています。

図 8：デュアル・インスタンス構成での検査取得 – スループット（MB/秒）


19


デュアル・インスタンス構成での心臓 CT の同時取得および挿入

最後のテストでは、デュアル・インスタンス・システムで心臓 CT 検査（MOD3）の同時取得および挿入をテストしました。図 9 は画像/秒のパフォーマンスを示し、

図 10 は MB/秒のパフォーマンスを示しています。これらの速度では、1 時間当た

り 1,200 件以上の心臓 CT 検査の読取りと、760 件の新規検査の挿入を同時実行で

きました。

図 9：デュアル・インスタンス構成での検査取得および挿入 – スループット（画像/秒）


20


図 10：デュアル・インスタンス構成での検査取得および挿入 – スループット（MB/秒）


21


付録 - ワークロードの実装

以下に、Oracle Database 11g で Oracle Multimedia と Oracle SecureFiles を使用して、

医用画像の保存時と取得時に最大のパフォーマンスを実現するための簡単なガイ

ドラインを示します。このガイダンスは、データベース・ストレージ、表設計、

アプリケーション設計、ネットワーク構成の 4 つの領域で構成されています。

データベース・ストレージ

• Oracle ASM を使用して、ディスク・ストレージを管理します。

• 自動領域管理のローカル均一エクステントを使用して、画像コンテンツ

を表領域に保存します（64MB）。

• Oracle Partitioning によるストレージ・セグメントの最大容量の管理を検討

してください。このベンチマークでは、1TB の表パーティションを使用

しました。

表設計

DICOM 画像コンテンツは、ORDDicom オブジェクト・データ型を使用して保存さ

れます。これは 2 つの BLOB 属性（SOURCE.LOCALDATA と EXTENSION）と

1 つの XMLType 属性（METADATA）を含む複合データ型です（表 6 を参照）。

挿入および取得時にコンパクトで効率的な保存と高いパフォーマンスを実現する

には、ストレージ・パラメータに注意を払う必要があります。

重要事項として、ORDDicom オブジェクトのロードと初期化に通常使用される 2段階のプロセスを理解しておく必要があります。第 1 段階では、レコードが空の

ORDDicom オブジェクトで作成され、画像データが SOURCE.LOCALDATA BLOB 属性にロードされます。第 2 段階では、表から ORDDicom オブジェクトが

選択され、setProperties()メソッドが起動されてメタデータの抽出とオブジェクト

属性の設定が実行されます。続いて、行が新規 ORDDicom オブジェクトで更新さ

れます。初期化されたオブジェクトはサイズが増加しているため、ページでより

多くの容量が必要です。このベンチマークでは、表 8 の表定義を使用して、メタ

データ抽出とオブジェクト属性の初期化後に、ORDDicom オブジェクトのサイズ

が約 190 バイト増加していることを確認しました。

更新に必要な増加容量を正しく予測することは、PCTFREE 表パラメータの適正値

を設定するためには重要です。このパラメータは、更新時にサイズが増加する行

の容量を確保しておくために、行挿入時のページの空き容量を制御します。ペー

ジに更新行を保存するだけの容量がない場合は、ほかのデータベース・ページに

行を移行する必要があります。その場合は、行連鎖が発生し、パフォーマンスが

大幅に低下します。

表定義でのもう 1 つの重要な項目は、METADATA 属性のストレージ指定です。

これは XMLType の属性で、構造化ストレージを使用して、LOB として保存する

ことも分割して保存することもできます。構造化ストレージではデータがページ

にインライン配置されるため、行の平均長が大幅に増加します。DICOM メタデー

タ・ドキュメントは大容量になる場合があるため、長い行に対応できる大容量の

データベース・ページが必要となります。このベンチマークでは、SecureFile CLOBストレージを使用してメタデータ属性を保存することとし、行内の保存を無効に

してページ容量が小容量のドキュメントで消費されるのを防止しました。また、


22


NOCACHE 属性を指定して、メタデータ・ドキュメントがこのワークロードの一

部として読み取られないようにしました。

表 6：ORDDicom オブジェクト型

属性タイプ

SOP_INSTANCE_UID VARCHAR2(128)

SOP_CLASS_UID VARCHAR2(64)

STUDY_INSTANCE_UID VARCHAR2(64)

SERIES_INSTANCE_UID VARCHAR2(64)

SOURCE ORDSYS.ORDDATASOURCE

LOCALDATA BLOB

SRCTYPE VARCHAR2(4000)

SRCLOCATION VARCHAR2(4000)

SRCNAME VARCHAR2(4000)

UPDATETIME DATE

METADATA SYS.XMLTYPE

CONTENTLENGTH NUMBER

FLAG NUMBER

EXTENSION BLOB

さらに、内部使用の BLOB 型である EXTENSION 属性が、NOCACHE オプション

で SecureFile として保存されます。この属性のサイズは通常 4,000 バイト未満であ

り、行属性で保存が無効に指定されていない限り、ページにインラインで保存さ

れます。

DICOM 画像のデータセットは、マスター・ディテール関係を使用して 2 つの表に

保存されます。各検査につき 1 レコードが、DICOM_IMAGE_GROUP 表に保存さ

れます。また、各画像につき 1 レコードが、DICOM_IMAGE 表に保存されます。

この 2 つの表の DDL を表 7 と表 8 にそれぞれ示しています。

DICOM_IMAGE 表は、I_DATE 列を使用して、1 パーティションにつき 1 週間の

間隔でパーティション化されています。この日付列の値は、各パーティションに

1TB のデータが含まれるように固定されています。


23


表 7：DICOM_IMAGE_GROUP の表定義

create table dicom_image_group ( ig_id integer, --image group id ig_modid integer, --modality id ig_date date, --date of load ig_patient_name varchar2(200), ig_description varchar2(400), constraint ig_id_u unique(ig_id) using index (create unique index ig_id_ix

on dicom_image_group(ig_id) reverse) );

表 8：DICOM_IMAGE の表定義

create table dicom_image ( i_id integer, --image id i_ig_id integer, --image group id i_date date, --load date i_image ordsys.orddicom, --dicom image constraint i_ig_id_u unique(i_ig_id, i_id)

using index (create unique index i_ig_id_ix on dicom_image(i_ig_id, i_id) ) ) )

-- --metadata extraction expands the ORDDicom object

pctfree 60 -- --lob storage lob(i_image.source.localdata) store as SecureFile ( nocache filesystem_like_logging retention none ), -- disable in row storage for the extension -- so that it does not consume page space -- it is usually < 4k in size lob(i_image.extension) store as SecureFile ( nocache disable storage in row ), -- store the metadata as a CLOB, -- disable storage in row

xmltype i_image.metadata store as SecureFile clob ( nocache disable storage in row )

-- --store 1 TB of image data per partition -- partition by range(i_date) ( partition image_04122008 values less than (to_date('04/12/2008', 'MM/DD/YYYY')), partition image_04192008 values less than (to_date('04/19/2008', 'MM/DD/YYYY')), partition image_04262008 values less than (to_date('04/26/2008', 'MM/DD/YYYY')), partition image_05032008 values less than (to_date('05/03/2008', 'MM/DD/YYYY')), partition image_05172008 values less than (to_date('05/17/2008', 'MM/DD/YYYY'))

;


24


アプリケーション設計

• アプリケーションが Java で記述されている場合は、JDBC シン・ドライ

バを使用すると最高のパフォーマンスを実現できます。アプリケーショ

ンが C または C++で記述されている場合は、OCI ドライバを使用しても

良好なパフォーマンスを実現できます。

• アプリケーションが Java で記述されている場合は、java.sql.Blob ク

ラスから getBytes()メソッドと setBytes()メソッドを使用して、

SecureFile の読取り/書込みを実行します。これらのメソッドは JDBC 3.0に導入されており、BLOB への読取り/書込みをもっとも効率的に実行で

きます。

• 読取り/書込みを実行するもう 1 つの方法は、java.io.InputStream

または java.io.OutputStreamの Java ストリーム・クラスのオブジェ

クトを取得してストリーム・クラスの read()メソッドと write()メ

ソッドを使用することです。ただしこの方法では、最高のパフォーマン

スを得ることはできません。

• 大容量の読取り/書込みバッファをデータベースに割り当てます。このベ

ンチマークでは、最大バッファ・サイズ 10MB で、大容量の画像の読取

り/書込みをデータベースで実行しました。

• 使用可能なネットワーク・リンク間でアプリケーション・トラフィック

を分散します。このベンチマークでは、ラウンドロビン方式で 5 つのイー

サネット・リンクに接続を作成しました。このスキームにより、全ネッ

トワーク・リンクへの分散とリンクの最大活用を実現できました。

ネットワーク構成

• ネットワーク切替え時の TCP フロー制御を有効にします。これは、高使

用率のネットワーク・リンクがある環境で一貫したパフォーマンスを確

保するためには不可欠です。

• ジャンボ・フレームの使用を検討してください。大容量パケットを使用

すれば、クライアントとサーバー両方の CPU 使用率を削減して、最大ス

ループットを若干向上できます。このベンチマークでは、MTU 設定を

9000 としました。さらに netperf ツールを使用して、118MB/秒の最大ネッ

トワーク・スループットを測定しました。デフォルトのネットワーク設

定（MTU=1500）では、112MB/秒の最大スループットを測定しました。

謝辞

このベンチマークは、オラクルと Hewlett-Packard、および Intel が共同で実施した

ものです。重要なリソースを提供し、当プロジェクトの完了にご尽力いただいた

HP と Intel のスタッフに感謝の意を表します。

HP ブレード・サーバーと Intel プロセッサを使用した Oracle Database 11g のストレージ・パフォーマンス評価と DICOM 画像コンテンツの取得 2008 年 7 月 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口：電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com Copyright © 2008, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく

変更されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による明示

的保証や法律による黙示的保証を含め、商品性ないし特定目的適合性に関する黙示的保

証および条件などのいかなる保証および条件も提供するものではありません。オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的ま

たは間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的のために

も、電子または印刷を含むいかなる形式や手段によっても再作成または送信することは

できません。 Oracle、JD Edwards、PeopleSoft、および Siebel は、米国 Oracle Corporation および

その子会社、関連会社の登録商標です。そのほかの名称はそれぞれの会社の商標です。

Date post:	09-Sep-2020
Category:	Documents
Upload:	others
View:	8 times
Download:	0 times

HP ブレード・サーバーと Intel Oracle Database 11g DICOM 画...HP...

Documents