JP2020204802A - データ管理システムおよび方法 - Google Patents

データ管理システムおよび方法 Download PDF

Info

Publication number
JP2020204802A
JP2020204802A JP2019110823A JP2019110823A JP2020204802A JP 2020204802 A JP2020204802 A JP 2020204802A JP 2019110823 A JP2019110823 A JP 2019110823A JP 2019110823 A JP2019110823 A JP 2019110823A JP 2020204802 A JP2020204802 A JP 2020204802A
Authority
JP
Japan
Prior art keywords
data
request
request message
managed
server
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.)
Pending
Application number
JP2019110823A
Other languages
English (en)
Inventor
稔久 藤井
Toshihisa Fujii
稔久 藤井
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Azbil Corp
Original Assignee
Azbil Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Azbil Corp filed Critical Azbil Corp
Priority to JP2019110823A priority Critical patent/JP2020204802A/ja
Publication of JP2020204802A publication Critical patent/JP2020204802A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】管理側の情報とサーバーとを同期して管理する必要を無くすためのデータ管理システム及びデータ管理方法を提供する。【解決手段】データ管理システムは、データを記憶する複数のヒストリサーバー1−A〜1−Cと、ヒストリサーバー1−A〜1−Cを統括する統合管理部2と、を備える。統合管理部2は、クライアントからの要求内容を含む要求メッセージをヒストリサーバー1−A〜1−Cに同報送信する第1の送受信処理部20と、要求メッセージに対する各ヒストリサーバー1−A〜1−Cからの応答データの内容を統合した結果をクライアントに送信する第2の送受信処理部21と、を備える。各ヒストリサーバー1−A〜1−Cは、データを記憶するデータベース10と、受信した要求メッセージの要求内容に相当するデータを自装置のデータベース10内で管理しているときに、応答データを統合管理部2に送信する制御部14と、を備える。【選択図】図1

Description

本発明は、複数のサーバーにデータを分散して管理するデータ管理システムおよび方法に関するものである。
産業オートメーションの世界では従来よりも広範囲なデータ、1つ以上の製造現場と上位の経営側のアプリケーションとの情報連携など、を利用した解析により局所最適から全体最適に向けた動きがある。ヒストリデータのアクセスに関しては長期間に渡るデータにアクセスするケースが考えられ、そのデータ量は1つのヒストリサーバーで管理する量を超える場合がある。従来のように1つのヒストリサーバーが保持できるものを超える時間幅のデータを扱う場合には、つぎに挙げるような分断された作業を人手によって連結することが求められていた。
従来の技術では、1つのサーバーで管理できないデータを複数のサーバーに分散させて管理するようにしている(特許文献1、特許文献2参照)。
特許文献1、特許文献2に開示された技術では、分散しているサーバーに関する情報を一括して管理する必要があり、サーバーの追加や構成変更などが行われた場合には、管理側の情報も変更する必要がある。管理側の情報とサーバーとを同期して管理する必要がある為に操作ミスが発生し、正しいデータを抽出できないというミスが発生する可能性があった。
特許第4948276号広報 特開2001−265768号公報
本発明は、上記課題を解決するためになされたもので、サーバーの追加や削除、構成変更などが行われた場合でも、管理側の情報とサーバーとを同期して管理する必要を無くすことができるデータ管理システムおよび方法を提供することを目的とする。
本発明のデータ管理システムは、データを記憶する複数のサーバーと、前記複数のサーバーを統括する統合管理部とを備え、前記統合管理部は、クライアントからの要求内容を含む要求メッセージを前記複数のサーバーに同報送信するように構成された第1の送受信処理部と、前記要求メッセージに対する各サーバーからの応答データの内容を統合した結果を前記クライアントに送信するように構成された第2の送受信処理部とを備え、各サーバーは、データを記憶するように構成されたデータベースと、受信した要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、応答データを前記統合管理部に送信するように構成された制御部とを備えることを特徴とするものである。
また、本発明のデータ管理システムの1構成例において、前記クライアントからの要求内容は、特定のデータを要求するものであり、各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、管理しているデータとこのデータの期間の情報とを含む前記応答データを前記統合管理部に送信することを特徴とするものである。
また、本発明のデータ管理システムの1構成例において、前記クライアントからの要求内容は、特定のデータを管理しているかどうかの確認を要求するものであり、各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、管理しているデータの期間の情報を含む前記応答データを前記統合管理部に送信し、前記統合管理部の第2の送受信処理部は、前記応答データを送信したサーバーが管理しているデータの期間の情報とこのサーバーの識別情報とを対応付けた結果を前記クライアントに送信することを特徴とするものである。
また、本発明のデータ管理システムの1構成例において、各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理していないときに、データが無いことを示す前記応答データを前記統合管理部に送信することを特徴とするものである。
また、本発明のデータ管理方法は、クライアントからの要求内容を含む要求メッセージを、複数のサーバーを統括する統合管理部から前記複数のサーバーに同報送信する第1のステップと、前記複数のサーバーのそれぞれが、受信した要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理しているときに、応答データを前記統合管理部に送信する第2のステップと、前記統合管理部が、前記要求メッセージに対する各サーバーからの応答データの内容を統合した結果を前記クライアントに送信する第3のステップとを含むことを特徴とするものである。
本発明によれば、複数のサーバーに関する情報を統合管理部で管理する必要がなくなるので、サーバーの追加や削除、構成変更などが行われた場合でも、統合管理部には何の変更を加えることなく、その変更を反映した形で処理を継続することができる。その結果、本発明では、正しいデータを抽出できないというミスが発生する可能性を大幅に低減することができる。
図1は、本発明の第1の実施例に係るデータ管理システムの構成を示すブロック図である。 図2は、本発明の第1の実施例に係る統合管理部の動作を説明するフローチャートである。 図3は、本発明の第1の実施例に係るヒストリサーバーの動作を説明するフローチャートである。 図4は、本発明の第1の実施例に係るデータ管理システムの動作例を説明する図である。 図5は、本発明の第1の実施例に係るデータ管理システムの動作例を説明する図である。 図6は、本発明の第1の実施例に係るデータ管理システムの動作例を説明する図である。 図7は、本発明の第1の実施例に係るデータ管理システムの動作例を説明する図である。 図8は、本発明の第2の実施例に係る統合管理部の動作を説明するフローチャートである。 図9は、本発明の第2の実施例に係るヒストリサーバーの動作を説明するフローチャートである。 図10は、本発明の第2の実施例に係るデータ管理システムの動作例を説明する図である。 図11は、本発明の第2の実施例に係るデータ管理システムの動作例を説明する図である。 図12は、本発明の第2の実施例に係るデータ管理システムの動作例を説明する図である。 図13は、本発明の第2の実施例に係るデータ管理システムの動作例を説明する図である。 図14は、本発明の第1、第2の実施例に係るデータ管理システムを実現するコンピュータの構成例を示すブロック図である。
[第1の実施例]
以下、本発明の実施例について図面を参照して説明する。図1は本発明の第1の実施例に係るデータ管理システムの構成を示すブロック図である。データ管理システムは、時系列データを記憶する複数のヒストリサーバー1−A,1−B,1−Cと、複数のヒストリサーバー1−A〜1−Cを統括する統合管理部2と、クライアントの要求を受信する受信部3と、クライアントからの要求内容を含む要求メッセージをヒストリサーバー1−A〜1−Cに同報送信する送信部4と、ヒストリサーバー1−A〜1−Cからの応答データを受信する受信部5と、ヒストリサーバー1−A〜1−Cからの応答データの内容を統合した結果をクライアントに送信する送信部6とから構成される。
受信部3,5と送信部4,6とは、API(Application Programming Interface)のエンドポイント/エントリポイントのようにソフトウェアで実装されるものであってよいし、ネットワーク端末のようにハードウェアで実装されるものであってよい。
各ヒストリサーバー1−A〜1−Cは、それぞれ時系列データ(ヒストリデータ)を記憶するデータベース10と、時系列データに割り当てられた論理名と自装置内で管理している時系列データに割り当てられた内部アイテム名との対応表を記憶するデータベース11と、統合管理部2からの要求メッセージを受信する受信部12と、応答データを統合管理部2に送信する送信部13と、ヒストリサーバー全体を制御する制御部14とを備えている。
受信部12と送信部13とは、API(Application Programming Interface)のエンドポイント/エントリポイントのようにソフトウェアで実装されるものであってよいし、ネットワーク端末のようにハードウェアで実装されるものであってよい。
統合管理部2は、第1の送受信処理部20と、第2の送受信処理部21とを備えている。
図2は統合管理部2と受信部3,5と送信部4,6の動作を説明するフローチャート、図3は各ヒストリサーバー1−A〜1−Cの動作を説明するフローチャートである。図4〜図7はデータ管理システムの動作例を説明する図である。ただし、図4〜図7では、各ヒストリサーバー1−A〜1−Cの受信部12と送信部13と制御部14の記載を省略している。
本実施例では、時系列データの例として、装置X,Yの温度の時系列データをヒストリサーバー1−A〜1−Cに分散させて管理する例で説明する。
統合管理部2は、クライアント(ユーザ)の要求を受信する受信部3(エンドポイント)と、クライアントの要求をブロードキャストまたはマルチキャストで同報する送信部4(エントリポイント)と、要求の処理結果を受信する受信部5(エンドポイント)とを管理する。
個々のヒストリサーバー1−A〜1−Cは、起動すると、送信部4からブロードキャストまたはマルチキャストで通知されるメッセージの受信待ち状態になる。
統合管理部2の第1の送受信処理部20は、受信部3を通じて、クライアントの装置(不図示)からの要求を受信する(図2ステップS100)。
例えば図4の例では、装置X温度という論理名で特定されるアクセス対象の時系列データのうち、アクセス対象期間が2018年2月1日10時00分から2018年4月10日13時00分までのデータを求めるクライアントからの要求を受信している。
統合管理部2の第1の送受信処理部20は、クライアントからの要求を受信すると、クライアントからの要求内容と要求に対する処理結果の通知先(受信部5)の情報とを定義した要求メッセージRMを送信部4に送信する(図2ステップS101)。そして、統合管理部2は、要求に対する処理結果が受信部5に返信されるのを待つ。
例えば図5の例では、アクセス対象が装置X温度でアクセス対象期間が2018年2月1日10時00分から2018年4月10日13時00分まで、という要求内容と、処理結果の通知先の情報とを含む要求メッセージRMが送信部4に送信される。なお、図5の例では、受信部5をAPIのエンドポイントとし、このエンドポイントをepBとしている。
送信部4は、統合管理部2から受信した要求メッセージRMを、ブロードキャストで全てのヒストリサーバー1−A〜1−Cに送信するか、またはヒストリサーバー1−A〜1−Cのうち特定の複数のヒストリサーバーにマルチキャストで送信する(図2ステップS102)。
マルチキャストで送信する場合には、予め定められた複数のヒストリサーバーに要求メッセージRMを送信すればよい。あるいはクライアント側から所望のヒストリサーバーが物理的に存在している領域等を指定し、送信部4が、クライアントから指定された条件に合う複数のヒストリサーバーに要求メッセージRMを送信するようにしてもよい。
各ヒストリサーバー1−A〜1−Cの制御部14は、自装置内の受信部12を通じて、送信部4からの要求メッセージRMを受信すると(図3ステップS200においてYES)、受信した要求メッセージRMに含まれる要求内容に相当する時系列データを自装置内で管理しているかどうかを判定する(図3ステップS201)。
各ヒストリサーバー1−A〜1−Cは、それぞれ時系列データを記憶するデータベース10と、時系列データに割り当てられた論理名と各ヒストリサーバー1−A〜1−C内で管理している時系列データに割り当てられた内部アイテム名との対応表を記憶するデータベース11とを有している。例えば図1〜図5の例では、装置X温度という論理名に対応するヒストリサーバー1−A内の内部アイテム名は、TX100である。装置X温度という論理名に対応するヒストリサーバー1−B内の内部アイテム名は、X50_Tである。また、装置X温度という論理名に対応するヒストリサーバー1−C内の内部アイテム名は、X−20−Tである。
各ヒストリサーバー1−A〜1−Cの制御部14は、要求メッセージRMの要求内容に記述されたアクセス対象(論理名)とアクセス対象期間の少なくとも一部とに相当する時系列データを、自装置内のデータベース10に格納している場合(ステップS201においてYES)、この時系列データをデータベース10から取り出す。そして、制御部14は、データベース10から取り出した時系列データと、その時系列データの期間の情報とを含む応答データRDを、要求メッセージRMに記述された通知先に送信する(図3ステップS202)。
上記の図5の例では、要求メッセージRMは、アクセス対象が装置X温度でアクセス対象期間が2018年2月1日10時00分から2018年4月10日13時00分まで、という要求内容と、通知先の情報として受信部5(epB)の情報とを含んでいる。
このため、ヒストリサーバー1−Aの制御部14は、図6に示すように、装置X温度という論理名に対応するTX100という内部アイテム名が割り当てられた時系列データのうち、2018年2月1日10時00分から2018年3月31日23時59分までの期間の時系列データと、この期間の情報とを格納した応答データRD−Aを、通知先の受信部5に送信する。
同様に、ヒストリサーバー1−Bの制御部14は、図6に示すように、装置X温度という論理名に対応するX50_Tという内部アイテム名が割り当てられた時系列データのうち、2018年4月1日00時00分から2018年4月10日13時00分までの期間の時系列データと、この期間の情報とを格納した応答データRD−Bを、通知先の受信部5に送信する。
なお、要求メッセージの要求内容に相当する時系列データを自装置内に格納していないヒストリサーバーの制御部14は、データが無いことを示す応答データを通知先に返信するようにしてもよい。
統合管理部2の第2の送受信処理部21は、受信部5を通じて応答データRDを受信して、応答データRDの内容を取り出し(図2ステップS103)、クライアントから要求された全ての期間の時系列データが揃ったかどうかを判定する(図2ステップS104)。第2の送受信処理部21は、要求された全ての期間の時系列データが揃った時点で、各ヒストリサーバーから受信した応答データRDの内容を統合した応答データGDを、送信部6を通じてクライアントの装置に送信する(図2ステップS105)。
図7の例では、2018年2月1日10時00分から2018年4月10日13時00分までの期間の時系列データと、この期間の情報とを格納した応答データGDがクライアントに送信される。
以上のように、本実施例では、クライアントの要求をブロードキャストまたはマルチキャストで各ヒストリサーバーに同報送信する。統合管理部2は、各ヒストリサーバーが格納しているデータに関する情報を有しておらず、各ヒストリサーバー側で要求内容に相当する時系列データを自装置内に格納しているかどうかを判定する。
本実施例によれば、分散しているヒストリサーバーに関する情報を統合管理部2で管理する必要がなくなるので、ヒストリサーバーの追加や削除、構成変更などが行われた場合でも、統合管理部2には何の変更を加えることなく、その変更を反映した形で処理を継続することができる。
なお、統合管理部2と個々のヒストリサーバーとの通信プロトコルの方法には他にも応用が考えられる。例えば要求メッセージRMを受信した全てのヒストリサーバーが受信確認メッセージを返すことで、その時点で初めて統合管理部2は、今回の処理を行う可能性のあるヒストリサーバーとしてどのようなヒストリサーバーがあるかを確認することができる。そして、統合管理部2は、受信確認メッセージを返した全てのヒストリサーバーから何等かの応答があった時点で、処理終了と見なすことができる。要求メッセージの要求内容に相当する時系列データを自装置内に格納していないヒストリサーバーの制御部14は、データが無いことを示す応答データを統合管理部2に返信すればよい。
また、各ヒストリサーバー1−A〜1−Cのデータベース11で記憶している対応表に、時系列データの有効期間の情報を加えるようにしてもよい。
[第2の実施例]
次に、本発明の第2の実施例について説明する。本実施例においても、データ管理システムの構成は第1の実施例と同様であるので、図1の符号を用いて説明する。
ヒストリデータベースの分散化を設計するシステムエンジニアにとっては次の(I)〜(III)のようなことを検証できる手段があることが望ましい。なぜならば、システム運用上問題となるヒストリサーバーの構成になっているか否かを検証し、問題がある場合にはその構成を変更するという役割を担っているからである。
(I)過去に収集したデータが漏れなく何れかのヒストリサーバーに保存されているか。
(II)運用上の適切なヒストリサーバーにデータが保存されているか。
(III)ヒストリサーバーへのデータの分散化において過度の重複や過度のフラグメンテ―ションが発生していないか。
クライアント(システムエンジニア)は、自身が構築した分散構成が意図したとおりになっているかの評価を以下のように効率的に実施することができる。
図8は本実施例の統合管理部2と受信部3,5と送信部4,6の動作を説明するフローチャート、図9は本実施例の各ヒストリサーバー1−A〜1−Cの動作を説明するフローチャートである。図10〜図13はデータ管理システムの動作例を説明する図である。図4〜図7と同様に、図10〜図13では、各ヒストリサーバー1−A〜1−Cの受信部12と送信部13と制御部14の記載を省略している。
統合管理部2の第1の送受信処理部20は、受信部3を通じて、クライアント(システムエンジニア)からの要求を受信する(図8ステップS300)。
例えば図10の例では、装置X温度という論理名が割り当てられた時系列データを管理しているヒストリサーバーの構成情報を求めるクライアントからの要求を受信している。
統合管理部2の第1の送受信処理部20は、クライアントからの要求を受信すると、クライアントからの要求内容と要求に対する処理結果の通知先の情報とを定義した要求メッセージRMを送信部4に送信する(図8ステップS301)。
図11の例では、確認対象が装置X温度、という要求内容と、処理結果の通知先の情報とを含む要求メッセージRMが送信部4に送信される。
送信部4は、統合管理部2から受信した要求メッセージRMを、ブロードキャストで全てのヒストリサーバー1−A〜1−Cに送信するか、またはヒストリサーバー1−A〜1−Cのうち特定の複数のヒストリサーバーにマルチキャストで送信する(図8ステップS302)。
第1の実施例と同様に、マルチキャストで送信する場合には、予め定められた複数のヒストリサーバーに要求メッセージRMを送信すればよい。あるいは送信部4は、クライアントから指定された条件に合う複数のヒストリサーバーに要求メッセージRMを送信するようにしてもよい。
各ヒストリサーバー1−A〜1−Cの制御部14は、自装置内の受信部12を通じて、送信部4からの要求メッセージRMを受信すると(図9ステップS400においてYES)、受信した要求メッセージRMに含まれる要求内容に相当する時系列データを自装置内で管理しているかどうかを判定する(図9ステップS401)。
各ヒストリサーバー1−A〜1−Cの制御部14は、要求メッセージRMの要求内容に記述された確認内容(論理名)に相当する時系列データを、自装置内のデータベース10に格納している場合(ステップS401においてYES)、当該時系列データの期間の情報を含む応答データRDを、要求メッセージRMに記述された通知先に送信する(図9ステップS402)。
また、制御部14は、要求メッセージRMの要求内容に記述された確認内容に相当する時系列データを自装置内のデータベース10に格納していない場合、当該時系列データを管理していないことを示す応答データRDを、要求メッセージRMに記述された通知先に送信する(図9ステップS403)。
上記の図11の例では、要求メッセージRMは、確認対象が装置X温度、という要求内容と、通知先の情報として受信部5(epB)の情報とを含んでいる。
各ヒストリサーバー1−A〜1−Cの制御部14は、それぞれ装置X温度という論理名に対応するTX100,X50_T,X−20−Tという内部アイテム名が割り当てられた時系列データを管理しているので、指定された論理名の時系列データを管理していることを示すフラグと、この時系列データの期間の情報とを格納した応答データRD−A,RD−B,RD−Cを、通知先の受信部5に送信する(図12)。
統合管理部2の第2の送受信処理部21は、受信部5を通じて応答データRDを受信して、応答データRDの内容を取り出し(図8ステップS303)、全てのヒストリサーバーからの応答があったかどうかを判定する(図8ステップS304)。第2の送受信処理部21は、全てのヒストリサーバーからの応答が揃った時点で、各ヒストリサーバーから受信した応答データRDの内容を統合した応答データGDを、送信部6を通じてクライアントの装置に送信する(図8ステップS305)。
図13の例では、各ヒストリサーバー1−A〜1−Cの識別情報と、各ヒストリサーバー1−A〜1−Cが管理している時系列データの期間の情報とを対応付けた応答データGDがクライアントに送信される。
本実施例によれば、期待する論理名の時系列データを管理しているヒストリサーバーの構成情報取得が可能となる。その結果、システムエンジニアとしてのクライアントは、各ヒストリサーバーに対して個別にデータ存在の有無を検証するという煩雑な作業をすることなく、応答データGDが自身の期待する情報と同じであるかを確認することのみにより、分散構成が正しいかを評価することができる。
第1、第2の実施例では、時系列データアクセスの例で説明しているが、一般的なデータベースに本発明を適用することも可能である。一般的なデータベースにおいて、検索対象を管理するデータベースサーバーが分散して存在していても、データベースサーバーに関する情報を統合管理部2で管理する必要は無く、第1、第2の実施例と同様に分散データベースアクセスを実現することができる。
また、第1、第2の実施例では、複数のサーバーの例として、3つのサーバーを例に挙げて説明しているが、2つのサーバーでもよいし、3つ以上のサーバーであってもよい。
第1、第2の実施例で説明した統合管理部2と受信部3,5と送信部4,6とは、CPU(Central Processing Unit)、記憶装置及びインターフェースを備えたコンピュータと、これらのハードウェア資源を制御するプログラムによって実現することができる。このコンピュータの構成例を図14に示す。コンピュータは、CPU200と、記憶装置201と、インターフェース装置(以下、I/Fと略する)202とを備えている。I/F202には、通信回路等が接続される。このようなコンピュータにおいて、本発明のデータ管理方法を実現させるためのプログラムは記憶装置201に格納される。CPU200は、記憶装置201に格納されたプログラムに従って第1、第2の実施例で説明した処理を実行する。また、各ヒストリサーバー1−A〜1−Cについても、周知のとおりコンピュータとプログラムによって実現することができる。
本発明は、大量のデータを扱う技術に適用することができる。
1−A〜1−C…ヒストリサーバー、2…統合管理部、3,5,12…受信部、4,6,13…送信部、10,11…データベース、14…制御部、20…第1の送受信処理部、21…第2の送受信処理部。

