WO2013069073A1 - 時系列データ管理システム、装置および方法 - Google Patents

時系列データ管理システム、装置および方法 Download PDF

Info

Publication number
WO2013069073A1
WO2013069073A1 PCT/JP2011/075545 JP2011075545W WO2013069073A1 WO 2013069073 A1 WO2013069073 A1 WO 2013069073A1 JP 2011075545 W JP2011075545 W JP 2011075545W WO 2013069073 A1 WO2013069073 A1 WO 2013069073A1
Authority
WO
WIPO (PCT)
Prior art keywords
time
series data
processing
data
correction
Prior art date
Application number
PCT/JP2011/075545
Other languages
English (en)
French (fr)
Inventor
直弘 湯浅
博文 橋本
Original Assignee
株式会社日立製作所
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 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2011/075545 priority Critical patent/WO2013069073A1/ja
Publication of WO2013069073A1 publication Critical patent/WO2013069073A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C3/00—Registering or indicating the condition or the working of machines or other apparatus, other than vehicles

Definitions

  • the missing value is corrected by numerical calculation. Specifically, a means for collecting values measured by a sensor or the like and storing them in a database, a means for detecting missing values, and a deficit for calculating correction data by a predetermined process for each pattern for correcting missing values The deficiency is corrected by the data correction means.
  • a processing device that corrects defects detects defects generated in a plurality of patterns, performs correction processing on each of the defects, and stores them in a database.
  • the time-series data management system of the present invention measures a value that changes in time series such as energy and temperature by a sensor or the like, and collects time-series data collecting means collected by a data center, and the measured time-series data in a data center or the like.
  • the acquisition request reception means for receiving a plurality of time series data acquisition requests requested from the reference application, and the time series data acquisition request from the reference application.
  • the distributed environment for the time-series data storage processing and correction processing is used.
  • the present invention when managing time-series data such as energy information, an increase in data capacity due to correction of time-series data required by the reference application is suppressed.
  • the processing load for correcting the data to the series data can be reduced.
  • the system block diagram regarding embodiment of the basic form of this invention is shown. It is a sequence diagram of the registration process of time series data. It is an example of the data model registered into a database. It is a sequence diagram of the reference processing of time series data. It is an example of the data model which correct
  • the system block diagram regarding embodiment of the distributed processing of this invention is shown. It is an example of the data model registered into a distributed database. It is a structural example (interpolation of missing data) of the data model of a distributed database. It is a structural example (interpolation of missing data) of the data model of a distributed database. It is a structural example (interpolation of missing data) of the data model of a distributed database. It is a structural example (data merge result) of the data model of a distributed database. It is a sequence diagram of a reference process in a distributed type of time series data.
  • FIG. 1 is a system configuration diagram related to the basic embodiment.
  • each base that measures energy time series data
  • each base (client PC) where an application that refers to time series data is installed is a data center in which a server that manages time series data is installed. Connected via a network.
  • the control device 1040 performs control for starting measurement, control for changing the measurement interval, and the like for the “measuring instrument 1” 1010 and the “measuring instrument 2” 1020, and also transmits time series data to the data processing server 1100.
  • a communication unit 1042 for transmission is provided.
  • the communication unit 1042 can improve the throughput of the communication path by transmitting a plurality of time-series data collected at a certain time interval, instead of transmitting the time-series data one by one.
  • the control device 1040 targets “measurement instrument 1” 1010 and “measurement instrument 2” 1020, the correspondence between the measurement instrument and the control instrument can be freely changed.
  • the data center 1000 will be described.
  • the data center 1000 includes a data processing server 1100 that performs time-series data storage and correction processing according to the present invention and a database 1140 that can store time-series data.
  • the data processing server 1100 includes a communication unit 1110 that receives time-series data from the control device 1040 and the control device 1050, a calculation unit 1120 that stores, acquires, and corrects time-series data in the database 1140, and a value acquired from the database. And a storage unit 1130 storing APIs 1131 to 1133 for performing various corrections when a reference application described later acquires time-series data.
  • the calculation unit 1120 includes a registration process 1121 for registering time-series data in the database 1140, a reference process 1122 acquired from the database 1140, and a correction process 1123 for correcting the acquired time-series data to necessary data.
  • “Client PC A” 1210, “Client PC B” 1220, and “Client PC C” 1230 are installed at the base where the application for referring to the time series data is installed.
  • a “reference application A” 1211 that acquires time-series data from the data processing server 1100 is installed in the “client PC A” 1210.
  • “Client PC B” 1220 and “Client PC C” 1230 are also equipped with “Reference Application B” 1221 and “Reference Application C” 1231.
  • a plurality of reference applications may be installed in the client PC.
  • three types of reference applications are taken as an example, but the number is not limited.
  • the overall processing flow of the present invention will be described.
  • the entire processing flow is roughly divided into a registration process and a reference process.
  • time series data is measured by a sensor or the like, and the measured time series data is registered and stored in a database.
  • correction processing according to necessity is performed from time-series data stored in the database for each reference request, and the result is returned to the reference application.
  • the registration process and the reference process are independent processes, and time-series data may not be registered at the time of reference.
  • the measuring instrument 1 (1010) measures time-series data at a designated time interval by the measuring unit 1011 (S1001).
  • the type of time-series data to be measured such as temperature, humidity, energy amount, etc. is determined in advance for each measuring instrument.
  • the measurement time interval is set and determined in advance by the specification of the measuring instrument or the control device.
  • the measured values are a measurement instrument ID, a measurement time, and a measurement value.
  • the measuring instrument 1 (1010) transmits the measured time series data to the control device 1040 connected by the communication unit 1012 (S1002). Measurement (S1001) and transmission (S1002) of time series data are repeatedly performed every time the measuring instrument measures.
  • the communication unit 1110 of the data processing server 1100 receives the time series data and issues a request for registration processing to the arithmetic unit 1120 (S1006).
  • the registration process 1121 of the calculation unit 1120 converts the time series data into a storage format for registering in the database (S1007). This is because the registration method and the registration format differ depending on the database to be registered, and therefore it is necessary to convert to a format registered in each database. Thereafter, the registration process 1121 requests the database 1140 to register the value corrected to the storage format, and the time series data is stored in the database 1140 (S1008).
  • the registration process is not performed. However, when measurement is performed by the measuring instrument 1 (1010) but only the measurement value is not detected, the measurement value is treated as “null” and registered in the database.
  • a measuring instrument 1 (1010) whose measuring instrument ID is “1” is connected to an electrical device, and a measured value “10”, which is an energy amount at 10:10:10 on October 10, 2011. 10 "is measured (S1001).
  • This measuring instrument is designed to perform measurement once a second.
  • the measured time-series data is transmitted to the control device 1040 (S1002), and the control device receives the time-series data (S1003), corrects it to the character string “1, 20101010_101010, 10” (S1004), and transmits it to the data processing server. (S1005).
  • the data processing server 1100 receives the character string (S1006) and converts the time series data into a format registered in the database (S1007).
  • the database is registered in a table having a table name “SENSOR_LOG” in the relational database, and is corrected to the SQL format “INSERT INTO SENSER_LOG VALUES (1,20101010_1010,10)”.
  • the SQL is requested from the database (S1008).
  • construction of database tables and connection settings have been completed in advance. The above registration process is repeatedly performed at a fixed timing.
  • FIG. 3 shows “SENSOR_LOG” 2000 of the relational database.
  • the column includes “measurement instrument ID 2001” for uniquely identifying a measurement instrument, “time” 2002 that is a measurement time, and “value” 2003 that is a measurement value, and one record indicates one time-series data. Yes.
  • the measurement times “20101010_101010”, “20101010_101101”, and “20101010_101013” of the measuring instrument 1 per second, and the measurement times “20101010_101014” and “20101010_101015” of the measuring instrument 2 are displayed. "Is stored.
  • the “client PC A” 1210 includes a reference application A1211 that obtains time-series data from the data processing server 1100 and issues a warning when the amount of energy exceeds.
  • the time-series data necessary for the reference application is a value measured by the measuring instrument 1 (instrument ID is 1) at intervals of one second.
  • instrument ID is 1
  • the time range of the time series data necessary for issuing a warning when the amount of energy exceeds a preset amount within 3 seconds is 3 seconds. If there is no time-series data for 3 seconds, a warning based on correct determination cannot be performed. Therefore, it is necessary to correct the time-series data, and the previous value is corrected.
  • the flow of the reference process 1122 will be described with reference to FIG.
  • the reference application A1211 calls an API for acquiring time series data to the data processing server 1100 (S2001).
  • the communication unit 1110 of the data processing server 1100 receives an acquisition request (S2002).
  • the reference processing 1122 that performs the reference processing performs thread processing (S2003).
  • the reference processing 1122 searches for data that matches the API 1131 corresponding to the time-series data acquisition request received by the storage unit 1130, and inputs the data acquisition request to the database 1140 (S2004).
  • the database 1140 passes the time series data that matches the data acquisition request to the reference process 1122 (S2004).
  • time series data is held and stored in the storage area 1134 of the storage unit 1130 (S2005).
  • a process for detecting data (missing data) that requires an API is performed on the stored time-series data (S2006). If a lack of data is found in step S2006, correction processing (interpolation processing) is performed (S2007).
  • the reference application A1211 calls an API 1131 that performs the previous value correction in units of seconds provided by the data processing server 1100.
  • a calling method a connection is established with the data processing server 1100 and “getSecondRatePreData (sensorID, startDate, endDate)” which is a calling name of the API 1131 is designated.
  • API 1131 specifies the instrument ID (sensorID) as the first argument, the time range start condition (startDate) as the second argument, and the time range end condition (endDate) as the third argument as arguments. .
  • the reference application calls the data processing server 1100 by specifying the measuring instrument “1”, the time range start condition “20101010_1010”, and the time range end condition “20101010_101012” as arguments of the API 1131 in order to acquire time series data as requirements. (S2001).
  • the data processing server 1100 receives a time-series data acquisition request from the reference application A 1211 (S2002), and the calculation unit 1120 starts a reference processing thread (reference processing 1122) and sends a data acquisition request to the database 1140 (S2003).
  • the time series data shown in FIG. 3 is acquired from the database 1140 (S2004).
  • the acquired time series data is held in the storage area 1134 of the storage unit 1130 (S2005).
  • the time column 2002 includes two records “20101010_101010” and “20101010_101101” corresponding to the specified time range, and the request is in seconds. It is determined that the record “20101010_101012” is insufficient (S2006).
  • the record determined to be short of record has the value “20101010_101012” in the column of time 2002, and the data “20” of the value 2003 of the record “20101010_101011” in which the value of time 2002 is one second before this value. It can be seen that this is the previous value used for correction (S2007). Thereafter, the time series data interpolated by the above-mentioned missing record is transmitted to the reference application A1211.
  • FIG. 5 shows an example of values corrected for time-series data.
  • FIG. 5 shows time-series data 3000 that can be acquired by the reference application A1211 by correcting the time-series data that is lacking by the processing of the data processing server after the API 1131 is called.
  • the column configuration is the same as in FIG. 3, and the missing record 3001 has the column value of “time” 3002 “20101010_101012” and the column value of “value” 3003 is corrected to “20”. .
  • an API for time series data to be acquired by a reference application is selected by a call name as in step S2001.
  • processing that can be performed differs for each defined processing, and it is possible to realize correction processing that matches time-series data to requests such as seconds, minutes, and hours.
  • the reference application can acquire time-series data that is not stored in the database. In this case, the reference application does not need to manage the data storage state.
  • a method such as a previous value, an average value, or a maximum value can be dynamically applied.
  • the reference application A and the reference application B call an API that refers to time-series data.
  • the reference application A uses “getSecondRatePreData (sensorID, startDate, endDate)” as an argument at 10:10:10 on Nov. 10, 2010 and the time range start condition “201010_101010” and the time range end condition “ “20101012_101010” is specified to call the API, and the reference application B also specifies the API with the same API as an argument at the same time by specifying the measuring instrument "1", the time range start condition "20101011_000000”, and the time range end condition "20101013_101010” call.
  • the time range “20101011_000000” to “20101011_235959” is the first time-series data
  • “20101012_000000” to “20101012_235959” is the second time-series data
  • “20101013_000000” to “20101013_1010” is the third.
  • the time series data is divided into the time series data.
  • the reference applications A and B process time-series data in the same time range “20101011_000000” to “20101011_235959”, the processing for the second time-series data that is a request from the reference application A and the reference application B It is determined that the processing for the first time-series data, which is a request for, is duplicated.
  • time-series data when time-series data is not updated frequently, it may be determined that it is a duplicate process if it is not “same API call time” but “same API” and “API call time within 10 seconds”. Is done.
  • the API “getSecondRatePreData (sensorID, startDate, endDate)” the measuring instrument, the time range start condition, and the time range end condition are specified as arguments in the above embodiment.

