JP5461215B2 - データベースシステム - Google Patents

Description

本発明は、統計処理のための分散型のデータベースシステムに関する。

近年、ＩＣＴ（Information and Communication Technology）技術やユビキタス技術の発達に伴い、流通するデータの種類と量が爆発的に増加している。特に、ストリームデータと呼ばれる連続的に発生し続けるデータの増加が著しい。このストリームデータは、環境情報サービスやデータマイニングなどの用途のための統計的利用を前提としている場合が多い。センサネットワークにおけるセンサストリームデータがその顕著な例である。

これらの大量に流通するストリームデータの蓄積および統計処理を低コストかつ低負荷で効率的に行うための技術が必要とされている。特に、その統計における精度をコントロールできること、および、その精度とかかる負荷がトレードオフの関係にあることが必要とされている。

「スケールアウトの技術」首藤一幸、情報処理 Ｖｏｌ．５０，Ｎｏ．１１，２００９

ところで、増加し続ける大量のデータを低コストで扱うためには、スケーラビリティ、すなわち容易な規模拡張性が必須である。このスケーラビリティを備えていることを前提として、データ蓄積のための既存技術には、以下に挙げる問題点を有している。

安価なハードディスクを複数つなげて、論理的に１台のディスクとして扱うストライピング技術が一般的によく使われている。システムの導入時にディスク容量を自由に大きくできるだけでなく、書き込み／読み込みをディスクごとに並列処理できるので、高速である。ただし、一旦稼動を始めた後は容量拡張ができないこと、一部のディスクの故障により全てのデータが失われることなどが問題である。

また、複数のサーバに分散して置かれたデータベースを論理的に単一のデータベースとして扱い、書き込み／読み込みをサーバごとに並列処理することにより高速に処理できる分散データベース技術が知られている。各サーバへのデータ（テーブル）の分配方法には、垂直分割すなわち列（属性）単位での分割と水平分割すなわち行（レコード）単位での分割がある。しかしながら垂直分割では規模拡張が困難なので、以下、水平分割の場合について説明する。一般に分散データベースでは、ハッシュ関数を用いてサーバごとのデータの分担を決定する。これにより、各サーバの担当するデータの範囲が比較的均一になるが、規模拡張のためにサーバを追加した際にはそれに伴って他のサーバの分担も変更になるため、サーバ間でデータの再配置が発生し、システムに高い負荷がかかる。

分散ハッシュテーブルにより再配置を小さく抑える工夫も提案されているが、再配置が発生することには変わりはない（例えば、非特許文献１参照）。また、ハッシュ関数によるデータの割り当てが周期性を伴っていたり、特定のデータが特定のサーバに偏ったりしている場合には、サーバ故障時に偏ったデータのみが消失することになるので、統計的な意味でデータ全体の価値を著しく損なう可能性があることも問題である。たとえ冗長構成を取ることでデータの消失の機会を減らしたとしても、普段の書き込み処理におけるデータ複製、ならびに障害時の復旧のための処理は、サーバに高い負荷をかけることになる。また、一般に分散データベースではデータ再配置等で各データサーバ同士の連携の必要があるため、サーバは他のサーバの状態を保持しなくてはならない。したがってサーバ数が増えればその分負荷が増えることになり、その影響でスケーラビリティが低くなっていることが問題である。

また、これら二つの技術に共通して、データをランダムサンプリングするためには、全ディスクまたは全サーバに対してアクセスを行い、母集団となるデータを検索した上で、そこから必要な精度に合わせた分のデータをランダムサンプリングするか、もしくは、全データに対してランダムサンプリングを行い、そこから検索条件を元にフィルタを施すといった、いずれにしても重い処理が必要になることが問題である。そしてこの処理は、たとえ要求する精度が低いものだとしても、その分かかる負荷が低くなるようなことはなく、非効率である。

ランダムサンプリングを前提とした場合、データの書き込み時に最初から書き込むデータを適当に間引くというやり方もある。これはデータベースへの書き込み時の負荷が小さくなるという意味で優れた方法であるが、サンプリングの比率をはじめから決定しておくことになるので精度の制御ができなくなる。従って、その精度に限定して利用するか、さもなければ読み込み後に再度間引くことになる。前者は精度への自由度が無いことが問題であるし、後者は本質的な解決になっておらず、サンプリング処理によってシステムに高い負荷をかけることに変わりはない。

本発明は、このような事情に鑑みてなされたもので、統計処理を行う際に好適な分散型のデータベースシステムを提供することを目的とする。

本発明は、データを記憶する記憶手段をそれぞれ備える複数のデータサーバと、前記データサーバの所在を管理する管理サーバとを備え、標本データの抽出を行う分散型のデータベースシステムであって、前記データの書き込み時に、書き込み先の前記データサーバを機会均等に任意に選択し、選択した前記データサーバを介して、書き込むべきデータを前記記憶手段に書き込み、前記データの読み込み時に、前記データサーバを任意に選択し、選択した前記データサーバを介して、前記記憶手段から読み込むべきデータを読み込むことを特徴とする。

本発明は、前記データの書き込み時の機会均等なデータサーバを選択する際に、ランダム選択を採用して、前記データサーバの選択を行うことを特徴とする。

本発明は、前記データの読み込み時に前記データサーバを選択する際に、その時点でかかっている負荷の低い前記データサーバを優先して選択することを特徴とする。

本発明は、前記データの読み込み時に前記データサーバを選択する際に、その後予想される負荷が低い前記データサーバを優先して選択することを特徴とする。

本発明は、前記データの読み込み時に前記データサーバを選択する際に、統計処理において必要としている精度から、選択するべき前記データサーバの数を決定することを特徴とする。

本発明によれば、複数のデータサーバに対してデータアクセスする際に、各データサーバ毎に分担を決めないようにしたため、機会均等にデータをアクセスすることが可能になる。また、データサーバ毎に分担が決まっていないため、特定のデータサーバに障害があっても、母集団のサイズが変わるだけで、統計的な特徴は変わらず、また、データサーバの追加があっても分担の決めなおしの必要もないので、容易に規模を拡張することができるという効果が得られる。

本発明の一実施形態の構成を示すブロック図である。 図１に示す装置の動作を示すシーケンス図である。 図１に示す装置の動作を示すシーケンス図である。 図１に示す装置の動作を示すシーケンス図である。

以下、図面を参照して、本発明の一実施形態によるデータベースシステムを説明する。図１は同実施形態の構成を示すブロック図である。この図において、符号１〜５は、分散型のデータベースを構成するデータサーバであり、データを記憶する記憶装置１０〜５０のそれぞれに対してデータの読み書きを行うコンピュータ装置によって構成する。符号６は、データサーバ１〜５の所在を管理する管理サーバであり、コンピュータ装置によって構成される。符号７は、分散型データベースに記憶されているデータを利用するクライアント端末であり、コンピュータ装置によって構成される。管理サーバ６、データサーバ１〜５及びクライアント端末は、それぞれコンピュータネットワークＮに接続され、各装置間において情報通信が可能である。

ここでは、データサーバ１〜５のアドレスをそれぞれＡ１〜Ａ５とする。管理サーバ６は、データサーバ１〜５の死活管理、すなわち、データサーバ群を監視し、正常に稼動しているデータサーバを把握しているものとする。ここでの「正常な稼動」とは、システム自体が通常通り安定して稼動していることに加えて、残りのディスク容量が十分にあることも含んでいる。なお、ここでは管理サーバ６を１台のみとしているが、複数あってもよい。その場合は、各管理サーバがそれぞれ全データサーバを監視するか、もしくは分担して監視して、必要に応じてお互いに情報を共有する。そしていずれの場合もクライアント端末７は任意の管理サーバに問い合わせることになる。

次に、図２を参照して、図１に示すデータベースシステムのデータの書き込み動作について説明する。図２は、図１に示すデータベースシステムのデータの書き込み動作を示すシーケンス図である。ここでは、クライアント端末７は表１のデータを書き込むとする。このとき、１回の管理サーバ６へのアクセスあたり、データサーバ１〜５に１レコードずつ書き込んでも複数レコードをまとめて書き込んでもよいが、ここでは複数レコードをまとめて書き込むこととする。

まず、クライアント端末７は、管理サーバ６に対して書き込みたいレコード数として「３」を伝える（ステップＳ１）。このときデータサーバ１、データサーバ２、データサーバ３及びデータサーバ５は正常に稼動しているが、データサーバ４はダウンしていたとする。すると、管理サーバ６は現在正常に稼動しているデータサーバ１、データサーバ２、データサーバ３、データサーバ５の中から、のべ３台のデータサーバを選ぶ。その選び方は、クライアント端末７ごとに、稼動している全データサーバに対して機会均等になるような選び方であればよい。すなわち、その選び方で選択したデータサーバに書き込むという処理（選択＋書き込み）を仮に長期間繰り返した場合に、各データサーバへの書き込み回数がほぼ均一になると予測される選び方という意味である。

例えば、クライアント端末７がどのデータサーバに書き込んだかの履歴を管理サーバ６が保存しているとして、そのクライアント端末７から行われた最後の書き込みの時刻が古い順にデータサーバを３台選ぶというやり方や、各データサーバに同一の確率（ここでは候補が４台あるので各々１／４）を付与して、規則性を伴わずにその確率に従って重複を許して３台選ぶ、すなわちランダムに選ぶなどのやり方がある。但し、厳密な意味でのランダムである必要はなく、疑似ランダムでも構わない。ここではランダムに選ぶものとし、データサーバ１、データサーバ５及びデータサーバ３の順で３台が選ばれたとする。管理サーバ６はその選んだデータサーバのアドレスを選んだ順に並べ、（Ａ１、Ａ５、Ａ３）というアドレス列にしてクライアント端末７に返す（ステップＳ２）。クライアント端末７はそのアドレス列に従って、頭からそのアドレスが示すデータサーバに対してアクセスし、順に書き込むべきレコード（レコード１〜３）を書き込んでいく（ステップＳ３、Ｓ４、Ｓ５）。

なお、ここではレコード単位としたが、いくつかのレコードをまとめて、例えば３レコードずつ書き込んでもよい。その場合は、クライアント端末７はレコード数ではなくレコードの３つ組の数を伝えるようにすればよい。また、１レコードずつ書き込むのであれば、管理サーバ６が伝えるのはアドレス列ではなく単一のアドレスとなり、データサーバへのアクセスも１回となる。ストリームデータの場合、クライアント端末７はこの書き込みを断続的に行うことになるので、その都度同様の処理を行う。

また、この例では書き込み先となるデータサーバの選択を管理サーバ６が行ったが、選択ルールを共有した上で、クライアント端末７が行うようにしてもよい。この場合は、管理サーバ６がクライアント端末７に伝えるのは、正常に稼動している全サーバのアドレス列となり、クライアント端末７はそこからランダムに必要数のアドレスを選択してアクセスすることになる。

次に、図３を参照して、図１に示すデータベースシステムのデータ読み込み動作について説明する。図３は、図１に示すデータベースシステムのデータ読み込み動作を示すシーケンス図である。この例では大量のデータの中からサンプリングのみを行うものとする。

まず、クライアント端末７は管理サーバ６に対して要求するサーバ数を百分率（要求精度）で伝える（ステップＳ１１）。すなわち、最大の標本サイズの何パーセントを標本として抽出したいかを伝える。標本サイズが大きくなればなるほど、統計値の精度は向上する。ここでは、クライアント端末７が３０％を指定したものとする。ここでは、クライアント端末７が３０％を指定したものとする。図１に示す例ではデータサーバは５台あるので、その３０％は１．５台となる。管理サーバ６は、これを切り上げて、２台を必要台数と算出する。管理サーバ６は、現在正常に稼動しているデータサーバの中から、２台のデータサーバを任意に選択する。ここでは現在かかっている負荷の低いデータサーバから順に選ぶこととし、その際の負荷の指標として平均レスポンス時間を用いることとする。各データサーバの現在の平均レスポンス時間は例えば、表２に示す通りであるとすると、データサーバ２、データサーバ３が順に選ばれることになる。各データサーバ１〜５が記憶装置１０〜５０に保持するデータ例を表３に示す。

