(57)【要約】【課題】APサーバ側に振分設定ファイルを設けることなく、またAPサーバが複数ある場合でもデータ振分専門の管理サーバを設置することなく、APサーバが独自にデータの振分先を特定可能とする。【解決手段】第１のAPサーバ12と、第２のAPサーバ14と、第１DBサーバ16と、第２のDBサーバ18を備えたデータ分散管理システム10。各DBサーバは、相互に共通する構成のテーブルをそれぞれ有しており、各APサーバは、ユーザの振分キー（携帯電話番号の下４桁）に基づいて一のDBサーバを特定するための振分ルールを備える。各APサーバのDB振分部32は、各ユーザの振分キーを振分ルールに当てはめてデータの格納先となるDBサーバを特定する処理と、特定されたDBサーバに当該ユーザに係るデータを送信してテーブルへの登録を依頼する処理と、特定されたDBサーバに検索条件を送信して当該ユーザに係るデータの抽出を依頼する処理を実行する。【選択図】図２
2018010596.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザグループ単位で設けられた複数のDBサーバと、各DBサーバと接続されたAPサーバを備えたデータ分散管理システムであって、
各DBサーバは、相互に共通する構成のテーブルをそれぞれ有しており、
上記APサーバは、ユーザの振分キーに基づいて当該ユーザのデータを格納すべき一のDBサーバを特定するための振分ルールを有しており、
各ユーザの振分キーを上記振分ルールに当てはめてデータの格納先となるDBサーバを特定する処理と、
特定されたDBサーバに当該ユーザに係るデータを送信してテーブルへの登録を依頼する処理と、
特定されたDBサーバに検索条件を送信して当該ユーザに係るデータの抽出を依頼する処理と、
を実行することを特徴とするデータ分散管理システム。
【請求項２】
上記のAPサーバが複数設けられており、
各APサーバが共通の振分ルールを備えていることを特徴とする請求項１に記載のデータ分散管理システム。
【請求項３】
上記振分ルールが、以下の内容を備えたものであることを特徴とする請求項１または２に記載のデータ分散管理システム。
(1) 振分キーが、所定桁数の数字の組合せにより構成される。
(2) 振分キーを、DBサーバの数で除して整数の商及び余りを求める。
(3) 余りの数値毎に、データの格納先となるDBサーバを予め関連付けておく。
(4) 各ユーザの振分キーに基づいて(2)の計算を行い、算出された余りの数値に基づき、一のDBサーバを特定する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はデータ分散管理システムに係り、特に、大量のトランザクションデータを複数のデータベースサーバで分散管理する技術に関する。
【背景技術】
【０００２】
サービス全体で利用する共通データ（マスターデータ）については、可用性を担保する観点から、単一のデータベースサーバで管理することが望ましい。
これに対し、日々の業務処理を通じて増大していくトランザクションデータについては、負荷分散や障害局所化の要請から、複数のデータベースサーバによって分散管理することが行われている。
【０００３】
例えば特許文献１においては、APサーバの業務処理部から各ユーザに係るデータが出力された際に、DB振分部が、振分設定ファイルを参照してデータの格納先となるDBサーバを特定した上で、当該DBサーバにデータを送信する技術が開示されている。
この振分設定ファイルには、各ユーザのユーザIDと当該ユーザに係るデータを格納すべきDBサーバとの対応関係が予め定義されている。
【特許文献１】特開２０１５−１１８６４５
【０００４】
この特許文献１の技術によれば、確かに、ユーザ数の増大に伴いDBサーバを増設した場合でも、APサーバ内の振分設定ファイルを修正し、ユーザIDと担当DBサーバとの対応関係をアップデートすることにより、柔軟に対応可能となる利点を備えている。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、DBサーバの増設ではなく単に新規のユーザが追加された場合であっても、その都度、上記振分設定ファイルを更新する必要があり、煩に堪えなかった。
また、特許文献１では１台のAPサーバによる運用を前提とした説明となっているため、振分設定ファイルもAPサーバ内で管理されているが、業務処理の負荷分散に伴い多数のAPサーバが増設される場合には、APサーバ毎に振分設定ファイルを設けた上で、それぞれの更新を管理することは困難となる。
したがって、実際には振分設定ファイルを専門に管理する振分管理サーバを設けておき、各APサーバはデータを登録または参照する際にこの振分管理サーバにデータの格納先を問い合わせることとなる。
【０００６】
この結果、余計な通信の発生によるトラフィックの増大や待機時間の発生という問題が生じるのは勿論、万一、何らかの理由で振分管理サーバがダウンした場合には、サービス全体が機能不全に陥る危険性があった。
これに対しては、振分管理サーバを多重化することでダウンに備えることも考えられるが、システムの構成が複雑化することは否めず、また正の振分管理サーバから副の振分管理サーバに切り替わる際に一定のタイムラグが発生するため、その間にデータの整合性が害される懸念もあった。
【０００７】
この発明は、このようなデータの分散管理に係る従来の問題を解決するために案出されたものであり、APサーバ側に振分設定ファイルを設けることなく、またAPサーバが複数ある場合でもデータ振分専門の管理サーバを設置することなく、APサーバが独自にデータの振分先を特定可能とする技術の提供を目的としている。
【課題を解決するための手段】
【０００８】
上記の目的を達成するため、請求項１に記載したデータ分散管理システムは、複数のユーザグループ単位で設けられた複数のDBサーバと、各DBサーバと接続されたAPサーバを備えたデータ分散管理システムであって、各DBサーバは、相互に共通する構成のテーブルをそれぞれ有しており、上記APサーバは、ユーザの振分キーに基づいて当該ユーザのデータを格納すべき一のDBサーバを特定するための振分ルールを有しており、各ユーザの振分キーを上記振分ルールに当てはめてデータの格納先となるDBサーバを特定する処理と、特定されたDBサーバに当該ユーザに係るデータを送信してテーブルへの登録を依頼する処理と、特定されたDBサーバに検索条件を送信して当該ユーザに係るデータの抽出を依頼する処理と、を実行することを特徴としている。
【０００９】
請求項２に記載したデータ分散管理システムは、請求項１のシステムであって、さらに、上記のAPサーバが複数設けられており、各APサーバが共通の振分ルールを備えていることを特徴としている。
【００１０】
請求項３に記載したデータ分散管理システムは、請求項１または２のシステムであって、さらに、上記振分ルールが以下の内容を備えたものであることを特徴としている。
(1) 振分キーが、所定桁数の数字の組合せにより構成される。
(2) 振分キーを、DBサーバの数で除して整数の商及び余りを求める。
(3) 余りの数値毎に、データの格納先となるDBサーバを予め関連付けておく。
(4) 各ユーザの振分キーに基づいて(2)の計算を行い、算出された余りの数値に基づき、一のDBサーバを特定する。
【発明の効果】
【００１１】
この発明に係るデータ分散管理システムの場合、ユーザに関するデータの格納先となるDBサーバが、APサーバにおいて、ユーザに係る振分キーを振分ルールに当てはめることによって論理的に求められる仕組みであるため、各ユーザのユーザIDと担当DBサーバとの対応関係を定義した振分設定ファイルを設ける必要がない。
ユーザの追加がなされた場合であっても、当該ユーザの振分キーに基づいて自動的に振分先のDBサーバが算出される。
【００１２】
また、複数の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サーバを特定する振分ルールを例示したが、他の振分ルールを採用することもできる。
【００４６】
例えば、以下の振分ルールが該当する。
(1) 振分キーが、ユーザIDなど一意となる人工キーによって構成される。
(2) 各DBサーバに数字のレンジ帯を予め割り当てておく。
(3) 各ユーザの振分キーが属するレンジ帯を特定し、当該レンジ帯に割り当てられた一のDBサーバを特定する。
【００４７】
ここで、あるユーザのユーザIDが４桁の数字「6322」であり、各DBサーバに以下のレンジ帯が割り当てられていたとすると、当該ユーザに係るデータの格納先は、第３のDBサーバとなる。
0001 ≦ XXXX ＜2500  →  第１のDBサーバ
2500 ≦ XXXX ＜5000  →  第２のDBサーバ
5000 ≦ XXXX ＜7500  →  第３のDBサーバ
7500 ≦ XXXX ≦9999  →  第４のDBサーバ
なお、ユーザIDがアルファベットなど数字以外の文字列を含む場合は、ASCIIコード変換によって数値に変換することにより、この振分ルールを適用することができる。
【００４８】
また、上記においては複数のAPサーバの存在を前提に説明を展開したが、この発明はこれに限定されるものではなく、１台のAPサーバにおいて各ユーザのデータを複数のDBサーバに分散配置する場合にも適用可能であることは言うまでもない。
【００４９】
クライアント端末としても、上記したスマートフォン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サーバ
【図１】
2018010596.tif 000003
【図２】
2018010596.tif 000004
【図３】
2018010596.tif 000005
【図４】
2018010596.tif 000006
【図５】
2018010596.tif 000007