(57)【特許請求の範囲】
【請求項１】
複数のデータベースサーバと、各データベースサーバにネットワークを介して接続されたアプリケーションサーバとからなるデータ利用システムであって、
上記の各データベースサーバは、DB管理システムと、各種テーブルが格納される外部記憶装置を備えており、
上記の各テーブルには、データの更新及び削除が禁止される制約が設けられており、
上記アプリケーションサーバは、登録処理部及び検索処理部を備えており、
上記登録処理部は、複数のデータベースサーバがそれぞれ管理している異なるテーブルに対し相互に関連する複数データの組合せの追加を求める登録リクエストが入力された場合に、対応のテーブルを備えた各データベースサーバに対応データの追加登録を求めるSQLを発行する処理と、何れかのデータベースサーバの外部記憶装置に設けられた関連テーブルに対して各追加データのIDの登録を求めるSQLを生成し、当該関連テーブルを管理するデータベースサーバに発行する処理を実行し、
上記検索処理部は、複数のデータベースサーバの外部記憶装置に格納されている異なるテーブルから相互に関連する複数データの組合せの抽出を求める検索条件が入力された場合に、上記関連テーブルを参照して抽出対象となる各データのIDを特定する処理と、対応のデータベースサーバが管理している各テーブルを参照し、必要なデータの組合せが揃っているか否かを確認する処理と、必要なデータの組合せが全て揃っている場合には各データベースサーバにSQLを発行して対応データの抽出を指令し、必要なデータの組合せが揃っていない場合には当該データの組合せを抽出対象から除外する処理を実行することを特徴とするデータ利用システム。
【請求項２】
上記の各データベースサーバは、複数のDB系統に分類されており、
同一のDB系統に属する複数のデータベースサーバの外部記憶装置には、相互に等しいデータを保持した共通のテーブルがそれぞれ格納されており、異なるDB系統に属するデータベースサーバの外部記憶装置には、異なるデータを保持した別個のテーブルがそれぞれ格納されており、
上記アプリケーションサーバは、追加データ受付部と、複数の上記登録処理部と、検索条件分割処理部と、複数の上記検索処理部と、複数のデータ加工処理部と、検索結果統合処理部とを備え、
上記追加データ受付部は、複数のDB系統に属する異なるテーブルに対し相互に関連する複数データの組合せの追加を求める登録リクエストが入力された場合に、入力された複数データの組合せのコピーと、異なるDB系統に属する複数のデータベースサーバの特定情報を含むデータ追加リクエストを上記の各登録処理部に割り当てる処理を実行し、
各登録処理部は、対応データの追加登録を求めるSQLを自己に割り当てられた各データベースサーバに発行する処理と、各追加データのIDの登録を求めるSQLを生成し、各データベースサーバの中で上記関連テーブルを管理するデータベースサーバに発行する処理を実行し、
上記検索条件分割処理部は、異なるDB系統に属する複数のテーブルから相互に関連する複数データの組合せの抽出を求める検索条件が入力された場合に、この検索条件を解析して複数の検索条件に分割すると共に、分割された各検索条件及び異なるDB系統に属する各データベースサーバの特定情報を上記複数の検索処理部に割り当てる処理を実行し、
各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、自己に割り当てられた各データベースサーバに発行する処理と、各データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、
上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴とする請求項１に記載のデータ利用システム。
【請求項３】
上記検索条件分割処理部は、入力された検索条件が時間的な範囲を含んでいる場合に、これをより短い時間的な範囲に分割することを特徴とする請求項２に記載のデータ利用システム。
【請求項４】
上記検索条件分割処理部は、入力された検索条件が地域的な範囲を含んでいる場合に、これをより狭い地域的な範囲に分割することを特徴とする請求項２に記載のデータ利用システム。
【請求項５】
請求項１〜４の何れかに記載のデータ利用システムであって、
インデックス生成部及びインデックス記憶部を有するインデックスサーバを備えており、
また上記の各データベースサーバは、暫定記憶領域及び永続記憶領域を備えており、
上記DB管理システムは、上記アプリケーションサーバから送信された追加データを上記暫定記憶領域に格納する処理と、所定の時間間隔で暫定記憶領域内の追加データを上記永続記憶領域に移動する処理を実行し、
上記インデックスサーバのインデックス生成部は、所定の時間間隔で上記データベースサーバの暫定記憶領域に格納された追加データを取得する処理と、この追加データに基づいてインデックスを生成し、上記インデックス記憶部に格納する処理を実行し、
上記アプリケーションサーバの検索処理部は、自己に割り当てられた検索条件に対応した上記SQLを生成するに際し、上記インデックスサーバのインデックス記憶部を参照し、検索条件に該当する各データの主キーを取得する処理と、この主キーによって取得データを指定したSQLを生成する処理を実行することを特徴とするデータ利用システム。
【請求項６】
上記の各データベースサーバは、メモリ上に設けられた更新ログ記憶領域を備えており、
各データベースサーバのOSが、上記アプリケーションサーバから送信された追加データを上記更新ログ記憶領域に順次格納する処理を実行することを特徴とする請求項２〜５の何れかに記載のデータ利用システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はデータ利用システムに係り、特に、アプリケーションサーバとデータベースサーバとの連携により、データベースサーバに格納されたデータの利用を効率化する技術に関する。
【背景技術】
【０００２】
巨大流通チェーンのように、大規模な業務システムを構築し、日々運用している企業においては、データベースサーバ（以下「DBサーバ」）が多数のテーブルを管理しており、複数のアプリケーションサーバ（以下「APサーバ」）によって構成されるサブシステム（受発注システム、仕入れシステム、経理システム等）が、上記のテーブルを共同利用する形式をとっている（非特許文献１）。
【０００３】
データベースには、本来的にデータの一元性を維持するという使命があるため、従来は１台のDBサーバで業務に必要な全テーブルを管理することが行われていたが、取扱データ量の増大に伴い、１台のDBサーバで業務に必要なテーブル全てを管理することが物理的に困難となってきた。このため最近では、相互に独立した複数のDBサーバによって、各種テーブルを分散管理することが行われている。
【０００４】
ところで、複数のデータベースに対する更新処理を実行する際には、全てのデータベースに対するコミットが成立しないとデータ相互間に矛盾が生じるため、通常はXAインターフェースの２相コミットと称する調停方式が採用され、データベース相互間の整合性が担保される。
【０００５】
この２相コミットではまず、処理全体を司るマスターサーバが、対象となるDBサーバに対し、コミットが実行可能であるかを問い合わせる。更新準備が整っているDBサーバは「準備完了」の応答を返し、すべてのDBサーバが準備を終えたことを確認した上で、マスターサーバはコミット開始を通知し、データベースが一斉に書き換えられる。書き換え中にいずれかのデータベースで異常が発生した場合、異常が生じたDBサーバは失敗を伝え、マスターサーバはすべてのサーバに処理撤回を通知して、データを復元する「ロールバック」処理を行うよう指示する（非特許文献２）。
【非特許文献１】Webシステム入門／第１回  Webサイトの構成とJ2EEサーバ  インターネットURL：http://www.atmarkit.co.jp/fjava/rensai2/websys01/websys01.html  検索日：２０１１年１０月２０日
【非特許文献２】２相コミット  インターネットURL：http://e-words.jp/w/2E79BB8E382B3E3839FE38383E38388.html  検索日：２０１１年１２月１３日
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記のように、２相コミット方式の採用によって複数のDBサーバ間でデータの整合性を確保することは技術的に可能である。
しかしながら、DBサーバ間の調停を行うトランザクション・マネージャの処理能力がボトルネックとなり、データ処理量が膨大となる大規模システムの基盤としては、信頼性に不安があった。
【０００７】
この発明は、従来のこのような問題を解決するために案出されたものであり、複数のDBサーバによるテーブルの分散管理を前提としつつも、XAインターフェースの２相コミットに依存することなく、データ相互間の整合性を担保可能な技術の実現を目的としている。
【課題を解決するための手段】
【０００８】
上記の目的を達成するため、請求項１に記載したデータ利用システムは、複数のデータベースサーバと、各データベースサーバにネットワークを介して接続されたアプリケーションサーバとからなるデータ利用システムであって、上記の各データベースサーバは、DB管理システムと、各種テーブルが格納される外部記憶装置を備えており、上記の各テーブルには、データの更新及び削除が禁止される制約が設けられており、上記アプリケーションサーバは、登録処理部及び検索処理部を備えており、上記登録処理部は、複数のデータベースサーバがそれぞれ管理している異なるテーブルに対し相互に関連する複数データの組合せの追加を求める登録リクエストが入力された場合に、対応のテーブルを備えた各データベースサーバに対応データの追加登録を求めるSQLを発行する処理と、何れかのデータベースサーバの外部記憶装置に設けられた関連テーブルに対して各追加データのIDの登録を求めるSQLを生成し、当該関連テーブルを管理するデータベースサーバに発行する処理を実行し、上記検索処理部は、複数のデータベースサーバの外部記憶装置に格納されている異なるテーブルから相互に関連する複数データの組合せの抽出を求める検索条件が入力された場合に、上記関連テーブルを参照して抽出対象となる各データのIDを特定する処理と、対応のデータベースサーバが管理している各テーブルを参照し、必要なデータの組合せが揃っているか否かを確認する処理と、必要なデータの組合せが全て揃っている場合には各データベースサーバにSQLを発行して対応データの抽出を指令し、必要なデータの組合せが揃っていない場合には当該データの組合せを抽出対象から除外する処理を実行することを特徴としている。
【０００９】
請求項２に記載したデータ利用システムは、請求項１のシステムを前提とし、さらに、上記の各データベースサーバは複数のDB系統に分類されており、同一のDB系統に属する複数のデータベースサーバの外部記憶装置には、相互に等しいデータを保持した共通のテーブルがそれぞれ格納されており、異なるDB系統に属するデータベースサーバの外部記憶装置には、異なるデータを保持した別個のテーブルがそれぞれ格納されており、上記アプリケーションサーバは、追加データ受付部と、複数の上記登録処理部と、検索条件分割処理部と、複数の上記検索処理部と、複数のデータ加工処理部と、検索結果統合処理部とを備え、上記追加データ受付部は、複数のDB系統に属する異なるテーブルに対し相互に関連する複数データの組合せの追加を求める登録リクエストが入力された場合に、入力された複数データの組合せのコピーと、異なるDB系統に属する複数のデータベースサーバの特定情報を含むデータ追加リクエストを上記の各登録処理部に割り当てる処理を実行し、各登録処理部は、対応データの追加登録を求めるSQLを自己に割り当てられた各データベースサーバに発行する処理と、各追加データのIDの登録を求めるSQLを生成し、各データベースサーバの中で上記関連テーブルを管理するデータベースサーバに発行する処理を実行し、上記検索条件分割処理部は、異なるDB系統に属する複数のテーブルから相互に関連する複数データの組合せの抽出を求める検索条件が入力された場合に、この検索条件を解析して複数の検索条件に分割すると共に、分割された各検索条件及び異なるDB系統に属する各データベースサーバの特定情報を上記複数の検索処理部に割り当てる処理を実行し、各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、自己に割り当てられた各データベースサーバに発行する処理と、各データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴としている。
【００１０】
請求項３に記載したデータ利用システムは、請求項２のシステムを前提とし、さらに上記検索条件分割処理部は、入力された検索条件が時間的な範囲を含んでいる場合に、これをより短い時間的な範囲に分割することを特徴としている。
【００１１】
請求項４に記載したデータ利用システムは、請求項２のシステムを前提とし、さらに上記検索条件分割処理部は、入力された検索条件が地域的な範囲を含んでいる場合に、これをより狭い地域的な範囲に分割することを特徴としている。
【００１２】
請求項５に記載したデータ利用システムは、請求項１〜４のシステムを前提とし、さらに、インデックス生成部及びインデックス記憶部を有するインデックスサーバを備えており、また上記の各データベースサーバは、暫定記憶領域及び永続記憶領域を備えており、上記DB管理システムは、上記アプリケーションサーバから送信された追加データを上記暫定記憶領域に格納する処理と、所定の時間間隔で暫定記憶領域内の追加データを上記永続記憶領域に移動する処理を実行し、上記インデックスサーバのインデックス生成部は、所定の時間間隔で上記データベースサーバの暫定記憶領域に格納された追加データを取得する処理と、この追加データに基づいてインデックスを生成し、上記インデックス記憶部に格納する処理を実行し、上記アプリケーションサーバの検索処理部は、自己に割り当てられた検索条件に対応した上記SQLを生成するに際し、上記インデックスサーバのインデックス記憶部を参照し、検索条件に該当する各データの主キーを取得する処理と、この主キーによって取得データを指定したSQLを生成する処理を実行することを特徴としている。
【００１３】
請求項６に記載したデータ利用システムは、請求項２〜５のシステムを前提とし、さらに、上記の各データベースサーバはメモリ上に設けられた更新ログ記憶領域を備えており、各データベースサーバのOSが、上記アプリケーションサーバから送信された追加データを上記更新ログ記憶領域に順次格納する処理を実行することを特徴としている。
【発明の効果】
【００１４】
請求項１に記載のデータ利用システムにあっては、複数のデータベースサーバに対してそれぞれ異なるデータを同時に追加登録する際には各データの登録の成否を問題にすることなく、各データを検索する際に関連テーブルを参照して関連データが揃っているか否かを確認し、揃っていない場合には当該データの組合せの追加登録がなかったものとして処理する方式を採用している。
このため、従来のようにXAインターフェースの２相コミットを利用することなく、データ相互間の整合性を検索時に確保することが可能となる。
【００１５】
このデータ利用システムにおいては、テーブルに対する登録処理としてはデータの追加のみが許容され、データの更新や削除が禁止されているため、上記のようなデータ間の整合性確保方式を採用することが可能となる。
すなわち、データの内容変更は必ずデータの追加という形で表現されることから、検索処理部は関連テーブルを参照した結果、あるべきデータが存在しないと判明した時点で、追加処理の失敗と判断することが可能となる。
【００１６】
請求項２に記載のデータ利用システムの場合、各データベースサーバが複数のDB系統に分類されると共に、同一のDB分類に属する複数のデータベースサーバは相互に共通のテーブルを備えており、検索処理時には検索条件が各データベースサーバに分散される仕組みであるため、個々のデータベースサーバにおけるデータ抽出処理が軽減される結果、システム全体の処理速度を向上させることができる。
【００１７】
しかも、アプリケーションサーバにおいては、入力された検索条件が複数に分割され、それぞれ複数の検索処理部を介してデータベースサーバにデータの検索依頼が送信されると共に、データベースサーバから各検索処理部に対して返された検索結果データに対しても、一定量単位で複数のデータ加工処理部による並列処理が実行されるため、データベースサーバから大量のデータが送信される場合であっても、多数のCPUコアを用いることで効率的な処理が可能となる。また、このようにデータベースサーバからの検索結果データが全て揃うまで待機することなく、一定量のデータが揃った時点で部分的な加工処理に移行することにより、データベースサーバ側のDISK/IOによる遅延を緩和することも可能となる。
【００１８】
これまで、DNA解析や気象解析のように純粋な演算処理を主体とした科学技術計算と異なり、データベースに蓄積された大量のデータを参照する必要のある業務系処理の場合には、データベースサーバからの応答を待つDISK/IOがボトルネックとなるため、アプリケーションサーバ側のCPUコアの数を増やしたとしても、直ちに処理速度の向上には結びつかないという問題があった。
これに対し、上記のような仕組みをアプリケーションサーバに設けることにより、テーブルの正規化の追求に伴うデータベースサーバ側の負担増を、アプリケーションサーバ側の処理の効率化によってカバーすることが可能となる。
【００１９】
請求項５に記載のデータ利用システムの場合、インデックス（二次索引）の作成処理が外部の独立したインデックスサーバに移譲されているため、これに纏わるデータベースサーバ側の負担を解消することができる。
しかも、データ参照時には個々のデータの主キーを指定した形のSQLがアプリケーションサーバから発行されるため、データベースサーバ側でテーブルをソートする必要がなくなり、その分、データベースサーバの負荷を低減することができる。
【００２０】
請求項６に記載のデータ利用システムの場合、データベースサーバの更新ログがメモリ上に格納される機構を備えているため、更新ログをディスク上に格納する場合に比べて、データベースサーバ側のDISK/IOを低減することができる。
この更新ログ記憶領域は、各データベースサーバのOSによってメモリ上に設定されると共に、更新ログの格納処理もOSの機能によって実現される仕組みであるため、データベースサーバ用のアプリケーションプログラムが機能停止しても、OSがダウンしない限り復旧は可能である。
しかも、データベースサーバが物理的に複数台用意されると共に、各データベースサーバにおいては同一の追加データが更新ログとして更新ログ記憶領域に蓄積される仕組みであるため、停電等の事故によって一のデータベースサーバにおいて更新ログが消えてしまった場合でも、他のデータベースサーバに格納された更新ログによって容易に復旧可能となる。
【発明を実施するための最良の形態】
【００２１】
図１は、この発明に係るデータ利用システム10の全体構成を示す模式図であり、ロードバランサ13と、Webサーバ12と、複数のAPサーバ14と、複数のDBサーバ16とを備えている。
Webサーバ12には、インターネット17を介してクライアント端末18が接続されている。
【００２２】
各DBサーバ16は、DB管理システム（RDBMS）と、複数のテーブル群を格納した外部記憶装置19を備えている。
図２に示すように、各DBサーバ16は複数のDB系統に分類されており、同一のDB系統に属するDBサーバ16の外部記憶装置19には、相互に共通するデータを格納した複数のテーブルが格納されている。また、DB系統を異にするDBサーバ16間では、それぞれ異なるテーブルが外部記憶装置19に格納されている。
同一のDB系統に属するDBサーバ16の中の少なくとも一部は、データ保全の観点から遠隔地に配置されている。
図においては２つのDB系統（DBα系統及びDBβ系統）が例示されているが、さらに多くのDB系統を設けることができる。
【００２３】
最初に、本システム10における処理内容の概略について説明し、個々の具体的な構成や処理内容については後に詳説する。
まず、クライアント端末18にはWebサーバ12からデータ利用画面が送信され、Webブラウザ上に表示される（図示省略）。
そして、ユーザがこのデータ利用画面を通じて検索条件を指定し、データの検索をリクエストすると、Webサーバ12からAPサーバ14に対して検索リクエストが送信される。この際、ロードバランサ13を介して、最も負荷の小さい一のAPサーバ14に対して、検索リクエストが振り分けられる。
【００２４】
この検索リクエストを受け取ったAPサーバ14は、検索条件を論理的に複数に分割し、分割された検索条件に対応した複数のSQLを、対応のテーブルを備えたDB系統に属するDBサーバ16に発行し、検索条件に合致するデータの抽出を依頼する。
これを受けた各DBサーバ16は、SQLで指定されたデータを抽出し、APサーバ14に送信する。
【００２５】
APサーバ14は、各DBサーバ16から受け取ったデータを統合し、Webサーバ12に送信する。
これに対しWebサーバ12は、APサーバ14から受け取った検索結果データを表示する画面（図示省略）を生成し、クライアント端末18に送信する。
【００２６】
また、クライアント端末18からデータ追加のリクエストがWebサーバ12に送信された場合、ロードバランサ13によって選択された一のAPサーバ14に当該リクエストが送信される。
これを受けたAPサーバ14は、対応のテーブルを備えたDB系統に属する全DBサーバ16に対して同一のSQLを発行し、同データの追加を依頼する。
これに対し各DBサーバ16は、上記追加データを対応のテーブルに格納する処理を実行する。
【００２７】
図３は、クライアント端末18から送信された検索リクエストが、Webサーバ12及びAPサーバ14を経由してDBサーバ16に送信される場面での機能構成を表しており、APサーバ14は、検索条件分割処理部20と、複数の検索処理部22を備えている。
【００２８】
また図４は、DBサーバ16から検索結果が送信される場面での機能構成を表しており、APサーバ14は、各検索処理部22単位で複数割り当てられたデータ加工処理部24と、検索結果統合処理部26を備えている。
【００２９】
図５は、クライアント端末18から送信されたデータ追加のリクエストが、DBサーバ16に送信される場面での機能構成を表しており、APサーバ14は、追加データ受付部27と、複数の登録処理部28を備えている。
【００３０】
APサーバ14内に設けられた上記の検索条件分割処理部20、複数の検索処理部22、複数のデータ加工処理部24、検索結果統合処理部26、追加データ受付部27、複数の登録処理部28は、APサーバ14に搭載された多数のCPUコアが、専用のアプリケーションプログラムに従って所定の処理を実行することで実現されるのであるが、この際、OSによって複数のスレッドが起動されて各CPUコアに割り当てられることにより、マルチタスク処理が実現される。
【００３１】
図６は、各CPUコア30とスレッド32との対応関係を表しており、各スレッド32にはスレッドプール34が設けられ、そこに配置された複数のタスク36をスレッド32が順次処理していくイメージが描かれている。
この図におけるスレッド32が、図３〜図５に表された検索条件分割処理部20、複数の検索処理部22、複数のデータ加工処理部24、検索結果統合処理部26、追加データ受付部27、複数の登録処理部28として機能し、これらの機能構成部が実行する具体的な処理がタスク36に相当する。
【００３２】
各スレッド32は、スレッドプール34に蓄積されたタスクを古い順に次々と実行していき、自己のスレッドプール34が空になった場合には、他のスレッド32のスレッドプール34に蓄積されたタスク36を、新しい順に実行していく。
【００３３】
つぎに、図７〜図１０のフローチャートに従い、このシステム10における処理手順を詳細に説明する。
まず、図７に従い、検索条件分割処理部20による処理手順を説明する。
すなわち、クライアント端末18から送信された検索条件をWebサーバ12経由でAPサーバ14が受信すると（Ｓ10）、検索条件分割処理部20は検索条件を解析し、検索条件の内容に応じて複数の検索条件に分割する（Ｓ12）。
【００３４】
ここで分割の基準となるのは、時間（日、週、月、年等）や地域（都道府県、市町村等）など、検索対象データを論理的に複数に区分できるものが該当する。
例えば、「2010年における全チェーン店の売上を集計する」という検索条件が与えられた場合に、「2010年１月分の全チェーン店の売上」、「2010年２月の全チェーン店の売上」、「2010年３月の全チェーン店の売上」…というように、年を月単位に１２分割することが該当する。
また、各チェーン店の所在地データに着目し、「2010年における東京所在チェーン店の売上」、「2010年における北海道所在チェーン店の売上」、「2010年における沖縄所在チェーン店の売上」…というように、全国を都道府県単位に４７分割することも該当する。
もちろん、「2010年１月分の東京所在チェーン店の売上」や「2010年１月の北海道所在チェーン店の売上」のように、月×都道府県単位で５６４分割することもできる。
【００３５】
これらの分割基準は、クライアント端末18から発せられると予測される検索条件や、対象となるデータの量等に鑑みて、事前に幾つかの分割パターンがプログラム設計者によって策定され、検索条件分割処理部20を実現するためのプログラム中にコーディングされている。
【００３６】
ここでは、都道府県単位で４７分割されたものとして話を進める。
すなわち、検索条件分割処理部20は、４７個の検索処理部22に対して、上記都道府県単位の検索処理と、対応DBサーバ16を割り当てる（Ｓ14）。
【００３７】
つぎに図８に従い、各検索処理部22における処理手順を説明する。
まず検索処理部22は、自己に割り当てられた検索処理に必要な都道府県を指定したSQLを自動生成し、自己に割り当てられた特定のDBサーバ16に対して発行する（Ｓ20）。
【００３８】
ここで検索処理部22は、対応のDBサーバ16から全ての検索結果データが送信されるのを待つことなく、予め設定された一定量（例えばレコード1,000件分）のデータが送信された時点で（Ｓ22／Ｙ）、必要な演算処理を複数のデータ加工処理部24に割り当てる（Ｓ24）。
この結果、一部のデータ加工処理部24は、受信データをキー項目でソートすると共に、キー項目の値に基づいて複数のデータに分割する処理を実行する。また、他のデータ加工処理部24は、分割されたデータに基づく値の集計処理や、当該値を指定したデータの抽出をDBサーバ16に依頼する処理などを実行する。
受信データの分割手法については後に例示するが、検索条件の内容に応じて論理的に分割する検索条件分割処理部20による分割と異なり、受信データの値や分量に応じた分割手法となる。データ加工処理部24による具体的な処理についても、後に例示する。
【００３９】
検索処理部22は、データ加工処理部24から処理結果データが返信された時点で（Ｓ26／Ｙ）、この単位データ量当たりの処理結果をメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除する（Ｓ28）。
各検索処理部22は、DBサーバ16からのデータ送信が完了するまで、DBサーバ16から送信されるデータが一定量に達する度にＳ24〜Ｓ28の処理を繰り返す（Ｓ30／Ｎ、Ｓ22／Ｙ）。
そして、DBサーバ16からのデータ送信が完了し、Ｓ24〜Ｓ28の最後の処理が完了した時点で（Ｓ30／Ｙ）、検索処理部22はこれまでの部分的な処理結果の集計値を集計し（Ｓ32）、検索結果統合処理部26に集計結果を出力する（Ｓ34）。
【００４０】
つぎに図９に従い、検索結果統合処理部26による処理手順を説明する。
まず検索結果統合処理部26は、各検索処理部22から集計結果が送信される度に、全ての検索処理部22からの集計結果が揃ったか否かをチェックし（Ｓ40、Ｓ42）、全てが揃った段階で全検索処理部の集計結果を集計する（Ｓ44）。
そして、その最終的な集計結果をWebサーバ12に送信する（Ｓ46）。
Webサーバ12は、この集計結果を含むWebファイルを生成し、クライアント端末18に送信することになる。
【００４１】
つぎに図１０に従い、データ追加時におけるAPサーバ14側の処理手順を説明する。
まず、クライアント端末18から送信されたデータ追加のリクエストをWebサーバ12経由でAPサーバ14が受信すると（Ｓ50）、追加データ受付部27が対応のDB系統に属するDBサーバ16の数に対応した登録処理部28を起動させ、それぞれに担当DBサーバ16の特定情報及び追加データを渡す（Ｓ52）。
これを受けた各登録処理部28は、自己が担当するDBサーバ16に対して上記の追加データの登録を求めるSQLを発行する（Ｓ54）。
これを受けた各DBサーバ16は、対応のテーブルに対して一斉にデータを追加する。この結果、同一のDB系統に属する各DBサーバ16間においてデータの同一性が確保される。
【００４２】
図１１は、各DBサーバ16に格納されたテーブル群の具体例を示しており、顧客管理テーブル40と、予約管理テーブル42と、売上管理テーブル44と、予約取消管理テーブル46と、請求管理テーブル48とによって、各店舗の売り上げが管理されている。各テーブルは、同一DB系統に属するDBサーバ16にまとめて格納されていている場合もあるが、異なるDB系統に属するDBサーバ16に分散配置されていてもよい。
【００４３】
顧客管理テーブル40は、「顧客ID（主キー）」及び「地域」のデータ項目を備えている。
また、予約管理テーブル42は、「予約ID（主キー）」、「店ID」、「顧客ID（外部キー）」、「金額」及び「予約年月日」のデータ項目を備えている。
売上管理テーブル44は、「予約ID（主キー／外部キー）」及び「売上年月日」のデータ項目を備えている。
予約取消管理テーブル46は、「予約ID（主キー／外部キー）」及び「予約取消年月日」のデータ項目を備えている。
請求管理テーブル48は、「請求ID（主キー）」、「請求年月日」及び「予約ID（外部キー）」のデータ項目を備えている。
【００４４】
上記の各テーブル40〜48には、以下の(1)〜(3)の制約が予め課せられている。
(1)キー項目は一つに限定される。
したがって、複数の項目の組合せによってキー項目を構成すること（複合キー）は、禁止される。
【００４５】
(2)各テーブルにはレコードの追加のみが許容され、既存レコードの値の更新及びレコードの削除は禁止される。
したがって、値に変更が生じた場合など、発生タイミングの異なる情報は別テーブルに格納されることとなる（詳細は後述）。
なお、「レコードの削除」とは、通常のデータ処理の一環としてレコードを削除することを意味しており、外部記憶装置の空き容量を増やすために所定のタイミングで不要なレコードを引き落とし（一括削除）することまでも禁止されるものではない。
【００４６】
(3)各テーブルのカラムには、NULL値禁止制約、フラグ値禁止制約、区分値禁止制約が課せられる。
まず「NULL値禁止制約」とは、データ項目の値としてNULL（値なし）を充填することが禁止されることを意味しており、このようなNULL値の充填を想定したデータ項目の設定自体が許容されないことになる。
つぎに「フラグ値禁止制約」とは、データ項目の値としてフラグ値（「１／０」、「ON／OFF」、「TRUE／FALSE」等の２値データ）を充填することが禁止されることを意味しており、このようなフラグ値の充填を想定したデータ項目の設定自体が許容されないことになる。
「区分値禁止制約」とは、データ項目の値として区分値（「１：正社員」、「２：パート」、「３：アルバイト」等）を充填することが禁止されることを意味しており、このような区分値の充填を想定したデータ項目の設定自体が許容されないことになる。
【００４７】
これらの制約ルールは、新規テーブルの設計時やSQL発行時に、DBサーバ16のデータ管理システム（RDBMS）によって適否がチェックされ、制約ルールに違反する処理の実行が拒絶されることにより、その実効性が担保される。
【００４８】
図１１より明らかなように、各テーブルは単一のデータ項目によって主キー（PK）が構成されている。
また、「予約取消」に関するデータも、通常であれば予約管理テーブル42において「予約取消フラグ」等のデータ項目が設けられ、各レコードに「１／０」等のフラグ値を充填することで状態が管理されるところであるが、予約取消管理テーブル46を予約管理テーブル42とは別個に設けることにより、予約取消の状態管理がなされている。すなわち、この予約取消管理テーブル46に登録された予約IDが「予約取消」状態にあることとなり、レコードの有無によって予約取消の有無が表現されている。
【００４９】
各テーブルには上記(2)の制約（値の更新禁止）が課せられているため、例えばある顧客の「地域」に変動が生じた場合でも、顧客管理テーブル40における該当レコードの「地域」の値が書き換えられることはない。
図示は省略したが、このような場合には例えば「顧客ID」、「変更地域」、「変更年月日」等のデータ項目を備えた「顧客地域変更管理テーブル」が新たに設けられて、当該顧客の顧客ID、変更後の地域、変更年月日が格納される。
【００５０】
この結果、顧客の地域別に売上を集計する必要が生じた場合、APサーバ14側では顧客管理テーブル40を参照して各顧客の地域情報を取得した後、顧客地域変更管理テーブルを参照して地域変更の生じた顧客を特定し、変更後の地域に差し替える処理を実行することになる。
【００５１】
このようなテーブルがDBサーバ16において管理されている場合に、クライアント端末18から「Ａ店の８月分の請求額を地域毎に集計せよ」という内容の検索リクエストが送信された場合、検索条件分割処理部20は、まず「８月＝３１日間」というカレンダー情報に従い、「８月１日分」、「８月２日分」、「８月３日分」…「８月３１日分」というように、検索条件を３１分割する。
【００５２】
つぎに検索条件分割処理部20は、これらの分割された検索条件（「Ａ店の８月１日分の請求額を地域毎に集計せよ」等）を３１個の検索処理部22に割り当てる。
【００５３】
これを受けた各検索処理部22は、自己に割り当てられた請求日を指定した、請求管理テーブル48から請求データを取得するためのSQLを生成し、自己が担当するDBサーバ16に発行する。
そして、DBサーバ16から該当日の請求年月日を備えた請求データが送信されると、検索処理部22は一定量のデータ（例えば1,000件のレコード相当分）単位で受信データを分割し、複数のデータ加工処理部24に以下の処理を割り当てる。
(1)各請求データの「予約ID」を指定したSQLを生成してDBサーバ16に発行し、「予約管理テーブル42」から対応の予約データを取得する。
(2)送信された予約データの中で、該当店舗の「店ID」を有するデータのみを抽出し、他の店IDのデータを除外する。
(3)各予約データの「顧客ID」を指定したSQLを生成してDBサーバ16に発行し、顧客管理テーブル40から対応の顧客データを取得する。
(4)顧客データの「地域」毎に、予約データ中の「金額」の値を集計する。
これら(1)〜(4)の処理は、具体的にはタスク36として各データ加工処理部24のスレッドプール34に配置される。
【００５４】
検索処理部22は、データ加工処理部24から上がってきた1,OOO件単位の処理結果データをメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除する。そして、１日分の処理結果データが揃った時点で、全処理結果データを集計する。この集計結果は、検索結果統合処理部26に出力される。
検索結果統合処理部26は、全検索処理部22から８月１日〜８月３１日までの全集計結果が集まった時点でこれらを集計し、Webサーバ12に出力する。
【００５５】
このシステム10の場合、DBサーバ16からのフェッチが完了するまでAPサーバ14が待つことはなく、一定量のデータを受信する度に複数のデータ加工処理部24による処理が開始される仕組みであるため、DBサーバ16のDISK/IOによるボトルネックを解消することができる。
【００５６】
また、APサーバ14における部分的な集計が完了する度に、DBサーバ16から送信されたデータが占めていたメモリが解放され、データ量が格段に小さな集計結果データのみがメモリに格納される仕組みであるため、APサーバ14のメモリが大きなデータに占拠され続けることを回避できる。
【００５７】
さらに、各検索処理部22は、それぞれ別個のDBサーバ16に対しSQLを分散して発行するため、個々のDBサーバ16における処理の負担が必然的に低減することとなり、全体の処理速度を高速化することができる。
上記の通り、同一DB系統に属する各DBサーバ16は同じ内容のデータを保持しているため、検索処理部22にDBサーバ16を割り振る際にはDBサーバ16毎の特性を考慮することなく、機械的に対応付けることができる。
【００５８】
なお、処理速度の向上という観点からは、分割した検索条件と等しい数の検索処理部22及びDBサーバ16を用意することが望ましいが、検索処理部及びDBサーバ16に数はこれに限定されるものではない。
例えば、分割された検索条件が31個あり、検索処理部が31個設けられたにもかかわらず、DBサーバ16が物理的に10台しか用意されていない場合には、各DBサーバ16に対して３〜４個の検索条件が割り振られることになる。この場合でも、１台のDBサーバ16のみで全てを処理する場合に比べ、大幅な高速化が期待できる。
【００５９】
ここで、図１２を参照して、DBサーバ16から送信された一定量単位のデータに対する分割手順について説明する。
まず一のデータ加工処理部24は、DBサーバ16から送信されたデータを２等分する位置を探索し、そこから前方不一致検索によってキー項目の変わり目を探しだし、データを２分割させる。
例えば、(a)のデータ列はキー項目の値が１〜６があるが、データ加工処理部24は「３」と「４」との間を境にこれを２分割させ、(b)及び(c)のデータ列を生成する。
【００６０】
つぎに、他のデータ加工処理部24は、(b)のデータ列を「２」と「３」との間で２分割させ、(d)及び(e)のデータ列を生成する。
この時点で、(e)のデータ列のキー項目の値は「３」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(e)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００６１】
これに対し、(d)のデータ列の場合には「１」と「２」の間で２分割可能であるため、データ加工処理部24はここでデータ列を２分割させ、(h)及び(i)のデータ列を生成する。
この時点で、(h)のデータ列のキー項目の値は「１」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(h)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
同様に、(i)のデータ列のキー項目の値は「２」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(i)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００６２】
一方、(c)のデータ列については、他のデータ加工処理部24が「５」と「６」との間で２分割させ、(f)及び(g)のデータ列を生成する。
この時点で、(g)のデータ列のキー項目の値は「６」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(g)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００６３】
これに対し、(f)のデータ列の場合には「４」と「５」の間で２分割可能であるため、データ加工処理部24はここでデータ列を２分割させ、(j)及び(k)のデータ列を生成する。
この時点で、(j)のデータ列のキー項目の値は「４」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(j)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
同様に、(k)のデータ列のキー項目の値は「５」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(k)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
【００６４】
図１２の例では、説明の便宜上簡略化されたデータ列を例示したが、各データ加工処理部24は、実際にはDBサーバ16から送信された一定量（例えばレコード1,000件分）のデータ列に対して、ソートやマッチング、コントロールブレイクの都度、上記の分割処理を実行する。
この結果、大量のデータに対して複数のデータ加工処理部24による並列処理が可能となり、APサーバ14に複数搭載されたCPUコアの有効利用が可能となる。
このデータ加工処理部24による分割処理に際し、分割の回数（階層の深さ）に一定の限度を設けることもできる。
【００６５】
上記のように、データ加工処理部24は検索処理部22から渡されたデータ列の特定のデータ項目の値を指定してDBサーバ16にSQLを発行し、検索処理を依頼する場合があるため、必然的にDBサーバ16からの応答待ち（I/O Wait）が発生することになる。
【００６６】
そこで図１３に示すように、各スレッド32にI/O Waitを伴う処理用の第１のスレッドプール50と、I/O Waitを伴わない処理用の第２のスレッドプール52を設けることが望ましい。
この結果、第１のスレッドプール50に配置されたタスク36の実行によってI/O Waitが発生した場合、スレッド32は第２のスレッドプール52に配置されたタスク36を待ち時間の間に処理することが可能となり、処理の効率化を図ることが可能となる。
【００６７】
この発明にあっては、上記のようにDBサーバ16が管理する各テーブルの構造が極限まで単純化される分、テーブルの数が増え、SQLの発行数自体は増大するが、演算処理は多数のCPUコアを用いた並列処理によって高速化されたAPサーバ14側で行われ、DBサーバ16は単純化されたデータの管理（インサートとセレクト）に専念でき、データの更新や削除から解放されるため、DBサーバ16の負担は大幅に軽減される。
しかも、DBサーバ16は筐体レベルで複数台用意され、検索時にはデータの抽出処理がそれぞれに分散される。
このため、テーブルの正規化の追求に伴いDBサーバ16側の処理速度が低下することを、有効に回避できる。
【００６８】
また、フラグ値や区分値のように、特殊なビジネスルールに基づいた値の格納が禁止される結果、データモデルの見通しが良好となり、テスト・データの作成効率が向上するという効果も期待できる。
【００６９】
図１４に示すように、各DBサーバ16と各APサーバ14との間にインデックスサーバ60を設けることにより、このシステム10における検索処理をより高速化することができる。
この場合、各DBサーバ16は、DB管理システム（RDBMS）61と、当日分データ記憶領域（暫定記憶領域）62と、過去分データ記憶領域（永続記憶領域）63とを備える。
【００７０】
また、インデックスサーバ60は、インデックス生成部64と、インデックス記憶部65と、インデックス提供部66とを備えている。
インデックス生成部64及びインデックス提供部66は、インデックスサーバ60のCPUが専用のプログラムに従って動作することにより実現され、インデックス記憶部65は、インデックスサーバ60のSSD（Solid State Drive）内に設けられている。
【００７１】
APサーバ14の登録処理部28から送信された追加データは、DBサーバ16のDB管理システム61によって当日分データ記憶領域62に一旦格納された後、夜間バッチ処理によって過去分データ記憶領域63に移される。
また、インデックスサーバ60のインデックス生成部64は、夜間バッチ処理により、DB管理システム61から当日分データ記憶領域62内に格納された追加データを取得し、追加分のインデックスを作成した後、インデックス記憶部65に格納する。
【００７２】
この場合、APサーバ14の各検索処理部22は、各DBサーバ16に対してSQLを発行するに際し、インデックスサーバ60のインデックス提供部66を介してインデックス記憶部65を参照し、過去分データ記憶領域63に格納されたデータに関しては、検索条件の範囲に含まれる個々のデータの主キーを取得した後、個々の主キーを特定したSQLを生成する。
【００７３】
例えば、Webサーバ12から送信された検索条件が、特定店舗における過去１年分の売上データを取得するものであった場合、検索処理部22はこの条件に合致する全データの主キーをインデックスサーバ60から取得した上で、SQL中にこれらの主キーを記述してDBサーバ16に発行する。
【００７４】
このため、DBサーバ16のDB管理システム61は、データの検索処理を行うことなく、過去分データ記憶領域63に格納された各テーブルから主キーによって指定されたデータをダイレクトに取り出し、検索処理部22に迅速に返すことが可能となる。
しかも、インデックスはハードディスクよりも高速な動作が可能なSSDに格納されているため、APサーバ14がインデックスを参照する際のDISK/IOを低減することができる。
【００７５】
なお、インデックスは上記の通り夜間バッチにて生成されるため、当日分データについてはインデクスが用意されていない。このため、当日分データを取得する必要がある場合、検索処理部22は主キーを指定することなく、検索条件を指定したSQLをDBサーバ16に発行する。
【００７６】
このシステム10においては、上記の通り、個々のレコードに関して更新や削除が生じることがなく、新規レコードの追加のみが許される仕組みを採用しているため、DBサーバ16において当日分データと過去分データを明確に分離することが可能となる。
【００７７】
図１５は、各DBサーバ16の内部構造をより詳細に示すものであり、メモリ上に設けられたバッファ・キャッシュ領域70と、DB管理システム（RDBMS）61と、OS（Linux）72と、テーブル記憶領域74と、更新ログ記憶領域76とが描かれている。
ここでテーブル記憶領域74は、ハードディスク（HDD）内に設けられており、上記した顧客管理テーブル40や予約管理テーブル42等が格納されている。また更新ログ記憶領域76は、OSによってメモリ（tmpfs）内に設けられている。
【００７８】
この図に示されているように、DBサーバ16においては一般に、テーブル内のデータはブロック78単位でテーブル記憶領域74からバッファ・キャッシュ領域70に取り出されると共に、バッファ・キャッシュ領域70に書き込まれたデータはブロック78単位でテーブル記憶領域74に格納される。
このため、上記のように各テーブルに格納されるレコードの構造が極限まで簡素化されていると、１つのブロック78に収納できるレコード数を増やすことが可能となり、その分、DBサーバ16における処理の効率化を実現することが可能となる。
【００７９】
また、更新ログ79をハードディスクよりも高速に動作するメモリ上に設けられた更新ログ記憶領域76に格納することにより、その分DISK/IOを削減することが可能となり、DBサーバ16における処理のさらなる高速化を実現可能となる。
【００８０】
ところで、更新ログ79はDBサーバ16に何らかのトラブルが発生した場合に、データを復旧させるための最後の拠り所となる重要な構成要素であるため、通常は電源OFFによってデータが消失してしまうメモリ上に設けられることはない。
これに対し、このシステム10の場合には、上記のように各DB系統単位でDBサーバ16が物理的に複数台設けられており、DB系統を同じくする各DBサーバ16には同一内容のデータが保存される仕組みを備えているため、データ消失の危険を有効に分散させることが可能となる。
【００８１】
しかも、各テーブルにはデータの更新や削除が許容されないというルールが適用されているため、一のDBサーバ16の更新ログが消失してしまい、他のDBサーバ16の更新ログに基づいてデータを復旧させる必要性が生じた場合であっても、ハードディスクに格納された既存のデータとの間で整合性を確保する必要がなく、新たに追加された当日分のデータのみを追記させれば済むという利点も生じる。因みに、この復旧が完了するまでの間、当該DBサーバ16についてはWRITE ONLY状態（データの書き込み可／読み込み不可）に置かれる。
【００８２】
なお、上記の更新ログ記憶領域76は、上記のように各DBサーバ16のOSによってメモリ上に設定されると共に、更新ログの格納処理もOSの機能によって実現される仕組みであるため、DBサーバ16のデータ管理システム（RDBMS）がクラッシュ等しても、OSがダウンしない限り当該DBサーバ16内で復旧可能である。
【００８３】
このシステム10においては、上記の通り、DBサーバ16が異なる複数のDB系統に分かれており、DB系統毎に異なるテーブルが配置されている。このため、登録処理部28は、データの追加処理に際して異なるDB系統に属する複数のDBサーバ16に対してデータの追加を同時に依頼する場合が生じる。例えば、ユーザの氏名や住所等を管理する基本属性テーブルと、各ユーザの勤務先や趣味等を管理する派生属性テーブルが別個のDB系統に属している場合、新規会員登録に際し各登録処理部28は、２つのDB系統に属する対応のDBサーバ16に対して、それぞれ対応レコードの追加をリクエストするSQLを同時に発行することになる。
【００８４】
このような場合、図１６(a)に示すように、一方のDB系統に属するDBサーバ16においてデータの追加が成功すると同時に、他方のDB系統に属するDBサーバ16におけるデータの追加が失敗するというケースが当然に生じうる。
そして、この直後に登録会員の検索リクエストが発せられると、図１６(b)に示すように、一方のDB系統のデータのみが存在し、他方のDB系統のデータが欠落したデータの組合せが返されてしまう。
【００８５】
このような不正な結果が返されることを防止するため、従来は一方のデータベースに対するコミットが失敗した場合には、コミットに成功した方のデータを削除することにより、更新前の状態に戻すロールバック処理が実行されていた。
これに対し、このシステム10の場合には、データ追加時におけるデータの不整合は許容すると共に、データ参照時にこれを正す方式を採用している。
【００８６】
以下において、このデータ間の整合性確保方式について説明する。
まず、二つのDB系統に格納されたテーブルに対して同時にデータの追加を行う必要がある場合、登録処理部28は何れか一方のDBサーバ16内に設けられた関連テーブルに対して、本来の追加データとは別に、双方のデータの関連性を示すデータを登録する。
【００８７】
図１７はその一例を示すものであり、DBα系統に属するDBサーバ(α2)16内には、商品ID、商品コード、商品名、登録日時のデータ項目を備えた商品テーブル80の他に、商品ID及び店舗IDのデータ項目を備えた関連テーブル81が設けられている。
また、DBβ系統に属するDBサーバ(β2)16内には、店舗ID、店舗コード、店舗名、登録日時のデータ項目を備えた店舗テーブル82が設けられている。
上記の商品ID及び店舗IDは、システム10によって採番されるユニークな人工キーである。
【００８８】
ここで、追加データ受付部27から登録処理部28に対して商品データと店舗データの追加が指令されると、登録処理部28は、関連テーブル81に商品IDと店舗IDを格納することを指令するSQLを生成すると共に、商品テーブル80に商品データの追加を指令するSQLを生成し、DBサーバ(α2)16に発行する。
同時に登録処理部28は、店舗テーブル82に店舗データの追加を指令するSQLを生成し、DBサーバ(β2)16に発行する。
この時点で登録処理部28は、DBサーバ(α2)16及びDBサーバ(β2)16においてデータの追加が成功したか失敗したかについて関知しない。
【００８９】
この直後に、上記商品データ及び店舗データを含む検索条件を指定した検索リクエストがクライアント端末18から発せられると、検索処理部22はまずDBサーバ(α2)16の関連テーブル81を参照し、商品ID及び店舗IDを特定する（Ｓ60）。
つぎに検索処理部22は、DBサーバ(α2)16の商品テーブル80及びDBサーバ(β2)16の店舗テーブル82を参照し、上記の商品ID及び店舗IDに対応するデータの登録があるか否かを確認する（Ｓ62）。
【００９０】
ここで、必要なデータの組合せが揃っていると判定した場合（Ｓ64／Ｙ）、検索処理部22は対応の商品データ及び店舗データを取得するためのSQLをDBサーバ(α2)16及びDBサーバ(β2)16に発行する（Ｓ66）。
これに対し、何れか一方のデータのみが存在し、他方のデータが欠落している場合には、当該データの追加はなかったものと認定し、両データを取得対象から除外する（Ｓ68）。
【００９１】
なお、何れかのテーブルに対するデータの追加が失敗した場合には、その旨の通知がDBサーバ16からAPサーバ14、Webサーバ12を経由してクライアント端末18に戻される。
これに対しユーザは、同一データの組合せの追加登録を再度リクエストすることになる。この結果、前回の追加登録処理が成功している方のテーブルには、同一データが重複登録される結果となるが、この場合には登録日時の新しいものが有効として取り扱われ、登録日時の古いデータの存在は無視される。
【００９２】
図１８は、データ間の整合性確保方式に係る他の例を示すものであり、DBα系統に属するDBサーバ(α2)16内には、ユーザID、氏名、登録日時のデータ項目を備えた会員テーブル83と、住所ID、ユーザID、住所、登録日時のデータ項目を備えた住所テーブル84が設けられている。
また、DBβ系統に属するDBサーバ(β2)16内には、トランザクションID、購入金額、ユーザID、購入日時のデータ項目を備えた購入テーブル85の他に、住所ID及びトランザクションIDのデータ項目を備えた関連テーブル86が設けられている。
上記のユーザID、住所ID及びトランザクションIDは、システム10によって採番されるユニークな人工キーである。
【００９３】
ここで、追加データ受付部27から登録処理部28に対して会員の住所データの追加と同時に購入データの追加が指令されると、登録処理部28は、関連テーブル86に住所IDとトランザクションIDを格納することを指令するSQLを生成すると共に、購入テーブル85に購入データの追加を指令するSQLを生成し、DBサーバ(β2)16に発行する。
同時に登録処理部28は、住所テーブル84に住所データの追加を指令するSQLを生成し、DBサーバ(α2)16に発行する。
この時点で登録処理部28は、DBサーバ(α2)16及びDBサーバ(β2)16においてデータの追加が成功したか失敗したかについて関知しない。
【００９４】
この直後に、上記住所データ及び購入データを含む検索条件を指定した検索リクエストがクライアント端末18から発せられると、検索処理部22はまずDBサーバ(β2)16の関連テーブル86を参照し、住所ID及びトランザクションIDを特定する（Ｓ70）。
つぎに検索処理部22は、DBサーバ(β2)16の購入テーブル85及びDBサーバ(α2)16の住所テーブル84を参照し、上記のトランザクションID及び住所IDに対応するデータの登録があるか否かを確認する（Ｓ72）。
【００９５】
ここで、必要なデータの組合せが揃っていると判定した場合（Ｓ74／Ｙ）、検索処理部22は対応の購入データ及び住所データを取得するためのSQLをDBサーバ(α2)16及びDBサーバ(β2)16に発行する（Ｓ76）。
これに対し、何れか一方のデータのみが存在し、他方のデータが欠落している場合には、当該データの追加はなかったものと認定し、両データを取得対象から除外する（Ｓ78）。
【００９６】
何れかのテーブルに対するデータの追加が失敗した場合には、上記と同様、その旨の通知がクライアント端末18に戻される。
これに対しユーザは、同一データの組合せの追加登録を再度リクエストする。
【００９７】
ここで、先の追加登録リクエストにおいて住所データの追加登録が成功していた場合には、住所テーブル84において同一住所データが重複登録された状態となるが、上記と同様、登録日時の新しいものを有効として取り扱い、登録日時の古いデータの存在を無視することにより、データの一元性は確保される。
同様に、先の追加登録リクエストにおいて購入データの追加登録が成功していた場合には、購入テーブル85において同一購入データが重複登録された状態となるが、購入日時の新しいものを有効として取り扱い、購入日時の古いデータの存在を無視することにより、データの一元性は確保される。
【００９８】
このシステム10においては、テーブルに対する登録処理としてはデータの追加のみが許容され、データの更新や削除が禁止されているため、上記のようなデータ間の整合性確保方式を採用することが可能となる。
すなわち、データの内容変更は必ずデータの追加という形で表現されることから、検索処理部22は関連テーブルを参照した結果あるべきデータが存在しないと判明した時点で、追加処理の失敗と判断することができる。
これに対し、仮にデータの削除が許容されるという前提の下では、データの不存在がデータの削除によるものか、データの追加が失敗したことによるものかを判断不能となる。
【００９９】
なお、APサーバ14上で稼動するアプリケーションが複数のデータベースを同時更新中にクラッシュした場合、データベース間の不整合が出る可能性が生じる。この場合、APサーバ14の障害を検知した時点で、障害発生時刻近傍でデータベース間の不整合（レコードの不足）が発生していないか確認すると共に、不整合が認められた場合には必要なフォローを行う必要がある。
【０１００】
上記と同様、APサーバ14上には複数の検索処理部22が起動され、各検索処理部22は自己に割り当てられた異なるDB系統に属する複数のDBサーバ16に対してそれぞれSQLを発行する仕組みを備えているため、多数のCPUコアを用いることで効率的な分散処理が可能となる。
また、検索結果に基づいて各種のデータ加工処理を実行する必要性がある場合には、検索処理部22毎に複数のデータ加工処理部24が起動されるため、やはり多数のCPUコアを用いた効率的な分散処理が可能となる。
しかも、DBサーバ16からの検索結果データが全て揃うまで待機することなく、一定量単位でデータ加工処理部24による並列処理が実行されるため、データベースサーバ側のDISK/IOによる遅延を緩和することも可能となる。
【０１０１】
同様に、登録処理部28も複数存在し、各登録処理部28は自己に割り当てられた異なるDB系統に属する複数のDBサーバ16に対してそれぞれSQLを発行する仕組みを備えているため、データの追加登録時にも多数のCPUコアを用いた効率的な分散処理が可能となる。
【０１０２】
上記においては、２つのDB系統に属する各テーブルについてデータの追加を行う場合について説明したが、３つ以上のDB系統に属する各テーブルについてデータの追加を行う場合にも適用可能であることはいうまでもない。
【図面の簡単な説明】
【０１０３】
【図１】この発明に係るデータ利用システムの全体構成を示す模式図である。
【図２】DBサーバの構成を示す概念図である。
【図３】この発明に係るデータ利用システムの、検索リクエストがDBサーバに送信される場面での機能構成を示すブロック図である。
【図４】この発明に係るデータ利用システムの、DBサーバから検索結果が送信される場面での機能構成を示すブロック図である。
【図５】この発明に係るデータ利用システムの、クライアント端末から送信されたデータ追加のリクエストが、DBサーバに送信される場面での機能構成を示すブロック図である。
【図６】CPUコアとスレッドとの対応関係を示す模式図である。
【図７】検索条件分割処理部による処理手順を示すフローチャートである。
【図８】検索処理部による処理手順を示すフローチャートである。
【図９】検索結果統合処理部による処理手順を示すフローチャートである。
【図１０】クライアント端末から送信されたデータ追加のリクエストがDBサーバに送信される際の処理手順を示すフローチャートである。
【図１１】DBサーバに格納されたテーブルを例示する図である。
【図１２】データ加工処理部によるデータ分割の手順を示す模式図である。
【図１３】スレッド毎に複数のスレッドプールを設けた例を示す模式図である。
【図１４】この発明に係るデータ利用システムにインデックスサーバを追加した例を示すブロック図である。
【図１５】DBサーバの内部構造を示す模式図である。
【図１６】異なるDB系統に属する複数のDBサーバ間でデータの不整合が生じる例を示す説明図である。
【図１７】この発明に係るデータ間の整合性確保方式を示す説明図である。
【図１８】この発明に係るデータ間の整合性確保方式を示す説明図である。
【符号の説明】
【０１０４】
10    データ利用システム
12     Webサーバ
13    ロードバランサ
14    APサーバ
16    DBサーバ
17    インターネット
18    クライアント端末
19    外部記憶装置
20    検索条件分割処理部
22    検索処理部
24    データ加工処理部
26    検索結果統合処理部
27    追加データ受付部
28    登録処理部
30    CPUコア
32    スレッド
34    スレッドプール
36    タスク
40    顧客管理テーブル
42    予約管理テーブル
44    売上管理テーブル
46    予約取消管理テーブル
48    請求管理テーブル
50    第１のスレッドプール
52    第２のスレッドプール
60    インデックスサーバ
61    DB管理システム
62    当日分データ記憶領域
63    過去分データ記憶領域
64    インデックス生成部
65    インデックス記憶部
66    インデックス提供部
70    バッファ・キャッシュ領域
74    テーブル記憶領域
76    更新ログ記憶領域
78    ブロック
79    更新ログ
80    商品テーブル
81    関連テーブル
82    店舗テーブル
83    会員テーブル
84    住所テーブル
85    購入テーブル
86    関連テーブル
【図１】
0005608633.tif 000002
【図２】
0005608633.tif 000003
【図３】
0005608633.tif 000004
【図４】
0005608633.tif 000005
【図５】
0005608633.tif 000006
【図６】
0005608633.tif 000007
【図７】
0005608633.tif 000008
【図８】
0005608633.tif 000009
【図９】
0005608633.tif 000010
【図１０】
0005608633.tif 000011
【図１１】
0005608633.tif 000012
【図１２】
0005608633.tif 000013
【図１３】
0005608633.tif 000014
【図１４】
0005608633.tif 000015
【図１５】
0005608633.tif 000016
【図１６】
0005608633.tif 000017
【図１７】
0005608633.tif 000018
【図１８】
0005608633.tif 000019