JP2014016887A - データ利用システム - Google Patents

Abstract

【課題】データ処理における省電力化を極限まで追求できるデータ利用技術の提供。
【解決手段】各DBサーバ16は、同一データを保持した共通のテーブルを備える。各テーブルには、キー項目が一つに限定される制約と、更新・削除禁止の制約が課せられている。APサーバ14の検索条件分割処理部は、検索条件を分割して複数の検索処理部22に割り当て、各検索処理部22は、対応のSQLを対応のDBサーバ16に発行し、一定量の検索結果が送信される度に演算処理をデータ加工処理部24に割り当て、加工処理結果が揃った時点で検索結果統合処理部に集計結果を出力し、検索結果統合処理部は、各検索処理部22からの集計結果を集計し、検索結果として出力する。APサーバ14では、検索条件分割処理部、複数の検索処理部22等として機能する複数のスレッドが起動され、各スレッドが複数のCPUコアに割り当てられている。
【選択図】図２

Description

この発明はデータ利用システムに係り、特に、大量のデータを処理するに際しての省電力化を実現する技術に関する。

昨今、「ビッグ・データ」のキーワードの下、ハードディスク内に大量に蓄積されたデータを有効利用することの重要性が叫ばれるようになってきている。
その一方で、安全確保の観点から原子力発電を見直す気運が高まりつつあり、データ処理の分野においても省電力化への転換が待ったなしの情勢となってきている。
このように、増え続けるデータの活用と省電力の実現という、相矛盾する課題を同時に解決する手法が現在模索されている。

データ処理分野におけるこれまでの省電力化手法としては、発熱量の少ないCPUやハードディスクを搭載したサーバに切り替えることで、空調に要する電力量を削減することがメインであった（非特許文献１参照）。
IT省電力化計画Harmonious Greenプラン インターネットURL：http://www.hitachi.co.jp/environment/showcase/solution/it/storage.html 検索日：２０１２年６月２０日

しかしながら、データの処理方式やデータ構造に手を付けないまま、ハードウェアのみを若干の省電力対応のものに切り替えたとしても得られる効果は微々たるものであり、結局はデータ量の増加によって相殺されてしまうことが懸念される。
各所に配置された無数のセンサから連続的に発せられるデータ（所謂センサデータ）等、ユビキタス社会の到来によって処理対象となるデータの量が今後とも爆発的に増大し続けることは確実である以上、データ処理の省電力化に向けた根本的な解決手法の登場が強く求められている。

この発明は、このような現状に鑑みて案出されたものであり、データ処理における省電力化を極限まで追求可能な、これまでにない斬新なデータ管理技術を提供することを目的としている。

上記の目的を達成するため、請求項１に記載したデータ利用システムは、複数のデータベースサーバと、各データベースサーバにネットワークを介して接続されたアプリケーションサーバとからなり、上記の各データベースサーバは、DB管理システムと、データ記憶領域を備えており、各データベースサーバのデータ記憶領域には、データベースサーバ相互間に共通するデータを保持した共通のテーブルがそれぞれ複数格納されており、上記の各テーブルには、キー項目が一つに限定される制約と、データの更新及び削除が禁止される制約が設けられており、上記アプリケーションサーバは、検索条件分割処理部と、複数の検索処理部と、複数のデータ加工処理部と、検索結果統合処理部と、追加データ受付部と、複数の登録処理部を備え、上記検索条件分割処理部は、入力された検索条件を解析して複数の検索条件に分割すると共に、各検索条件及び対応データベースサーバを上記複数の検索処理部に割り当てる処理を実行し、上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、自己に割り当てられたデータベースサーバに発行する処理と、データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行し、上記追加データ受付部は、入力された追加データのコピーと、対応データベースサーバの特定情報を含むデータ追加リクエストを上記の各登録処理部に割り当てる処理を実行し、上記の各登録処理部は、上記追加データの登録を求めるSQLを生成し、自己に割り当てられたデータベースサーバに発行する処理を実行するデータ利用システムであって、上記データベースサーバのデータ記憶領域がＳＳＤよりなり、上記アプリケーションサーバにおいては、上記検索条件分割処理部、複数の検索処理部、複数のデータ加工処理部、検索結果統合処理部、追加データ受付部、複数の登録処理部として機能する複数のスレッドが起動されると共に、各スレッドが複数のCPU コアに割り当てられていることを特徴としている。

