各種事例紹介｜CoSort9　事例紹介｜株式会社両備システムズ

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

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する時間だった。