次に、管理サーバ６は、データサーバ２、データサーバ３のアドレス列（Ａ２、Ａ３）をクライアント端末７に返す（ステップＳ１２）。クライアント端末７はこのアドレス列を元に、データサーバ２、データサーバ３に対してアクセスし、検索クエリを投げていく（ステップＳ１３、Ｓ１４）。ここでは時刻ｔによる範囲検索として、（２００９−０４−０１＿１０：０５：００＜ｔ＜２００９−０４−０１＿１０：１５：００）を投げるとする。検索クエリを受け付けたデータサーバ２、データサーバ３は各々検索を行い、検索結果の情報（それぞれ表４、表５）を各々クライアント端末７に返す（ステップＳ１５、Ｓ１６）。クライアント端末７はそれらの結果をマージし（表６）、サンプリング結果とする。

表６に示すサンプリング結果においては便宜上ソートしているが、単なるサンプリングであればソートは必須ではない。また、ここでは負荷の指標として平均レスポンス時間を用いたが、平均アクセス回数やＣＰＵ利用率などでもよい。またはそれらを総合した値でもよい。さらに、負荷の変化に規則性がある場合や、これから別のタスクで負荷がかかることがわかっている場合などは、その予想される負荷を指標としてもよい。

また、この例では指定された標本サイズ以上であれば問題ないという考えの下、２台の検索結果を全て返しているが、いずれか１台のデータサーバ、例えばかかっている負荷の低いデータサーバ２において、過剰な分、この例ではデータサーバ２での検索結果の半数を間引くためのサンプリング処理を走らせた上でその結果を返し、その１台以外すなわちデータサーバ３が検索結果を全て返せば、重いサンプリング処理を１台だけに限定しながら、クライアント端末７に対する送信データ量を低く抑えることができる。なお、読み込み・書き込みともに、クライアント端末７の複数同時のアクセスをそのまま並行に処理してもよい。

次に、図４を参照して、図３に示すデータ読み込み動作の変形例を説明する。図４は、図１に示すデータベースシステムのデータ読み込み動作を示すシーケンス図である。この例では、閾値に対するレコードの比率（母比率）を推定するものとする。

まず、クライアント端末７は管理サーバ６に要求するサーバ数（要求精度）に加えて、検索クエリ、および、属性とその値に対する閾値を伝える（ステップＳ２１）。閾値は、指定された属性の値が閾値以上か未満かでレコードを分けて、その比率を出すためのものである。この例では指定属性は「Ｖａｌｕｅ１」とし、その閾値は７．０とする。要求するサーバ数の全サーバにおける百分率は６０％とし、検索クエリは同じく、時刻ｔにおける範囲検索（２００９−０４−０１＿１０：０５：００＜ｔ＜２００９−０４−０１＿１０：１５：００）とする。５台のデータサーバに対して６０％の要求なので、必要台数は３台となる。管理サーバ６は、現在正常に稼動しているデータサーバの中から、３台のデータサーバを任意に選択する。ここでは現在の負荷が低いデータサーバから順に選ぶこととし、その際の負荷の指標として平均レスポンス時間を用いることとする。

各データサーバの現在の平均レスポンス時間は表２の通りであるとすると、データサーバ２、データサーバ３及びデータサーバ５が順に選ばれることになる。管理サーバ６は、ここで最もかかっている負荷の低いデータサーバ２を集約サーバとし、集約ＩＤを適当に決める。この集約ＩＤは並列処理の際に他のプロセスとの混乱を防ぐためのものであるので、同時に処理を行う可能性のある集約処理の間でユニークである必要がある。例えば、管理サーバ６のアドレスと、要求を受け付けた時刻の組み合わせなどを使用すればよい。また、この集約ＩＤはクライアント端末７とのセッションとも紐付けられる。

次に、管理サーバ６は、データサーバ２に対して、集約ＩＤと、他データサーバのアドレス列（Ａ３、Ａ５）と、検索クエリ、閾値を伝える（ステップＳ２１）。また、管理サーバ６は、データサーバ３とデータサーバ５のそれぞれに対して、集約ＩＤと、集約データサーバのアドレス（Ａ２）と、検索クエリ、閾値を伝える（ステップＳ２２、Ｓ２３）。

データサーバ２は、自身の検索をかけながら、Ａ３とＡ５のアドレスで示されるデータサーバからこの集約ＩＤを持つ検索結果が返ってくるのを待つ。データサーバ３とデータサーバ５は、検索結果（それぞれ表５、表７）に集約ＩＤを付与して、データサーバ２に各々返す（ステップＳ２３、Ｓ２４）。データサーバ２はこれを受け取り、自分の検索結果（表４）とマージした上でそれらの標本比率を求め、集約ＩＤとともに管理サーバ６へ返す（ステップＳ２５）。管理サーバ６はこれを受け取り、集約ＩＤと紐付いているセッションを通じてクライアント端末７に推定される母比率として返す（ステップＳ２６）。

この例では検索を行うデータサーバのうち、１台のデータサーバを集約サーバとしたが、それら以外のデータサーバや管理サーバ６、集約専用の別サーバなどでも同様に処理するようにしてもよい。また、各データサーバで標本比率を求め、それらを集約するようにしてもよい。さらに、比率ではなく平均値などの計算であっても同様である。

次に、データ読み込み処理におけるデータサーバ台数の決定処理について説明する。ここでは、母集団のサイズ、すなわち、ランダムサンプリング前のレコード数Ｎが予め分かっている、または、予測できているとし、Ｎ＝１００００とする。例えば、全データに対するランダムサンプリングの場合で全レコード数を把握している場合や、クライアント端末７の書き込み頻度やタイミングを把握している場合である。

今、要求する精度を許容する誤差の幅をｅで表し、ｅ＝０．０ならば誤差を許さず、上下３％の誤差を許容するのならば、ｅ＝０．０６となる。クライアント端末７は要求する精度としてこのｅを検索クエリと一緒に管理サーバ６に伝える。また、信頼度はデータベースシステム側が決めてもクライアント端末７が指定しても構わないが、この例ではシステム側が信頼度９５％と決めて処理をするものとする。信頼度に対する正規分布の値をｕとする。９５％であればｕ＝１．９６、９９％であればｕ＝２．５８である。ここではｕ＝１．９６となる。このとき、必要な標本サイズｎは、
ｎ＝（２ｕ／ｅ）＾２・ｐ（１−ｐ）
となる。ｐは予測される母比率なので、予測できている場合はその値となる。ここでは予測できていないとして、ｎを最大とする０．５と設定すると、
ｎ＝（２ｘ１．９６／０．０６）＾２ｘ０．５ｘ０．５＝１０６７
となる。各データサーバの保持するレコード数はほぼ均一とみなせるので、１台あたり約１００００／５＝２０００レコードとなる。従って、１台のサーバで良いこととなる。

なお、求めるのが比率ではなく平均値の場合は、例えば母分散σ＾２がある程度推測できているとして、許容する誤差の幅ｅに対して、
ｎ＝４ｕ＾２・σ＾２／ｅ＾２
のようにして求める。（参考文献：「サンプルサイズの決め方」（永田靖）、Ｓ１２、朝倉書店）。

次に、母集団（全標本）のサイズを推定する方法について説明する。クライアント端末７はデータを書き込む前に管理サーバ６にアクセスをするが、その際に、管理サーバ６は一定の確率、例えば１／１０００の確率でランダムに間引きながら、クライアント端末７が書き込もうとしているレコードを自身に保持するようにする。クライアント端末７は読み込みの際に検索クエリを管理サーバ６に伝えるが、データサーバの台数を決定する前処理として、自身にその検索クエリを用いて検索をかける。ここでは、検索結果のレコード自体は必要なく、その個数さえわかればよいので、通常の検索よりかかる負荷は低い。この得られた個数を１０００倍することで、母集団（全標本）のサイズを推定することができる。同様に、自身を検索し、その検索結果を標本分散と見做し、さらに母分散の代わりとすることも可能である。

ここでは、管理サーバ６に独自にサンプリングされたデータレコードを保持したが、通常通りにデータを蓄積しているデータサーバを任意に１台選び、そこにまず検索クエリを投げ、その結果を見て台数を決定し、不足している台数（すなわち、必要台数−１）に検索クエリを改めて投げるという方法でも可能である。

また、これらの方法を使えば、クライアント端末７が必要標本サイズを直接的に指定することも可能である。すなわち、前述した説明において、クライアント端末７は、サーバの台数ではなく、必要とする標本サイズを管理サーバ６に伝え、管理サーバ６は上記の方法でデータサーバ１台あたりの検索結果のレコード数を見積った上で、クライアント端末７が要求する標本サイズを上回るためには何台のデータサーバが必要かを算出すればよい。

このように、前述したデータベースシステムによれば、ランダムサンプリングが蓄積時にネイティブで行われるため、データを統計的に利用する際にあらためてサンプリング処理でシスムテに負荷をかける必要がなくなる。また、ランダムサンプリング時に、データサーバの台数分の自由度で標本サイズを制御することができ、それを精度で制御することができる。さらに、データサーバは分散しているためデータベースシステム全体で見ると統計処理に必要とされる精度に応じた並列処理をすることになり、データサーバ台数によらず高速に処理することができる。

また、データサーバの故障が発生しても、各データサーバに蓄積されているデータの統計的な性質は均一なので、全体の最大精度が落ちることと、選べる精度の自由度が落ちるだけで、統計的な意味での偏りは発生しないので、データ全体での価値を著しく損なうことはない。また、新たにデータサーバの追加を行っても、時間が経てば自然に新しいデータサーバへ他のデータサーバと同様にデータが蓄積されていくので、データの再配置の必要がなく、余計な負荷がかからない。

また、データサーバの障害時に消失するのは当然ながら過去のデータであり、その後新しいデータが蓄積されていくに従って、全体の中での新しいデータの割合が増える。このようなデータサーバの障害すなわちデータの消失はデータベースシステム全体で常に発生し得る確率的なものなので、データ全体に均等に同様の影響を及ぼす。従って、データ読み込み時には新しいデータほど自然に優先されることになり、新しい情報を重要視することの多いストリームデータの統計処理においては好ましい特徴となる。また、各データサーバは他のサーバの状態を保持する必要がないので、一般の分散型データベースに比べてスケーラビリティが非常に高い。

また、データサーバの死活管理が不完全だった場合でも、一般にその死活判断の間違いはデータサーバ毎に確率的に均等に起こるものなので、その間違いに起因したデータの書き込みならびに読み込み処理の失敗の機会に偏りは生じない。従って、特定のデータのみがまとまって消失するようなことは起きず、影響はデータ全体での最大精度が若干落ちるのみで済む。

また、データ書き込み時にデータサーバをランダムに選択する、すなわち、周期性のない選択をすることになるので、データが周期信号だった場合でも、データサーバ故障による一部データの消失時に、元データの周波数成分が失われにくい。さらに、データ読み込み時に、かかっている負荷の低いデータサーバが優先して選ばれるので、負荷分散が適切に行われ、システム全体としての稼動が安定するとともに、キャパシティの向上、運用コストの低減が可能になる。

環境情報サービスやデータマイニングなどにおいては、データを統計的に利用することを前提としている場合が多く、センサネットワークにおけるセンサストリームデータがその顕著な例である。それらの大量のデータを低コストで取り扱うためのデータ蓄積技術として、従来から分散型データベースがある。従来の分散型データベースは、複数のサーバに分散しておかれたデータベースを論理的に一つのデータベースとして取り扱うものであるが、サーバ毎に分担を決めておくものであったため、規模を拡張する場合には、サーバの分担を決めなおす必要があり、また、サーバ間で常に連携をとる必要があるなどの問題がある。

