全天Ｘ線監視装置 MAXI 地上データ処理システムの開発 Ⅱ ー 世界初のX線光子データベースの実現に向けた高速データ処理技術 ー 〇小笠原 直進　高橋 知義　福田 知枝　 根来 均（日本大学）

１．概要 　全天X線監視装置MAXIは、国際宇宙ステーションに2008年から搭載予定のX線観測装置である。そのMAXIの全データ量は、HKデータ等も含め、2年間のミッションで約0.1T(テラ)レコード、約1TBにも達し、通常の検索方法だと、データを走査するだけで数時間を要する。しかし、X線新星などの突発天体の過去の強度履歴情報や、データの公開に向けた各天体毎のデータを取得するためには、毎日の更新で1天体につき約100sec以内、毎時間の更新で約3sec以内の検索速度が必要である。そこで、地上データ処理システムでは、任意の天球領域のデータを素早く検索できるように、取得したデータをリレーショナルデータベースにX線光子毎に格納する(Negoro et al.2003)。このデータベースへの検索速度を向上させるために、ハード面や検索方法の面で様々な改良を　行った。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

・MAXIとこれまでの観測衛星の違いについて以下にまとめたものを示す。 Table.1 MAXIと他観測衛星との比較 通常のPointing 観測衛星 MAXI これまでの 全天観測装置 視野方向 固定 常時変化 X線の飛来 方向の決定 各X線毎 まとめて処理 データ量 大 小 データ保存 単位 観測単位 光子単位 スキャン単位 世界初の

矢印の方向に１周約90分で走査していく。二つの視野の角度は約90°である。 2. 研究の目的 MAXIが突発天体現象を捉えた時に、次の観測（1300sec以内）までに、これまでにも同様な現象がないかを調べられるような、過去のデータに対する検索処理速度 　　が必要である。(Fig.1参照)。 約1000個の天体のLight CurveやEnergy 　　Spectrumを毎時間更新していくために、 　　各天体のデータを3sec以内(1h/1000天体) 　　に検索できるようにする必要がある。 以上2つの条件をクリアするため、用いる 　　データベースの性能調査、改良を行った。 ISS(MAXI) ※1 Fig.1 MAXIの視野 ※1. 1時間で約1000個の天体情報を更新していくため、 1h(3,600sec)/1000天体のデータの更新のためには1つの 天体に対して約3sec以内に終わらせる必要がある。 矢印の方向に１周約90分で走査していく。二つの視野の角度は約90°である。

[先に、水色の正方領域の 箇所を上の図のように絞り、 その中で円領域（赤い領域） を検索する。] 3. 試験環境 ・RDBMS　: postgreSQL(ver.8.0.6) ・クライアントからのデータ取得方法 　　→ECPG(C言語での埋め込みSQL)　 ・検索領域の指定方法 　　→正方領域　：　天球座標上の角度を表す(alpha,delta)を 　　　　　　　　　　　　用いて決定する。 　　→円領域 ：　先に、正方領域である程度の範囲に絞って 　　　　　　　　　　　　から、円領域での検索を行う(Fig.2 参照)。 　　　　　　　　　　　　この方法によってindexを有効に使用し、 　　　　　　　　　　　　正方領域と同じ検索時間が実現できた(05秋)。 ・使用機器(PC)スペック 　①汎用サーバーPC CPU：インテル®Xeon™デュアルプロセッサ3.06GHz メモリ：1GB(256MB×4)DDR-SDRAM PC2100 40MHz ECC 　　 ハードディスク：120GB Ultra ATA-100 7,200回転　HDD 　②RAID50サーバー(Xserve G5 サーバモデルM9745J/A) CPU：デュアル2.3GHz PowerPC G5 　　メモリ：1GB PC3200 DDR(400MHz) ECC ハードディスク：ストレージ容量→7TB(使用可能領域：約6TB)　Ultra ATA 7200rpm delta alpha Fig. 2 円領域の取り方。 [先に、水色の正方領域の　　　箇所を上の図のように絞り、　その中で円領域（赤い領域）　　を検索する。]

取る領域の範囲が大きいとIndexを作成しない時より余計に検索時間がかかってしまう。 4. 試験結果 4.1　レコード数1e7(約1日分)と1e8(約10日分)の比較 以下に示す通り、検索の結果得られるデータ量が多くなると必ずしもIndexが効果的であるとは言えなくなる。 1゜×1゜ 3゜×3゜ 5゜×5゜ 取る領域の範囲が大きいとIndexを作成しない時より余計に検索時間がかかってしまう。 Fig.3 ﾚｺｰﾄﾞ数1e7、1e8の時の、正方領域で絞った割合－検索時間の比較図

1e8ｲﾍﾞﾝﾄ 正方領域 Cluster Index使用 検索速度を向上させる手段としてテーブルのCluster化がある。これは、指定したIndexの情報を元にしてテーブル本体を並べ替える手法である。Cluster化を施すことで以下のように、検索時間が大幅に改善された。 1゜×1゜ 3゜×3゜ 5゜×5゜ Cluster Index により、 検索時間を 桁違いに 早くする ことができた。 1e8ｲﾍﾞﾝﾄ 正方領域 Indexなし 1e8ｲﾍﾞﾝﾄ 正方領域 Indexあり 1e8ｲﾍﾞﾝﾄ 正方領域 Cluster Index使用 Fig.4 Cluster Indexの有無による検索時間の比較　（データ量は1e8[ｲﾍﾞﾝﾄ数]）

