JP3598522B2 - 分散型データベース管理装置 - Google Patents
分散型データベース管理装置 Download PDFInfo
- Publication number
- JP3598522B2 JP3598522B2 JP04307593A JP4307593A JP3598522B2 JP 3598522 B2 JP3598522 B2 JP 3598522B2 JP 04307593 A JP04307593 A JP 04307593A JP 4307593 A JP4307593 A JP 4307593A JP 3598522 B2 JP3598522 B2 JP 3598522B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- information
- servers
- distributed database
- distributed
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【産業上の利用分野】
本発明は、分散型データベースの管理方法，及び、上記分散型データベースの管理方法を備えたシステムに関する。
【０００２】
従来から各種の情報を複数個のサーバに用途別に，或いは、同一の情報を複数のサーバに分散して、複数個の利用者（クライアント）が利用する分散型データベースシステムが知られている。
【０００３】
かかる分散型データベースシステムは、ダウンサイジング，処理の高速化等を目的としたシステムが多く、これまで、１台の大型コンピユータで実行していた処理を複数の小型コンピユータ、例えば、ワークステーションに分散し、１台当たりの負荷を低減し、並行に処理を実行する方法を採用している。
【０００４】
用途別にサーバに分散させる方法では、 １） 用途別に分散されたサーバを意識した制御が必要となり、システムが複雑になってしまう。 ２） サーバのネットワーク上でのアドレスの変更等が発生した場合に、利用者に、変更後のアドレスを知らせる必要があり、管理が繁雑となる等の問題がある。
【０００５】
又、同一情報を複数のサーバに管理させる方法では、 １） 同一用途の情報を、複数のサーバで重複管理した場合、１台当たりの管理データは分散されず、トータルの情報量は増加することになり、処理速度が低下してしまう。 ２） 同一用途の情報を複数のサーバに分散して管理した場合、分散された情報の一致性の問題があり、管理が繁雑となる。 ３） 分散型データベースシステムでは、１台当たりの負荷を低減させることが重要であるが、場合によっては、１台のサーバに処理が集中してしまうことがあり、かえって、低速なシステムになってしまう等の問題がある。
【０００６】
又、ネットワークシステムに精通した技術者がいないと、システムが構築できないとか、システムが大規模になればなる程、基幹ネットワークから分岐している各部門の専用サーバは、どの位の性能、例えば、どの位の利用者数が処理可能なのかを考慮した設計が必要となり、実現性が困難となる。
【０００７】
従って、分散型データベースシステムにおいて、利用者が利用し易くて、効率の良いサービスが実現できる分散型データベースの管理方法が要求される。
【０００８】
【従来の技術】
図８〜図１０は、従来の分散型データベース管理方法を説明する図であり、図８は、クライアントが、分散された情報を利用する場合の従来のアクセス方法を示し、図９は、同じ情報が複数個のサーバに重複して分散されている場合の従来のアクセス方法を示し、図１０は、情報が複数のサーバのどれに登録されているかを管理する格納先管理用サーバを設けている場合の従来のアクセス方法を示している。
【０００９】
先ず、図８において、従来から、本図に示されているように、サービス情報を複数個のサーバ １に分散されている場合、利用者は、どのサーバ １に、どのようなサービス情報があるかを認識して、サービス要求を出す。
【００１０】
即ち、データベース利用者は， 利用しようとするサービスを提供するサーバ １を意識して、サービス情報を要求する。
又、図９に示されているように、同じ情報が複数個のサーバに重複して分散されている場合、サーバ負荷が一様に分散されていることが望ましい。そこで、従来は、ネットワーク ３とサーバ １の専用化により負荷分散を行っていた。
【００１１】
即ち、本図に示されているように、特定の利用者 （クライアント）（１）〜利用者 （クライアント）（３） ２と、部門１専用サーバ １〜部門３専用サーバ １とを専用化することで、負荷の分散を図っていた。部門１専用サブネットワーク ３ａ に接続されている利用者（１） 〜 ２ａ は、部門１専用サーバ １ａ のみアクセスすることができる。
【００１２】
又、図１０は、情報が複数のサーバのどれに登録されているかを管理する格納先管理用サーバ １ａ を設けている場合を示している。
同一用途の情報を、複数のサーバ １に分散して管理する場合、複数のサーバ １を意識することなく情報の登録， 検索ができることが望ましい。
【００１３】
その一般的な方法としては、情報が複数のサーバ １のどれに登録されたかを管理する格納先管理用サーバ １ａ を設けておく。即ち、上記格納先管理用サーバ １ａ に、各情報を検索するのに必要な検索キーｉ（＝１，２，〜ｎ）と、情報の格納先のサーバのＩＤとの対応テーブル▲４▼ａを持たせる構成とすることにより、利用者は、必要とする情報を検索する為の検索キーｉのみで、サーバを意識することなく必要な情報が検索できる。
【００１４】
【発明が解決しようとする課題】
従って、上記従来の分散型データベースシステムにおいては、図８のように、例えば、従業員情報を参照する場合、従業員情報が分散されているサーバ（１） 〜サーバ（３） １ の、それぞれにどのような従業員情報があるかを、予め、認識して、サービス要求を出す必要があった。即ち、データベースの利用者は、利用しようとするサービスを提供するサーバ装置を意識しなければならず、前述のように、システムが複雑になってしまうという問題があった。
【００１５】
又、図９に示したように、ネットワーク ３とサーバ １の専用化により負荷分散を行っている場合、例えば、部門１専用サブネットワーク １ａ に接続されている利用者は、同じ情報が分散されている他の部門２，３の負荷が低くても利用することができないという問題があった。又、他の部門２，３の記憶媒体の空き容量が多くても、他の部門の記憶媒体を利用することができないという問題があった。
【００１６】
又、この場合、前述のように、サーバ１台当たりの管理データ量が分散されない為、処理速度が低下してしまうという問題と、同一用途の情報を分散管理した場合、分散されている同一情報の一致性をとる問題があった。
【００１７】
又、図１０に示されているように、情報が複数のサーバのどれに登録されたかを管理する格納先管理用サーバ １ａ を設けられている場合、複数のサーバ １を意識する必要はなくなるが、図１０に示されている従来の方法では、クライアント ２は、先ず、格納先管理用サーバ １ａ の検索キー・サーバＩＤテーブル▲４▼ａを検索して、検索キーｉに対応した格納先サーバＩＤを取得し、次に、格納先サーバ １に対して所望の情報を要求する必要があり、煩雑な操作 （２回操作）が必要となる問題があった。
【００１８】
本発明は上記従来の欠点に鑑み、分散型データベースの管理方法において、利用者の容易な利用と、効率の良いサービスを実現することができる管理方法を提供することを目的とするものである。
【００１９】
【課題を解決するための手段】
図１〜図３は、本発明の原理説明図であり、図１は、分散型データベースシステムの概念図であり、図２は、本発明のサーバを用途別に分類して管理するサーバ情報管理テーブル▲１▼の構成例を示し、図３はサービス毎の検索キーとサーバＩＤとの対応を示す検索キー・サーバＩＤテーブル▲４▼の登録方法を示している。上記の問題点は下記の如くに構成した分散型データベースの管理方法によって解決される。
【００２０】
（１） 分散型データベースの管理方法であって、
複数個のサーバ １を用途別にグループ化して分類したサーバ情報管理テーブル▲１▼｛図２参照｝を設けて、
上記サーバ情報管理テーブル▲１▼を、定期的に、或いは、クライアント ２からサービス要求があったときに登録， 更新， 削除， 参照し、
クライアント ２からのサービス要求を基に、上記サーバ情報管理テーブル▲１▼を参照したときの情報に基づいて、サーバ １を選択するように構成する。
【００２１】
（２） 分散型データベースの管理方法であって、
複数のサーバ １毎の負荷テーブル▲２▼を、クライアント ２， ルータ ４， サーバ １のいずれかに設けて、上記負荷テーブル▲２▼を、定期的に、或いは、クライアント ２からのサービス要求があったときに更新し、
クライアント ２からのサービス要求があって、上記サーバ情報管理テーブル▲１▼を参照したときの情報に基づいて、サーバ １を選択する際、上記サーバ １毎の負荷テーブル▲２▼を参照して、負荷の低いサーバ １を選択するように構成する。
【００２２】
（３） 分散型データベースの管理方法であって、
複数のサーバ １毎の使用状況テーブル▲３▼を、クライアント ２， ルータ ４， サーバ １のいずれかに設けて、上記使用状況テーブル▲３▼を、定期的に、或いは、クライアント ２からのサービス要求があったときに更新し、
クライアント ２からのサービス要求があって、上記サーバ情報管理テーブル▲１▼を参照したときの情報に基づいて、サーバ １を選択する際、上記サーバ １毎の使用状況テーブル▲３▼を参照して、空き容量の多いサーバ １を選択するように構成する。
【００２３】
（４） 分散型データベースの管理方法であって、
サービスを提供する複数のサーバ １を、サービス毎に検索キーと， サーバＩＤとからなる検索キー・サーバＩＤテーブル▲４▼を設けて、
上記検索キー・サーバＩＤテーブル▲４▼を、所定の格納先管理サーバ １ａ で管理するように構成する。
【００２４】
（５） 分散型データベースの管理方法であって、
利用者からの情報提供があったとき、上記サービス毎のサーバ情報管理テーブル▲１▼， 上記サーバ １毎の負荷テーブル▲２▼， 上記サーバ毎の使用状況テーブル▲３▼を参照して、負荷の少ない、資源の空きの多いサーバ １を選択して、上記提供された情報を格納し、
そのときの、検索キーと、サーバＩＤとを、上記格納先管理サーバ １ａ に、上記検索キー・サーバＩＤテーブル▲４▼として登録するように構成する。
【００２５】
【作用】
本発明の分散型データベースの管理方法においては、図１に示した分散型データベースシステムにおいて、用途別に分類された情報を管理するのに、図２に示したサーバ情報管理テーブル▲１▼を、クライアント，トランシーバ，ルータのいずれかに設けて、定期的に，或いは、利用者（クライアント）からのサービス要求があった時に、登録，更新，削除，参照できるようにすることで、複数のサーバを意識することなく、単に，サービスを意識して要求を出すだけで、必要とする情報を利用可能なようにしたものである。
【００２６】
ここで、クライアントから通知された用途別の情報をサーバのネットワーク上るアドレスに変換（元々、選択されたサーバＩＤから、ネットワーク上のアドレスに変換する機構はあったので、本発明では、用途を指定することで得られるサーバＩＤに基づいて、該当のサーバのネットワーク上のアドレスを得るようにした）することにより、利用者は、サーバを意識することなく、容易に各サーバの持っている情報を利用することができる。
【００２７】
又、同一情報を複数のサーバで重複して管理する場合、図２のサーバ情報管理テーブル▲１▼に示されているように、用途別（サービス別）にグループ化して管理することで、複数の各サーバを意識することなく利用可能なようにする。
【００２８】
このとき、各サーバの負荷テーブル▲２▼，使用状況テーブル▲３▼を、クライアント，トランシーバ，ルータのいずれかに設けて、定期的に，或いは、利用者（クライアント）からのサービス要求があった時に、更新するようにして、例えば、一番負荷の低いサーバとか、記憶媒体に空きの多いサーバを選択するようにすることで、利用者が意識することなく、１台のサーバに負荷が集中することを回避することができる。
【００２９】
又、同一用途の情報を分散管理する場合、利用者からの情報提供があったとき、上記サービス （用途） 毎のサーバ情報管理テーブル▲１▼， サーバ毎の負荷テーブル▲２▼， 上記サーバ毎の使用状況テーブル▲３▼を参照して、負荷の少ない、資源の空きの多いサーバ １を選択して、上記提供された情報を格納し、そのときの、提供された情報に対応した検索キーと、サーバＩＤとを、上記格納先管理サーバに、用途別に、上記検索キー・サーバＩＤテーブル▲４▼として登録するように構成することで、利用者は、サービス（用途）を指示するだけで、指示したサービスが格納されているサーバをアクセスすることができ、利用者がサーバを意識することなく、情報の分散管理を行うことができる。
【００３０】
【実施例】
以下本発明の実施例を図面によって詳述する。前述の図１〜図３は、本発明の原理説明図であり、図４〜図７は、本発明の一実施例を示した図であって、図４は、クライアントが、分散された情報を利用する場合のアクセス方法を示し、図５，図６は、同じ情報が複数個のサーバに重複して分散されている場合のアクセス方法を示し、図５は、負荷テーブル▲２▼を使用する場合を示しており，図６は使用状況テーブル▲３▼を使用する場合を示しており、図７は、情報が複数のサーバのどれに登録されているかを管理する格納先管理用サーバ １ａ を設けている場合のアクセス方法を示している。
【００３１】
本発明においては、複数個のサーバ １を、用途 （サービス） 別に分類 （グループ化） したサーバ情報管理テーブル▲１▼に基づいてサーバを選択する。このとき、各サーバ １毎の負荷テーブル▲２▼を、クライアント ２， ルータ ４， サーバ １のいずれかに設けて、最も負荷の低いサーバ １を選択したり、複数のサーバの記憶媒体 （ディスク， テープ等） の使用状況テーブル▲３▼を、クライアント ２， ルータ ４， サーバ １のいずれかに設けて、最も空き容量の多いサーバ １を選択したり、用途別の情報検索キーと、情報格納先のサーバＩＤを、格納先管理用のサーバ １ａ に検索キー・サーバＩＤテーブル▲４▼として登録しておき、利用者からのサービス要求に基づいて、上記検索キー・サーバＩＤテーブル▲４▼により、サーバを意識することなく、必要なサービスを利用できるようにする手段が、本発明を実施するのに必要な手段である。尚、全図を通して同じ符号は同じ対象物を示している。
【００３２】
以下、図１〜図３を参照しながら、図４〜図７によって、本発明の分散型データベースの管理方法を説明する。
図１は、一般的な分散型データベースシステムの構成例を示しており、各クライアント（１） 〜 ２からのサービス要求に基づいて、各サーバ（１） 〜 １がクライアント（１） 〜 ２の要求する情報を提供する。
【００３３】
本発明の分散型データベースシステムでは、サーバ（１） 〜 １を用途別に分類したサーバ情報管理テーブル▲１▼ （図２参照）を、例えば、各クライアント（１） 〜 ２， トランシーバ ５， ルータ ４のいずれかに持ち、例えば、定期的に、或いは、クライアント（１） 〜 ２からサービス要求のあったときに、登録， 更新， 削除， 参照ができるようにし、クライアント（１） 〜 ２から、サービス要求があると、上記サーバ情報管理テーブル▲１▼を参照して、サーバＩＤを認識し、認識したサーバＩＤに基づいて、該当のサーバ（１） 〜 １のネットワーク ３上のアドレスを認識してアクセスすることで、利用者 （クライアント） は、従来のように、サーバ（１） 〜 １を意識することなく、容易に、所望のサーバ（１） 〜 １が持っている情報を利用することができる。
【００３４】
このとき、本発明においては、各サーバ（１） 〜 １毎の負荷テーブル▲２▼とか、或いは、使用状況テーブル▲３▼を、例えば、上記各クライアント（１） 〜 ２， トランシーバ ５， ルータ ４のいずれかに備えておくことで、同一情報を複数のサーバ（１） 〜 １で重複管理されているとき、最も負荷の低いサーバ（１） 〜 １とか、情報の記憶媒体の空きの多いサーバ（１） 〜 １を選択し、利用者が意識することなく、負荷を分散を図ることができるようにしている。
【００３５】
又、同一用途の情報を、複数個のサーバ（１） 〜 １で分散管理する場合、前述の図１０に示されているように、情報が格納されているサーバ（１） 〜 １の識別子（ＩＤ）と、情報の検索キーの部分を、格納先管理用サーバ １ａ に登録するのが一般的である。
【００３６】
然し、この従来方法では、クライアント（１） 〜 ２から、所定の検索キーに対応するサーバ（１） 〜 １をアクセスするのに、クライアント（１） 〜 ２ は、先ず、格納先管理用サーバ １ａ を検索して、検索キーに対応した格納先サーバＩＤを取得し、次に、格納先サーバ（１） 〜 １ に対して所望の情報を要求する必要があり、煩雑な操作 （２回操作）が必要となる問題があったが、本発明においては、図７に示されているように、上記検索キー・サーバＩＤテーブル▲４▼を、用途（サービス）別に構成して、格納先管理用サーバ １ａ で管理する方法を採ることにより、クライアント（１） 〜 ２からの只１回のサービス要求に基づいて、該サービスに対応する検索キー・サーバＩＤテーブル▲４▼が検索され、所望のサーバＩＤを認識して、該当のサーバ（１） 〜 １をアクセスできるようになる。
【００３７】
又、上記の如く、同一用途の情報を分散管理する場合、利用者からの情報提供があると、図３に示されているように、上記サービス （用途） 毎のサーバ情報管理テーブル▲１▼， サーバ毎の負荷テーブル▲２▼， 上記サーバ毎の使用状況テーブル▲３▼を参照して、負荷の少ない、資源の空きの多いサーバ １を選択して、上記提供された情報を格納し、そのときの、提供された情報に対応した検索キーと、サーバＩＤとを、上記格納先管理サーバ １ａ に、用途（サービス）別に、上記検索キー・サーバＩＤテーブル▲４▼として登録するように構成することで、利用者がサーバを意識することなく、情報の分散管理を行うことができる。
【００３８】
以下、図４〜図７に基づいて、更に、具体的に説明する。
図４は、複数個のサーバ（１） 〜 １を用途別に分類したサーバ情報管理テーブル▲１▼（図２参照）に基づいて、サーバ（１） 〜 １が検索される例を示している。
【００３９】
今、クライアント（１） 〜 ２の利用者が、従業員情報のサービスを要求すると、本発明においては、例えば、各クライアント（１） 〜 ２に設けられている、図２に示されている本発明のサーバ情報管理テーブル▲１▼が参照され、対応するサーバ（１） がアクセスされる。従って、データベースの利用者は、利用しようとするサービスのみを意識することで事足り、従来のように、必要とする情報が格納されているサーバを意識する必要がなくなり、容易にサービスを受けることができるようになる。
【００４０】
更に、本発明においては、図５に示したように、各サーバ（１） 〜 ２に掛かっている負荷を負荷テーブル▲２▼として、クライアント （利用者）（１）〜 ２， ルータ ４， サーバ（１） 〜 １のいずれか， 又は、複数に設けることで、上記サーバ情報管理テーブル▲１▼で選択されたサーバ（１） 〜 １の中で、例えば、負荷の一番低いサーバ（１） 〜 １に対してサービスを要求することができる。
【００４１】
各サーバ（１） 〜 １の負荷の計算方法としては、例えば、同一の処理に掛かっている時間を計算し、掛かっている時間の長いサーバ（１） 〜 １の負荷が重いとするとか、処理パケット （通常、処理はパケットを単位として行われるので、その要求パケット， 終了パケット） の数を計数することで、処理パケットの多いサーバ（１） 〜 １の負荷が重いとする方法があるが、特に、限定するものではない。
【００４２】
又、図６に示したように、各サーバ（１） 〜 １の持っている記憶媒体の使用状況テーブル▲３▼を、クライアント （利用者）（１）〜 ２， ルータ ４， サーバ（１） 〜 １のいずれか， 又は、複数に設けることで、上記サーバ情報管理テーブル▲１▼で選択されたサーバ（１） 〜 １の中で、例えば、空き容量の多いサーバ（１） 〜 １に対して、情報を登録したり、サービスを要求することができる。
【００４３】
上記各サーバ（１） 〜 １の負荷， 空き容量を判定するタイミングとしては、例えば、定期的に， 或いは、クライアント（１） 〜 １から要求のあった時に行うようにしてもよい。又、上記負荷テーブル▲２▼， 使用状況テーブル▲３▼の更新タイミングも、上記定期的に， 或いは、クライアント（１） 〜 １から要求のあった時に行うようにしても良い。
【００４４】
次に、図７によって、検索キー・サーバＩＤテーブル▲４▼によるデータベースの管理方法を説明する。
前述のように、同一用途の情報を複数のサーバ（１） 〜 １に分散して管理する場合、複数のサーバ（１） 〜 １を意識することなく、登録， 検索ができることが望ましい。
【００４５】
そこで、本発明においては、クライアント（１） 〜 ２から、情報の提供があったとき、前述の図３で説明したように、上記サーバ情報管理テーブル▲１▼， 負荷テーブル▲２▼， 使用状況テーブル▲３▼によって選択されたサーバ（１） 〜 １に登録すると共に、格納先管理用サーバ １ａ では、検索キー・サーバＩＤテーブル▲４▼をサービス （用途） 毎に構成して管理するようにする。
【００４６】
このように構成することにより、利用者は、サービスのみを指定するだけで、要求する情報が格納されているサーバ（１） 〜 １を選択することができる。
又、サービス毎に管理する方法を用いたことにより、図１０で説明した従来の格納先管理用サーバ １ａ では管理することができなかった複数のサービスを管理することができるようになる。
【００４７】
上記の実施例においては、分散型データベースシステムを例にして説明したが、上記のサーバ情報管理テーブル▲１▼， 負荷テーブル▲２▼， 使用状況テーブル▲３▼， 更に、検索キー・サーバＩＤテーブル▲４▼と同等の各テーブルを備えたクライアントシステム， ルーティングシステムであっても良いし、上記各テーブル▲１▼〜▲４▼を利用したネットワークシステムとか、上記各テーブル▲１▼〜▲４▼を用いたサーバの処理を入出力デバイスの制御に用いた入出力制御方法であっても良い。
【００４８】
このように、本発明は、分散型データベースの管理方法において、複数個のサーバを、用途 （サービス） 別に分類 （グループ化） したサーバ情報管理テーブル▲１▼に基づいてサーバを選択する。このとき、各サーバ毎の負荷テーブル▲２▼を設けて、最も負荷の低いサーバを選択したり、複数のサーバの記憶媒体 （ディスク， テープ等） の使用状況テーブル▲３▼を設けて、最も空き容量の多いサーバを選択したり、情報検索キーと、情報格納先のサーバＩＤを用途別に構成して、格納先管理用のサーバに検索キー・サーバＩＤテーブル▲４▼として登録しておき、利用者からの只１回のサービス要求に基づいて、サーバを意識することなく、必要なサービスを利用できるようにしたところに特徴がある。
【００４９】
【発明の効果】
以上、詳細に説明したように、本発明の分散型データベース管理方法によれば、利用者は、サーバを意識する必要がなく、単に、サービスだけを意識するだけで事足り、容易にサーバを利用することができる。又、負荷の低いサーバとか、空き容量の多いサーバを選択することにより、１台のサーバに負荷が集中することがなくなり、利用者が意識することなく負荷が分散し、効率のよいサービスが実現できる効果がある。
【図面の簡単な説明】
【図１】本発明の原理説明図（その１）
【図２】本発明の原理説明図（その２）
【図３】本発明の原理説明図（その３）
【図４】本発明の一実施例を示した図（その１）
【図５】本発明の一実施例を示した図（その２）
【図６】本発明の一実施例を示した図（その３）
【図７】本発明の一実施例を示した図（その４）
【図８】従来の分散型データベースの管理方法を説明する図（その１）
【図９】従来の分散型データベースの管理方法を説明する図（その２）
【図１０】従来の分散型データベースの管理方法を説明する図（その３）
【符号の説明】
１ サーバ， サーバ（１），（２），〜
１ａ 格納先管理用サーバ
２ クライアント， クライアント（１），（２），〜， 利用者（１），（２），〜
３ ネットワーク ３ａ サブネットワーク
▲１▼ サーバ情報管理テーブル
▲２▼ 負荷テーブル
▲３▼ 使用状況テーブル
▲４▼ 用途別の検索キー・サーバＩＤテーブル
【産業上の利用分野】
本発明は、分散型データベースの管理方法，及び、上記分散型データベースの管理方法を備えたシステムに関する。
【０００２】
従来から各種の情報を複数個のサーバに用途別に，或いは、同一の情報を複数のサーバに分散して、複数個の利用者（クライアント）が利用する分散型データベースシステムが知られている。
【０００３】
かかる分散型データベースシステムは、ダウンサイジング，処理の高速化等を目的としたシステムが多く、これまで、１台の大型コンピユータで実行していた処理を複数の小型コンピユータ、例えば、ワークステーションに分散し、１台当たりの負荷を低減し、並行に処理を実行する方法を採用している。
【０００４】
用途別にサーバに分散させる方法では、 １） 用途別に分散されたサーバを意識した制御が必要となり、システムが複雑になってしまう。 ２） サーバのネットワーク上でのアドレスの変更等が発生した場合に、利用者に、変更後のアドレスを知らせる必要があり、管理が繁雑となる等の問題がある。
【０００５】
又、同一情報を複数のサーバに管理させる方法では、 １） 同一用途の情報を、複数のサーバで重複管理した場合、１台当たりの管理データは分散されず、トータルの情報量は増加することになり、処理速度が低下してしまう。 ２） 同一用途の情報を複数のサーバに分散して管理した場合、分散された情報の一致性の問題があり、管理が繁雑となる。 ３） 分散型データベースシステムでは、１台当たりの負荷を低減させることが重要であるが、場合によっては、１台のサーバに処理が集中してしまうことがあり、かえって、低速なシステムになってしまう等の問題がある。
【０００６】
又、ネットワークシステムに精通した技術者がいないと、システムが構築できないとか、システムが大規模になればなる程、基幹ネットワークから分岐している各部門の専用サーバは、どの位の性能、例えば、どの位の利用者数が処理可能なのかを考慮した設計が必要となり、実現性が困難となる。
【０００７】
従って、分散型データベースシステムにおいて、利用者が利用し易くて、効率の良いサービスが実現できる分散型データベースの管理方法が要求される。
【０００８】
【従来の技術】
図８〜図１０は、従来の分散型データベース管理方法を説明する図であり、図８は、クライアントが、分散された情報を利用する場合の従来のアクセス方法を示し、図９は、同じ情報が複数個のサーバに重複して分散されている場合の従来のアクセス方法を示し、図１０は、情報が複数のサーバのどれに登録されているかを管理する格納先管理用サーバを設けている場合の従来のアクセス方法を示している。
【０００９】
先ず、図８において、従来から、本図に示されているように、サービス情報を複数個のサーバ １に分散されている場合、利用者は、どのサーバ １に、どのようなサービス情報があるかを認識して、サービス要求を出す。
【００１０】
即ち、データベース利用者は， 利用しようとするサービスを提供するサーバ １を意識して、サービス情報を要求する。
又、図９に示されているように、同じ情報が複数個のサーバに重複して分散されている場合、サーバ負荷が一様に分散されていることが望ましい。そこで、従来は、ネットワーク ３とサーバ １の専用化により負荷分散を行っていた。
【００１１】
即ち、本図に示されているように、特定の利用者 （クライアント）（１）〜利用者 （クライアント）（３） ２と、部門１専用サーバ １〜部門３専用サーバ １とを専用化することで、負荷の分散を図っていた。部門１専用サブネットワーク ３ａ に接続されている利用者（１） 〜 ２ａ は、部門１専用サーバ １ａ のみアクセスすることができる。
【００１２】
又、図１０は、情報が複数のサーバのどれに登録されているかを管理する格納先管理用サーバ １ａ を設けている場合を示している。
同一用途の情報を、複数のサーバ １に分散して管理する場合、複数のサーバ １を意識することなく情報の登録， 検索ができることが望ましい。
【００１３】
その一般的な方法としては、情報が複数のサーバ １のどれに登録されたかを管理する格納先管理用サーバ １ａ を設けておく。即ち、上記格納先管理用サーバ １ａ に、各情報を検索するのに必要な検索キーｉ（＝１，２，〜ｎ）と、情報の格納先のサーバのＩＤとの対応テーブル▲４▼ａを持たせる構成とすることにより、利用者は、必要とする情報を検索する為の検索キーｉのみで、サーバを意識することなく必要な情報が検索できる。
【００１４】
【発明が解決しようとする課題】
従って、上記従来の分散型データベースシステムにおいては、図８のように、例えば、従業員情報を参照する場合、従業員情報が分散されているサーバ（１） 〜サーバ（３） １ の、それぞれにどのような従業員情報があるかを、予め、認識して、サービス要求を出す必要があった。即ち、データベースの利用者は、利用しようとするサービスを提供するサーバ装置を意識しなければならず、前述のように、システムが複雑になってしまうという問題があった。
【００１５】
又、図９に示したように、ネットワーク ３とサーバ １の専用化により負荷分散を行っている場合、例えば、部門１専用サブネットワーク １ａ に接続されている利用者は、同じ情報が分散されている他の部門２，３の負荷が低くても利用することができないという問題があった。又、他の部門２，３の記憶媒体の空き容量が多くても、他の部門の記憶媒体を利用することができないという問題があった。
【００１６】
又、この場合、前述のように、サーバ１台当たりの管理データ量が分散されない為、処理速度が低下してしまうという問題と、同一用途の情報を分散管理した場合、分散されている同一情報の一致性をとる問題があった。
【００１７】
又、図１０に示されているように、情報が複数のサーバのどれに登録されたかを管理する格納先管理用サーバ １ａ を設けられている場合、複数のサーバ １を意識する必要はなくなるが、図１０に示されている従来の方法では、クライアント ２は、先ず、格納先管理用サーバ １ａ の検索キー・サーバＩＤテーブル▲４▼ａを検索して、検索キーｉに対応した格納先サーバＩＤを取得し、次に、格納先サーバ １に対して所望の情報を要求する必要があり、煩雑な操作 （２回操作）が必要となる問題があった。
【００１８】
本発明は上記従来の欠点に鑑み、分散型データベースの管理方法において、利用者の容易な利用と、効率の良いサービスを実現することができる管理方法を提供することを目的とするものである。
【００１９】
【課題を解決するための手段】
図１〜図３は、本発明の原理説明図であり、図１は、分散型データベースシステムの概念図であり、図２は、本発明のサーバを用途別に分類して管理するサーバ情報管理テーブル▲１▼の構成例を示し、図３はサービス毎の検索キーとサーバＩＤとの対応を示す検索キー・サーバＩＤテーブル▲４▼の登録方法を示している。上記の問題点は下記の如くに構成した分散型データベースの管理方法によって解決される。
【００２０】
（１） 分散型データベースの管理方法であって、
複数個のサーバ １を用途別にグループ化して分類したサーバ情報管理テーブル▲１▼｛図２参照｝を設けて、
上記サーバ情報管理テーブル▲１▼を、定期的に、或いは、クライアント ２からサービス要求があったときに登録， 更新， 削除， 参照し、
クライアント ２からのサービス要求を基に、上記サーバ情報管理テーブル▲１▼を参照したときの情報に基づいて、サーバ １を選択するように構成する。
【００２１】
（２） 分散型データベースの管理方法であって、
複数のサーバ １毎の負荷テーブル▲２▼を、クライアント ２， ルータ ４， サーバ １のいずれかに設けて、上記負荷テーブル▲２▼を、定期的に、或いは、クライアント ２からのサービス要求があったときに更新し、
クライアント ２からのサービス要求があって、上記サーバ情報管理テーブル▲１▼を参照したときの情報に基づいて、サーバ １を選択する際、上記サーバ １毎の負荷テーブル▲２▼を参照して、負荷の低いサーバ １を選択するように構成する。
【００２２】
（３） 分散型データベースの管理方法であって、
複数のサーバ １毎の使用状況テーブル▲３▼を、クライアント ２， ルータ ４， サーバ １のいずれかに設けて、上記使用状況テーブル▲３▼を、定期的に、或いは、クライアント ２からのサービス要求があったときに更新し、
クライアント ２からのサービス要求があって、上記サーバ情報管理テーブル▲１▼を参照したときの情報に基づいて、サーバ １を選択する際、上記サーバ １毎の使用状況テーブル▲３▼を参照して、空き容量の多いサーバ １を選択するように構成する。
【００２３】
（４） 分散型データベースの管理方法であって、
サービスを提供する複数のサーバ １を、サービス毎に検索キーと， サーバＩＤとからなる検索キー・サーバＩＤテーブル▲４▼を設けて、
上記検索キー・サーバＩＤテーブル▲４▼を、所定の格納先管理サーバ １ａ で管理するように構成する。
【００２４】
（５） 分散型データベースの管理方法であって、
利用者からの情報提供があったとき、上記サービス毎のサーバ情報管理テーブル▲１▼， 上記サーバ １毎の負荷テーブル▲２▼， 上記サーバ毎の使用状況テーブル▲３▼を参照して、負荷の少ない、資源の空きの多いサーバ １を選択して、上記提供された情報を格納し、
そのときの、検索キーと、サーバＩＤとを、上記格納先管理サーバ １ａ に、上記検索キー・サーバＩＤテーブル▲４▼として登録するように構成する。
【００２５】
【作用】
本発明の分散型データベースの管理方法においては、図１に示した分散型データベースシステムにおいて、用途別に分類された情報を管理するのに、図２に示したサーバ情報管理テーブル▲１▼を、クライアント，トランシーバ，ルータのいずれかに設けて、定期的に，或いは、利用者（クライアント）からのサービス要求があった時に、登録，更新，削除，参照できるようにすることで、複数のサーバを意識することなく、単に，サービスを意識して要求を出すだけで、必要とする情報を利用可能なようにしたものである。
【００２６】
ここで、クライアントから通知された用途別の情報をサーバのネットワーク上るアドレスに変換（元々、選択されたサーバＩＤから、ネットワーク上のアドレスに変換する機構はあったので、本発明では、用途を指定することで得られるサーバＩＤに基づいて、該当のサーバのネットワーク上のアドレスを得るようにした）することにより、利用者は、サーバを意識することなく、容易に各サーバの持っている情報を利用することができる。
【００２７】
又、同一情報を複数のサーバで重複して管理する場合、図２のサーバ情報管理テーブル▲１▼に示されているように、用途別（サービス別）にグループ化して管理することで、複数の各サーバを意識することなく利用可能なようにする。
【００２８】
このとき、各サーバの負荷テーブル▲２▼，使用状況テーブル▲３▼を、クライアント，トランシーバ，ルータのいずれかに設けて、定期的に，或いは、利用者（クライアント）からのサービス要求があった時に、更新するようにして、例えば、一番負荷の低いサーバとか、記憶媒体に空きの多いサーバを選択するようにすることで、利用者が意識することなく、１台のサーバに負荷が集中することを回避することができる。
【００２９】
又、同一用途の情報を分散管理する場合、利用者からの情報提供があったとき、上記サービス （用途） 毎のサーバ情報管理テーブル▲１▼， サーバ毎の負荷テーブル▲２▼， 上記サーバ毎の使用状況テーブル▲３▼を参照して、負荷の少ない、資源の空きの多いサーバ １を選択して、上記提供された情報を格納し、そのときの、提供された情報に対応した検索キーと、サーバＩＤとを、上記格納先管理サーバに、用途別に、上記検索キー・サーバＩＤテーブル▲４▼として登録するように構成することで、利用者は、サービス（用途）を指示するだけで、指示したサービスが格納されているサーバをアクセスすることができ、利用者がサーバを意識することなく、情報の分散管理を行うことができる。
【００３０】
【実施例】
以下本発明の実施例を図面によって詳述する。前述の図１〜図３は、本発明の原理説明図であり、図４〜図７は、本発明の一実施例を示した図であって、図４は、クライアントが、分散された情報を利用する場合のアクセス方法を示し、図５，図６は、同じ情報が複数個のサーバに重複して分散されている場合のアクセス方法を示し、図５は、負荷テーブル▲２▼を使用する場合を示しており，図６は使用状況テーブル▲３▼を使用する場合を示しており、図７は、情報が複数のサーバのどれに登録されているかを管理する格納先管理用サーバ １ａ を設けている場合のアクセス方法を示している。
【００３１】
本発明においては、複数個のサーバ １を、用途 （サービス） 別に分類 （グループ化） したサーバ情報管理テーブル▲１▼に基づいてサーバを選択する。このとき、各サーバ １毎の負荷テーブル▲２▼を、クライアント ２， ルータ ４， サーバ １のいずれかに設けて、最も負荷の低いサーバ １を選択したり、複数のサーバの記憶媒体 （ディスク， テープ等） の使用状況テーブル▲３▼を、クライアント ２， ルータ ４， サーバ １のいずれかに設けて、最も空き容量の多いサーバ １を選択したり、用途別の情報検索キーと、情報格納先のサーバＩＤを、格納先管理用のサーバ １ａ に検索キー・サーバＩＤテーブル▲４▼として登録しておき、利用者からのサービス要求に基づいて、上記検索キー・サーバＩＤテーブル▲４▼により、サーバを意識することなく、必要なサービスを利用できるようにする手段が、本発明を実施するのに必要な手段である。尚、全図を通して同じ符号は同じ対象物を示している。
【００３２】
以下、図１〜図３を参照しながら、図４〜図７によって、本発明の分散型データベースの管理方法を説明する。
図１は、一般的な分散型データベースシステムの構成例を示しており、各クライアント（１） 〜 ２からのサービス要求に基づいて、各サーバ（１） 〜 １がクライアント（１） 〜 ２の要求する情報を提供する。
【００３３】
本発明の分散型データベースシステムでは、サーバ（１） 〜 １を用途別に分類したサーバ情報管理テーブル▲１▼ （図２参照）を、例えば、各クライアント（１） 〜 ２， トランシーバ ５， ルータ ４のいずれかに持ち、例えば、定期的に、或いは、クライアント（１） 〜 ２からサービス要求のあったときに、登録， 更新， 削除， 参照ができるようにし、クライアント（１） 〜 ２から、サービス要求があると、上記サーバ情報管理テーブル▲１▼を参照して、サーバＩＤを認識し、認識したサーバＩＤに基づいて、該当のサーバ（１） 〜 １のネットワーク ３上のアドレスを認識してアクセスすることで、利用者 （クライアント） は、従来のように、サーバ（１） 〜 １を意識することなく、容易に、所望のサーバ（１） 〜 １が持っている情報を利用することができる。
【００３４】
このとき、本発明においては、各サーバ（１） 〜 １毎の負荷テーブル▲２▼とか、或いは、使用状況テーブル▲３▼を、例えば、上記各クライアント（１） 〜 ２， トランシーバ ５， ルータ ４のいずれかに備えておくことで、同一情報を複数のサーバ（１） 〜 １で重複管理されているとき、最も負荷の低いサーバ（１） 〜 １とか、情報の記憶媒体の空きの多いサーバ（１） 〜 １を選択し、利用者が意識することなく、負荷を分散を図ることができるようにしている。
【００３５】
又、同一用途の情報を、複数個のサーバ（１） 〜 １で分散管理する場合、前述の図１０に示されているように、情報が格納されているサーバ（１） 〜 １の識別子（ＩＤ）と、情報の検索キーの部分を、格納先管理用サーバ １ａ に登録するのが一般的である。
【００３６】
然し、この従来方法では、クライアント（１） 〜 ２から、所定の検索キーに対応するサーバ（１） 〜 １をアクセスするのに、クライアント（１） 〜 ２ は、先ず、格納先管理用サーバ １ａ を検索して、検索キーに対応した格納先サーバＩＤを取得し、次に、格納先サーバ（１） 〜 １ に対して所望の情報を要求する必要があり、煩雑な操作 （２回操作）が必要となる問題があったが、本発明においては、図７に示されているように、上記検索キー・サーバＩＤテーブル▲４▼を、用途（サービス）別に構成して、格納先管理用サーバ １ａ で管理する方法を採ることにより、クライアント（１） 〜 ２からの只１回のサービス要求に基づいて、該サービスに対応する検索キー・サーバＩＤテーブル▲４▼が検索され、所望のサーバＩＤを認識して、該当のサーバ（１） 〜 １をアクセスできるようになる。
【００３７】
又、上記の如く、同一用途の情報を分散管理する場合、利用者からの情報提供があると、図３に示されているように、上記サービス （用途） 毎のサーバ情報管理テーブル▲１▼， サーバ毎の負荷テーブル▲２▼， 上記サーバ毎の使用状況テーブル▲３▼を参照して、負荷の少ない、資源の空きの多いサーバ １を選択して、上記提供された情報を格納し、そのときの、提供された情報に対応した検索キーと、サーバＩＤとを、上記格納先管理サーバ １ａ に、用途（サービス）別に、上記検索キー・サーバＩＤテーブル▲４▼として登録するように構成することで、利用者がサーバを意識することなく、情報の分散管理を行うことができる。
【００３８】
以下、図４〜図７に基づいて、更に、具体的に説明する。
図４は、複数個のサーバ（１） 〜 １を用途別に分類したサーバ情報管理テーブル▲１▼（図２参照）に基づいて、サーバ（１） 〜 １が検索される例を示している。
【００３９】
今、クライアント（１） 〜 ２の利用者が、従業員情報のサービスを要求すると、本発明においては、例えば、各クライアント（１） 〜 ２に設けられている、図２に示されている本発明のサーバ情報管理テーブル▲１▼が参照され、対応するサーバ（１） がアクセスされる。従って、データベースの利用者は、利用しようとするサービスのみを意識することで事足り、従来のように、必要とする情報が格納されているサーバを意識する必要がなくなり、容易にサービスを受けることができるようになる。
【００４０】
更に、本発明においては、図５に示したように、各サーバ（１） 〜 ２に掛かっている負荷を負荷テーブル▲２▼として、クライアント （利用者）（１）〜 ２， ルータ ４， サーバ（１） 〜 １のいずれか， 又は、複数に設けることで、上記サーバ情報管理テーブル▲１▼で選択されたサーバ（１） 〜 １の中で、例えば、負荷の一番低いサーバ（１） 〜 １に対してサービスを要求することができる。
【００４１】
各サーバ（１） 〜 １の負荷の計算方法としては、例えば、同一の処理に掛かっている時間を計算し、掛かっている時間の長いサーバ（１） 〜 １の負荷が重いとするとか、処理パケット （通常、処理はパケットを単位として行われるので、その要求パケット， 終了パケット） の数を計数することで、処理パケットの多いサーバ（１） 〜 １の負荷が重いとする方法があるが、特に、限定するものではない。
【００４２】
又、図６に示したように、各サーバ（１） 〜 １の持っている記憶媒体の使用状況テーブル▲３▼を、クライアント （利用者）（１）〜 ２， ルータ ４， サーバ（１） 〜 １のいずれか， 又は、複数に設けることで、上記サーバ情報管理テーブル▲１▼で選択されたサーバ（１） 〜 １の中で、例えば、空き容量の多いサーバ（１） 〜 １に対して、情報を登録したり、サービスを要求することができる。
【００４３】
上記各サーバ（１） 〜 １の負荷， 空き容量を判定するタイミングとしては、例えば、定期的に， 或いは、クライアント（１） 〜 １から要求のあった時に行うようにしてもよい。又、上記負荷テーブル▲２▼， 使用状況テーブル▲３▼の更新タイミングも、上記定期的に， 或いは、クライアント（１） 〜 １から要求のあった時に行うようにしても良い。
【００４４】
次に、図７によって、検索キー・サーバＩＤテーブル▲４▼によるデータベースの管理方法を説明する。
前述のように、同一用途の情報を複数のサーバ（１） 〜 １に分散して管理する場合、複数のサーバ（１） 〜 １を意識することなく、登録， 検索ができることが望ましい。
【００４５】
そこで、本発明においては、クライアント（１） 〜 ２から、情報の提供があったとき、前述の図３で説明したように、上記サーバ情報管理テーブル▲１▼， 負荷テーブル▲２▼， 使用状況テーブル▲３▼によって選択されたサーバ（１） 〜 １に登録すると共に、格納先管理用サーバ １ａ では、検索キー・サーバＩＤテーブル▲４▼をサービス （用途） 毎に構成して管理するようにする。
【００４６】
このように構成することにより、利用者は、サービスのみを指定するだけで、要求する情報が格納されているサーバ（１） 〜 １を選択することができる。
又、サービス毎に管理する方法を用いたことにより、図１０で説明した従来の格納先管理用サーバ １ａ では管理することができなかった複数のサービスを管理することができるようになる。
【００４７】
上記の実施例においては、分散型データベースシステムを例にして説明したが、上記のサーバ情報管理テーブル▲１▼， 負荷テーブル▲２▼， 使用状況テーブル▲３▼， 更に、検索キー・サーバＩＤテーブル▲４▼と同等の各テーブルを備えたクライアントシステム， ルーティングシステムであっても良いし、上記各テーブル▲１▼〜▲４▼を利用したネットワークシステムとか、上記各テーブル▲１▼〜▲４▼を用いたサーバの処理を入出力デバイスの制御に用いた入出力制御方法であっても良い。
【００４８】
このように、本発明は、分散型データベースの管理方法において、複数個のサーバを、用途 （サービス） 別に分類 （グループ化） したサーバ情報管理テーブル▲１▼に基づいてサーバを選択する。このとき、各サーバ毎の負荷テーブル▲２▼を設けて、最も負荷の低いサーバを選択したり、複数のサーバの記憶媒体 （ディスク， テープ等） の使用状況テーブル▲３▼を設けて、最も空き容量の多いサーバを選択したり、情報検索キーと、情報格納先のサーバＩＤを用途別に構成して、格納先管理用のサーバに検索キー・サーバＩＤテーブル▲４▼として登録しておき、利用者からの只１回のサービス要求に基づいて、サーバを意識することなく、必要なサービスを利用できるようにしたところに特徴がある。
【００４９】
【発明の効果】
以上、詳細に説明したように、本発明の分散型データベース管理方法によれば、利用者は、サーバを意識する必要がなく、単に、サービスだけを意識するだけで事足り、容易にサーバを利用することができる。又、負荷の低いサーバとか、空き容量の多いサーバを選択することにより、１台のサーバに負荷が集中することがなくなり、利用者が意識することなく負荷が分散し、効率のよいサービスが実現できる効果がある。
【図面の簡単な説明】
【図１】本発明の原理説明図（その１）
【図２】本発明の原理説明図（その２）
【図３】本発明の原理説明図（その３）
【図４】本発明の一実施例を示した図（その１）
【図５】本発明の一実施例を示した図（その２）
【図６】本発明の一実施例を示した図（その３）
【図７】本発明の一実施例を示した図（その４）
【図８】従来の分散型データベースの管理方法を説明する図（その１）
【図９】従来の分散型データベースの管理方法を説明する図（その２）
【図１０】従来の分散型データベースの管理方法を説明する図（その３）
【符号の説明】
１ サーバ， サーバ（１），（２），〜
１ａ 格納先管理用サーバ
２ クライアント， クライアント（１），（２），〜， 利用者（１），（２），〜
３ ネットワーク ３ａ サブネットワーク
▲１▼ サーバ情報管理テーブル
▲２▼ 負荷テーブル
▲３▼ 使用状況テーブル
▲４▼ 用途別の検索キー・サーバＩＤテーブル
Claims (1)
- 複数のクライアントが複数のサーバに同一用途の情報を分散して格納する分散型データベースのシステムを管理する分散型データベース管理装置であって、
前記情報に含まれる検索キーと、前記情報を格納するサーバの識別子であるサーバＩＤとを対応づけて格納するサーバＩＤテーブルと、
前記複数のサーバ毎の空き容量情報を含む使用状況テーブルと、
前記使用状況テーブルを、定期的に、或いは、クライアントからの情報格納要求があったときに更新する更新手段と、
クライアントからの情報格納要求に基づいて、前記サーバを選択する際、前記使用状況テーブルを参照して、空き容量の多いサーバを選択して情報格納する格納手段と、
前記格納された情報の検索キーと前記格納されたサーバのサーバＩＤとを関連づけて前記サーバＩＤテーブルに登録すると共に、該サーバＩＤテーブルをデータベースに接続された複数のクライアントに通知する登録手段と、
を有することを特徴とする分散型データベース管理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP04307593A JP3598522B2 (ja) | 1993-03-04 | 1993-03-04 | 分散型データベース管理装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP04307593A JP3598522B2 (ja) | 1993-03-04 | 1993-03-04 | 分散型データベース管理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH06259308A JPH06259308A (ja) | 1994-09-16 |
| JP3598522B2 true JP3598522B2 (ja) | 2004-12-08 |
Family
ID=12653733
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP04307593A Expired - Fee Related JP3598522B2 (ja) | 1993-03-04 | 1993-03-04 | 分散型データベース管理装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3598522B2 (ja) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH10240684A (ja) * | 1997-02-27 | 1998-09-11 | Oki Electric Ind Co Ltd | 複数端末の制御方法 |
| JP3249994B2 (ja) * | 1997-02-27 | 2002-01-28 | 日本電信電話株式会社 | サーバ・クライアント型情報提供方法及びシステム |
| JPH10254831A (ja) * | 1997-03-10 | 1998-09-25 | Oki Electric Ind Co Ltd | 複数端末の制御方法 |
| JP3314665B2 (ja) * | 1997-05-30 | 2002-08-12 | 日本電気株式会社 | 分散ファイルシステム |
| US6862623B1 (en) * | 2000-04-14 | 2005-03-01 | Microsoft Corporation | Capacity planning for server resources |
| JP2002024325A (ja) * | 2000-07-07 | 2002-01-25 | Takenaka Komuten Co Ltd | 建設支援方法 |
| JP2003186785A (ja) * | 2001-12-14 | 2003-07-04 | Sanyo Electric Co Ltd | ローカルサーバ、情報配信システムおよびユーザ端末装置 |
| WO2005006671A1 (ja) | 2003-07-09 | 2005-01-20 | Fujitsu Limited | ネットワークにおける特定サービスの最適ルーティング方法並びに同ネットワークに用いられるサーバ及びルーティングノード |
| US7895247B2 (en) * | 2003-10-29 | 2011-02-22 | Oracle International Corporation | Tracking space usage in a database |
| US8560639B2 (en) * | 2009-04-24 | 2013-10-15 | Microsoft Corporation | Dynamic placement of replica data |
| JP5740210B2 (ja) | 2011-06-06 | 2015-06-24 | 株式会社東芝 | 顔画像検索システム、及び顔画像検索方法 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0266647A (ja) * | 1988-08-31 | 1990-03-06 | Hitachi Ltd | 分散型データベースシステムの障害情報通知方式 |
| JPH02275563A (ja) * | 1989-04-17 | 1990-11-09 | Nippon Telegr & Teleph Corp <Ntt> | 情報処理システムにおけるサーバ利用方式 |
| JPH0342742A (ja) * | 1989-07-10 | 1991-02-22 | Nec Corp | レンジ分割によるオンラインデータベースシステム |
| JPH03257571A (ja) * | 1990-03-07 | 1991-11-18 | Fujitsu Ltd | 資源管理サーバ特定処理方式 |
| JPH04152439A (ja) * | 1990-10-17 | 1992-05-26 | Fujitsu Ltd | ファイル代行処理方式 |
-
1993
- 1993-03-04 JP JP04307593A patent/JP3598522B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH06259308A (ja) | 1994-09-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11494380B2 (en) | Management of distributed computing framework components in a data fabric service system | |
| US20200364223A1 (en) | Search time estimate in a data intake and query system | |
| US6832248B1 (en) | System and method for managing usage quotas | |
| US7237027B1 (en) | Scalable storage system | |
| US6983322B1 (en) | System for discrete parallel processing of queries and updates | |
| US7376953B2 (en) | Apparatus and method for routing a transaction to a server | |
| US8131689B2 (en) | Accumulating access frequency and file attributes for supporting policy based storage management | |
| US6377984B1 (en) | Web crawler system using parallel queues for queing data sets having common address and concurrently downloading data associated with data set in each queue | |
| KR100974149B1 (ko) | 네임스페이스에 대한 정보 유지 방법, 시스템 및 컴퓨터 판독가능 저장 매체 | |
| US20100121855A1 (en) | Lookup Partitioning Storage System and Method | |
| CN100590620C (zh) | 用于使记录在分区之间移动的系统和方法 | |
| JP2004070403A (ja) | ファイル格納先ボリューム制御方法 | |
| US7797392B2 (en) | System and method for efficiently supporting multiple native network protocol implementations in a single system | |
| JP3598522B2 (ja) | 分散型データベース管理装置 | |
| US20180248977A1 (en) | Selective distribution of messages in a publish-subscribe system | |
| JP3584630B2 (ja) | データベース処理システムにおける分類集計処理方法 | |
| JP4839585B2 (ja) | 資源情報収集配信方法およびシステム | |
| US20070174248A1 (en) | Method and system for data processing with load balance | |
| JP3994059B2 (ja) | クラスタ化コンピュータ・システム | |
| US8285720B2 (en) | Grouping of computers in a computer information database system | |
| US11106739B2 (en) | Document structures for searching within and across messages | |
| US20030115202A1 (en) | System and method for processing a request using multiple database units | |
| JP2007206913A (ja) | データベースアクセスシステム、アプリケーションサーバノード、データベースアクセス方法及びプログラム | |
| JP2002116944A (ja) | メンバシップ管理方法 | |
| KR20010070944A (ko) | 데이터베이스 구조변화에 대응하는 웹기반 통신망성능감시 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040106 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040308 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20040324 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040824 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040906 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080924 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080924 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090924 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |