(57)【要約】【課題】サービスを停止することなくデータの再配置が可能であり、その間の新規データが消失する危険性もないデータ再配置技術の提供。【解決手段】APサーバで生成されたデータを、既存DBサーバ内の旧テーブルに格納して管理しているシステムに対し、新規DBサーバを追加するステップと、新旧の全DBサーバに新テーブルを追加するステップと、ユーザに係るデータを格納する一のDBサーバを特定するための新規振分ルールを、APサーバ上で有効化するステップと、APサーバのデータの参照先を、既存DBサーバ内の旧テーブルに限定し、データの追加先については、旧テーブルの他に、新規振分ルールに従って特定されるDBサーバ内の新テーブルとするステップと、旧テーブルに格納されている既存データを、新規振分ルールに則り各DBサーバ内の新テーブルに振分追加するステップと、振分追加が完了した時点で、APサーバによるデータの参照先及び追加先を新テーブルに限定するステップとからなるデータ再配置方法。【選択図】図７
2018010597.tif 000002
【特許請求の範囲】
【請求項１】
APサーバによって生成された複数のユーザに係るデータを、既存DBサーバ内の旧テーブルに格納して管理しているシステムに対し、
新規DBサーバを追加するステップと、
新規DBサーバ及び既存DBサーバに、上記旧テーブルと共通する構造を備えた新テーブルをそれぞれ追加するステップと、
各ユーザの振分キーに基づいて、上記新テーブルが設けられた各DBサーバの中で、当該ユーザに係るデータを格納する一のDBサーバを特定するための新規振分ルールを、上記APサーバ上で有効化するステップと、
APサーバによるデータの参照先を、既存DBサーバ内の旧テーブルに限定する一方、データの追加先については、上記旧テーブルの他に、上記新規振分ルールに従って特定される何れか一つのDBサーバ内の新テーブルとするステップと、
既存DBサーバ内の旧テーブルに格納されている既存データを、上記新規振分ルールに則り、各DBサーバ内の新テーブルに振分追加するステップと、
この既存データの振分追加が完了した時点で、APサーバによるデータの追加先から上記旧テーブルを除外するステップと、
からなることを特徴とするデータ再配置方法。
【請求項２】
複数のAPサーバによって生成された複数のユーザに係るデータを、既存DBサーバ内の旧テーブルに格納して管理しているシステムに対し、
新規DBサーバを追加するステップと、
新規DBサーバ及び既存DBサーバに、上記旧テーブルと共通する構造を備えた新テーブルをそれぞれ追加するステップと、
各ユーザの振分キーに基づいて、上記新テーブルが設けられた各DBサーバの中で、当該ユーザに係るデータを格納する一のDBサーバを特定するための新規振分ルールを、各APサーバ上で有効化するステップと、
各APサーバによるデータの参照先を、既存DBサーバ内の旧テーブルに限定する一方、データの追加先については、上記旧テーブルの他に、上記新規振分ルールに従って特定される何れか一つのDBサーバ内の新テーブルとするステップと、
既存DBサーバ内の旧テーブルに格納されている既存データを、上記新規振分ルールに則り、各DBサーバ内の新テーブルに振分追加するステップと、
この既存データの振分追加が完了した時点で、各APサーバによるデータの参照先を、各DBサーバ内の新テーブルに変更する一方、データの追加先については、上記旧テーブル及び新テーブルのままとするステップと、
全てのAPサーバによるデータの参照先が新テーブルに変更された時点で、各APサーバによるデータの追加先から上記旧テーブルを除外するステップと、
からなることを特徴とするデータ再配置方法。
【請求項３】
上記旧テーブルを備えた既存DBサーバが複数存在し、
上記APサーバは、各ユーザの振分キーに基づいて、既存DBサーバの中で当該ユーザに係るデータを格納する一のDBサーバを特定するための旧振分ルールを備えており、
上記APサーバが旧テーブルのデータを参照する際や、旧テーブルにデータを追加する際には、この旧振分ルールに則って一のDBサーバが特定されることを特徴とする請求項１または２に記載のデータ再配置方法。
【請求項４】
上記振分ルールが、以下の内容を備えたものであることを特徴とする請求項１〜３何れかに記載のデータ再配置方法。
(1) 振分キーが、所定桁数の数字の組合せにより構成される。
(2) 振分キーを、DBサーバの数で除して整数の商及び余りを求める。
(3) 余りの数値毎に、データの格納先となるDBサーバを予め関連付けておく。
(4) 各ユーザの振分キーに基づいて(2)の計算を行い、算出された余りの数値に基づき、一のDBサーバを特定する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はデータ再配置方法に係り、特に、システムの運用を停止することなく、DBサーバの増設及びデータの再配置を可能とする技術に関する。
【背景技術】
【０００２】
サービス全体で利用する共通データ（マスターデータ）については、可用性を担保する観点から、単一のデータベースサーバで管理することが望ましい。
これに対し、日々の業務処理を通じて増大していくトランザクションデータについては、負荷分散や障害局所化の要請から、複数のデータベースサーバによって分散管理することが行われているが、ネット通販のような大規模サービスの場合、ユーザ数の拡大に応じてDBサーバを順次増設し、各ユーザのデータを新旧DBサーバ間で再配置する必要が生じる。
【０００３】
この点に関し、特許文献１のデータ再配置システムにあっては、DBサーバの増設及びデータの再配置に際し、リバランシング装置が各DBサーバに対して新規テーブルを生成させると共に、各DBサーバの既存テーブルに格納された既存データを収集し、新規振分設定ファイルに基づいて各既存データの再配置先を特定した上で、各DBサーバの新規テーブルに既存データを格納させる仕組みを備えている。
【特許文献１】特開２０１５−１３２９７２
【０００４】
このデータ再配置システムの場合、既存テーブルはそのまま残されるため、既存テーブルに基づいたサービスを継続したまま、大量の既存データを新たな振分基準に従って柔軟に再配置することが可能となる。
また、既存データの再配置中にデータの更新が生じた場合、APサーバはDBサーバ上の既存テーブルにアクセスすることになるが、APサーバ上に更新履歴情報が保持され、この更新履歴情報に基づいてリバランシング装置が更新データを各DBサーバの新規テーブルに反映させる仕組みを備えているため、新旧テーブル間でのデータ整合性を確保することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記更新履歴情報はAPサーバのメモリ上に保持されるため、リバランシング装置によって更新履歴情報がDBサーバのテーブルに反映される前に、何らかの事情でAPサーバがダウンした場合、データの整合性を確保できない危険性があった。
【０００６】
この発明は、このようなデータの再配置に係る従来の問題を解決するために案出されたものであり、サービスを停止することなくデータの再配置を行うことが可能であり、その間に生じた新規データが消失する危険性もないデータ再配置技術の提供を目的としている。
【課題を解決するための手段】
【０００７】
上記の目的を達成するため、請求項１に記載したデータ再配置方法は、APサーバによって生成された複数のユーザに係るデータを、既存DBサーバ内の旧テーブルに格納して管理しているシステムに対し、新規DBサーバを追加するステップと、新規DBサーバ及び既存DBサーバに、上記旧テーブルと共通する構造を備えた新テーブルをそれぞれ追加するステップと、各ユーザの振分キーに基づいて、上記新テーブルが設けられた各DBサーバの中で、当該ユーザに係るデータを格納する一のDBサーバを特定するための新規振分ルールを、上記APサーバ上で有効化するステップと、APサーバによるデータの参照先を、既存DBサーバ内の旧テーブルに限定する一方、データの追加先については、上記旧テーブルの他に、上記新規振分ルールに従って特定される何れか一つのDBサーバ内の新テーブルとするステップと、既存DBサーバ内の旧テーブルに格納されている既存データを、上記新規振分ルールに則り、各DBサーバ内の新テーブルに振分追加するステップと、この既存データの振分追加が完了した時点で、APサーバによるデータの追加先から上記旧テーブルを除外するステップと、からなることを特徴としている。
【０００８】
上記「新規振分ルールを、上記APサーバ上で有効化する」とは、APサーバに新規振分ルールを追加的に導入することや、予めAPサーバが備えていた振分ルールを適用させることを意味している（以下同様）。
【０００９】
請求項２に記載したデータ再配置方法は、複数のAPサーバによって生成された複数のユーザに係るデータを、既存DBサーバ内の旧テーブルに格納して管理しているシステムに対し、新規DBサーバを追加するステップと、新規DBサーバ及び既存DBサーバに、上記旧テーブルと共通する構造を備えた新テーブルをそれぞれ追加するステップと、各ユーザの振分キーに基づいて、上記新テーブルが設けられた各DBサーバの中で、当該ユーザに係るデータを格納する一のDBサーバを特定するための新規振分ルールを、各APサーバ上で有効化するステップと、各APサーバによるデータの参照先を、既存DBサーバ内の旧テーブルに限定する一方、データの追加先については、上記旧テーブルの他に、上記新規振分ルールに従って特定される何れか一つのDBサーバ内の新テーブルとするステップと、既存DBサーバ内の旧テーブルに格納されている既存データを、上記新規振分ルールに則り、各DBサーバ内の新テーブルに振分追加するステップと、この既存データの振分追加が完了した時点で、各APサーバによるデータの参照先を、各DBサーバ内の新テーブルに変更する一方、データの追加先については、上記旧テーブル及び新テーブルのままとするステップと、全てのAPサーバによるデータの参照先が新テーブルに変更された時点で、各APサーバによるデータの追加先から上記旧テーブルを除外するステップと、からなることを特徴としている。
【００１０】
請求項３に記載したデータ再配置方法は、請求項１または２の方法であって、上記旧テーブルを備えた既存DBサーバが複数存在し、上記APサーバは、各ユーザの振分キーに基づいて、既存DBサーバの中で当該ユーザに係るデータを格納する一のDBサーバを特定するための旧振分ルールを備えており、上記APサーバが旧テーブルのデータを参照する際や、旧テーブルにデータを追加する際には、この旧振分ルールに則って一のDBサーバが特定されることを特徴としている。
【００１１】
請求項４に記載したデータ再配置方法は、請求項１〜３の方法であって、上記の振分ルールが、以下の内容を備えたものであることを特徴としている。
(1) 振分キーが、所定桁数の数字の組合せにより構成される。
(2) 振分キーを、DBサーバの数で除して整数の商及び余りを求める。
(3) 余りの数値毎に、データの格納先となるDBサーバを予め関連付けておく。
(4) 各ユーザの振分キーに基づいて(2)の計算を行い、算出された余りの数値に基づき、一のDBサーバを特定する。
【発明の効果】
【００１２】
この発明に係るデータ再配置方法の場合、新規DBサーバが追加され、新旧の各DBサーバ上に追加された新テーブルに対する既存データの再配置が実行されている最中には、既存DBサーバが管理する旧テーブルがデータの参照先となり、また旧テーブルに対する新規データの追加も継続されるため、サービスを停止することなく、データの再配置が可能となる。
しかも、既存データの再配置中に生じた新規データは、新規振分ルールに則って新テーブルにリアルタイムで追加されるため、途中でAPサーバがダウンしても各DBサーバのディスク上に確実に保全される。
【００１３】
APサーバが複数存在する場合には、既存データの再配置完了後、各APサーバにおけるデータの参照先及び追加先を直ちに新テーブルに切り替えるのではなく、全てのAPサーバにおいてデータの参照先が旧テーブルから新テーブルに切り替わった時点で、新規データの追加先から旧テーブルを外すように制御することにより、APサーバ間で切替のタイミングにズレが生じても、不正なデータが参照されることを有効に防止できる。
【発明を実施するための最良の形態】
【００１４】
図１は、この発明の前提となるデータ分散管理システム10の全体構成を示すブロック図であり、第１のAPサーバ12と、第２のAP サーバ14と、第１のDBサーバ16と、第２のDBサーバ18とを備えている。
【００１５】
第１のAPサーバ12及び第２のAPサーバ14には、ロードバランサ（負荷分散装置）20及び通信キャリアの回線網22を介して、多数のユーザが所持するスマートフォン（クライアント端末）24が接続される。
スマートフォン24から送信されたリクエストは、ロードバランサ20により、第１のAPサーバ12及び第２のAPサーバ14の何れかに振り分けられる。
【００１６】
図２は、APサーバの機能構成を示すブロック図であり、第１のAPサーバ12及び第２のAPサーバ14は、それぞれ業務処理部30とDB振分部32を備えている。
この業務処理部30及びDB振分部32は、各APサーバのCPUが、OS及び専用のアプリケーションプログラムに従い必要な処理を実行することにより、実現される。
【００１７】
各業務処理部30は、ユーザのスマートフォン24から送信されたリクエストに応じて、各種の業務処理を実行する。
また、各DB振分部32は、通信回線を介して第１のDBサーバ16及び第２のDBサーバ18と接続されており、業務処理部30から出力されたデータを第１のDBサーバ16及び第２のDBサーバ18の何れか一方に送信して登録を依頼し、あるいは特定のユーザに係るデータを第１のDBサーバ16及び第２のDBサーバ18の何れか一方から取得し、業務処理部30に渡す機能を果たす。
【００１８】
第１のDBサーバ16及び第２のDBサーバ18は、それぞれ同一構造のテーブルを備えている。図においては、第１のDBサーバ16に「TBL 2_01」が設けられており、第２のDBサーバ18に「TBL 2_02」が設けられている。
各DBサーバに設けられるテーブルの数に限定はないが、個々のユーザに係るデータは、第１のDBサーバ16及び第２のDBサーバ18の何れか一方にまとめて格納される。
【００１９】
このように、ユーザに関するデータが複数のDBサーバによって分散管理されているため、万一、何れかのDBサーバに障害が発生しても、影響を受けるのは当該DBサーバにデータが格納されているユーザグループに限定され、残りのDBサーバにデータが格納されているユーザグループに対しては、サービスの提供を続行することが可能となる。
【００２０】
各APサーバのDB振分部32は、それぞれ共通の振分ルールを複数パターンずつ備えている。
ここで「振分ルール」とは、業務処理部30から業務処理の結果としてデータが出力された際に、当該データを第１のDBサーバ16及び第２のDBサーバ18の何れに送信して登録を依頼すべきか、あるいは業務処理部30から特定のデータを抽出するための検索条件が出力された際に、第１のDBサーバ16及び第２のDBサーバ18の何れに対してデータの抽出を依頼すべきか、を決定するための判断基準を意味している。
【００２１】
ここでは、２台のDBサーバ間における振分ルールである「mod2（モード２）」が適用されている。
この「mod2」の振分ルールは、具体的には以下の内容を備えている。
■スマートフォン24の携帯電話番号の少なくとも一部（例えば下４桁）を２で割って整数の商と余りを求める。
■余りが０になる場合→TBL2_01（第１のDBサーバ16）にアクセスする。
■余りが１になる場合→TBL2_02（第２のDBサーバ18）にアクセスする。
【００２２】
各DB振分部32は、これ以外にも複数の振分ルールを予め備えており、外部から入力されたコマンドに応じて適用すべき振分ルールを切り替え可能となされている。
この振分ルールは、DB振分部32を実現するためのプログラム中に記述されている。あるいは、振分ルールが記述された外部ファイルを読み込むことにより、DB振分部32に実装させてもよい。
【００２３】
つぎに、図３のフローチャートに従い、ユーザ甲の所持するスマートフォン24（電話番号：090-XXX-1234）から送信されたリクエストに基づいて、第１のAPサーバ12の業務処理部30が一定の処理を実行し、その結果生じたデータをテーブルに追加登録する場合における、DB振分部32の処理手順を説明する。
【００２４】
まず、業務処理部30から処理結果であるデータ（例えば取引ID、携帯電話番号、商品ID、数量等のデータ項目を備えた商品購入データ）が出力されると（Ｓ10）、これを受けたDB振分部32は、携帯電話番号の下４桁である「1234」を振分キーとして抽出し、これを「mod2」の計算式に代入して以下の計算を行う（Ｓ12）。
１２３４÷２＝６１７…０
【００２５】
この場合、余りが「０」であるため（Ｓ14／(0)）、DB振分部32は当該データの格納先を第１のDBサーバ16が管理する「TBL 2_01」と判定し、第１のDBサーバ16に対して当該データの追加を依頼する（Ｓ16）。
【００２６】
これに対し、携帯電話番号が「090-XXX-3333」であるユーザ丁のスマートフォン24から、第２のAPサーバ14に対して同様のリクエストが送信され、業務処理部30から処理結果である商品購入データが出力されると（Ｓ10）、これを受けたDB振分部32は、携帯電話番号の下４桁である「3333」を振分キーとして抽出し、これを「mod2」の計算式に代入して以下の計算を行う（Ｓ12）。
３３３３÷２＝１６６６…１
【００２７】
この場合、余りが「１」であるため（Ｓ14／(1)）、DB振分部32は当該データの格納先を第２のDBサーバ18が管理する「TBL 2_02」と判定し、第２のDBサーバ18に対して当該データの追加を依頼する（Ｓ18）。
【００２８】
つぎに、図４のフローチャートに従い、ユーザ乙の所持するスマートフォン24（電話番号：090-XXX-1235）から送信されたリクエストに基づいて、第１のAPサーバ12の業務処理部30が乙に関する一定範囲のデータを参照する場合における、DB振分部32の処理手順を説明する。
【００２９】
まず、業務処理部30から検索条件（例えば携帯電話番号＋特定の日付等）が出力されると（Ｓ20）、これを受けたDB振分部32は、携帯電話番号の下４桁である「1235」を振分キーとして抽出し、これを「mod2」の計算式に代入して以下の計算を行う（Ｓ22）。
１２３５÷２＝６１７…１
【００３０】
この場合、余りが「１」であるため（Ｓ24／(1)）、DB振分部32は当該データの格納先を第２のDBサーバ18が管理する「TBL 2_02」と判定し、第２のDBサーバ18に対して該当データの抽出を依頼する（Ｓ28）。
【００３１】
これに対し、携帯電話番号が「090-XXX-4444」であるユーザ丙のスマートフォン24から、第２のAPサーバ14に対して同様のリクエストが送信され、業務処理部30から携帯電話番号を含む検索条件が出力されると（Ｓ20）、これを受けたDB振分部32は、携帯電話番号の下４桁である「4444」を振分キーとして抽出し、これを「mod2」の計算式に代入して以下の計算を行う（Ｓ22）。
４４４４÷２＝２２２２…０
【００３２】
この場合、余りが「０」であるため（Ｓ24／(0)）、DB振分部32は当該データの格納先を第１のDBサーバ16が管理する「TBL 2_01」と判定し、第１のDBサーバ16に対して該当データの抽出を依頼する（Ｓ26）。
【００３３】
上記においては、各ユーザのデータを２台のDBサーバ間で振り分ける例を説明したが、途中でDBサーバを増設し、より多くのDBサーバ間で振り分けるように振分ルールを変更することも可能である。
【００３４】
図５は、その一例として、第３のDBサーバ34及び第４のDBサーバ36を増設し、各ユーザのデータを４台のDBサーバ間で振り分ける場合を示している。
この場合、各DB振分部32が参照する振分ルールも、４台のDBサーバ間における振分ルールである「mod4（モード４）」に切り替えられる。
【００３５】
この「mod4」の振分ルールは、具体的には以下の内容を備えている。
■スマートフォン24の携帯電話番号の少なくとも一部（例えば下４桁）を４で割って整数の商と余りを求める。
■余りが０になる場合→TBL4_01（第１のDBサーバ16）にアクセスする。
■余りが１になる場合→TBL4_02（第２のDBサーバ18）にアクセスする。
■余りが２になる場合→TBL4_03（第３のDBサーバ34）にアクセスする。
■余りが３になる場合→TBL4_04（第４のDBサーバ36）にアクセスする。
【００３６】
当然ながら、これまで第１のDBサーバ16及び第２のDBサーバ18に格納されていた各ユーザのデータは、新しい「mod4」の振分ルールに従い、第１のDBサーバ16、第２のDBサーバ18、第３のDBサーバ34、第４のDBサーバ36に再配置されているものとする（詳細は後述）。
【００３７】
ここで、携帯電話番号が「090-XXX-1234」であるユーザ甲のスマートフォン24から、第１のAPサーバ12に対してリクエストが送信され、業務処理部30から処理結果として携帯電話番号を含むデータが出力されると、これを受けたDB振分部32は、携帯電話番号の下４桁である「1234」を振分キーとして抽出し、これを「mod4」の計算式に振分キーを代入して以下の計算を行う。
１２３４÷４＝３０８…２
【００３８】
この場合、余りが「２」であるため、DB振分部32は、当該データの格納先を第３のDBサーバ34が管理する「TBL 4_03」と判定し、第３のDBサーバ34に対して当該データの追加を依頼する。
【００３９】
これに対し、携帯電話番号が「090-XXX-3333」であるユーザ丁のスマートフォン24から、第２のAPサーバ14に対して同様のリクエストが送信され、その業務処理部30から処理結果であるデータが出力されると、これを受けたDB振分部32は、携帯電話番号の下４桁である「3333」を振分キーとして抽出し、これを「mod4」の計算式に代入して以下の計算を行う。
３３３３÷４＝８３３…１
【００４０】
この場合、余りが「１」であるため、DB振分部32は当該データの格納先を第２のDBサーバ18が管理する「TBL 4_02」と判定し、第２のDBサーバ18に対して当該データの追加を依頼する。
【００４１】
また、携帯電話番号が「090-XXX-1235」であるユーザ乙のスマートフォン24から、第１のAPサーバ12に対して何らかの処理のリクエストが送信され、業務処理部30から携帯電話番号を含む検索条件が出力されると、これを受けたDB振分部32は、携帯電話番号の下４桁である「1235」を振分キーとして抽出し、これを「mod4」の計算式に代入して以下の計算を行う。
１２３５÷４＝３０８…３
【００４２】
この場合、余りが「３」であるため、DB振分部32は、当該データの格納先を第４のDBサーバ36が管理する「TBL 4_04」と判定し、第４のDBサーバ36に対して該当データの抽出を依頼する。
【００４３】
これに対し、携帯電話番号が「090-XXX-4444」であるユーザ丙のスマートフォン24から、第２のAPサーバ12に対して同様のリクエストが送信され、業務処理部30から携帯電話番号を含む検索条件が出力されると、これを受けたDB振分部32は、携帯電話番号の下４桁である「4444」を振分キーとして抽出し、これを「mod4」の計算式に代入して以下の計算を行う。
４４４４÷４＝１１１１…０
【００４４】
この場合、余りが「０」であるため、DB振分部32は、当該データの格納先を第１のDBサーバ16が管理する「TBL 4_01」と判定し、第１のDBサーバ16に対して該当データの抽出を依頼する。
【００４５】
ユーザ数の増大に応じて４台のDBサーバでは追いつかなくなった場合には、適用すべき振分ルールを再度変更することにより、容易に対応可能となる。
例えば、図示は省略したが、８台のDBサーバによってユーザのデータを分散管理する場合、各ユーザの携帯電話番号の下４桁を８で割り、その余りの数値パターン（０〜７）に応じてデータの振分先を決定する振分ルールが適用される。
【００４６】
上記のように、DBサーバの増設を行う際、新旧の各DBサーバのテーブルには、新しい振分ルールに従って既存データが再配置されていることが前提となる。
例えば、図６(a)に示すように、これまで「mod1（モード１）」の振分ルールに従い、第１のDBサーバ16の１台でデータを管理していたところ、図６(b)に示すように、ユーザ数の増大に伴い第２のDBサーバ18を増設した場合、既存テーブルであるTAB 1_00（第１のDBサーバ16）に格納されていたデータを、「mod2（モード２）」の振分ルールに従ってTAB 2_01（第１のDBサーバ16）及びTAB 2_02（第２のDBサーバ18）に分配する必要が生じる。
【００４７】
因みに、「mod1」の振分ルールは以下の内容を備えている。
■スマートフォン24の携帯電話番号の少なくとも一部（例えば下４桁）を１で割って整数の商と余りを求める。
■余りが０になる場合→TBL1_01（第１のDBサーバ16）にアクセスする。
※余りは必ず「０」になる
【００４８】
ただし、１台のDBサーバによってデータを管理している段階では、「mod1」の如き明確な振分ルールを適用することなく、単にAPサーバで生成された全データを第１のDBサーバ16に追加登録する黙示の振分ルールで運用しておき、２台以上のDBサーバによるデータの分散管理に移行する時点で、初めてAPサーバに「mod2」の如き明確な振分ルールを導入することも当然に可能である。
【００４９】
以下、図７のフローチャートに従い、DBサーバの増設及びデータ再配置の手順について説明する。
まず、図８に示すように、システム10内に第２のDBサーバ18を追加し（Ｓ30）、第１のAPサーバ12及び第２のAPサーバ14と接続する。
【００５０】
つぎに、第１のDBサーバ16及び第２のDBサーバ18に対し、「mod2」の新規振分ルールに対応した新テーブルとして、TBL 2_01及びTBL 2_02を追加する（Ｓ32）。
この際、第１のDBサーバ16の旧テーブルであるTBL 1_01は削除されることはなく、そのまま残される。
【００５１】
つぎに、外部からコマンドを入力することにより、第１のAPサーバ12のDB振分部32と、第２のAPサーバ14のDB振分部32において適用される振分ルールの組合せが変更される（Ｓ34）。
【００５２】
具体的には、図８に示されているように、データの参照については従前通り、「mod1」が適用され、「TBL 1_01」のみが対象となる。
これに対し、データの追加については、「mod1」に基づき「TBL 1_01」に対してデータが追加される他、「mod2」の適用により、余りが「０」か「１」かに応じて「TBL 2_01」または「TBL 2_02」に対するデータの振分追加も実行される。
【００５３】
このように、新規データの追加が新テーブルのみならず、旧テーブルである「TBL 1_01」に対しても引き続き行われるため、データの参照先が「TBL 1_01」に限定されていても、第１のAPサーバ12及び第２のAPサーバ14は最新のデータを参照することができる。
また、第１のAPサーバ12及び第２のAPサーバ14における振分ルールの切り替えに時間差が生じ、何れか一方のAPサーバにおいては「mod1」に基づく「TBL 1_01」に対するデータの追加のみが暫く続いたとしても、問題は生じない。
【００５４】
一方で、「TBL 1_01」に格納されていた既存データは、「mod2」の振分ルールに従い、「TBL 2_01」または「TBL 2_02」に振分追加される（Ｓ36）。
具体的には、図９に示すように、第１のDBサーバ16及び第２のDBサーバ18に接続されたデータ再配置装置40が、「TBL 1_01」に格納された既存データを読み出し、当該データの振分キーを「mod2」の計算式に代入する。
そして、データ再配置装置40は、余りが「０」か「１」かに応じて、既存データを「TBL 2_01」または「TBL 2_02」に選択的に追加する。
データ再配置装置40は、データ再配置用のアプリケーションプログラム及び複数の振分ルールを備えたコンピュータよりなる。
【００５５】
上記の「既存データ」とは、各APサーバにおいて上記振分ルールの変更（Ｓ34）が行われた時点より前に発生したデータを意味している。
このため、一方のAPサーバにおいて振分ルールの変更に遅れが生じていた場合であっても、振分ルールの変更前に当該APサーバによって生成され、「TBL 1_01」のみに格納されたデータについては、データ再配置装置40によって既存データとして認定され、新しい振分ルールに則った新テーブルへの再配置が実行される。
【００５６】
この既存データの新テーブルに対する振分追加が完了した時点で（Ｓ38）、外部からコマンドを入力することにより、各APサーバにおいて適用される振分ルールが再度変更される（Ｓ40）。
【００５７】
具体的には、図１０に示すように、データの参照については「mod2」のみが適用され、余りが「０」か「１」かに応じて「TBL 2_01」または「TBL 2_02」が参照先となる（「TBL 1_01」が参照先から外される）。
これに対し、データの追加については、「mod1」に基づいた「TBL 1_01」に対する追加の他に、「mod2」の適用により、余りが「０」か「１」かに応じた「TBL 2_01」または「TBL 2_02」への追加も並列的に実行される。
【００５８】
このように、データの追加については「mod1」に基づく「TBL 1_01」に対する追加も引き続き行われるため、図示のように第２のAPサーバ14における振分ルールの変更が遅れ、参照先が「TBL 1_01」のままであったとしても、不正なデータの参照という問題は生じない。
【００５９】
この振分ルールの全APサーバにおける変更が完了した時点で（Ｓ42）、外部からコマンドを入力することにより、各APサーバにおける振分ルールが再度変更される（Ｓ44）。
【００６０】
具体的には、図１１に示すように、データの追加先から「TBL 1_01」が外される結果、参照及び追加の何れについても「mod2」が適用され、余りが「０」か「１」かに応じて「TBL 2_01」または「TBL 2_02」がアクセス先となる。
この時点で「TBL 1_01」は不要となるため、第１のAPサーバ12及び第２のAPサーバ14から切り離され、廃止される（Ｓ46）。
【００６１】
上記においては１台のDBサーバから２台のDBサーバによる分散化に移行する例を示したが、DBサーバの数をさらに増やす際にも同様の手順で行うことができる。
例えば、２台のDBサーバによる分散化から４台のDBサーバによる分散化に移行する場合、まずは２台のDBサーバを追加し（Ｓ30）、第１のDBサーバ16、第２のDBサーバ18、第３のDBサーバ34、第４のDBサーバ36の４台体制とする。
【００６２】
つぎに、第１のDBサーバ16、第２のDBサーバ18、第３のDBサーバ34、第４のDBサーバ36に対し、「mod4」に対応した新テーブルとして「TBL 4_01」、「TBL 4_02」、「TBL 4_03」、「TBL 4_04」をそれぞれ追加する（Ｓ32）。
この際、第１のDBサーバ16の旧テーブルである「TBL 2_01」や、第２のDBサーバ18の旧テーブルである「TBL 2_02」は、削除されることなく維持される。
【００６３】
つぎに、外部からコマンドを入力することにより、第１のAPサーバ12のDB振分部32と、第２のAPサーバ14のDB振分部32において適用される振分ルールが変更される（Ｓ34）。
【００６４】
具体的には、データの参照については従前通り、「mod2」に従い「TBL 2_01」または「TBL 2_02」が対象となる。
これに対し、データの追加については、「mod2」の適用により、余り（０／１）に応じた「TBL 2_01」または「TBL 2_02」に対する追加の他、「mod4」の適用により、余り（０／１／２／３）に応じた「TBL 4_01」〜「TBL 4_04」に対する追加も実行される。
【００６５】
これと並行して、「TBL 2_01」及び「TBL 2_02」に格納されていた既存データは、「mod4」の振分ルールに従い、「TBL 4_01」〜「TBL 4_04」の何れかに振分追加される（Ｓ36）。
具体的には、データ再配置装置40が「TBL 2_01」及び「TBL 2_02」に格納された既存データを読み出し、各データの振分キーを「mod4」の計算式に代入する。そして、余りの「０」〜「３」に応じて、既存データは「TBL 4_01」〜「TBL 4_04」に選択的に追加される。
【００６６】
この既存データの新テーブルに対する追加が完了した時点で（Ｓ38）、外部からコマンドを入力することにより、各APサーバにおいて適用される振分ルールが再度変更される（Ｓ40）。
【００６７】
具体的には、データの参照については「mod4」のみが適用され、余りが「０」〜「３」の何れかに応じて「TBL 4_01」〜「TBL 4_04」の何れかが参照先となる。
これに対し、データの追加については、「mod2」に基づいた「TBL 2_01」または「TBL 2_02」に対する追加の他に、「mod4」の適用により、「TBL 4_01」〜「TBL 4_04」に対する追加も並列的に実行される。
【００６８】
この振分ルールの変更が全APサーバにおいて完了した時点で（Ｓ42）、外部からコマンドを入力することにより、各APサーバにおける振分ルールが再度変更される（Ｓ44）。
【００６９】
具体的には、データの追加先から「TBL 2_01」及び「TBL 2_02」が外される結果、参照及び追加の何れについても「mod4」が適用され、余りが「０」〜「３」かに応じて「TBL 4_01」〜「TBL 4_04」がアクセス先となる。
この時点で「TBL 2_01」及び「TBL 2_02」は不要となるため、第１のAPサーバ12及び第２のAPサーバ14から切り離され、廃止される（Ｓ46）。
【００７０】
この発明の場合、上記の通り、データの登録については追加（インサート）のみを対象としており、削除（デリート）や更新（アップデート）を行わないことを前提としているため、既存データの再配置に際しては単純に新テーブルに存在しないデータを旧テーブルからコピーすれば済むこととなり、処理の簡素化が実現されている。
【００７１】
これに対し、データの削除が必要な場合には、削除専用のテーブルに削除したいデータの主キーを登録することにより、当該データの無効を表現する。
例えば、図１２(a)に示すように、「取引ID」、「携帯電話番号」、「商品ID」、「数量」、「タイムスタンプ」のデータ項目を備えた商品購入データを格納する商品購入テーブルが各DBサーバに設けられている場合において、あるユーザに係る特定の商品購入データを削除する必要が生じた際には、図１２(b)に示すように、削除したい商品購入データの「取引ID」及び「携帯電話番号」を備えた購入取消データがAPサーバから当該ユーザのデータを管理するDBサーバに送信され、購入取消テーブルに格納される。
【００７２】
APサーバは、当該ユーザの購入履歴を参照するに際しては、まず上記DBサーバの商品購入テーブルから当該ユーザに係る全商品購入データを抽出した後、同DBサーバの購入取消テーブルを参照する。
そして、取引IDを同じくする購入取消データが存在している商品購入データについては、無効なものとして排除する。
この結果、APサーバは現時点で有効な商品購入データを得ることができ、データの実質的な削除が実現される。
【００７３】
また、既登録データの更新が必要な場合には、同じ主キーを備えた修正済みのデータを追加することにより、事実上の更新を実現することができる。
例えば、図１２(a)に示す商品購入データを追加した後、数量を修正する必要が生じた場合、APサーバは同じ取引ID、携帯電話番号、商品IDで、数量及びタイムスタンプの値を変えた購入データを商品購入テーブルに追加する。
【００７４】
APサーバは、当該ユーザの購入履歴を参照するに際しては、まず上記DBサーバの商品購入テーブルから当該ユーザに係る全商品購入データを抽出した後、相互の取引IDを比較する。
そして、同じ取引IDを備えた複数の商品購入データが存在する場合、APサーバはタイムスタンプが最新のものを採用し、残りの商品購入データを除外する。
この結果、APサーバは現時点で有効な購入データを得ることができ、データの実質的な更新が実現される。
【００７５】
上記においては、振分キーとして各ユーザの携帯電話番号の一部を用い、これを分割すべき数で除した際の余りに基づいてデータの格納先となるDBサーバを特定する例を示したが、振分ルールは上記に限定されるものではなく、他の振分キーを採用し、あるいは他の計算式を採用することもできる。
【００７６】
また、上記においては複数のAPサーバの存在を前提に説明を展開したが、この発明はこれに限定されるものではなく、１台のAPサーバにおいて各ユーザのデータを複数のDBサーバに分散配置する場合にも適用可能であることは言うまでもない。
【００７７】
この場合、旧テーブルに格納された既存データの全てがデータ再配置装置40によって新テーブルに追加された時点で（Ｓ38）、直ちにAPサーバによるデータの参照先及び追加先を新テーブルに限定することができ（Ｓ44）、Ｓ40のステップを省略することができる。
【００７８】
クライアント端末としても、上記したスマートフォン24に限定されるものではなく、PCやタブレット端末等であってもよい。
【図面の簡単な説明】
【００７９】
【図１】この発明の前提となるデータ分散管理システムの全体構造を示すブロック図である。
【図２】APサーバの機能構成を示すブロック図である。
【図３】データの登録時におけるDB振分部の処理手順を示すフローチャートである。
【図４】データの参照時におけるDB振分部の処理手順を示すフローチャートである。
【図５】４台のDBサーバでデータを分散管理する場合を示すブロック図である。
【図６】データ再配置の概要を示すブロック図である。
【図７】データ再配置の手順を示すフローチャートである。
【図８】データ再配置の途中経過を示すブロック図である。
【図９】データ再配置の途中経過を示すブロック図である。
【図１０】データ再配置の途中経過を示すブロック図である。
【図１１】データ再配置の途中経過を示すブロック図である。
【図１２】データの構成例を示す図である。
【符号の説明】
【００８０】
10    データ分散管理システム
12    第１のAPサーバ
14    第２のAPサーバ
16    第１のDBサーバ
18    第２のDBサーバ
20    ロードバランサ
22    回線網
24    スマートフォン
30    業務処理部
32    DB振分部
34    第３のDBサーバ
36    第４のDBサーバ
40    データ再配置装置
【図１】
2018010597.tif 000003
【図２】
2018010597.tif 000004
【図３】
2018010597.tif 000005
【図４】
2018010597.tif 000006
【図５】
2018010597.tif 000007
【図６】
2018010597.tif 000008
【図７】
2018010597.tif 000009
【図８】
2018010597.tif 000010
【図９】
2018010597.tif 000011
【図１０】
2018010597.tif 000012
【図１１】
2018010597.tif 000013
【図１２】
2018010597.tif 000014