請求項２に記載したデータ利用システムは、請求項１に記載のシステムであって、さらに、上記検索条件分割処理部が、入力された検索条件が時間的な範囲を含んでいる場合に、これをより短い時間的な範囲に分割することを特徴としている。

請求項３に記載したデータ利用システムは、請求項１に記載のシステムであって、さらに、上記検索条件分割処理部が、入力された検索条件が地域的な範囲を含んでいる場合に、これをより狭い地域的な範囲に分割することを特徴としている。

この発明に係るデータ利用システムの場合、データベースサーバが管理する各テーブルの正規化が極限まで追求され、構造の単純化、冗長性の排除が徹底されているため、ハードディスクに比べて容量の小さなＳＳＤでデータ記憶領域を構成しても、業務処理に必要なデータを格納することが容易となる。
ＳＳＤはモータ駆動による可動部を有さないため、ハードディスクに比べて消費電力を抑えることができる。また、発熱量も大幅に低減できるため、空調に要する電力量を大幅に低減可能である。

また、テーブルから抽出したデータの加工処理（ソートやマッチング、コントロールブレイク等）はアプリケーションサーバ側で実行され、データベースサーバはデータの出し入れに専念できるため、テーブル数の増大やテーブル間の関係の複雑化に伴いSQLの発行数が増大しても、データベースサーバ側の負担増を抑制することが可能となる。
しかも、データベースサーバが物理的に複数台用意され、検索処理時には検索条件が各データベースサーバに分散される仕組みであるため、個々のデータベースサーバにおけるデータ抽出処理が軽減される結果、システム全体の処理速度を向上させることができる。
このため、各データベースサーバを比較的処理速度の遅い省電力型のCPUコアを多数搭載したコンピュータで構成することが可能となり、その分、消費電力を低減することができる。

アプリケーションサーバにおいては、入力された検索条件が複数に分割され、それぞれ複数の検索処理部を介してデータベースサーバにデータの検索依頼が送信されると共に、データベースサーバから各検索処理部に対して返された検索結果データに対しても、一定量単位で複数のデータ加工処理部による並列処理が実行されるため、データベースサーバから大量のデータが送信される場合であっても、多数のCPUコアを用いることで効率的な処理が可能となる。また、このようにデータベースサーバからの検索結果データが全て揃うまで待機することなく、一定量のデータが揃った時点で部分的な加工処理に移行することにより、データベースサーバ側のDISK/IOによる遅延を緩和することも可能となる。

これまで、DNA解析や気象解析のように純粋な演算処理を主体とした科学技術計算と異なり、データベースに蓄積された大量のデータを参照する必要のある業務系処理の場合には、データベースサーバからの応答を待つDISK/IOがボトルネックとなるため、アプリケーションサーバ側のCPUコアの数を増やしたとしても、直ちに処理速度の向上には結びつかないという問題があった。
これに対し、上記のような仕組みをアプリケーションサーバに設けることにより、テーブルの正規化の追求に伴うデータベースサーバ側の負担増を、アプリケーションサーバ側の処理の効率化によってカバーすることが可能となった。

このように、CPUのマルチコア化に適合する結果、アプリケーションサーバを比較的処理速度の遅い省電力型のCPUコアを多数搭載したコンピュータで構成することが可能となり、その分、消費電力を低減することができる。

図１は、この発明に係るデータ利用システム10の全体構成を示す模式図であり、ロードバランサ13と、Webサーバ12と、複数のAP（アプリケーション）サーバ14と、複数のDB（データベース）サーバ16とを備えている。
Webサーバ12には、インターネット17を介してPC等よりなるクライアント端末18が接続されている。
各DBサーバ16は、全DBサーバ16間に共通するデータを格納した複数のテーブル群と、DB管理システム（RDBMS）とを備えており、DBサーバ16の中の少なくとも一部は、データ保全の観点から遠隔地に配置されている。

最初に、本システム10における処理内容について大まかに説明し、個々の具体的な構成や処理内容については後に詳説する。
まず、クライアント端末18にはWebサーバ12からデータ利用画面が送信され、Webブラウザ上に表示される（図示省略）。
そして、ユーザがこのデータ利用画面を通じて検索条件を指定し、データの検索をリクエストすると、Webサーバ12からAPサーバ14に対して検索リクエストが送信される。この際、ロードバランサ13を介して、最も負荷の小さい一のAPサーバ14に対して、検索リクエストが振り分けられる。

