(57)【特許請求の範囲】
【請求項１】
複数台のコンピュータシステムを用いて構成した分散データベースにデータを格納するデータ格納システムであって、前記分散データベースの構成単位となる互いに記憶容量が等しい複数の仮想サーバと、前記仮想サーバの中からデータを格納する仮想サーバを決定する選別手段とを備え、前記仮想サーバは、データを格納する記憶領域を互いに等しい単位サイズである複数のテーブルに分割したデータ格納部を備え、前記仮想サーバの記憶容量は、前記複数台のコンピュータの記憶容量のうちの最小の記憶容量を上限とするように前記データ格納部の記憶容量を定めてあり、前記選別手段は、前記データが属する集合を識別するように数値で表されたデータＩＤを用いて、同じ集合に属するデータが同じ仮想サーバかつ同じテーブルに格納されるように、前記データを格納する仮想サーバとテーブルとを決定し、前記分散データベースに格納するデータを、前記仮想サーバに分散させ、かつ前記テーブルに分散させて格納することを特徴とするデータ格納システム。
【請求項２】
前記データ格納部は、データを種類ごとに記憶する複数の種類別記憶部を備えることを特徴とする請求項１記載のデータ格納システム。
【請求項３】
前記分散データベースは、前記データ格納部へのデータの格納、前記データ格納部からのデータの提供、前記データ格納部のデータの削除を行う管理機能部を備えることを特徴とする請求項１又は２記載のデータ格納システム。
【請求項４】
前記データには、当該データが属する集合を識別するデータＩＤが付加されており、前記選別手段は、データＩＤに対して、データＩＤを前記仮想サーバの個数で除した剰余で仮想サーバを特定し、かつデータＩＤを前記テーブルの個数で除した剰余でテーブルを特定することにより、同じデータＩＤを持つデータが同じテーブルに格納されるように、データを分散させて格納することを特徴とする請求項１〜３のいずれか１項に記載のデータ格納システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散データベースにデータを格納するデータ格納システムに関するものである。
【背景技術】
【０００２】
従来から、インターネットのような電気通信回線を通してアクセスする様々なデータベースが運営されている。この種のデータベースには、地球上の多地点の気象に関する観測データを集約するデータベースや、電気やガスなどの需要家から検針データを収集するデータベースのように、多数台の端末からデータを繰り返して収集することが必要なものがある。
【０００３】
この種のデータベースが扱うデータの量は膨大であるから、１台のコンピュータシステムでデータベースを構築するのではなく、複数台のコンピュータシステムにデータを分散させて格納することが考えられている（たとえば、特許文献１参照）。したがって、この種のデータベースを管理するデータベース管理システムは、物理的に実在している多数台のコンピュータシステムにデータを分散させて保存する機能と、複数台のコンピュータシステムを統合して１台のコンピュータシステムのように扱う機能とを備えている必要がある。すなわち、データが分散して記憶されるにもかかわらず、利用者に複数台のコンピュータを意識させないようにする必要がある。この種の技術は分散データーベースと呼ばれている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表２００２−５２８８１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した分散データベースには、ハードウェア資源の異なるコンピュータシステムが混在していることがある。データベースシステムでは、ハードウェア資源のうち、とくにＣＰＵ（Central Processing Unit）の性能と記憶装置の記憶容量との相違がスループットに大きく影響する。そのため、分散データベースシステムを構成しているコンピュータシステムにおけるハードウェア資源のばらつきに起因して、データを格納する際の書込時間やデータを提供する際の応答時間にばらつきが生じることがある。
【０００６】
また、分散データベースシステムを構成している複数のコンピュータシステムにデータを格納する際に、単一のコンピュータシステムにアクセスが集中する場合があり、この場合には該当するコンピュータシステムがボトルネックになる。すなわち、分散データベースシステムの全体としてのスループットが低下することになる。
【０００７】
本発明は、分散データベースシステムを構成している複数のコンピュータシステムにハードウェア資源のばらつきがあってもボトルネックの発生が抑制されるようにし、結果的に、ハードウェア資源の劣るコンピュータシステムが混在していてもスループットの低下が生じにくい分散データベースを構築することを可能にしたデータ格納システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明に係るデータ格納システムは、複数台のコンピュータシステムを用いて構成した分散データベースにデータを格納するデータ格納システムであって、分散データベースの構成単位となる互いに記憶容量が等しい複数の仮想サーバと、仮想サーバの中からデータを格納する仮想サーバを決定する選別手段とを備え、仮想サーバは、データを格納する記憶領域を互いに等しい単位サイズである複数のテーブルに分割したデータ格納部を備え、仮想サーバの記憶容量は、複数台のコンピュータの記憶容量のうちの最小の記憶容量を上限とするようにデータ格納部の記憶容量を定めてあり、選別手段は、データが属する集合を識別するように数値で表されたデータＩＤを用いて、同じ集合に属するデータが同じ仮想サーバかつ同じテーブルに格納されるように、データを格納する仮想サーバとテーブルとを決定し、分散データベースに格納するデータを、仮想サーバに分散させ、かつテーブルに分散させて格納することを特徴とする。
【０００９】
このデータ格納システムにおいて、データ格納部は、データを種類ごとに記憶する複数の種類別記憶部を備えることが好ましい。
【００１０】
このデータ格納システムにおいて、分散データベースは、データ格納部へのデータの格納、データ格納部からのデータの提供、データ格納部のデータの削除を行う管理機能部を備えることが好ましい。
【００１１】
このデータ格納システムにおいて、データには、当該データが属する集合を識別するデータＩＤが付加されており、選別手段は、データＩＤに対して、データＩＤを仮想サーバの個数で除した剰余で仮想サーバを特定し、かつデータＩＤをテーブルの個数で除した剰余でテーブルを特定することにより、同じデータＩＤを持つデータが同じテーブルに格納されるように、データを分散させて格納することが好ましい。
【発明の効果】
【００１２】
本発明の構成によれば、分散データベースシステムを構成している複数のコンピュータシステムにハードウェア資源のばらつきがあってもボトルネックの発生が抑制され、結果的に、ハードウェア資源の劣るコンピュータシステムが混在していてもスループットの低下が生じにくい分散データベースを構築することが可能になる。
【図面の簡単な説明】
【００１３】
【図１】実施形態を示すブロック図である。
【図２】同上の概略構成図である。
【図３】同上の動作説明図である。
【図４】他の実施形態を示すブロック図である。
【発明を実施するための形態】
【００１４】
以下に説明する実施形態は、データベースシステムが、電気、ガス、水道などの需要家に設置されたメータの検針値を電気通信回線を通して収集した検針データを格納し、格納されたデータを提供する遠隔検針システムに用いられる場合を想定する。遠隔検針システムでは、一定時間（たとえば、１０分）ごとに得られる検針データを格納することが要求され、また、検針データを需要家ごとに仕分けて管理する必要がある。そのため、本実施形態は、一定時間毎に収集される検針データがレコードとして格納される多数個のテーブルをデータベースシステムが備え、１つの需要家に対応するレコードは、１つのテーブルにまとめて格納されるようにしている。各テーブルの記憶領域は互いに等しい単位サイズにしてある。また、１つのテーブルには複数の需要家のレコードが登録される。すなわち、各需要家の検針データがテーブルに仕分けられる。
【００１５】
なお、以下に説明する実施形態は、データベースシステムの用途を遠隔検針システムに限定する趣旨ではなく、１つのテーブルに同種のレコードが多数個格納され、かつレコードの仕分けが必要な用途であれば、同様の技術を採用可能である。このようなデータを扱う用途には、たとえば、多数の観測点について気象条件の観測データを格納する用途、多数の設備について動作状態の監視データを格納する用途、防災や防犯のために多箇所の監視データを格納する用途などがある。これらの用途では、いずれもデータを定期的ないし不定期的にサンプリングして格納する必要がある。これらの用途は一例であってデータの定点観測を行う用途では、本実施形態において説明する技術でデータを格納することにより後述する効果が期待できる。
【００１６】
いま、データベースシステムに、多数個（たとえば、２５００個）のテーブルが設けられ、各テーブルに、多数個（たとえば、１００万個）のレコードが格納される場合を想定する。この数値例では、１０分毎に検針データを収集し、１個の検針データを１レコードに対応付けている場合であって、１００万の需要家に対応するとすれば、１つの需要家に対して２５００レコードの検針データを格納することが可能である。つまり、約１７日間の検針データが格納される。テーブルの容量の上限を２ＧＢとすると、１レコードについて２ｋＢを使用することが可能である。したがって、データベースシステムの全体で、検針データの格納に必要な容量は５ＴＢ（２５億レコード）になる。
【００１７】
上述のように、比較的短い時間間隔で大量のデータが発生する場合、１つのコンピュータシステムで対応しようとすると、データの収集や提供のための入出力がボトルネックになる上に、排他制御が行われる頻度が高くなる。そのため、入出力の速度や内部の処理能力が高い高性能のコンピュータシステムが必要になるという問題が生じる。この種の問題に対処する技術としては、分散データベースが知られている。すなわち、分散データベースは、複数のコンピュータシステムでそれぞれ構築されているデータベースを、１つのデータベースとみなしてアクセスするデータベース管理システムを備える。分散データベースを用いると、複数のコンピュータシステムにデータが分散して格納されるから、１つのコンピュータシステムで構築されたデータベースにおけるボトルネックを回避することが可能になる。
【００１８】
しかしながら、分散データベースを構築している物理的実体としてのコンピュータシステム（以下では、「実体システム」という）が複数存在している場合に、ハードウェア資源が異なる実体システムが混在することがある。データベースシステムでは、ハードウェア資源のうち、とくにＣＰＵ（Central Processing Unit）の性能と記憶装置の記憶容量との相違はスループットに大きく影響する。そのため、分散データベースシステムを構成している実体システムのハードウェア資源のばらつきに起因して、データを格納する際の書込時間やデータを提供する際の応答時間にばらつきが生じる。
【００１９】
また、分散データベースシステムを構成している複数の実体システムにデータを格納する際に、単一の実体システムにアクセスが集中する場合があり、この場合には該当する実体システムがボトルネックになる。すなわち、分散データベースシステムの全体としてのスループットが低下することになる。
【００２０】
本実施形態は、分散データベースシステムを構成している複数の実体システムにハードウェア資源のばらつきがあってもボトルネックの発生が抑制されるように、以下の構成を採用している。すなわち、以下の構成を採用することによって、ハードウェア資源の劣る実体システムが混在していてもスループットの低下が生じにくい分散データベースの提供が可能になる。
【００２１】
本実施形態は、図２に示すように、複数台（図示例は３台）の実体システム２１，２２，２３を備え、少なくとも１つの実体システム２１と他の実体システム２２，２３とが電気通信回線ＮＴ１を通して通信する構成を用いて説明する。電気通信回線ＮＴ１はインターネットのような広域網である公衆網を想定しているが、専用網や構内網であってもよい。各実体システム２１，２２，２３は、ハードディスク装置のような大容量の記憶装置と、プログラムを実行するＣＰＵと、電気通信回線ＮＴ１を通して他装置と通信するための通信インターフェイス装置を備える。
【００２２】
図１に示すように、実体システム２１，２２，２３は、一体となってサーバ２０として機能し、電気通信回線ＮＴ１に接続された利用者端末３１をクライアントとしたクライアントサーバシステムを構築する。このクライアントサーバシステムは、プレゼンテーション層とアプリケーション層とデータ層とからなる３層アーキテクチャを有し、プレゼンテーション層は利用者端末３１により実現されている。
【００２３】
サーバ２０はデータ層に対応し、図示例において、アプリケーション層に相当するサーバ３２はサーバ２０とは別に設けられている。サーバ３２は、利用者端末３１から要求された処理に対応した依頼をサーバ２０に対して行い、サーバ２０の応答を利用者端末３１に返す機能を備える。
【００２４】
また、後述するように、サーバ２０は、複数台の仮想的なサーバ（以下、「仮想サーバ」という）１０に分割されており、サーバ３２は、複数台の仮想サーバ１０を統合して１台のサーバ２０として動作させる機能を備える。この機能はサーバ３２に設けられるＡＰＩ（Application Program Interface）により実現される。すなわち、サーバ３２のＡＰＩは、利用者端末３１からの要求に対応する仮想サーバ１０を選択する機能を実現するための関数ないし命令を備える。また、サーバ３２のＡＰＩは、複数台の実体システム２１，２２，２３を１台のサーバ２０として扱う機能も備える。
【００２５】
言い換えると、サーバ２０は複数台の実体システム２１，２２，２３により構成された分散データベースであって、仮想サーバ１０は、このサーバ２０の構成単位になる。本実施形態において、各仮想サーバ１０は互いに記憶容量を等しくしてある。
【００２６】
本実施形態は遠隔検針システムを想定しているから、検針データを収集してサーバ２０に格納させるための収集サーバ３３も電気通信回線ＮＴ１に接続される。収集サーバ３３には、複数の仮想サーバ１０の中から検針データを格納する仮想サーバ１０を決定する選別機能部（選別手段）３３１を実現するためのＡＰＩが設けられる。選別機能部３３１の動作については後述する。
【００２７】
仮想サーバ１０は、それぞれデータを格納するデータ格納部１０１と、データベース管理システムの機能を付与する管理機能部１０２とを備える。管理機能部１０２は、実体システム２１，２２，２３に設けたＡＰＩにより実現されている。管理機能部１０２は、データ格納部１０１へのデータの格納、記憶装置から読み出したデータの提供、記憶装置に格納されているデータの削除などのデータの操作を行う機能のほか、トランザクション管理を行う機能などを備える。管理機能部１０２におけるこの種の機能は一般的なデータベース管理システムが備えている機能と同様である。ただし、管理機能部１０２は、トランザクション管理を行うインターフェイス層１０２１、データベース制御を行う上位層１０２２、データベース操作を行う下位層１０２３を備えた３層で構成されている。
【００２８】
上述したようにサーバ２０は、複数台（たとえば、１００台）の仮想サーバ１０に分割されているから、データ格納部１０１も分割される。また、仮想サーバ１０ごとに管理機能部１０２を備えている。ここでは、説明を簡単にするために、データ格納部１０１と管理機能部１０２とが一対一に対応していると仮定する。言い換えると、仮想サーバ１０ごとに、データ格納部１０１と管理機能部１０２とが１つずつ設けられていることになる。
【００２９】
また、本実施形態では、仮想サーバ１０において、データ格納部１０１の記憶容量が互いに等しく設定される。したがって、仮想サーバ１０を構成する実体システム２１，２２，２３の記憶装置の記憶容量にかかわらず、各仮想サーバ１０のデータ格納部１０１の記憶容量は等しくなる。実体システム２１，２２，２３では、一般的な傾向としては、処理能力が高いほど記憶装置の記憶容量が大きくなっている。このことから、仮想サーバ１０においてデータ格納部１０１の記憶容量を等しくしたことにより、実体システム２１，２２，２３の処理能力にかかわらず仮想サーバ１０のスループットはほぼ等しくなると考えられる。
【００３０】
１つの仮想サーバ１０のデータ格納部１０１は、図３に示すように、記憶領域が互いに等しい単位サイズに分割され、各単位サイズの記憶領域がそれぞれテーブル１０１１を形成している。したがって、データ格納部１０１は、複数個（図示例では、１００個）のテーブル１０１１を備える。図示例では、テーブル１０１１ごとに識別用の４桁の番号が割り当ててある。図示例では、テーブル１０１１を識別する番号は「０００１」〜「２５００」になっている。テーブル１０１１を識別する番号の下二桁は、仮想サーバ１０を識別する番号に相当し、「０１」…「９９」「００」が用いられている。なお、「００」は１００番に対応する。
【００３１】
また、需要家には個別に識別情報（以下、「データＩＤ」という）が設定され、図示例は１００万の需要家が存在している場合を想定している。すなわち、テーブル１０１１に登録されるレコードには１００万種類のデータＩＤが付与される。ここに、同じデータＩＤのレコードは、同じテーブル１０１１に格納される。また、データＩＤは数値で設定されるか、適宜に数値に変換され、１番から順に１００００００番まで付与される。ここでは、データが検針データであるから、データＩＤは需要家に対応しているが、一般化すれば、データＩＤは、データが属する集合を識別するために付与されていると言える。
【００３２】
上述のような仮想サーバ１０を構築するには、仮想サーバ１０の個数、１つの仮想サーバ１０の記憶容量、１つのテーブル１０１１の記憶容量などを定める必要がある。
【００３３】
以下では、仮想サーバ１０を適正に構築する手順を説明する。まず、データベースシステムの規模を定めるために、想定される需要家の数、すなわち、想定されるデータＩＤの最大数が必要である。
【００３４】
また、仮想サーバ１０は、実体システム２１，２２，２３により構成されているから、１つの仮想サーバ１０が複数の実体システム２１，２２，２３に跨って構成されることは好ましくない。そのため、仮想サーバ１０を構築するにあたっては、実体システム２１，２２，２３ごとの記憶容量を知る必要がある。
【００３５】
仮想サーバ１０におけるデータ格納部１０１の記憶容量は、実体システム２１，２２，２３が備えている記憶装置のうちの最小の記憶容量が上限になる。したがって、実体システム２１，２２，２３における記憶装置について想定される記憶容量の最小値を求め、この最小値を用いて仮想サーバ１０におけるデータ格納部１０１の記憶容量が定められる。
【００３６】
さらに、１つのテーブル１０１１に格納するデータ量（レコード数）およびテーブル１０１１の記憶容量は設計値であって、需要家から取得して格納するデータ量に応じて適宜に定められることになる。１つのテーブル１０１１に格納されるデータ量の上限値は、仮想サーバ１０におけるデータ格納部１０１の記憶容量として定めた値になる。ただし、実際には、データ格納部１０１の記憶容量よりも十分に小さくすることが好ましい。
【００３７】
以上のように、仮想サーバ１０を用いた分散データベースを構築するには、設計条件として以下の情報が必要である。すなわち、想定されるデータＩＤの最大数、データＩＤごとに格納するレコード数、実体システムの記憶容量、仮想サーバ１０の記憶容量、テーブル１０１１の記憶容量、テーブル１０１１に格納するレコードの最大数が必要である。
【００３８】
これらのパラメータが得られると、仮想サーバ１０の個数、テーブル１０１１の総数の最大値、１つの仮想サーバ１０におけるテーブル１０１１の個数が求められる。また、実体システム２１，２２，２３に対する仮想サーバ１０の対応付けが可能になる。
【００３９】
いま、１つの仮想サーバ１０の記憶容量をＱ、テーブル１０１１の記憶容量をｑとすると、１つの仮想サーバ１０におけるテーブル１０１１の個数はＱ／ｑになる。さらに、想定されるデータＩＤの最大数をＮ、１つのデータＩＤに関して格納するレコード数をｍ、１つのテーブル１０１１に格納するレコード数をｎとすれば、必要なテーブル１０１１の個数はＮ×ｍ／ｎになる。このことから、仮想サーバ１０の個数は、（Ｎ×ｍ／ｎ）／（Ｑ／ｑ）＝Ｎｍｑ／ｎＱになる。
【００４０】
図３に示す構成例は、想定される需要家（データＩＤ）の最大数Ｎを１００万、テーブル１０１１の記憶容量ｑを２ＧＢ、テーブル１０１１に格納するレコード数ｎを１００万としている。さらに、１つの需要家に関して格納するレコード数ｍは２５００個にしている。図３に示す構成例では、複数台の実体システムにおける記憶容量の最小値を５０ＧＢとしている。そのため、仮想サーバ１０の記憶容量Ｑも５０ＧＢとしている。なお、図２の構成例では３台の実体システム２１，２２，２３を用いているが、図３の構成例は、さらに多くの実体システムを用いることになる。
【００４１】
これらの数値を上述した関係式に当てはめると、１つの仮想サーバ１０に設けるテーブル１０１１の個数は、５０ＧＢ／２ＧＢ＝２５個になる。また、データベースシステムを構成する仮想サーバ１０の個数は、（１００００００個×２５００レコード×２ＧＢ）／（１００００００×５０ＧＢ）＝１００個になる。
【００４２】
ここで、データベースシステムを構成する実体システムとして、記憶容量が１００ＧＢの実体システムと、記憶容量が５０ＧＢの実体システムとを用いている場合を想定する。仮想サーバ１０の記憶容量が５０ＧＢであるとすれば、１個の仮想サーバ１０のみを構成する実体システムと、２個の仮想サーバ１０を構成する実体システムとが混在することになる。
【００４３】
上述した構成例において、データベースシステムが、１００ＧＢの実体システムを４０台用い、５０ＧＢの実体システムを２０台用いて構成されていると仮定する。このように仮定すると、１００個の仮想サーバ１０のうち、２０個が５０ＧＢの実体システムに割り当てられ、８０個が１００ＧＢの実体システムに割り当てられる。この構成では、仮想サーバ１０の識別に用いる番号は、複数個の仮想サーバ１０を含む実体システムで構成された仮想サーバ１０の間に、１個の仮想サーバ１０のみを含む実体システムで構成された仮想サーバ１０が並ぶように割り当てることが好ましい。
【００４４】
たとえば、複数の仮想サーバ１０を含む実体システムを用いた仮想サーバ１０を識別する番号に「０１」〜「４０」、「６１」〜「９９」「００」を用い、単体の仮想サーバ１０を含む実体システムを用いた仮想サーバ１０を識別する番号に「４１」〜「６０」を用いる。ここに、複数の仮想サーバ１０を含む実体システムにおいて、仮想サーバ１０を識別する番号は必ずしも連続していなくてもよいが、以下の説明では連続していると仮定して説明する。
【００４５】
ところで、上述の構成を備えるデータベースシステムを用いて検針データを格納する際に、検針データを格納するテーブル１０１１を決定する必要がある。すなわち、収集サーバ３３の選別機能部３３１は、以下に説明する手順で、検針データを格納するための仮想サーバ１０を求め、その仮想サーバ１０に対応する実体システムを決定し、さらに、検針データを格納するテーブル１０１１を決定する。
【００４６】
検針データを格納する仮想サーバ１０は、数値で表されているデータＩＤを用いることにより簡単に決定することができる。すなわち、データＩＤをＸとし、仮想サーバ１０の個数をＫとすると、当該需要家に対応する検針データを格納する仮想サーバ１０を識別する番号は、ＸをＫで除した剰余で求められる（つまり、Ｘ  mod  Ｋ）。ただし、剰余が０になる場合は、「００」の仮想サーバ１０に割り当てられる。
【００４７】
たとえば、データＩＤ＝５０であれば、（５０  mod  １００）＝５０であるから、該当する検針データは５０番の仮想サーバ１０に格納される。また、たとえば、データＩＤ＝３６９３５であれば、（３６９３５  mod  １００）＝３５であるから、該当する検針データは３５番の仮想サーバ１０に格納される。仮想サーバ１０の番号は、収集サーバ３３の選別機能部３３１において、ルックアップテーブルなどによって、実体システムとの対応付けがなされているから、どの実体システムにアクセスするかが決められる。
【００４８】
次に、仮想サーバ１０の中のどのテーブル１０１１に検針データを格納するかを決定する必要がある。上述した構成では、検針データを格納するテーブル１０１１の決定も容易であって、テーブル１０１１の総数をＬとすると、データＩＤがＸであるとき、ＸをＬで除した剰余がテーブル１０１１の番号になる（つまり、Ｘ  mod  Ｌ）。ただし、剰余が０になる場合は、２５００番のテーブル１０１１が割り当てられる。
【００４９】
たとえば、データＩＤ＝５０であれば、（５０  mod  ２５００）＝５０であるから、該当する検針データは００５０番のテーブル１０１１に格納される。また、たとえば、データＩＤ＝３６９３５であれば、（３６９３５  mod  ２５００）＝１９３５であるから、該当する検針データは１９３５番のテーブル１０１１に格納される。
【００５０】
上述したように、検針データを格納する仮想サーバ１０を定めることにより、検針データを格納する実体システムが求められるから、該当する実体システムの範囲で、仮想サーバ１０およびテーブル１０１１に相当する記憶領域を抽出することができる。すなわち、検針データを適正なテーブル１０１１に格納することができる。
【００５１】
このような手順で検針データを格納するテーブル１０１１を選択すると、データＩＤが連続した数値であるときには、図３に矢印で示しているように、各需要家の検針データが異なる仮想サーバ１０に順に格納される。
【００５２】
すなわち、１番の需要家の検針データは１番の仮想サーバ１０に設けた０００１番のテーブルに格納され、２番の需要家の検針データは２番の仮想サーバ１０に設けた０００２番のテーブルに格納される。同様にして、１０１番の需要家の検針データは１番の仮想サーバ１０に設けた０１０１番のテーブル１０１１に格納され、２５００番の需要家の検針データは１００番の仮想サーバ１０の２５００番のテーブル１０１１に格納される。ここに、２５０１番の需要家の検針データは、１番の仮想サーバ１０における０００１番のテーブル１０１１に格納される。要するに、データＩＤを２５００で除した剰余が１である検針データは、０００１番のテーブル１０１１に格納される。このようにして、１００万の需要家に対して、１つのテーブル１０１１には４００の需要家の検針データが格納される。
【００５３】
上述の動作により、あたかも複数台のハードディスクを用いてストライピングを行う場合のように、各需要家の検針データが異なる仮想サーバ１０に振り分けて格納される。すなわち、アクセスが単一の仮想サーバ１０に集中しなくなり、検針データの格納が高速化される。また、１つの仮想サーバ１０の処理能力が比較的低い場合でもボトルネックが生じにくい分散データベースを構築することが可能になる。すなわち、本実施形態では、仮想サーバ１０の記憶容量を等しくし、各仮想サーバ１０の処理能力を平準化したことにより、検針データを格納する際の処理速度も平準化されることになる。
【００５４】
上述した構成例では、需要家の検針データを扱うデータベースの例について説明したが、１つの計測点において複数種類のデータを取得して格納する用途もある。たとえば、需要家における電気の検針データだけではなく、ガスの検針データと水道の検針データとを併せて格納することが可能であり、また、需要家における防犯や防災に関連する情報を格納することなども可能である。つまり、データベースの用途は遠隔検針の用途に限定されず、数値データのほか、テキストデータ、音声データ、画像データなどの複数種類のデータを格納する場合もある。このように、種類の異なるデータを収集する場合は、データの種類が識別可能となるように、データが得られた場所などに関するデータＩＤだけではなくデータの種別名がデータに付加される。
【００５５】
ところで、この種のデータは、データの種類によって情報量が異なるから、複数種類のデータが混在している場合にデータを一括して扱うと、一括されたデータに含まれているデータの種類に応じて情報量に大きなばらつきが生じる。そのため、複数種類のデータが混在した状態で、この種のデータを一括して一つのテーブル１０１１に格納すると、仮想サーバ１０のアクセス時間に大きなばらつきが生じる。
【００５６】
そこで、図４に示すように、仮想サーバ１０のデータ格納部１０１に、データの種類ごとに振り分けてデータを格納する複数個（図示例では３個）の種類別記憶部１０１２，１０１３，１０１４を設けることが望ましい。この場合、仮想サーバ１０には、データの種類を振り分けるための分類機能部１０３が設けられる。分類機能部１０３は、管理機能部１０２と同様にＡＰＩを用いて構成される。すなわち、収集サーバ３３から仮想サーバ１０に転送されたデータは、仮想サーバ１０の分類機能部１０３においてデータの種類ごとに振り分けられ、それぞれの種類別記憶部１０１２，１０１３，１０１４に格納される。
【００５７】
このように、異なる種類のデータが種類別記憶部１０１２，１０１３，１０１４に振り分けて格納される。したがって、データＩＤごとに情報量が異なっていても、種類別記憶部１０１２，１０１３，１０１４に格納されるデータについては、情報量（データ量）のばらつきが抑制される。すなわち、データＩＤごとに、種類別記憶部１０１２，１０１３，１０１４に格納するデータが対応付けられる場合と、データが対応付けられない場合があるが、データＩＤに格納するデータが対応付けられている場合、当該データの情報量のばらつきは少ない。したがって、各種類別記憶部１０１２，１０１３，１０１４にデータを格納する処理の負荷は、種類別記憶部１０１２，１０１３，１０１４ごとに、それぞれ平準化されることになる。
【００５８】
なお、図４の構成例では、１つの仮想サーバ１０に複数の種類別記憶部１０１２，１０１３，１０１４を設けているが、種類別記憶部１０１２，１０１３，１０１４ごとに異なる仮想サーバ１０に分散させたり、種類別記憶部１０１２，１０１３，１０１４の一部を異なる仮想サーバ１０に分散させてもよい。
【００５９】
ところで、データＩＤが増加し、予想したデータＩＤの最大数を上回るときには、データベースシステムの拡張が必要になる。上述の例では、データＩＤの最大数を１００万としているが、さらに大規模にデータを収集しようとすれば、データＩＤの最大数を増加させることが必要になる。このような場合、上述した構成を１単位とし、必要なだけ単位数を増加させればよい。たとえば、１単位ごとにグループ名を付与し、グループ名として０から順に与えられる数値を用いる。上述した構成例では、１００万個のデータＩＤについて、合計で２５億レコードを格納することができるから、１グループ増加させると、２００万個のデータＩＤについて、合計で５０億レコードを格納することが可能になる。つまり、データＩＤが１〜１００００００の範囲のデータはグループ「０」に格納し、データＩＤが１０００００１〜２００００００の範囲のデータはグループ「１」に格納すればよい。この例において、グループ名は、データＩＤを１００００００で除した商になる。
【００６０】
上述のように１つのグループを単位として、グループ単位でデータベースを拡張することにより、収集サーバ３３の選別機能部３３１は、グループを識別する手順を付加するだけで、他の手順を変更することなくデータを振り分けることが可能になる。なお、収集サーバ３３の前段に、グループを分けるサーバを別に設けてもよい。すなわち、グループの仕分けを行う機能を専用に設け、収集サーバ３３も含めてグループを追加することによって、データベースシステムの拡張を図ってもよい。
【００６１】
データベースシステムを拡張が必要になるか否かは、データＩＤの総数によるから、収集サーバ３３あるいはサーバ３２において、データＩＤの総数を取得する機能を設けておけばよい（通常は、キーボードなどの入力装置が操作されることにより取得する）。収集サーバ３３あるいはサーバ３２では、取得したデータＩＤの総数からデータの格納に必要なグループ数を算出し、算出したグループ数が現状のグループ数よりも多ければ、データベースの拡張を利用者端末３１に指示するようにすればよい。
【００６２】
ところで、一般的には、データベースを拡張した場合、新規に設けられた実体システムにデータが格納されるから、新規の実体システムにアクセスが集中すると考えられる。しかしながら、本実施形態では、データＩＤを用いて複数の仮想サーバ１０にデータを分散させて格納しているので、データベースを拡張した場合であっても、新規に設けられた実体システムにアクセスが集中することがない。つまり、実体システムへのアクセスが集中することがなく、仮想サーバ１０へのアクセスが平準化され、結果的に仮想サーバ１０の記憶容量やアクセスによる負荷が平準化できるのである。
【００６３】
なお、上述の例においてデータを格納する際に、仮想サーバ１０およびテーブル１０１１を決定し、該当する実体システムにデータを引き渡す技術について説明したが、データを抽出する際にも同様の手順を用いる。たとえば、特定のデータＩＤに関するデータが必要であれば、データＩＤを与えて仮想サーバ１０およびテーブル１０１１を決定し、該当する実体システムのテーブル１０１１からデータを抽出すればよい。
【００６４】
上述した構成例では、格納するデータの収集および格納されたデータの使用にあたり電気通信回線を用い、複数台の実体システムの間で電気通信回線を通して通信することにより実体システムを連携させているが、電気通信回線を用いて通信することは必須ではない。つまり、データの収集あるいは使用を実体システムに付設した入力装置や出力装置によって行うことが可能であり、また、複数の実体システムを空間的に近接させて配置するとともに連携可能となるように適宜のインターフェイス装置を介して接続してもよい。
【００６５】
なお、管理機能部１０２を構成するＡＰＩに、上述したデータベースシステムに関する種々のパラメータを受け付ける機能を持たせてもよい。この場合、管理機能部１０２にパラメータを設定することによって、管理機能部１０２が、仮想サーバ１０におけるデータ格納部１０１の記憶容量、テーブル１０１１の総数、テーブル１０１１の記憶容量などを定めるようにしてもよい。
【００６６】
また、上述の例ではデータを格納する仮想サーバ１０およびテーブル１０１１を決めるために、選別機能部３３１において、データＩＤの除算を行っているが、乱数などの他の関係を用いて分散させてもよい。
【符号の説明】
【００６７】
１０  仮想サーバ
２０  サーバ（分散データベース）
２１，２２，２３  実体システム（コンピュータシステム）
１０１  データ格納部
１０２  管理機能部
３３１  選別機能部（選別手段）
１０１１  テーブル
１０１２，１０１３，１０１４  種類別記憶部
【図１】
0005919529.tif 000002
【図２】
0005919529.tif 000003
【図３】
0005919529.tif 000004
【図４】
0005919529.tif 000005