特許 6226737 データ分散管理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6226737

(24)【登録日】2017年10月20日

(45)【発行日】2017年11月8日

(54)【発明の名称】データ分散管理システム

(51)【国際特許分類】

   G06F 12/00 20060101AFI20171030BHJP

【ＦＩ】

   G06F12/00 545A

【請求項の数】1

【全頁数】8

(21)【出願番号】特願2013-263167(P2013-263167)

(22)【出願日】2013年12月20日

(65)【公開番号】特開2015-118645(P2015-118645A)

(43)【公開日】2015年6月25日

【審査請求日】2016年11月25日

(73)【特許権者】

【識別番号】000155469

【氏名又は名称】株式会社野村総合研究所

(74)【代理人】

【識別番号】100096002

【弁理士】

【氏名又は名称】奥田 弘之

(74)【代理人】

【識別番号】100091650

【弁理士】

【氏名又は名称】奥田 規之

(72)【発明者】

【氏名】安増 拓見

(72)【発明者】

【氏名】小林 修武

(72)【発明者】

【氏名】塩沢 史

【審査官】 桜井 茂行

(56)【参考文献】

【文献】 国際公開第２０１２／１２７９８８（ＷＯ，Ａ１）

【文献】 米国特許出願公開第２０１４／００１２８８７（ＵＳ，Ａ１）

【文献】 特開平１０−２４０７５３（ＪＰ，Ａ）

【文献】 特開２００９−１２２９６６（ＪＰ，Ａ）

【文献】 特開２０１３−１３１０１１（ＪＰ，Ａ）

【文献】 特開２００９−２４５２６３（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１４／０１８８８２５（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

Ｇ０６Ｆ １７／３０

Ｇ０６Ｆ ３／０６

(57)【特許請求の範囲】

【請求項1】

複数のユーザ単位で設けられた複数のDBサーバと、各DBサーバと接続されたAPサーバを備えたデータ分散管理システムであって、
各DBサーバは、相互に共通する構成のテーブルを複数ずつ有しており、
各テーブルは、ユーザに係る一連の異種データを関連付けるための共通の主キー項目を備えており、
上記APサーバは、ユーザの操作するクライアント端末から送信されたリクエストに対応した処理を実行する少なくとも一つの業務処理手段と、
各ユーザのユーザIDと、当該ユーザに係る業務処理の結果データを格納すべき一のDBサーバとの対応関係を予め定義しておく振分設定ファイルと、
上記の主キー項目の値とユーザIDとの対応関係を格納する関連付記憶手段と、
DB振分手段とを備え、
このDB振分手段は、
上記業務処理手段から出力されたユーザID及び上記主キー項目の値の組合せを上記関連付記憶手段に格納する処理と、
上記業務処理手段からユーザIDを含まない業務処理の結果データが出力された場合に、上記関連付記憶手段を参照し、当該結果データに含まれる上記主キー項目の値に関連付けられたユーザIDを取得する処理と、
上記振分設定ファイルを参照し、当該ユーザIDに関連付けられたDBサーバを特定する処理と、
当該DBサーバに対して上記結果データを送信し、その登録を依頼する処理と、
を実行することを特徴とするデータ分散管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、データ分散管理システムに係り、特に、大量のトランザクションデータを複数のデータベースサーバで分散管理する技術に関する。

【背景技術】

【0002】

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

【0003】

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

【0004】

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

【0005】

以下の非特許文献１においては、SNSのユーザ数の急拡大に対応するため、データベースを多数のPCサーバに分散配置させると共に、ユーザIDとDBサーバとの対応関係が定義された分割マップをWebサーバのアプリケーションが参照することで、各ユーザIDに関連付けられたデータの在処を取得する仕組みが開示されている。

【非特許文献1】mixiの生みの親"バタラ氏"が語るMySQLの意外な利用法 インターネットURL：http://techtarget.itmedia.co.jp/tt/news/0709/12/news01.html 検索日：２０１３年１２月１２日

【発明の開示】

【発明が解決しようとする課題】

【0006】

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

【0007】

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

【0008】

この発明は、このようなデータの分散管理に係る従来の問題を解決するために案出されたものであり、ユーザIDのようなデータ分散基準となるデータ項目を有さないデータが発生するサービスについても、関連するデータを同一のデータベースに管理して障害局所化の目的を満たしつつ、データベースの分散管理を可能とする技術の提供を目的としている。

【課題を解決するための手段】

【0009】

上記の目的を達成するため、請求項１に記載したデータ分散管理システムは、複数のユーザ単位で設けられた複数のDBサーバと、各DBサーバと接続されたAPサーバを備えたデータ分散管理システムであって、各DBサーバは、相互に共通する構成のテーブルを複数ずつ有しており、各テーブルは、個々のユーザに係る一連の異種データを関連付けるための共通の主キー項目を備えており、上記APサーバは、ユーザの操作するクライアント端末から送信されたリクエストに対応した処理を実行する少なくとも一つの業務処理手段と、各ユーザのユーザIDと、当該ユーザに係る業務処理の結果データを格納すべき一のDBサーバとの対応関係を予め定義しておく振分設定ファイルと、上記の主キー項目の値とユーザIDとの対応関係を格納する関連付記憶手段と、DB振分手段とを備え、このDB振分手段は、上記業務処理手段から出力されたユーザID及び上記主キー項目の値の組合せを上記関連付記憶手段に格納する処理と、上記業務処理手段からユーザIDを含まない業務処理の結果データが出力された場合に、上記関連付記憶手段を参照し、当該結果データに含まれる上記主キー項目の値に関連付けられたユーザIDを取得する処理と、上記振分設定ファイルを参照し、当該ユーザIDに関連付けられたDBサーバを特定する処理と、当該DBサーバに対して上記結果データを送信し、その登録を依頼する処理を実行することを特徴としている。

【発明の効果】

【0010】

この発明に係るデータ分散管理システムの場合、APサーバのDB振分手段によって、初めにユーザIDと処理結果データに含まれるキー項目の値との組合せが関連付記憶手段に格納される仕組みを備えているため、以後、ユーザIDを含まない処理結果データが業務処理手段から出力された場合であっても、関連付記憶手段を参照することによってユーザIDを特定することができ、振分設定ファイルを参照することでこのユーザIDに関連付けられたDBサーバを特定することが可能となる。
また、一の業務処理手段によってユーザIDとキー項目の値との対応関係が関連付記憶手段に一旦登録されれば、以後、他の業務処理手段による処理結果データをデータベースに格納する際にもこれを利用することが可能となる。

【発明を実施するための最良の形態】

【0011】

図１は、この発明に係るデータ分散管理システム10を示すブロック図であり、APサーバ12と、第１のDBサーバ14、第２のDBサーバ16〜第ｎのDBサーバ18を備えている。APサーバ12と第１のDBサーバ14、第２のDBサーバ16〜第ｎのDBサーバ18は、通信回線を介してネットワーク接続されている。

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

つぎに、クライアント端末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）。

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【図面の簡単な説明】

【0026】

【図1】この発明に係るデータ分散管理システムの構成を示すブロック図である。

【図2】関連付テーブルの構造を示す図である。

【図3】伝票合計テーブルの構造を示す図である。

【図4】伝票明細テーブルの構造を示す図である。

【図5】伝票取消テーブルの構造を示す図である。

【図6】伝票合計データ及び伝票明細データの登録に際しての処理手順を示すフローチャートである。

【図7】伝票取消データの登録に際しての処理手順を示すフローチャートである。

【図8】既存の銀行口座管理システムの構成を示す概念図である。

【符号の説明】

【0027】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】