HiRDB/シングルサーバとHiRDB/パラレルサーバでの共通の考慮点を次に示します。

(a)　ディスクに対するアクセスの競合を考慮した横分割

複数のUAPがそれぞれ別々の表に同時にアクセスする場合は，これらの表をそれぞれ異なるディスク上の異なるユーザ用RDエリアにわたって横分割します。ディスクに対するアクセスの競合を考慮した横分割の概要を次の図に示します。

図12-10　ディスクに対するアクセスの競合を考慮した横分割の概要

〔説明〕

表Aと表Bをそれぞれ異なるディスク上のユーザ用RDエリアUSR01〜USR02とUSR03〜USR04にわたって横分割しています。このため，UAP1とUAP2が同時に表Aと表Bにアクセスしても，ディスクに対するアクセスの競合による待ちが発生しないため，待ち時間を短くできます。

しかし，一つのディスク上のユーザ用RDエリアに複数の表を格納した場合，これらの表に対して複数のUAPが同時にアクセスすると，ディスクに対するアクセスの競合が発生します。このため，この表にアクセスできた一つのUAPのアクセスが終了するまで，ほかのUAPが待たされることになり，待ち時間が長くなります。

(b)　操作性を考慮した横分割

操作性を考慮した横分割の概要を次の図を基に説明します。

図12-11　操作性を考慮した横分割の概要

〔説明〕

• 表とインデクスの同一ユーザ用RDエリアへの格納
  検索性能よりはむしろ，表の作成，表の再編成，ユーザ用RDエリアのバックアップの取得，RDエリアの回復などの運用の操作性を重視する場合は，横分割した表とそれに対応するインデクスを同じユーザ用RDエリアに格納します。これによって，ユーザ用RDエリアごとの独立した運用が便利になります。
  図12-11の例では，表ABのうち，業務Aに関係する部分の表とインデクスを専用のユーザ用RDエリアUSR01にまとめて格納しています。これによって，例えば，業務Aを停止する場合は，pdholdコマンド（RDエリアの閉塞）で運用できます。また，データベース複写ユティリティ（pdcopy）を使用した業務単位でのバックアップが取得しやすくなります。
  
• 関連するユーザ用RDエリアの同一ディスクへの配置
  横分割した表とそれに対応するインデクスをそれぞれ異なるユーザ用RDエリアに格納する場合は，これらの互いに関連するユーザ用RDエリアを同一のディスクに配置します。これによって，ディスクごとに独立したユーザ用RDエリアの運用ができます。
  図12-11の例では，表CDのうち，業務Dに関係する部分の表とインデクスをそれぞれ格納したユーザ用RDエリアUSR04とUSR06を同一のディスクに配置しています。これによって，ディスクごとに業務の運用ができます。
  

HiRDB/パラレルサーバ固有の考慮点を次に示します。

(a)　ディスクに対するアクセスの負荷を考慮した横分割

• 複数のバックエンドサーバにわたる横分割
  一つのバックエンドサーバのディスクに複数のユーザ用RDエリアを配置したとき，それぞれのユーザ用RDエリアに格納された表のアクセス頻度がどれも高い場合，このバックエンドサーバでのディスクに対するアクセスの負荷が高くなります。
  このため，アクセス頻度の高い表は，複数のバックエンドサーバの異なるディスク上のユーザ用RDエリアにわたって横分割します。このとき，それぞれのバックエンドサーバでの表に対するアクセス頻度が均等になるようにします。
  
• 複数のサーバマシンにわたるディスクアクセスの並列化
  あるサーバマシンの一つのバックエンドサーバのユーザ用RDエリアに格納された表に対する処理が，入出力が主体でCPUの負荷が低い場合，ディスクに対するアクセスの負荷が複数のサーバマシンにわたって均等にならないため，並列処理の効率が下がります。
  このため，サーバマシン内のCPUビジー率に余裕がある場合は，このサーバマシンに更にバックエンドサーバとユーザ用RDエリアを配置して，ディスクに対するアクセスの並列度を向上させるようにします。
  

(b)　入出力処理の並列度を考慮した横分割

表をできるだけ多くのサーバマシンにわたって横分割すると，並列処理によって表に対する入出力処理時間が短縮できます。横分割できるサーバマシン数に限界があれば，各サーバマシンにバックエンドサーバとディスクを増やして表を横分割することで，入出力処理の並列効果が得られます。表を横分割するバックエンドサーバの数に伴う入出力処理性能の概要を次の図に示します。

図12-12　表を横分割するバックエンドサーバの数に伴う入出力処理性能の概要