Claims (8)

  1. データを記憶する複数のサーバーと、
    前記複数のサーバーを統括する統合管理部とを備え、
    前記統合管理部は、
    クライアントからの要求内容を含む要求メッセージを前記複数のサーバーに同報送信するように構成された第1の送受信処理部と、
    前記要求メッセージに対する各サーバーからの応答データの内容を統合した結果を前記クライアントに送信するように構成された第2の送受信処理部とを備え、
    各サーバーは、
    データを記憶するように構成されたデータベースと、
    受信した要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、応答データを前記統合管理部に送信するように構成された制御部とを備えることを特徴とするデータ管理システム。
  2. 請求項1記載のデータ管理システムにおいて、
    前記クライアントからの要求内容は、特定のデータを要求するものであり、
    各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、管理しているデータとこのデータの期間の情報とを含む前記応答データを前記統合管理部に送信することを特徴とするデータ管理システム。
  3. 請求項1記載のデータ管理システムにおいて、
    前記クライアントからの要求内容は、特定のデータを管理しているかどうかの確認を要求するものであり、
    各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、管理しているデータの期間の情報を含む前記応答データを前記統合管理部に送信し、
    前記統合管理部の第2の送受信処理部は、前記応答データを送信したサーバーが管理しているデータの期間の情報とこのサーバーの識別情報とを対応付けた結果を前記クライアントに送信することを特徴とするデータ管理システム。
  4. 請求項2または3記載のデータ管理システムにおいて、
    各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理していないときに、データが無いことを示す前記応答データを前記統合管理部に送信することを特徴とするデータ管理システム。
  5. クライアントからの要求内容を含む要求メッセージを、複数のサーバーを統括する統合管理部から前記複数のサーバーに同報送信する第1のステップと、
    前記複数のサーバーのそれぞれが、受信した要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理しているときに、応答データを前記統合管理部に送信する第2のステップと、
    前記統合管理部が、前記要求メッセージに対する各サーバーからの応答データの内容を統合した結果を前記クライアントに送信する第3のステップとを含むことを特徴とするデータ管理方法。
  6. 請求項5記載のデータ管理方法において、
    前記クライアントからの要求内容は、特定のデータを要求するものであり、
    前記第2のステップは、前記要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理しているときに、管理しているデータとこのデータの期間の情報とを含む前記応答データを前記統合管理部に送信するステップを含むことを特徴とするデータ管理方法。
  7. 請求項5記載のデータ管理方法において、
    前記クライアントからの要求内容は、特定のデータを管理しているかどうかの確認を要求するものであり、
    前記第2のステップは、前記要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理しているときに、管理しているデータの期間の情報を含む前記応答データを前記統合管理部に送信するステップを含み、
    前記第3のステップは、前記応答データを送信したサーバーが管理しているデータの期間の情報とこのサーバーの識別情報とを対応付けた結果を前記クライアントに送信するステップを含むことを特徴とするデータ管理方法。
  8. 請求項6または7記載のデータ管理方法において、
    前記第2のステップは、前記要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理していないときに、データが無いことを示す前記応答データを前記統合管理部に送信するステップを含むことを特徴とするデータ管理方法。
