JPH06259308A - 分散型データベースの管理方法、及びシステム - Google Patents
分散型データベースの管理方法、及びシステムInfo
- Publication number
- JPH06259308A JPH06259308A JP5043075A JP4307593A JPH06259308A JP H06259308 A JPH06259308 A JP H06259308A JP 5043075 A JP5043075 A JP 5043075A JP 4307593 A JP4307593 A JP 4307593A JP H06259308 A JPH06259308 A JP H06259308A
- Authority
- JP
- Japan
- Prior art keywords
- server
- information
- distributed database
- client
- load
- 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.)
- Granted
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【目的】 本発明は、分散型データベースの管理方法に
関し、利用者の容易な利用と、効率の良いサービスを実
現する。 【構成】 複数個のサーバを、用途 (サービス) 別に分
類 (グループ化) したサーバ情報管理テーブルに基づ
いてサーバを選択する。このとき、各サーバ毎の負荷テ
ーブルを設けて、最も負荷の低いサーバを選択した
り、複数のサーバの記憶媒体 (ディスク, テープ等) の
使用状況テーブルを設けて、最も空き容量の多いサー
バを選択したり、用途別の情報検索キーと、情報格納先
のサーバＩＤを、格納先管理用のサーバに検索キー・サ
ーバＩＤテーブルとして登録しておき、利用者からの
只１回のサービス要求に基づいて、サーバを意識するこ
となく、必要なサービスを利用できるようにする。
関し、利用者の容易な利用と、効率の良いサービスを実
現する。 【構成】 複数個のサーバを、用途 (サービス) 別に分
類 (グループ化) したサーバ情報管理テーブルに基づ
いてサーバを選択する。このとき、各サーバ毎の負荷テ
ーブルを設けて、最も負荷の低いサーバを選択した
り、複数のサーバの記憶媒体 (ディスク, テープ等) の
使用状況テーブルを設けて、最も空き容量の多いサー
バを選択したり、用途別の情報検索キーと、情報格納先
のサーバＩＤを、格納先管理用のサーバに検索キー・サ
ーバＩＤテーブルとして登録しておき、利用者からの
只１回のサービス要求に基づいて、サーバを意識するこ
となく、必要なサービスを利用できるようにする。
Description
【０００１】
【産業上の利用分野】本発明は、分散型データベースの
管理方法，及び、上記分散型データベースの管理方法を
備えたシステムに関する。
管理方法，及び、上記分散型データベースの管理方法を
備えたシステムに関する。
【０００２】従来から各種の情報を複数個のサーバに用
途別に，或いは、同一の情報を複数のサーバに分散し
て、複数個の利用者（クライアント）が利用する分散型
データベースシステムが知られている。
途別に，或いは、同一の情報を複数のサーバに分散し
て、複数個の利用者（クライアント）が利用する分散型
データベースシステムが知られている。
【０００３】かかる分散型データベースシステムは、ダ
ウンサイジング，処理の高速化等を目的としたシステム
が多く、これまで、１台の大型コンピユータで実行して
いた処理を複数の小型コンピユータ、例えば、ワークス
テーションに分散し、１台当たりの負荷を低減し、並行
に処理を実行する方法を採用している。
ウンサイジング，処理の高速化等を目的としたシステム
が多く、これまで、１台の大型コンピユータで実行して
いた処理を複数の小型コンピユータ、例えば、ワークス
テーションに分散し、１台当たりの負荷を低減し、並行
に処理を実行する方法を採用している。
【０００４】用途別にサーバに分散させる方法では、
1) 用途別に分散されたサーバを意識した制御が必要と
なり、システムが複雑になってしまう。 2) サーバのネ
ットワーク上でのアドレスの変更等が発生した場合に、
利用者に、変更後のアドレスを知らせる必要があり、管
理が繁雑となる等の問題がある。
1) 用途別に分散されたサーバを意識した制御が必要と
なり、システムが複雑になってしまう。 2) サーバのネ
ットワーク上でのアドレスの変更等が発生した場合に、
利用者に、変更後のアドレスを知らせる必要があり、管
理が繁雑となる等の問題がある。
【０００５】又、同一情報を複数のサーバに管理させる
方法では、 1) 同一用途の情報を、複数のサーバで重複
管理した場合、１台当たりの管理データは分散されず、
トータルの情報量は増加することになり、処理速度が低
下してしまう。 2) 同一用途の情報を複数のサーバに分
散して管理した場合、分散された情報の一致性の問題が
あり、管理が繁雑となる。 3) 分散型データベースシス
テムでは、１台当たりの負荷を低減させることが重要で
あるが、場合によっては、１台のサーバに処理が集中し
てしまうことがあり、かえって、低速なシステムになっ
てしまう等の問題がある。
方法では、 1) 同一用途の情報を、複数のサーバで重複
管理した場合、１台当たりの管理データは分散されず、
トータルの情報量は増加することになり、処理速度が低
下してしまう。 2) 同一用途の情報を複数のサーバに分
散して管理した場合、分散された情報の一致性の問題が
あり、管理が繁雑となる。 3) 分散型データベースシス
テムでは、１台当たりの負荷を低減させることが重要で
あるが、場合によっては、１台のサーバに処理が集中し
てしまうことがあり、かえって、低速なシステムになっ
てしまう等の問題がある。
【０００６】又、ネットワークシステムに精通した技術
者がいないと、システムが構築できないとか、システム
が大規模になればなる程、基幹ネットワークから分岐し
ている各部門の専用サーバは、どの位の性能、例えば、
どの位の利用者数が処理可能なのかを考慮した設計が必
要となり、実現性が困難となる。
者がいないと、システムが構築できないとか、システム
が大規模になればなる程、基幹ネットワークから分岐し
ている各部門の専用サーバは、どの位の性能、例えば、
どの位の利用者数が処理可能なのかを考慮した設計が必
要となり、実現性が困難となる。
【０００７】従って、分散型データベースシステムにお
いて、利用者が利用し易くて、効率の良いサービスが実
現できる分散型データベースの管理方法が要求される。
いて、利用者が利用し易くて、効率の良いサービスが実
現できる分散型データベースの管理方法が要求される。
【０００８】
【従来の技術】図８〜図１０は、従来の分散型データベ
ース管理方法を説明する図であり、図８は、クライアン
トが、分散された情報を利用する場合の従来のアクセス
方法を示し、図９は、同じ情報が複数個のサーバに重複
して分散されている場合の従来のアクセス方法を示し、
図１０は、情報が複数のサーバのどれに登録されている
かを管理する格納先管理用サーバを設けている場合の従
来のアクセス方法を示している。
ース管理方法を説明する図であり、図８は、クライアン
トが、分散された情報を利用する場合の従来のアクセス
方法を示し、図９は、同じ情報が複数個のサーバに重複
して分散されている場合の従来のアクセス方法を示し、
図１０は、情報が複数のサーバのどれに登録されている
かを管理する格納先管理用サーバを設けている場合の従
来のアクセス方法を示している。
【０００９】先ず、図８において、従来から、本図に示
されているように、サービス情報を複数個のサーバ 1に
分散されている場合、利用者は、どのサーバ 1に、どの
ようなサービス情報があるかを認識して、サービス要求
を出す。
されているように、サービス情報を複数個のサーバ 1に
分散されている場合、利用者は、どのサーバ 1に、どの
ようなサービス情報があるかを認識して、サービス要求
を出す。
【００１０】即ち、データベース利用者は, 利用しよう
とするサービスを提供するサーバ 1を意識して、サービ
ス情報を要求する。又、図９に示されているように、同
じ情報が複数個のサーバに重複して分散されている場
合、サーバ負荷が一様に分散されていることが望まし
い。そこで、従来は、ネットワーク 3とサーバ 1の専用
化により負荷分散を行っていた。
とするサービスを提供するサーバ 1を意識して、サービ
ス情報を要求する。又、図９に示されているように、同
じ情報が複数個のサーバに重複して分散されている場
合、サーバ負荷が一様に分散されていることが望まし
い。そこで、従来は、ネットワーク 3とサーバ 1の専用
化により負荷分散を行っていた。
【００１１】即ち、本図に示されているように、特定の
利用者 (クライアント)(1)〜利用者(クライアント)(3)
2と、部門１専用サーバ 1〜部門３専用サーバ 1とを専
用化することで、負荷の分散を図っていた。部門１専用
サブネットワーク 3a に接続されている利用者(1) 〜 2
a は、部門１専用サーバ 1a のみアクセスすることがで
きる。
利用者 (クライアント)(1)〜利用者(クライアント)(3)
2と、部門１専用サーバ 1〜部門３専用サーバ 1とを専
用化することで、負荷の分散を図っていた。部門１専用
サブネットワーク 3a に接続されている利用者(1) 〜 2
a は、部門１専用サーバ 1a のみアクセスすることがで
きる。
【００１２】又、図１０は、情報が複数のサーバのどれ
に登録されているかを管理する格納先管理用サーバ 1a
を設けている場合を示している。同一用途の情報を、複
数のサーバ 1に分散して管理する場合、複数のサーバ 1
を意識することなく情報の登録, 検索ができることが望
ましい。
に登録されているかを管理する格納先管理用サーバ 1a
を設けている場合を示している。同一用途の情報を、複
数のサーバ 1に分散して管理する場合、複数のサーバ 1
を意識することなく情報の登録, 検索ができることが望
ましい。
【００１３】その一般的な方法としては、情報が複数の
サーバ 1のどれに登録されたかを管理する格納先管理用
サーバ 1a を設けておく。即ち、上記格納先管理用サー
バ 1a に、各情報を検索するのに必要な検索キーｉ(=1,
2,〜n)と、情報の格納先のサーバのＩＤとの対応テーブ
ルａを持たせる構成とすることにより、利用者は、必
要とする情報を検索する為の検索キーｉのみで、サーバ
を意識することなく必要な情報が検索できる。
サーバ 1のどれに登録されたかを管理する格納先管理用
サーバ 1a を設けておく。即ち、上記格納先管理用サー
バ 1a に、各情報を検索するのに必要な検索キーｉ(=1,
2,〜n)と、情報の格納先のサーバのＩＤとの対応テーブ
ルａを持たせる構成とすることにより、利用者は、必
要とする情報を検索する為の検索キーｉのみで、サーバ
を意識することなく必要な情報が検索できる。
【００１４】
【発明が解決しようとする課題】従って、上記従来の分
散型データベースシステムにおいては、図８のように、
例えば、従業員情報を参照する場合、従業員情報が分散
されているサーバ(1) 〜サーバ(3) 1 の、それぞれにど
のような従業員情報があるかを、予め、認識して、サー
ビス要求を出す必要があった。即ち、データベースの利
用者は、利用しようとするサービスを提供するサーバ装
置を意識しなければならず、前述のように、システムが
複雑になってしまうという問題があった。
散型データベースシステムにおいては、図８のように、
例えば、従業員情報を参照する場合、従業員情報が分散
されているサーバ(1) 〜サーバ(3) 1 の、それぞれにど
のような従業員情報があるかを、予め、認識して、サー
ビス要求を出す必要があった。即ち、データベースの利
用者は、利用しようとするサービスを提供するサーバ装
置を意識しなければならず、前述のように、システムが
複雑になってしまうという問題があった。
【００１５】又、図９に示したように、ネットワーク 3
とサーバ 1の専用化により負荷分散を行っている場合、
例えば、部門１専用サブネットワーク 1a に接続されて
いる利用者は、同じ情報が分散されている他の部門２，
３の負荷が低くても利用することができないという問題
があった。又、他の部門２，３の記憶媒体の空き容量が
多くても、他の部門の記憶媒体を利用することができな
いという問題があった。
とサーバ 1の専用化により負荷分散を行っている場合、
例えば、部門１専用サブネットワーク 1a に接続されて
いる利用者は、同じ情報が分散されている他の部門２，
３の負荷が低くても利用することができないという問題
があった。又、他の部門２，３の記憶媒体の空き容量が
多くても、他の部門の記憶媒体を利用することができな
いという問題があった。
【００１６】又、この場合、前述のように、サーバ１台
当たりの管理データ量が分散されない為、処理速度が低
下してしまうという問題と、同一用途の情報を分散管理
した場合、分散されている同一情報の一致性をとる問題
があった。
当たりの管理データ量が分散されない為、処理速度が低
下してしまうという問題と、同一用途の情報を分散管理
した場合、分散されている同一情報の一致性をとる問題
があった。
【００１７】又、図１０に示されているように、情報が
複数のサーバのどれに登録されたかを管理する格納先管
理用サーバ 1a を設けられている場合、複数のサーバ 1
を意識する必要はなくなるが、図１０に示されている従
来の方法では、クライアント2は、先ず、格納先管理用
サーバ 1a の検索キー・サーバＩＤテーブルａを検索
して、検索キーｉに対応した格納先サーバＩＤを取得
し、次に、格納先サーバ1に対して所望の情報を要求す
る必要があり、煩雑な操作 (２回操作）が必要となる問
題があった。
複数のサーバのどれに登録されたかを管理する格納先管
理用サーバ 1a を設けられている場合、複数のサーバ 1
を意識する必要はなくなるが、図１０に示されている従
来の方法では、クライアント2は、先ず、格納先管理用
サーバ 1a の検索キー・サーバＩＤテーブルａを検索
して、検索キーｉに対応した格納先サーバＩＤを取得
し、次に、格納先サーバ1に対して所望の情報を要求す
る必要があり、煩雑な操作 (２回操作）が必要となる問
題があった。
【００１８】本発明は上記従来の欠点に鑑み、分散型デ
ータベースの管理方法において、利用者の容易な利用
と、効率の良いサービスを実現することができる管理方
法を提供することを目的とするものである。
ータベースの管理方法において、利用者の容易な利用
と、効率の良いサービスを実現することができる管理方
法を提供することを目的とするものである。
【００１９】
【課題を解決するための手段】図１〜図３は、本発明の
原理説明図であり、図１は、分散型データベースシステ
ムの概念図であり、図２は、本発明のサーバを用途別に
分類して管理するサーバ情報管理テーブルの構成例を
示し、図３はサービス毎の検索キーとサーバＩＤとの対
応を示す検索キー・サーバＩＤテーブルの登録方法を
示している。上記の問題点は下記の如くに構成した分散
型データベースの管理方法によって解決される。
原理説明図であり、図１は、分散型データベースシステ
ムの概念図であり、図２は、本発明のサーバを用途別に
分類して管理するサーバ情報管理テーブルの構成例を
示し、図３はサービス毎の検索キーとサーバＩＤとの対
応を示す検索キー・サーバＩＤテーブルの登録方法を
示している。上記の問題点は下記の如くに構成した分散
型データベースの管理方法によって解決される。
【００２０】(1) 分散型データベースの管理方法であっ
て、複数個のサーバ 1を用途別にグループ化して分類し
たサーバ情報管理テーブル｛図２参照｝を設けて、上
記サーバ情報管理テーブルを、定期的に、或いは、ク
ライアント 2からサービス要求があったときに登録, 更
新, 削除, 参照し、クライアント 2からのサービス要求
を基に、上記サーバ情報管理テーブルを参照したとき
の情報に基づいて、サーバ 1を選択するように構成す
る。
て、複数個のサーバ 1を用途別にグループ化して分類し
たサーバ情報管理テーブル｛図２参照｝を設けて、上
記サーバ情報管理テーブルを、定期的に、或いは、ク
ライアント 2からサービス要求があったときに登録, 更
新, 削除, 参照し、クライアント 2からのサービス要求
を基に、上記サーバ情報管理テーブルを参照したとき
の情報に基づいて、サーバ 1を選択するように構成す
る。
【００２１】(2) 分散型データベースの管理方法であっ
て、複数のサーバ 1毎の負荷テーブルを、クライアン
ト 2, ルータ 4, サーバ 1のいずれかに設けて、上記負
荷テーブルを、定期的に、或いは、クライアント2か
らのサービス要求があったときに更新し、クライアント
2からのサービス要求があって、上記サーバ情報管理テ
ーブルを参照したときの情報に基づいて、サーバ 1を
選択する際、上記サーバ 1毎の負荷テーブルを参照し
て、負荷の低いサーバ 1を選択するように構成する。
て、複数のサーバ 1毎の負荷テーブルを、クライアン
ト 2, ルータ 4, サーバ 1のいずれかに設けて、上記負
荷テーブルを、定期的に、或いは、クライアント2か
らのサービス要求があったときに更新し、クライアント
2からのサービス要求があって、上記サーバ情報管理テ
ーブルを参照したときの情報に基づいて、サーバ 1を
選択する際、上記サーバ 1毎の負荷テーブルを参照し
て、負荷の低いサーバ 1を選択するように構成する。
【００２２】(3) 分散型データベースの管理方法であっ
て、複数のサーバ 1毎の使用状況テーブルを、クライ
アント 2, ルータ 4, サーバ 1のいずれかに設けて、上
記使用状況テーブルを、定期的に、或いは、クライア
ント 2からのサービス要求があったときに更新し、クラ
イアント 2からのサービス要求があって、上記サーバ情
報管理テーブルを参照したときの情報に基づいて、サ
ーバ 1を選択する際、上記サーバ 1毎の使用状況テーブ
ルを参照して、空き容量の多いサーバ 1を選択するよ
うに構成する。
て、複数のサーバ 1毎の使用状況テーブルを、クライ
アント 2, ルータ 4, サーバ 1のいずれかに設けて、上
記使用状況テーブルを、定期的に、或いは、クライア
ント 2からのサービス要求があったときに更新し、クラ
イアント 2からのサービス要求があって、上記サーバ情
報管理テーブルを参照したときの情報に基づいて、サ
ーバ 1を選択する際、上記サーバ 1毎の使用状況テーブ
ルを参照して、空き容量の多いサーバ 1を選択するよ
うに構成する。
【００２３】(4) 分散型データベースの管理方法であっ
て、サービスを提供する複数のサーバ 1を、サービス毎
に検索キーと, サーバＩＤとからなる検索キー・サーバ
ＩＤテーブルを設けて、上記検索キー・サーバＩＤテ
ーブルを、所定の格納先管理サーバ 1a で管理するよ
うに構成する。
て、サービスを提供する複数のサーバ 1を、サービス毎
に検索キーと, サーバＩＤとからなる検索キー・サーバ
ＩＤテーブルを設けて、上記検索キー・サーバＩＤテ
ーブルを、所定の格納先管理サーバ 1a で管理するよ
うに構成する。
【００２４】(5) 分散型データベースの管理方法であっ
て、利用者からの情報提供があったとき、上記サービス
毎のサーバ情報管理テーブル, 上記サーバ 1毎の負荷
テーブル, 上記サーバ毎の使用状況テーブルを参照
して、負荷の少ない、資源の空きの多いサーバ 1を選択
して、上記提供された情報を格納し、そのときの、検索
キーと、サーバＩＤとを、上記格納先管理サーバ 1a
に、上記検索キー・サーバＩＤテーブルとして登録す
るように構成する。
て、利用者からの情報提供があったとき、上記サービス
毎のサーバ情報管理テーブル, 上記サーバ 1毎の負荷
テーブル, 上記サーバ毎の使用状況テーブルを参照
して、負荷の少ない、資源の空きの多いサーバ 1を選択
して、上記提供された情報を格納し、そのときの、検索
キーと、サーバＩＤとを、上記格納先管理サーバ 1a
に、上記検索キー・サーバＩＤテーブルとして登録す
るように構成する。
【００２５】
【作用】本発明の分散型データベースの管理方法におい
ては、図１に示した分散型データベースシステムにおい
て、用途別に分類された情報を管理するのに、図２に示
したサーバ情報管理テーブルを、クライアント，トラ
ンシーバ，ルータのいずれかに設けて、定期的に，或い
は、利用者（クライアント）からのサービス要求があっ
た時に、登録，更新，削除，参照できるようにすること
で、複数のサーバを意識することなく、単に，サービス
を意識して要求を出すだけで、必要とする情報を利用可
能なようにしたものである。
ては、図１に示した分散型データベースシステムにおい
て、用途別に分類された情報を管理するのに、図２に示
したサーバ情報管理テーブルを、クライアント，トラ
ンシーバ，ルータのいずれかに設けて、定期的に，或い
は、利用者（クライアント）からのサービス要求があっ
た時に、登録，更新，削除，参照できるようにすること
で、複数のサーバを意識することなく、単に，サービス
を意識して要求を出すだけで、必要とする情報を利用可
能なようにしたものである。
【００２６】ここで、クライアントから通知された用途
別の情報をサーバのネットワーク上るアドレスに変換
（元々、選択されたサーバＩＤから、ネットワーク上の
アドレスに変換する機構はあったので、本発明では、用
途を指定することで得られるサーバＩＤに基づいて、該
当のサーバのネットワーク上のアドレスを得るようにし
た）することにより、利用者は、サーバを意識すること
なく、容易に各サーバの持っている情報を利用すること
ができる。
別の情報をサーバのネットワーク上るアドレスに変換
（元々、選択されたサーバＩＤから、ネットワーク上の
アドレスに変換する機構はあったので、本発明では、用
途を指定することで得られるサーバＩＤに基づいて、該
当のサーバのネットワーク上のアドレスを得るようにし
た）することにより、利用者は、サーバを意識すること
なく、容易に各サーバの持っている情報を利用すること
ができる。
【００２７】又、同一情報を複数のサーバで重複して管
理する場合、図２のサーバ情報管理テーブルに示され
ているように、用途別（サービス別）にグループ化して
管理することで、複数の各サーバを意識することなく利
用可能なようにする。
理する場合、図２のサーバ情報管理テーブルに示され
ているように、用途別（サービス別）にグループ化して
管理することで、複数の各サーバを意識することなく利
用可能なようにする。
【００２８】このとき、各サーバの負荷テーブル，使
用状況テーブルを、クライアント，トランシーバ，ル
ータのいずれかに設けて、定期的に，或いは、利用者
（クライアント）からのサービス要求があった時に、更
新するようにして、例えば、一番負荷の低いサーバと
か、記憶媒体に空きの多いサーバを選択するようにする
ことで、利用者が意識することなく、１台のサーバに負
荷が集中することを回避することができる。
用状況テーブルを、クライアント，トランシーバ，ル
ータのいずれかに設けて、定期的に，或いは、利用者
（クライアント）からのサービス要求があった時に、更
新するようにして、例えば、一番負荷の低いサーバと
か、記憶媒体に空きの多いサーバを選択するようにする
ことで、利用者が意識することなく、１台のサーバに負
荷が集中することを回避することができる。
【００２９】又、同一用途の情報を分散管理する場合、
利用者からの情報提供があったとき、上記サービス (用
途) 毎のサーバ情報管理テーブル, サーバ毎の負荷テ
ーブル, 上記サーバ毎の使用状況テーブルを参照し
て、負荷の少ない、資源の空きの多いサーバ 1を選択し
て、上記提供された情報を格納し、そのときの、提供さ
れた情報に対応した検索キーと、サーバＩＤとを、上記
格納先管理サーバに、用途別に、上記検索キー・サーバ
ＩＤテーブルとして登録するように構成することで、
利用者は、サービス（用途）を指示するだけで、指示し
たサービスが格納されているサーバをアクセスすること
ができ、利用者がサーバを意識することなく、情報の分
散管理を行うことができる。
利用者からの情報提供があったとき、上記サービス (用
途) 毎のサーバ情報管理テーブル, サーバ毎の負荷テ
ーブル, 上記サーバ毎の使用状況テーブルを参照し
て、負荷の少ない、資源の空きの多いサーバ 1を選択し
て、上記提供された情報を格納し、そのときの、提供さ
れた情報に対応した検索キーと、サーバＩＤとを、上記
格納先管理サーバに、用途別に、上記検索キー・サーバ
ＩＤテーブルとして登録するように構成することで、
利用者は、サービス（用途）を指示するだけで、指示し
たサービスが格納されているサーバをアクセスすること
ができ、利用者がサーバを意識することなく、情報の分
散管理を行うことができる。
【００３０】
【実施例】以下本発明の実施例を図面によって詳述す
る。前述の図１〜図３は、本発明の原理説明図であり、
図４〜図７は、本発明の一実施例を示した図であって、
図４は、クライアントが、分散された情報を利用する場
合のアクセス方法を示し、図５，図６は、同じ情報が複
数個のサーバに重複して分散されている場合のアクセス
方法を示し、図５は、負荷テーブルを使用する場合を
示しており，図６は使用状況テーブルを使用する場合
を示しており、図７は、情報が複数のサーバのどれに登
録されているかを管理する格納先管理用サーバ 1a を設
けている場合のアクセス方法を示している。
る。前述の図１〜図３は、本発明の原理説明図であり、
図４〜図７は、本発明の一実施例を示した図であって、
図４は、クライアントが、分散された情報を利用する場
合のアクセス方法を示し、図５，図６は、同じ情報が複
数個のサーバに重複して分散されている場合のアクセス
方法を示し、図５は、負荷テーブルを使用する場合を
示しており，図６は使用状況テーブルを使用する場合
を示しており、図７は、情報が複数のサーバのどれに登
録されているかを管理する格納先管理用サーバ 1a を設
けている場合のアクセス方法を示している。
【００３１】本発明においては、複数個のサーバ 1を、
用途 (サービス) 別に分類 (グループ化) したサーバ情
報管理テーブルに基づいてサーバを選択する。このと
き、各サーバ 1毎の負荷テーブルを、クライアント
2, ルータ 4, サーバ 1のいずれかに設けて、最も負荷
の低いサーバ 1を選択したり、複数のサーバの記憶媒体
(ディスク, テープ等) の使用状況テーブルを、クラ
イアント 2, ルータ 4,サーバ 1のいずれかに設けて、
最も空き容量の多いサーバ 1を選択したり、用途別の情
報検索キーと、情報格納先のサーバＩＤを、格納先管理
用のサーバ 1a に検索キー・サーバＩＤテーブルとし
て登録しておき、利用者からのサービス要求に基づい
て、上記検索キー・サーバＩＤテーブルにより、サー
バを意識することなく、必要なサービスを利用できるよ
うにする手段が、本発明を実施するのに必要な手段であ
る。尚、全図を通して同じ符号は同じ対象物を示してい
る。
用途 (サービス) 別に分類 (グループ化) したサーバ情
報管理テーブルに基づいてサーバを選択する。このと
き、各サーバ 1毎の負荷テーブルを、クライアント
2, ルータ 4, サーバ 1のいずれかに設けて、最も負荷
の低いサーバ 1を選択したり、複数のサーバの記憶媒体
(ディスク, テープ等) の使用状況テーブルを、クラ
イアント 2, ルータ 4,サーバ 1のいずれかに設けて、
最も空き容量の多いサーバ 1を選択したり、用途別の情
報検索キーと、情報格納先のサーバＩＤを、格納先管理
用のサーバ 1a に検索キー・サーバＩＤテーブルとし
て登録しておき、利用者からのサービス要求に基づい
て、上記検索キー・サーバＩＤテーブルにより、サー
バを意識することなく、必要なサービスを利用できるよ
うにする手段が、本発明を実施するのに必要な手段であ
る。尚、全図を通して同じ符号は同じ対象物を示してい
る。
【００３２】以下、図１〜図３を参照しながら、図４〜
図７によって、本発明の分散型データベースの管理方法
を説明する。図１は、一般的な分散型データベースシス
テムの構成例を示しており、各クライアント(1) 〜 2か
らのサービス要求に基づいて、各サーバ(1) 〜 1がクラ
イアント(1) 〜 2の要求する情報を提供する。
図７によって、本発明の分散型データベースの管理方法
を説明する。図１は、一般的な分散型データベースシス
テムの構成例を示しており、各クライアント(1) 〜 2か
らのサービス要求に基づいて、各サーバ(1) 〜 1がクラ
イアント(1) 〜 2の要求する情報を提供する。
【００３３】本発明の分散型データベースシステムで
は、サーバ(1) 〜 1を用途別に分類したサーバ情報管理
テーブル (図２参照）を、例えば、各クライアント
(1) 〜 2, トランシーバ 5, ルータ 4のいずれかに持
ち、例えば、定期的に、或いは、クライアント(1) 〜 2
からサービス要求のあったときに、登録, 更新, 削除,
参照ができるようにし、クライアント(1) 〜 2から、サ
ービス要求があると、上記サーバ情報管理テーブルを
参照して、サーバＩＤを認識し、認識したサーバＩＤに
基づいて、該当のサーバ(1) 〜 1のネットワーク 3上の
アドレスを認識してアクセスすることで、利用者 (クラ
イアント) は、従来のように、サーバ(1) 〜 1を意識す
ることなく、容易に、所望のサーバ(1) 〜 1が持ってい
る情報を利用することができる。
は、サーバ(1) 〜 1を用途別に分類したサーバ情報管理
テーブル (図２参照）を、例えば、各クライアント
(1) 〜 2, トランシーバ 5, ルータ 4のいずれかに持
ち、例えば、定期的に、或いは、クライアント(1) 〜 2
からサービス要求のあったときに、登録, 更新, 削除,
参照ができるようにし、クライアント(1) 〜 2から、サ
ービス要求があると、上記サーバ情報管理テーブルを
参照して、サーバＩＤを認識し、認識したサーバＩＤに
基づいて、該当のサーバ(1) 〜 1のネットワーク 3上の
アドレスを認識してアクセスすることで、利用者 (クラ
イアント) は、従来のように、サーバ(1) 〜 1を意識す
ることなく、容易に、所望のサーバ(1) 〜 1が持ってい
る情報を利用することができる。
【００３４】このとき、本発明においては、各サーバ
(1) 〜 1毎の負荷テーブルとか、或いは、使用状況テ
ーブルを、例えば、上記各クライアント(1) 〜 2, ト
ランシーバ 5, ルータ 4のいずれかに備えておくこと
で、同一情報を複数のサーバ(1)〜 1で重複管理されて
いるとき、最も負荷の低いサーバ(1) 〜 1とか、情報の
記憶媒体の空きの多いサーバ(1) 〜 1を選択し、利用者
が意識することなく、負荷を分散を図ることができるよ
うにしている。
(1) 〜 1毎の負荷テーブルとか、或いは、使用状況テ
ーブルを、例えば、上記各クライアント(1) 〜 2, ト
ランシーバ 5, ルータ 4のいずれかに備えておくこと
で、同一情報を複数のサーバ(1)〜 1で重複管理されて
いるとき、最も負荷の低いサーバ(1) 〜 1とか、情報の
記憶媒体の空きの多いサーバ(1) 〜 1を選択し、利用者
が意識することなく、負荷を分散を図ることができるよ
うにしている。
【００３５】又、同一用途の情報を、複数個のサーバ
(1) 〜 1で分散管理する場合、前述の図１０に示されて
いるように、情報が格納されているサーバ(1) 〜 1の識
別子(ID)と、情報の検索キーの部分を、格納先管理用サ
ーバ 1a に登録するのが一般的である。
(1) 〜 1で分散管理する場合、前述の図１０に示されて
いるように、情報が格納されているサーバ(1) 〜 1の識
別子(ID)と、情報の検索キーの部分を、格納先管理用サ
ーバ 1a に登録するのが一般的である。
【００３６】然し、この従来方法では、クライアント
(1) 〜 2から、所定の検索キーに対応するサーバ(1) 〜
1をアクセスするのに、クライアント(1) 〜 2 は、先
ず、格納先管理用サーバ 1a を検索して、検索キーに対
応した格納先サーバＩＤを取得し、次に、格納先サーバ
(1) 〜 1 に対して所望の情報を要求する必要があり、
煩雑な操作 (２回操作）が必要となる問題があったが、
本発明においては、図７に示されているように、上記検
索キー・サーバＩＤテーブルを、用途（サービス）別
に構成して、格納先管理用サーバ 1a で管理する方法を
採ることにより、クライアント(1) 〜 2からの只１回の
サービス要求に基づいて、該サービスに対応する検索キ
ー・サーバＩＤテーブルが検索され、所望のサーバＩ
Ｄを認識して、該当のサーバ(1) 〜 1をアクセスできる
ようになる。
(1) 〜 2から、所定の検索キーに対応するサーバ(1) 〜
1をアクセスするのに、クライアント(1) 〜 2 は、先
ず、格納先管理用サーバ 1a を検索して、検索キーに対
応した格納先サーバＩＤを取得し、次に、格納先サーバ
(1) 〜 1 に対して所望の情報を要求する必要があり、
煩雑な操作 (２回操作）が必要となる問題があったが、
本発明においては、図７に示されているように、上記検
索キー・サーバＩＤテーブルを、用途（サービス）別
に構成して、格納先管理用サーバ 1a で管理する方法を
採ることにより、クライアント(1) 〜 2からの只１回の
サービス要求に基づいて、該サービスに対応する検索キ
ー・サーバＩＤテーブルが検索され、所望のサーバＩ
Ｄを認識して、該当のサーバ(1) 〜 1をアクセスできる
ようになる。
【００３７】又、上記の如く、同一用途の情報を分散管
理する場合、利用者からの情報提供があると、図３に示
されているように、上記サービス (用途) 毎のサーバ情
報管理テーブル, サーバ毎の負荷テーブル, 上記サ
ーバ毎の使用状況テーブルを参照して、負荷の少な
い、資源の空きの多いサーバ 1を選択して、上記提供さ
れた情報を格納し、そのときの、提供された情報に対応
した検索キーと、サーバＩＤとを、上記格納先管理サー
バ 1a に、用途（サービス）別に、上記検索キー・サー
バＩＤテーブルとして登録するように構成すること
で、利用者がサーバを意識することなく、情報の分散管
理を行うことができる。
理する場合、利用者からの情報提供があると、図３に示
されているように、上記サービス (用途) 毎のサーバ情
報管理テーブル, サーバ毎の負荷テーブル, 上記サ
ーバ毎の使用状況テーブルを参照して、負荷の少な
い、資源の空きの多いサーバ 1を選択して、上記提供さ
れた情報を格納し、そのときの、提供された情報に対応
した検索キーと、サーバＩＤとを、上記格納先管理サー
バ 1a に、用途（サービス）別に、上記検索キー・サー
バＩＤテーブルとして登録するように構成すること
で、利用者がサーバを意識することなく、情報の分散管
理を行うことができる。
【００３８】以下、図４〜図７に基づいて、更に、具体
的に説明する。図４は、複数個のサーバ(1) 〜 1を用途
別に分類したサーバ情報管理テーブル（図２参照）に
基づいて、サーバ(1) 〜 1が検索される例を示してい
る。
的に説明する。図４は、複数個のサーバ(1) 〜 1を用途
別に分類したサーバ情報管理テーブル（図２参照）に
基づいて、サーバ(1) 〜 1が検索される例を示してい
る。
【００３９】今、クライアント(1) 〜 2の利用者が、従
業員情報のサービスを要求すると、本発明においては、
例えば、各クライアント(1) 〜 2に設けられている、図
２に示されている本発明のサーバ情報管理テーブルが
参照され、対応するサーバ(1) がアクセスされる。従っ
て、データベースの利用者は、利用しようとするサービ
スのみを意識することで事足り、従来のように、必要と
する情報が格納されているサーバを意識する必要がなく
なり、容易にサービスを受けることができるようにな
る。
業員情報のサービスを要求すると、本発明においては、
例えば、各クライアント(1) 〜 2に設けられている、図
２に示されている本発明のサーバ情報管理テーブルが
参照され、対応するサーバ(1) がアクセスされる。従っ
て、データベースの利用者は、利用しようとするサービ
スのみを意識することで事足り、従来のように、必要と
する情報が格納されているサーバを意識する必要がなく
なり、容易にサービスを受けることができるようにな
る。
【００４０】更に、本発明においては、図５に示したよ
うに、各サーバ(1) 〜 2に掛かっている負荷を負荷テー
ブルとして、クライアント (利用者)(1)〜 2, ルータ
4,サーバ(1) 〜 1のいずれか, 又は、複数に設けるこ
とで、上記サーバ情報管理テーブルで選択されたサー
バ(1) 〜 1の中で、例えば、負荷の一番低いサーバ(1)
〜 1に対してサービスを要求することができる。
うに、各サーバ(1) 〜 2に掛かっている負荷を負荷テー
ブルとして、クライアント (利用者)(1)〜 2, ルータ
4,サーバ(1) 〜 1のいずれか, 又は、複数に設けるこ
とで、上記サーバ情報管理テーブルで選択されたサー
バ(1) 〜 1の中で、例えば、負荷の一番低いサーバ(1)
〜 1に対してサービスを要求することができる。
【００４１】各サーバ(1) 〜 1の負荷の計算方法として
は、例えば、同一の処理に掛かっている時間を計算し、
掛かっている時間の長いサーバ(1) 〜 1の負荷が重いと
するとか、処理パケット (通常、処理はパケットを単位
として行われるので、その要求パケット, 終了パケッ
ト) の数を計数することで、処理パケットの多いサーバ
(1) 〜 1の負荷が重いとする方法があるが、特に、限定
するものではない。
は、例えば、同一の処理に掛かっている時間を計算し、
掛かっている時間の長いサーバ(1) 〜 1の負荷が重いと
するとか、処理パケット (通常、処理はパケットを単位
として行われるので、その要求パケット, 終了パケッ
ト) の数を計数することで、処理パケットの多いサーバ
(1) 〜 1の負荷が重いとする方法があるが、特に、限定
するものではない。
【００４２】又、図６に示したように、各サーバ(1) 〜
1の持っている記憶媒体の使用状況テーブルを、クラ
イアント (利用者)(1)〜 2, ルータ 4, サーバ(1) 〜 1
のいずれか, 又は、複数に設けることで、上記サーバ情
報管理テーブルで選択されたサーバ(1) 〜 1の中で、
例えば、空き容量の多いサーバ(1) 〜 1に対して、情報
を登録したり、サービスを要求することができる。
1の持っている記憶媒体の使用状況テーブルを、クラ
イアント (利用者)(1)〜 2, ルータ 4, サーバ(1) 〜 1
のいずれか, 又は、複数に設けることで、上記サーバ情
報管理テーブルで選択されたサーバ(1) 〜 1の中で、
例えば、空き容量の多いサーバ(1) 〜 1に対して、情報
を登録したり、サービスを要求することができる。
【００４３】上記各サーバ(1) 〜 1の負荷, 空き容量を
判定するタイミングとしては、例えば、定期的に, 或い
は、クライアント(1) 〜 1から要求のあった時に行うよ
うにしてもよい。又、上記負荷テーブル, 使用状況テ
ーブルの更新タイミングも、上記定期的に, 或いは、
クライアント(1) 〜 1から要求のあった時に行うように
しても良い。
判定するタイミングとしては、例えば、定期的に, 或い
は、クライアント(1) 〜 1から要求のあった時に行うよ
うにしてもよい。又、上記負荷テーブル, 使用状況テ
ーブルの更新タイミングも、上記定期的に, 或いは、
クライアント(1) 〜 1から要求のあった時に行うように
しても良い。
【００４４】次に、図７によって、検索キー・サーバＩ
Ｄテーブルによるデータベースの管理方法を説明す
る。前述のように、同一用途の情報を複数のサーバ(1)
〜 1に分散して管理する場合、複数のサーバ(1) 〜 1を
意識することなく、登録, 検索ができることが望まし
い。
Ｄテーブルによるデータベースの管理方法を説明す
る。前述のように、同一用途の情報を複数のサーバ(1)
〜 1に分散して管理する場合、複数のサーバ(1) 〜 1を
意識することなく、登録, 検索ができることが望まし
い。
【００４５】そこで、本発明においては、クライアント
(1) 〜 2から、情報の提供があったとき、前述の図３で
説明したように、上記サーバ情報管理テーブル, 負荷
テーブル, 使用状況テーブルによって選択されたサ
ーバ(1) 〜 1に登録すると共に、格納先管理用サーバ 1
a では、検索キー・サーバＩＤテーブルをサービス
(用途) 毎に構成して管理するようにする。
(1) 〜 2から、情報の提供があったとき、前述の図３で
説明したように、上記サーバ情報管理テーブル, 負荷
テーブル, 使用状況テーブルによって選択されたサ
ーバ(1) 〜 1に登録すると共に、格納先管理用サーバ 1
a では、検索キー・サーバＩＤテーブルをサービス
(用途) 毎に構成して管理するようにする。
【００４６】このように構成することにより、利用者
は、サービスのみを指定するだけで、要求する情報が格
納されているサーバ(1) 〜 1を選択することができる。
又、サービス毎に管理する方法を用いたことにより、図
１０で説明した従来の格納先管理用サーバ 1a では管理
することができなかった複数のサービスを管理すること
ができるようになる。
は、サービスのみを指定するだけで、要求する情報が格
納されているサーバ(1) 〜 1を選択することができる。
又、サービス毎に管理する方法を用いたことにより、図
１０で説明した従来の格納先管理用サーバ 1a では管理
することができなかった複数のサービスを管理すること
ができるようになる。
【００４７】上記の実施例においては、分散型データベ
ースシステムを例にして説明したが、上記のサーバ情報
管理テーブル, 負荷テーブル, 使用状況テーブル
, 更に、検索キー・サーバＩＤテーブルと同等の各
テーブルを備えたクライアントシステム, ルーティング
システムであっても良いし、上記各テーブル〜を利
用したネットワークシステムとか、上記各テーブル〜
を用いたサーバの処理を入出力デバイスの制御に用い
た入出力制御方法であっても良い。
ースシステムを例にして説明したが、上記のサーバ情報
管理テーブル, 負荷テーブル, 使用状況テーブル
, 更に、検索キー・サーバＩＤテーブルと同等の各
テーブルを備えたクライアントシステム, ルーティング
システムであっても良いし、上記各テーブル〜を利
用したネットワークシステムとか、上記各テーブル〜
を用いたサーバの処理を入出力デバイスの制御に用い
た入出力制御方法であっても良い。
【００４８】このように、本発明は、分散型データベー
スの管理方法において、複数個のサーバを、用途 (サー
ビス) 別に分類 (グループ化) したサーバ情報管理テー
ブルに基づいてサーバを選択する。このとき、各サー
バ毎の負荷テーブルを設けて、最も負荷の低いサーバ
を選択したり、複数のサーバの記憶媒体 (ディスク,テ
ープ等) の使用状況テーブルを設けて、最も空き容量
の多いサーバを選択したり、情報検索キーと、情報格納
先のサーバＩＤを用途別に構成して、格納先管理用のサ
ーバに検索キー・サーバＩＤテーブルとして登録して
おき、利用者からの只１回のサービス要求に基づいて、
サーバを意識することなく、必要なサービスを利用でき
るようにしたところに特徴がある。
スの管理方法において、複数個のサーバを、用途 (サー
ビス) 別に分類 (グループ化) したサーバ情報管理テー
ブルに基づいてサーバを選択する。このとき、各サー
バ毎の負荷テーブルを設けて、最も負荷の低いサーバ
を選択したり、複数のサーバの記憶媒体 (ディスク,テ
ープ等) の使用状況テーブルを設けて、最も空き容量
の多いサーバを選択したり、情報検索キーと、情報格納
先のサーバＩＤを用途別に構成して、格納先管理用のサ
ーバに検索キー・サーバＩＤテーブルとして登録して
おき、利用者からの只１回のサービス要求に基づいて、
サーバを意識することなく、必要なサービスを利用でき
るようにしたところに特徴がある。
【００４９】
【発明の効果】以上、詳細に説明したように、本発明の
分散型データベース管理方法によれば、利用者は、サー
バを意識する必要がなく、単に、サービスだけを意識す
るだけで事足り、容易にサーバを利用することができ
る。又、負荷の低いサーバとか、空き容量の多いサーバ
を選択することにより、１台のサーバに負荷が集中する
ことがなくなり、利用者が意識することなく負荷が分散
し、効率のよいサービスが実現できる効果がある。
分散型データベース管理方法によれば、利用者は、サー
バを意識する必要がなく、単に、サービスだけを意識す
るだけで事足り、容易にサーバを利用することができ
る。又、負荷の低いサーバとか、空き容量の多いサーバ
を選択することにより、１台のサーバに負荷が集中する
ことがなくなり、利用者が意識することなく負荷が分散
し、効率のよいサービスが実現できる効果がある。
【図１】本発明の原理説明図（その１）
【図２】本発明の原理説明図（その２）
【図３】本発明の原理説明図（その３）
【図４】本発明の一実施例を示した図（その１）
【図５】本発明の一実施例を示した図（その２）
【図６】本発明の一実施例を示した図（その３）
【図７】本発明の一実施例を示した図（その４）
【図８】従来の分散型データベースの管理方法を説明す
る図（その１）
る図（その１）
【図９】従来の分散型データベースの管理方法を説明す
る図（その２）
る図（その２）
【図１０】従来の分散型データベースの管理方法を説明
する図（その３）
する図（その３）
1 サーバ, サーバ(1),(2),〜 1a 格納先管理用サーバ 2 クライアント, クライアント(1),(2),〜, 利用者
(1),(2),〜 3 ネットワーク 3a サブネッ
トワーク サーバ情報管理テーブル 負荷テーブル 使用状況テーブル 用途別の検索キー・サーバＩＤテーブル
(1),(2),〜 3 ネットワーク 3a サブネッ
トワーク サーバ情報管理テーブル 負荷テーブル 使用状況テーブル 用途別の検索キー・サーバＩＤテーブル
Claims (10)
- 【請求項１】分散型データベースの管理方法であって、 複数個のサーバ(1) を用途別にグループ化して分類した
サーバ情報管理テーブル () を設けて、 上記サーバ情報管理テーブル () を、定期的に、或い
は、クライアント(2)からサービス要求があったときに
登録, 更新, 削除, 参照し、 クライアント(2) からのサービス要求を基に、上記サー
バ情報管理テーブル () を参照したときの情報に基づ
いて、サーバ(1) を選択することを特徴とする分散型デ
ータベースの管理方法。 - 【請求項２】分散型データベースの管理方法であって、 複数のサーバ(1) 毎の負荷テーブル () を設けて、上
記負荷テーブル ()を、定期的に、或いは、クライア
ント(2) からのサービス要求があったときに更新し、 クライアント(2) からのサービス要求があって、上記サ
ーバ情報管理テーブル() を参照したときの情報に基
づいて、サーバ(1) を選択する際、上記サーバ(1) 毎の
負荷テーブル () を参照して、負荷の低いサーバ(1)
を選択することを特徴とする分散型データベースの管理
方法。 - 【請求項３】分散型データベースの管理方法であって、 複数のサーバ(1) 毎の使用状況テーブル（）を設け
て、上記使用状況テーブル（）を、定期的に、或い
は、クライアント(2) からのサービス要求があったとき
に更新し、 クライアント(2) からのサービス要求があって、上記サ
ーバ情報管理テーブル() を参照したときの情報に基
づいて、サーバ(1) を選択する際、上記サーバ(1) 毎の
使用状況テーブル () を参照して、空き容量の多いサ
ーバ(1) を選択することを特徴とする分散型データベー
スの管理方法。 - 【請求項４】分散型データベースの管理方法であって、 サービスを提供する複数のサーバ(1) を、サービス毎に
検索キーと, サーバＩＤとからなる検索キー・サーバＩ
Ｄテーブル（）を設けて、 上記検索キー・サーバＩＤテーブル（）を、所定の格
納先管理サーバ(1a)で管理することを特徴とする分散型
データベースの管理方法。 - 【請求項５】分散型データベースの管理方法であって、 利用者からの情報提供があったとき、上記サービス毎の
サーバ情報管理テーブル (),上記サーバ(1) 毎の負荷
テーブル (),上記サーバ(1) 毎の使用状況テーブル
() を参照して、負荷の少ない、資源の空きの多いサ
ーバ(1) を選択して、上記提供された情報を格納し、 そのときの、検索キーと、サーバＩＤとを、上記格納先
管理サーバ(1a)に、上記検索キー・サーバＩＤテーブル
（）として登録することを特徴とする分散型データベ
ースの管理方法。 - 【請求項６】上記請求項１〜５に記載の方法によって選
択されたサーバ(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 true JPH06259308A (ja) | 1994-09-16 |
| JP3598522B2 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) |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH10240662A (ja) * | 1997-02-27 | 1998-09-11 | Nippon Telegr & Teleph Corp <Ntt> | サーバ・クライアント型情報提供方法及びシステム |
| JPH10240684A (ja) * | 1997-02-27 | 1998-09-11 | Oki Electric Ind Co Ltd | 複数端末の制御方法 |
| JPH10254831A (ja) * | 1997-03-10 | 1998-09-25 | Oki Electric Ind Co Ltd | 複数端末の制御方法 |
| JPH10333964A (ja) * | 1997-05-30 | 1998-12-18 | Nec Corp | 分散ファイルシステム |
| JP2002024325A (ja) * | 2000-07-07 | 2002-01-25 | Takenaka Komuten Co Ltd | 建設支援方法 |
| JP2003186785A (ja) * | 2001-12-14 | 2003-07-04 | Sanyo Electric Co Ltd | ローカルサーバ、情報配信システムおよびユーザ端末装置 |
| JP2007510231A (ja) * | 2003-10-29 | 2007-04-19 | オラクル・インターナショナル・コーポレイション | データベースにおける空間使用の追跡 |
| US7305471B2 (en) * | 2000-04-14 | 2007-12-04 | Microsoft Corporation | Capacity planning for server resources |
| WO2010124024A3 (en) * | 2009-04-24 | 2011-01-20 | Microsoft Corporation | Dynamic placement of replica data |
| US7929550B2 (en) | 2003-07-09 | 2011-04-19 | Fujitsu Limited | Method for optimally routing specific service in network, and server and routing node used in the network |
| US8861801B2 (en) | 2011-06-06 | 2014-10-14 | Kabushiki Kaisha Toshiba | Facial image search system and facial image search method |
Citations (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
Patent Citations (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 | ファイル代行処理方式 |
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH10240684A (ja) * | 1997-02-27 | 1998-09-11 | Oki Electric Ind Co Ltd | 複数端末の制御方法 |
| JPH10240662A (ja) * | 1997-02-27 | 1998-09-11 | Nippon Telegr & Teleph Corp <Ntt> | サーバ・クライアント型情報提供方法及びシステム |
| JPH10254831A (ja) * | 1997-03-10 | 1998-09-25 | Oki Electric Ind Co Ltd | 複数端末の制御方法 |
| JPH10333964A (ja) * | 1997-05-30 | 1998-12-18 | Nec Corp | 分散ファイルシステム |
| US7305471B2 (en) * | 2000-04-14 | 2007-12-04 | 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 | ローカルサーバ、情報配信システムおよびユーザ端末装置 |
| US7929550B2 (en) | 2003-07-09 | 2011-04-19 | Fujitsu Limited | Method for optimally routing specific service in network, and server and routing node used in the network |
| JP2007510231A (ja) * | 2003-10-29 | 2007-04-19 | オラクル・インターナショナル・コーポレイション | データベースにおける空間使用の追跡 |
| WO2010124024A3 (en) * | 2009-04-24 | 2011-01-20 | Microsoft Corporation | Dynamic placement of replica data |
| CN102414692A (zh) * | 2009-04-24 | 2012-04-11 | 微软公司 | 副本数据的动态安置 |
| US8560639B2 (en) | 2009-04-24 | 2013-10-15 | Microsoft Corporation | Dynamic placement of replica data |
| US8861801B2 (en) | 2011-06-06 | 2014-10-14 | Kabushiki Kaisha Toshiba | Facial image search system and facial image search method |
Also Published As
| Publication number | Publication date |
|---|---|
| JP3598522B2 (ja) | 2004-12-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6832248B1 (en) | System and method for managing usage quotas | |
| US7035931B1 (en) | Volume location service for a distributed file system | |
| US6983322B1 (en) | System for discrete parallel processing of queries and updates | |
| US7237027B1 (en) | Scalable storage system | |
| US7664742B2 (en) | Index data structure for a peer-to-peer network | |
| US8676951B2 (en) | Traffic reduction method for distributed key-value store | |
| US7146377B2 (en) | Storage system having partitioned migratable metadata | |
| US20070299804A1 (en) | Method and system for federated resource discovery service in distributed systems | |
| US6363375B1 (en) | Classification tree based information retrieval scheme | |
| US7797392B2 (en) | System and method for efficiently supporting multiple native network protocol implementations in a single system | |
| US7657499B2 (en) | Grouping of computers in a computer information database system | |
| JPH06259308A (ja) | 分散型データベースの管理方法、及びシステム | |
| CN1326363C (zh) | 网络管理配置方法及其装置 | |
| US8285720B2 (en) | Grouping of computers in a computer information database system | |
| JPH04251346A (ja) | データ処理システムにおいて文書を階層的にグループ化する方法 | |
| JPH05241934A (ja) | 計算機システム | |
| JP2002116944A (ja) | メンバシップ管理方法 | |
| KR100295391B1 (ko) | 씨.에이.엘.에스 통합 데이터베이스를 위한 메타 데이터카탈로그 시스템 | |
| EP1787222A1 (en) | Method, system and computer program product for managing database records with attributes located in multiple databases | |
| JP3460622B2 (ja) | ネットワーク構成データベースの構築および検索方法 | |
| JP2001216308A (ja) | 文書管理システム | |
| JPH0235535A (ja) | ネットワーク間ファイル検索処理システム | |
| JP2000348063A (ja) | データベース管理方法およびシステム | |
| JP2003223344A (ja) | データベース管理方法 | |
| JP2000010842A (ja) | ファイル管理方法および方式 |
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 |