この検索リクエストを受け取ったAPサーバ14は、検索条件を論理的に複数に分割し、分割された検索条件に対応した複数のSQLをそれぞれ別個の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サーバ16に対して同一のSQLを発行し、同データの追加を依頼する。
これに対し各DBサーバ16は、上記追加データを対応のテーブルに格納する処理を実行する。

図２は、APサーバ14及びDBサーバ16のハードウェア構成を示す模式図である。
まず、各APサーバ14は、多数（例えば128個）のCPUコア20と、複数のDRAMモジュール22を少なくとも備えている。
各CPUコア20は、ARM（登録商標）アーキテクチャ等に準拠した省電力型CPUコアよりなる。
各CPUコア20は、所謂Shared Everythingアーキテクチャに基づき、各DRAMモジュール22を共有する関係にある。すなわち、各CPUコア20は各DRAMモジュール22に対してメッシュ状にアクセス可能となされている。

各DBサーバ16は、多数（例えば128個）のCPUコア20と、複数のDRAMモジュール22と、複数のＳＳＤ14を備えている。
各CPUコア20は、上記と同様、ARM（登録商標）アーキテクチャ等に準拠した省電力型CPUコアよりなる。
各CPUコア20は、所謂Shared Everythingアーキテクチャに基づき、各DRAMモジュール22を共有する関係にある。
ＳＳＤ24には、Linux（登録商標）等のOSの他に、DBサーバ用のプログラムが格納されている。また、各種テーブルもＳＳＤ24内に格納されている。

図３は、各DBサーバ16に格納されたテーブル群の具体例を示しており、顧客管理テーブル30と、予約管理テーブル32と、売上管理テーブル34と、予約取消管理テーブル36と、請求管理テーブル38とによって、各店舗の売り上げが管理されている。

顧客管理テーブル30は、「顧客ID（主キー）」及び「地域」のデータ項目を備えている。
また、予約管理テーブル32は、「予約ID（主キー）」、「店ID」、「顧客ID（外部キー）」、「金額」及び「予約年月日」のデータ項目を備えている。
売上管理テーブル34は、「予約ID（主キー／外部キー）」及び「売上年月日」のデータ項目を備えている。
予約取消管理テーブル36は、「予約ID（主キー／外部キー）」及び「予約取消年月日」のデータ項目を備えている。
請求管理テーブル38は、「請求ID（主キー）」、「請求年月日」及び「予約ID（外部キー）」のデータ項目を備えている。

上記の各テーブル30〜38には、以下の(1)〜(3)の制約が予め課せられている。
(1)キー項目は一つに限定される。
したがって、複数の項目の組合せによってキー項目を構成すること（複合キー）は、禁止される。

(2)各テーブルにはレコードの追加のみが許容され、既存レコードの値の更新及びレコードの削除は禁止される。
したがって、値に変更が生じた場合など、発生タイミングの異なる情報は別テーブルに格納されることとなる。

(3)各テーブルのカラムには、NULL値禁止制約、フラグ値禁止制約、区分値禁止制約が課せられる。
まず「NULL値禁止制約」とは、データ項目の値としてNULL（値なし）を充填することが禁止されることを意味しており、このようなNULL値の充填を想定したデータ項目の設定自体が許容されないことになる。
つぎに「フラグ値禁止制約」とは、データ項目の値としてフラグ値（「１／０」、「ON／OFF」、「TRUE／FALSE」等の２値データ）を充填することが禁止されることを意味しており、このようなフラグ値の充填を想定したデータ項目の設定自体が許容されないことになる。
「区分値禁止制約」とは、データ項目の値として区分値（「１：正社員」、「２：パート」、「３：アルバイト」等）を充填することが禁止されることを意味しており、このような区分値の充填を想定したデータ項目の設定自体が許容されないことになる。

これらの制約ルールは、新規テーブルの設計時やSQL文発行時に、DBサーバ16のデータベース管理システムによって適否がチェックされ、制約ルールに違反する処理の実行が拒絶されることにより、その実効性が担保される。

図３より明らかなように、各テーブルは単一のデータ項目によって主キー（PK）が構成されている。
また、「予約取消」に関するデータも、通常であれば予約管理テーブル32において「予約取消フラグ」等のデータ項目が設けられ、各レコードに「１／０」等のフラグ値を充填することで状態が管理されるところであるが、予約取消管理テーブル36を予約管理テーブル32とは別個に設けることにより、予約取消の状態管理がなされている。すなわち、この予約取消管理テーブル36に登録された予約IDが「予約取消」状態にあることとなり、レコードの有無によって予約取消の有無が表現されている。