JP2019110823A 2019-06-14 2019-06-14 データ管理システムおよび方法 Pending JP2020204802A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2019110823A JP2020204802A (ja) 2019-06-14 2019-06-14 データ管理システムおよび方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2019110823A JP2020204802A (ja) 2019-06-14 2019-06-14 データ管理システムおよび方法

Publications (1)

Publication Number Publication Date
JP2020204802A true JP2020204802A (ja) 2020-12-24

Family

ID=73838391

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019110823A Pending JP2020204802A (ja) 2019-06-14 2019-06-14 データ管理システムおよび方法

Country Status (1)

Country Link
JP (1) JP2020204802A (ja)

Similar Documents

Publication Publication Date Title
US11943312B2 (en) Custom reference tag for versioning
CN107295080B (zh) 应用于分布式服务器集群的数据存储方法和服务器
KR102004160B1 (ko) 사물인터넷 환경에서 클라이언트 식별자를 이용하여 클라이언트 노드들을 논리적으로 그룹화하는 장치 및 방법
US10959089B2 (en) Data management microservice in a microservice domain
US9069835B2 (en) Organizing data in a distributed storage system
CN101383839A (zh) 基于数据服务器的数据分发系统及其实现方法
JP2005050165A (ja) 分散ストレージ装置のファイル管理方法及び分散ストレージシステム
US7590618B2 (en) System and method for providing location profile data for network nodes
KR20170121911A (ko) P2P를 이용한 IoT 기기의 펌웨어 업데이트 방법 및 그 장치
JP4548146B2 (ja) 状態管理装置および方法およびプログラム
CN101675424A (zh) 用于可扩展和冗余电信系统的进程间通信方法和装置
CN105373563A (zh) 数据库切换方法及装置
JP2020204802A (ja) データ管理システムおよび方法
KR101696911B1 (ko) 분산 데이터 베이스 장치 및 그 장치에서의 스트림 데이터 처리 방법
CN117043762A (zh) 用于交换和管理存储在异构数据源中的数据的系统和方法
US20110264763A1 (en) Method for retrieving object from device management client and associated device management system
JP2009245118A (ja) アプリケーションサービス提供システム、及び方法、並びにアプリケーション移行方法
CN114827283B (zh) 资源访问方法、装置、介质及机器人
JP5394329B2 (ja) センサクライアント装置、アプリケーションクライアント装置、センサ情報転送システム、コマンド情報受信方法、コマンド情報登録方法、センサ情報転送方法
JP2009251890A (ja) サーバ監視システム及びサーバ監視方法
JP2003195938A (ja) 分散型制御システム及びその制御装置並びにプログラム
CN118368275A (zh) 服务器的确定方法、装置、系统及计算机可读存储介质
WO2011093492A1 (ja) イベント配信システム、イベント配信ネットワーク、イベント配信ノード、イベント配信方法、及び、コンピュータ読み取り可能な記録媒体
CN111061746A (zh) 商家管理设备系统及运行方法
CN117014450A (zh) 一种基于区块链的数据处理方法及相关产品