(57)【要約】【課題】APサーバとDBサーバを同一筐体内に実現するに際し、CPUのマルチコアを有効に活用することにより、処理速度を向上させる。【解決手段】複数のCPUコアを内蔵したCPUパッケージ、及び複数のテーブルを格納しておく外部記憶装置30を備えたサーバコンピュータ11と、このコンピュータ11に起動されたAPサーバ32と、第１のDBサーバ36〜第６のDBサーバ46を備えたデータ管理システム10。APサーバ32と各DBサーバには、それぞれ複数の異なるCPUコアが専用的に割り当てられている。APサーバ32は、業務処理の実行に必要なデータの種類を特定する機能と、各DBサーバに対して必要なデータの抽出を依頼する機能と、DBサーバから取得したデータに対して必要な演算処理を施す機能を備える。各DBサーバにデータの抽出を依頼するに際しては、処理を担当するCPUコアを具体的に指定した状態でSQLが発行される。【選択図】図２
2015210665.tif 000002
【特許請求の範囲】
【請求項１】
複数のCPUコアを内蔵したCPUパッケージ、及び複数のテーブルを格納しておく外部記憶装置を備えたコンピュータと、
このコンピュータ上でAPサーバ用プログラムを起動させることによって構成されたAPサーバと、
上記コンピュータ上でDBサーバ用プログラムを複数起動させることによって構成された複数のDBサーバを備え、
上記の外部記憶装置には、相互に共通するデータを格納する複数のテーブルが、DBサーバ単位で別個に格納されており、
上記のAPサーバ及び各DBサーバには、それぞれ複数の異なるCPUコアが専用的に割り当てられており、
上記APサーバは、業務処理の実行に必要なデータの種類を特定する機能と、
上記DBサーバの何れかに対して必要なデータの抽出を依頼する機能と、
当該DBサーバから取得したデータに対して必要な演算処理を施す機能と、
業務処理によって生じたデータの登録を、上記の全DBサーバに対して同時に依頼する機能を少なくとも備えており、
上記DBサーバにデータの抽出または登録を依頼するに際しては、当該処理を担当するCPUコアを具体的に指定した状態でSQLを発行し、
これを受けたDBサーバでは、指定されたCPUコアが対応の処理を実行することを特徴とするデータ管理システム。
【請求項２】
上記コンピュータは、上記CPUパッケージを複数備えており、
各CPUパッケージには専用のローカルメモリが割り当てられており、
上記APサーバ及び上記DBサーバの少なくとも一部には、それぞれ別個のCPUパッケージに属するCPUコアが割り当てられており、
上記APサーバ及び各DBサーバには、ローカルメモリにのみアクセス可能で、他のCPUパッケージに専用的に割り当てられたローカルメモリにはアクセスできない制約が課せられていることを特徴とする請求項１に記載のデータ管理システム。
【請求項３】
上記APサーバには、上記の各DBサーバに対してデータの挿入及び抽出を依頼することのみが許容され、データの更新及び削除を依頼することが禁止される制約が課せられていることを特徴とする請求項１または２に記載のデータベース管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はデータ管理システムに係り、特に、一つの筐体内に業務処理を担当するAPサーバ機能とデータベースの管理を担当するDBサーバ機能を併存させる技術に関する。
【背景技術】
【０００２】
通常、業務処理を担当するAPサーバと、業務処理の結果である各種データをデータベースに格納して管理するDBサーバとは別個のサーバコンピュータで構成され、それぞれの間を通信ネットワーク経由で接続することが行われている。このため、APサーバとDBサーバ間ではイーサネット（登録商標）による通信のオーバーヘッドが発生し、高速な処理が実現できなかった（非特許文献１参照）。
【０００３】
もちろん、１台のサーバコンピュータ内にAPサーバ用プログラムとDPサーバ用プログラムをセットアップすることにより、APサーバとDBサーバを同一筐体内に形成することは従来でも可能であり、これにより通信のオーバーヘッドをなくすこと自体は実現できる。
しかしながら、この場合にはAPサーバとDBサーバとの間でコンピュータのリソースを奪い合う形になるため、通信のオーバーヘッドが解消されることによる高速化のメリットが半ば相殺されてしまい、全体としての処理速度が劇的に向上することは期待できなかった。
【０００４】
ところで、コンピュータの処理能力の向上は、以前は主としてCPUのクロック数の向上に依存してきたが、発熱や消費電力の問題が浮上したため、2003年〜2005年頃を境にCPUのクロック数は頭打ちと状態となっている。その代わりに、近年ではCPUのマルチコア化が進み、比較的低いクロック数のCPUコアであっても、一つのパッケージ内に４〜６個のCPUコアを格納させて処理の並列化を図ることにより、増え続けるデータ処理量に対応することが期待されている。
【０００５】
確かに、DNA解析や気象解析のように、純粋な演算処理を主体とした科学技術計算の場合には、多数のCPUコアを連携させることにより、処理能力を比較的容易に向上させることができる。
これに対し、データベースに蓄積された大量のデータを複雑に組み合わせて参照する必要のある業務系処理の場合には、DBサーバにおけるデータの抽出処理や演算処理に時間を要するため、例えAPサーバ及びDBサーバを載せるサーバコンピュータのCPUコア数を増やしたとしても、直ちに処理速度の向上には結びつかないことが指摘されていた。
【０００６】
【非特許文献１】「ちょっと待った！」、オーバーヘッドを忘れていませんかインターネットURL：http://itpro.nikkeibp.co.jp/free/TIS/denwa/20040517/1/  検索日：２０１４年４月３日
【発明の開示】
【発明が解決しようとする課題】
【０００７】
この発明は、このような現状を鑑みて案出されたものであり、APサーバとDBサーバを同一筐体内に実現するに際して、CPUのマルチコアを有効に活用することにより、APサーバ及びDBサーバの処理速度を飛躍的に向上させる技術を提供することを目的としている。
【課題を解決するための手段】
【０００８】
上記の目的を達成するため、請求項１に記載したデータ管理システムは、複数のCPUコアを内蔵したCPUパッケージ、及び複数のテーブルを格納しておく外部記憶装置を備えたコンピュータと、このコンピュータ上でAPサーバ用プログラムを起動させることによって構成されたAPサーバと、上記コンピュータ上でDBサーバ用プログラムを複数起動させることによって構成された複数のDBサーバを備え、上記の外部記憶装置には、相互に共通するデータを格納する複数のテーブルが、DBサーバ単位で別個に格納されており、上記のAPサーバ及び各DBサーバには、それぞれ複数の異なるCPUコアが専用的に割り当てられており、上記APサーバは、業務処理の実行に必要なデータの種類を特定する機能と、上記DBサーバの何れかに対して必要なデータの抽出を依頼する機能と、当該DBサーバから取得したデータに対して必要な演算処理を施す機能と、業務処理によって生じたデータの登録を、上記の全DBサーバに対して同時に依頼する機能を少なくとも備えており、上記DBサーバにデータの抽出または登録を依頼するに際しては、当該処理を担当するCPUコアを具体的に指定した状態でSQLを発行し、これを受けたDBサーバでは、指定されたCPUコアが対応の処理を実行することを特徴としている。
【０００９】
請求項２に記載したデータ管理システムは、請求項１のシステムであって、さらに、上記コンピュータは上記CPUパッケージを複数備えており、各CPUパッケージには専用のローカルメモリが割り当てられており、上記APサーバ及び上記DBサーバの少なくとも一部には、それぞれ別個のCPUパッケージに属するCPUコアが割り当てられており、上記APサーバ及び各DBサーバには、ローカルメモリにしかアクセスできない制約が課せられていることを特徴としている。
【００１０】
請求項３に記載したデータ管理システムは、請求項１または２のシステムであって、さらに、上記APサーバには、上記の各DBサーバに対してデータの挿入及び抽出を依頼することのみが許容され、データの更新及び削除を依頼することが禁止される制約が課せられていることを特徴としている。
【発明の効果】
【００１１】
請求項１に記載したデータ管理システムの場合、コンピュータ上に起動されたAPサーバ及び複数のDBサーバに対して、それぞれ別個のCPUコアが専用的に割り当てられているため、同一の筐体内にAPサーバと複数のDBサーバを共存させても、CPUリソースの競合が生じることはない。
また、各DBサーバは相互に独立したテーブルを備えており、各テーブルには共通のデータが格納されているため、APサーバは複数のDBサーバに対して同時に異なるデータの抽出を依頼することで、全体における処理速度を向上させることができる。
しかも、APサーバからDBサーバにデータ抽出のSQLを発行するに際しては、当該処理を担当すべきCPUコアを指定した形でなされるため、マルチコア化されたCPUの潜在能力を極限まで引き出すことが可能となる。すなわち、業務処理に必要なデータの種類や演算の手順を知悉しているのはAPサーバであるため、同時並列的に処理可能な場面では異なるCPUコアを指定して異なるデータの抽出を依頼することで、CPUコアの稼働率を上げることができる。
APサーバは、DBサーバから抽出したデータに対し演算処理する機能を備えているため、複数のDBサーバからそれぞれ別個にデータを抽出した場合であっても、各データを結合したり、ソートやマッチングしたりする処理を、APサーバ側で有効に実行することができる。
【００１２】
請求項２に記載したデータ管理システムの場合、APサーバ及び各DBサーバの利用可能なメモリがローカルメモリに限定され、リモートメモリへのアクセスが禁じられるため、さらなる処理の高速化が実現できる。
【００１３】
請求項３に記載したデータ管理システムの場合、DBサーバ側の処理内容が単純化される結果、各DBサーバからの応答性能をさらに向上させることが可能となる。
【発明を実施するための最良の形態】
【００１４】
図１は、この発明に係るデータ管理システム10を実現するためのハードウェア構成を示すものであり、サーバコンピュータ11内には、第１のCPUパッケージ12、第２のCPUパッケージ14、第３のCPUパッケージ16、第４のCPUパッケージ18を備えたマザーボード20が収納されている。
【００１５】
各CPUパッケージ内には、それぞれ15個のCPUコアが形成されているため、サーバコンピュータ11は合計で60個ものCPUコアを有していることとなる。
各CPUパッケージは、マザーボード20上に設けられたCPUソケット（図示省略）にそれぞれ装着されている。
【００１６】
各CPUパッケージには、それぞれ専用のメモリ（ローカルメモリ）が割り当てられている。
すなわち、第１のCPUパッケージ12には第１のメモリ22が、第２のCPUパッケージ14には第２のメモリ24が、第３のCPUパッケージ16には第３のメモリ26が、第４のCPUパッケージ18には第４のメモリ28が専属的に設けられている。
【００１７】
サーバコンピュータ11には、SSD（Solid State Drive）よりなる外部記憶装置30が接続されており、この外部記憶装置30内には各種テーブル（詳細は後述）が格納されている。SSDの代わりに、ハードディスクによって外部記憶装置30を構成することもできる。
【００１８】
各CPUコアには、それぞれ固有の機能が予め割り当てられている。
すなわち、第１のCPUパッケージ12内に形成されたコア(01)〜コア(15)には、APサーバ32が専用的に割り当てられている。
【００１９】
また、第２のCPUパッケージ14内に形成されたコア(16)には、カーネルスレッド（OS）34が専用的に割り当てられている。
第２のCPUパッケージ14内に形成されたコア(17)〜コア(23)には、第１のDBサーバ36が専用的に割り当てられている。
同じく、第２のCPUパッケージ14内に形成されたコア(24)〜コア(30)には、第２のDBサーバ38が専用的に割り当てられている。
【００２０】
第３のCPUパッケージ16内に形成されたコア(31)〜コア(38)には、第３のDBサーバ40が専用的に割り当てられている。
同じく、第３のCPUパッケージ16内に形成されたコア(39)〜コア(45)には、第４のDBサーバ42が専用的に割り当てられている。
【００２１】
第４のCPUパッケージ18内に形成されたコア(46)〜コア(53)には、第５のDBサーバ44が専用的に割り当てられている。
同じく、第４のCPUパッケージ18内に形成されたコア(54)〜コア(60)には、第６のDBサーバ46が専用的に割り当てられている。
【００２２】
以上のように、１台のサーバコンピュータ11内には、１つのAPサーバ用プログラムと、６つのDBサーバ用プログラム（インスタンス）が起動されており、各サーバにはそれぞれ複数のCPUコアが専用的に割り当てられている。
【００２３】
また、上記した通り、APサーバ32には第１のメモリ22が、カーネルスレッド（OS）34、第１のDBサーバ36及び第２のDBサーバ38には第２のメモリ24が、第３のDBサーバ40及び第４のDBサーバ42には第３のメモリ26が、第５のDBサーバ44及び第６のDBサーバ46には第４のメモリ28が、それぞれローカルメモリとして専用的に割り当てられている。
この場合、各CPUコアはローカルメモリにはダイレクトに（高速に）アクセスできるが、他のCPUパッケージに割り当てられたリモートメモリにアクセスするためには、当該CPUパッケージに属するCPUコアを経由する必要があり、その分、処理速度が低下する問題が生じる。
このため、このシステム10においては、各CPU コアがアクセスできるのはローカルメモリのみに限定され、他のCPUパッケージの配下にあるリモートメモリへのアクセスは禁止されている。
【００２４】
このような割当て及び制約は、OS起動時に次のような「NUMAコントロール」のコマンドを入力することにより、実現される。
【００２５】
［１］APサーバに関する割当て
「#numactl
-physcpubind=1-15    ←コア(01)〜(15)の割当て
-membind=0           ←第１のメモリの割当て
nice -n -5               ←プロセスの優先度の指定
java -jar aloha.jar」    ←APサーバプロセス（Java）の起動
【００２６】
［２］第１のDBサーバに関する割当て
「#numactl
-physcpubind=17-23   ←コア(17)〜(23)の割当て
-membind=1           ←第２のメモリの割当て
nice -n -5                ←プロセスの優先度の指定
su -postgres         ←プロセスの実行ユーザをpostgresに切り替え（su）
-c "pg_ctl -D data1 start"←第１のDBサーバプロセスの起動
（データ領域data1に対するデータベース）」
【００２７】
［３］第２のDBサーバに関する割当て
「#numactl
-physcpubind=24-30   ←コア(24)〜(30)の割当て
-membind=1           ←第２のメモリの割当て
nice -n -5                ←プロセスの優先度の指定
su -postgres          ←プロセスの実行ユーザをpostgresに切り替え（su）
-c "pg_ctl -D data2 start"  ←第２のDBサーバプロセスの起動
（データ領域data2に対するデータベース）」
【００２８】
［４］第３のDBサーバに関する割当て
「#numactl
-physcpubind=31-38  ←コア(31)〜(38)の割当て
-membind=2           ←第３のメモリの割当て
nice -n -5               ←プロセスの優先度の指定
su -postgres         ←プロセスの実行ユーザをpostgresに切り替え（su）
-c "pg_ctl -D data3start"  ←第３のDBサーバプロセスの起動
（データ領域data3に対するデータベース）」
【００２９】
［５］第４のDBサーバに関する割当て
「#numactl
-physcpubind=39-45   ←コア(39)〜(45)の割当て
-membind=2           ←第３のメモリの割当て
nice -n -5                ←プロセスの優先度の指定
su -postgres         ←プロセスの実行ユーザをpostgresに切り替え（su）
-c "pg_ctl -D data4 start"  ←第４DBサーバプロセスの起動
（データ領域data4に対するデータベース）」
【００３０】
［６］第５のDBサーバに関する割当て
「#numactl
-physcpubind=46-53   ←コア(46)〜(53)の割当て
-membind=3           ←第４のメモリの割当て
nice -n -5                ←プロセスの優先度の指定
su -postgres         ←プロセスの実行ユーザをpostgresに切り替え（su）
-c "pg_ctl -D data5 start"  ←第５のDBサーバプロセスの起動
（データ領域data5に対するデータベース）」
【００３１】
［７］第６のDBサーバに関する割当て
「#numactl
-physcpubind=54-60   ←コア(54)〜(60)の割当て
-membind=3           ←第４のメモリの割当て
nice -n -5                ←プロセスの優先度の指定
su -postgres         ←プロセスの実行ユーザをpostgresに切り替え（su）
-c "pg_ctl -D data6 start"  ←第６のDBサーバプロセスの起動
（データ領域data6に対するデータベース）」
【００３２】
図２は、このデータ管理システム10の機能構成を示すブロック図であり、APサーバ32内には、画面処理部52と、処理内容特定部54と、DB処理割当部56と、演算処理部58が形成されている。
画面処理部52には、インターネット等の通信ネットワーク60を介して、複数のクライアント端末62が接続される。
【００３３】
これら画面処理部52、処理内容特定部54、DB処理割当部56及び演算処理部58は、業務処理用のアプリケーションプログラムに従い、CPUコア(01)〜コア(15)が所定の処理を実行することにより実現されるのであるが、この際、OSやミドルウェアによって複数のスレッドが起動されて各CPUコアに割り当てられることにより、マルチタスク処理が実現される。
【００３４】
図３は、各CPUコアと複数のスレッド64との対応関係を表しており、各スレッド64にはスレッドプール66が設けられ、そこに配置された複数のタスク68をスレッド64が順次処理していくイメージが描かれている。
この図におけるスレッド64が、APサーバ32の画面処理部52、処理内容特定部54、DB処理割当部56、演算処理部58として機能し、これらの各機能構成部が実行する具体的な処理が、タスク68に相当する。
【００３５】
各スレッド64は、スレッドプール66に蓄積されたタスク68を古い順に次々と実行していき、自己のスレッドプール66が空になった場合には、他のスレッド64のスレッドプール66に蓄積されたタスク68を、新しい順に実行していく。
【００３６】
DB処理割当部56は、第１のDBサーバ36〜第６のDBサーバ46に対してSQLを発行し、業務処理に必要なデータの抽出（セレクト）や追加（インサート）を指令する機能を果たす。
【００３７】
DB処理割当部56と各DBサーバとの間は、それぞれのCPUコア数に対応した本数のコネクションプール70を介して接続されている。
例えば、第１のDBサーバ36には７個のCPUコアが割り当てられているため７本のコネクションプール70が設けられ、各コネクションプール70は予め特定のCPUコアと関連付けられている。
また、第５のDBサーバ44には８個のCPUコアが割り当てられているため８本のコネクションプール70が設けられ、各コネクションプール70は予め特定のCPUコアと関連付けられている。
【００３８】
外部記憶装置30内には、例えば、仕入テーブル72、注文テーブル73、注文明細テーブル74、注文取消テーブル75、品目テーブル76、完成品テーブル77、原材料テーブル78、原材料目録テーブル79、原価テーブル80、供給者テーブル81等を含むテーブル群が、各DBサーバ単位で複数セット格納されている。
ここでは、第１のDBサーバ36〜第６のDBサーバ46が設けられているため、Ａ〜Ｆの６セットのテーブル群が、それぞれ各DBサーバ専用として外部記憶装置30内の別個の領域に格納されている。
また、後述のように、各テーブル群に属する同一名称のテーブルには、それぞれ同一のレコードが同時に重複して格納される。
【００３９】
図４は、各テーブルに格納されているレコードの構成を例示するものである。
すなわち、仕入テーブル72には、「仕入ID」、「原価ID」、「数量」のデータ項目を備えたレコードが格納されている。
また、注文テーブル73には、「注文ID」、「顧客ID」のデータ項目を備えたレコードが格納されている。
注文明細テーブル74には、「注文明細ID」、「注文ID」、「品目ID」、「数量」のデータ項目を備えたレコードが格納されている。
注文取消テーブル75には、「注文明細ID」のデータ項目を備えたレコードが格納されている。
【００４０】
品目テーブル76には、「品目ID」のデータ項目を備えたレコードが格納されている。
完成品テーブル77には、「品目ID」のデータ項目を備えたレコードが格納されている。
原材料テーブル78には、「品目ID」のデータ項目を備えたレコードが格納されている。
原材料目録テーブル79には、「原材料目録ID」、「親品目ID」、「子品目ID」、「数量」のデータ項目を備えたレコードが格納されている。
原価テーブル80には、「原価ID」、「供給者品目ID」、「原価」のデータ項目を備えたレコードが格納されている。
供給者テーブル81には、「供給者品目ID」、「供給者ID」、「品目ID」のデータ項目を備えたレコードが格納されている。
【００４１】
上記の各テーブル72〜81に関しては、以下の(1)〜(3)の制約が予め課せられている。
(1)キー項目は一つに限定される。
したがって、複数の項目の組合せによってキー項目を構成すること（複合キー）は、禁止される。
【００４２】
(2)APサーバ32が各テーブルにアクセスするに際しては、レコードの参照と追加のみが許容され、既存レコードの削除と更新は禁止される。
【００４３】
このため、既存データを無効にする必要が生じた場合には、レコードを削除する代わりに、他のテーブルに新たなレコードを追加することによって削除と同等の状態が実現される。例えば、注文の取り消しがなされた場合、一般的には取消の対象となる注文データに「取消」を示す値を記述することで状態が管理されることになるが、このシステム10においては、注文取消テーブル75に対象となる「注文明細ID」のレコードを追加することで「取消」の事実が表現される。
【００４４】
また、既存レコードの値に変更が生じた場合には、修正済みの値を備えた異なるプライマリキーのレコードを同一テーブルに追加することで、実質的に値の更新が実現される。例えば、注文明細テーブル74に格納されたあるレコードの数量を「３」から「５」に変更する場合、数量を「５」とした新たなレコードが注文明細テーブル74に追加される。各レコードにはミリ秒精度のタイムスタンプが刻印されているため、これを比較することでレコード間の新旧（更新の事実）が明確化される。
【００４５】
(3)各テーブルのカラムには、NULL値禁止制約、フラグ値禁止制約、区分値禁止制約が課せられる。
まず「NULL値禁止制約」とは、データ項目の値としてNULL（値なし）を充填することが禁止されることを意味しており、このようなNULL値の充填を想定したデータ項目の設定自体が許容されないことになる。
つぎに「フラグ値禁止制約」とは、データ項目の値としてフラグ値（「１／０」、「ON／OFF」、「TRUE／FALSE」等の２値データ）を充填することが禁止されることを意味しており、このようなフラグ値の充填を想定したデータ項目の設定自体が許容されないことになる。
「区分値禁止制約」とは、データ項目の値として区分値（「１：正社員」、「２：パート」、「３：アルバイト」等）を充填することが禁止されることを意味しており、このような区分値の充填を想定したデータ項目の設定自体が許容されないことになる。
【００４６】
上記のようにAPサーバ32によるレコードの削除及び更新が禁止されているため、各テーブルには過去の如何なる時点のデータも温存されることとなり、将来において変更履歴の再現が必要となった場合にも対応できる利点がある。
ただし、十分に時間が経過し、データ保持の必要性が完全になくなった場合には、各DBサーバに直接ログインして削除のSQLを発行することにより、レコードを削除することはできる。
【００４７】
このシステム10の場合、各テーブルに格納される個々のレコードが上記の通り極限まで正規化されており、またデータ間の演算処理はAPサーバ32の演算処理部58によって行われ、DBサーバ側の演算処理によって冗長な中間データが生成されることもないため、レコードの削除や更新の代わりにレコードの挿入によって対応するとしても、ディスク容量が従来に比べて徒に圧迫されることはない。また、キャッシュメモリのヒット率が向上するため、DBサーバの処理の高速化にも資する。
【００４８】
これらの制約ルールは、新規テーブルの設計時やSQL文発行時に、各DBサーバのデータベース管理システムによって適否がチェックされ、制約ルールに違反する処理の実行が拒絶されることにより、その実効性が担保される。
【００４９】
このようなテーブル群によって業務データが管理されている状況下において、新規データの登録を希望するユーザは、画面処理部52からクライアント端末62に送信されたデータ入力画面（図示省略）を通じて、データを入力する。
【００５０】
この入力データを画面処理部52から受け取った処理内容特定部54は、DB処理割当部56に対してデータの登録を依頼する。
DB処理割当部56は、この入力データの登録を依頼するSQLを第１のDBサーバ36〜第６のDBサーバ46に発行する。この際、DB処理割当部56は各DBサーバに対し、特定のCPUコアに関連付けられたコネクションプールを通じてSQLを発行することにより、各DBサーバにおける担当CPUコアを指定する。
【００５１】
これを受けた各DBサーバでは、DB処理割当部56によって指定されたCPUコアにより、対応のテーブルに対するレコードの挿入が一斉に実行される。
この結果、各DBサーバが独立して管理している同名テーブルに、同一レコードが重複して格納されることとなる。
【００５２】
つぎに、ある完成品（例えば品目ID「NRI-0001」）の在庫数についてクライアント端末から照会リクエストが送信された場合の処理手順について、図５及び図６のフローチャートに従い説明する。
【００５３】
まず、画面処理部52から送信された検索条件指定画面上でユーザが完成品である品目ID「NRI-0001」の在庫検索を指定すると、この検索リクエストの実現に必要な処理が処理内容特定部54によって特定される（図５のＳ10）。
【００５４】
具体的には、以下の処理内容が特定された後、順次実行される。
(01)注文明細テーブルから、品目ID「NRI-0001」を備えた全レコードを抽出する（Ｓ12）。
(02)品目ID「NRI-0001」の累積注文数量を算出する（Ｓ14）。
(03)注文取消テーブルから、品目ID「NRI-0001」を備えた全レコードを抽出する（Ｓ16）。
(04)品目ID「NRI-0001」の累積注文取消数量を算出する（Ｓ18）。
(05)品目ID「NRI-0001」の累積注文数量から累積注文取消数量を減算して、現時点における累積実注文数量を算出する（Ｓ20）。
(06)原材料目録テーブルを参照し、品目ID「NRI-0001」を親品目IDとしている子品目IDと、その数量を取得する（Ｓ22）。この子品目IDが、完成品である品目ID「NRI-0001」の原材料を示している。
(07)各子品目IDをキーにして、供給者テーブルから供給者品目IDを取得する（図６のＳ24）。
(08)供給者品目IDをキーにして、原価テーブルから原価IDを取得する（Ｓ26）。
(09)原価IDをキーにして、仕入テーブルから当該原材料に係る全レコードを抽出する（Ｓ28）。
(10)原材料毎に、累積仕入数量を算出する（Ｓ30）。
(11)各原材料の累積仕入数量に基づいて、品目ID「NRI-0001」の生産可能数量を算出する（Ｓ32）。
(12)この生産可能数量から累積実注文数量を減算することにより、当該完成品の現在における在庫数量を算出する（図５のＳ34）。
(13)最後に、「NRI-0001」の在庫数量が記載された処理結果画面をクライアント端末62に送信する（Ｓ36）。
【００５５】
これらの処理の中、データの抽出処理は、DB処理割当部56から各DBサーバに対してSQLを発行することによって実行される。この際、DB処理割当部56は各DBサーバに対し、特定のCPUコアに関連付けられたコネクションプールを通じてSQLを送信する。この結果、DBサーバにおけるレコードの抽出処理は、指定されたCPUコアによって実行される。
また、各DBサーバから送信されたデータに対しては、演算処理部58によってソートやマージ、マッチング、コントロールブレイク等の必要な演算処理が施される。
【００５６】
ところで、上記の各処理の中には、先行する処理が完了しないと後続の処理を実行できないものと、同時並行して処理が可能なものとがある。
例えば、図５に示したように、注文明細テーブル74から該当品目IDのレコードを抽出するＳ12の処理と、注文取消テーブル75から該当品目IDのレコードを抽出するＳ16の処理と、原材料目録テーブル79を参照し、該当品目IDを親品目IDとしている子品目ID及び数量を取得するＳ22の処理は、品目IDが特定された時点で同時並行することができる。
このため、DB処理割当部56は、上記の処理をそれぞれ別個のCPUコアを指定して何れかのDBサーバに抽出処理を依頼する。
【００５７】
また、Ｓ22の処理によって完成品を生産するのに必要な原材料の種類が特定された時点で、図６に示したように、各原材料の仕入数量を算出するのに必要なデータの抽出処理が開始されることになるが、このＳ24〜Ｓ28も原材料毎に同時並行で処理される。
例えば、原材料の数が50種類であった場合、DB処理割当部56は、それぞれ異なる50個のCPUコアを指定して、各DBサーバにレコードの抽出を依頼する。
このように、特定のCPUコアに具体的なレコードの抽出を直接的に割り振ることにより、効率的にデータの参照が可能となる。
【００５８】
なお、原材料の種類が数百種以上に及ぶ場合、原材料単位の処理を一度に異なるCPUコアに割り当てることができなくなる。
このような場合、DB処理割当部56は各CPUコアに順番に原材料毎の処理を依頼し、処理が完了した時点で当該CPUコアに残りの原材料単位の処理を順番に割り当てることを繰り返す。
【００５９】
特定の業務処理を実現するために必要なデータの種類や抽出手順についてはAPサーバ32のアプリケーションプログラムが認識しているため、具体的なレコードの抽出を各DBサーバに対しCPUコアを指定した形で依頼することにより、マルチコアCPUの潜在能力を最も効果的に引き出すことが可能となる。
【００６０】
なお、OSには統計情報に基づいてデータ処理の効率化や省電力化を実現するため、処理の途中で敢えてCPUのクロック数をダウンさせる機能が設けられているが、本システム10のようにCPUコア単位で処理内容をきめ細かく制御する際には邪魔になるため、この種の余計なサービスは事前に無効化しておくことが望ましい。
【図面の簡単な説明】
【００６１】
【図１】この発明に係るデータ管理システムを実現するためのハードウェア構成を示す模式図である。
【図２】この発明に係るデータ管理システムの機能構成を示すブロック図である。
【図３】APサーバの各CPUコアと複数のスレッド64との対応関係を示す模式図である。
【図４】各テーブルに格納されているレコードの構成例を示す図である。
【図５】このシステムにおける処理手順を示すフローチャートである。
【図６】このシステムにおける処理手順を示すフローチャートである。
【符号の説明】
【００６２】
10    データ管理システム
11    サーバコンピュータ
12    第１のパッケージ
14    第２のパッケージ
16    第３のパッケージ
18    第４のパッケージ
20    マザーボード
22    第１のメモリ
24    第２のメモリ
26    第３のメモリ
28    第４のメモリ
30    外部記憶装置
32    APサーバ
36    第１のDBサーバ
38    第２のDBサーバ
40    第３のDBサーバ
42    第４のDBサーバ
44    第５のDBサーバ
46    第６のDBサーバ
52    画面処理部
54    処理内容特定部
56    DB処理割当部
58    演算処理部
60    通信ネットワーク
62    クライアント端末
64    スレッド
66    スレッドプール
68    タスク
70    コネクションプール
72    仕入テーブル
73    注文テーブル
74    注文明細テーブル
75    注文取消テーブル
76    品目テーブル
77    完成品テーブル
78    原材料テーブル
79    原材料目録テーブル
80    原価テーブル
81    供給者テーブル
【図１】
2015210665.tif 000003
【図２】
2015210665.tif 000004
【図３】
2015210665.tif 000005
【図４】
2015210665.tif 000006
【図５】
2015210665.tif 000007
【図６】
2015210665.tif 000008