各テーブルには上記(2)の制約（値の更新禁止）が課せられているため、例えばある顧客の「地域」に変動が生じた場合でも、顧客管理テーブル30における該当レコードの「地域」の値が書き換えられることはない。
図示は省略したが、このような場合には例えば「顧客ID」、「変更地域」、「変更年月日」等のデータ項目を備えた「顧客地域変更管理テーブル」が新たに設けられて、当該顧客の顧客ID、変更後の地域、変更年月日が格納される。

この結果、顧客の地域別に売上を集計する必要が生じた場合、APサーバ14側では顧客管理テーブル30を参照して各顧客の地域情報を取得した後、顧客地域変更管理テーブルを参照して地域変更の生じた顧客を特定し、変更後の地域に差し替える処理を実行することになる。

図４は、クライアント端末18から送信された検索リクエストが、Webサーバ12及びAPサーバ14を経由してDBサーバ16に送信される場面での機能構成を表しており、APサーバ14は、検索条件分割処理部40と、複数の検索処理部42を備えている。

また図５は、DBサーバ16から検索結果が送信される場面での機能構成を表しており、APサーバ14は、各検索処理部42単位で複数割り当てられたデータ加工処理部44と、検索結果統合処理部46を備えている。

図６は、クライアント端末18から送信されたデータ追加のリクエストが、DBサーバ16に送信される場面での機能構成を表しており、APサーバ14は、追加データ受付部47と、複数の登録処理部48を備えている。

APサーバ14内に設けられた上記の検索条件分割処理部40、複数の検索処理部42、複数のデータ加工処理部44、検索結果統合処理部46、追加データ受付部47、複数の登録処理部48は、APサーバ14に搭載された多数のCPUコア20が、専用のアプリケーションプログラムに従って所定の処理を実行することで実現されるのであるが、この際、OSやミドルウェアによって複数のスレッドが起動されて各CPUコア20に割り当てられることにより、マルチタスク処理が実現される。

図７は、各CPUコア20とスレッド52との対応関係を表しており、各スレッド52にはスレッドプール54が設けられ、そこに配置された複数のタスク56をスレッド52が順次処理していくイメージが描かれている。
この図におけるスレッド52が、図４〜図６に表された検索条件分割処理部40、複数の検索処理部42、複数のデータ加工処理部44、検索結果統合処理部46、追加データ受付部47、複数の登録処理部48として機能し、これらの機能構成部が実行する具体的な処理がタスク56に相当する。

各スレッド52は、スレッドプール54に蓄積されたタスクを古い順に次々と実行していき、自己のスレッドプール54が空になった場合には、他のスレッド52のスレッドプール54に蓄積されたタスク56を、新しい順に実行していく。

つぎに、図８〜図１０のフローチャートに従い、このシステム10のデータ検索時における処理手順を詳細に説明する。
まず、クライアント端末18から送信された検索条件をWebサーバ12経由でAPサーバ14が受信すると（図８のＳ10）、検索条件分割処理部40は検索条件を解析し、検索条件の内容に応じて複数の検索条件に分割する（Ｓ12）。

ここで分割の基準となるのは、時間（日、週、月、年等）や地域（都道府県、市町村等）など、検索対象データを論理的に複数に区分できるものが該当する。
例えば、「2010年における全チェーン店の売上を集計する」という検索条件が与えられた場合に、「2010年１月分の全チェーン店の売上」、「2010年２月の全チェーン店の売上」、「2010年３月の全チェーン店の売上」…というように、年を月単位に１２分割することが該当する。
また、各チェーン店の所在地データに着目し、「2010年における東京所在チェーン店の売上」、「2010年における北海道所在チェーン店の売上」、「2010年における沖縄所在チェーン店の売上」…というように、全国を都道府県単位に４７分割することも該当する。
もちろん、「2010年１月分の東京所在チェーン店の売上」や「2010年１月の北海道所在チェーン店の売上」のように、月×都道府県単位で５６４分割することもできる。

これらの分割基準は、クライアント端末18から発せられると予測される検索条件や、対象となるデータの量等に鑑みて、事前に幾つかの分割パターンがプログラム設計者によって策定され、検索条件分割処理部40を実現するためのプログラム中にコーディングされている。

ここでは、クライアント端末18から「Ａ店の８月分の請求額を地域毎に集計せよ」という内容の検索リクエストが送信されたものとして、説明を続ける。
まず検索条件分割処理部40は、「８月＝３１日間」というカレンダー情報に従い、「８月１日分」、「８月２日分」、「８月３日分」…「８月３１日分」というように、検索条件を３１分割する。

つぎに検索条件分割処理部40は、これらの分割された各検索条件（「Ａ店の８月１日分の請求額を地域毎に集計せよ」等）及び担当すべき対応DBサーバ16を、３１個の検索処理部42に割り当てる（Ｓ14）。

これに対し各検索処理部42は、自己に割り当てられた請求日を指定した、請求管理テーブル38から請求データを取得するためのSQL文を生成し、自己が担当するDBサーバ16に発行する（図９のＳ20）。

そして、DBサーバ16から該当日の請求年月日を備えた請求データが送信され始めると、検索処理部42は対応のDBサーバ16から全ての検索結果データが送信されるのを待つことなく、予め設定された一定量のデータ（例えば1,000件のレコード相当分）が送信された時点で（Ｓ22／Ｙ）、必要な演算処理を複数のデータ加工処理部44に割り当てる（Ｓ24）。

具体的には、以下のような処理がデータ加工処理部44によって実行される。
(1)各請求データの「予約ID」を指定したSQL文を生成してDBサーバ16に発行し、「予約管理テーブル32」から対応の予約データを取得する。
(2)送信された予約データの中で、該当店舗の「店ID」を有するデータのみを抽出し、他の店IDのデータを除外する。
(3)各予約データの「顧客ID」を指定したSQL文を生成してDBサーバ16に発行し、顧客管理テーブル30から対応の顧客データを取得する。
(4)顧客データの「地域」毎に、予約データ中の「金額」の値を集計する。
これら(1)〜(4)の処理は、具体的にはタスク56として各データ加工処理部44のスレッドプール54に配置される。

検索処理部42は、データ加工処理部44から1,OOO件単位の処理結果データが返信された時点で（Ｓ26／Ｙ）、この単位データ量当たりの処理結果をメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除する（Ｓ28）。
各検索処理部42は、DBサーバ16からのデータ送信が完了するまで、DBサーバ16から送信されるデータが一定量に達する度にＳ22〜Ｓ28の処理を繰り返す（Ｓ30／Ｎ、Ｓ22／Ｙ）。
そして、DBサーバ16からのデータ送信が完了し、Ｓ22〜Ｓ28の最後の処理が完了して１日分の処理結果データが揃った時点で（Ｓ30／Ｙ）、検索処理部42はこれまでの部分的な処理結果の集計値を集計し（Ｓ32）、検索結果統合処理部46に集計結果を出力する（Ｓ34）。

これを受けた検索結果統合処理部46は（図１０のＳ40）、全ての検索処理部42からの集計結果が揃ったか否かをチェックし（Ｓ42）、全てが揃った段階で全検索処理部42の集計結果を集計する（Ｓ44）。
そして、その最終的な集計結果をWebサーバ12に送信する（Ｓ46）。
Webサーバ12は、この集計結果を含むWebファイルを生成し、クライアント端末18に送信することになる。

つぎに図１１に従い、データ追加時におけるAPサーバ14側の処理手順を説明する。
まず、クライアント端末18から送信されたデータ追加のリクエストをWebサーバ12経由でAPサーバ14が受信すると（Ｓ50）、追加データ受付部47がDBサーバ16の数に対応した登録処理部48を起動させ、それぞれに担当DBサーバ16の特定情報及び追加データを渡す（Ｓ52）。
これを受けた各登録処理部48は、自己が担当するDBサーバ16に対して上記の追加データの登録を求めるSQLを発行する（Ｓ54）。
これを受けた各DBサーバ16は、対応のテーブルに対して一斉にデータを追加する。この結果、各DBサーバ16が管理するデータの同一性が確保される。

このシステム10の場合、DBサーバ16からのフェッチが完了するまでAPサーバ14が待つことはなく、一定量のデータを受信する度に複数のデータ加工処理部44による処理が開始される仕組みであり、しかも各テーブルはハードディスクではなく高速処理が可能なＳＳＤ24に格納されているため、DBサーバ16のDISK/IOによるボトルネックを解消することができる。

また、APサーバ14における部分的な集計が完了する度に、DBサーバ16から送信されたデータが占めていたメモリが解放され、データ量が格段に小さな集計結果データのみがメモリに格納される仕組みであるため、APサーバ14のメモリが大きなデータに占拠され続けることを回避できる。

また、図１２に示すように、各DBサーバ16は同じ内容のデータを保持しており、APサーバ14の各検索処理部42は、DBサーバ16aから「８／１（８月１日分）」のデータを取得し、DBサーバ16bからは「８／２（８月２日分）」のデータを、DBサーバ16cからは「８／３（８月３日分）」のデータを…、というように、自己に割り当てられた一つのDBサーバ16から自己に割り当てられた１日分のデータを取得するSQL文を分散して発行できる。
このため、個々のDBサーバ16における処理の負担が必然的に低減することとなり、全体の処理速度を高速化することができる。検索条件分割処理部40は、各検索処理部42に担当のDBサーバ16を割り振る際に、DBサーバ16毎の特性（保持データの範囲等）を考慮することなく、機械的に対応付けることが可能となる。

なお、処理速度の向上という観点からは、分割した検索条件と等しい数の検索処理部42及びDBサーバ16を用意することが望ましいが、検索処理部42及びDBサーバ16の数はこれに限定されるものではない。
例えば、分割された検索条件が31個あり、検索処理部42が31個設けられたにもかかわらず、DBサーバ16が物理的に10台しか用意されていない場合には、各DBサーバ16に対して３〜４個の検索条件が割り振られることになる。この場合でも、１台のDBサーバ16のみで全てを処理する場合に比べ、大幅な高速化が期待できる。

上記のように、DBサーバ16が管理する各テーブルの構造が極限まで単純化される分、テーブルの数が増え、SQLの発行数自体は増大するが、演算処理は多数のCPUコア20を用いた並列処理によって高速化されたAPサーバ14側で行われ、DBサーバ16は単純化されたデータの管理（インサートとセレクト）に専念でき、データの更新や削除から解放されるため、DBサーバ16の負担は大幅に軽減される。
しかも、DBサーバ16は上記のように筐体レベルで複数台用意され、検索時にはデータの抽出処理がそれぞれに分散されるため、テーブルの正規化の追求に伴いDBサーバ16側の処理速度が低下することを、有効に回避できる。

また、フラグ値や区分値のように、特殊なビジネスルールに基づいた値の格納が禁止される結果、データモデルの見通しが良好となり、テスト・データの作成効率が向上するという効果も期待できる。

上記のように、DBサーバ16が物理的に複数台設けられており、各DBサーバ16には同一内容のデータが保存される仕組みを備えているため、あるDBサーバ16に何らかのトラブルが発生した場合であっても、他のDBサーバ16のデータを用いてデータを容易に復旧させることができる利点を有している。
各テーブルには、データの更新や削除が許容されないというルールが適用されているため、一のDBサーバ16のデータが一部消失してしまい、他のDBサーバ16のデータに基づいてこれを復旧させる必要性が生じた場合であっても、新たに追加されたデータのみを追記させれば済む。
この復旧が完了するまでの間、当該DBサーバ16についてはWRITE ONLY状態（データの書き込み可／読み込み不可）に置かれるため、一時的なデータの不整合が顕在化することもない。

図１３は、各DBサーバ16の内部構造をより詳細に示すものであり、メモリ上に設けられたバッファ・キャッシュ領域70と、DB管理システム（RDBMS）61と、OS（Linux）72と、テーブル記憶領域74とが描かれている。
ここでテーブル記憶領域74はＳＳＤ24内に設けられており、上記した顧客管理テーブル30や予約管理テーブル32等が格納されている。

この図に示されているように、DBサーバ16においては一般に、テーブル内のデータはブロック78単位でテーブル記憶領域74からバッファ・キャッシュ領域70に取り出されると共に、バッファ・キャッシュ領域70に書き込まれたデータはブロック78単位でテーブル記憶領域74に格納される。
このため、上記のように各テーブルに格納されるレコードの構造が極限まで簡素化されていると、１つのブロック78に収納できるレコード数を増やすことが可能となる。

一般に、ＳＳＤの書換（既存データの消去及び新規データの書込）回数には一定の限界があり、その寿命を延ばすためには書換回数を可能な限り低減すべきものとされている。
これに対し、このシステム10の場合には上記のように、１つのブロック78に収納できるレコード数が増大する結果、新規データの追加に際しての書込回数を大幅に低減することができる。また、DBサーバ16の各テーブルには、「既存データの更新や削除が許容されない」ルールが適用されるため、その分、ＳＳＤの書換回数が低減することとなる。この結果、DBサーバ16に搭載されたＳＳＤ24の寿命特性を、飛躍的に高めることが可能となる。

この発明に係るデータ利用システムの全体構成を示す模式図である。 APサーバ及びDBサーバのハードウェア構成を示す模式図である。 DBサーバに格納されたテーブルを例示する図である。 検索リクエストがDBサーバに送信される場面におけAPサーバの機能構成を示すブロック図である。 DBサーバから検索結果が送信される場面におけるAPサーバの機能構成を示すブロック図である。 クライアント端末から送信されたデータ追加のリクエストがDBサーバに送信される場面におけるAPサーバの機能構成を示すブロック図である。 CPUコアとスレッドとの対応関係を示す模式図である。 データ検索時の処理手順を示すフローチャートである。 データ検索時の処理手順を示すフローチャートである。 データ検索時の処理手順を示すフローチャートである。 データ追加時の処理手順を示すフローチャートである。 共通のデータを保持した複数のDBサーバから、それぞれ別個のデータを分散取得する様子を示す模式図である。 DBサーバの内部構造を示す模式図である。

10 データ利用システム
12 Webサーバ
13 ロードバランサ
14 APサーバ
16 DBサーバ
17 インターネット
18 クライアント端末
20 CPUコア
22 DRAMモジュール
22 検索処理部
24 データ加工処理部
26 検索結果統合処理部
27 追加データ受付部
28 登録処理部
30 顧客管理テーブル
32 予約管理テーブル
34 売上管理テーブル
36 予約取消管理テーブル
38 請求管理テーブル
40 検索条件分割処理部
42 検索処理部
44 データ加工処理部
46 検索結果統合処理部
47 追加データ受付部
48 登録処理部
52 スレッド
54 スレッドプール
56 タスク
70 バッファ・キャッシュ領域
74 テーブル記憶領域
78 ブロック

Claims (3)

1. 複数のデータベースサーバと、各データベースサーバにネットワークを介して接続されたアプリケーションサーバとからなり、
   上記の各データベースサーバは、DB管理システムと、データ記憶領域を備えており、
   各データベースサーバのデータ記憶領域には、データベースサーバ相互間に共通するデータを保持した共通のテーブルがそれぞれ複数格納されており、
   上記の各テーブルには、キー項目が一つに限定される制約と、データの更新及び削除が禁止される制約が設けられており、
   上記アプリケーションサーバは、検索条件分割処理部と、複数の検索処理部と、複数のデータ加工処理部と、検索結果統合処理部と、追加データ受付部と、複数の登録処理部を備え、
   上記検索条件分割処理部は、入力された検索条件を解析して複数の検索条件に分割すると共に、各検索条件及び対応データベースサーバを上記複数の検索処理部に割り当てる処理を実行し、
   上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、自己に割り当てられたデータベースサーバに発行する処理と、データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、
   上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行し、
   上記追加データ受付部は、入力された追加データのコピーと、対応データベースサーバの特定情報を含むデータ追加リクエストを上記の各登録処理部に割り当てる処理を実行し、
   上記の各登録処理部は、上記追加データの登録を求めるSQLを生成し、自己に割り当てられたデータベースサーバに発行する処理を実行するデータ利用システムであって、
   上記データベースサーバの上記データ記憶領域がＳＳＤよりなり、
   上記アプリケーションサーバにおいては、上記検索条件分割処理部、複数の検索処理部、複数のデータ加工処理部、検索結果統合処理部、追加データ受付部、複数の登録処理部として機能する複数のスレッドが起動されると共に、各スレッドが複数のCPU コアに割り当てられていることを特徴とするデータ利用システム。
2. 上記検索条件分割処理部は、入力された検索条件が時間的な範囲を含んでいる場合に、これをより短い時間的な範囲に分割することを特徴とする請求項１に記載のデータ利用システム。
3. 上記検索条件分割処理部は、入力された検索条件が地域的な範囲を含んでいる場合に、これをより狭い地域的な範囲に分割することを特徴とする請求項１に記載のデータ利用システム。

Images