事例のご紹介|CoSort

パフォーマンスに関するソリューション事例

CoSort9 さまざまな機能におけるパフォーマンス事例のご紹介

CoSortの開発元 IRI社のWebサイトにあるベンチマークに関する情報をまとめてご紹介します。 いくつかの機能の処理時間性能についての事例紹介です。参考情報としてご参照ください。 正確な時間計測による実測値は、H/Wやチューニングによって大きく結果が変動します。 実際、一時的に使用する作業領域と処理結果を格納する出力先で、 物理的に異なるハードディスクをそれぞれ別個に用意したり、 スレッド数、メモリサイズ、ブロックサイズなどを変えてチューニングしたりすると、 実行する処理時間が変わってきます。 したがって精度の高い実測値が必要な場合は、本番のターゲットマシンや本番環境に近いテストマシンなどで、 評価版を使ったベンチマークテストの実施をおすすめします。

ご紹介する事例は次のとおりです。

  • ソート/マージ
  • CoSort(SortCL) プロセス 対 Oracleプロシージャ
  • もうひとつのOracleソリューション事例
  • LDIFの変換処理事例 The Comcast DEMI
  • MF COBOL ソート機能の高速化

CoSort9におけるソート/マージ機能の速度向上

従来バージョンとの比較

IBM p570, 2.1GHz, 6CPUのうち2個だけ使用

入力サイズ

従来Ver.

v9.1

約1GB

40秒

20秒

約2GB

1分20秒

30秒

約6GB

5分10秒

2分50秒

客観的にみてCoSort9では次のことが言えます

  • 1. 同じリソースを使ってパフォーマンスを2倍向上することが可能。
  • 2. マージにおいてプレソートのジョブスクリプトは不要になる。
  • 3. 詳細行とサマリ行の性能は改善される。
  • 4. パフォーマンス向上には次の要素が影響する。
  • データタイプ、ボリューム、レイアウト
  • ソートキーの数と位置
  • 実行中の他のアプリケーション
  • システムとCoSortのチューニング
  • CPU数、コア数、メモリ容量、ディスクサイズ(作業領域)
  • ジョブスクリプト内の他の関数

下記の測定結果では、上記のパフォーマンス向上のための要素は、 あまり考慮されていませんが、参考情報としてご参照ください。

CoSort Version 8

H/W

入力サイズ

処理時間

SunFire15K 6CPU

2.4GB

39秒

IBM p690 4CPU

1GB

12秒

Linux Itanium 4CPU

5GB

6分以下

HP N440 8CPU

50GB

49分

Compaq GS140/8

1.8GB

67秒

CoSort Version 7

H/W

入力サイズ

処理時間

AlphaServer 4100 300Mhz 4CPU

1GB

58秒

IBM (Sequent) Numa Q-2000 4CPU

272GB

114分

P200/2 WindowsNT

2 keys, 19MB

2秒

Sun UE3000

23 keys, 5.2GB

20分

CoSort(SortCL) プロセス 対 Oracleプロシージャ

Oracleプロシージャ利用のソリューションを10倍改善

目的

ある電話会社のOracleベースのデータウェアハウスで、 現在使用されているSQLプロシージャのクエリ・ロジックによる通話履歴の詳細レポート (CDR: call detail report)の処理時間を減少すること。

SQLメソッド

Oracleの環境では同時にDBと交信する3つのCDRファイルを処理するのに、 およそ3時間かかった。 31ファイルずつ3地域で、処理すべき圧縮された入力ファイルは全部で93ファイルあった。 通話履歴ファイルは、地域ごとの電話番号の発信履歴とステータスの情報を保持するOracleテーブルに関連付けられている。 SQLプロシージャは各通話履歴ファイルを調べて、呼び出し方式(たとえばG-GSM)により分類されたフィールドを出力していた。 出力フィールドには、電話番号と呼び出しステータス(PRE, POS, EPR, ERR)などがあり、 適切にフィルタリングされた出力テーブルに情報がまとめられていた。 この処理には、1,188行のSQLプログラムが必要で、処理終了までに93時間かかっていた。

CoSortメソッド

ファイルベースのCoSortソリューションでは、 上記処理と等価となるようにSortCLジョブスクリプトを作成して、必要なスクリプトは6個になった。 各処理では15~16個の通話履歴ファイルを並行処理し、マージして9ファイルの結果にまとめた。 最初のステップでは、さまざまな電話呼び出し方式でソートして、地域ごとにその出力をセグメント化した。 マージは各ステータス・カテゴリごとにレコード数を検出するのに使われ、 すべての出力は上記と同じ結果にするため、さらにマージした。 この処理を実現するのにSortCLのステップで500行が必要で、処理は9時間で終了した。 処理時間は約90%減少した。

電話履歴のボリューム

地域1: 17GB弱, 8400万レコード弱
地域2: 23GB弱, 1億1800万レコード弱
地域3: 29GB強, 1億4100万レコード弱

実行環境

CoSort v8.2.1, Oracle r8.1.7, Alpha Server GS320 Tru64 5.1A 4CPU, メモリ4GB

もうひとつのOracleソリューション事例

FACTはOracleおよびDB2のアンロードツールです。

2004年にia64 HP rx5670 サーバー、1GHz Itanium2 4CPU メモリ32GB 上で、 Oracle 9i のSQL*Plusにより1GBのテーブルを結合するのに48分かかった。
CoSortのFast Extract (FACT) v1 for HP-UXで同じテーブルをアンロードして、 これらをパイプ処理でフラットなストリームとしてCoSort V8のSortCLツールでソートとマージを実行して、 その結果もパイプ処理でSQL*Loaderに渡して同じ結合テーブルを作成するのに18分で処理できた。 (約1/3に処理時間を短縮)
2007年には、HP t5500 Intel Core Duo メモリ2GB 上で、 Oracle 10g の SQL*Plus による1GB (2500万行)のテーブルを新規作成するのに49分かかった。
Windows版 FACT v2 のアンロードの結果をCoSort V9 のSortCLツールにパイプ処理で渡して、 並行処理でプレソートしたものをダイレクトパスでロード処理をした。 上記と同じソートされたテーブルを7分で新規作成することができた。(処理時間は1/7に短縮)

LDIFの変換処理事例 The Comcast DEMI

The Comcast Data Engineering and Management Integration (DEMI)

H/W環境
SunFire 4800
8 x 1200MHz CPUs
16 GB RAM
64-bit Solaris 9

「ザ コムキャスト データ エンジニアリング アンド マネージメント インテグレーション (DEMI) の組織内で、 我々の仕事は10テラバイトのDAP (ディレクトリ アクセス プロトコル)のデータを毎日、 ビジネス基準の情報リソースに加工して他の部署に配布することです。 実際、CoSortなしではこれをうまくやり遂げることはできなかったでしょう。 正確にしかも、迅速に数十億行のDAPデータを処理して、 この情報を我々の持つ他のデータウェアハウスと接続して結合したり、分析したりすることを可能にしてくれます。 これほどの高速性と柔軟性をもたらすツールで、 これほど大容量のフラットファイルLDIFレコードを処理して変換できるツールは他にはありません。 とても有能なCoSortチームが直接我々と一緒に作業して、CoSortモジュールの開発と迅速な改良をしてくれました。 結果的に、彼らはアメリカ最大のケーブル事業会社と長期にわたる顧客関係を築いたのと同時に、 大規模で(50TB)さらに増大するデータウェアハウスを開発したというわけです。」
開発に要した時間は30分以下でCoSort SortCL のデータレイアウトとジョブスクリプトの作成と、 さらにunzip、処理(CoSort)、ロード(SQLLDR)を実行するKSHスクリプトの作成までできた。
CoSortを使ったデータ処理は、Perlで2~5時間かかっていたものが約15分に短縮された。 (1000万の加入者と1000万の機器レコードの処理) データセットの処理でもっとも時間を費やしたのは、実際には大きなデータファイルをunzipする時間だった。

MF COBOL ソート機能の高速化

MF COBOLのソート機能の置き換え事例

2007年10月
4GB以下のキーが4つの可変長レコード
HW: IBM p5 570, 2CPU AIX 5.3 (64-bit)
MF COBOL4 (Workbench) でファイルをソートすると 約50分
CoSort v9 で同じファイルをソートすると、3分12秒

トップに戻る