  によるデータアフィニティを考慮した
分散並列処理の提案と実装
菱沼 直子Ý

竹房あつ子ÝÝ

中田秀基ÝÝ

小口正人Ý

お茶の水女子大学 〒   東京都文京区大塚  
産業技術総合研究所 〒  茨城県つくば市梅園                  

あらまし クラウド技術の普及により，個人が生み出す情報が大量にネットワーク上に保存されるようになり，大量のデータを高速に処理することが必要となっている．そこで，分散環境で一貫性の制限を緩和して処理性能を重視する分散    と呼ばれる  型データベース管理システムが注目され始めた．分散  を用いると，  では管理が困難な規模の大容量データを分散環境で管理することができる．管理されている大容量データを効率よく活用するためには，対象となるデータに対して複数計算機を利用して並列処理を行う必要がある．しかしながら，分散  からデータを取り出した後に再度データを複数計算機に分散させて並列処理を行うと，データの転送オーバヘッドが非常に大きくなってしまう．本研究では分散  の実装のひとつである   !""#$ に着目し，データアフィニティを考慮して大容量データをより高速に処理するための手法を提案する．本稿では，!""#$

上に分散して保存された異なる値に対し，事前に指定された処理を値が格納されている計算機上で並列に実行できる機能を実装した．性能評価を行い，本提案手法は !""#$ を通常使用した際よりも処理が高速に行えることを示す．

キーワード 分散並列処理，，分散 ，  !""#$，通信データ量   Æ   Ý*  

             ÝÝ    ÝÝ     Ý  ! " # $   %$ &$   '()(*+   (#  + ,   & $ -(+,&.
  " ! &/ +/    '()(*                

タの複製を生成，管理する機能も提供されており，可用性が はじめに高いことが知られている．分散  に管理されている大容量クラウド技術の普及により，映像共有システムやソーシャルデータを効率よく活用するためには，対象となるデータに対しネットワークサービス等，極めて多数の利用者が情報を共有して複数計算機を利用して並列処理を行う必要がある．しかしなつつ利用できるような大規模アプリケーションが多く開発されがら，分散  からデータを取り出した後に再度データを複ている．これに伴い，個人が生み出す情報が大量にネットワー

数計算機に分散させて並列処理を行うと，データの転送オーバ

ク上に保存されるようになり，ネットワーク上に存在するデーヘッドが非常に大きくなってしまう．そのため，大容量データタ量が爆発的に増加している．その結果大量のデータを高速に処理では従来のように処理を行う場所に値を転送するのではな処理することが必要となり，従来のデータベース管理システム

く，値が保存されている場所に処理を割り当てることが必要だである ではデータの格納や処理の柔軟性に関して不満が出るようになった．そこで，分散環境で一貫性の制限を緩和して処理性能を重視する分散     と呼ばれる  型データベース管理システムが注目され始めた．
分散  を用いると，

 では管理が困難な規模の大容量データを分散環境で管理することができる．一般に，デーと考えられる ．

本研究では分散  の実装のひとつである        !以下     に着目し，データアフィニティを考慮して大容量データをより高速に処理するための手法を提案する．   に保存されたデータに対して任意の処理を行う場合，   から処理の対象となる値を取得し，その後"" 書き込み読み出し処理の流れ      の構成と処理の流れ   は，クライアントノード，プロキシノード，データノードからなる．
・クライアントノード

任意のプロキシノードに接続し，リクエストを送信する．その後処理された結果を受け取る．
・プロキシノード
図 のデータモデル処理を行うのが通常の流れである．しかし，   の読み出し処理性能はあまり高くない # 上に，対象とする値のデータ量が大きいと値を取得するための通信処理が遅くなってしまうことが考えられる．本提案手法では，   上の値に対し任意の処理を効率よく行えるようにするために， $%$& %  ' と類似した機能を    に追加する．

この機能を用いてユーザが実行したい処理をプラグインとして定義し，定義された処理を各データノード上で実行して処理結果のみをクライアントに返す．これにより通信データ量を抑えることができる．また，処理対象の値を複数指定することで異なる値に対して複数のデータノード上で並列処理が可能になり，より高速に処理が行えると考えられる．よって，本稿ではキーを元にデータノードのリストを作成し，全データノードにリクエスト内容を記したメッセージを送信する．その後，一貫性レベルに応じたレスポンスを待ち，クライアントノードに結果を返す．プロキシノードはクライアントが最初に接続したデータノードが担う．
・データノード

リクエストメッセージの内容をみて，それに応じた処理を行い，処理の結果をプロキシノードに返す．

 

書き込みの流れ

書き込みは，追記ログの形式でシーケンシャルに行われるため，ランダム +,- が発生せず高速に行える実装となっている．に示す．図書き込み処理の主な流れを図. ( ，0 (  はそれぞれ，ディスク上のすべての書き込みをログの形式で記録するファイル，メモリ上に常駐する構
造体，ディスク上にある変更不可なファイルである．

   に保存された複数の異なる値に対し，事前に指定した処理を各データノード上で実行し，処理結果のみを返す機能

ᵢᵿᶒᵿᵬᶍᶂᶃ

ᵫᶃᶋᶒᵿᶀᶊᶃを実装する．評価実験から，本提案手法は    を通常使ᵡᶊᶇᶃᶌᶒ用した際よりも通信データ量を削減させ，処理が高速に行るこᵮᶐᶍᶖᶗ    の概要

本研究では， 型データベースである     に着目した．     は，% () 社が開発し，

  プロジェクトとしてオープンソース化された分散データベース管理システムである *．   の特徴としては，カラム型データ構造を持つリッチデータモデルである点が挙げられる．   のデータモデルを図  に示す． 型のデータベースは通常  つのキーで  つのバリューを管理しているが，   はキースペース，カラムファミリ，キー，カラムの # つ，もしくはスーパーカラムを加えた * つのキーで つのバリューを管理している．これにより通常の分散  よりも複雑なデータ管理が可能となっている．
その他の主な特徴としては，耐障害性の高さ，非中央集中型で単一故障点がない，データの分散保持を考慮した分散特性や一貫性の程度をユーザが自由に設定可能といった事が挙げられる．また    は書き込み性能を重視した分散  として開発されているため，書き込みの際にはディスクへのランダムアクセスが発生せず処理が高速になり，読み出しの際にはディスクへのランダムアクセスが発生し処理が低速になるという実装になっている．

ᵆᵑᵇᵢᶇᶑᶉ

ᵆᵏᵇ

ᵆᵐᵇ

ᶕᶐᶇᶒᶃ

ᵡᶍᶋᶋᶇᶒᵪᶍᶅ

ᵱᶃᶏᶓᶃᶌᶒᶇᵿᶊ ᶄᶊᶓᶑᶆ

ᵫᶃᶋᶍᶐᶗとを示す．

 

中の ..' /，図ᵱᵱᵲᵿᶀᶊᶃᵆἙὊἑύỶὅἙἕἁἋύἧỵἽἑ ᵇ

書き込み処理の流れ

 書き込みリクエストがプロキシノードに送信され，担当するデータノードにリクエストが送信される．

  リクエストを受け取ったデータノードはディスク上にある ..' / にシーケンシャルに書き込みを行い，同時にメモリ上の .

(  に書き込む．
! . (  上のデータ量が閾値を超える，もしくは一定時間が経過したら，ディスク上の 0 (  ファイルにロウデータがフラッシュされる．

書き込みは ..' / に書き込みが行われた段階で処理完了とみなす．.

(  上のデータはロウキーとカラムファミ
リのマップとして保存され，0 (  にはインデックス，ロウデータ，ブルームフィルタが保存される．一度フラッシュが実行されると，0 (  上のファイルは変更不可能になり，それ以上の書き込みは受け付ず，コンパクション処理で複数の古い0 (  ファイルを一つの新しいファイルにマージする処理のみ実行可能となる．

   読み出しの流れ
読み出しはメモリ上のデータに加え，ディスク上のデータも読む必要があり，ランダム +,- が発生する実装となっている．
そのため書き込みに比べると処理が低速になる傾向がある．読み出し処理の主な流れを図 ! に示す．

 読み出しリクエストがクライアントから任意のプロキシノードに送信される．

" "

ᵆᵐᵇ
ᵡᶊᶇᶃᶌᶒ

ᵆᵏᵇᵊᵆᵒᵇᶔᵿᶊᶓᶃᴾᵟᵆᵏᵇ

ᵰᶃᵿᶊᵢᵿᶒᵿ

ᵡᶊᶍᶑᶃᶑᶒᵢᵿᶒᵿᵬᶍᶂᶃ

ᵮᶐᶍᶖᶗᵰᶍᶕ
ᵢᵿᶒᵿ

ᵢᶇᶅᶃᶑᶒᴾᵯᶓᶃᶐᶗܱἙὊἑᵡᶊᶇᶃᶌᶒ
ᵱᵱᵲᵿᶀᶊᶃᵫᶃᶐᶅᶃᵆᵐᵇᵆᵑᵇᶔᵿᶊᶓᶃᴾᵟḚᵮᶐᶍᶖᶗᵫᶃᶋᶒᵿᶀᶊᶃܱἙὊἑ

ᵆᵑᵇᶔᵿᶊᶓᶃᴾᵟἾἩἼỽᶔᵿᶊᶓᶃᴾᵠḚᵢᵿᶒᵿᵬᶍᶂᶃ

ᵰᶍᶕ
ᵢᵿᶒᵿ

ܱἙὊἑ

ᵱᵱᵲᵿᶀᶊᶃ

ἾἩἼỽᶔᵿᶊᶓᶃᴾᵠᵫᶃᶋᶒᵿᶀᶊᶃ

図ᶔᵿᶊᶓᶃᴾᵟḚܱἙὊἑ

読み出し処理の流れ  リクエストを受け取ったプロキシノードは   デー

タノードにのみ実データの問い合わせを行い1 その他のデータノードに対しては '/ データのハッシュ値のみを求める 問い合わせを実行する．

! 実データの問い合わせを受け取った   データノードは 0 (  と . (  をマージし，問い合わせに一致するロウデータを探索し，プロキシノードに返す．

# プロキシノードは一貫性レベルに応じたレスポンスを待ち，その後クライアントへと結果を送信する．

プロキシノードは受け取った実データと '/ を比較し，一致していなかった場合には非同期にバックグラウンドでリードリペア処理を実行する．コンパクションを行うことで，読み込みが必要な 0 (  ファイル数を制限し，また使用されていな

いデータによって埋められているスペースを取り戻すことが可能になっている．

 提案手法設計

   に保存されたデータに対して任意の処理を行う場
合，   から処理の対象となる値を取得し，その後任意の処理を行うのが通常である．しかし，   の読み出し処理性能はあまり高くなくない上に，対象とする値のデータ量が大きいと値を取得するための通信処理が遅くなってしまうことが考えられる．

図ϼྸᵆᵐᵇ提案手法の概要

果を新たな値 212 とする．各値のレプリカに対しても同様の処理を行う．図 # では値  のレプリカの表示は省略している．

! 処理結果である値 212 をリクエストの答えとして返す．

本稿では    に保存された複数の異なる値に対し，事前に指定した処理を各データノード上で実行し，処理結果のみをリクエストの答えとして返す機能を実装した．事前に指定される処理は，引数にパス名を指定することにより，各実行時に指定された任意の ' 3 コマンドを対象データを管理している

データノード上で実行可能となっている．各値のレプリカに対しても定義した処理を実行し，リクエストの答えをハッシュ値

'/  で返す．
 評価   に保存された値に対し処理を行う際に，   を通常利用した場合と，前章で説明した実装を用いた場合の性能比較を行う．

  実 験 環 境

ノード数 4 台からなるクラスタに，機能拡張を行った    をインストールした．今回の開発では，   バー
ジョン 556 を用いた．測定に用いたノードの性能を表  に示す．
表そこで本提案手法では，   上の値に対し任意の処マシン性能

 理をデータアフィニティを考慮して効率よく行えるようにする    

ために，まず $%$ & %  ' と類似した機能を

関数をユーザが独自にプラグインとして定義できる機能である．

)%*+,*', -") .  /   に追加する．$% は  中でデータに適用可能な

この機能により    で管理するデータに対してユーザが実行したい処理をプラグインとして定義可能になる．その後，定義された処理を各データノード上で実行して処理結果のみをクライアントに返す．これにより通信データ量を抑えることができ，また，処理対象の値を複数指定すると異なる値に対して複数のデータノード上で並列処理が可能になって，より高速に処理が行えると考えられる．

本提案手法の概要を図 # に示す．

 クライアントから各データノードへリクエストを送信する．

  各データノード上の，異なる値 1 に対してプラグインとして定義された処理を各値に対して並列実行し，処理結 !"# $%!"#  & '(  !"# $%!"#  &  '( ". %% . "0%/1測定概要

   によるクラスタを構築し，   の標準コマ'/ * を使用して複数の値を取得してからワードカ
ウントコマンド   を実行した場合（以下クライアント側処ンド .

理）と，今回実装した，複数の値に対して各データノード上で を実行してその結果のみをクライアントに返す機能を使用した場合（以下サーバ側処理）の，データノード数，処理対象の値の数の変化に伴う実行時間の差異を比較した．今回の測定"!"

では， つの処理対象の値である

6  のテキストに対して  を実行し，処理対象の値の数が 6 個の場合には  が 6回実行される．図 *，7 に処理対象の値の数を とした際のそれぞれの処理の流れを示す．値  のレプリカの表示については  クライアント側処理，サーバ側処理性能比較
通常手法であるクライアント側処理と，提案手法であるサーバ側処理の性能比較を行った．図 :，4 にデータノード数を !
台，* 台，4 台とし，一貫性レベルを -8，9

 数を 6，!6と指定した場合の  の直列実行，クライアント側処理の値取得省略している．
ᵥᶃᶒẲẺᶔᵿᶊᶓᶃᴾᵟύᵠᵵᵡ

のみにかかる時間，クライアント側処理全体の処理時間，サーᵆᵑᵇ

バ側処理の実行時間を示す．図 : が 9

 数 6，図 4 が 9 

数 !6 としている．縦軸が実行時間  で，横軸がデータノー

ᵆᵏᵇᵡᶊᶇᶃᶌᶒ

ド数となっている．二つのグラフより，サーバ側処理の実行時

ᶔᵿᶊᶓᶃᴾᵟ間が 9ܱἙὊἑ

ᵮᶐᶍᶖᶗᵆᵐᵇᶔᵿᶊᶓᶃᴾᵟἾἩἼỽ 数に関わらずクライアント側処理の実行時間に対し，* 分の  以下に抑えられている．これは，サーバ側処理が  の処理結果をリクエストのレスポンスとして返すため，通信データ量が削減できたことと，処理を分散させて並列実行しているᶔᵿᶊᶓᶃᴾᵠとにより，  を直列実行しているクライアント側処理より ܱἙὊἑ図

処理にかかる時間を短縮できたためである．また，クライアン

クライアント側処理の流れ

ト側処理において，データノード数が増加してるのにも関わらクライアント側処理の流れ 読み出しリクエストをクライアントから送信する．
  担当するデータノードはリクエストに対する答えとして値 ， をプロキシに返し，プロキシはその値をクライアントに返す．

! 読み出した値 ， にをファイルに書き込み，ファイず実行時間が一定になっていることがグラフから見られる．これは，クライアント側処理における値取得のみにかかる時間も台数に関わらず一定であることから，   から取得してきた，データサイズが比較的大きな値をプロキシがクライアン
トに返す過程がボトルネックになっているためだと考えられる．
ᵓᵎルに対して  を直列実行する．ここで言う直列実行とは取得した値に対し  処理を  台のノード上で順次行うことを意味

ᵒᵓ

している．

ᵑᵓ

ܱᘍ଺᧓ᵹᶑᶃᶁᵻ

ᶔᵿᶊᶓᶃᴾᵟᵆᵏᵇܱἙὊἑ

ᵡᶊᶇᶃᶌᶒᵒᵎᶕᶁᵑᵎᵐᵓ

ᶁᶊᶇᶃᶌᶒ ͨϼྸᵆ͌ӕࢽỉỚᵇᵐᵎᶁᶊᶇᶃᶌᶒ ͨϼྸᵏᵓᶑᶃᶐᶔᶃᶐͨϼྸᵏᵎᶔᵿᶊᶓᶃᴾᵟḚᵮᶐᶍᶖᶗᵓܱἙὊἑᵎᵆᵑᵇᵑӨᶔᵿᶊᶓᶃᴾᵟἾἩἼỽᶔᵿᶊᶓᶃᴾᵠḚ
ܱἙὊἑ図-ᵓӨᵖӨ

ノード数を変化させた際の各処理の実行時間 !2  数3 #ᶔᵿᶊᶓᶃᴾᵟḚἾἩἼỽᶔᵿᶊᶓᶃᴾᵠܱἙὊἑᵓᵎᵆᵐᵇᵒᵓ

サーバ側処理の流れ

サーバ側処理の流れ 読み出しリクエストをクライアントから送信する．
  担当するデータノードはリクエストに対応する値 ， に対して  を並列実行し，処理結果を新たな値 2，2 とする．

! データノードは値 2，2 をプロキシに返し，プロキシはその値をクライアントに返す．

クライアント側処理，サーバ側処理どちらも 〜! を一つの処理とする．データノード数を ! 台，* 台，4 台と変化させ，
   のレプリケーション数は !，一貫性レベルを -8，，9  数を *〜:6 まで変化させ，実行時間を測定した．
9  数は処理対象の値の数を表している．

ᵒᵎܱᘍ଺᧓ᵹᶑᶃᶁᵻ

図ᵵᵡᶕᶁᵑᵓᵑᵎ
ᵐᵓᶁᶊᶇᶃᶌᶒ ͨϼྸᵆ͌ӕࢽỉỚᵇᵐᵎᶁᶊᶇᶃᶌᶒ ͨϼྸᵏᵓᶑᶃᶐᶔᶃᶐͨϼྸ

ᵏᵎ
ᵓ
ᵎᵑӨ

図+ᵓӨᵖӨ

ノード数を変化させた際の各処理の実行時間 !2  数3#   数，データノード数を考慮したサーバ側処理性能

次に 9

 数，データノード数を考慮した際のサーバ側処理の実行時間を測定した．データノード数を増加させた場合のサーバ側処理の平均値を図 ; に示す．縦軸が実行時間  で，横軸がデータノード数となっている．図 ; より，9

 数に関わらず，データノード数が増加すると実行時間が減少しており，"#"スケールアウトできているといえる．
ᵐᵓ࠯‫ܱר‬ᘍ଺᧓ᵹᶑᶃᶁᵻ

ᶔᵿᶊᶓᶃᴾᵑᵎᵏᵓᶔᵿᶊᶓᶃᴾᵏᵎᵏᵎܱᘍ଺᧓ᵹᶑᶃᶁᵻ

ᶔᵿᶊᶓᶃᴾᵓᵎᶔᵿᶊᶓᶃᴾᵓᵎᶔᵿᶊᶓᶃᴾᵑᵎ

ᵐᵓᶔᵿᶊᶓᶃᴾᵕᵎᵐᵎᶔᵿᶊᶓᶃᴾᵏᵎ

ᵐᵎ
ᵏᵓ
ᵏᵎ
ᵓ
ᵎᵓ

ᵎ

ᵐᵒ

ᵔ

ᵖᵏᵎ

ᵏᵐ

ᚾᘍ‫ׅ‬ૠᵎᵑӨ

図4ᵓӨ

図 ᵖӨ

ノード数をそれぞれ ! 台，* 台，4 台とし，9

 数を 6〜:6まで増加させた場合の実行時間を表している．縦軸が実行時間 で，横軸が試行回数を表す．グラフより，データノード 数に関わらず処理時間にばらつきが生じていることが確認できた．これは処理がどのレプリカ 今回の場合は ! つ
数，9のデータノードで実行されかはランダムに決定されるため，一部のデータノードに処理が偏る可能性があるためである．デー

タノード数が 4 台の場合にはあまり大きなばらつきが生じていないことがグラフから見て取れる．これは試行回数が 6 回と最後に一貫性レベル  を指定した際の実行時間の変化を測定した．図 ! にデータノードを ! 台もしくは 4 台，一貫性レベルを  とし，9 数を !6 と指定した場合の各処理の実行時間の変化を示す．縦軸が実行時間  で，データノード数となっている．一貫性レベル  を指定した場合も，クライアント側処理よりもサーバ側処理の方が高速である．また，サーバ側処理ではデータノード数が多い場合が高速になっており，一貫性レベル -8 を指定した時と同様の結果が得られた．
よって本提案手法では，高い一貫性を保ちたい状況でも高速に処理することができることを確認した．

あまり多くないため，データノード数が 4 台の際には特定のᵓᵎᵒᵓ

データノードへの処理の極端な偏りが生じにくいためだと考えあたりのデータ処理量が少なくなり，より高速に処理が行えているといえる．
ᵑӨᵐᵓᵒᵎ
ܱᘍ଺᧓ᵹᶑᶃᶁᵻ

られる．以上のことより，台数を増やすことで，データノード

ᵑᵎᵑᵓ
ᵑᵎ
ᵐᵓ

ᶑᶃᶐᶔᶃᶐͨϼྸ

ᵐᵎᶁᶊᶇᶃᶌᶒ ͨϼྸᵏᵓᶔᵿᶊᶓᶃᴾᵕᵎᵏᵎᶔᵿᶊᶓᶃᴾᵓᵎᵓᶔᵿᶊᶓᶃᴾᵑᵎ

ᵎᵑӨᶔᵿᶊᶓᶃᴾᵏᵎ

ᵐᵎ+ 台の場合の実行時間  一貫性を考慮した処理性能

データノード数増加に伴う平均実行時間の変化

図 6〜 に，図 ; の詳細を示す．図 6，， はデータܱᘍ଺᧓ᵹᶑᶃᶁᵻᶔᵿᶊᶓᶃᴾᵕᵎᵖӨᵑᵎ

図 ᵏᵓᵏᵎᵖӨ

データノード数を変化させた際の各処理の実行時間

 関 連 研 究ᵓᵎᵎᵐᵒᵔ

図  台の場合の実行時間ᚾᘍ‫ׅ‬ૠᵖᵏᵎ

ᵏᵐ

本研究に関連している研究として <  '  7 : があげられる．<  '  は，'  をベースにする並列 である．これらは，  '9   と呼ばれる機能を用いて， クエリの並列実行をサポートしており，複数のクライアンᵓӨᵑᵎ

トにクエリをジョブとして分散させることで並列実行を可能にᶔᵿᶊᶓᶃᴾᵓᵎしている．各ジョブをそれぞれのデータノードで実行し，結果ᶔᵿᶊᶓᶃᴾᵑᵎᵐᵓ
ܱᘍ଺᧓ᵹᶑᶃᶁᵻ

ᶔᵿᶊᶓᶃᴾᵕᵎᶔᵿᶊᶓᶃᴾᵏᵎᵐᵎᵏᵓを取得して，それらの結果を一箇所に集約する．本研究の提案
手法も <  '  と同様に，複数のデータノードで処理を並列に実行することが目的であるが，本提案手法はリクエストを分ᵏᵎ

割するのではなく，同一のリクエストを複数のデータノードにᵓ送信し，異なる値に対して処理を実行する仕組みになっている．

ᵎᵎᵐᵒ

ᵔ

ᵖᚾᘍ‫ׅ‬ૠ図 台の場合の実行時間ᵏᵎᵏᵐ

また，<  '  は $=$& =(  と呼ばれる，クライアントが発行する  クエリの中にシェルコマン
ドを埋め込むことができる機能によってデータをデータベースから取得して，データに対して任意の処理を実行し，その結果"*"

のみを得ることが可能になる．これは，本研究の提案手法で用いた関数をユーザが独自にプラグインとして定義しデータをデータベースから取得して，データに対して任意の処理を実行し，その結果のみを得る手法と類似している．

 お わ り に分散  の実装の  つである      に着目し，データアフィニティを考慮した並列分散処理を提案した．本稿
ではユーザが指定した複数の異なる値に対し，その値が保存されている各データノード上でユーザが指定した処理を実行し，処理結果をカラムの新たな値としてクライアントに返すサーバ側処理機能を実装した．
実装した機能の処理時間を評価したところ，クライアント側処理に対して提案手法であるサーバ側処理では，9 数，一貫性レベル，データノード数に関わらず実行時間が大幅に削減されていた．また，サーバ側処理ではスケールアウトができていることが示せたことに加え，データノード数の増加に伴い特定ノードへの処理の集中を抑えることができており，処理を並列分散実行することで処理性能の向上につながることを示した．
今後の課題としては，   上に保存されている値が依存関係にあった際の処理を追加すること， $% と類似した機能を追加すること，   の >  連携機能との性能比較を行うことがあげられる．
文献

5 6 7  *8 2  9 8 )   % 8 .   ( *8 2  : 8   ' ; <  =< )>  ? % > <; ) <%%@ 9<?
 < "1%8 ) "9" 
56 .2 ? /?8 ? ) /8 ;  . < ( < %> *; 9?  .)   % :%/?%1 % > <     * )  08 <% 4
56 .1<? A?1A<1<?%>
5 6 菱沼直子，竹房あつ子，中田秀基，小口正人，; による BC データ処理におけるデータ容量と処理性能に関する考察; D) E%  ， ，  年  月．
56 D '0 !著#8 大谷晋平8 小林隆 !訳#A8 オライ
リー・ジャパン8
56 9 > ?，BF % 9，; 2 9 %<> :%/G%0 0 ?     *;  7 9<? < "1%8C%  '  ，.>  
5-6 中谷翔，9 > ?，田浦健次朗，;ワークフローアプリケー
ション基盤としての並列 , の性能評価; 情報処理学会研究報
告，C%  '   ，  年 + 月．

"7"