4.3　複合テーブルを対象とした検索時間の調査 ・　天体の位置情報から得られたDPTCを元にして、同じDPTCの他のテーブルの　　　該当するデータ(HK等)を同時に検索する必要がある。　　　　　　　　　　　　　　　　　　検索方法は以下の2種類がある。 ①　検索時のSQL文で結合条件などを提示する。　　　　　　　　　　　　　　　　　　　　　SQL　→　SELECT * FROM (位置情報を保有するテーブル)　　　　　　　　　　　　　　　　　　　　　　　 　　　　　　　JOIN (他の情報を保有するテーブル) USING(DPTC ) 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　WHERE (位置情報を保有するテーブルに対する天体の　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　位置情報での検索); ②　あらかじめ、あるテーブルとテーブルの結合条件で　　　　　　　　　　　　　　　　　　　　設定したビューを用意する。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　SQL　→　CREATE VIEW (作成するビューの名前) AS (結合条件); 結合条件に従う　データの検索 位置情報 の入った テーブル HKデータ の入った テーブル 位置情報を元に検索 検索結果のoutput SQL発行 クライアント ①②どちらの方法でも、単一テーブルからの 検索に比べて10倍以上の時間がかかってしまう。 Fig.5 複合テーブルからの検索のイメージ 頻繁に使用するデータは、位置情報と同じテーブルに入れておくことが望ましい。

Fig.6 RAID50を用いたサーバーでの検索試験の結果 (青：1゜×1゜ 緑：3゜×3゜ 紫：5゜×5゜) 4.4　RAID50を用いたサーバーでの試験結果(1e6～1e9イベント) RAIDサーバーを用いた試験結果を以下の図にまとめる。正方領域、　円領域ともほぼ同じ検索時間を示しているため、正方領域のみ示す。 1day 10days 100days Fig.6 　RAID50を用いたサーバーでの検索試験の結果 (青：1゜×1゜ 緑：3゜×3゜ 紫：5゜×5゜) Fig.7 本研究で用いたRAIDサーバー

4.5　RAIDサーバーと汎用サーバーとの比較 これです 汎用サーバーからRAIDサーバーに変えたことで、検索時間が全体的に約半分程度に短縮された。(下図参照　青：汎用サーバー　赤：RAIDサーバー) 1day 10days 100days Indexのみの検索 1e6ｲﾍﾞﾝﾄ 1e7ｲﾍﾞﾝﾄ 1e8ｲﾍﾞﾝﾄ 1e9ｲﾍﾞﾝﾄ Cluster Indexを用いた検索 Fig.9 本研究で用いた汎用サーバー Fig.8 3゜×3゜のRAIDシステムと前回まで用いていたサーバーとの比較 Indexの有無に限らず、検索量の増加に伴う、ハードディスクのシークタイム の増加が検索時間の増加に影響を与えていると考えられる。

4.6 RAIDサーバーでの、検索時間短縮のための工夫 目標とする検索時間達成のための手段として以下に示す2通りの検索方法を試験した。 元のデータを領域毎にテーブルを分割する 　　[1e9イベント数のデータを100分割したうちの一つにアクセスした場合] 元のデータを1日分のイベント数まで減らした後に検索する 　　[1e9イベント数のデータを1e7まで減らした場合] Table.2 ここだけ、イレギュラ ーな検索時間となったため、現在調査中。 　データを1日分まで減らしてから検索する方法は、 　最初の1回の検索は200sec前後かかるが、その後は 　1回目で作成した別テーブルに直接検索するように 　すれば、1日分のテーブルからの検索と同じような 　早さを得られる。ただし、Cluster Indexでは逆効果。 　公開データの更新作業では使える見込みあり！

５．まとめと考察 RAIDシステムを用いることで、汎用サーバーと比較して各検索条件で約半分の検索時間になった。 複数テーブルへの検索は、検索時間が10倍以上に増加してしまう。 　　→　位置情報とセットで得る機会の多いデータ（Light Curve作成に必要なもの等）　　は同じテーブルに保存するようにする。 Cluster IndexはIndexのみの場合に対して10分の1以下に検索時間を短縮できるが更新中のデータに対しては使用できない。 　　→　更新中のテーブルと過去のある期間分の履歴データとを分ける必要がある。　　（どのくらいの期間でテーブルを分けるかは要検討）。 　　　　ここからは更新中のテーブルと過去の履歴とを分けるという前提での話 約1000個の天体のLight Curve等の毎時間の更新のために必要な検索時間の目安となっている(3sec以内)は、更新中のテーブルから最新の1日分のデータを丸ごと検索して別テーブルを作成し、その中からそれぞれの天体の情報を検索していく方法で、この目標は達成できる見通しが立った。 突発天体現象を捉えた時に次の観測までに過去の履歴を調べるための検索時間の目安となっている(1300sec以内)は、Cluster Indexが作成されたテーブルであれば、問題なく検索できるレベルに達している。