ただし，表を横分割するバックエンドサーバの数が多過ぎると，各バックエンドサーバでの処理結果をフロントエンドサーバに返すための通信量が増加します。このため，データベースの運用やSQL処理（容量の大きい表から大量のデータを検索するSQL処理かどうか）を考慮して，表を横分割するバックエンドサーバの数を決定する必要があります。

(c)　表に対するアクセス頻度を考慮した横分割

それぞれのバックエンドサーバでの表に対するアクセス頻度が均等になるように表を横分割します。

アクセス頻度を均等にするための考慮点を次に示します。

キーレンジ分割の場合

• 表の横分割を定義する場合に，分割キーにUNIQUEを指定して，データ量が均等になるようにします。
• 表を横分割する場合に，あるキーレンジのデータに対するアクセス回数が，ほかのキーレンジのデータに対するアクセス回数よりも多いと予想できるときは，アクセス回数が多いと予想できるキーレンジのデータを更にキーレンジで分割します。

フレキシブルハッシュ分割，FIXハッシュ分割の場合

• ハッシュ関数を変更して，データ量が均等になるように調整します。
• 分割キーに偏りや重複がないものを選択して，データ量が均等になるように調整します。

複数のバックエンドサーバにわたって表を横分割する場合でも，表に対するアクセス頻度が均等になるように横分割した場合と，均等にならないように横分割した場合とでは，表に対する並列処理の性能に差が生じます。表に対するアクセス頻度の違いによる並列処理性能の違いを次の図に示します。

図12-13　表に対するアクセス頻度の違いに伴う並列処理性能の違い

〔説明〕

アクセス頻度が均等になるように表を横分割した場合と，均等にならないように表を横分割した場合とでは，削減できる処理時間が異なります。均等にならないように表を横分割した場合は，バックエンドサーバBES2での処理が終了するまで，表に対する処理は終了しないため，並列処理の効果が得られません。

(d)　複雑な検索処理を考慮した横分割

大量のデータの検索や結合処理をするなど，複雑な検索処理を考慮した表の横分割をする場合，次に示す手順で設計します。

1. ディスクに対する処理時間とディスクの台数の決定
   データの規模と処理のパターンから，ディスクへのアクセス頻度（利用率）を求め，これを基にデータをディスクに配分して，ディスクに対する処理時間の目標値を決めます。なお，結合処理をする場合は，結合処理に必要なワークディスク（ソートマージ用に使用する作業表用ファイルを作成するHiRDBファイルシステム領域の数）を除いてデータを配分します。結合処理に必要な時間は，ディスクに対する処理時間の目標値から除きます。ディスクへのデータ配分から，ディスクの台数を決定します。
   
2. サーバマシンの台数の決定
   データの処理パターンから，サーバマシンでの処理のオーバヘッド時間を求めます。ディスクに対する処理時間とサーバマシンでのオーバヘッド時間が，それぞれ均等になるようにサーバマシンの台数（バックエンドサーバを配置するサーバマシンの台数）を決定します。
   
3. 結合処理をするサーバマシンの台数の決定
   データの処理パターンから，結合処理をするときに掛かるサーバマシンでのオーバヘッド時間を求めます。この時間とディスクに対する処理時間を基に，必要とするフロータブルマシンの台数を決定します。
   フロータブルマシンとは，結合処理のような複雑な検索処理をするための専用のバックエンドサーバ（フロータブルサーバ）を配置するサーバマシンのことです。フロータブルサーバとするバックエンドサーバは，ユーザ用RDエリアを割り当てないバックエンドサーバとして定義します。
   
4. ワークディスクの台数の決定
   フロータブルマシンには，結合処理の対象となるデータが各バックエンドサーバから均等に分配されます。このときに予想されるデータ量を基に，ワークディスク（作業表用ファイルを作成するHiRDBファイルシステム領域）の台数を求めます。
   
5. システム構成の決定
   以上で決定したサーバマシンとディスクの台数から，システム全体の構成を決定します。
   

以上の手順で設計した，複雑な検索処理を考慮した横分割のシステム構成の概念を次の図に示します。

図12-14　複雑な検索処理を考慮した横分割のシステム構成

〔説明〕

バックエンドサーバBES1〜BES3とバックエンドサーバBES4〜BES6が，それぞれ表Aと表Bから結合処理の対象となるデータを読み出します。フロータブルサーバBES7〜BES9は，バックエンドサーバBES1〜BES6が読み出したデータを受け取り，並列に突き合わせる処理をします。

このようなシステム構成にすることで，バックエンドサーバBES1〜BES6での負荷を軽減でき，処理時間を短縮できます。なお，フロータブルサーバを配置しなかった場合は，フロータブルサーバで実行していた結合処理をバックエンドサーバBES1〜BES6のどれかが実行することになります。