本発明による分散型のデータベースシステムは、統計的に利用されるデータを蓄積する際に、複数のデータサーバに対してデータアクセスする際に、各データサーバ毎に分担を決めないようにしたため、機会均等にデータをアクセスすることが可能になる。データサーバ毎に分担が決まっていないため、特定のデータサーバに障害があっても、母集団のサイズが変わるだけで、統計的な特徴は変わらず、また、データサーバの追加があっても分担の決めなおしの必要もないので、容易に規模を拡張することができる。

なお、図１における処理部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによりデータベースのアクセス管理処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、ホームページ提供環境（あるいは表示環境）を備えたＷＷＷシステムも含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアント端末７となるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

統計処理のための分散型のデータベースシステムを構築することが不可欠な用途に適用できる。

１〜５・・・データサーバ、１０〜５０・・・記憶装置、６・・・管理サーバ、７・・・クライアント端末

Claims (5)

1. データを記憶する記憶手段をそれぞれ備える複数のデータサーバと、前記データサーバの所在を管理する管理サーバとを備え、標本データの抽出を行う分散型のデータベースシステムであって、
   前記データの書き込み時に、書き込み先の前記データサーバを機会均等に任意に選択し、選択した前記データサーバが備える前記記憶手段に書き込むべきデータを書き込み、
   前記データの読み込み時に、必要な数の前記データサーバを任意に選択し、選択した前記データサーバが備える前記記憶手段から読み込むべきデータを読み込み、それらのデータをマージしてサンプリング結果とする
   ことを特徴とするデータベースシステム。
2. データを記憶する記憶手段をそれぞれ備える複数のデータサーバと、前記データサーバの所在を管理する管理サーバとを備え、標本データの抽出を行う分散型のデータベースシステムであって、
   前記データの書き込み時に、書き込み先の前記データサーバを機会均等に任意に選択し、選択した前記データサーバが備える前記記憶手段に書き込むべきデータを書き込み、
   前記データの読み込み時に、前記データサーバを任意に選択し、選択した前記データサーバが備える前記記憶手段から読み込むべきデータを読み込み、
   前記データの読み込み時に前記データサーバを選択する際に、その時点でかかっている負荷の低い前記データサーバを優先して選択する
   ことを特徴とするデータベースシステム。
3. データを記憶する記憶手段をそれぞれ備える複数のデータサーバと、前記データサーバの所在を管理する管理サーバとを備え、標本データの抽出を行う分散型のデータベースシステムであって、
   前記データの書き込み時に、書き込み先の前記データサーバを機会均等に任意に選択し、選択した前記データサーバが備える前記記憶手段に書き込むべきデータを書き込み、
   前記データの読み込み時に、前記データサーバを任意に選択し、選択した前記データサーバが備える前記記憶手段から読み込むべきデータを読み込み、
   前記データの読み込み時に前記データサーバを選択する際に、その後予想される負荷が低い前記データサーバを優先して選択する
   ことを特徴とするデータベースシステム。
4. データを記憶する記憶手段をそれぞれ備える複数のデータサーバと、前記データサーバの所在を管理する管理サーバとを備え、標本データの抽出を行う分散型のデータベースシステムであって、
   前記データの書き込み時に、書き込み先の前記データサーバを機会均等に任意に選択し、選択した前記データサーバが備える前記記憶手段に書き込むべきデータを書き込み、
   前記データの読み込み時に、前記データサーバを任意に選択し、選択した前記データサーバが備える前記記憶手段から読み込むべきデータを読み込み、
   前記データの読み込み時に前記データサーバを選択する際に、統計処理において必要としている精度から、選択するべき前記データサーバの数を決定する
   ことを特徴とするデータベースシステム。
5. 前記データの書き込み時の機会均等なデータサーバを選択する際に、ランダム選択を採用して、前記データサーバの選択を行うことを特徴とする請求項１から４のいずれか１項に記載のデータベースシステム。

Images