Go to Qiita Advent Calendar 2024 Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@shinyama(Shin Yama)

Cognos Analytics アップロードデータをデータベースに保管する(12.0.2～)

Posted at

概要

Cognos Analytics 12.0.2からExcelやCSV等のアップロードデータファイルをDb2データベースに保管可能となりました。
アップロードデータ参照時にCognosノードにかかっていた負荷が、DBノードに任せれるimage.png
事になるのがメリットです。
実際に色々と触って検証してみて、いくつか知っておくべきポイントがわかりましたので共有します。

参考情報

Db2 を使用して、アップロードされたファイルおよびデータ・セットにデータを保管する
https://www.ibm.com/docs/en/cognos-analytics/12.0.0?topic=administration-using-db2-store-data-in-uploaded-files-data-sets

セットアップ手順

LinuxノードでDB作成
保管するDb2ノードはWindows OSはサポートされていません。アップロード時に以下のようなエラーとなります。
UnixかLinuxノードをご選択ください。
image.png

今回はRedhatノードで試してみました。
DBはContent Storeと共用はNGで、カラムナー型のDBを使用する必要があります。
https://www.ibm.com/docs/en/db2/11.5?topic=to-creating-setting-up-your-database-configuration-analytic-workloads
https://www.ibm.com/docs/en/db2/11.5?topic=organization-enabling-parallel-processing-column-organized-tables

db2 "CREATE DATABASE DB2COL ON /mnt/db2path USING CODESET UTF-8 TERRITORY JP COLLATE USING IDENTITY PAGESIZE 32 K"

インスタンス構成パラメーター変更

db2 update dbm cfg using INTRA_PARALLEL YES
db2stop
db2start

データベース構成パラメーター変更

db2 update db cfg using dft_table_org COLUMN
db2 update db cfg using dft_degree ANY
db2 update db cfg using dft_extent_sz 4
db2 update db cfg using sheapthres_shr 32768
db2 update db cfg using sortheap 1638
db2 update db cfg using auto_reorg ON
db2 ALTER THRESHOLD SYSDEFAULTCONCURRENT ENABLE

データ・サーバー接続作成(データ・セット保管)
image.png

名前を入力し、IBM Db2を選択し次へ
image.png

URLを記載し次へ
image.png

サインオンを追加し接続のテスト
この時、接続に使用するユーザーは（Create tables (CREATEIN), Drop tables (DROPIN), INSERT (INSERTIN) and query (SELECTIN) )という強い権限が必要です。
image.png

問題なければ次へ
image.png

作成する
image.png

以下のような表示となります
image.png

TestData01.xlsxをアップロードしてみます。
image.png

DBにテーブルが自動的に作成されています
image.png

TestData02.xlsxをアップロード
image.png

2個目のテーブルが作成されました。
image.png

基本はこのような動作になります。

ポイント
Db2にデータ保管した場圧縮されるものの、ファイルとしてCognosサーバー上に保管するこれまでのやり方(Parquet)よりやや圧縮効率が良くないようなので、Db2側にはそれも考慮して表スペース領域用意しましょう。
image.png

Export/Importで持ち運べるか実験

チームコンテンツにデータエントリーを移動
image.png

ケース1：データアップロードエントリーのあるフォルダのみExport/Import
Export。該当のフォルダだけをエクスポート。「アップロードしたデータを含める」をチェック。
image.png

ここはチェックなし
image.png

StoreDataフォルダを削除
image.png

テーブルは消えない
image.png

※ポータルでアップロードデータのエントリー消すと、後からクリーナースレッドが発動してDB上のテーブルを削除してくれる。
デフォルト15分間隔だが、Query Serviceの詳細設定の以下のパラメーターで変更可能

qs.dbdatasets.orphanedTablesCleanupInterval

DBごと再作成

db2 drop db DB2COL
db2 "CREATE DATABASE DB2COL ON /mnt/db2path USING CODESET UTF-8 TERRITORY JP COLLATE USING IDENTITY PAGESIZE 32 K"
以下、前述の手順と同じ。

インポート
image.png

以下のチェック
image.png

データアップロードエントリーが復旧
image.png

テーブルも自動作成される
image.png

中身も問題なく見れる
image.png

ケース2：データ・サーバー接続も含めてExport/Import
同様にExport操作
image.png

ここで「データ・ソースと接続を含める」をチェック
image.png

StoreDataフォルダを削除

データサーバー接続を削除
image.png

DBごと再作成

インポート
image.png

ここをチェック
image.png

アップロードデータが復旧
image.png

データサーバー接続も復旧
image.png

テーブルも自動作成
image.png

中身のデータも問題なし
image.png

ケース3：Content Store全体のExport/Import
ExportでContent Store全体
image.png

StoreDataフォルダを削除

データサーバー接続削除

DB再作成

インポート
image.png

アップロードデータ復旧
image.png

データ・サーバー接続復旧
image.png

テーブルも自動作成

中身のデータ参照も問題なし
image.png

DB側での処理について

サポートされるDB製品は以下4つ

ORACLE
Db2 LUW ※Db2 Z、Db2 I、Big SQLは接続エラーとなる
SQL Server
Informix

Compute Serviceを使ってクエリーが発行される。
それによりワークロードはCognosサーバーの負荷は小さくなり、DBノードに任せる事ができるのがメリット。
https://www.ibm.com/docs/en/cognos-analytics/12.0.0?topic=sets-configuring-compute-service

Content Managerのデフォルトサイズ制限(2GB)は適用されなくなり、DB製品側のサイズ制限が適用される事となる。
BLOBタイプ列に保管される。
https://www.ibm.com/docs/en/cognos-analytics/12.0.0?topic=SSEP7J_12.0.0/com.ibm.swg.ba.cognos.ca_new.doc/c_ca_nf_11_2_4_default_max_size.htm

Row size(列の合計長)32Kリミットに注意。
https://www.ibm.com/docs/en/db2/11.5?topic=sql-xml-limits
image.png

レポート上でフィルターした場合、フィルターがかかったSQLがDBに投げられるのか検証
FMパッケージとCSVを結合したデータモジュールを作成
image.png

CSVの製品ラインにフィルターをかけたレポートを実行。
保管DB側にwhere句の効いたSQLが投げられているので、全量とって来てしまうという事は無さそう。
image.png

バックアップ運用について

Export/Importで移行可能なのは便利だが、逆に言うとExport/Importが長時間化するので、バックアップはContent Storeと保管DBのDBバックアップ取得が良いのだろうかと考え検証してみた。
Content Storeと保管DBのリストアで回復可能だろうか

Content Store バックアップ
image.png

保管DBバックアップ

$ db2 backup db db2col to .

フォルダ削除
image.png

テーブルが削除されていることを確認。15分くらい待つと自動削除された。
image.png

Cognos停止
image.png

Content Store リストア
image.png

保管DBリストア

$ db2 restore db DB2COL from . 
SQL2539W  The specified name of the backup image to restore is the same as the name of the target database.  Restoring to an existing database that is the same as the backup image database will cause the current database to be overwritten by the backup version.
Do you want to continue ? (y/n) y
DB20000I  The RESTORE DATABASE command completed successfully.

Cognos起動
image.png

データも復活
image.png

レポートも実行可能
DBのバックアップを取得しておけば、復旧できる事が確認できた。
image.png

その他知っておくべき事

保管DBを複数使用した場合は、実行時に選択する事は不可でエラーになるので、各ユーザーがデータ・サーバーエントリー1個だけの権限を持つように権限設定をする。
データサーバーのプロパティーから権限設定。
image.png

データが保管DBにあるか、ファイルとして保存されているかは、プロパティからわかる
image.png

「データの場所」がファイルだと「Content Manager」になる。
image.png

結論

データアップロードのDBへの保管は、レポート上のフィルターのSQLのWhere句への付与もありパフォーマンス面での懸念なく、Cognosサーバー上からDBサーバーに負荷をオフロードできるメリットがある。
データの列長の合計など、DB側の制限を超えるアップロードデータを使用しないのであれば、DB側への保管機能は使用するのが良いかと思います。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?