JP2015132972A - データ再配置システム - Google Patents

Abstract

【課題】ユーザID等のデータ振分基準を有さないデータを複数のDBサーバで管理している場合に、容易にデータの再配置を可能とする。
【解決手段】第１のDBサーバ14及び第２のDBサーバ16で管理していたユーザのデータを、第３のDBサーバ18を加えた３台で管理する体制に移行するに際し、まずリバランシング装置19は各DBサーバに新規テーブルを生成させる。つぎに、第１のDBサーバ14及び第２のDBサーバ16から既存データを取得する。つぎに、APサーバ12のDB振分部24から取得した関連付データ（既存データ中の主キー項目の値とユーザIDとの組合せ）と新規振分設定ファイル26（ユーザIDと再配置先のDBサーバとの組合せ）を用いて、既存データの再配置先を特定する。つぎに、再配置先のDBサーバに既存データを送信し、新規テーブルに格納させる。
【選択図】図１０

Description

この発明は、データ再配置システムに係り、特に、ユーザID等のデータ分散基準となる項目を含まないデータを複数のデータベースサーバで分散管理している場合において、各データの配置先を柔軟に変更可能とする技術に関する。

サービス全体で利用する共通データ（マスターデータ）については、可用性を担保する観点から、単一のデータベースサーバで管理することが望ましい。これに対し、日々の業務処理を通じて増大していくトランザクションデータについては、負荷分散や障害局所化の要請から、複数のデータベースサーバによって分散管理することが行われている。

例えば、図１２に示すように、口座番号の下一桁の数字（１〜０）に予め関連付けられた１０台のAPサーバ52及びDBサーバ54によって、各預金者の口座情報を管理する銀行口座管理システム50が存在している。
この場合、預金者の操作するクライアント端末56から入力された口座番号の下一桁の数字（１〜０）に基づいて、振分装置58は簡単に該当のAPサーバ52及びDBサーバ54に処理を振り分けることができる。
また、各APサーバ52には予め専用のDBサーバ54が割り当てられているため、APサーバ52に搭載されたアプリケーションプログラムは、データ格納時に接続先を選択する必要がないという利点も生じる。

これに対し、各ユーザに紐付いたデータに互いにアクセスするようなシステム（例えばSNS等）の場合には、振分装置により特定のAPサーバに振り分け、そのAPサーバに予め割り当てられているDBサーバのデータだけにアクセスすれば良いわけではないため、自動的に担当サーバを振り分けるといった解決策が使えない。
このため、クライアント端末から送信されたユーザIDに基づいて、データの格納先となるデータベースサーバを特定する機能を設ける必要が生じる。

以下の非特許文献１においては、SNSのユーザ数の急拡大に対応するため、データベースを多数のPCサーバに分散配置させると共に、ユーザIDとDBサーバとの対応関係が定義された分割マップをWebサーバのアプリケーションが参照することで、各ユーザIDに関連付けられたデータの在処を取得する仕組みが開示されている。
mixiの生みの親"バタラ氏"が語るMySQLの意外な利用法 インターネットURL：http://techtarget.itmedia.co.jp/tt/news/0709/12/news01.html 検索日：２０１３年１２月１５日

確かに、SNS中の各種サービス（日記サービス、メッセージサービス、コミュニティサービス等）を通じて発生するデータには、基本的にユーザIDが付加されているため、アプリケーションが分割マップを参照することにより、比較的容易に対応のDBサーバを特定することができる。

ただし、SNSのようにデータが基本的にユーザに紐付くような形式とならないサービス（例えばネット通販サービス）の中には、業務処理の過程でユーザIDを伴わない多数の関連データが生成される場合があり、このようなユーザIDを伴わない関連データの参照や更新については、上記した「分割マップの参照方式」では対応できないこととなる。
また、仮にユーザID以外の項目でデータ分散を行った場合、同一ユーザに関連するデータは同一のDBサーバで管理した方が障害局所化（DBサーバ障害時に影響ユーザが局所化できる）の観点から望ましいが、それを満たせなくなる。

上記のような問題については、例えば、ユーザIDを有するデータからユーザIDを抜き出し、これを各関連データが共通に有しているデータ項目の値と関連付ける機能をAPサーバ側に設けておくことにより、解決することはできる。

何れにしても、ネット通販のような大規模サービスの場合、ユーザ数の拡大に伴いシステムの規模も随時拡張していく必要があり、例えば、これまで100台のDBサーバで管理していたデータを200台のDBサーバで管理する体制に移行するといったことが当然のごとくに生じるが、サービスを停止することなく、大量の既存データをそれぞれ別々のDBサーバに再配置することは極めて困難であった。

この発明は、このような従来の問題を解決するために案出されたものであり、多数のDBサーバで管理されている既存データを、サービスを停止させることなく、新たなDBサーバに比較的容易に再配置させる技術の提供を目的としている。

上記の目的を達成するため、請求項１に記載したデータ再配置システムは、複数のDBサーバと、各DBサーバと接続されたAPサーバと、各DBサーバ及びAPサーバと接続されたリバランシング装置とを備え、各DBサーバの中の少なくとも一部は、相互に共通する構成の既存テーブルを有しており、上記APサーバは、入力されたリクエストに対応した処理を実行する少なくとも一つの業務処理手段と、この業務処理手段から出力される結果データ中の特定データ項目の値と、当該結果データを格納すべき一のDBサーバとの対応関係を予め定義しておく振分設定ファイルと、DB振分手段とを有し、このDB振分手段は、上記業務処理手段から業務処理の結果データが出力された場合に、上記振分設定ファイルを参照し、当該結果データ中の特定データ項目の値に関連付けられたDBサーバを特定する処理と、当該DBサーバに対して上記結果データを送信し、上記既存テーブルへの登録を依頼する処理を実行するシステムにおいて、上記リバランシング装置が、上記の各DBサーバに対して相互に共通する構成を備えた新規テーブルの生成を指令する処理と、上記既存テーブルを備えたDBサーバから、当該既存テーブルに格納された既存データを取得する処理と、各DBサーバと上記特定データ項目の値との新たな対応関係を定義した新規振分設定ファイルを参照し、各既存データの再配置先となるDBサーバを特定する処理と、当該DBサーバに対し、当該既存データを上記新規テーブルに格納することを依頼する処理とを実行することを特徴としている。

請求項２に記載したデータ再配置システムは、請求項１のシステムであって、さらに上記DB振分手段が、少なくとも上記リバランシング装置からデータの再配置開始の通知を受けた以降、各DBサーバに対して送信した結果データを含む更新履歴情報を所定の記憶手段に格納する処理と、上記リバランシング装置から更新履歴情報の送信指令を受信した際に、上記更新履歴情報をリバランシング装置に送信する処理を実行し、上記リバランシング装置が、この更新履歴情報に含まれる結果データに係る特定データ項目の値を抽出する処理と、上記の新規振分設定ファイルを参照し、各結果データの反映先となるDBサーバを特定する処理と、各DBサーバに対し当該結果データに基づくデータの更新を依頼する処理を実行することを特徴としている。

請求項３に記載したデータ再配置システムは、請求項１のシステムであって、さらに、上記少なくとも一部のDBサーバは、ユーザに係る一連の異種データを関連付けるための共通の主キー項目をそれぞれ備えた複数の既存テーブルを有しており、上記APサーバは、上記既存テーブルの主キー項目の値とユーザIDとの組合せからなる関連付データを格納する関連付記憶手段を備えており、上記APサーバの振分設定ファイルは、各ユーザのユーザIDと、当該ユーザに係る業務処理の結果データを格納すべき一のDBサーバとの対応関係が予め定義されており、上記APサーバのDB振分手段が、上記業務処理手段から出力されたユーザID及び上記主キー項目の値の組合せを上記関連付記憶手段に格納する処理と、上記業務処理手段からユーザIDを含まない業務処理の結果データが出力された場合に、上記関連付記憶手段を参照し、当該結果データに含まれる上記主キー項目の値に関連付けられたユーザIDを取得する処理と、上記振分設定ファイルを参照し、当該ユーザIDに関連付けられたDBサーバを特定する処理を実行し、上記リバランシング装置が、上記APサーバから上記関連付データを取得する処理と、この関連付データに基づいて、各既存データに係るユーザIDを特定する処理と、各DBサーバとユーザIDとの新たな対応関係を定義した新規振分設定ファイルを参照し、各既存データの再配置先となるDBサーバを特定する処理を実行することを特徴としている。

請求項４に記載したデータ再配置システムは、請求項１〜３のシステムであって、さらに上記リバランシング装置が、上記新規振分設定ファイルを上記DB振分手段に送信する処理を実行し、上記DB振分手段が、以後、この新振分設定ファイルに基づいて各結果データの送信先となるDBサーバを特定することを特徴としている。

請求項１に記載したデータ再配置システムの場合、各データの格納先を別のDBサーバに変更するデータの再配置に際しては、リバランシング装置が各DBサーバに対して新規テーブルを生成させると共に、各DBサーバの既存テーブルに格納された既存データを収集し、新規振分設定ファイルに基づいて各既存データの再配置先を特定した上で、各DBサーバの新規テーブルに既存データを格納させる仕組みを備えており、既存テーブルはそのまま残されるため、既存テーブルに基づいたサービスを継続したまま、大量の既存データを新たな振分基準に従って柔軟に再配置することが可能となる。

また、既存データの再配置中にデータの更新が生じた場合、DB振分手段は既存テーブルにアクセスすることになるが、請求項２のデータ再配置システムの場合、APサーバ上に更新履歴情報が保持され、この更新履歴情報に基づいてリバランシング装置が更新データを各DBサーバの新規テーブルに反映させる仕組みを備えているため、新規テーブルのデータ整合性を確保することができる。

請求項３のデータ再配置システムにあっては、APサーバのDB振分手段によって、初めにユーザIDと処理結果データに含まれるキー項目の値のとの組合せが関連付記憶手段に格納される仕組みを備えているため、以後、ユーザIDを含まない処理結果データが業務処理手段から出力された場合であっても、関連付記憶手段を参照することによってユーザIDを特定することができ、振分設定ファイルを参照することでこのユーザIDに関連付けられたDBサーバを特定することが可能となる。
また、各ユーザに係るデータの格納先を別のDBサーバに変更するデータの再配置に際しても、リバランシング装置がAPサーバから取得した関連付データに基づいて各既存データに係るユーザIDを特定した上で、新規振分設定ファイルに基づいて各既存データの再配置先を特定する仕組みを備えているため、ユーザIDを有さない既存データを確実に新たな配置先に移動させることができる。

請求項４に記載したデータ再配置システムによれば、新規振分設定ファイルがリバランシング装置からDB振分手段に送信され、それ以降、DB振分手段は新振分設定ファイルに基づいて各結果データの送信先となるDBサーバを特定するようになるため、新規テーブルを用いた業務処理の体制に確実に移行することが可能となる。

図１は、この発明に係るデータ再配置システム10を示すブロック図であり、APサーバ12と、第１のDBサーバ14と、第２のDBサーバ16と、リバランシング装置19を備えている。
APサーバ12と、第１のDBサーバ14及び第２のDBサーバ16は、通信回線を介してネットワーク接続されている。
またリバランシング装置19も、通信回線を介してAPサーバ12、第１のDBサーバ14及び第２のDBサーバ16とネットワーク接続されている。

APサーバ12は、第１の業務処理部20と、第２の業務処理部22と、DB振分部24と、振分設定ファイル26と、関連付テーブル28を備えている。
第１の業務処理部20及び第２の業務処理部22は、APサーバ12のCPUが、専用のアプリケーションプログラムに従って必要な処理を実行することにより実現される。なお、業務処理部の数について特に限定はない。
第１の業務処理部20及び第２の業務処理部22には、インターネット等の通信ネットワーク経由で、ユーザが操作するクライアント端末30及び管理者が操作するクライアント端末（以下「管理端末40」）が接続される。
DB振分部24は、APサーバ12のCPUが、専用のミドルウェアに従って必要な処理を実行することにより実現される。

振分設定ファイル26は、APサーバ12の外部記憶装置内に格納されており、図示は省略したが、このAPサーバ12によって提供されるサービスの全ユーザの「ユーザID」と、当該ユーザに係るデータが格納される「DBサーバの特定情報（サーバ名等）」との組合せ（対応関係）が格納されている。新規ユーザの加入があった場合、この振分設定ファイル26は、当該ユーザのユーザIDと対応のDBサーバの特定情報との組合せが追加されたものに更新される。
関連付テーブル28も、APサーバ12の外部記憶装置内に設けられており、図２に示すように、「伝票番号」と「ユーザID」のデータ項目を備えている。

第１のDBサーバ14及び第２のDBサーバ16は、それぞれ伝票合計テーブル32、伝票明細テーブル34、伝票取消テーブル36を備えている。
伝票合計テーブル32には、図３に示すように、「伝票番号」、「ユーザID」、「合計金額」のデータ項目が設定されている。
また、伝票明細テーブル34には、図４に示すように、「伝票番号」、「商品名」、「数量」、「単価」、「金額」のデータ項目が設定されている。
伝票取消テーブル36には、図５に示すように、「伝票番号」及び「取消理由」のデータ項目が設定されている。
上記の「伝票番号」が、各テーブルに格納された異種データを関連付ける共通の主キー項目に該当する。

各DBサーバの伝票合計テーブル32、伝票明細テーブル34、伝票取消テーブル36には、例えば100万ユーザ分のデータがそれぞれ格納されている。
また、同一ユーザに関連するデータは同一のDBサーバで管理した方が障害局所化の観点から望ましいため、同一ユーザに係る伝票合計データ、伝票明細データ及び伝票取消データは、同一のDBサーバ内に格納されている。

リバランシング装置19は、OS及び専用のミドルウェアを搭載したコンピュータよりなり、後に詳述するデータの再配置処理を実行する。

つぎに、図６及び図７のフローチャートに従い、このシステム10におけるデータ分散管理手順について説明する。
まず、第１の業務処理部20は、サービスへのログインに伴いクライアント端末30からユーザIDが送信されると（図６のＳ10）、これをDB振分部24に渡し、ユーザIDの登録を依頼する（Ｓ12）。
これを受けたDB振分部24は、関連付テーブル28に当該ユーザIDのレコードを追加登録する（Ｓ14）。

つぎに、クライアント端末30から商品購入のリクエストが送信されると（Ｓ16）、第１の業務処理部20は伝票合計データを生成し（Ｓ18）、DB振分部24にデータベースへの登録を依頼する（Ｓ20）。

これを受けたDB振分部24は、伝票合計データ中のユーザIDに基づいて関連付テーブル28に格納された上記のレコードを特定し、当該伝票合計データ中の伝票番号を同レコードに登録する（Ｓ22）。
つぎにDB振分部24は、振分設定ファイル26を参照し、当該ユーザIDに予め関連付けられた第２のDBサーバ16を特定する（Ｓ24）。
つぎにDB振分部24は、伝票合計データを第２のDBサーバ16に送信し、その登録を依頼する（Ｓ26）。

これを受けた第２のDBサーバ16は、伝票合計テーブル32にこの伝票合計データを登録する（Ｓ28）。

つぎに、第１の業務処理部20が上記伝票合計データに関連する伝票明細データを生成すると（Ｓ30）、これをDB振分部24に渡し、データベースへの登録を依頼する（Ｓ32）。

これを受けたDB振分部24は、伝票明細データに含まれる伝票番号に基づいて関連付テーブル28に格納された上記の関連付データを参照し、ユーザIDを取得する（Ｓ34）。
つぎにDB振分部24は、振分設定ファイル26を参照し、当該ユーザIDに関連付けられた第２のDBサーバ16を特定する（Ｓ36）。
つぎにDB振分部は、伝票明細データを第２のDBサーバ16に送信し、その登録を依頼する（Ｓ38）。

これを受けた第２のDBサーバ16は、伝票明細テーブル34にこの伝票明細データを登録する（Ｓ40）。

伝票明細データ自体はDBサーバの振分基準となる「ユーザID」を有していないが、関連付テーブル28においてユーザIDと関連付けられている「伝票番号」を有しているため、DB振分部24は関連付テーブル28及び振分設定ファイル26を参照することで、格納先となる第２のDBサーバ16を確実に特定することができる。

つぎに、管理端末40から伝票番号及び取消理由を特定した注文取消のリクエストがAPサーバに送信されると（図７のＳ50）、第２の業務処理部22は伝票取消データを生成し（Ｓ52）、DB振分部24にデータベースへの登録を依頼する（Ｓ54）。
これを受けたDB振分部24は、伝票取消データに含まれる伝票番号に基づいて関連付テーブル28に格納された上記の関連付データを参照し、ユーザIDを取得する（Ｓ56）。

つぎにDB振分部24は、振分設定ファイル26を参照し、当該ユーザIDに関連付けられた第２のDBサーバを特定する（Ｓ58）。
つぎにDB振分部24は、伝票取消データを第２のDBサーバ16に送信し、その登録を依頼する（Ｓ60）。
これを受けた第２のDBサーバ16は、伝票取消テーブル36にこのデータを登録する（Ｓ62）。

伝票取消データは、DBサーバの振分基準となる「ユーザID」を有しておらず、しかも伝票合計データや伝票取消データとは発生のタイミングが異なっているが、関連付テーブル28においてユーザIDと関連付けられている「伝票番号」を有しているため、DB振分部24は関連付テーブル28及び振分設定ファイル26を参照することで、格納先となる第２のDBサーバ16を確実に特定することができる。

上記においては、まずユーザがログインした時点でユーザIDが関連付テーブル28に登録され（Ｓ14）、伝票合計データの登録時点で関連付テーブル28に伝票番号が登録される（Ｓ22）例を示したが、このシステム10はこれに限定されるものではない。
すなわち、第１の業務処理部20から伝票合計データが送信された時点で、DB振分部24が当該伝票合計データからユーザIDと伝票番号を取り出し、一度に関連付テーブル28に登録することもできる。

つぎに、このシステム10におけるデータ再配置方法について説明する。
まず、図８に示すように、これまで第１のDBサーバ14及び第２のDBサーバ16によってユーザの取引データを管理していたシステム10に第３のDBサーバ18を追加し、合計３台のDBサーバによってデータを分散管理する体制に移行することを前提に論を進める。

具体的には、図９(a)に示すように、これまで第１のDBサーバ14及び第２のサーバ16の「既存テーブル」によって分散管理されていたデータを、図９(b)に示すように、新規の振分ルールに基づいて第１のDBサーバ14、第２のDBサーバ16、第３のDBサーバ18に設けられた「新規テーブル」に振り分け直すと共に、以後は３台のDBサーバの新規テーブルを用いた分散管理方式に機能を拡張することを意味している。

図１０及び図１１は、このデータ再配置に係る処理手順を示すフローチャートである。
まず、管理端末40から「新規振分ルール」及び「新規振分設定ファイル」を伴うデータ再配置の指令が送信され、これをリバランシング装置19が受信すると（図１０のＳ70）、第１のDBサーバ14、第２のDBサーバ16、第３のDBサーバ18に対して、新規テーブルの生成を依頼する（Ｓ71）。

上記の新規振分ルールには、拡張後のDBサーバの構成、各DBサーバが備えるべきテーブルの構成が含まれている。
また、上記の新規振分設定ファイルには、現時点での全ユーザの「ユーザID」と、各ユーザに係るデータが格納されるべき「拡張後のDBサーバの特定情報（サーバ名等）」との組合せ（対応関係）が格納されている。

これを受けた第１のDBサーバ14、第２のDBサーバ16、第３のDBサーバ18では、指定された仕様のテーブルがそれぞれ新設される（Ｓ72）。
この結果、第１のDBサーバ14及び第２のDBサーバ16においては、この時点で同じ構成のテーブルが新規／既存の２セット分存在していることとなる。

つぎにリバランシング装置19は、APサーバ12のDB振分部24に対して、データの再配置モードへの移行を指令する（Ｓ73）。
これを受けたDB振分部24は、データベースの参照及び更新に関し、再配置モードに移行する（Ｓ74）。
ここで「再配置モード」とは、データの参照・更新先は既存テーブルのままとしつつも、データの更新を行う場合にはメモリ上にその更新履歴情報を逐一保存することを意味している。
この「更新履歴情報」には、ユーザIDと伝票番号の組合せからなる関連付データ、更新データ、更新種別（削除、追加、変更）、更新日時が少なくとも含まれている。

つぎにリバランシング装置79は、第１のDBサーバ14及び第２のDBサーバ16に対し、既存テーブルに格納されている既存データの送信を依頼する（Ｓ75）。
これを受けた第１のDBサーバ14及び第２のDBサーバ16は、現時点で既存テーブルに格納されている全データをリバランシング装置19に送信する（Ｓ76）。

つぎにリバランシング装置79は、DB振分部24に対して関連付データの送信を依頼する（Ｓ77）。
これを受けたDB振分部24は、関連付テーブル28に格納された現時点における関連付データをリバランシング装置79に送信する（Ｓ78）。

リバランシング装置79は、この関連付データと、先に管理端末40から送信された新規振分設定ファイルに基づいて、第１のDB サーバ14及び第２のDBサーバ16から送信された既存データの移行先を決定する（Ｓ79）。
すなわち、関連付データには各伝票番号とユーザIDとの対応関係が規定されているため、これに第１のDB サーバ14及び第２のDBサーバ16から送信された既存データの伝票番号を突き合わせることにより、ユーザIDが特定される。
つぎに、このユーザIDを新規振分設定ファイルの記述に当てはめることにより、移行先となるDBサーバが特定される。

つぎにリバランシング装置79は、第１のDBサーバ14、第２のDBサーバ16、第３のDBサーバ18に対して、各既存データを新規テーブルに格納することを依頼する（Ｓ80）。
これに対し第１のDBサーバ14、第２のDBサーバ16、第３のDBサーバ18は、送信された既存データを新規テーブルに格納する（図１１のＳ81）。

リバランシング装置79は、第１のDBサーバ14、第２のDBサーバ16、第３のDBサーバ18から新規テーブルへの格納完了の通知を受信した後、DB振分部24に対してメモリ上に保持された更新履歴情報の送信を依頼する（Ｓ82）。
これを受けたDB振分部24は、メモリ上に蓄積された更新履歴情報をリバランシング装置79に送信する（Ｓ83）。

リバランシング装置79は、この更新履歴情報に含まれる関連付データと新規振分設定ファイルに基づいて、更新履歴情報の反映先を決定する（Ｓ84）。
すなわち、関連付データには各伝票番号とユーザIDとの対応関係が規定されているため、これに更新履歴情報に含まれる更新データの伝票番号を突き合わせることにより、ユーザIDが特定される。
つぎに、このユーザIDを新規振分設定ファイルの記述に当てはめることにより、反映先となるDBサーバが特定される。

つぎにリバランシング装置79は、第１のDBサーバ14、第２のDBサーバ16、第３のDBサーバ18に対して、各更新データを日時順に新規テーブルに反映させることを依頼する（Ｓ85）。
これに対し第１のDBサーバ14、第２のDBサーバ16、第３のDBサーバ18は、送信された更新データによって新規テーブルを順に更新する（Ｓ86）。

またリバランシング装置79は、DB振分部24に対して新規振分設定ファイルを送信すると同時に（Ｓ87）、再配置モードの終了を通知する（Ｓ88）。
これを受けたDB振分部24は、新規振分設定ファイルによって振分設定ファイル26を上書更新すると同時に（Ｓ89）、再配置モードを解除する（Ｓ90）。

以後、DB振分部24は新規振分設定ファイルに記述された「各ユーザIDと第１のDB サーバ14〜第３のDBサーバ18との対応関係」を参照することにより、新規テーブルにアクセスするようになる。
また、DB振分部24は、更新履歴情報のメモリへの保存を停止する。

リバランシング装置79は、適当なタイミングで第１のDB サーバ14及び第２のDBサーバ16に対し既存テーブルの削除を依頼する（Ｓ91）。
これを受けた第１のDB サーバ14及び第２のDBサーバ16は、それぞれの既存テーブルを削除する（Ｓ92）。

上記においては、第３のDBサーバ18を増設する場合について説明したが、この発明はこれに限定されるものではない。
すなわち、当初から第１のDBサーバ14〜第３のDBサーバ18を用いてデータ分散管理を行っていた場合において、単純にユーザの割り振りを変更する場合にも応用可能である。

上記においては、振分設定ファイル26に全ユーザの「ユーザID」と、当該ユーザに係るデータが格納される「DBサーバの特定情報」との組合せを格納しておくと共に、関連付テーブル28に「ユーザID」と「伝票番号」との組合せを格納しておき、両者を参照することによってユーザIDを含まない複数種類の結果データ（伝票明細データや伝票取消データ）の格納先を特定することを前提としていたが、このシステム10はこのような構成に限定されるものではない。

例えば、振分設定ファイル26に振分基準となるデータ項目の値（ユーザIDに限らない）とDBサーバとの対応関係を格納しておき、これを参照することで単純に当該値を含むデータの格納先を特定するようなデータ分散管理システムにも応用可能である。この場合、リバランシング装置はデータの再配置に際してDB振分部24から関連付データを取得する必要がなくなり、新規振分設定ファイルを参照するだけで既存データの再配置先となるDBサーバを特定可能となる。

この発明に係るデータ再配置システムの構成を示すブロック図である。 関連付テーブルの構造を示す図である。 伝票合計テーブルの構造を示す図である。 伝票明細テーブルの構造を示す図である。 伝票取消テーブルの構造を示す図である。 伝票合計データ及び伝票明細データの登録に際しての処理手順を示すフローチャートである。 伝票取消データの登録に際しての処理手順を示すフローチャートである。 このシステムのデータ再配置時における構成を示すブロック図である。 データ再配置のイメージを示す模式図である。 データ再配置に係る処理手順を示すフローチャートである。 データ再配置に係る処理手順を示すフローチャートである。 既存の銀行口座管理システムの構成を示す概念図である。

10 データ再配置システム
12 APサーバ
14 第１のDBサーバ
16 第２のDBサーバ
18 第３のDBサーバ
19 リバランシング装置
20 第１の業務処理部
22 第２の業務処理部
24 DB振分部
26 振分設定ファイル
28 関連付テーブル
30 クライアント端末
32 伝票合計テーブル
34 伝票明細テーブル
36 伝票取消テーブル
40 管理端末

Claims (4)

1. 複数のDBサーバと、各DBサーバと接続されたAPサーバと、各DBサーバ及びAPサーバと接続されたリバランシング装置とを備え、
   各DBサーバの中の少なくとも一部は、相互に共通する構成の既存テーブルを有しており、
   上記APサーバは、入力されたリクエストに対応した処理を実行する少なくとも一つの業務処理手段と、
   この業務処理手段から出力される結果データ中の特定データ項目の値と、当該結果データを格納すべき一のDBサーバとの対応関係を予め定義しておく振分設定ファイルと、
   DB振分手段とを有し、
   このDB振分手段は、
   上記業務処理手段から業務処理の結果データが出力された場合に、上記振分設定ファイルを参照し、当該結果データ中の特定データ項目の値に関連付けられたDBサーバを特定する処理と、
   当該DBサーバに対して上記結果データを送信し、上記既存テーブルへの登録を依頼する処理を実行するシステムにおいて、
   上記リバランシング装置が、上記の各DBサーバに対して相互に共通する構成を備えた新規テーブルの生成を指令する処理と、
   上記既存テーブルを備えたDBサーバから、当該既存テーブルに格納された既存データを取得する処理と、
   各DBサーバと上記特定データ項目の値との新たな対応関係を定義した新規振分設定ファイルを参照し、各既存データの再配置先となるDBサーバを特定する処理と、
   当該DBサーバに対し、当該既存データを上記新規テーブルに格納することを依頼する処理と、
   を実行することを特徴とするデータ再配置システム。
2. 上記DB振分手段は、少なくとも上記リバランシング装置からデータの再配置開始の通知を受けた以降、各DBサーバに対して送信した結果データを含む更新履歴情報を所定の記憶手段に格納する処理と、
   上記リバランシング装置から更新履歴情報の送信指令を受信した際に、上記更新履歴情報をリバランシング装置に送信する処理を実行し、
   上記リバランシング装置は、この更新履歴情報に含まれる結果データに係る特定データ項目の値を抽出する処理と、
   上記の新規振分設定ファイルを参照し、各結果データの反映先となるDBサーバを特定する処理と、
   各DBサーバに対し当該結果データに基づくデータの更新を依頼する処理と、
   を実行することを特徴とする請求項１に記載のデータ再配置システム。
3. 上記少なくとも一部のDBサーバは、ユーザに係る一連の異種データを関連付けるための共通の主キー項目をそれぞれ備えた複数の既存テーブルを有しており、
   上記APサーバは、上記既存テーブルの主キー項目の値とユーザIDとの組合せからなる関連付データを格納する関連付記憶手段を備えており、
   上記APサーバの振分設定ファイルは、各ユーザのユーザIDと、当該ユーザに係る業務処理の結果データを格納すべき一のDBサーバとの対応関係が予め定義されており、
   上記APサーバのDB振分手段が、上記業務処理手段から出力されたユーザID及び上記主キー項目の値の組合せを上記関連付記憶手段に格納する処理と、
   上記業務処理手段からユーザIDを含まない業務処理の結果データが出力された場合に、上記関連付記憶手段を参照し、当該結果データに含まれる上記主キー項目の値に関連付けられたユーザIDを取得する処理と、
   上記振分設定ファイルを参照し、当該ユーザIDに関連付けられたDBサーバを特定する処理を実行し、
   上記リバランシング装置が、上記APサーバから上記関連付データを取得する処理と、
   この関連付データに基づいて、各既存データに係るユーザIDを特定する処理と、
   各DBサーバとユーザIDとの新たな対応関係を定義した新規振分設定ファイルを参照し、各既存データの再配置先となるDBサーバを特定する処理を実行することを特徴とする請求項１に記載のデータ再配置システム。
4. 上記リバランシング装置は、上記新規振分設定ファイルを上記DB振分手段に送信する処理を実行し、
   上記DB振分手段は、以後、この新振分設定ファイルに基づいて各結果データの送信先となるDBサーバを特定することを特徴とする請求項１〜３の何れかに記載のデータ再配置システム。

Images