Abstract

　エネルギーや温度など時系列で変化する値をセンサ等により細かな分解能で計測、データセンタで収集管理するシステムに関わる。エネルギー量や温度等の時系列で変化する値を計測し、収集、管理する時系列データ管理システムは、少なくとも一つの計測器が計測した値をサーバで受信しデータベース等のデータを管理し、受信した時系列データに対して演算をせずに格納し、複数の参照アプリケーションによって時系列データを取得する要求の際に、保持されている時系列データに対して参照アプリケーションの要求により補正する対象と補正する方法を指定した補正処理を実施した時系列データを取得する。

Description

時系列データ管理システム、装置および方法
　エネルギーや温度など時系列で変化する値をセンサ等により細かな分解能で計測し、データセンタで収集管理するシステムに関わる。
　近年、エネルギーや温度などの時系列で変化する値（時系列データ）を管理するシステムのニーズが高まっている。例えば、発電機や家電機器のエネルギー量をリアルタイムで監視し、消費しているエネルギー量を可視化するシステムや契約電力量を超過させないために家電機器などを制御し消費電力を低下させるシステムなどである。
　これらのシステムではエネルギー量等を計測する機器の故障、時系列データをサーバに送信する際のネットワーク障害、計測する機器が電池で稼働する場合に電力消費を抑制するために計測間隔を長くする場合など様々な理由により、データが欠けてしまう欠損や、計測数が少ない状態となってサンプリング数不足が発生してしまう可能性がある。上記のような時系列データを活用するシステムにおいて、時系列データの状態により、時として、機器の制御や時系列の傾向の解析などが実施できなくなる等の影響がある。
　特許文献１に記載の技術では、上記課題を解決するために、欠損値を数値計算によって補正する。具体的には、センサ等によって計測された値を収集しデータベースに格納する手段と、欠損値を検出する手段と、欠損値を補正するパターンごとにあらかじめ定められた処理によって補正データを算出する欠損データ補正手段によって欠損を補正する。
　特許文献２に記載の技術でも、上記課題を解決するために、サンプリング数の不足を数値計算によって補正する。具体的には、第一の計測器において計測されなかった時系列データを予測するために、第一の計測器の時系列データと相関がある第二の計測器によって、第一の計測器において計測されなかった値を予測する予測式を生成する手段と、予測式から補正処理によって時系列データを補正する予測値演算手段によってサンプリング数が不足したデータを予測する。
特開２０１０－１８１９８２号公報 特開２００８－２０６５７５号公報
　上記特許文献１に記載の技術によれば、欠損を補正する処理装置が、複数のパターンで発生する欠損を検出し、それぞれに対する補正処理を実施した後にデータベースに格納している。
　しかし、同じ時系列データが複数の参照アプリケーションから取得される場合には、補正するパターンが増えるに従ってそれぞれに補正した時系列データを保持する必要があり補正データの容量が増える。例えば、ソーラー発電を設置した家庭において、一定間隔で計測した発電及び消費したエネルギーの情報を家庭向けのディスプレイに可視化する際に、欠損値があれば前回計測した値によって補正した1分間隔の時系列データを表示させるアプリケーションと、発電量を電力会社に売電する際の報告書を作成する際に、欠損値があれば平均値によって補正した1日単位の時系列データを対象とする参照アプリケーションがあるとする。上記アプリケーションでは複数の要求が想定され、各補正するパターンを補正するためには欠損値に対して各要求に適合した補正を実施し、補正を適用した値ごとにデータベースに格納するためデータ容量が増加する。
　上記特許文献２に記載の技術によれば、サンプリング数不足である時系列データを補正するために、データ参照時にその時系列データと相関があるデータをデータベースから取得し、関連する計測器の値から必要なデータを予測し補正を実施している。この手法はアプリケーションがデータを参照する際に補正しており、補正した値をデータベースに格納していないため補正パターンごとにデータ容量が増加することはない。しかし、参照アプリケーション側で必要なデータの有無やサンプリング数などのデータの状態を把握して、要求された補正方法を実施すると、参照アプリケーション側の負荷となる場合がある。
　そこで本発明の目的は、時系列で計測された値が、参照アプリケーションにおいて必要なデータ数に達していない場合に補正を行なう際に、複数の補正要求のパターンがある場合でもデータベースのデータ容量を補正のたびに増加させず、また、参照アプリケーションが時系列データを取得する場合に、補正処理に関わる処理負荷を軽減させる時系列データ管理システムを提供することにある。
　本発明の時系列データ管理システムは、エネルギーや温度などの時系列で変化する値をセンサ等によって計測し、データセンタが収集する時系列データ収集手段と、計測した時系列データをデータセンタ等のデータベースに格納する時系列データ格納手段と、参照アプリケーションから要求される複数の時系列データの取得要求を受け付ける取得要求受付手段と、参照アプリケーションからの時系列データの取得要求の際に、要求された条件の時系列データをデータベースから検索する手段と、検索した時系列データに複数の補正要求のパターンに該当する場合に時系列データを補正する時系列データ補正手段とを備える。
　また、本発明の時系列データ管理システムでは、参照アプリケーションが必要な時系列データに補正する際に補正処理が処理負荷となる場合には、時系列データの格納処理及び補正処理に対して分散環境による構成で負荷分散を実施する。
　その他、本願が開示する課題、及びその解決手段は、発明を実施するための形態の欄、及び図面により明らかになる。
　本発明によれば、エネルギー情報等の時系列データを管理する際に、参照アプリケーションが必要な時系列データを補正することによるデータ容量の増加を抑止するので、データ参照時に参照アプリケーション側が要求した時系列データにデータを補正するための処理の負荷を軽減できる。
本発明の基本形の実施形態に関するシステム構成図を示す。 時系列データの登録処理のシーケンス図である。 データベースに登録するデータモデルの一例である。 時系列データの参照処理のシーケンス図である。 時系列データを補正したデータモデルの一例である。 本発明の分散処理の実施形態に関するシステム構成図を示す。 分散型データベースに登録するデータモデルの一例である。 分散型データベースのデータモデルの構成例（欠損データの補間）である。 分散型データベースのデータモデルの構成例（欠損データの補間）である。 分散型データベースのデータモデルの構成例（欠損データの補間）である。 分散型データベースのデータモデルの構成例（データのマージ結果）である。 時系列データの分散型における参照処理のシーケンス図である。
　以下、図面を参照しつつ、本発明を実施するための最良の形態について説明する。
　＜第一の実施形態＞
　第一の実施形態では、計測器がエネルギー量を秒単位で計測し、その時系列データをデータセンタのデータベースで格納する。さらにデータベースに格納された時系列データを参照アプリケーションが取得要求をする際に、計測器の個別番号と時刻範囲を指定する。また、取得要求においては、取得したい時系列データの時刻の分解能と補正方法が定義されたＡＰＩ(Application Program Interface)を呼び出すこととする。
　図１は、基本の実施形態に関わるシステム構成図である。このシステムでは、エネルギー量（時系列データ）を計測する各拠点、及び時系列データを参照するアプリケーションを設置した拠点（クライアントＰＣ）のそれぞれが、時系列データを管理するサーバが設置されたデータセンタを経由してネットワークで接続されている。
　エネルギー量を計測する拠点では、電気機器のエネルギー量を計測する「計測器１」１０１０、「計測器２」１０２０、「計測器３」１０３０が電気機器ごとにそれぞれ設置されている。ただし、計測器は計測する点数分だけ設置できるため、計測器の設置数に制限はない。「計測器１」１０１０では、エネルギー量を計測する計測部１０１１とエネルギー量の時系列データを制御機器１０４０へ通知する通信部１０１２を備え、計測器をユニークに特定するＩＤを有する。
　制御機器１０４０は、「計測器１」１０１０、及び「計測器２」１０２０に対して計測を開始する制御や計測間隔を変更する制御等を実施し、また、時系列データをデータ処理サーバ１１００へ送信するする通信部１０４２を備える。通信部１０４２は、時系列データを１点ずつ送信するのではなく、ある時間間隔で纏まった複数の時系列データを送信し通信路のスループットを向上させることもできる。また、制御機器１０４０では「計測器１」１０１０と「計測器２」１０２０を対象としたが、計測器と制御機器との対応は自由に変更できる。
　データセンタ１０００について説明する。データセンタ１０００は、本発明の時系列データの格納及び補正処理を実施するデータ処理サーバ１１００と時系列データを格納しておけるデータベース１１４０を備える。
　データ処理サーバ１１００は、制御機器１０４０や制御機器１０５０からの時系列データを受信する通信部１１１０と、時系列データをデータベース１１４０に格納、取得、及び補正する演算部１１２０と、データベースから取得した値を補正処理のために記憶する記憶領域１１３４、及び後述の参照アプリケーションが時系列データを取得する際のさまざまな補正を実施するＡＰＩ１１３１～１１３３が格納された記憶部１１３０とを有する。
　演算部１１２０は、時系列データをデータベース１１４０に登録する登録処理１１２１とデータベース１１４０から取得する参照処理１１２２と取得した時系列データを必要なデータへ補正する補正処理１１２３を備える。
　次に、時系列データを参照するアプリケーションが設置された拠点では「クライアントＰＣ Ａ」１２１０、「クライアントＰＣ　Ｂ」１２２０、「クライアントＰＣ　Ｃ」１２３０が設置されている。「クライアントＰＣ Ａ」１２１０にはデータ処理サーバ１１００から時系列データを取得する「参照アプリケーションＡ」１２１１が搭載されている。「クライアントＰＣ Ａ」１２１０と同様に「クライアントＰＣ Ｂ」１２２０、「クライアントＰＣ Ｃ」１２３０にも「参照アプリケーションＢ」１２２１、「参照アプリケーションＣ」１２３１が搭載されている。ただし、クライアントＰＣには複数の参照アプリケーションが搭載されていても良い。また、ここでは３種類の参照アプリケーションを例としているが数に制限はない。
　本発明の全体の処理フローを説明する。全体の処理フローは大きく分けて、登録処理と参照処理に分けられる。登録処理では、時系列データをセンサ等により計測し、計測した時系列データを登録しデータベースに格納する。参照処理では、参照要求ごとにデータベースに格納された時系列データから必要に合わせた補正処理を実施し、その結果を参照アプリケーションへ返す。ただし、登録処理と参照処理は独立した処理であり、参照時に時系列データが登録されていない場合もありえる。
　図２により登録処理１１２１の詳細を示す。登録処理では、計測器１（１０１０）が、指定された時間間隔で時系列データを計測部１０１１により計測する（Ｓ１００１）。温度、湿度、エネルギー量など計測する時系列データの種別は計測器ごとに事前に決定されている。また、計測時間間隔は、計測器の仕様または制御機器によって設定され事前に決定されている。ここでは、計測される値は計測器ＩＤ、計測時刻、及び計測値とする。計測器１（１０１０）は、計測した時系列データを、通信部１０１２により接続されている制御機器１０４０へ送信する（Ｓ１００２）。時系列データの計測（Ｓ１００１）及び送信（Ｓ１００２）は計測器が計測するたびに繰り返し実施される。
　計測器１（１０１０）から送信された時系列データを、制御機器１０４０の通信部１０１２が受信する（Ｓ１００３）。次に、演算部１０４１が、制御機器１０４０が受信した時系列データを、データ処理サーバ１１００へ送信するための形式に補正する（Ｓ１００４）。これは、計測器によって計測する値の形式が異なるため、送信側である制御機器が統一的な形式に時系列データを変換している。ただし、データ処理サーバ側で時系列データを変換してもよい。次に、通信部１０４２が、変換した時系列データをデータ処理サーバ１１００へ送信する（Ｓ１００５）。
　データ処理サーバ１１００の通信部１１１０は、時系列データを受信し、演算部１１２０に登録処理する要求を出す（Ｓ１００６）。演算部１１２０の登録処理１１２１は、時系列データをデータベースに登録するための格納形式に変換する（Ｓ１００７）。これは、登録するデータベースによって登録方法や登録形式が異なるため、それぞれのデータベースに登録する形式に変換する必要があるためである。その後、登録処理１１２１がデータベース１１４０に対して格納形式に補正した値の登録処理を依頼し、データベース１１４０に時系列データが格納される（Ｓ１００８）。このとき、計測器１（１０１０）からネットワーク障害や未計測により時系列データが送信されてこない場合は登録処理が実施されない。ただし、計測器１（１０１０）によって計測が行われるが計測値のみが検出されない場合は、計測値を「ｎｕｌｌ」として扱いデータベースに登録することとする。
　具体例として、計測器ＩＤが「１」である計測器１（１０１０）が、ある電気機器に接続されており、２０１１年１０月１０日１０時１０分１０秒にエネルギー量である計測値「１０」を計測する（Ｓ１００１）。この計測器では１秒１回の計測を実施する仕様である。計測した時系列データを制御機器１０４０に送信し（Ｓ１００２）、制御機器は時系列データを受け取って（Ｓ１００３）「１、２０１０１０１０＿１０１０１０、１０」の文字列に補正し（Ｓ１００４）、データ処理サーバに送信する（Ｓ１００５）。
　データ処理サーバ１１００では文字列を受け取り（Ｓ１００６）データベースへ登録する形式に時系列データを変換する（Ｓ１００７）。ここでは、データベースはリレーショナルデータベースの「ＳＥＮＳＯＲ＿ＬＯＧ」としたテーブル名のテーブルに登録することを想定し、ＳＱＬの形式である「ＩＮＳＥＲＴ　ＩＮＴＯ　ＳＥＮＳＥＲ＿ＬＯＧ　ＶＡＬＵＥＳ　（１,２０１０１０１０＿１０１０１０,１０）」に補正する。その後、そのＳＱＬをデータベースに要求する（Ｓ１００８）。ただし、事前にデータベースのテーブル等の構築や接続設定が完了しているものとする。以上の登録処理が一定のタイミングで繰り返し実施されている。
　図３を用いて時系列データが格納されたテーブルの例を説明する。図３ではリレーショナルデータベースの「ＳＥＮＳＯＲ＿ＬＯＧ」２０００を示している。カラムには、計測器をユニーク特定するための「計測器ＩＤ２００１」、計測時刻である「時刻」２００２、及び計測値である「値」２００３があり、１レコードが１つの時系列データを示している。「ＳＥＮＳＯＲ＿ＬＯＧ」２０００の「時刻」２００２のカラムには、１秒ごとの計測器１の計測時刻「２０１０１０１０＿１０１０１０」、「２０１０１０１０＿１０１０１１」、及び「２０１０１０１０＿１０１０１３」と、計測器２の計測時刻「２０１０１０１０＿１０１０１４」及び「２０１０１０１０＿１０１０１５」の５レコードが格納されている。
　次に、参照処理１１２２の詳細を示す。具体例として、「クライアントＰＣ　Ａ」１２１０では、データ処理サーバ１１００から時系列データを取得し、エネルギー量が超過すると警告を発する参照アプリケーションＡ１２１１が搭載されている。参照アプリケーションが必要な時系列データは、１秒間隔かつ計測器１（計測器ＩＤが１）が計測した値である。また、参照アプリケーションＡ１２１１では、３秒間以内にエネルギー量が予め設定された量を超過する場合に警告を発するために必要な時系列データの時間範囲は３秒である。もし、３秒分の時系列データがない場合には正しい判定による警告が実施できないため、時系列データを補正する必要があり前回値で補正することとなる。
　図４を用いて参照処理１１２２のフローを説明する。参照アプリケーションＡ１２１１がデータ処理サーバ１１００に対して時系列データを取得するＡＰＩを呼び出す（Ｓ２００１）。
　データ処理サーバ１１００の通信部１１１０が取得要求を受け付ける（Ｓ２００２）。通信部１１１０が処理要求を受け付けると参照処理を実施する参照処理１１２２がスレッド処理を実施する（Ｓ２００３）。参照処理１１２２は、記憶部１１３０が受け付けた時系列データ取得要求に対応するＡＰＩ１１３１に一致するデータを検索し、そのデータの取得要求をデータベース１１４０に入力する（Ｓ２００４）。
　データベース１１４０はデータ取得要求に一致する時系列データを参照処理１１２２に渡す（Ｓ２００４）。参照処理１１２２は、時系列データを記憶部１１３０の記憶領域１１３４に保持して記憶しておく（Ｓ２００５）。記憶しておいた時系列データに対するＡＰＩの必要なデータ（欠損データ）の検出処理を実施する（Ｓ２００６）。ステップＳ２００６にてデータの不足が発見されると補正処理（補間処理）を実施する（Ｓ２００７）。
　具体例として、参照アプリケーションＡ１２１１は、データ処理サーバ１１００が提供する秒単位の前回値補正を実施するＡＰＩ１１３１を呼び出す。呼び出し方法は、データ処理サーバ１１００とコネクションを張り、ＡＰＩ１１３１の呼び出し名である「ｇｅｔＳｅｃｏｎｄＲａｔｅＰｒｅＤａｔａ（ｓｅｎｓｏｒＩＤ，ｓｔａｒｔＤａｔｅ，ｅｎｄＤａｔｅ）」を指定する。ここで、ＡＰＩ１１３１では、引数として第一引数に計測器ＩＤ（ｓｅｎｓｏｒＩＤ）と第二引数に時刻範囲開始条件(ｓｔａｒｔＤａｔｅ)と第三引数に時刻範囲終了条件（ｅｎｄＤａｔｅ）を指定することを前提とする。参照アプリケーションは、要件である時系列データを取得するためにＡＰＩ１１３１の引数に計測器「１」と時刻範囲開始条件「２０１０１０１０＿１０１０１０」と時刻範囲終了条件「２０１０１０１０＿１０１０１２」を指定してデータ処理サーバ１１００を呼び出す（Ｓ２００１）。
　データ処理サーバ１１００は、参照アプリケーションＡ１２１１から時系列データ取得要求を受け付け（Ｓ２００２）、演算部１１２０が、参照処理スレッド（参照処理１１２２）を開始してデータベース１１４０にデータ取得要求を送り（Ｓ２００３）、データベース１１４０から図３に示した時系列データを取得する（Ｓ２００４）。取得した時系列データは記憶部１１３０の記憶領域１１３４に保持される（Ｓ２００５）。図３に示した時系列データのテーブル「ＳＥＮＳＯＲ＿ＬＯＧ」２０００では時刻のカラム２００２は指定された時刻範囲に該当するレコードは「２０１０１０１０＿１０１０１０」と「２０１０１０１０＿１０１０１１」の２件であり要求が秒単位であるため、「２０１０１０１０＿１０１０１２」のレコードが不足していると判定される（Ｓ２００６）。このとき、要求が、前回値（既に登録されている計測値）にて補正する処理要求であるため、前回値を取得する必要がある。レコードが不足と判定されたレコードは、時刻２００２のカラムの値が「２０１０１０１０＿１０１０１２」であって、時刻２００２の値がこの値よりも１秒前のレコード「２０１０１０１０＿１０１０１１」の値２００３のデータ「２０」が補正に利用する前回値であることがわかる（Ｓ２００７）。その後、上記の不足していたレコードによって補間された時系列データを参照アプリケーションＡ１２１１に送信する。
　図５に、時系列データを補正した値の例を示す。図５は上記ＡＰＩ１１３１が呼び出された後、データ処理サーバの処理により不足があった時系列データが補正され、参照アプリケーションＡ１２１１が取得できる時系列データ３０００である。カラム構成は図３と同様であり、不足していたレコード３００１は、「時刻」３００２のカラムの値が「２０１０１０１０＿１０１０１２」であり、「値」３００３のカラムの値が「２０」で補正されている。
　上記の例ではＡＰＩ１１３１は秒単位の時系列データとしてデータに不足があった場合に、前回値により補正する処理を実施した。前回値がない場合には固定値０として補正することとする。また、他のＡＰＩも呼び出すことができる。例えば、ＡＰＩ１１３２では分単位の時系列データとしてデータ不足を判定し、取得したレコードの「値」３００３の平均値を求め、この平均値を用いて補正することする。また、ＡＰＩ１１３３ではデータベース１１４０に格納されている時系列データを取得し、必要データの検出処理と補正処理を実施せずに参照アプリケーションに渡す。
　上記のＡＰＩの選択では、ステップＳ２００１のように、参照アプリケーションにより取得したい時系列データのためのＡＰＩが、呼び出し名により選択されることが本発明の特徴である。ＡＰＩでは定義された処理ごとに実施できる処理が異なり、時系列データを秒単位や分単位や時単位などの要求に合わせた補正処理が実現できる。実際は、データベースに格納されていていない時系列データでも参照アプリケーションが取得することができ、その場合は、参照アプリケーションではデータの格納状態を管理する必要がない。さらに、データベースに格納されていない時系列データを、格納されているデータによって補正する際には、前回値や平均値や最多値などの手法を動的に適用することができる。
　また、上記の手法では、センサの分解能が低くサンプリングデータが少ない場合でも要求に合わせて補正することができる。一方、エネルギー量の消費量が変化した場合のみを通知する等の参照プリケーションによっては、データベースに格納されている時系列データのすべてが必要であるとは限らない。必要のない時系列データをデータ処理サーバから参照アプリケーションへ通信すると、通信ネットワークに負荷がかかる場合があり無駄な通信となる。その場合は、データ処理サーバ１１００が提供する「値」に変化があった場合のレコードのみを取得するＡＰＩを、ステップＳ２００１と同様のタイミングで呼び出す。その呼び出し方法では、データ処理サーバ１１００とコネクションを張り、呼び出し名である「ｇｅｔＣｈａｎｇｅＯｆＶａｌｕｅ（ｓｅｎｓｏｒＩＤ，ｓｔａｒｔＤａｔｅ，ｅｎｄＤａｔｅ）」を指定する。このＡＰＩの引数はＡＰＩ１１３１と同様である。例えば、図３の「ＳＥＮＳＯＲ＿ＬＯＧ」２０００のテーブルに格納されている時系列データに対して、計測器ＩＤ（ｓｅｎｓｏｒＩＤ）を「２」として、時刻範囲開始条件「２０１０１０１０＿１０１０１０」と時刻範囲終了条件「２０１０１０１０＿１０１０１５」を引数に指定してＡＰＩ呼び出しを実施すると、計測器ＩＤ「２」、時刻「２０１０１０＿１０１０１４」、及び値「５０」のレコードのみが取得できる。これは、時系列データを間引く補正処理に相当する。
　以上のように、参照アプリケーションの要求に合わせた補正処理を実施するＡＰＩを追加して実装することで、データベースの時系列データのデータ容量を増加させずに、時系列データを補正する種々のパターンに対応することができる。
　＜第二の実施形態＞
　第一の実施形態では、データベースの種別は特に指定していない。ただし、データの一貫性を保障するデータベースであるＲＤＢを利用した場合においてステップＳ２００４によってデータベース１１４０から大量のデータを検索して取得する、または、同時に複数の参照アプリケーションから時系列データの取得要求を受けるとデータ処理サーバの処理能力がボトルネックとなり補正処理に時間がかかる可能性がある。第二の実施形態ではボトルネックとなる時系列データの取得においてデータベースを「分散型データベース」とし、補正処理において分散処理によって上記のボトルネックを解消する。
（システム構成）
　図６は第二の実施形態に関わるシステム構成図である。第一の実施形態のシステム構成図と異なる部分を中心に説明する。時系列データを計測する拠点には変更はない。また、参照アプリケーションが設置された拠点にも変更はない。ただし、後述のデータセンタ１０００側へのネットワークの接続方法が異なる。
　データセンタ１０００では、既存のデータ処理サーバ１１００に加え、データ処理サーバ１２００、１３００を追加する。各データ処理サーバの構成は既存のデータ処理サーバ１１００と変更はない。ただし、この実施形態ではデータ処理サーバの数は３台としているが、参照アプリケーションから同時にアクセスされる数及び補正処理の負荷によって異なるため３台とは限らない。
　また、データ処理サーバ１１００、１２００、１３００の登録処理、参照処理の際に各データ処理サーバの負荷状態を把握し、負荷状況に基づいて登録処理または参照処理を各データ処理サーバに分散するロードバランシング装置１００１を追加する。ロードバランシング装置１００１は、１つの処理をいくつかの処理に分割し、分割された処理を各データ処理サーバに依頼するための負荷状態の取得やバランシングの制御を実施する演算部１００２、第一の実施形態で保持していたＡＰＩの処理方法や各データ処理サーバの負荷状態や補正した時系列データを保持しておく記憶部１００３により構成される。ただし、記憶部１００３は各種ＡＰＩを保持しているが、各データ処理サーバへの受け口として参照アプリケーションにＡＰＩが公開されているのみであるため、実際の補正処理は各データ処理サーバが実施する。
　また、ロードバランシング装置１００１を追加する際にネットワークのアドレス体系を変更する。具体的には、第一の実施形態では、制御機器１０４０からの時系列データの送信先、及び参照アプリケーションの接続先をデータ処理サーバ１１００のアドレスとしていたが、第二の実施形態では、ロードバランシング装置１００１にデータ処理サーバ１１００が保持していたアドレスを割り当てるように変更する。これにより、制御機器からの送信先、及び参照アプリケーションからの接続先のアドレスを変更せずにそのままデータ処理サーバを利用できる構成となる。データ処理サーバ１１００、１２００、１３００にはロードバランシング装置１００１が接続され、互いに重複しないアドレスがそれぞれのデータ処理サーバに設定され、各データ処理サーバをユニークに特定できる。
　また、データベース１１４０を「分散型データベース」１１５０に変更する。分散型データベース１１５０はデータベースのノード１１５１、１１５２、１１５３によって構成される。厳密には、分散型データベースは、それぞれがストレージ装置であるノードの集まりのことであり、各ノードが互いに同期を取ってデータの分散が行なわれ、Ｋｅｙに対応するデータを保持している情報をすべてのノードで共有している。また、上記では例として３つのノードで構成されているが、ノードの数に制限はない。分散型データベース１１５０は各データ処理サーバと接続される。
（データモデル）
　分散型データベースに時系列データを格納するデータモデル（データ格納形式）を説明する。図７に示した第二の実施形態におけるデータモデルＤ２０００を示す。分散型データベースでは、表形式のデータモデルとは異なり、ＳＱＬのようなデータベース共通の問い合わせ言語がなく、格納されている値に対する格納と取得のみであり演算などは実施できない。分散型データベースでは、「Ｋｅｙ」Ｄ２００１と「Ｖａｌｕｅ」Ｄ２００４の対応づけによってデータが管理され、「Ｋｅｙ」の単位で各ノードに分散されて保持される。
　また、多くの分散型データベースの構造には、実際の時系列データの値である「Ｖａｌｕｅ」Ｄ２００４とその値が格納されるカラム名に相当するラベルとなる「Ｎａｍｅ」Ｄ２００３とが対になって複数個存在し、さらに、いくつかの「Ｎａｍｅ」をまとめたものに対するラベルとして定義できる「ＳｕｐｅｒＣｏｌｕｍｎ」Ｄ２００２がある。「Ｎａｍｅ」及び「ＳｕｐｅｒＣｏｌｕｍｎ」では格納された値は文字列の値に対する辞書順序やバイナリ列の値に対する順序などのある規則に従ってソートされる。
　「Ｎａｍｅ」Ｄ２００３及びこれと対になる「Ｖａｌｕｅ」Ｄ２００４には、日時７０１、年月日７０２、時刻７０３、シーケンス７０４、計測器ＩＤ７０５、名称７０６、及びエネルギー量７０７の各項目名と対応する値が格納されている。時系列データが発生した日時７０１の情報が分割されて年月日７０２と時刻７０３に格納される。
　１日単位で時系列データを取得する場合が最も多いと想定し、「２０１０１０１０」のような年月日の値をＫｅｙとし、Ｋｅｙに対する時系列データの計測器ＩＤ、時刻、及び値などをＶａｌｕｅと定義する。ＳｕｐｅｒＣｏｌｕｍｎＤ２００２に対して時刻範囲を指定してデータを取得する場合、時刻（時、分、秒）及び検索条件である計測器を特定するための計測器ＩＤが同じであるが、それぞれ異なる計測が実施される可能性がある。即ち、時刻の最小単位が１秒であるため、この１秒の間にそれぞれ異なる計測が実施される可能性があり、時刻（時、分、秒）と計測器ＩＤとの組みを指定するだけではそれぞれの計測をユニークに特定できなくなる。そこで、時刻と計測器ＩＤが同じであってもそれぞれの計測をユニークに特定できるようにするため、Ｋｅｙに、それぞれの計測に対応した、時刻とは別の固有のシーケンス番号を付与する。
（登録処理）
　登録処理について説明する。登録処理は図２に示した登録処理フローと異なる部分のみ説明する。第一の実施形態においてはステップＳ１００５において時系列データをデータ処理サーバ１１００に送信していたが、第二の実施形態では、ロードバランシング処理１００１に送信することになる。ただし、制御機器１０４０からの送信先であるアドレスに変更がないためデータセンタ１０００の構成変更による影響は受けない。
　ロードバランシング処理１００１は、常に、接続された各データ処理サーバ１１００、１２００、１３００に対して処理負荷の状態（たとえばＣＰＵ使用率など）を送信するように要求しており、登録の要求を受信した際に各データ処理サーバのうち最も処理負荷の状態が良好である（ＣＰＵ使用率が最も低い）データ処理サーバに制御機器１０４０からの登録処理を要求する。また、第一の実施形態で示したデータ処理サーバ１１００の登録処理であるステップＳ１００７の処理ではデータをそのままデータベースに格納する形式としたが、図７に示したデータモデルとして分散型データベース１１５０に格納する形式にデータを補正する。分散型データベース１１５０は、登録の要求を受けると格納する形式に補正された時系列データのＫｅｙごとにノード１１５１、１１５２、１１５３へ分散してデータを登録する。
（参照処理）
　参照処理について図９を用いて説明する。参照処理は図４に示した登録処理フローと異なる部分のみ説明する。第一の実施形態では、参照アプリケーション１２１１から時系列データを取得するＡＰＩの呼び出し（Ｓ２００１）をデータ処理サーバ１１００に対して実施していたが、第二の実施形態では、参照アプリケーション１２１１はロードバランシング装置１００１に対してＡＰＩの呼び出しを実施する。ただし、第二の実施形態におけるロードバランシング装置のアドレスはデータセンタ１１００に設定されていたアドレスに変更されているため、参照アプリケーション１２１１はデータセンタ１０００の構成変更の影響を受けることはない。
　次に、ロードバランシング装置１００１は、参照アプリケーション１２１１から参照要求を受け付けると、演算部１００２が参照する時刻範囲に基づいて分散型データベースに格納されているデータモデルのＫｅｙの単位で時系列データを取得して補正処理を実施するために、各データ処理サーバに処理を分散させる（Ｓ２１０１）。データ処理サーバとこのサーバが担当するＫｅｙの値とを対応づける際に、Ｋｅｙの順序の値Ｎをデータ処理サーバの数Ｍで割った時の余りＲの値と各処理サーバとが対応づけられる。即ち、０または正の整数Ｋを用いるとＮはＮ＝Ｍ・Ｋ＋Ｒと表され、余りがＲ（＝０～Ｍ－１）となるので、Ｋｅｙの順序の値がＮのデータは、データ処理サーバＲに割り当てられる。但し、Ｒ＝０の時はデータ処理サーバＭにデータを割り当てる。Ｋｅｙの順序の値Ｎに応じてデータ処理サーバを割り当てる方法としては、データ処理サーバの処理能力や処理状況などを考慮した割り当て方法など、別の方法でもよい。
　例えば、Ｋｅｙの総数が５であり、データ処理サーバが「データ処理サーバ１（１１００）」、「データ処理サーバ２（１２００）」及び「データ処理サーバ３（１３００）」の３台（Ｍ＝３）であった場合は、１番目に小さい年月日のＫｅｙの値「１」（Ｎ＝１）に対する３の余りは１となりデータ処理サーバ１（１１００）が担当する。また、Ｋｅｙの順序の値が「２」（Ｎ＝２）である場合にはデータ処理サーバ２（１２００）が担当するように処理を分散する。
　各データ処理サーバへのＡＰＩの呼び出し方法は第一の実施形態と同様である。また、ステップＳ２００４のデータベースへの時系列データ取得要求において、第一の実施形態と呼び出し方法は同じであるが、分散型データベース１１５０のデータ取得方法が異なる。分散型データベース１１５０は、時系列データの取得要求を受け付けると、各ノード１１５１、１１５２、１１５３は上記の式に基づいて各自のノードが保持すべきＫｅｙに対応する時系列データの取得を実施する。各ノードは上記の式に基づいて選択されたＫｅｙ単位の時系列データを取得するのみで良いため、１つのノードの処理量は少なくなり、データベースから時系列データを取得する場合の処理負荷のボトルネックが軽減されやすくなる。
　また、第一の実施形態ではステップＳ２００７で補正された時系列データを、データ処理サーバ１１００は参照アプリケーション１２１１に渡していたが、第二の実施形態ではステップＳ２１０１で分散処理を実施しているため、各データ処理サーバが補正した時系列データをロードバランシング装置１００１の記憶部１００３に一時的に保持しておき、演算部１００２が各補正された時系列データをマージ処理することで参照アプリケーション１２１１が要求した時系列データとして渡すことができる。
（参照処理の具体例）
　第二の実施形態における参照処理の具体例を示す。参照アプリケーションＢ１２１２は、データセンタが提供する秒単位の前回値補正を実施するＡＰＩ１１３１を呼び出す。ここで、ＡＰＩ１１３１は第一の実施形態と同一のＡＰＩであり、引数として第一引数に計測器ＩＤ（文字列）を、第二引数として時刻範囲開始条件(文字列)を、第三引数として時刻範囲終了条件（文字列）をそれぞれ指定することを前提とする。
　参照プリケーションの業務例としては、毎日のある一定時刻のデータを取得し、日々の時系列データの傾向分析をするものとする。例えば、毎日の10時00分からの６件(１秒間に１回の計測)の計測値を取得する。
　参照アプリケーションは、要件である時系列データを取得するために、ＡＰＩ１１３１の引数に計測器「１」と時刻範囲開始条件「２０１０１０１０＿１０１０１０」と時刻範囲終了条件「２０１０１０１２＿１０１０１０」を指定してＡＰＩ１１３１を呼び出す。ＡＰＩ１１３１を呼び出すと、データセンタ１０００のロードバランシング装置１００１がＡＰＩ呼び出し要求を受け付け、参照処理をデータ処理サーバ１１００、１２００、１３００へ分担させる。
　具体的には、演算部１００２が年月日単位（Ｋｅｙの値）に処理を分割する際に、「２０１０１０１０＿１０１０１０」から「２０１０１０＿２３５９５９」を１日分の時刻範囲の年月日が最少であるため１番目の取得要求とし、「２０１０１１＿００００００」から「２０１０１２＿２３５９５９」を２番目の取得要求とし、「２０１０１２＿００００００」から「２０１０１２＿１０１０１０」を３番目の取得要求とする。年月日単位の時系列データ取得要求と処理する各データ処理サーバとの割り当ては、前記ステップＳ２１０１の手法により、１番目の取得要求は「データ処理サーバ１」１１００が、２番目の取得要求は「データ処理サーバ２」１２００が、３番目の取得要求は「データ処理サーバ３」１３００がそれぞれ実施する。
　ロードバランシング装置１００１から各データ処理サーバ１１００、１２００、１３００に対するＡＰＩ１１３１の呼び出し方法では、参照アプリケーションＢ１２１２からの呼び出しの引数である時刻範囲が分割されて部分的に各データ処理サーバに指定される。例えば、データ処理サーバ１１００に対しては、時刻範囲開始条件が「２０１０１１＿００００００」、時刻範囲終了条件が「２０１０１２＿２３５９５９」となるだけであり、各データ処理サーバ１１００、１２００、１３００のＡＰＩの処理自体に変更はない。
　次に、分散型データベース１１５０に対して、「データ処理サーバ１」１１００は計測器ＩＤ「１」と時刻範囲「２０１０１１＿００００００」から「２０１０１２＿２３５９５９」の検索条件に一致するレコードの取得要求を実施する。「データ処理サーバ２」１２００、「データ処理サーバ３」１３００も同様に検索条件に一致するレコードの取得要求を実施する。分散型データベース１１５０は、それぞれの条件に一致するレコードの検索を各ノード１１５１、１１５２、１１５３に対して並列的に実施し、要求したデータ処理サーバ１１００、１２００、１３００に返す。
（データモデルの具体例）
　図８Ａ－８Ｃは、「データ処理サーバ１」が取得した、上記の条件に一致したレコードのデータモデルの具体例Ｄ３０００、即ち、図７のデータモデルＤ２０００の具体例である。図８Ａは、取得した時系列データの全体を示し、図８Ｂは、図８Ａの全体のデータの中から、センサＩＤが「１」のデータのみを抽出した結果であり、図８Ｃは、図８Ｂのデータに対して補間すべきデータを示したものである。
　Ｋｅｙである「年月日」Ｄ３００１は図７のＤ２００１に対応し、ＳｕｐｅｒＣｏｌｕｍｎである「時分＋センサＩＤ＋シーケンス」Ｄ３００２はＤ２００２に対応する。更に、ＣｏｌｕｍｎのＤ３００３～Ｄ３００８の各項目は、図７のＤ２００３及びＤ２００４の各項目７０２～７０７に対応し、その対応関係を、以下では（　）で示す。
　第一の実施形態と同様に、ＡＰＩ１１３１は秒単位の時系列データを取得するため、「時分」Ｄ３００６（７０３）のカラムの値が１秒ずつの値で増加していくかを判定していくと、図８Ｂに示すように、「１０：００：０２」のレコードＤ３１００の次が「１０：００：０４」のＤ３１０２のレコードであるため、１秒ずつの時系列データのレコードが格納されておらず、Ｄ３１０１に示した「１０：００：０３」に相当するレコードが不足している、即ち、欠損データであることがわかる。　　
　必要なデータへの補正は前回値を利用するが、時系列データでは時分の値を予測して埋める必要がある。秒単位の時系列データでは、時分Ｄ３００６の値を、前回値であるＤ３１００の「１０：００：０２」から１秒を経過した「１０：００：０３」に対応するデータで欠損データを埋める。即ち、図８Ｂに示すように、時分が「１０：００：０２」であってセンサＩＤが同じ「１」である、前回値であるＤ３１００を用いて、時分が「１０：００：０３」に対応するデータとして欠損データＤ３１０１を埋める。また、時刻でソートさせておくためのＳｕｐｅｒＣｏｌｕｍｎＤ３００２は、前回値であるＤ３１００のＳｕｐｅｒＣｏｌｕｍｎＤ３００２と同様に、時分が「１０：００：０３」に対応した「１０：００：０３；１；５」となる。他のカラムは、年月日Ｄ３００１、「計測器ＩＤ」Ｄ３００３（７０５）、シーケンスＤ３００４（７０４）、年月日Ｄ３００５（７０２）、名称Ｄ３００７（７０６）、エネルギー量Ｄ３００８（７０７）を前回値であるレコードＤ３１００と同じ値で補正すると、図８Ｃに示すように、年月日Ｄ３００１は「２０１１／１０／１０」、「計測器ＩＤ」Ｄ３００３は「１」、シーケンスＤ３００４は「５」、年月日Ｄ３００５は「２０１１／１０／１０」、名称Ｄ３００７は「センサＡ」、エネルギー量Ｄ３００８は「１２」と補正したレコードＤ３２００となる。
　最後に、「データ処理サーバ１」１１００が補正した時系列データＤ３３００と同様に、年月日が異なる時系列データを「データ処理サーバ２」１２００、及び「データ処理サーバ３」１３００によって補正された時系列データＤ３４００、Ｄ３５００が年月日の順番になるようにマージしたデータが、図８Ｄに示すＤ３６００となる。３台のデータ処理サーバでそれぞれ処理されたデータをマージした結果であるＤ３６００を、参照アプリケーション１２１１に提供すると一連の処理が終了する（Ｓ２１０２）。
（重複処理の検出）
　また、本発明の特徴である、参照アプリケーション側ではなくデータセンタ側で必要なデータの検出及び補正を実施することの利点として、複数の参照アプリケーションから同時に同じ補正処理を要求される場合に、ロードバランシング装置１００１がデータ処理サーバに処理を分散する際に、重複する処理は実施させないことにある。参照アプリケーション側で必要データの検出及び補正を実施すると、各参照アプリケーションはそれぞれ独立して処理するため、他の参照アプリケーションの処理において互いの処理の重複を検出することができない。その結果、重複する処理は無駄な処理となり、全体の処理負荷が低減しない場合がある。
　図９を参照して、重複処理を検出して除去する具体的な処理フローを説明する。前提として参照アプリケーションＡと参照アプリケーションＢが時系列データを参照するＡＰＩを呼び出すこととする。参照アプリケーションＡでは２０１０年１１月１０日１０時１０分１０秒に「ｇｅｔＳｅｃｏｎｄＲａｔｅＰｒｅＤａｔａ（ｓｅｎｓｏｒＩＤ，ｓｔａｒｔＤａｔｅ，ｅｎｄＤａｔｅ）」を引数にして計測器「１」と時刻範囲開始条件「２０１０１０１０＿１０１０１０」と時刻範囲終了条件「２０１０１０１２＿１０１０１０」を指定してＡＰＩを呼び出し、参照アプリケーションＢも同時刻に同ＡＰＩを引数にして計測器「１」と時刻範囲開始条件「２０１０１０１１＿００００００」と時刻範囲終了条件「２０１０１０１３＿１０１０１０」を指定してＡＰＩを呼び出す。
　次に、ロードバランシング装置１０１１はステップＳ２１０１において、ＡＰＩ呼び出し要求を受け付ける。各参照アプリケーションからＡＰＩが呼び出された時刻を取得し、記憶部１００３に格納しておく。同じ時刻からの同じＡＰＩの呼び出し、同じ計測器、及び同じ時刻範囲に対する時系列データの補正処理を実施する場合には、時系列データは更新されていないとみなし、これらの補正処理は重複する補正処理と判定できる。
　その後、時刻範囲で時系列データの取得及び補正処理を実施させるため、各データ処理サーバに処理を分割させる。参照アプリケーションＡでは、時刻範囲が「２０１０１０１０＿１０１０１０」から「２０１０１０＿２３５９５９」を１番目の時系列データ、「２０１０１０１１＿００００００」から「２０１０１０１１＿２３５９５９」を２番目の時系列データ、「２０１０１０１２＿００００００」から「２０１０１０１２＿１０１０１０」を３番目の時系列データに時系列データが分割される。一方、参照アプリケーションＢでは、時刻範囲が「２０１０１０１１＿００００００」から「２０１０１０１１＿２３５９５９」を１番目の時系列データ、「２０１０１０１２＿００００００」から「２０１０１０１２＿２３５９５９」を２番目の時系列データ、「２０１０１０１３＿００００００」から「２０１０１０１３＿１０１０１０」を３番目の時系列データに時系列データが分割される。ここで、参照アプリケーションＡ及びＢが同じ時刻範囲「２０１０１０１１＿００００００」から「２０１０１０１１＿２３５９５９」の時系列データを処理するので、参照アプリケーションＡからの要求である２番目の時系列データに対する処理と、参照アプリケーションＢからの要求である１番目の時系列データに対する処理とが重複していると判定する。従って、重複している参照アプリケーションＢからの要求である１番目の時系列データに対する処理を行わず、以降の処理の対象は、参照アプリケーションＡの１番目、２番目、３番目の時系列データと参照アプリケーションＢの２番目、３番目の時系列データの５つとなる。
　次に、３台あるデータ処理サーバに、第一の実施形態で述べた余りによる割り当て処理と同様の処理を実施し、参照アプリケーションＡの１番目の時系列データに対する補正処理をデータ処理サーバ１に、２番目をデータ処理サーバ２に、３番目をデータ処理サーバ３にそれぞれ担当させ、参照アプリケーションＢの２番目の時系列データに対する補正処理をデータ処理サーバ２に、３番目をデータ処理サーバ３にそれぞれ担当させる。以降は、前記の各データ処理サーバにおけるＡＰＩを呼び出して各時系列データに対応する補正処理を実施させ、処理結果を、記憶部１００３に、処理した計測器、ＡＰＩ、時刻範囲とともに記憶させる。
　各データ処理サーバ１１００、１２００、１３００に処理を分割させた後の各データ処理サーバ１１００、１２００、１３００、及びデータベース１１５０におけるステップＳ２００２～Ｓ２００７の処理は、図４に示す処理と同じである。
　最後に、補正されたデータをステップＳ２１０２においてマージさせる。1番目、２番目、３番目のすべての時系列データが揃うとそれらをまとめて参照アプリケーションＡに返す。参照アプリケーションＢは、参照アプリケーションＡの２番目の時系列データに対する補正処理を実施した値が記憶部１００３格納されているので、計測器、ＡＰＩ、時刻範囲を指定して、この補正処理を実施した値を取得する。さらに、取得した値（重複しているとして処理されなかった参照アプリケーションＢからの要求である１番目の時系列データ）と参照アプリケーションＢの２番目と３番目の補正処理した値とをマージして参照アプリケーションＢに返す。これにより重複した処理を参照アプリケーション側が実施しないことにより、全体的な処理量を低減させることができる。
（重複処理の検出の変形例）
　上記のように、重複処理を検知して処理負荷を軽減する補正方法では、重複検知の判定は固定的にデータ処理サーバ側で決定されていたが、ＡＰＩの引数を追加することで参照アプリケーションの要求ごとに、重複検知の判定方法を動的に変更できる。具体的には、データ処理サーバでは、重複する処理であるとの判定には、複数のアプリケーションからのＡＰＩ呼び出しにおいて、同一ＡＰＩ、同一ＡＰＩ呼び出し時刻、同一計測器に対する時系列データ、及び同一時刻範囲における補正処理を重複の判定の対象としていたが、参照アプリケーションからの要求に合わせて上記の項目を変更できるようにする。
　参照アプリケーションによっては時系列データの更新が頻繁でない場合には「同一ＡＰＩ呼び出し時刻」ではなく「同一ＡＰＩ」かつ「１０秒以内のＡＰＩ呼び出し時刻」であれば重複処理であると判定できる場合が想定される。具体例として、ＡＰＩ「ｇｅｔＳｅｃｏｎｄＲａｔｅＰｒｅＤａｔａ（ｓｅｎｓｏｒＩＤ，ｓｔａｒｔＤａｔｅ，ｅｎｄＤａｔｅ）」において、上記の実施例では、計測器、時刻範囲開始条件、時刻範囲終了条件を引数と指定していた。しかし、同一計測器かつＴ秒以内のＡＰＩ呼び出し時刻には重複処理であると判定し、補正処理を実施せず、他の補正結果を利用する新たなＡＰＩとして「ｇｅｔＳｅｃｏｎｄＲａｔｅＰｒｅＤａｔａ（ｓｅｎｓｏｒＩＤ，ｓｔａｒｔＤａｔｅ，ｅｎｄＤａｔｅ，ＴｈｒｅｓｈｏｌｄＴｉｍｅ）」を追加することで重複処理の検出を実現できる。
　例えば、ＴｈｒｅｓｈｏｌｄＴｉｍｅではＴ秒以内のＡＰＩ呼び出しの「Ｔ」を指定する。処理方法としては、上記ＡＰＩｇｅｔＳｅｃｏｎｄＲａｔｅＰｒｅＤａｔａ（ｓｅｎｓｏｒＩＤ，ｓｔａｒｔＤａｔｅ，ｅｎｄＤａｔｅ）が呼び出されたときに時刻を記憶部１００３に格納し、「ｇｅｔＳｅｃｏｎｄＲａｔｅＰｒｅＤａｔａ（ｓｅｎｓｏｒＩＤ，ｓｔａｒｔＤａｔｅ，ｅｎｄＤａｔｅ，ＴｈｒｅｓｈｏｌｄＴｉｍｅ）」が呼び出された際には、記憶部１００３に格納された値と後から呼び出されたＡＰＩの呼び出し時刻の値との時刻の差が、ＴｈｒｅｓｈｏｌｄＴｉｍｅの値がより小さい場合には重複処理であると判定できる。以降は前記の上記重複処理を検知して処理負荷を軽減する補正手法と同様である。
　本発明の実施形態においては具体的な説明のために例を示しているが、これらの例に制限されないための記述をする。構成としてデータセンタよる形態としているが、複数の計測器及び参照アプリケーションと接続され、時系列データを登録及び取得できる環境であるならば、外部ネットワークとは接続されないようなローカルの環境などの異なる形態でも構わない。ＡＰＩでは業務や参照ＡＰＩによって処理が異なることを許容し、ユーザが事前にこれらのＡＰＩを追加しておくことも構わない。データベースでは分散型データベースを利用した実施形態を示しているが、格納されている時系列データを取得する際に処理が集中することによる処理負荷が発生しない環境のデータベースであれば他の環境でも構わない。また、第二の実施形態におけるデータモデルでは、Ｋｅｙを年月日単位の値としたが、業務などの要件に合わせて異なるパラメータを単位として分散処理を要求することも可能である。
１０００　データセンタ
１００１　ロードバランシング装置
１００２　ロードバランシング装置の演算部
１００３　ロードバランシング装置の記憶部
１０１０　計測器１
１０１１　計測部
１０１２　通信部
１０１１　登録端末
１０２０　計測器２
１０３０　計測器３
１０４０　制御機器
１０４１　制御機器の演算部
１０４２　制御機器の通信部
１０５０　制御機器
１１００　データ処理サーバ（１）
１１１０　データ処理サーバ（１）の通信部
１１２０　データ処理サーバ（１）の演算部
１１２１　登録機能
１１２２　参照機能
１１２３　補正機能
１１３０　データ処理サーバ（１）の記憶部
１１３１　ＡＰＩ（秒単位の前回値補正）
１１３２　ＡＰＩ（分単位の前回値補正）
１１３３　ＡＰＩ（無補正）
１１３４　記憶機能
１１４０　データベース
１１５０　分散型データベース
１１５１　分散型データベースを構成するノード１
１１５１　分散型データベースを構成するノード２
１１５１　分散型データベースを構成するノード３
１２００　データ処理サーバ　２
１２１０　クライアントＰＣ　Ａ
１２１１　参照アプリケーションＡ
１２２０　クライアントＰＣ　Ｂ
１２２１　参照アプリケーションＢ
１２３０　クライアントＰＣ　Ｃ
１２３１　参照アプリケーションＣ
１３００　データ処理サーバ　Ｎ
２０００　時系列データの「ＳＥＮＳＯＲ＿ＬＯＧ」テーブル
３０００　時系列データの「ＳＥＮＳＯＲ＿ＬＯＧ」テーブルの補正した値
Ｄ２０００　分散型データベースの「ＳＥＮＳＯＲ＿ＬＯＧ」テーブル構成
Ｄ３０００　分散型データベースの「ＳＥＮＳＯＲ＿ＬＯＧ」テーブル値

Claims (12)

  1. 　時系列で変化する値を計測し、収集、管理する時系列データ管理システムにおいて、
    　少なくとも一つの計測器が計測した時系列データを受信し、前記受信した時系列データを管理する手段と、
    　前記受信した時系列データを格納する手段と、
    　複数の参照アプリケーションによって時系列データを取得する要求の際に、保持されている時系列データに対して参照アプリケーションの要求により補正する対象と補正する方法を指定した補正処理を実施した時系列データを取得する手段と、
    　を備えることを特徴とする時系列データ管理システム。
  2. 　請求項１に記載の時系列データ管理システムであって、
    　複数の参照アプリケーションによって時系列データを取得する要求の際に、時系列データを分割し、分割された時系列データに対する補正処理を複数の処理サーバの分散処理によって実施し、分散処理において特定の条件により他の分散処理と同一の処理であると判定される場合に、いずれか一つの補正処理による結果をキャッシュとして記憶しておき、それ以外の補正処理を実施せずキャッシュを利用することで全体の演算処理を削減する手段を備えること
    　を特徴とする時系列データ管理システム。
  3. 　請求項１及び２のいずれかに記載の時系列データ管理システムであって、
    　補正処理による結果をキャッシュとして記憶する手段において、前記キャッシュの内容に対して、同一の処理と判定するための特定の条件を参照アプリケーションから指定すること
    　を特徴とする時系列データ管理システム。
  4. 　請求項１から３のいずれかに記載の時系列データ管理システムであって、
    　時系列データの登録及び参照における処理の負荷がかかる場合において、分散型データベースによるデータベースからの時系列データを取得する処理及び時系列データを補正する処理を分散して行うこと
    　を特徴とする時系列データ管理システム。
  5. 　時系列で変化する値を計測し、収集、管理する時系列データ管理装置において、
    　少なくとも一つの計測器が計測した時系列データ値を受信し、前記受信した時系列データを管理する手段と、
    　前記受信した時系列データを格納する手段と、
    　複数の参照アプリケーションによって時系列データを取得する要求の際に、保持されている時系列データに対して参照アプリケーションの要求により補正する対象と補正する方法を指定した補正処理を実施した時系列データを取得する手段と、
    　を備えることを特徴とする時系列データ管理装置。
  6. 　請求項５に記載の時系列データ管理装置であって、
    　複数の参照アプリケーションによって時系列データを取得する要求の際に、時系列データを分割し、分割された時系列データに対する補正処理を複数の処理サーバの分散処理によって実施し、分散処理において特定の条件により他の分散処理と同一の処理であると判定される場合に、いずれか一つの補正処理による結果をキャッシュとして記憶しておき、それ以外の補正処理を実施せずキャッシュを利用することで全体の演算処理を削減する手段
    　を備えることを特徴とする時系列データ管理装置。
  7. 　請求項５及び６のいずれかに記載の時系列データ管理装置であって、
    　補正処理による結果をキャッシュとして記憶する手段において、前記キャッシュの内容に対して、同一の処理と判定するための特定の条件を参照アプリケーションから指定すること
    　を特徴とする時系列データ管理装置。
  8. 　請求項５から７のいずれかに記載の時系列データ管理装置であって、
    　時系列データの登録及び参照における処理の負荷がかかる場合において、分散型データベースによるデータベースからの時系列データを取得する処理及び時系列データを補正する処理を分散して行うこと
    　を特徴とする時系列データ管理装置。
  9. 　少なくとも一つの計測器に接続されたデータ処理サーバにおける時系列データ管理方法であって、前記データ処理サーバは、
    　時系列で変化するデータを前記計測器から収集し、
    　前記収集した時系列データ記憶装置に格納し、
    　参照アプリケーションから要求される複数の時系列データの取得要求を受け付け、
    　前記参照アプリケーションからの時系列データの取得要求の際に要求された条件の時系列データを前記記憶装置から検索し、
    　前記検索した時系列データに複数の補正要求のパターンに該当する場合に前記検索した時系列データを補正する
    ことを特徴とする時系列データ管理方法。
  10. 　前記データ処理サーバを複数有し、
    　複数の前記参照アプリケーションによって前記時系列データを取得する要求の際に、前記時系列データを分割し、分割された時系列データに対する補正処理を複数の前記データ処理サーバの分散処理によって実施し、分散処理において特定の条件により他の分散処理と同一の処理であると判定される場合に、いずれか一つの補正処理による結果をキャッシュとして記憶しておき、それ以外の補正処理を実施せずキャッシュを利用することで全体の演算処理を削減すること
    　を特徴とする請求項９記載の時系列データ管理方法。
  11. 　補正処理による結果をキャッシュとして記憶し、前記キャッシュの内容に対して、同一の処理と判定するための特定の条件を参照アプリケーションから指定すること
    　を特徴とする請求項９及び１０のいずれかに記載の時系列データ管理方法。
  12. 　前記時系列データの登録及び参照における処理の負荷がかかる場合において、分散型データベースによるデータベースからの時系列データを取得する処理及び時系列データを補正する処理を分散して行うこと
    　を特徴とする請求項９から１１のいずれかに記載の時系列データ管理方法。
