(57)【要約】      （修正有）【課題】データを複数拠点に保全でき、通常時においても各拠点の設備が有効活用できるデータ管理システムの提供。【解決手段】複数の拠点に設置されたAPサーバ16と、拠点毎に複数設置されたDBサーバ18と、複数の管理サーバ12を備え、各DBサーバは全拠点で共通するデータを保持したテーブルを備える。データ追加時には、何れか一つの管理サーバから各拠点のAPサーバに追加データの登録が指令され、各APサーバは同一拠点内の各DBサーバに追加データの登録を求め、各DBサーバは追加データをテーブルに挿入する。データ検索時には、何れか一つの管理サーバが何れか一つの拠点のAPサーバに検索条件を送信し、APサーバは検索条件を複数に分割して同一拠点内の各DBサーバに発行し、各DBサーバは対応のデータをテーブルから抽出してAPサーバに送信し、APサーバは各DBサーバから送信されたデータを統合して管理サーバに送信する。【選択図】図３
2013235328.tif 000002
【特許請求の範囲】
【請求項１】
相互に所定の距離を隔てた複数の拠点にそれぞれ設置されたAPサーバと、上記拠点毎に複数設置され、同一拠点内のAPサーバとネットワークを介して接続されたDBサーバと、各拠点のAPサーバとネットワークを介して接続された複数の管理サーバとを備え、
上記の各APサーバは、追加データ複製部と、複数の登録処理部と、検索条件分割部と、複数の検索処理部と、複数のデータ加工部と、検索結果統合部を備え、
上記の各DBサーバは、全拠点を通じて相互に共通するデータを保持した複数のテーブルをそれぞれ備えており、各テーブルには、キー項目が一つに限定される制約と、データの更新が禁止される制約が設けられており、
クライアント端末から何れかの管理サーバに追加データが送信された場合に、当該管理サーバは、各拠点に配置されたAPサーバに対して当該追加データの登録を指令する処理を実行し、
各APサーバの上記追加データ複製部は、送信された追加データの複製物と、同一拠点内に配置されたDBサーバの特定情報を含むデータ追加リクエストを、上記の各登録処理部に割り当てる処理を実行し、
上記の各登録処理部は、上記追加データの登録を求めるSQL文を生成し、自己に割り当てられたDBサーバに発行する処理を実行し、
各DPサーバは、上記追加データに対応するレコードをテーブルに挿入する処理を実行し、
クライアント端末から何れかの管理サーバに検索条件が送信された場合に、当該管理サーバは何れか一つの拠点内のAPサーバに当該検索条件を送信する処理を実行し、
当該APサーバの検索条件分割部は、管理サーバから送信された検索条件を解析して複数の検索条件に分割すると共に、各検索条件及び担当のDBサーバを上記複数の検索処理部に割り当てる処理を実行し、
上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQL文を生成し、自己に割り当てられたDBサーバに発行する処理と、DBサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、DBサーバから送信されたデータをメモリ上から削除する処理と、DBサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合部に集計結果を出力する処理を実行し、
上記検索結果統合部は、各検索処理部から渡された集計結果を集計し、検索結果として上記管理サーバに送信する処理を実行し、
上記管理サーバは、APサーバから送信されたデータを検索結果として上記クライアント端末に送信する処理を実行することを特徴とするデータ管理システム。
【請求項２】
上記検索条件分割部は、入力された検索条件が時間的な範囲を含んでいる場合に、これをより短い時間的な範囲に分割することを特徴とする請求項１に記載のデータ管理システム。
【請求項３】
上記検索条件分割部は、入力された検索条件が地域的な範囲を含んでいる場合に、これをより狭い地域的な範囲に分割することを特徴とする請求項１に記載のデータ管理システム。
【請求項４】
請求項１〜３の何れかに記載のデータ管理システムであって、
インデックス生成部及びインデックス記憶部を有するインデックスサーバを備えており、
また上記の各DBサーバは、データベース管理システムと、暫定記憶領域及び永続記憶領域を備えており、
上記データベース管理システムは、上記APサーバから送信された追加データを上記暫定記憶領域に格納する処理と、所定の時間間隔で暫定記憶領域内の追加データを上記永続記憶領域に移動する処理を実行し、
上記インデックスサーバのインデックス生成部は、所定の時間間隔で上記DBサーバの暫定記憶領域に格納された追加データを取得する処理と、この追加データに基づいてインデックスを生成し、上記インデックス記憶部に格納する処理を実行し、
上記APサーバの各検索処理部は、自己に割り当てられた検索条件に対応した上記SQL文を生成するに際し、上記インデックスサーバのインデックス記憶部を参照し、検索条件に該当する各データの主キーを取得する処理と、この主キーによって取得対象データを指定したSQL文を生成する処理を実行することを特徴とするデータ管理システム。
【請求項５】
上記の各DBサーバは、メモリ上に設けられた更新ログ記憶領域を備えており、
上記データベース管理システムは、上記APサーバから送信された追加データを上記更新ログ記憶領域に順次格納する処理を実行することを特徴とする請求項１〜４の何れかに記載のデータ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はデータ管理システムに係り、特に、業務データを複数の拠点に設置されたサーバに重複格納することで、大規模災害の発生等によって業務データが消失するリスクを分散する技術に関する。
【背景技術】
【０００２】
地震や津波、噴火等の大規模災害、あるいは原発事故やテロ等の人災によってデータベースが物理的に損壊する場合に備え、企業の基幹システムにおいては、業務データを遠隔地に設置したバックアップ用のデータベースに重複登録することが以前より行われている。
例えば、特許文献１においては、正制御装置のディスク装置にデータを登録した後、遠隔地に設置された副制御装置に同一データを送信し、その登録を求める技術が開示されている。
【特許文献１】特開平１１−８５４０８号
【発明の開示】
【発明が解決しようとする課題】
【０００３】
このように、正副２台の制御装置によってデータを二重持ちすることにより、一方の地域において地震等が発生し、ディスク装置が物理的に破損した場合であっても、生き残った他方のディスク装置内のデータを活用することで、業務処理の連続性を担保することが可能となる。
しかしながら、従来のデータ保全技術の場合、副制御装置はあくまでも緊急事態に備えた保険として設けられるものであり、通常時にこれが有効に活用されることはなく、その非効率性が問題となっていた。
【０００４】
この発明は、このような現状に鑑みて案出されたものであり、大切な業務データを複数拠点に確実に保全できると共に、緊急時はもちろんのこと、通常時においても各拠点の設備が有効活用可能なデータ管理システムを提供することを目的としている。
【課題を解決するための手段】
【０００５】
上記の目的を達成するため、請求項１に記載したデータ管理システムは、相互に所定の距離を隔てた複数の拠点にそれぞれ設置されたAPサーバと、上記拠点毎に複数設置され、同一拠点内のAPサーバとネットワークを介して接続されたDBサーバと、各拠点のAPサーバとネットワークを介して接続された複数の管理サーバとを備え、上記の各APサーバは、追加データ複製部と、複数の登録処理部と、検索条件分割部と、複数の検索処理部と、複数のデータ加工部と、検索結果統合部を備え、上記の各DBサーバは、全拠点を通じて相互に共通するデータを保持した複数のテーブルをそれぞれ備えており、各テーブルには、キー項目が一つに限定される制約と、データの更新が禁止される制約が設けられており、クライアント端末から何れかの管理サーバに追加データが送信された場合に、当該管理サーバは、各拠点に配置されたAPサーバに対して当該追加データの登録を指令する処理を実行し、各APサーバの上記追加データ複製部は、送信された追加データの複製物と、同一拠点内に配置されたDBサーバの特定情報を含むデータ追加リクエストを、上記の各登録処理部に割り当てる処理を実行し、上記の各登録処理部は、上記追加データの登録を求めるSQL文を生成し、自己に割り当てられたDBサーバに発行する処理を実行し、各DPサーバは、上記追加データに対応するレコードをテーブルに挿入する処理を実行し、クライアント端末から何れかの管理サーバに検索条件が送信された場合に、当該管理サーバは何れか一つの拠点内のAPサーバに当該検索条件を送信する処理を実行し、当該APサーバの検索条件分割部は、管理サーバから送信された検索条件を解析して複数の検索条件に分割すると共に、各検索条件及び担当のDBサーバを上記複数の検索処理部に割り当てる処理を実行し、上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQL文を生成し、自己に割り当てられたDBサーバに発行する処理と、DBサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、DBサーバから送信されたデータをメモリ上から削除する処理と、DBサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合部に集計結果を出力する処理を実行し、上記検索結果統合部は、各検索処理部から渡された集計結果を集計し、検索結果として上記管理サーバに送信する処理を実行し、上記管理サーバは、APサーバから送信されたデータを検索結果として上記クライアント端末に送信する処理を実行することを特徴としている。
【０００６】
請求項２に記載したデータ管理システムは、請求項１に記載のシステムであって、さらに、上記検索条件分割部は、入力された検索条件が時間的な範囲を含んでいる場合に、これをより短い時間的な範囲に分割することを特徴としている。
【０００７】
請求項３に記載したデータ管理システムは、請求項１に記載のシステムであって、さらに、上記検索条件分割部は、入力された検索条件が地域的な範囲を含んでいる場合に、これをより狭い地域的な範囲に分割することを特徴としている。
【０００８】
請求項４に記載したデータ管理システムは、請求項１〜３に記載のシステムであって、さらに、インデックス生成部及びインデックス記憶部を有するインデックスサーバを備えており、また上記の各DBサーバは、データベース管理システムと、暫定記憶領域及び永続記憶領域を備えており、上記データベース管理システムは、上記APサーバから送信された追加データを上記暫定記憶領域に格納する処理と、所定の時間間隔で暫定記憶領域内の追加データを上記永続記憶領域に移動する処理を実行し、上記インデックスサーバのインデックス生成部は、所定の時間間隔で上記DBサーバの暫定記憶領域に格納された追加データを取得する処理と、この追加データに基づいてインデックスを生成し、上記インデックス記憶部に格納する処理を実行し、上記APサーバの各検索処理部は、自己に割り当てられた検索条件に対応した上記SQL文を生成するに際し、上記インデックスサーバのインデックス記憶部を参照し、検索条件に該当する各データの主キーを取得する処理と、この主キーによって取得対象データを指定したSQL文を生成する処理を実行することを特徴としている。
【０００９】
請求項５に記載したデータ管理システムは、請求項１〜４に記載のシステムであって、さらに、上記の各DBサーバは、メモリ上に設けられた更新ログ記憶領域を備えており、上記データベース管理システムは、上記APサーバから送信された追加データを上記更新ログ記憶領域に順次格納する処理を実行することを特徴としている。
【発明の効果】
【００１０】
請求項１に記載したデータ管理システムの場合、データの追加に際しては、複数の拠点に設置されたAPサーバを介して同拠点内に配置された複数のDBサーバに対するデータの追加が同時に実行される仕組みを備えているため、何れかの拠点が大規模災害等によって壊滅的な被害を被ったとしても、他の拠点に配置されたDBサーバ内のデータに基づいて、業務処理をシームレスに続行可能となる。
同一機能を備えた管理サーバも複数用意されているため、それぞれを地理的に十分な距離を隔てた場所に設置しておくことで、管理サーバレベルでもリスク分散が図れる。
【００１１】
また、各拠点の設備には正副の別がなく、管理サーバは検索処理に際し、直近の処理実績や距離等を勘案して自由に拠点を選択できるため、通常時であっても各拠点に配置された設備の有効活用が図れる。
【００１２】
また、DBサーバが管理する各テーブルの正規化が極限まで追求され、構造の単純化が実現される一方で、テーブルから抽出したデータの加工処理（ソートやマッチング、コントロールブレイク等）はAPサーバ側で実行され、DBサーバはデータの出し入れに専念できるため、テーブル数の増大やテーブル間の関係の複雑化に伴いSQLの発行数が増大しても、DBサーバ側の負担増を抑制することが可能となる。
【００１３】
さらに、同一内容のデータを備えたDBサーバが物理的に複数台用意され、検索処理時には検索条件が各DBサーバに分散される仕組みであるため、個々のDBサーバにおけるデータ抽出処理が軽減される結果、システム全体の処理速度を向上させることができる。
【００１４】
しかも、APサーバにおいては、入力された検索条件が複数に分割され、それぞれ複数の検索処理部を介してDBサーバにデータの検索依頼が送信されると共に、DBサーバから各検索処理部に対して返された検索結果データに対しても、一定量単位で複数のデータ加工処理部による並列処理が実行されるため、DBサーバから大量のデータが送信される場合であっても、多数のCPUコアを用いることで効率的な処理が可能となる。また、このようにDBサーバからの検索結果データが全て揃うまで待機することなく、一定量のデータが揃った時点で部分的な加工処理に移行することにより、DBサーバ側のDISK/IOによる遅延を緩和することも可能となる。
【００１５】
これまで、DNA解析や気象解析のように純粋な演算処理を主体とした科学技術計算と異なり、データベースに蓄積された大量のデータを参照する必要のある業務系処理の場合には、DBサーバからの応答を待つDISK/IOがボトルネックとなるため、APサーバ側のCPUコアの数を増やしたとしても、直ちに処理速度の向上には結びつかないという問題があった。
これに対し、上記のような仕組みをAPサーバに設けることにより、テーブルの正規化の追求に伴うDBサーバ側の負担増を、APサーバ側の処理の効率化によってカバーすることが可能となった。
【００１６】
請求項４に記載のデータ管理システムの場合、インデックス（二次索引）の作成処理が外部の独立したインデックスサーバに移譲されているため、これに纏わるDBサーバ側の負担を解消することができる。
しかも、データ参照時には個々のデータの主キーを指定した形のSQLがAPサーバから発行されるため、DBサーバ側でテーブルをソートする必要がなくなり、その分、DBサーバの負荷を低減することができる。
【００１７】
請求項５に記載のデータ管理システムの場合、DBサーバの更新ログがメモリ上に格納される機構を備えているため、更新ログをディスク上に格納する場合に比べて、DBサーバ側のDISK/IOを低減することができる。
しかも、DBサーバが物理的に複数台用意されると共に、各DBサーバにおいては同一の追加データが更新ログとして更新ログ記憶領域に蓄積される仕組みであるため、停電等の事故によって一のDBサーバにおいて更新ログが消えた場合でも、他のDBサーバに格納された更新ログによって容易に復旧可能となる。
【発明を実施するための最良の形態】
【００１８】
図１は、この発明に係るデータ管理システム10の全体構成を示すものであり、複数の拠点にそれぞれ配置された管理サーバ12と、APサーバ16と、複数のDBサーバ18とを備えている。
同一拠点内の管理サーバ12とAPサーバ16間及びAPサーバ16とDBサーバ18間は、LAN等の通信ネットワークを介して接続されている。
また、拠点を異にする管理サーバ12とAPサーバ16間は、WAN等の通信ネットワーク20を介して接続されている。
【００１９】
各管理サーバ12には、インターネット等の通信ネットワーク20を介して、ユーザの操作するクライアント端末22が接続される。
クライアント端末22は、PC等のコンピュータよりなり、OSやWebブラウザ等のプログラムを搭載している。
各クライアント端末22は、基本的には最寄りの拠点に設置された管理サーバ12にアクセスするようにWebブラウザ上で設定されているが、大規模災害の発生等によって当該拠点が機能不全に陥り、所定時間内に応答がない場合には、アクセス先が他の拠点内の管理サーバ12に自動または手動で切り替えられる機能を備えている。
【００２０】
各拠点は、地理的に所定の距離を隔てた場所に設けられたデータセンター等が該当する。例えば、図１においては、第１の拠点14aが東京に、第２の拠点14bが大阪に設けられている。
なお、拠点の数は２箇所に限定されるものではなく、災害によるリスク分散という観点からは、より多くの拠点（札幌、名古屋、福岡、那覇等）が設けられることが望ましい。
【００２１】
図示の便宜上、各拠点14a, 14bには１台の管理サーバ12と１台のAPサーバ16が描かれているが、実際には複数の管理サーバ12と複数のAPサーバ16が設置され、それぞれロードバランサによって負荷分散されている。また、各拠点14a, 14bに設置されるDBサーバ18の数も３台に限定されるものでなく、実際には４台以上のDBサーバ18が設置されている。
各DBサーバ18は、全DBサーバ18間に共通するデータを格納した複数のテーブル群と、データベース管理システム（RDBMS）とを備えている。
【００２２】
図２は、各DBサーバ18に格納されたテーブル群の具体例を示しており、顧客管理テーブル24と、予約管理テーブル26と、売上管理テーブル28と、予約取消管理テーブル30と、請求管理テーブル32とによって、各店舗の売り上げが管理されている。
【００２３】
顧客管理テーブル24は、「顧客ID（主キー）」及び「地域」のデータ項目を備えている。
また、予約管理テーブル26は、「予約ID（主キー）」、「店ID」、「顧客ID（外部キー）」、「金額」及び「予約年月日」のデータ項目を備えている。
売上管理テーブル28は、「予約ID（主キー／外部キー）」及び「売上年月日」のデータ項目を備えている。
予約取消管理テーブル30は、「予約ID（主キー／外部キー）」及び「予約取消年月日」のデータ項目を備えている。
請求管理テーブル32は、「請求ID（主キー）」、「請求年月日」及び「予約ID（外部キー）」のデータ項目を備えている。
【００２４】
上記の各テーブル24〜32には、以下の(1)〜(3)の制約が予め課せられている。
(1)キー項目は一つに限定される。
したがって、複数の項目の組合せによってキー項目を構成すること（複合キー）は、禁止される。
【００２５】
(2)各テーブルにはレコードの追加のみが許容され、既存レコードの値の更新及びレコードの削除は禁止される。
したがって、値に変更が生じた場合など、発生タイミングの異なる情報は別テーブルに格納されることとなる。
【００２６】
(3)各テーブルのカラムには、NULL値禁止制約、フラグ値禁止制約、区分値禁止制約が課せられる。
まず「NULL値禁止制約」とは、データ項目の値としてNULL（値なし）を充填することが禁止されることを意味しており、このようなNULL値の充填を想定したデータ項目の設定自体が許容されないことになる。
つぎに「フラグ値禁止制約」とは、データ項目の値としてフラグ値（「１／０」、「ON／OFF」、「TRUE／FALSE」等の２値データ）を充填することが禁止されることを意味しており、このようなフラグ値の充填を想定したデータ項目の設定自体が許容されないことになる。
「区分値禁止制約」とは、データ項目の値として区分値（「１：正社員」、「２：パート」、「３：アルバイト」等）を充填することが禁止されることを意味しており、このような区分値の充填を想定したデータ項目の設定自体が許容されないことになる。
【００２７】
これらの制約ルールは、新規テーブルの設計時やSQL文発行時に、DBサーバ18のデータベース管理システムによって適否がチェックされ、制約ルールに違反する処理の実行が拒絶されることにより、その実効性が担保される。
【００２８】
図２より明らかなように、各テーブルは単一のデータ項目によって主キー（PK）が構成されている。
また、「予約取消」に関するデータも、通常であれば予約管理テーブル26において「予約取消フラグ」等のデータ項目が設けられ、各レコードに「１／０」等のフラグ値を充填することで状態が管理されるところであるが、予約取消管理テーブル30を予約管理テーブル26とは別個に設けることにより、予約取消の状態管理がなされている。すなわち、この予約取消管理テーブル30に登録された予約IDが「予約取消」状態にあることとなり、レコードの有無によって予約取消の有無が表現されている。
【００２９】
各テーブルには上記(2)の制約（値の更新禁止）が課せられているため、例えばある顧客の「地域」に変動が生じた場合でも、顧客管理テーブル24における該当レコードの「地域」の値が書き換えられることはない。
図示は省略したが、このような場合には例えば「顧客ID」、「変更地域」、「変更年月日」等のデータ項目を備えた「顧客地域変更管理テーブル」が新たに設けられて、当該顧客の顧客ID、変更後の地域、変更年月日が格納される。
【００３０】
この結果、顧客の地域別に売上を集計する必要が生じた場合、APサーバ16側では顧客管理テーブル24を参照して各顧客の地域情報を取得した後、顧客地域変更管理テーブルを参照して地域変更の生じた顧客を特定し、変更後の地域に差し替える処理を実行することになる。
【００３１】
図３は、クライアント端末22から何れかの管理サーバ12に送信されたデータ追加のリクエストが、各拠点14a, 14b内の各DBサーバ18に格納される場面での機能構成を表しており、管理サーバ12は、追加データ受付部34と、拠点数に対応した複数の追加データ送信部36を備えている。
また、各APサーバ16は、追加データ複製部38と、DBサーバ18の数に対応した複数の登録処理部40を備えている。
【００３２】
図４は、クライアント端末22から何れかの管理サーバ12に送信された検索リクエストが、管理サーバ12及び一の拠点のAPサーバ16を経由して同拠点内の各DBサーバ18に送信される場面での機能構成を表しており、管理サーバ12は、検索条件送信部42を備えている。
また、APサーバ16は、検索条件分割部44と、DBサーバ18の数に対応した複数の検索処理部46を備えている。
【００３３】
図５は、DBサーバ18から検索結果が送信される場面での機能構成を表しており、APサーバ16は、各検索処理部46単位で複数割り当てられたデータ加工部47と、検索結果統合部48を備えている。
また管理サーバ12は、検索結果送信部50を備えている。
【００３４】
各管理サーバ12の追加データ受付部34、追加データ送信部36、検索条件送信部42、検索結果送信部50は、管理サーバ12に搭載された多数のCPUコアが、専用のアプリケーションプログラムに従って所定の処理を実行することで実現されるのであるが、この際、OSまたは専用のミドルウェアによって複数のスレッドが起動され、各CPUコアにタスクが割り当てられることにより、マルチタスク処理が実現される。
【００３５】
また、各APサーバ16の追加データ複製部38、登録処理部40、検索条件分割部44、検索処理部46、データ加工部47、検索結果統合部48は、各APサーバ16に搭載された多数のCPUコアが、専用のアプリケーションプログラムに従って所定の処理を実行することで実現されるのであるが、この際、OSまたは専用のミドルウェアによって複数のスレッドが起動され、各CPUコアにタスクが割り当てられることにより、マルチタスク処理が実現される。
【００３６】
図６は、CPUコア52とスレッド54との対応関係を表しており、各スレッド54にはスレッドプール56が設けられ、そこに配置された複数のタスク58をスレッド54が順次処理していくイメージが描かれている。
この図におけるスレッド54が、管理サーバ12の追加データ受付部34、追加データ送信部36、検索条件送信部42、検索結果送信部50として機能し、あるいはAPサーバ16の追加データ複製部38、登録処理部40、検索条件分割部44、検索処理部46、データ加工部47、検索結果統合部48として機能し、これらの各機能構成部が実行する具体的な処理が、タスク58に相当する。
【００３７】
各スレッド54は、スレッドプール56に蓄積されたタスク58を古い順に次々と実行していき、自己のスレッドプール56が空になった場合には、他のスレッド54のスレッドプール56に蓄積されたタスク58を、新しい順に実行していく。
【００３８】
つぎに図７のフローチャート及び図３のブロック図に従い、このシステム10のデータ追加時における処理手順を説明する。
まず、クライアント端末22から送信されたデータ追加のリクエストを管理サーバ12が受信すると（Ｓ10）、追加データ受付部34が追加データを拠点数分コピーし（Ｓ12）、それぞれを各追加データ送信部36に渡す。
各追加データ送信部36は、受け取った追加データを自己が担当する拠点のAPサーバ16に送信する（Ｓ14）。
【００３９】
これを受けた各APサーバ16の追加データ複製部38は（Ｓ16）、追加データをDBサーバ18の台数分コピーし（Ｓ18）、それぞれを登録処理部40に渡す。
各登録処理部40は、自己が担当するDBサーバ18に対して上記の追加データの登録を求めるSQL文を発行する（Ｓ20）。
これを受けた各DBサーバ18は（Ｓ22）、該当のテーブルに対して一斉に対応のレコードを追加する（Ｓ24）。この結果、全拠点における全DBサーバ18が管理するデータの同一性が確保される。
【００４０】
つぎに、図８〜図１０のフローチャート及び図４、図５のブロック図に従い、このシステム10のデータ検索時における処理手順を説明する。
まず、クライアント端末22から送信された検索条件を第１の拠点14a内の管理サーバ12が受信すると（図８のＳ30）、検索条件送信部42が検索処理を担当する一つのAPサーバ16を決定し（Ｓ32）、当該APサーバ16に検索条件を送信する（Ｓ34）。
通常は、同一の拠点14a内に配置されたAPサーバ16が選択されるが、当該APサーバ16が何らかの理由で動作していない場合、管理サーバ12の検索条件送信部42は、他の拠点までの物理的な距離や通信ネットワークの混雑状況、過去の実績等を勘案し、現時点で検索結果が最も早く戻ってくると判断した拠点のAPサーバ16を選択する。
【００４１】
上記の検索条件を第１の拠点14aのAPサーバ16が受信すると（Ｓ36）、検索条件分割部44が検索条件を解析し、検索条件の内容に応じて複数の検索条件に分割する（Ｓ38）。
【００４２】
ここで分割の基準となるのは、時間（日、週、月、年等）や地域（都道府県、市町村等）など、検索対象データを論理的に複数に区分できるものが該当する。
例えば、「2010年における全チェーン店の売上を集計する」という検索条件が与えられた場合に、「2010年１月分の全チェーン店の売上」、「2010年２月の全チェーン店の売上」、「2010年３月の全チェーン店の売上」…というように、年を月単位に１２分割することが該当する。
また、各チェーン店の所在地データに着目し、「2010年における東京所在チェーン店の売上」、「2010年における北海道所在チェーン店の売上」、「2010年における沖縄所在チェーン店の売上」…というように、全国を都道府県単位に４７分割することも該当する。
もちろん、「2010年１月分の東京所在チェーン店の売上」や「2010年１月の北海道所在チェーン店の売上」のように、月×都道府県単位で５６４分割することもできる。
【００４３】
これらの分割基準は、クライアント端末22から発せられると予測される検索条件や、対象となるデータの量等に鑑みて、事前に幾つかの分割パターンがプログラム設計者によって策定され、検索条件分割部44を実現するためのプログラム中にコーディングされている。
【００４４】
ここでは、クライアント端末22から「Ａ店の８月分の請求額を地域毎に集計せよ」という内容の検索リクエストが送信されたものとして、説明を続ける。
まず検索条件分割部44は、「８月＝３１日間」というカレンダー情報に従い、「８月１日分」、「８月２日分」、「８月３日分」…「８月３１日分」というように、検索条件を３１分割する。
【００４５】
つぎに検索条件分割部44は、これらの分割された各検索条件（「Ａ店の８月１日分の請求額を地域毎に集計せよ」等）及び担当すべき対応DBサーバ18を、３１個の検索処理部46に割り当てる（Ｓ40）。
【００４６】
これに対し各検索処理部46は、自己に割り当てられた請求日を指定した、請求管理テーブル32から請求データを取得するためのSQL文を生成し、自己が担当するDBサーバ18に発行する（図９のＳ42）。
【００４７】
そして、DBサーバ18から該当日の請求年月日を備えた請求データが送信されると、検索処理部46は対応のDBサーバ18から全ての検索結果データが送信されるのを待つことなく、予め設定された一定量のデータ（例えば1,000件のレコード相当分）が送信された時点で（Ｓ44／Ｙ）、必要な演算処理を複数のデータ加工部47に割り当てる（Ｓ46）。
【００４８】
具体的には、以下のような処理がデータ加工部47によって実行される。
(1)各請求データの「予約ID」を指定したSQL文を生成してDBサーバ18に発行し、「予約管理テーブル26」から対応の予約データを取得する。
(2)送信された予約データの中で、該当店舗の「店ID」を有するデータのみを抽出し、他の店IDのデータを除外する。
(3)各予約データの「顧客ID」を指定したSQL文を生成してDBサーバ18に発行し、顧客管理テーブル24から対応の顧客データを取得する。
(4)顧客データの「地域」毎に、予約データ中の「金額」の値を集計する。
これら(1)〜(4)の処理は、具体的にはタスク58として各データ加工部47のスレッドプール56に配置される。
【００４９】
検索処理部46は、データ加工部47から1,OOO件単位の処理結果データが返信された時点で（Ｓ48／Ｙ）、この単位データ量当たりの処理結果をメモリに格納すると共に、DBサーバ18から送信されたデータをメモリ上から削除する（Ｓ50）。
各検索処理部46は、DBサーバ18からのデータ送信が完了するまで、DBサーバ18から送信されるデータが一定量に達する度にＳ46〜Ｓ50の処理を繰り返す（Ｓ52／Ｎ、Ｓ44／Ｙ）。
そして、DBサーバ18からのデータ送信が完了し、Ｓ46〜Ｓ50の最後の処理が完了して１日分の処理結果データが揃った時点で（Ｓ52／Ｙ）、検索処理部46はこれまでの部分的な処理結果の集計値を集計し（Ｓ54）、検索結果統合部48に集計結果を出力する（Ｓ56）。
【００５０】
これを受けた検索結果統合部48は（図１０のＳ58）、各検索処理部44から集計結果が送信される度に、全ての検索処理部44からの集計結果が揃ったか否かをチェックし（Ｓ60）、全てが揃った段階で全検索処理部44の集計結果を集計する（Ｓ62）。
そして、その最終的な集計結果を管理サーバ12に送信する（Ｓ64）。
これを受けた管理サーバ12の検索結果送信部50は（図８のＳ66）、この集計結果を含むWebファイルを生成し、クライアント端末22に送信する（Ｓ68）。
【００５１】
このシステム10の場合、DBサーバ18からのフェッチが完了するまでAPサーバ16が待つことはなく、一定量のデータを受信する度に複数のデータ加工部47による処理が開始される仕組みであるため、DBサーバ18のDISK/IOによるボトルネックを解消することができる。
【００５２】
また、APサーバ16における部分的な集計が完了する度に、DBサーバ18から送信されたデータが占めていたメモリが解放され、データ量が格段に小さな集計結果データのみがメモリに格納される仕組みであるため、APサーバ16のメモリが大きなデータに占拠され続けることを回避できる。
【００５３】
さらに、図１１に示すように、各DBサーバ18は同じ内容のデータを保持しており、APサーバ16の各検索処理部46は、DBサーバ18aから「８／１（８月１日分）」のデータを取得し、DBサーバ18bからは「８／２（８月２日分）」のデータを、DBサーバ18cからは「８／３（８月３日分）」のデータを…、というように、自己に割り当てられた一つのDBサーバ18から自己に割り当てられた１日分のデータを取得するSQL文を分散して発行できる。このため、個々のDBサーバ18における処理の負担が必然的に低減することとなり、全体の処理速度を高速化することができる。また、各検索処理部46に担当のDBサーバ18を割り振る際に、DBサーバ18毎の特性（保持データの範囲等）を考慮することなく、機械的に対応付けることができる。
【００５４】
なお、処理速度の向上という観点からは、分割した検索条件と等しい数の検索処理部46及びDBサーバ18を用意することが望ましいが、検索処理部46及びDBサーバ18に数はこれに限定されるものではない。
例えば、分割された検索条件が31個あり、検索処理部46が31個設けられたにもかかわらず、DBサーバ18が物理的に10台しか用意されていない場合には、各DBサーバ18に対して３〜４個の検索条件が割り振られることになる。この場合でも、１台のDBサーバ18のみで全てを処理する場合に比べ、大幅な高速化が期待できる。
【００５５】
上記の通り、複数の拠点には同じ機能構成を備えた管理サーバ12、APサーバ16及び複数のDBサーバ18が配置されており、データの追加時には一の拠点内の管理サーバ12から全拠点のAPサーバ16に対してデータ追加の指令が同時に送信され、各APサーバ16から同一拠点内の各DBサーバ18に対してデータ追加のSQLが一斉に発行される仕組みを備えているため、地震等の自然災害によって何れかの拠点が壊滅的な被害を被った場合であっても、クライアント端末22は即座に他の拠点の管理サーバ12にアクセスすることで、当該拠点に配置されたAPサーバ16及びDBサーバ18を通じて、業務データの検索や追加といった処理を継続することができる。
【００５６】
また平常時においても、各拠点の管理サーバ12やAPサーバ16、DBサーバ18は近隣のクライアント端末22に対して通常の業務サービスを休みなく提供しており、漫然と待機しているわけではないため、保有設備の有効活用と拠点単位での負荷分散が実現される。
【００５７】
なお、管理サーバ12は必ずしもAPサーバ16及びDBサーバ18と同一の拠点内に配置される必要はなく、各管理サーバ12を他の場所に設置することも当然に可能である。
【００５８】
上記のように、実際には各拠点内には複数のAPサーバ16が設置され、図示しないロードバランサによって負荷分散されているため、各拠点内にはAPロックサーバ（図示省略）が設置され、APサーバ16間における拠点単位での排他制御が実行されている。
また、拠点間を跨ってデータの整合性を確保する必要がある場合（オークションの入札リクエスト等）には、図示は省略したが、各管理サーバ12間に管理ロックサーバを設け、管理サーバ12間における排他制御が実行される。
【００５９】
この発明にあっては、上記のようにDBサーバ18が管理する各テーブルの構造が極限まで単純化される分、テーブルの数が増え、SQL文の発行数自体は増大するが、演算処理は多数のCPUコアを用いた並列処理によって高速化されたAPサーバ16側で行われ、DBサーバ18は単純化されたデータの管理（インサートとセレクト）に専念でき、データの更新や削除から解放されるため、DBサーバ18の負担は大幅に軽減される。
しかも、DBサーバ18は筐体レベルで複数台用意され、検索時にはデータの抽出処理がそれぞれに分散される。
このため、テーブルの正規化の追求に伴いDBサーバ18側の処理速度が低下することを、有効に回避できる。
【００６０】
また、フラグ値や区分値のように、特殊なビジネスルールに基づいた値の格納が禁止される結果、データモデルの見通しが良好となり、テスト・データの作成効率が向上するという効果も期待できる。
【００６１】
図１２に示すように、各DBサーバ18とAPサーバ16との間にインデックスサーバ60を設けることにより、このシステム10における検索処理をより高速化することができる。
この場合、各DBサーバ18は、データベース管理システム（RDBMS）61と、当日分データ記憶領域（暫定記憶領域）62と、過去分データ記憶領域（永続記憶領域）63とを備える。
【００６２】
また、インデックスサーバ60は、インデックス生成部64と、インデックス記憶部65と、インデックス提供部66とを備えている。
インデックス生成部64及びインデックス提供部66は、インデックスサーバ60のCPUが専用のプログラムに従って動作することにより実現され、インデックス記憶部65は、インデックスサーバ60のSSD（Solid State Drive）内に設けられている。
【００６３】
APサーバ16の登録処理部40から送信された追加データは、DBサーバ18のデータベース管理システム61によって当日分データ記憶領域62に一旦格納された後、夜間バッチ処理によって過去分データ記憶領域63に移される。
また、インデックスサーバ60のインデックス生成部64は、夜間バッチ処理により、データベース管理システム61から当日分データ記憶領域62内に格納された追加データを取得し、追加分のインデックスを作成した後、インデックス記憶部65に格納する。
【００６４】
この場合、APサーバ16の各検索処理部46は、各DBサーバ18に対してSQL文を発行するに際し、インデックスサーバ60のインデックス提供部66を介してインデックス記憶部65を参照し、過去分データ記憶領域63に格納されたデータに関しては、検索条件の範囲に含まれる個々のデータの主キーを取得した後、個々の主キーを特定したSQL文を生成する。
【００６５】
例えば、管理サーバ12から送信された検索条件が、特定店舗における過去１年分の売上データを取得するものであった場合、検索処理部46はこの条件に合致する全データの主キーをインデックスサーバ60から取得した上で、SQL文中にこれらの主キーを記述してDBサーバ18に発行する。
【００６６】
このため、DBサーバ18のデータベース管理システム61は、データの検索処理を行うことなく、過去分データ記憶領域63に格納された各テーブルから主キーによって指定されたデータをダイレクトに取り出し、検索処理部46に迅速に返すことが可能となる。
しかも、インデックスはハードディスクよりも高速な動作が可能なSSDに格納されているため、APサーバ16がインデックスを参照する際のDISK/IOを低減することができる。
【００６７】
なお、インデックスは上記の通り夜間バッチにて生成されるため、当日分データについてはインデックスが用意されていない。このため、当日分データを取得する必要がある場合、検索処理部46は主キーを指定することなく、検索条件を指定したSQL文をDBサーバ18に発行する。
【００６８】
このシステム10においては、上記の通り、個々のレコードに関して更新や削除が生じることがなく、新規レコードの追加のみが許容される仕組みを採用しているため、DBサーバ18において当日分データと過去分データを明確に分離することが可能となる。
【００６９】
図１３は、各DBサーバ18の内部構造をより詳細に示すものであり、メモリ上に設けられたバッファ・キャッシュ領域70と、データベース管理システム（RDBMS）61と、OS（Linux／登録商標）72と、テーブル記憶領域74と、更新ログ記憶領域76とが描かれている。
ここでテーブル記憶領域74は、ハードディスク（HDD）内に設けられており、上記した顧客管理テーブル24や予約管理テーブル26等が格納されている。また更新ログ記憶領域76は、OSによってメモリ（tmpfs）内に設けられている。
【００７０】
この図に示されているように、DBサーバ18においては一般に、テーブル内のデータはブロック78単位でテーブル記憶領域74からバッファ・キャッシュ領域70に取り出されると共に、バッファ・キャッシュ領域70に書き込まれたデータはブロック78単位でテーブル記憶領域74に格納される。
このため、上記のように各テーブルに格納されるレコードの構造が極限まで簡素化されていると、１つのブロック78に収納できるレコード数を増やすことが可能となり、その分、DBサーバ18における処理の効率化を実現することが可能となる。
【００７１】
また、更新ログ79をハードディスクよりも高速に動作するメモリ上に設けられた更新ログ記憶領域76に格納することにより、その分DISK/IOを削減することが可能となり、DBサーバ18における処理のさらなる高速化を実現可能となる。
【００７２】
ところで、更新ログ79はDBサーバ18に何らかのトラブルが発生した場合に、データを復旧させるための最後の拠り所となる重要な構成要素であるため、通常は電源OFFによってデータが消失してしまうメモリ上に設けられることはない。
これに対し、このシステム10の場合には、上記のようにDBサーバ18が拠点毎に物理的に複数台設けられており、各DBサーバ18には同一内容のデータが保存される仕組みを備えているため、データ消失の危険を有効に分散させることが可能となる。
【００７３】
しかも、各テーブルにはデータの更新や削除が許容されないというルールが適用されているため、一のDBサーバ18の更新ログが消失してしまい、他のDBサーバ18の更新ログに基づいてデータを復旧させる必要性が生じた場合であっても、ハードディスクに格納された既存のデータとの間で整合性を確保する必要がなく、新たに追加された当日分のデータのみを追記させれば済むという利点も生じる。因みに、この復旧が完了するまでの間、当該DBサーバ18についてはWRITE ONLY状態（データの書き込み可／読み込み不可）に置かれる。
【００７４】
なお、上記の更新ログ記憶領域76は、上記のように各DBサーバ18のOSによってメモリ上に設定されると共に、更新ログの格納処理もOSの機能によって実現される仕組みであるため、DBサーバ用のアプリケーションプログラムがクラッシュ等しても、OSがダウンしない限り当該DBサーバ内で復旧可能である。
【図面の簡単な説明】
【００７５】
【図１】この発明に係るデータ管理システムの全体構成を示す模式図である。
【図２】DBサーバに格納されたテーブルを例示する図である。
【図３】クライアント端末から送信されたデータ追加のリクエストが、DBサーバに送信される場面での機能構成を示すブロック図である。
【図４】検索リクエストがDBサーバに送信される場面での機能構成を示すブロック図である。
【図５】DBサーバから検索結果が送信される場面での機能構成を示すブロック図である。
【図６】CPUコアとスレッドとの対応関係を示す模式図である。
【図７】データ追加時の処理手順を示すフローチャートである。
【図８】データ検索時の処理手順を示すフローチャートである。
【図９】データ検索時の処理手順を示すフローチャートである。
【図１０】データ検索時の処理手順を示すフローチャートである。
【図１１】共通のデータを保持した複数のDBサーバから、それぞれ別個のデータを分散取得する様子を示す模式図である。
【図１２】この発明に係るデータ管理システムにインデックスサーバを追加した例を示すブロック図である。
【図１３】DBサーバの内部構造を示す模式図である。
【符号の説明】
【００７６】
10 データ管理システム
12 管理サーバ
14a 拠点
14b 拠点
16 APサーバ
18 DBサーバ
20 通信ネットワーク
22 クライアント端末
24 顧客管理テーブル
26 予約管理テーブル
28 売上管理テーブル
30 予約取消管理テーブル
32 請求管理テーブル
34 追加データ受付部
36 追加データ送信部
38 追加データ複製部
40 登録処理部
42 検索条件送信部
44 検索処理部
44 検索条件分割部
46 検索処理部
47 データ加工部
48 検索結果統合部
50 検索結果送信部
52 CPUコア
54 スレッド
56 スレッドプール
58 タスク
60 インデックスサーバ
61 データベース管理システム
62 当日分データ記憶領域
63 過去分データ記憶領域
64 インデックス生成部
65 インデックス記憶部
66 インデックス提供部
70 キャッシュ領域
74 テーブル記憶領域
76 更新ログ記憶領域
78 ブロック
79 更新ログ
【図１】
2013235328.tif 000003
【図２】
2013235328.tif 000004
【図３】
2013235328.tif 000005
【図４】
2013235328.tif 000006
【図５】
2013235328.tif 000007
【図６】
2013235328.tif 000008
【図７】
2013235328.tif 000009
【図８】
2013235328.tif 000010
【図９】
2013235328.tif 000011
【図１０】
2013235328.tif 000012
【図１１】
2013235328.tif 000013
【図１２】
2013235328.tif 000014
【図１３】
2013235328.tif 000015