全天X線監視装置MAXI 地上データ処理システムの開発Ⅱ ー世界

全天Ｘ線監視装置 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線毎
まとめて処理
データ量
大
小
データ保存
単位
観測単位
世界初の
光子単位
スキャン単位
2. 研究の目的
• MAXIが突発天体現象を捉えた時に、次の観測（1300sec以内）
までに、これまでにも同様な現象がないかを調べられるような、
過去のデータに対する検索処理速度
が必要である。(Fig.1参照)。
ISS(MAXI
• 約1000個の天体のLight CurveやEnergy
)
Spectrumを毎時間更新していくために、
※1
各天体のデータを3sec以内(1h/1000天体)
に検索できるようにする必要がある。
• 以上2つの条件をクリアするため、用いる
データベースの性能調査、改良を行った。
Fig.1 MAXIの視野
※1. 1時間で約1000個の天体情報を更新していくため、
1h(3,600sec)/1000天体のデータの更新のためには1つの
天体に対して約3sec以内に終わらせる必要がある。
矢印の方向に１周約90分で
走査していく。二つの視野
の角度は約90°である。
3. 試験環境
・RDBMS : postgreSQL(ver.8.0.6)
・クライアントからのデータ取得方法
→ECPG(C言語での埋め込みSQL)
・検索領域の指定方法
delta
→正方領域：天球座標上の角度を表す(alpha,delta)を
用いて決定する。
→円領域
：先に、正方領域である程度の範囲に絞って
alpha
から、円領域での検索を行う(Fig.2 参照)。
この方法によってindexを有効に使用し、
Fig. 2 円領域の取り方。
正方領域と同じ検索時間が実現できた(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
4. 試験結果
4.1 レコード数1e7(約1日分)と1e8(約10日分)の比較
以下に示す通り、検索の結果得られるデータ量が多くなると必ずしも
Indexが効果的であるとは言えなくなる。
1゜×1゜
3゜×3゜
5゜×5゜
取る領域の範
囲が大きいと
Indexを作成し
ない時より余計
に検索時間が
かかってしまう。
1000
検索時間[sec]
100
[ｲﾍﾞﾝﾄ数1e7]正方領域
[indexなし]
10
[ｲﾍﾞﾝﾄ数1e7]正方領域
[indexあり]
[ｲﾍﾞﾝﾄ数1e8]正方領域
[indexなし]
1
0.00001
[ｲﾍﾞﾝﾄ数1e8]正方領域
[indexあり]
0.0001
0.001
天球全体のうち正方領域で絞った割合[ΔΩ/Ω]
Fig.3 ﾚｺｰﾄﾞ数1e7、1e8の時の、正方領域で絞った割合－検索時間の比較図
4.2 Cluster Indexによる検索速度向上
検索速度を向上させる手段としてテーブルのCluster化がある。これは、指定したIndex
の情報を元にしてテーブル本体を並べ替える手法である。Cluster化を施すことで以下
のように、検索時間が大幅に改善された。
1゜×1゜
1000
検索時間[sec]
100
10
1
0.00001
3゜×3゜
5゜×5゜
1e8ｲﾍﾞﾝﾄ正方
領域 Indexなし
Cluster Index
により、
検索時間を
桁違いに
早くする
ことができた。
1e8ｲﾍﾞﾝﾄ正方
領域 Indexあり
1e8ｲﾍﾞﾝﾄ正方
領域 Cluster
Index使用
0.0001
0.001
天球全体のうち正方領域で絞った割合[ΔΩ/Ω]
Fig.4 Cluster Indexの有無による検索時間の比較（データ量は1e8[ｲﾍﾞﾝﾄ数]）
4.3 複合テーブルを対象とした検索時間の調査
・天体の位置情報から得られたDPTCを元にして、同じDPTCの他のテーブルの
該当するデータ(HK等)を同時に検索する必要がある。
検索方法は以下の2種類がある。
① 検索時のSQL文で結合条件などを提示する。
SQL → SELECT * FROM (位置情報を保有するテーブル)
JOIN (他の情報を保有するテーブル) USING(DPTC )
WHERE (位置情報を保有するテーブルに対する天体の
位置情報での検索);
位置情報
の入った
テーブル
② あらかじめ、あるテーブルとテーブルの結合条件で
設定したビューを用意する。
位置情報を
元に検索
→ CREATE VIEW (作成するビューの名前) AS (結合条件);
結合条件に従う
データの検索
SQL発行
HKデータ
の入った
テーブル
SQL
検索結果
のoutput
クライアント
①②どちらの方法でも、単一テーブルからの
検索に比べて10倍以上の時間がかかってしまう。
Fig.5 複合テーブルからの
検索のイメージ
頻繁に使用するデータは、位置情報と同じテーブルに入れておくことが望ましい。
4.4 RAID50を用いたサーバーでの試験結果(1e6～1e9イベント)
RAIDサーバーを用いた試験結果を以下の図にまとめる。正方領域、
円領域ともほぼ同じ検索時間を示しているため、正方領域のみ示す。
1day
10days
100days
10000
正方領域[indexなし]
検索時間[sec]
1000
正方領域[indexあり]
100
正方領域[クラスタ
index]
正方領域[indexなし]
10
正方領域[indexあり]
1
1.00E+06
1.00E+07
1.00E+08
1.00E+09
正方領域[クラスタ
index]
正方領域[indexなし]
正方領域[indexあり]
0.1
正方領域[クラスタ
index]
0.01
データ量[ｲﾍﾞﾝﾄ数]
Fig.6 RAID50を用いたサーバーでの検索試験の結果
(青：1゜×1゜緑：3゜×3゜紫：5゜×5゜)
Fig.7 本研究で用いた
RAIDサーバー
4.5 RAIDサーバーと汎用サーバーとの比較
これです
汎用サーバーからRAIDサーバーに変えたことで、検索時間が全体的に
約半分程度に短縮された。(下図参照青：汎用サーバー赤：RAIDサーバー)
1day
10days
100days
10000
検索時間[sec]
1000
Indexのみ
の検索
100
10
1
1.00E+06
1e6ｲﾍﾞﾝﾄ
1.00E+07
1e7ｲﾍﾞﾝﾄ
1.00E+08
1e8ｲﾍﾞﾝﾄ
1.00E+09
1e9ｲﾍﾞﾝﾄ
0.1
0.01
Cluster Indexを
用いた検索
データ量[イベント数]
Fig.8 3゜×3゜のRAIDシステムと前回まで用いていたサーバーとの比較
Fig.9 本研究で用いた
汎用サーバー
Indexの有無に限らず、検索量の増加に伴う、ハードディスクのシークタイム
の増加が検索時間の増加に影響を与えていると考えられる。
4.6 RAIDサーバーでの、検索時間短縮のための工夫
目標とする検索時間達成のための手段として以下に示す2通りの検索方法を
試験した。
•
元のデータを領域毎にテーブルを分割する
[1e9イベント数のデータを100分割したうちの一つにアクセスした場合]
• 元のデータを1日分のイベント数まで減らした後に検索する
[1e9イベント数のデータを1e7まで減らした場合]
Table.2
検索範囲3゜×3゜
領域の取り方
通常の検索
単位は[sec]
分割ﾃｰﾌﾞﾙへの検索
dptcを限定してからの検索
Index
Cluster Index
Index
Cluster Index
Index
Cluster Index
正方領域
1996.817
35.095
46.585
18.628
205.027
1870.29
円領域
1952.461
35.452
738.483
20.015
202.83
1877.213
ここだけ、イレギュラ
ーな検索時間となっ
たため、現在調査中。
データを1日分まで減らしてから検索する方法は、
最初の1回の検索は200sec前後かかるが、その後は
1回目で作成した別テーブルに直接検索するように
すれば、1日分のテーブルからの検索と同じような
早さを得られる。ただし、Cluster Indexでは逆効果。
公開データの更新作業では使える見込みあり！
５．まとめと考察
• RAIDシステムを用いることで、汎用サーバーと比較して各検索条件で約半分の
検索時間になった。
• 複数テーブルへの検索は、検索時間が10倍以上に増加してしまう。
→ 位置情報とセットで得る機会の多いデータ（Light Curve作成に必要なもの
等）は同じテーブルに保存するようにする。
• Cluster IndexはIndexのみの場合に対して10分の1以下に検索時間を短縮できる
が更新中のデータに対しては使用できない。
→ 更新中のテーブルと過去のある期間分の履歴データとを分ける必要がある。
（どのくらいの期間でテーブルを分けるかは要検討）。
ここからは更新中のテーブルと過去の履歴とを分けるという前提での話
• 約1000個の天体のLight Curve等の毎時間の更新のために必要な検索時間の
目安となっている(3sec以内)は、更新中のテーブルから最新の1日分のデータを
丸ごと検索して別テーブルを作成し、その中からそれぞれの天体の情報を検索
していく方法で、この目標は達成できる見通しが立った。
• 突発天体現象を捉えた時に次の観測までに過去の履歴を調べるための検索時
間の目安となっている(1300sec以内)は、Cluster Indexが作成されたテーブルで
あれば、問題なく検索できるレベルに達している。

Download Report