PCT/JP2011/075545 2011-11-07 2011-11-07 時系列データ管理システム、装置および方法 WO2013069073A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/075545 WO2013069073A1 (ja) 2011-11-07 2011-11-07 時系列データ管理システム、装置および方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/075545 WO2013069073A1 (ja) 2011-11-07 2011-11-07 時系列データ管理システム、装置および方法

Publications (1)

Publication Number Publication Date
WO2013069073A1 true WO2013069073A1 (ja) 2013-05-16

Family

ID=48288662

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/075545 WO2013069073A1 (ja) 2011-11-07 2011-11-07 時系列データ管理システム、装置および方法

Country Status (1)

Country Link
WO (1) WO2013069073A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016110620A (ja) * 2014-12-05 2016-06-20 知意圖股▲分▼有限公司 ビッグストリームデータのリアルタイム処理方法、ストリームデータ処理エンジン及びビッグストリームデータのリアルタイム処理システム
JP2017532702A (ja) * 2014-09-15 2017-11-02 マイクロソフト テクノロジー ライセンシング，エルエルシー 向上したイベント処理のための構築されたデータストリーム
JPWO2016157271A1 (ja) * 2015-03-27 2018-02-01 日本電気株式会社 センサネットワークシステム
JP2018133105A (ja) * 2013-11-11 2018-08-23 アマゾン・テクノロジーズ・インコーポレーテッド データストリーム取り込み及び永続性ポリシ
CN110543496A (zh) * 2019-09-06 2019-12-06 中国联合网络通信集团有限公司 用于时序数据库集群的数据处理方法和装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003044518A (ja) * 2001-07-31 2003-02-14 Yamatake Corp データ処理プログラム、データ処理システム及びデータ処理方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003044518A (ja) * 2001-07-31 2003-02-14 Yamatake Corp データ処理プログラム、データ処理システム及びデータ処理方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
SHOICHI SAITO ET AL.: "An Evaluation of Large- Scale Data Processing on Distributed Shared Memory Server", IPSJ SIG NOTES, vol. 95, no. 28, 9 March 1995 (1995-03-09), pages 25 - 32 *
YOICHIRO SATO: "MES Un'yo kara Mita Kojo no Togoka - Johoka", KEISO, vol. 51, no. 2, 1 February 2008 (2008-02-01), pages 31 - 34 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018133105A (ja) * 2013-11-11 2018-08-23 アマゾン・テクノロジーズ・インコーポレーテッド データストリーム取り込み及び永続性ポリシ
JP2017532702A (ja) * 2014-09-15 2017-11-02 マイクロソフト テクノロジー ライセンシング，エルエルシー 向上したイベント処理のための構築されたデータストリーム
JP2016110620A (ja) * 2014-12-05 2016-06-20 知意圖股▲分▼有限公司 ビッグストリームデータのリアルタイム処理方法、ストリームデータ処理エンジン及びビッグストリームデータのリアルタイム処理システム
JPWO2016157271A1 (ja) * 2015-03-27 2018-02-01 日本電気株式会社 センサネットワークシステム
CN110543496A (zh) * 2019-09-06 2019-12-06 中国联合网络通信集团有限公司 用于时序数据库集群的数据处理方法和装置

Similar Documents

Publication Publication Date Title
WO2013069073A1 (ja) 時系列データ管理システム、装置および方法
CN101902505B (zh) 一种分布式dns查询日志的实时统计装置及方法
WO2012086824A1 (ja) 運用管理装置、運用管理方法、及びプログラム
US20030033155A1 (en) Integration of data for user analysis according to departmental perspectives of a customer
Mitzenmacher Analyzing distributed join-idle-queue: A fluid limit approach
CN102713861A (zh) 操作管理装置、操作管理方法以及程序存储介质
US8892726B2 (en) Apparatus and method for tracking requests in a multi threaded multi tier computerized environment
US20100017486A1 (en) System analyzing program, system analyzing apparatus, and system analyzing method
CN107798460A (zh) 用于处理在连续工艺中获得的数据的智能工厂平台
US20160085655A1 (en) Monitoring system, monitoring device, and monitoring method
JP2018036991A (ja) センサデータ検索システム、センサデータ検索方法及び管理計算機
US11243951B2 (en) Systems and methods for automated analysis, screening, and reporting of group performance
CN107491463A (zh) 数据查询的优化方法和系统
CN116701330A (zh) 物流信息共享方法、装置、设备及存储介质
CN109560940B (zh) 一种内容分发网络cdn服务的计费方法及装置
WO2016127854A1 (zh) 一种信息处理方法及装置
RU2646374C1 (ru) Анализ данных датчиков для множества пользователей
JP6271089B2 (ja) サービス連携システムおよびサービス連携方法
US20140059077A1 (en) Data Processing
Liu et al. Parallelizing uncertain skyline computation against n‐of‐N data streaming model
US20100017401A1 (en) Recording medium storing system analyzing program, system analyzing apparatus, and system analyzing method
JP6634938B2 (ja) 分析支援方法、分析支援プログラムおよび分析支援装置
US20210042328A1 (en) Partitioning data in a clustered database environment
CN111291991B (zh) 绩效值的计算方法、装置、设备及可读存储介质
Rakhmawati et al. On Metrics for Measuring Fragmentation of Federation over SPARQL Endpoints.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11875347

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11875347

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP