WO2014181475A1 - 複数バージョンのデータを格納するデータベースサーバ、及び、データベース管理方法 - Google Patents

複数バージョンのデータを格納するデータベースサーバ、及び、データベース管理方法 Download PDF

Info

Publication number
WO2014181475A1
WO2014181475A1 PCT/JP2013/063213 JP2013063213W WO2014181475A1 WO 2014181475 A1 WO2014181475 A1 WO 2014181475A1 JP 2013063213 W JP2013063213 W JP 2013063213W WO 2014181475 A1 WO2014181475 A1 WO 2014181475A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
database
data acquisition
version
merge policy
Prior art date
Application number
PCT/JP2013/063213
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/JP2013/063213 priority Critical patent/WO2014181475A1/ja
Priority to US14/768,078 priority patent/US20150379065A1/en
Publication of WO2014181475A1 publication Critical patent/WO2014181475A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/219—Managing data history or versioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/248—Presentation of query results

Definitions

  • the present invention relates to a database server and a database method, and more particularly to a technique for managing time-series data in a database server storing a plurality of versions of data.
  • the database server has a database inside, and has a database management server and a database processing device as a system for managing the database.
  • a technique for managing database time-series data a technique for automatically deleting unnecessary time-series data from a database file is known.
  • the database server includes time series data search means, unnecessary data deletion selection means, unnecessary data deletion means, etc., and when old time series data and new time series data exist on the database, the old time series
  • a method for deleting only data in a time zone overlapping with new time series data is disclosed.
  • the invention of Patent Document 1 makes it possible to automatically store time-series data at a required time in the same database file when deleting unnecessary time-series data from the database file. The purpose is to eliminate the need to check the version of time series data.
  • the database processing apparatus has an old version database definition and a new version database definition, and can select either the old version or new version definition information at the time of access request. It has an access selection means, and further has a mechanism for rewriting the information of the old version to the new version when the definition change process is confirmed.
  • Such automated processes include, for example, a process for detecting a sign of abnormality and a process for finding the root cause from a plurality of abnormalities (Root Cause Analysis, hereinafter referred to as RCA).
  • RCA Root Cause Analysis
  • FIG. 20A is a diagram schematically showing a state in which time-series data (raw data) before processing is processed in stages by a plurality of analysis programs and stored in a database as time-series data.
  • abnormal data in the database obtained as a result of processing by the “abnormality detection processing” program as an analysis program, RCA processing is performed as subsequent processing to generate abnormal data dependency information and “abnormal data” As for “,” a search index creation process is performed to generate “abnormal data for search”.
  • FIG. 20B is a diagram schematically illustrating a version upgrade procedure of a conventional analysis program.
  • the raw data is processed by the analysis program “Abnormality Detection Processing” (Ver. 1), and the data (abnormal data: (Ver. 1)) is generated by the subsequent analysis programs “RCA Processing” and “Search Index”. Used by “creation process”.
  • the analysis programs such as “RCA processing” and “search index creation processing” are referred to as subsequent processing of a certain analysis program (in this example, “abnormality detection processing”).
  • the length of the period during which the subsequent processing continues to require the analysis results (“Abnormal data (ver. 1)" in Fig. 20B) created by the old analysis program (Ver. 1) is "RCA processing", etc. It depends on the content of the process. Therefore, if the analysis result created by the old analysis program is deleted without confirmation from the developer of the subsequent process, the subsequent process may be adversely affected. However, when the number of subsequent processes is large, or when the subsequent processes are in multiple stages, it is difficult to accurately report the analysis results that need to be left to the developer of the subsequent processes.
  • the database server deletes all data in a time zone that overlaps with new time-series data regardless of the contents of subsequent processing. Therefore, when it is assumed that the invention of Patent Document 1 is applied to management of time-series data in which a plurality of monitoring automation technologies are combined, there is a possibility of adversely affecting subsequent processing.
  • Patent Document 2 has a function of rewriting information of an old version to a new version, it does not provide a means for finding data that can be deleted from the data of the old and new versions. In other words, the invention of Patent Document 2 is not supposed to delete unnecessary time-series data.
  • One of the problems to be solved by the present invention is that a database server that stores multiple versions of time-series data can be deleted from data created by an old analysis program in a manner that does not rely on self-declaration of the developer of subsequent processing.
  • the object is to provide a time-series data management technique for automatically extracting data.
  • the database server includes a database capable of storing a plurality of versions of data for various types of time series data, and a database management server that manages the database.
  • the database management server includes: A search unit capable of designating a merge policy in which a policy for determining whether or not to allow mixing of data of a plurality of versions is defined, and the search unit includes a time range included in the search condition based on the designated merge policy A result of merging the data of the plurality of versions is generated as a data acquisition history, and the data acquisition history is recorded in the database.
  • a database server that stores a plurality of versions of time-series data
  • data created by an old analysis program within a time range included in a search condition is automatically deleted, and the disk usage of the database server Can be automatically minimized.
  • FIG. 2 is a diagram schematically showing a database server according to the first embodiment of the present invention. It is an example expressing the mutual relationship of a plurality of merge policies in the present invention.
  • FIG. 6 is a diagram for explaining operations of a search unit 1 and a data registration unit of the analysis server and the database management server in the first embodiment.
  • FIG. 5 is a diagram showing an example of time-series data in the first embodiment.
  • FIG. 6 is a diagram showing an example of a data acquisition history in the first embodiment.
  • FIG. 3 is a diagram schematically showing a method for upgrading an analysis program in the first embodiment.
  • FIG. 6 is a diagram for explaining operations of a non-deletable data finding unit and a deletable data display unit of the database management server in the first embodiment.
  • FIG. 6 is a flowchart of a non-deletable data discovery program in the first embodiment.
  • 6 is a flowchart of a non-deletable data discovery program in the first embodiment.
  • 6 is a diagram illustrating an example of a data acquisition history in which a target time range is changed to a relative time in the first embodiment.
  • FIG. FIG. 5 is a diagram showing an example of data that cannot be deleted in the first embodiment.
  • FIG. 5 is a diagram showing an example of a data acquisition pattern in the first embodiment.
  • FIG. 6 is a diagram schematically showing a state in which a plurality of versions of time-series data exist on a database in the first embodiment.
  • FIG. 5 is a diagram schematically showing a state in which a plurality of versions of time-series data are classified into non-deletable data and deletable data in the first embodiment.
  • FIG. 6 is a diagram showing an example of screen display by a erasable data display program in the first embodiment.
  • FIG. 6 is a diagram showing an example of a screen display by a erasable data display program in the first embodiment.
  • FIG. 10 is a functional block diagram showing an internal structure of a database management server in a second embodiment of the present invention.
  • FIG. 10 is a diagram showing an example of screen display by a erasable data display program in the second embodiment.
  • FIG. 10 is a functional block diagram showing an internal structure of a database management server in a third embodiment of the present invention.
  • FIG. 12 is a flowchart of a merge policy change plan creation program in the third embodiment.
  • FIG. 20 is a diagram showing an example of screen display by a merge policy change plan display program in the third embodiment. It is a figure which shows typically a mode that time series data are processed in steps by a some analysis program. It is a figure which shows typically the upgrade procedure of the conventional analysis program.
  • the database management server of the present invention makes it mandatory to declare a merge policy as to whether or not to allow mixing of multiple versions of time-series data in a database in a data acquisition request for subsequent processing.
  • the database management server determines whether the latest version of the time series data, the old version of the time series data, or the latest version according to the given merge policy and the time series data of each version existing on the database at that time. Return time-series data with a mixture of old versions to subsequent processing.
  • the database management server of the present invention records an acquisition history of data including the merge policy. Then, based on these data acquisition histories, the time series data of the database created by the old analysis program is found that can be deleted. The database management server presents the data that can be deleted to the database administrator, or automatically deletes the time series data from the database.
  • the database management server of the present invention calculates the merge policy change proposal specified by the subsequent processing and the amount of data that can be reduced when the merge policy is changed based on the data acquisition history.
  • the database management server presents these merge policy change proposals to the developer of the subsequent process, or automatically applies these policy change proposals to the database management server.
  • the database management server of the present invention in a database server storing multiple versions of time-series data, time-series data created by an old analysis program is automatically deleted from the database, and the disk usage of the database server is automatically Can be minimized.
  • the database management server of the present invention does not allow the subsequent processing of the analysis server to specify the version number and acquire the time series data of the database created by the old analysis program. This is because if the database management server permits the acquisition of the subsequent process with the specified version number, the subsequent process may continue to use the old version of the time-series data.
  • the database management server of the present invention will explain why the time series data created by the old analysis program can be deleted and why it is better to change the merge policy of the subsequent processing. Can be presented to the developer or subsequent developer. Therefore, a user such as a database administrator can shorten the work time for determining data to be actually deleted from the database by using the presented information.
  • FIG. 1 schematically shows a database server assumed in the first embodiment.
  • the internal structure of the database management server is shown as a functional block diagram.
  • the database server assumed in the present invention has an analysis server and a database management server.
  • the analysis server analyzes the database and returns the result to the application.
  • the database server includes a database management server 2, a database 3, a raw data generation server 4, an analysis server 5, and an administrator terminal 6. These devices are connected to the network 1 through a physical communication line 7.
  • the database management server 2 is a server that manages data input / output with respect to the database 3 to be described later.
  • the database management server 2 has a function of finding data that can be deleted from data created by an old analysis program.
  • the database management server 2 transmits and receives packets through the interface (I / F) 21.
  • Each program of the database management server 2 is stored in the memory 23, and the CPU 22 reads and executes them through the data path 24 during operation.
  • the memory 23 stores a data acquisition program 231, a data registration program 232, a non-deletable data discovery program 233, and a deletable data display program 234.
  • the computer can be used as search means or data acquisition means (231), data registration means (232), non-deletable data. It functions as a discovery means (233) and a deleteable data display means (234).
  • the database 3 is a database that stores time series data 3000 and acquisition request history (hereinafter, data acquisition history) 3100 for these time series data.
  • the database 3 also temporarily stores data 3450 that can be deleted as necessary.
  • the raw data generation server 4 is a server that generates time series data (raw data) to be analyzed and registers the data in the database 3.
  • raw data generation servers 4 there are a plurality of raw data generation servers 4 (4-1, 4-2, ⁇ -).
  • the raw data generation server include a Web application server in which agent software that measures server performance information (CPU usage rate, etc.) operates, and a small device that records values (temperature, etc.) measured by sensors.
  • the raw data generation server 4 does not need to specify a version number when registering data in the database 3. However, the version number may be specified in the same manner as the analysis server 5. In this case, the old version of the raw data is also subject to deletion.
  • the analysis server 5 is a server in which a plurality (5-1, 5-2,-) exist, and one or more analysis programs 5100 each operate.
  • the analysis program (analysis means) 5100 acquires time series data (data registered by the raw data generation server 4 or data registered by the analysis server 5) from the database 3, and performs some processing on these data. This processing includes creation of a Web page for displaying the monitoring result on the Web browser.
  • the analysis program can also register the analysis result in the database 3 as time series data of a different type (that is, having a different name) from the acquired time series data. When an analysis program registers data in the database 3, it is necessary to specify the version number of the analysis program.
  • the analysis server 5 also includes means 5102 for setting a search condition and a merge policy as part of the analysis program function.
  • the administrator terminal 6 includes a display unit 61 with a GUI function.
  • the administrator terminal 6 displays a display screen (1100). It is the terminal which operates via.
  • the user confirms the output of the program operating on the database management server 2 through client software (such as a Web browser) operating on the administrator terminal 6.
  • client software such as a Web browser
  • the user appropriately sets search conditions in the analysis server 5, parameters relating to the merge policy, and the like through the administrator terminal 6.
  • the analysis server 5 operates the analysis program based on the set search conditions and merge policy.
  • the present invention can be applied to a distributed database.
  • Search means or data acquisition means (hereinafter, search means) 231 is a program that returns time-series data on the database 3 in response to a data acquisition request from the analysis means operating on the analysis server 5.
  • the analysis means must always include a policy (hereinafter referred to as a merge policy) as to whether or not mixing of multiple versions of data is allowed in the data acquisition request.
  • a merge policy a policy that specifies a merge policy as to whether or not mixing of multiple versions of data is allowed in the data acquisition request.
  • the search unit 231 rejects the data acquisition request or processes the data acquisition request using a default merge policy. Then, the search means records the history of the data acquisition request including this merge policy in the database 3.
  • the contents of the merge policy include, for example, “Which priority should be given to the latest version data or the version data that exists for the longest time in the time range included in the search condition?” Whether or not search is interrupted when merging of multiple versions of data occurs, and whether or not priority is given to the same version as data acquired in the past.
  • the following merge policies 1 to 6 are used as specific examples.
  • Merge policies 1, 2, and 6 are This is an example of a merge policy for merging multiple versions of data.
  • merge policies 3, 4, and 5 are examples of merge policies that do not perform merging.
  • Merge policies 1, 3, and 6 are examples of merge policies that prioritize the latest version of data.
  • the merge policy 5 is an example of a merge policy in which the search is not continued when a merge of a plurality of versions of data occurs.
  • the merge policy 6 is an example of a merge policy that prioritizes the same version as the data acquired in the past.
  • FIG. 2A is an example expressing the mutual relationship of the plurality of merge policies.
  • the analysis means 5100 must determine this merge policy (S20).
  • the plurality of merge policies can be classified into two according to “whether or not to merge data of a plurality of versions” (S21).
  • the merge policy 1 gives priority to the latest version of data within the time range included in the search condition (YES in S22).
  • the merge policy 2 gives priority to the version data that exists for the longest time in the range (YES in S23).
  • the merge policy 6 gives priority to the same version as the data acquired in the past (YES in S24).
  • the merge policy 7 is one in which a specific condition is set when none of these is satisfied (NO in S24).
  • the merge policy 3 gives priority to the latest version data (YES in S25).
  • the merge policy 4 gives priority to the version of data that exists for the longest time in the range (YES in S26).
  • the merge policy 5 that gives priority to the same version as the data acquired in the past (YES in S27) interrupts the search (S28).
  • the merge policy 8 is one in which a specific condition is set when none of these is satisfied (NO in S27).
  • merge policies that are considered to be particularly practical are listed among possible merge policies.
  • the analysis server 5 designates a numerical value of 1 to 6 or sets an additional condition of 7 to 8 as a merge policy for the search unit 231.
  • the method of expressing the merge policy is not limited to this, and may be extended without departing from the spirit of the present invention.
  • the merge policy is not a single integer, but may be a set of multiple Boolean values.
  • the merge policy may have a parameter.
  • the search unit 231 may apply a fixed merge policy according to the transmission source of the data acquisition request.
  • the database administrator describes a fixed merge policy in the setting file on the database management server using the request source program name, the request source IP address, and the port number as keys. Then, each time the data acquisition request is received, the search unit 231 may refer to the setting file and determine the merge policy.
  • this method requires the developer of the subsequent process to have the authority to edit the configuration file on the database management server.
  • the data registration means 232 is a program for registering time series data in the database 3 in response to a data registration request from software operating on the raw data generation server 4 or an analysis program operating on the analysis server 5.
  • a data registration request from an analysis program must always include the version number of the analysis program.
  • the data registration unit 232 may apply a fixed version number according to the data transmission source. For example, the database administrator writes a fixed version number in the setting file on the database management server using the transmission source program name, the transmission source IP address, and the port number as keys. The data registration unit 232 may determine the version number by referring to the setting file every time a data registration request is received. However, this method requires the developer of the subsequent process to have the authority to edit the configuration file on the database management server.
  • FIG. 2B is a diagram for explaining the operation of the search means 231 and the data registration means 232 of the analysis server 5 and the database management server 2.
  • the analysis server 5 activates the search unit 231 of the database management server 2, searches the time series data 3000 of the database 3 based on the given search condition and merge policy, and the search result is stored in the database by the data registration unit 232. 3 is stored in the data acquisition history 3100.
  • Database 3 stores data in a table format.
  • the embodiment of the present embodiment is not limited to tabular data.
  • the time-series data 3000 includes time-series data (raw data) generated by the raw data generation server 4 and registered in the database 3, and time-series data generated by the analysis server 5 (results of analyzing raw data or some analysis) Results of further analysis of the results).
  • Fig. 3A is an example of time-series data 3000.
  • a column 3001 of the time series data 3000 indicates times associated with the time series data. This time may be the time when the time series data is created, or may be the time indicating the beginning of the time zone indicated by the time series data.
  • a column 3002 is the name of the time series data. In the following example, the name of the CPU usage rate registered by the raw data generation server 4 is “CPU usage rate”, and the name of the analysis result registered by the analysis program “abnormality detection processing” operating on the analysis server 5 is “abnormal data”.
  • a column 3003 is a version number of the time series data. A blank or fixed value is stored in the column 3003 of the data (rows 3011 to 3012) registered by the raw data generation server 4.
  • the column number 3003 of the machining data (rows 3021 to 3051) registered by the analysis program stores the version number of the analysis program that created the machining data.
  • the version number in this column 3003 is the version number of the analysis program that created the time series data.
  • the analysis program version number and the time series data version number do not necessarily have a one-to-one correspondence.
  • a column 3004 is data other than the time included in the time series data. In this example, data other than the time is shown as a key-value pair.
  • the row 3011 indicates that the CPU usage rate acquired from the server with the host name host1 at 10.0 hours 00:00 on October 1, 2012 is 10.0%.
  • lines 3021-3031 in which the time-series data name is “abnormal data” indicate that the CPU usage rate is rapidly increasing.
  • Fig. 3B is an example of the data acquisition history 3100.
  • the data acquisition history 3100 is a data acquisition history generated by the search unit 231 when the search unit 231 receives a data acquisition request from the analysis server 5.
  • a column 3101 is a time when the search unit 231 receives the data acquisition request.
  • a column 3102 is a name for uniquely identifying the program that transmitted the data acquisition request. Instead of such a name, another character string (such as a transmission IP address of a data acquisition request) that can uniquely identify a program in the system may be used.
  • a column 3103 is the name of the time series data targeted by the data acquisition request.
  • Column 3104 is the number of the merge policy specified in the data acquisition request.
  • a column 3105 is a time range specified by the data acquisition request.
  • a column 3106 is a search condition other than the time specified in the data acquisition request. That is, the column 3104 is a merge policy, and the columns 3105 and 3106 are data search conditions.
  • a column 3107 is a version number of time series data returned as a result of the data acquisition request. When a plurality of versions of data are merged by the merge policy, a version number for each period is recorded as in a row 3121.
  • FIG. 4 is a diagram schematically showing a method for upgrading the analysis program 5100 according to the first embodiment.
  • there are two analysis programs (“RCA processing” and “search index creation processing”) as subsequent processing of the analysis program “abnormality detection processing” 5100.
  • the search means 231 switches the data reading destination (switching from abnormal data ver. 1 to ver. 2).
  • the non-deletable data discovery means 233 of the database management server 2 is a program for discovering non-deletable time series data based on the data in the database 3.
  • This program is started by a database administrator or an analysis program developer via the administrator terminal 6, or automatically started by a job scheduler such as cron available in Linux (registered trademark).
  • This program passes the generated data to the deleteable data display program.
  • the deleteable data display means 234 of the database management server 2 provides the database administrator or the analysis program developer (user) with information on deleteable time-series data based on the data generated by the non-deleteable data discovery means 233. Present. Alternatively, this program automatically deletes time series data determined to be deleteable.
  • FIG. 10 is a diagram schematically showing a state in which time-series data of four versions (Ver.1, Ver2, Ver3, Ver4) exists in the database.
  • Ver. 1 is the version that has existed for the longest period
  • Ver 4 is the latest version of the program.
  • FIG. 5 is a diagram for explaining the operation of the non-deletable data finding means 233 and the deletable data display means 234 of the database management server 2.
  • the non-deletable data discovery means 233 generates a data acquisition history (relative time) 3200 in which the target time range of the data acquisition history 3100 is converted into a relative time based on the time series data 3000 of the database 3, and the non-deletable time series The data is discovered, and two types of information (non-deletable data 3300 and data acquisition pattern 3400) regarding the non-deletable time series data are generated.
  • the data acquisition history 3200 (see FIG. 7) is obtained by converting the target time range 3105 of the data acquisition history 3100 of FIG. 3B into a relative time range 3205.
  • the non-deletable data 3300 (see FIG. 8) is data indicating the name, version number, target time range, and the like of time series data that should not be deleted. This data is essential for the deletion data display means 234 to operate.
  • the data acquisition pattern 3400 (see FIG. 9) is data indicating the contents of past data acquisition, which is the reason why the time series data indicated by the non-deletable data 3300 should not be deleted. This data is not indispensable data for the deleteable data display means 234 to operate.
  • the deleteable data display means 234 has an effect that it can present a specific reason why some time series data cannot be deleted to the system administrator or the developer of the analysis program. .
  • the non-deletable data finding means 233 passes these non-deletable time series data to the deletable data display means 234.
  • FIGS. 6A to 6B are flowcharts for the non-deletable data discovery means 233 to discover non-deletable time-series data (deletable data 3300, data acquisition pattern 3400) from the data acquisition history 3100.
  • FIGS. 6A to 6B are flowcharts for the non-deletable data discovery means 233 to discover non-deletable time-series data (deletable data 3300, data acquisition pattern 3400) from the data acquisition history 3100.
  • the non-deletable data discovery means 233 first acquires a set of target data 3103 included in the data acquisition history 3100 from the database (S101).
  • this set of target data is referred to as TDS.
  • TDS this set of target data
  • only “abnormal data” is included in the TDS.
  • the processing of S104 to S128 is performed on each target data (hereinafter referred to as TD) included in the TDS (S102 to S103).
  • the non-deletable data finding means 233 acquires all the data acquisition histories 3100 in which the target data matches the TD and the merge policy is 6 from the database 3 (S104). These are data acquisition histories including the merge policy 6 "prioritize the same version as data acquired in the past". Hereinafter, this list of data acquisition histories is referred to as DHL1. In the example of the data acquisition history 3100 in FIG. 3B, the data acquisition history of rows 3111 to 3112 is included in DHL1.
  • the non-deletable data finding means 233 creates non-deletable data 3300 based on the data acquisition history included in DHL1. Then, the created data is added to a list (hereinafter referred to as UDL) of non-deletable data 3300 in the memory (S105).
  • FIG. 8 is an example of the non-deletable data 3300.
  • a column 3301 is an identifier uniquely assigned to each non-deletable data by the non-deletable data finding unit 233.
  • a column 3302 is a name of time series data that should not be deleted.
  • a column 3303 is a version number of time series data that should not be deleted.
  • a column 3304 is a target time range of time series data that should not be deleted.
  • a column 3305 is a data amount of time series data indicated by the columns 3302 to 3304.
  • the non-deletable data finding means 233 obtains the data of the non-deletable data 3300 columns 3302, 3330, and 3304 based on the data of the column 3103, column 3105, and column 3107 of the data acquisition history 3100. create.
  • the non-deletable data ID in the column 3301 is newly assigned by the non-deletable data finding means 233.
  • the data amount in the column 3305 is newly calculated by the non-deletable data finding means 233 searching the time series data 3000.
  • a set of the column 3302, the column 3303, and the column 3304 is always unique. For example, even if there are a plurality of rows 3111 of the data acquisition history 3100, only one row 3311 of the non-deletable data 3300 is created.
  • non-deletable data discovery means 233 creates a data acquisition pattern 3400 corresponding to the non-deletable data created in S105 based on the data acquisition history included in DHL1. Then, the created data is added to a list of data acquisition patterns (hereinafter referred to as DRPL) on the memory (S106).
  • DRPL data acquisition patterns
  • FIG. 9 shows an example of the data acquisition pattern 3400.
  • a column 3401 is an identifier uniquely assigned to each data acquisition pattern by the non-deletable data finding unit 233.
  • a column 3402 is an identifier of non-deletable data corresponding to the data acquisition pattern.
  • the row 3414 of the data acquisition pattern 3400 shows time series data in the target time range of the column 3304 indicated by the rows 3314 to 3315 of the non-deletable data 3300 in FIG. 8 because the data acquisition request indicated by this row has been made in the past. Indicates that cannot be deleted.
  • a column 3403 is a name of a program that has executed the data acquisition pattern in the past.
  • Columns 3404 to 3406 are a merge policy, a target time range, and a narrowing condition of past data acquisition requests indicated by the data acquisition pattern.
  • a column 3407 indicates the number of times a past data acquisition request indicated by the data acquisition pattern is made.
  • the non-deletable data discovery means 233 creates data of columns 3403 to 3406 of the data acquisition pattern 3400 based on the data of columns 3102 to 3106 of the data acquisition history 3100.
  • the pattern ID of the column 3401 is newly assigned by the non-deletable data finding means 233.
  • the non-deletable data ID in the column 3402 stores the non-deletable data ID created by the non-deletable data discovery means 233 in S105.
  • a plurality of non-deletable data is created in S105, a plurality of non-deletable data IDs are stored here.
  • the number of times of the column 3407 stores the number of data acquisition histories for the time series data indicated by the non-deletable data created in S105.
  • the non-deletable data discovery means 233 acquires all data acquisition histories whose target data matches the TD and whose merge policy is 2, 4, or 5 from the database (S111). These are data acquisition histories including a merge policy that “priorizes the version data that exists for the longest time over the latest version data”. Below, this list of data acquisition histories is called DHL2. In the example of the data acquisition history 3100 in FIG. 3B, the data acquisition history of rows 3121 to 3123 is included in DHL2.
  • the non-deletable data finding means 233 generates a data acquisition history (relative time) 3200 in which the target time range of the data acquisition history 3100 is converted to a relative time (S112).
  • the data acquisition history of the rows 3121 to 3123 is converted into the rows 3221 to 3223 of the data acquisition history 3200 of FIG.
  • the columns 3202 to 3204 and the column 3206 in the data acquisition history 3200 in FIG. 7 have the same meaning as the columns 3102 to 3104 and the column 3106 in the data acquisition history 3100 in FIG. 3B.
  • a column 3205 is obtained by converting the data of the target time range (absolute time) in the column 3105 in FIG. 3B into a relative time from the request date and time in the column 3101. When performing this conversion, taking into account small differences in the request date and time, it is difficult to see the tendency of data acquisition that is frequently performed. Therefore, the non-deletable data finding unit 233 may round down or round up times less than or equal to minutes in the column 3101 or times less than seconds.
  • the time below the minute in the column 3101 is rounded down, the column 3101 and the column 3105 are compared, and the data of the target time in the column 3105 is converted into a relative time.
  • the non-deletable data finding means 233 may perform the same abstraction for the target time range. For example, a search for time series data 30 days ago and a search for time series data 31 days ago may both be abstracted as “search for time series data one month ago”.
  • the non-deletable data finding means 233 selects the data acquisition history requesting the data at the smallest time (that is, the past) from the data acquisition history 3200 included in the DHL 2 (S113).
  • the target time range is “(7 days before request date and time) or more and less than (request date and time)” and 2 data “(14 days before request date and time) or more and less than (7 days before request date and time)”
  • the non-deletable data finding means 233 selects the latter.
  • the rows 3121 to 3123 of the data acquisition history 3100 in FIG. 3B these are converted to exactly the same content (lines 3221 to 3223 in the data acquisition history 3200 in FIG. 7) by abstraction. Therefore, the non-deletable data finding means 233 selects any one from the rows 3221 to 3223 of the data acquisition history 3200 in FIG. In the following, it is assumed that row 3221 has been selected.
  • the non-deletable data finding unit 233 identifies the version in which data is present for the longest period (S114). Assuming that the current time is 12/17 00:00, the result of applying the current time to the target time range indicated by row 3221 of the data acquisition history 3200 is "12/10 00:00 or more, less than 12/17 00:00" It becomes.
  • the version number with the longest data in this time range is 3.
  • the latest version is selected.
  • the non-deletable data finding means 233 applies the current time to the start time of the target time range included in the data acquisition history selected in S113 (S116). Then, for the version specified in S114, all data after the time calculated in S116 is added to the UDL (S117). For example, the non-deletable data in the row 3313 in FIG. 8 is created from the row 3221 in FIG. Further, the non-deletable data finding means 233 calculates the data amount of the non-deletable data by the same method as S105.
  • the non-deletable data discovery means 233 creates a data acquisition pattern corresponding to the non-deletable data created in S117 based on the data acquisition history selected in S113, and adds it to the DRPL (S118). For example, the data acquisition pattern of the row 3413 of the data acquisition pattern 3400 of FIG. 9 is created from the non-deletable data of the row 3221.
  • the non-deletable data discovery means 233 acquires all data acquisition histories whose target data matches the TD and whose merge policy is 1, 2, 4 or 5 from the database (S121). These are data acquisition histories including a merge policy “which may acquire past versions of data”. Below, this list of data acquisition histories is called DHL3. In the example of FIG. 3B, the data acquisition history of rows 3121 to 3134 is included in DHL3.
  • the non-deletable data finding means 233 converts the target time range for the data acquisition history included in DHL3 into a relative time from the request date (S122). This process is the same as S112.
  • the data acquisition history of rows 3121 to 3134 is converted into rows 3221 to 3234 of FIG.
  • the non-deletable data finding means 233 selects the data acquisition history requesting the data at the smallest time (that is, the past) from the data acquisition history included in the DHL 3 (S123). If there are a plurality of data request histories with the same narrowing conditions that request the data at the smallest time, all of them are selected. This process is the same as S113.
  • the data acquisition histories requesting the data with the smallest (oldest) time are the rows 3231 to 3234 until the target period is “one month ago”. In the following, it is assumed that two lines 3231 and 3232 are selected in these acquisition histories.
  • the non-deletable data finding means 233 applies the current time to the start time of the target time range included in the data acquisition history selected in S123 (S124). Then, the non-deletable data finding means 233 identifies the latest version in which data exists for each time zone after the time calculated in S124 (S125). In the example of FIG. 10, the latest version in the time period from 11/161100: 00 to 12/1 00:00 until the target period is “one month ago” is 2. The latest version is 3 from 12/1 1200: 00 to 12/14 00:00. The latest version after that time is 4.
  • the non-deletable data finding means 233 adds all the data after the time calculated in S124 for the version specified in S125, here, versions 2 to 4, to the UDL (S127). For example, from the row 3231 and the row 3232 in FIG. 7, the non-deletable data in the rows 3314 to 3315 in FIG. Further, the non-deletable data finding means 233 calculates the data amount of the non-deletable data by the same method as S105.
  • the non-deletable data discovery means 233 creates a data acquisition pattern 3400 corresponding to the non-deletable data created in S127 based on the data acquisition history selected in S123, and adds it to the DRPL (S128).
  • the data acquisition patterns of rows 3414 to 3415 of FIG. 9 are created from the non-deletable data of rows 3231 to 3232 of FIG.
  • the above is the outline of the process in which the non-deletable data discovery means 233 discovers the non-deletable time series data 3300.
  • the non-deletable data finding unit 233 passes the above-mentioned UDL and DRPL to the deletable data display unit 234.
  • FIG. 11 is a diagram schematically showing the relationship between the non-deletable data 3300 and the deletable data 3400 in multiple versions on the database.
  • the non-deletable data discovery means 233 sets the area of each version hatched in FIG. 11 as UDL. Output.
  • the non-deletable data UDL (1) to (5) in FIG. 11 corresponds to the non-deletable data (1) to (5) in FIG.
  • the non-hatched area is data that can be deleted (hereinafter, data that can be deleted 3450).
  • data that can be deleted 3450 data that can be deleted 3450
  • FIG. 12 is a diagram showing an example of the screen display 1100 by the erasable data display means in the first embodiment.
  • reference numeral 1101 denotes a tab indicating the name of time series data that can be deleted. This tab is displayed for the number of types of time series data that can be deleted.
  • An area 1102 shows details of time series data that can be deleted. When the user selects the tab 1101, the details of the time-series data that can be deleted among the types are displayed in the frame of the area 1102.
  • Reference numeral 1103 denotes an area indicating the data amount of deleteable data 3450 and non-deleteable data 3400 in each of a plurality of versions. The non-deletable data is generated based on the UDL.
  • the deleteable data 3450 is generated by dividing the data amount of the non-deleteable data 3400 from the total data amount of the data of each version.
  • the total data amount of each version of data may be calculated by the erasable data display means 234 when the screen is displayed, or may be calculated in advance by another program.
  • Reference numeral 1104 denotes an area indicating details of the non-deleteable data 3400. The contents of the UDL are displayed as they are in this area.
  • Reference numeral 1105 denotes a button for deleting all deleteable data 3450 at once. When the user presses this button, the erasable data display means deletes all data other than the non-deletable data 3400 shown in the area 1104.
  • Reference numeral 1106 denotes a button for closing this screen without actually performing deletion.
  • the deleteable data display means 234 can present to the user the reason why the respective data that cannot be deleted 3400 cannot be deleted. For example, when the “details” button included in the area 1104 in FIG. 12 is pressed, the reason can be presented.
  • FIG. 13 is a diagram showing an example of detailed display of the non-deletable data 3400 by the deletable data display means in the first embodiment.
  • Reference numeral 1201 denotes an area indicating information of the non-deletable data 3400 which shows details on this screen.
  • An area 1202 indicates a pattern of data acquisition performed in the past, which is the reason why the data cannot be deleted. In this area, the contents of DRPL are displayed as they are.
  • Reference numeral 1203 denotes a “return” button.
  • the deleteable data display means displays the details of the non-deleteable data 3400 in the area 1104. This is to make it easier to display a menu (“details” button) for displaying a data acquisition pattern (FIG. 13) corresponding to data that cannot be deleted. However, the deleteable data display means may display the details of the deleteable data 3450 in this area.
  • the erasable data display means 234 can present the erasable data included in a plurality of versions of time series data on the display screen to the database managers. Further, the deleteable data display means 234 can present the reason why the data created by the old analysis program can be deleted to the database managers on the display screen. According to this embodiment, in a database server that stores multiple versions of time-series data, each version of time-series data is displayed on the display screen separately as non-deletable data and non-deletable data. Since the data to be deleted is determined at the user's discretion, the user can easily minimize the amount of data created by the old analysis program on the database server.
  • non-deletable data finding unit 233 and the deletable data display unit 234 may be automatically activated. These programs may be automatically performed until deletion of the deleteable data 3450 is performed. These programs can be started automatically by a method that is periodically started by the job scheduler, some event (for example, a new version of data is registered for the first time, or the disk usage of the database exceeds the threshold. There is a way to start it. As described above, according to this embodiment, in the database server that stores multiple versions of time-series data, the data created by the old analysis program is automatically deleted, and the disk usage of the database server is automatically minimized. It can also be converted.
  • FIG. 14 is a functional block diagram showing the internal structure of the database management server in the second embodiment.
  • the internal structures of the database server and the database management server 2 assumed in the second embodiment are the same as those in the first embodiment.
  • a stopable analysis process discovery / display program stoppable analysis process discovery / display means 237 is provided.
  • the analysis program that can be stopped is presented to the database administrator and the developer of the analysis program.
  • FIG. 15 is a diagram showing an example of a screen display 1100 by the erasable data display means 234 and the analysis process discovery / display means 237 that can be stopped in the second embodiment. 1101 to 1106 are the same as the screen display (FIG. 12) in the first embodiment.
  • 1107 is an area indicating the version of the analysis program that can be stopped.
  • a version number in which the non-deletable data 3400 does not exist for a certain period in the past (for example, one day) from the current time is displayed.
  • the stopable analysis processing discovery / display unit 237 displays the version numbers 1 and 2 as the version number of the stopable analysis program.
  • the discontinuable analysis process discovery / display means 237 contacts the developer of the specified version of the analysis program, sends a stop instruction to the specified version of the analysis program, Alternatively, data registration from the specified version of the analysis program is rejected.
  • the analysis processing discovery / display unit 237 that can be stopped presents a version that can be stopped in the analysis program to the database administrator or the developer of the analysis program on the display screen. be able to. It should be noted that the function of the analysis process discovery / display unit 237 that can be stopped and the function of the erasable data display unit 234 may be combined to constitute one erasable data display unit 234.
  • non-deletable data discovery unit 233, the deletable data display unit 234, and the analysis process discovery / display unit 237 that can be stopped may be automatically activated. These programs may be automatically executed until the old version of the analysis program is stopped. These programs can be started automatically by a method that is periodically started by the job scheduler, some event (for example, a new version of data is registered for the first time, or the disk usage of the database exceeds the threshold. There is a way to start it. Thus, when the activation of these programs is automated, the work time for the database managers to determine the analysis program to actually stop can be reduced to zero. As a result, an effect of reducing operational costs of a database for storing time series data and an analysis server for creating time series data can be obtained.
  • the database server assumed in the third embodiment is the same as that in the first and second embodiments.
  • the internal structure of the database management server 2 is different from those in the first and second embodiments.
  • FIG. 16 is a functional block diagram showing the internal structure of the database management server in the third embodiment.
  • the database management server 2 transmits and receives packets through the interface (I / F) 21.
  • Each program of the database management server 2 is stored in the memory 23.
  • the memory 23 stores a merge policy change plan creation program 235 and a merge policy change plan display program 236 in addition to the same program as in the first embodiment.
  • the database management server 2 When the database management server 2 operates, the CPU 22 reads and executes them through the data path 24, and by executing these programs on the CPU 22, the database management server (computer) 2 can be used as a search means (231), The data registration unit (232), the non-deletable data discovery unit (233), the deletable data display unit (234), the merge policy change plan creation unit (235), and the merge policy change plan display unit (236) function.
  • the merge policy change proposal creating unit 235 uses the non-deletable data UDL and the data acquisition pattern DRPL created by the non-deletable data discovery unit 233 to create a merge policy change plan (hereinafter, merge policy change plan) designated by the analysis program. It is.
  • merge policy change plan is a set of a data acquisition request made in the past and a new merge policy in the data acquisition request. Also, two or more data acquisition request changes may be included in one merge policy change proposal.
  • the merge policy change plan creation unit 235 passes the created merge policy change plan to the merge policy change plan display unit 236.
  • FIG. 17 is an example of a merge policy change proposal 3500.
  • a column 3501 is an identifier uniquely assigned to each merge policy change proposal by the merge policy change proposal creation means 235.
  • a column 3502 is an ID of the non-deletable data 3400 related to the merge policy change proposal.
  • a column 3503 is an ID of a data acquisition pattern that may change the merge policy.
  • the merge policy change plan 3500 may store the data acquisition request itself instead of the pattern ID.
  • a column 3504 is a current merge policy of the data acquisition pattern indicated by the column 3503.
  • a column 3505 is a new merge policy created by the merge policy change proposal creating means 235.
  • the current merge policy is 2, that is, in the searched range, “prioritizes the data of the version that exists for the longest period”.
  • the merge policy change plan creation unit 235 generates a merge policy change plan based on a preset guideline such as a reduction in the data amount.
  • the merge policy change plan display means 236 presents the merge policy change plan 3500 to the database administrator or analysis program developer on the display screen 1300 (see FIG. 19) based on the data generated by the merge policy change plan creation means 235.
  • this program forcibly changes a part of the merge policy included in the data acquisition request received by the search unit 231 by a method such as updating the setting file of the search unit 231.
  • FIG. 18 is a flowchart for the merge policy change plan creation means 235 to create a merge policy change plan.
  • the merge policy change proposal creating unit 235 first acquires a list of the non-deletable data 3400 created by the non-deletable data finding unit 233 (S201). In the following, this list is called UDL. Thereafter, the processing of S204 to S215 is performed for each non-deletable data 3400 (hereinafter referred to as UD) included in the UDL (S202 to 203).
  • UD non-deletable data 3400
  • the merge policy change proposal creating unit 235 searches the UD time range for the same target data as the UD and data having a newer version than the UD version number (S204). If there is no data corresponding to the search condition, the creation of the merge policy change proposal based on the UD is interrupted (S205). For example, when the row 3311 of the non-deletable data 3300 in FIG. 8 is selected as UD, there is no data of a version newer than version 1 between 11/1 00:00 and 11/2 00:00. Therefore, the merge policy change plan creation means 235 interrupts the creation of the merge policy change plan.
  • the merge policy change proposal creating unit 235 obtains the data with the non-deletable data ID matching UD from the list of data acquisition patterns created by the non-deletable data finding unit 233 (S206).
  • the list of data acquisition patterns acquired here is referred to as DRPL2.
  • the creation of the merge policy change proposal based on UD is interrupted (S207). For example, when the row 3314 of the non-deletable data 3300 in FIG. 8 is selected as the UD, the data acquisition patterns corresponding to the UD are the rows 3414 to 3415 of the data acquisition pattern 3400 in FIG. However, the merge policy of these data acquisition patterns is all 1. Therefore, the merge policy change plan creation means 235 interrupts the creation of the merge policy change plan.
  • the merge policy change plan creation means 235 assigns an identifier for uniquely identifying the merge policy change plan to the UD that has passed the above check (S208).
  • S208 the merge policy change plan creation means 235 assigns an identifier for uniquely identifying the merge policy change plan to the UD that has passed the above check.
  • the UD indicated by the row 3313 passes the above check.
  • 1 is assigned as the change plan ID to this UD.
  • DRP data acquisition pattern
  • S209 to S210 the processing from S211 to S215 is performed for each data acquisition pattern (hereinafter referred to as DRP) included in DRPL2 (S209 to S210).
  • DRP data acquisition pattern
  • These processes are processes for changing a merge policy having a high possibility of using data of a past version into a merge policy having a low possibility of using such data.
  • the merge policy 6 always gives priority to the same version as the data acquired in the past, but the merge policy 2 may give priority to the new version of data.
  • the merge policy 2 may give priority to the old version of data, but the merge policy 1 always gives priority to the new version of data. Therefore, the merge policy 6 has the highest possibility of using the past version of the merge policy of this embodiment.
  • the merge policy 1 has the lowest possibility.
  • Merge policies 2, 4, and 5 are located between the two.
  • the merge policy change proposal creating unit 235 checks whether the merge policy of the DRP is 6 (S211). That is, it is checked whether the merge policy of the DRP is a merge policy “prioritizes the same version as the data acquired in the past”. If the DRP merge policy is 6, a plan for changing the DRP merge policy to 2 is added to a list of merge policy change plans (hereinafter referred to as MPL) in the memory (S212).
  • MPL merge policy change plans
  • the merge policy change proposal creating means 235 checks whether the merge policy of the DRP is 2, 4 or 5 (S213). That is, it is checked whether or not the merge policy of the DRP is a merge policy that “priorizes the version data that exists for the longest period of time over the latest version data”. If the DRP merge policy is 2, 4 or 5, a plan for changing the DRP merge policy to 1 is added to the MPL (S214). For example, the row 3511 of the merge policy change plan 3500 of FIG. 17 is created from the row 3413 of the data acquisition pattern 3400 of FIG.
  • the merge policy change plan creation means 235 passes the above-mentioned MPL to the merge policy change plan display means 236.
  • the merge policy change plan creating means 235 may create a plan for changing from the merge policy 6 to 1.
  • FIG. 19 is a diagram showing an example of display on the display screen 1300 by the merge policy change plan display means in the third embodiment.
  • Reference numeral 1301 denotes a tab indicating the ID of the merge policy change proposal. This tab is displayed as many as the number of proposed merge policy changes.
  • Reference numeral 1302 denotes an area indicating details of the merge policy change proposal and the amount of data reduced by the change proposal. When the user selects the tab 1301, information related to the merge policy change proposal is displayed in the frame 1302.
  • Reference numeral 1303 denotes an area indicating information of the non-deletable data 3400 where the data amount can be reduced by the merge policy change proposal. This area is generated based on the UDL.
  • the data amounts of the erasable data 3450 and the non-deletable data 3400 are calculated by the same method as the erasable data display means 234.
  • Reference numeral 1304 denotes the details of the merge policy change proposal. In this area, the merge policy change plan having the same change plan ID as the ID selected in the tab 1301 in the MPL is displayed.
  • the merge policy change proposal display means 236 may display the number of past accesses based on the data acquisition pattern on the display screen 1300 using information included in the DRPL as a judgment material for the user.
  • Reference numeral 1305 denotes an area indicating the amount of data that can be reduced by the merge policy change proposal for each version number. This data amount is also calculated by the same method as that of the erasable data display means 234.
  • Reference numeral 1306 denotes a button for notifying a developer who has developed an old version analysis program of the merge policy change proposal.
  • the merge policy change plan display means 236 notifies the developer of all versions of the analysis program displayed in 1305 of this information by e-mail or the like.
  • Reference numeral 1307 denotes a button for forcibly applying the merge policy change proposal to the search means 231. 1307 is a button for closing this screen without notifying or forcibly applying a merge policy change proposal.
  • the merge policy change plan display means 236 may change the display order in order to help the user to select the merge policy change plan to be actually adopted.
  • the merge policy change plan display means 236 may change the display order based on the following criteria.
  • the merge policy change proposal display means 236 displays the revision plan of the merge policy included in the data acquisition request on the display screen 1300 as described above. Can be presented. Further, the merge policy change plan display means 236 can present the data amount that can be reduced by the correction to the database managers on the display screen 1300.
  • the developer of the analysis program can reduce the work time for determining the merge policy change method and the work time for modifying the analysis program to change the merge policy.
  • non-deletable data discovery unit 233, the merge policy change plan creation unit 235, and the merge policy change plan display unit 236 may be automatically activated. Further, these programs may be automatically executed until the merge policy change proposal is applied. These programs can be started automatically by a method that is periodically started by the job scheduler, some event (for example, a new version of data is registered for the first time, or the disk usage of the database exceeds the threshold. There is a way to start it. As described above, when the activation of these programs is automated, the work time for the analysis program developer to change the merge policy can be reduced to zero. As a result, an effect of reducing the operation cost of the analysis program can be obtained.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　データベースサーバは、各種の時系列データについて、複数のバージョンのデータを格納可能なデータベースと、前記データベースを管理するデータベース管理サーバとを備え、前記データベース管理サーバは、前記データベースの検索条件に加えて、前記複数バージョンのデータの混在を許すかどうかのポリシが定義されたマージポリシを指定可能な検索手段を備え、前記検索手段は、前記指定されたマージポリシに基づいて、前記検索条件に含まれる時間の範囲内で前記複数バージョンのデータをマージした結果をデータ取得履歴として生成し、該データ取得履歴を前記データベースに記録する。

Description

複数バージョンのデータを格納するデータベースサーバ、及び、データベース管理方法
　本発明は、データベースサーバ及びデータベース方法に係り、特に、複数バージョンのデータを格納するデータベースサーバにおける時系列データの管理技術に関する。
　データベースサーバは、データベースを内部に持ち、このデータベースを管理するシステムとしてのデータベース管理サーバやデータベース処理装置を有している。  
　データベースの時系列データの管理技術として、データベースのファイルから不要な時系列データを自動的に削除する技術が知られている。  
　複数バージョンのデータを格納するデータベースに関する公知例を、以下に示す。  
　特許文献1では、データベースサーバが、時系列データ検索手段、不要データ削除選択手段、不要データ削除手段等を備え、データベース上に古い時系列データと新しい時系列データが存在する場合に、古い時系列データのなかで、新しい時系列データと重複する時間帯のデータのみを削除する方法が開示されている。特許文献1の発明は、データベースファイルから不要な時系列データを削除する際、自動的に必要時点の時系列データを同一データベースファイルに保持することを可能にし、外部のアプリケーションプログラムが、データベース上の時系列データのバージョンをチェックする必要をなくすことを目的としている。
　特許文献2の発明では、データベース処理装置が、旧バージョンのデータベース定義と新しいバージョンのデータベース定義を持ち、かつ旧バージョンまたは新バージョンの定義情報のいずれか一方をアクセス依頼時に選択することを可能とするアクセス選択手段を備え、さらに、定義の変更処理が確定した時に、旧バージョンの情報を新バージョンに書き換える機構を備えている。
特開平7-73086号公報 特許第2503297号公報
　大規模なデータセンタでは、サーバ装置などから収集した時系列データに対して、複数の監視自動化技術を組み合わせた複雑な処理を行うことにより、監視作業の一部を自動化・効率化したいという要求がある。そのような自動化処理には、例えば、異常の予兆を検出する処理や、複数の異常から根本原因を発見する処理（Root Cause Analysis、以下RCA）などがある。将来は、これらの自動化処理を実現するための分析プログラムを、多段階に組み合わせることが一般化すると考えられる。
　図20Aは、加工前の時系列データ（生データ）を複数の分析プログラムにより段階的に処理し、時系列データとしてデータベースに格納する様子を模式的に示す図である。例えば、分析プログラムとしての「異常検出処理」プログラムによる処理の結果得られたデータベースの「異常データ」について、後続処理としてのRCA処理を行い、異常データ依存関係の情報を生成すると共に、「異常データ」に関して、検索用インデックスの作成処理を行い、「検索用異常データ」を生成する。
　自動化処理を実際の運用現場に適用する場合、これらの分析プログラムのアルゴリズムやパラメータは、頻繁に見直す必要がある。以下では、このようなアルゴリズムやパラメータの見直しを、バージョンアップと呼ぶ。分析プログラムをバージョンアップすると、その結果も変化する。そのため、分析プログラムを見直した場合、その後一定期間は、新旧の分析プログラムの並行稼働や、古い分析プログラムによって作成された分析結果の保存が必要である。
　図20Bは、従来の分析プログラムのバージョンアップ手順を模式的に示す図である。この例では、生データを分析プログラム「異常検出処理」(Ver. 1)が処理して作成したデータ（異常データ:(Ver. 1)）は、後続の分析プログラム「RCA処理」および「検索インデックス作成処理」によって利用される。例えば、「RCA処理」では過去1回分、「検索インデックス作成処理」では過去1年分のデータ（異常データ:(Ver. 1)）を処理の対象とする。以下では、これら「RCA処理」、「検索インデックス作成処理等の分析プログラムを、ある分析プログラム（この例では「異常検出処理」）の後続処理と呼ぶ。  
　後続処理を持つ分析プログラム、ここでは「異常検出処理」プログラム、を(Ver. 1)から(Ver.2)にバージョンアップする場合、図20Bの（1）に示したように、古い分析プログラム(「異常検出処理」(Ver. 1))と新しい分析プログラム(「異常検出処理」(Ver. 2))を並行稼働する。さらに、図20Bの（2）に示したように、後続処理ごとの判断基準に基づいて、各後続処理(「RCA処理」,「検索インデックス作成処理」)の側で、データの読み込み先を変更する必要がある。もし、この古い分析プログラムが稼働し続けたり、古い分析プログラムによって作成された分析結果がデータベース上に存在し続けると、データベース上のディスク使用量は、バージョンアップ回数に応じて増加し続けてしまう。
　後続処理が、古い分析プログラム(Ver. 1)で作成された分析結果（図20Bの「異常データ（ver. 1）」）を引き続き必要とする期間の長さは、「RCA処理」等、後続処理の内容によって異なる。そのため、後続処理の開発者への確認なしに、古い分析プログラムで作成された分析結果を削除すると、後続処理に悪影響を及ぼす可能性がある。しかし、後続処理の数が多い場合や、後続処理が多段に渡る場合は、残す必要のある分析結果を後続処理の開発者自身に正確に申告させることは難しい。
　後続処理が多段に渡る場合は、ある後続処理に対する1個以上の後続処理が、その後続処理の分析結果をどのように使うかを知る必要が生じるため、特に申告が難しくなる。その結果、後続処理の開発者は、実際に必要なものよりも余分に分析結果を残すよう申告する可能性がある。従って、データベース上のディスク使用量を最小化するためには、後続処理の開発者の自己申告に頼らずに、不要な分析結果を削除する方法が必要である。
　特許文献1の発明では、データベースサーバが、後続処理の内容に関わらず、新しい時系列データと重複する時間帯のデータについてはすべて削除対象とする。そのため、特許文献1の発明を、複数の監視自動化技術を組み合わせた時系列データの管理に適用することを想定した場合、後続処理に悪影響を与える可能性がある。
　特許文献2の発明は、旧バージョンの情報を新バージョンに書き換える機能は有するものの、旧新バージョンのデータのなかで削除可能なものを発見する手段を提供しない。換言すると、特許文献２の発明は、不要な時系列データを削除することについては、想定されていない。
　本発明の解決課題の１つは、複数バージョンの時系列データを格納するデータベースサーバにおいて、後続処理の開発者の自己申告に頼らない方法で、古い分析プログラムによって作成されたデータのなかで削除可能なものを自動的に抽出する時系列データの管理技術を提供することにある。
　本発明の代表的なものの一例を示すと、次の通りである。データベースサーバは、各種の時系列データについて、複数のバージョンのデータを格納可能なデータベースと、前記データベースを管理するデータベース管理サーバとを備え、前記データベース管理サーバは、前記データベースの検索条件に加えて、前記複数バージョンのデータの混在を許すかどうかのポリシが定義されたマージポリシを指定可能な検索手段を備え、前記検索手段は、前記指定されたマージポリシに基づいて、前記検索条件に含まれる時間の範囲内で前記複数バージョンのデータをマージした結果をデータ取得履歴として生成し、該データ取得履歴を前記データベースに記録することを特徴とする。
　本発明によれば、複数バージョンの時系列データを格納するデータベースサーバにおいて、検索条件に含まれる時間の範囲内で古い分析プログラムによって作成されたデータを自動的に削除し、データベースサーバのディスク使用量を自動的に最小化できる。
本発明の第1の実施形態に係る、データベースサーバを模式的に示す図である。 本発明における複数のマージポリシの相互の関係を表現した一例である。 第1の実施形態における、分析サーバ、及び、データベース管理サーバの検索手段1及びデータ登録手段の動作を説明する図である。 第1の実施形態における、時系列データの例を示す図である。 第1の実施形態における、データ取得履歴の例を示す図である。 第1の実施形態における、分析プログラムのバージョンアップ方法を模式的に示す図である。 第1の実施形態における、データベース管理サーバの削除不可データ発見手段、及び、削除可能データ表示手段の動作を説明する図である。 第1の実施形態における、削除不可データ発見プログラムのフローチャートである。 第1の実施形態における、削除不可データ発見プログラムのフローチャートである。 第1の実施形態における、対象時刻範囲を相対時刻に変更したデータ取得履歴の例を示す図である。 第1の実施形態における、削除不可データの例を示す図である。 第1の実施形態における、データ取得パターンの例を示す図である。 第1の実施形態において、データベース上に、複数のバージョンの時系列データが存在する様子を模式的に示す図である。 第1の実施形態において、複数バージョンの時系列データを、削除不可データおよび削除可能データに区別した状態を模式的に示す図である。 第1の実施形態における、削除可能データ表示プログラムによる画面表示の例を示す図である。 第1の実施形態における、削除可能データ表示プログラムによる画面表示の例を示す図である。 本発明の第2の実施形態における、データベース管理サーバの内部構造を示す機能ブロック図である。 第2の実施形態における、削除可能データ表示プログラムによる画面表示の例を示す図である。 本発明の第3の実施形態における、データベース管理サーバの内部構造を示す機能ブロック図である。 マージポリシ変更案の例を示す図である。 第3の実施形態における、マージポリシ変更案作成プログラムのフローチャートである。 第3の実施形態における、マージポリシ変更案表示プログラムによる画面表示の例を示す図である。 時系列データを複数の分析プログラムで段階的に処理する様子を模式的に示す図である。 従来の分析プログラムのバージョンアップ手順を模式的に示す図である。
　本発明のデータベース管理サーバは、後続処理に対して、データ取得要求のなかで、データベースに複数バージョンの時系列データの混在を許すかどうかのマージポリシの宣言を必須とする。データベース管理サーバは、この与えられたマージポリシと、その時点でデータベース上に存在する各バージョンの時系列データに応じて、最新バージョンの時系列データ、古いバージョンの時系列データ、あるいは最新バージョンのものと古いバージョンのものが混在した時系列データを、後続処理に返す。
　また、本発明のデータベース管理サーバは、上記のマージポリシを含むデータの取得履歴を記録する。そして、これらのデータ取得履歴をもとに、古い分析プログラムによって作成されたデータベースの時系列データのなかで削除可能なものを発見する。データベース管理サーバはそれらの削除可能なデータをデータベース管理者に提示するか、あるいはそれらの時系列データをデータベースから自動的に削除する。
　更に、本発明のデータベース管理サーバは、上記のデータ取得履歴をもとに、後続処理の指定する上記マージポリシの変更案と、マージポリシを変更した場合に削減できるデータ量を計算する。データベース管理サーバはそれらのマージポリシ変更案を後続処理の開発者に提示するか、あるいはそれらのポリシ変更案を自動的にデータベース管理サーバへ適用する。
　本発明のデータベース管理サーバによれば、複数バージョンの時系列データを格納するデータベースサーバにおいて、古い分析プログラムによって作成された時系列データをデータベースから自動的に削除し、データベースサーバのディスク使用量を自動的に最小化できる。換言すると、本発明のデータベース管理サーバは、分析サーバの後続処理に対して、バージョン番号を指定して、古い分析プログラムによって作成されたデータベースの時系列データを取得することを許可しない。もしデータベース管理サーバが後続処理に対して、バージョン番号を指定した取得を許可すると、後続処理は古いバージョンの時系列データを使い続ける恐れがあるためである。
　また、自動的にデータを削除しない場合、本発明のデータベース管理サーバは、古い分析プログラムによって作成された時系列データを削除できる理由や、後続処理のマージポリシを変更した方がよい理由を、データベース管理者や後続処理の開発者に提示することができる。従って、データベース管理者等の利用者は、提示された情報を利用することで、データベースから実際に削除するデータを決定するための作業時間を短縮できる。以下、図面を用いて本発明の実施形態を詳細に説明する。
　本発明の第1の実施形態に係るデータベースサーバについて、図面を用いて説明する。  
　図1に、実施例1で想定するデータベースサーバを模式的に示す。また、データベース管理サーバの内部構造を機能ブロック図として示す。  
　本発明で想定するデータベースサーバは、分析サーバ及びデータベース管理サーバを保有し、クライアントからデータベースの検索や更新などの要求を受けたときに分析サーバによるデータベースの分析処理を行い、その結果をアプリケーションに返す。すなわち、データベースサーバは、データベース管理サーバ2、データベース3、生データ生成サーバ4、分析サーバ5、管理者端末6によって構成される。これらの機器は、物理的な通信回線7を通してネットワーク1に接続される。  
　データベース管理サーバ2は、後述するデータベース3に対するデータの入出力を管理するサーバである。また、データベース管理サーバ2は、古い分析プログラムによって作成されたデータのなかから、削除可能なデータを発見する機能を持つ。  
　データベース管理サーバ2は、インターフェイス（I/F）21を通してパケットを送受信する。データベース管理サーバ2の各プログラムはメモリ23に格納されており、動作時にはCPU 22がデータパス24を通してそれらを読み出して実行する。  
　メモリ23は、データ取得プログラム231、データ登録プログラム232、削除不可データ発見プログラム233、削除可能データ表示プログラム234を格納する。これらのプログラムをCPU 22で実行することにより、コンピュータ(データベース管理サーバ2、管理者端末6、分析サーバ5)を、検索手段若しくはデータ取得手段（231）、データ登録手段（232）、削除不可データ発見手段（233）、削除可能データ表示手段（234）として機能させる。
　データベース3は、時系列データ3000と、これらの時系列データに対する取得要求の履歴（以下、データ取得履歴）3100を格納するデータベースである。なお、データベース3には、必要に応じて、削除可能なデータ3450も一次的に保持される。
　生データ生成サーバ4は、分析対象の時系列データ（生データ）を生成し、それらのデータを、データベース3に登録するサーバである。通常、生データ生成サーバ4は複数(4-1, 4-2, -)存在する。生データ生成サーバの一例としては、サーバの性能情報（CPU使用率など）を測定するエージェントソフトウェアが動作するWebアプリケーションサーバや、センサで計測した値（温度など）を記録する小型装置などがある。生データ生成サーバ4は、データベース3にデータを登録する際に、バージョン番号を指定する必要はない。しかし、分析サーバ5と同様にバージョン番号を指定してもよい。その場合、生データについても、古いバージョンのデータは削除の対象になる。
　分析サーバ5は、複数(5-1, 5-2, -)存在し、各々、1個以上の分析プログラム5100が動作するサーバである。分析プログラム（分析手段）5100は、データベース3から時系列データ（生データ生成サーバ4が登録したデータ、または分析サーバ5が登録したデータ）を取得し、それらのデータに対して何らかの処理を行う。この処理には、監視結果をWebブラウザに表示するためのWebページの作成なども含まれる。また、分析プログラムは、分析した結果を、取得した時系列データとは別の種類の（すなわち、別の名前を持つ）時系列データとして、データベース3に登録することもできる。分析プログラムは、データベース3にデータを登録する際に、必ずその分析プログラムのバージョン番号を指定する必要がある。分析サーバ5は、分析プログラムの機能の一部として、検索条件やマージポリシを設定する手段5102も備えている。
　管理者端末6は、GUI機能付きの表示部61を備え、データベース管理者および分析プログラムの後続処理の開発者等（利用者）が、データベース管理サーバ2を利用する際に表示画面(1100)を介して操作する端末である。利用者は、管理者端末6の上で動作するクライアントソフトウェア（Webブラウザなど）を通して、データベース管理サーバ2の上で動作するプログラムの出力を確認する。また、利用者は、適宜、管理者端末6を通して、分析サーバ5における検索条件やマージポリシに関するパラメータ等を設定する。分析サーバ5は、設定されたこれらの検索条件やマージポリシに基づき分析プログラムを動作させる。
　なお、削除不可データ発見手段233が特定の対象データに関するすべての時系列データ3000およびデータ取得履歴3100にアクセスできるならば、データベース管理サーバ2およびデータベース3は複数存在してもよい。そのため、本発明は分散型のデータベースに対しても適用可能である。
　次に、データベース管理サーバ2の詳細を説明する。  
　検索手段若しくはデータ取得手段（以下、検索手段）231は、分析サーバ5で動作する分析手段からのデータ取得要求に応じて、データベース3上の時系列データを返すプログラムである。分析手段は、このデータ取得要求のなかに、複数バージョンのデータの混在を許すかどうかのポリシ（以下、マージポリシ）を必ず含めなければならない。検索手段231がマージポリシを含まないデータ取得要求を受信した場合、検索手段231はそのデータ取得要求を拒否するか、またはデフォルトのマージポリシを用いてそのデータ取得要求を処理する。そして、検索手段は、このマージポリシを含むデータ取得要求の履歴を、データベース3に記録する。
　マージポリシの内容としては、例えば、「最新バージョンのデータと、検索条件に含まれる時間の範囲で最も長期間存在するバージョンのデータのどちらを優先するか」、「複数バージョンのデータのマージを許可するかどうか」、「複数バージョンのデータのマージが発生した場合に検索を中断するかどうか」、「過去に取得したデータと同じバージョンを優先するかどうか」などがある。
　本実施例では、以下のマージポリシ1～6を具体例として用いる。  
　（1）検索条件に含まれる時間の範囲に複数バージョンのデータが混在した場合、その範囲内での最新バージョンのデータを優先したうえで、異なるバージョンのデータをマージした結果を取得
　（2）検索条件に含まれる時間の範囲に複数バージョンのデータが混在した場合、その範囲内で最も長期間存在するバージョンのデータを優先したうえで、異なるバージョンのデータをマージした結果を取得
　（3）検索条件に含まれる時間の範囲に複数バージョンのデータが混在した場合、その範囲内での最新バージョンのデータのみ取得
　（4）検索条件に含まれる時間の範囲に複数バージョンのデータが混在した場合、その範囲内で最も長期間存在するバージョンのデータのみ取得
　（5）検索条件に含まれる時間の範囲に複数バージョンのデータが混在しており、かつその範囲内で最も長期間存在するバージョンのデータでは全範囲をカバーできない場合、検索を中断
　（6）検索条件に含まれる時間の範囲に複数バージョンのデータが混在した場合、過去にその手段が取得したデータについてはそのときと同じバーションを最優先とし、最新バージョンのデータをその次に優先したうえで、異なるバージョンのデータをマージした結果を取得
　マージポリシ1、2、6は、複数バージョンのデータのマージを行うマージポリシの例である。逆に、マージポリシ3、4、5はマージを行わないマージポリシの例である。マージポリシ1、3、6は、最新バージョンのデータを優先するマージポリシの例である。特にマージポリシ5は、複数バージョンのデータのマージが発生した場合に検索を続行しないマージポリシの例である。マージポリシ6は、過去に取得したデータと同じバージョンを優先するマージポリシの例である。
　図２Aは、上記複数のマージポリシの相互の関係を表現した一例である。分析手段5100は、このマージポリシを必ず決定しなければならない(S20)。複数のマージポリシは、まず、「複数バージョンのデータのマージを行うか否か」で２つに分類することができる(S21)。マージを行う場合(S21でYES)において、検索条件に含まれる時間の範囲内での最新バージョンのデータを優先するのが(S22でYES)、マージポリシ1である。範囲内で最も長期間存在するバージョンのデータを優先するのが(S23でYES)、マージポリシ2である。過去に取得したデータと同じバージョンを優先するのが(S24でYES)、マージポリシ6である。これらの何れにも該当しない(S24でNO)場合に、特有の条件を設定したものが、マージポリシ7である。
　一方、複数バージョンのデータのマージを行なわない場合(S21でNO)において、最新バージョンのデータを優先するのが(S25でYES)、マージポリシ3である。範囲内で最も長期間存在するバージョンのデータを優先するのが(S26でYES)、マージポリシ4である。過去に取得したデータと同じバージョンを優先するのが(S27でYES)、検索を中断する(S28)マージポリシ5である。これらの何れにも該当しない(S27でNO)場合に、特有の条件を設定したものが、マージポリシ8である。
　以上の例では、あり得るマージポリシのなかで、特に実用的と思われるマージポリシのみを記載した。本実施例では、分析サーバ5は、検索手段231に対して、マージポリシとして、1～6の数値を指定する、若しくは7, 8の追加条件を設定するものとする。しかし、マージポリシの表現方法はこれに限られるものではなく、この発明の趣旨を逸脱しない範囲で拡張してよい。例えば、マージポリシは単一の整数ではなく、複数のブール値の集合でもよい。また、マージポリシはパラメータを持ってもよい。例えば、検索手段231は、「検索条件に含まれる時刻の範囲のnパーセントを網羅するデータを、最新バージョンのデータよりも優先する（n=60）」といったマージポリシを許可してもよい。
　また、検索手段231は、データ取得要求の送信元に応じて、固定のマージポリシを適用してもよい。例えば、データベース管理者が、データベース管理サーバ上の設定ファイルに、要求元プログラム名や、要求元IPアドレスやポート番号をキーにして、固定のマージポリシを記載する。そして、検索手段231は、データ取得要求を受信するたびにその設定ファイルを参照し、マージポリシを決定してもよい。ただし、この方法では、後続処理の開発者が、データベース管理サーバ上の設定ファイルを編集するための権限を持つ必要がある。
　データ登録手段232は、生データ生成サーバ4で動作するソフトウェアまたは分析サーバ5で動作する分析プログラムからのデータ登録要求に応じて、データベース3に時系列データを登録するプログラムである。分析プログラムからのデータ登録要求には、必ずその分析プログラムのバージョン番号が含まれている必要がある。
　また、データ登録手段232は、データの送信元に応じて、固定のバージョン番号を適用してもよい。例えば、データベース管理者が、データベース管理サーバ上の設定ファイルに、送信元プログラム名や、送信元IPアドレスやポート番号をキーにして、固定のバージョン番号を記載する。そして、データ登録手段232は、データ登録要求を受信するたびにその設定ファイルを参照し、バージョン番号を決定してもよい。ただし、この方法では、後続処理の開発者が、データベース管理サーバ上の設定ファイルを編集するための権限を持つ必要がある。
　図２Bは、分析サーバ5、データベース管理サーバ2の検索手段231及びデータ登録手段232の動作を説明する図である。分析サーバ5は、データベース管理サーバ2の検索手段231を起動し、与えられた検索条件やマージポリシに基づいてデータベース3の時系列データ3000を検索し、その検索結果を、データ登録手段232により、データベース3のデータ取得履歴3100に格納する。
　以下に、データベース3の詳細を示す。本実施例のデータベース3は、データを表形式で格納する。なお、本実施例の実施形態は表形式のデータに限定されるものではない。
　時系列データ3000は、生データ生成サーバ4によって生成されデータベース3に登録された時系列データ（生データ）、および分析サーバ5によって生成された時系列データ（生データを分析した結果、またはある分析結果をさらに分析した結果）である。
　図3Aは、時系列データ3000の一例である。時系列データ3000の列3001は、その時系列データに関連付けられた時刻である。この時刻はその時系列データが作成された時刻でもよいし、その時系列データが示す時間帯の先頭を示す時刻でもよい。列3002は、その時系列データの名称である。以下の例では、生データ生成サーバ4が登録したCPU利用率の名前は「CPU利用率」、分析サーバ5で動作する分析プログラム「異常検出処理」が登録した分析結果の名前は「異常データ」とする。列3003は、その時系列データのバージョン番号である。生データ生成サーバ4が登録したデータ（行3011～3012）の列3003には、空白または固定値を格納する。一方、分析プログラムが登録した加工データ（行3021～3051）の列3003には、その加工データを作成した分析プログラムのバージョン番号を格納する。通常、この列3003のバージョン番号は、その時系列データを作成した分析プログラムのバージョン番号である。しかし、分析プログラムのバージョン番号と、時系列データのバージョン番号は、必ずしも1対1対応する必要はない。列3004は、その時系列データに含まれる、時刻以外のデータである。この例では、時刻以外のデータを、キーと値のペアとして示している。例えば、行3011は、2012年10月1日の0時0分0秒に、ホスト名host1のサーバから取得したCPU使用率が、10.0%であることを示している。また、時系列データ名が「異常データ」となっている行3021-3031は、CPU使用率が急増していることを示している。
　図3Bは、データ取得履歴3100の一例である。データ取得履歴3100は、検索手段231が分析サーバ5からデータ取得要求を受信した際に、検索手段231によって生成されたデータ取得履歴である。列3101は、検索手段231が、そのデータ取得要求を受け付けた時刻である。列3102は、そのデータ取得要求を送信したプログラムを一意に識別するための名称である。このような名称の代わりに、そのシステムにおいてプログラムを一意に識別できる他の文字列（データ取得要求の送信元IPアドレスなど）を用いてもよい。列3103は、そのデータ取得要求で対象とされた時系列データの名前である。列3104は、そのデータ取得要求で指定されたマージポリシの番号である。列3105は、そのデータ取得要求で指定された時刻の範囲である。範囲の開始時刻または終了時刻の指定は無くてもよい。列3106は、そのデータ取得要求で指定された、時刻以外の検索条件である。すなわち、列3104がマージポリシ、列3105と列3106が、データの検索条件である。列3107は、そのデータ取得要求の結果として返された時系列データのバージョン番号である。マージポリシにより複数のバージョンのデータがマージされた場合は、行3121のように、各期間ごとのバージョン番号が記録される。
　図4は、第1の実施形態における分析プログラム5100のバージョンアップ方法を模式的に示す図である。この例では、図20Bの例と同様に、分析プログラム「異常検出処理」5100の後続処理として、2個の分析プログラム（「RCA処理」、「検索インデックス作成処理」）が存在する。ただし図20Bとは異なり、データ読み込み先の切り替え（異常データver. 1からver. 2への切り替え）は、検索手段231が行う。
　図１に戻って、データベース管理サーバ２の削除不可データ発見手段233は、データベース3のデータに基づいて、削除不可な時系列データを発見するプログラムである。このプログラムは、管理者端末6を経由して、データベース管理者または分析プログラムの開発者によって起動されるか、Linux（登録商標）で利用可能なcronなどのジョブスケジューラによって自動的に起動される。このプログラムは、生成したデータを削除可能データ表示プログラムに渡す。
　データベース管理サーバ２の削除可能データ表示手段234は、削除不可データ発見手段233が生成したデータに基づいて、削除可能な時系列データに関する情報をデータベース管理者または分析プログラムの開発者（利用者）に提示する。または、このプログラムが、削除可能と判定された時系列データを、自動的に削除する。
　なお、以下の説明では、データベース上に、分析プログラム5100に関する複数のバージョンの異常データが存在しているものとする。図10は、データベース上に、4個のバージョン（Ver.1，Ver2，Ver3，Ver4）の時系列データが存在する様子を模式的に示す図である。図10の例では、分析プログラム5100に関し、Ver.1が最も長期間存在するバージョン、Ver4が最新バージョンのプログラムである。
　以下では、これら4個のバージョンの異常データのなかから削除可能なデータを発見し、それらをデータベース管理者らに提示するまでの手順を示す。すなわち、図５以下で、削除不可データ発見手段233および削除可能データ表示手段234の詳細を示す。
　図５は、データベース管理サーバ2の削除不可データ発見手段233及び、削除可能データ表示手段234の動作を説明する図である。
　削除不可データ発見手段233は、データベース3の時系列データ3000に基づいて、データ取得履歴3100の対象時刻範囲を相対時刻に変換したデータ取得履歴（相対時刻）3200を生成し、削除不可な時系列データを発見し、それらの削除不可な時系列データに関する2種類の情報（削除不可データ3300、データ取得パターン3400）を生成する。
　データ取得履歴3200（図7参照）は、図3Bのデータ取得履歴3100の対象時刻範囲3105を、相対時刻範囲3205に変換したものである。  
　削除不可データ3300（図8参照）は、削除してはいけない時系列データの名称、バージョン番号、対象時刻範囲などを示すデータである。このデータは、削除可能データ表示手段234が動作するために必須のデータである。  
　データ取得パターン3400（図9参照）は、削除不可データ3300が示す時系列データを削除してはいけない理由になっている、過去のデータ取得の内容を示すデータである。このデータは、削除可能データ表示手段234が動作するために必須のデータではない。しかし、このデータを作ることで、削除可能データ表示手段234は、システム管理者や分析プログラムの開発者に対して、一部の時系列データを削除できない具体的な理由を提示できるという効果がある。削除不可データ発見手段233は、これらの削除不可な時系列データを削除可能データ表示手段234に渡す。
　図6A～6Bは、削除不可データ発見手段233が、データ取得履歴3100から削除不可な時系列データ（削除不可データ3300、データ取得パターン3400）を発見するためのフローチャートである。
　削除不可データ発見手段233は、最初に、データ取得履歴3100に含まれる対象データ3103の集合をデータベースから取得する（S101）。以下では、この対象データの集合をTDSと呼ぶ。図3Bのデータ取得履歴3100の例では、TDSには「異常データ」のみが含まれる。これ以降では、TDSに含まれる個々の対象データ（以下、TD）に対して、S104～S128の処理を行う（S102～S103）。
　まず、削除不可データ発見手段233は、対象データがTDと一致し、かつマージポリシが6のデータ取得履歴3100すべてをデータベース3から取得する（S104）。これらは、「過去に取得したデータと同じバージョンを優先する」マージポリシ6を含むデータ取得履歴である。以下では、このデータ取得履歴のリストをDHL1と呼ぶ。図3Bのデータ取得履歴3100の例では、行3111～3112のデータ取得履歴がDHL1に含まれる。
　次に、削除不可データ発見手段233は、DHL1に含まれるデータ取得履歴を元に削除不可データ3300を作成する。そして、その作成したデータをメモリ上の削除不可データ3300のリスト（以下、UDL）に追加する（S105）。 
　図8は、削除不可データ3300の一例である。列3301は、削除不可データ発見手段233が、個々の削除不可データに対して一意に割り当てる識別子である。列3302は、削除してはいけない時系列データの名前である。列3303は、削除してはいけない時系列データのバージョン番号である。列3304は、削除してはいけない時系列データの対象時刻範囲である。列3305は、列3302～3304が示す時系列データのデータ量である。
　図6AのS105において、削除不可データ発見手段233は、データ取得履歴3100の列3103、列3105、列3107のデータをもとに、削除不可データ3300の列3302、列3303、列3304のデータを作成する。列3301の削除不可データIDは、削除不可データ発見手段233が新たに割り当てる。また、列3305のデータ量は、削除不可データ発見手段233が時系列データ3000を検索することで新たに計算する。なお、列3302、列3303、列3304の組は必ず一意とする。例えば、もし仮にデータ取得履歴3100の行3111が複数あったとしても、削除不可データ3300の行3311は1個だけ作成される。
　さらに、削除不可データ発見手段233は、DHL1に含まれるデータ取得履歴をもとに、S105で作成した削除不可データに対応するデータ取得パターン3400を作成する。そして、その作成したデータをメモリ上のデータ取得パターンのリスト（以下、DRPL）に追加する（S106）。
　図9は、データ取得パターン3400の一例である。列3401は、削除不可データ発見手段233が、個々のデータ取得パターンに対して一意に割り当てる識別子である。列3402は、そのデータ取得パターンが対応する削除不可データの識別子である。例えば、データ取得パターン3400の行3414は、この行が示すデータ取得要求が過去に行われたために、図8の削除不可データ3300の行3314～3315が示す列3304の対象時刻範囲の時系列データを削除できない、ということを示している。列3403は、そのデータ取得パターンを過去に実行したプログラムの名前である。列3404～3406は、そのデータ取得パターンが示す過去のデータ取得要求のマージポリシ、対象時刻範囲、および絞り込み条件である。列3407は、そのデータ取得パターンが示す過去のデータ取得要求が行われた回数である。
　削除不可データ発見手段233は、データ取得履歴3100の列3102～列3106のデータをもとに、データ取得パターン3400の列3403～3406のデータを作成する。列3401のパターンIDは、削除不可データ発見手段233が新たに割り当てる。列3402の削除不可データIDには、削除不可データ発見手段233がS105で作成した削除不可データのIDが格納される。S105で複数の削除不可データが作成された場合は、ここに複数の削除不可データIDが格納される。列3407の回数には、S105で作成した削除不可データが示す時系列データに対する、データ取得履歴の個数が格納される。
　削除不可データ発見手段233は、対象データがTDと一致し、かつマージポリシが2、4または5のデータ取得履歴すべてをデータベースから取得する（S111）。これらは「最新バージョンのデータよりも、最も長期間存在するバージョンのデータを優先する」マージポリシを含むデータ取得履歴である。以下では、このデータ取得履歴のリストをDHL2と呼ぶ。図3Bのデータ取得履歴3100の例では、行3121～3123のデータ取得履歴がDHL2に含まれる。
　次に、削除不可データ発見手段233は、データ取得履歴3100の対象時刻範囲を相対時刻に変換したデータ取得履歴（相対時刻）3200を生成する（S112）。  
　DHL2に含まれるデータ取のデータ取得履歴3100例では、行3121～3123のデータ取得履歴が、図7のデータ取得履歴3200の行3221～3223に変換される。
　図7のデータ取得履歴3200の列3202～3204および列3206は、図3Bのデータ取得履歴3100の列3102～3104および列3106と同じ意味を持つ。列3205は、図3Bの列3105の対象時刻範囲（絶対時刻）のデータを、列3101の要求日時からの相対時刻に変換したものである。この変換を行う際に、要求日時の細かい違いを考慮すると、頻繁に行われているデータ取得の傾向が見えにくくなる。そのため、削除不可データ発見手段233は、列3101の分以下の時刻や、秒以下の時刻を切り捨てるか、または切り上げてもよい。本実施例では、列3101の分以下の時刻を切り捨てたうえで、列3101と列3105を比較し、列3105の対象時刻のデータを相対時刻に変換している。また、削除不可データ発見手段233は、対象時刻範囲についても同様の抽象化を行ってもよい。例えば、30日前の時系列データに対する検索と、31日前の時系列データに対する検索は、どちらも「1ヶ月前の時系列データに対する検索」と抽象化してよい。
　そして、削除不可データ発見手段233は、DHL2に含まれるデータ取得履歴3200から、最も小さい時刻（すなわち最も過去）のデータを要求しているデータ取得履歴を選択する（S113）。  
　例えば、対象時刻範囲が「（要求日時の7日前）以上、（要求日時）未満」という履歴と、「（要求日時の14日前）以上、（要求日時の7日前）未満」という2個のデータ取得履歴があった場合、削除不可データ発見手段233は、後者を選択する。図3Bのデータ取得履歴3100の行3121～3123の例では、これらは抽象化によって全く同じ内容（図7のデータ取得履歴3200の行3221～3223）に変換されている。従って、削除不可データ発見手段233は、図7のデータ取得履歴3200の行3221～3223からいずれか1個を選択する。以下では、行3221が選択されたものと仮定する。
　次に、削除不可データ発見手段233は、S113で選択したデータ取得履歴を現在時刻に当てはめた場合に、最も長期間データが存在するバージョンを特定する（S114）。  
　現在時刻を12/17 00:00と仮定すると、データ取得履歴3200の行3221の示す対象時刻範囲に現在時刻を当てはめた結果は「12/10 00:00以上、12/17 00:00未満」となる。
　図10の例では、この時刻範囲に最も長期間データが存在するバージョンの番号は3である。なお、最も長期間データが存在するバージョンが複数存在する場合は、その中で最も新しいバージョンを選択する。
　もし、S114で特定したバージョンが最新のバージョン（図10の例ではバージョン番号4）である場合、削除してはいけない古いバージョンのデータは存在しない。従って、S121以降の処理に移る（S115）。そうでない場合は、S116～117の処理によって、削除不可データを作成する。
　まず、削除不可データ発見手段233は、S113で選択したデータ取得履歴に含まれる対象時刻範囲の開始時刻に、現在の時刻を当てはめる（S116）。そして、S114で特定したバージョンについて、S116で計算した時刻以降の全データをUDLに追加する（S117）。例えば、図7の行3221からは、図8の行3313の削除不可データが作成される。また、削除不可データ発見手段233は、S105と同様の方法で、その削除不可データのデータ量を計算する。
　そして、削除不可データ発見手段233は、S113で選択したデータ取得履歴をもとに、S117で作成した削除不可データに対応するデータ取得パターンを作成し、DRPLに追加する（S118）。例えば、行3221の削除不可データからは、図9のデータ取得パターン3400の行3413のデータ取得パターンが作成される。
　さらに、削除不可データ発見手段233は、対象データがTDと一致し、かつマージポリシが1、2、4または5のデータ取得履歴すべてをデータベースから取得する（S121）。これらは「過去のバージョンのデータを取得する可能性のある」マージポリシを含むデータ取得履歴である。以下では、このデータ取得履歴のリストをDHL3と呼ぶ。図3Bの例では、行3121～3134のデータ取得履歴がDHL3に含まれる。
　次に、削除不可データ発見手段233は、DHL3に含まれるデータ取得履歴について、対象時刻範囲を、要求日時からの相対時刻に変換する（S122）。この処理はS112と同様である。図3Bの例では、行3121～3134のデータ取得履歴が、図7の行3221～3234に変換される。
　そして、削除不可データ発見手段233は、DHL3に含まれるデータ取得履歴から、最も小さい時刻（すなわち最も過去）のデータを要求しているデータ取得履歴を選択する（S123）。最も小さい時刻のデータを要求している、絞り込み条件の同じデータ要求履歴が複数ある場合は、それらすべてを選択する。この処理はS113と同様である。図7の行3221～3234のなかで、最も小さい（最も過去の）時刻のデータを要求しているデータ取得履歴は、対象期間が「1ヶ月前」迄の行3231～3234である。以下では、これらの取得履歴の中で、行3231および行3232の2個が選択されたものと仮定する。
　次に、削除不可データ発見手段233は、S123で選択したデータ取得履歴に含まれる対象時刻範囲の開始時刻に、現在の時刻を当てはめる（S124）。そして、削除不可データ発見手段233は、S124で計算した時刻以降の各時間帯について、データが存在する最も新しいバージョンを特定する（S125）。図10の例では、対象期間が「1ヶ月前」迄の、11/16 00:00から12/1 00:00の時間帯における最新バージョンは2である。12/1 00:00から12/14 00:00の時間帯における最新バージョンは3である。それ以降の時間帯の最新バージョンは4である。
　もし、S125で特定したすべてのバージョンが最新のバージョン（図10の例ではバージョン番号4）である場合、削除してはいけない古いバージョンのデータは存在しない。従って、S121以降の処理に移る（S126）。そうでない場合は、S127～128の処理によって、削除不可データを作成する。
　まず、削除不可データ発見手段233は、S125で特定したバージョン、ここでは、バージョン2～４、について、S124で計算した時刻以降の全データをUDLに追加する（S127）。例えば、図7の行3231および行3232からは、バージョン2～3に関して、図8の行3314～3315の削除不可データが作成される。また、削除不可データ発見手段233は、S105と同様の方法で、その削除不可データのデータ量を計算する。
　そして、削除不可データ発見手段233は、S123で選択したデータ取得履歴をもとに、S127で作成した削除不可データに対応するデータ取得パターン3400を作成し、DRPLに追加する（S128）。例えば、図7の行3231～3232の削除不可データからは、図9の行3414～3415のデータ取得パターンが作成される。
　以上が、削除不可データ発見手段233が、削除不可な時系列データ3300を発見する処理の概要である。削除不可データ発見手段233は、前述のUDLおよびDRPLを、削除可能データ表示手段234に渡す。
　図11は、データベース上の複数バージョンにおける、削除不可データ3300および削除可能データ3400の関係を模式的に示す図である。例えば、データベース上に、図10の複数バージョンの時系列データおよび図3Bのデータ取得履歴が存在する場合、削除不可データ発見手段233は、図11でハッチングされている各バージョンの領域を、UDLとして出力する。図11の削除不可データUDL（1）～（5）は、図８の削除不可データ（1）～（5）に相当する。図11において、ハッチングされていない領域は、削除することが可能なデータ（以下、削除可能データ3450）である。図11において、新旧のバージョンに削除不可データが存在するのは、プログラムのバージョンが新しいものに変わった場合、そのプログラムが適切に動作するか不明なことがあるので、マージポリシにより、旧バージョンに対応したデータも残しておくためである。
　図12は、第1の実施形態における削除可能データ表示手段による画面表示1100の例を示す図である。画面表示1100において、1101は、削除可能な時系列データの名前を示すタブである。このタブは、削除可能な時系列データの種類の数だけ表示される。1102は、削除可能な時系列データの詳細を示す領域である。利用者が1101のタブを選択すると、その種類のなかで削除可能な時系列データの詳細が、領域1102の枠内に表示される。1103は、複数のバージョンの各々における削除可能データ3450および削除不可データ3400のデータ量を示す領域である。削除不可データは、UDLに基づいて生成される。削除可能データ3450は、各バージョンのデータの合計データ量から、削除不可データ3400のデータ量を除算することで生成される。各バージョンのデータの合計データ量は、削除可能データ表示手段234が画面表示時に計算してもよいし、他のプログラムが事前に計算してもよい。1104は、削除不可データ3400の詳細を示す領域である。この領域にはUDLの内容がそのまま表示される。1105は、すべての削除可能データ3450を一括削除するためのボタンである。利用者がこのボタンを押すと、削除可能データ表示手段は、領域1104に示されている削除不可データ3400以外のすべてのデータを削除する。1106は実際の削除は行わず、この画面を閉じるためのボタンである。
　また、削除可能データ表示手段234は、それぞれの削除不可データ3400について、それらのデータを削除できない理由を利用者に提示することができる。例えば、図12の領域1104に含まれる「詳細」ボタンが押されたときに、それらの理由を提示するという方法が考えられる。
　図13は、第1の実施形態における削除可能データ表示手段による削除不可データ3400の詳細表示の例を示す図である。1201は、この画面で詳細を示す削除不可データ3400の情報を示す領域である。1202は、そのデータを削除できない理由である、過去に行われたデータ取得のパターンを示す領域である。この領域にはDRPLの内容がそのまま表示される。1203は、「戻る」ボタンである。
　なお、図12の例では、削除可能データ表示手段は、1104の領域に削除不可データ3400の詳細を表示した。これは、削除不可データに対応するデータ取得パターン（図13）を表示するためのメニュー（「詳細」ボタン）を表示しやすくするためである。しかし、削除可能データ表示手段は、この領域に、削除可能データ3450の詳細を表示してもよい。
　以上のようにして、削除可能データ表示手段234は、データベース管理者らに対して、複数バージョンの時系列データのなかに含まれる削除可能なデータを、表示画面に提示することができる。また、削除可能データ表示手段234は古い分析プログラムによって作成されたデータを削除できる理由を、表示画面上でデータベース管理者らに提示することができる。本実施例によれば、複数バージョンの時系列データを格納するデータベースサーバにおいて、各バージョンの時系列データを、削除不可データと、削除不可データとして区別して表示画面に表示し、これらの情報を利用して、利用者の判断で削除するデータを決定するので、利用者は、データベースサーバ上の古い分析プログラムによって作成されたデータのデータ量を最小化することが容易となる。
　これにより、データベース管理者らは、分析処理の見直し時（バージョンアップ時）に、データベースサーバ上の、古い分析プログラムによって作成された複数バージョンの時系列データのデータ量を最小化できる。また、データベース管理者らが実際に削除するデータを決定するための作業時間を短縮できる。
　また、上記の削除不可データ発見手段233および削除可能データ表示手段234は、自動的に起動されてもよい。また、これらのプログラムが、削除可能データ3450の削除まで自動的に行ってもよい。これらのプログラムを自動的に起動する方法としては、ジョブスケジューラによって定期的に起動する方法や、何らかのイベント（例えば、新しいバージョンのデータが初めて登録されたことや、データベースのディスク使用量が閾値を超えたこと）を契機に起動する方法がある。このように、本実施例によれば、複数バージョンの時系列データを格納するデータベースサーバにおいて、古い分析プログラムによって作成されたデータを自動的に削除し、データベースサーバのディスク使用量を自動的に最小化することもできる。これらのプログラムの起動を自動化した場合、データベース管理者らが実際に削除するデータを決定するための作業時間をゼロにすることができる。これにより、時系列データを格納するデータベースの運用コストの削減という効果が得られる。また、その結果、新旧処理の並行稼働期間も最小化できるため、分析に必要なCPU資源等も最小化できる。
　次に、本発明の第2の実施例に係るデータベースサーバについて、説明する。  
　図14は、第2の実施形態におけるデータベース管理サーバの内部構造を示す機能ブロック図である。実施例2で想定するデータベースサーバおよびデータベース管理サーバ2の内部構造は、実施例1のものと同じである。ただし、本実施例では、削除不可データ発見手段233および削除可能データ表示手段234に加えて、停止可能な分析処理の発見・表示プログラム（停止可能な分析処理の発見・表示手段）237を備えており、削除可能なデータに加えて、停止可能な分析プログラムをデータベース管理者および分析プログラムの開発者に提示する。
　図15は、第2の実施形態における削除可能データ表示手段234及び停止可能な分析処理の発見・表示手段237による画面表示1100の例を示す図である。1101～1106は、第1の実施形態における画面表示（図12）と同じである。
　1107は、分析プログラムのなかで停止可能なバージョンのものを示す領域である。
　この領域には、現在時刻から過去一定期間（例えば1日）の間に削除不可データ3400が存在しないバージョン番号を表示する。例えば、図11の例では、12/16 00:00から12/17 00:00の間に、バージョン1～2には削除不可データが存在しない。そのため、停止可能な分析処理の発見・表示手段237は、バージョン番号1～2を、停止可能な分析プログラムのバージョン番号として表示する。
　1108は、すべての停止可能な分析プログラムを一括停止するためのボタンである。利用者がこのボタンを押すと、停止可能な分析処理の発見・表示手段237は、指定されたバージョンの分析プログラムの開発者への連絡、指定されたバージョンの分析プログラムへの停止命令の送信、または指定されたバージョンの分析プログラムからのデータ登録の拒否を行う。
　以上のようにして、停止可能な分析処理の発見・表示手段237は、データベース管理者または分析プログラムの開発者に対して、分析プログラムの中で停止可能なバージョンのものを表示画面上に提示することができる。なお、停止可能な分析処理の発見・表示手段237の機能と削除可能データ表示手段234の機能を纏めて、１つの削除可能データ表示手段234として構成しても良い。
　これにより、データベース管理者らは、表示画面1100に表示された情報を利用して、データベースサーバ上の、古い分析プログラムによって作成されたデータのデータ量を最小化できる。また、データベース管理者らは、分析サーバ上での分析プログラムの動作に必要なCPU資源やネットワーク資源の利用料を最小化できる。また、データベース管理者らが実際に停止する分析プログラムを決定するための作業時間を短縮できる。
　また、上記の削除不可データ発見手段233、削除可能データ表示手段234、及び、停止可能な分析処理の発見・表示手段237は、自動的に起動されてもよい。また、これらのプログラムが、古いバージョンの分析プログラムの停止まで自動的に行ってもよい。これらのプログラムを自動的に起動する方法としては、ジョブスケジューラによって定期的に起動する方法や、何らかのイベント（例えば、新しいバージョンのデータが初めて登録されたことや、データベースのディスク使用量が閾値を超えたこと）を契機に起動する方法がある。このように、これらのプログラムの起動を自動化した場合、データベース管理者らが実際に停止する分析プログラムを決定するための作業時間をゼロにすることができる。これにより、時系列データを格納するデータベース、および時系列データを作成する分析サーバの運用コストの削減という効果が得られる。
　次に、本発明の第3の実施例に係るデータベースサーバについて、説明する。  
　実施例3で想定するデータベースサーバは、実施例1および2のものと同じである。ただし、データベース管理サーバ2の内部構造は、実施例1および2のものと異なる。
　図16は、第3の実施形態におけるデータベース管理サーバの内部構造を示す機能ブロック図である。データベース管理サーバ2はインターフェイス（I/F）21を通してパケットを送受信する。データベース管理サーバ2の各プログラムはメモリ23に格納されており、メモリ23は、実施例1と同じプログラムに加えて、マージポリシ変更案作成プログラム235およびマージポリシ変更案表示プログラム236を格納する。データベース管理サーバ2の動作時にはCPU 22がデータパス24を通してそれらを読み出して実行することで、これらのプログラムをCPU 22で実行することにより、データベース管理サーバ(コンピュータ)2を、検索手段（231）、データ登録手段（232）、削除不可データ発見手段（233）、削除可能データ表示手段（234）、マージポリシ変更案作成手段（235）およびマージポリシ変更案表示手段（236）として機能させる。
　マージポリシ変更案作成手段235は、削除不可データ発見手段233が作成した削除不可データUDLおよびデータ取得パターンDRPLを用いて、分析プログラムが指定するマージポリシの変更案（以下、マージポリシ変更案）を作成するプログラムである。マージポリシ変更案は、過去に行われたデータ取得要求と、そのデータ取得要求における新しいマージポリシの組である。また、1個のマージポリシ変更案のなかに、2個以上のデータ取得要求の変更が含まれていてもよい。マージポリシ変更案作成手段235は、作成したマージポリシ変更案を、マージポリシ変更案表示手段236に渡す。
　図17は、マージポリシ変更案3500の一例である。列3501は、マージポリシ変更案作成手段235が、個々のマージポリシ変更案に対して一意に割り当てる識別子である。列3502は、このマージポリシ変更案に関連する削除不可データ3400のIDである。列3503は、マージポリシを変更できる可能性のあるデータ取得パターンのIDである。マージポリシ変更案3500は、このパターンIDの代わりに、データ取得要求そのものを格納してもよい。列3504は、列3503が示すデータ取得パターンの、現在のマージポリシである。列3505は、マージポリシ変更案作成手段235が作成した新しいマージポリシである。現在のマージポリシが２、すなわち、検索した範囲の中で「最も長期間存在するバージョンのデータを優先」であったものを、マージポリシ１、すなわち、検索した範囲の中で「最新バージョンのデータを優先」に変更すると、削除可能なデータ量の増加が見込める。現在のマージポリシ６をマージポリシ２に変更することによっても、同様に、削除可能なデータ量の増加が見込める。このように、マージポリシ変更案作成手段235は、データ量の削減等、予め設定された指針に基づいて、マージポリシの変更案を生成する。
　マージポリシ変更案表示手段236は、マージポリシ変更案作成手段235が生成したデータに基づいて、表示画面1300（図19参照）においてマージポリシの変更案3500をデータベース管理者または分析プログラムの開発者に提示する。または、このプログラムは、検索手段231の設定ファイルを更新するなどの方法により、検索手段231が受信するデータ取得要求に含まれるマージポリシの一部を、強制的に変更する。
　図18は、マージポリシ変更案作成手段235が、マージポリシの変更案を作成するためのフローチャートである。  
　マージポリシ変更案作成手段235は、最初に、削除不可データ発見手段233が作成した削除不可データ3400のリストを取得する（S201）。以下では、このリストをUDLと呼ぶ。これ以降では、UDLに含まれる個々の削除不可データ3400（以下、UD）に対して、S204～S215の処理を行う（S202～203）。
　まず、マージポリシ変更案作成手段235は、UDの時刻範囲に、UDと同じ対象データかつ、UDのバージョン番号よりも新しいバージョンのデータが存在するか検索する（S204）。そして、もしこの検索条件に該当するデータが存在しない場合は、UDに基づくマージポリシ変更案の作成を中断する（S205）。例えば、UDとして図8の削除不可データ3300の行3311が選択された場合、11/1 00:00から11/2 00:00の間には、バージョン1より新しいバージョンのデータは存在しない。従って、マージポリシ変更案作成手段235は、マージポリシ変更案の作成を中断する。
　次に、マージポリシ変更案作成手段235は、削除不可データ発見手段233が作成したデータ取得パターンのリストから、削除不可データIDがUDに一致するものを取得する（S206）。以下では、ここで取得したデータ取得パターンのリストをDRPL2と呼ぶ。そして、このDRPL2のなかに、マージポリシが2、4または6のデータ取得パターンが1個もない場合は、UDに基づくマージポリシ変更案の作成を中断する（S207）。例えば、UDとして図8の削除不可データ3300の行3314が選択された場合、UDに対応するデータ取得パターンは図9のデータ取得パターン3400の行3414～3415である。しかし、これらのデータ取得パターンのマージポリシはすべて1である。従って、マージポリシ変更案作成手段235は、マージポリシ変更案の作成を中断する。
　マージポリシ変更案作成手段235は、上記のチェックを通過したUDに対して、マージポリシ変更案を一意に識別するための識別子を割り当てる（S208）。図8の削除不可データ3300の例では、行3313が示すUDのみが上記のチェックを通過する。以下の説明では、このUDに対して、変更案IDとして1が割り当てられたものとする。
　これ以降では、DRPL2に含まれる個々のデータ取得パターン（以下、DRP）に対して、S211～S215の処理を行う（S209～S210）。これらの処理は、過去のバージョンのデータを使う可能性が高いマージポリシを、そのような可能性がより低いマージポリシに変更する処理である。例えば、マージポリシ6は、過去に取得したデータと同じバージョンを常に優先するが、マージポリシ2は新しいバージョンのデータを優先する場合もある。また、マージポリシ2は古いバージョンのデータを優先する場合もあるが、マージポリシ1は常に新しいバージョンのデータを優先する。従って、本実施例のマージポリシのなかでは、過去のバージョンのデータを使う可能性が最も高いのはマージポリシ6である。一方、そのような可能性が最も低いのはマージポリシ1である。マージポリシ2、4、5は両者の中間に位置する。
　まず、マージポリシ変更案作成手段235は、DRPのマージポリシが6であるかどうかを検査する（S211）。つまり、DRPのマージポリシが、「過去に取得したデータと同じバージョンを優先する」マージポリシかどうかを検査する。DRPのマージポリシが6である場合は、DRPのマージポリシを2に変更する案を、メモリ上のマージポリシ変更案のリスト（以下、MPL）に追加する（S212）。
　次に、マージポリシ変更案作成手段235は、DRPのマージポリシが2、4または5であるかどうかを検査する（S213）。つまり、DRPのマージポリシが、「最新バージョンのデータよりも、最も長期間存在するバージョンのデータを優先する」マージポリシかどうかを検査する。DRPのマージポリシが2、4または5の場合は、DRPのマージポリシを1に変更する案を、MPLに追加する（S214）。例えば、図9のデータ取得パターン3400の行3413からは、図17のマージポリシ変更案3500の行3511が作成される。
　DRPが上記のいずれの条件にも該当しない場合は、DRPのマージポリシを変更しない案を、MPLに追加する（S215）。  
　以上が、マージポリシ変更案作成手段235が、マージポリシ変更案を作成する処理の概要である。マージポリシ変更案作成手段235は、前述のMPLを、マージポリシ変更案表示手段236に渡す。
　なお、本実施例では、マージポリシ6はマージポリシ2に、マージポリシ2、4、5はマージポリシ1に変更する案を作成した。これは、マージポリシの変更が後続処理に与える影響を極力少なくするためである。しかし、後続処理への影響よりもデータ量の削減を優先したい場合、マージポリシ変更案作成手段235は、マージポリシ6から1に変更する案などを作成してもよい。
　図19は、第3の実施形態におけるマージポリシ変更案表示手段による表示画面1300の表示の例を示す図である。1301は、マージポリシ変更案のIDを示すタブである。このタブは、作成されたマージポリシ変更案の数だけ表示される。1302は、マージポリシ変更案の詳細と、その変更案によって削減されるデータ量を示す領域である。利用者が1301のタブを選択すると、そのマージポリシ変更案に関係する情報が、1302の枠内に表示される。1303は、そのマージポリシ変更案によってデータ量を削減できる、削除不可データ3400の情報を示す領域である。この領域は、UDLに基づいて生成される。削除可能データ3450および削除不可データ3400のデータ量は、削除可能データ表示手段234と同様の方法で計算される。1304は、マージポリシ変更案の詳細である。この領域には、MPLのなかにある、タブ1301で選択されたIDと同じ変更案IDを持つマージポリシ変更案が表示される。マージポリシ変更案表示手段236は、利用者のための判断材料として、DRPLに含まれる情報を用いて、そのデータ取得パターンによる過去のアクセス回数などを表示画面1300に表示してもよい。1305は、そのマージポリシ変更案によって削減できるデータ量を、バージョン番号ごとに示す領域である。このデータ量も、削除可能データ表示手段234と同様の方法で計算される。なお、領域1305に、「削減できるデータ量」の期間やバージョンの情報も併せて提示しても良い。1306は、このマージポリシ変更案を、古いバージョンの分析プログラムを開発した開発者に通知するためのボタンである。利用者がこのボタンを押すと、マージポリシ変更案表示手段236は、1305に表示されているすべてのバージョンの分析プログラムの開発者へ、この情報をメール等で通知する。1307は、このマージポリシ変更案を、検索手段231に対して強制的に適用するためのボタンである。1307はマージポリシ変更案の通知や強制適用は行わず、この画面を閉じるためのボタンである。
　なお、本実施例では、タブ1301を、変更案IDの順に表示している。しかし、マージポリシ変更案表示手段236は、利用者が、実際に採用するマージポリシ変更案を選ぶことを助けるために、この表示順を変更してもよい。例えば、マージポリシ変更案表示手段236は、以下のような基準で表示順を変更してもよい。
　・削減できるデータ量が多い順
　・マージポリシの変更が必要なデータ取得パターンの数が少ない順
　・マージポリシの変更が必要な分析プログラム（要求元プログラム名）の数が少ない順
　・マージポリシの変更が必要なデータ取得パターンにおけるアクセス回数の合計値が少ない順
　以上のようにして、マージポリシ変更案表示手段236は、データベース管理者らに対して、データ取得要求の中に含まれるマージポリシの修正案を表示画面1300に提示することができる。また、マージポリシ変更案表示手段236は、その修正によって削減できるデータ量を、表示画面1300においてデータベース管理者らに提示することができる。
　これにより、データベース管理者らは、データベースサーバ上の、古い分析プログラムによって作成されたデータのデータ量を最小化できる。また、分析プログラムの開発者が、マージポリシの変更方法を決定するための作業時間や、マージポリシを変更するために分析プログラムを修正するための作業時間を短縮できる。
　また、上記の削除不可データ発見手段233、マージポリシ変更案作成手段235、およびマージポリシ変更案表示手段236は、自動的に起動されてもよい。また、これらのプログラムが、マージポリシ変更案の適用まで自動的に行ってもよい。これらのプログラムを自動的に起動する方法としては、ジョブスケジューラによって定期的に起動する方法や、何らかのイベント（例えば、新しいバージョンのデータが初めて登録されたことや、データベースのディスク使用量が閾値を超えたこと）を契機に起動する方法がある。このように、これらのプログラムの起動を自動化した場合、分析プログラムの開発者がマージポリシを変更するための作業時間をゼロにすることができる。これにより、分析プログラムの運用コストの削減という効果が得られる。
　以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計なども含まれる。
1　ネットワーク
2　データベース管理サーバ
21　I/F
22　CPU
23　メモリ
231　データ取得プログラム
232　データ登録プログラム
233　削除不可データ発見プログラム
234　削除可能データ表示プログラム
235　マージポリシ変更案作成プログラム
236　マージポリシ変更案表示プログラム
24　データパス
3　データベース
3000　時系列データ
3100　データ取得履歴
3300　削除不可データ
3400　データ取得パターン
3450　削除可能データ　
4　生データ生成サーバ
5　分析サーバ
6　管理者端末
7　物理的な通信回線。

Claims (15)

  1. 　各種の時系列データについて、複数のバージョンのデータを格納可能なデータベースと、
    　前記データベースを管理するデータベース管理サーバとを備え、
    　前記データベース管理サーバは、前記データベースの検索条件に加えて、前記複数バージョンのデータの混在を許すかどうかのポリシが定義されたマージポリシを指定可能な検索手段を備え、
    　前記検索手段は、前記指定されたマージポリシに基づいて、前記検索条件に含まれる時間の範囲内で前記複数バージョンのデータをマージした結果をデータ取得履歴として生成し、該データ取得履歴を前記データベースに記録する
    ことを特徴とするデータベースサーバ。
  2. 　請求項1において、
    　前記データベース管理サーバは、
    　前記データ取得履歴を基に、前記検索条件に含まれる時間の範囲内で削除可能な前記時系列データのバージョン及びその時間範囲を計算し、該計算結果を出力する
    ことを特徴とするデータベースサーバ。
  3. 　請求項２において、
    　前記マージポリシは、
    　最新バージョンのデータと、前記検索条件に含まれる時間の範囲で最も長期間存在するバージョンのデータのどちらを優先するかを指定できる
    ことを特徴とするデータベースサーバ。
  4. 　請求項２において、
    　前記マージポリシは、
    　過去に取得したデータと同じバージョンを優先するかどうかを指定できる
    ことを特徴とするデータベースサーバ。
  5. 　請求項２において、
    　前記マージポリシは、
    　前記検索条件の範囲に前記複数のバージョンのデータが混在する場合、前記複数バージョンのデータのマージを許可するかどうかを指定できる
    ことを特徴とするデータベースサーバ。
  6. 　複数のバージョンの分析プログラムを保有する分析サーバと、
    　前記複数のバージョンの分析プログラムに対応する、各種の時系列データを格納可能なデータベースと、
    　前記データベースを管理するデータベース管理サーバと、
    　管理者端末とを備え、
    　前記データベース管理サーバは、
    　前記データベースの検索条件に加えて、前記複数バージョンのデータをマージする方法が定義されたマージポリシを指定可能な検索手段と、
    　削除不可な時系列データを発見する削除不可データ発見手段と、
    　削除可能なデータを表示する、削除可能データ表示手段とを備え、
    　前記検索手段は、前記複数バージョンのデータに関して、前記検索条件に含まれる時間の範囲内で、前記マージポリシを含むデータ取得履歴を前記データベースに記録し、
    　前記削除不可データ発見手段は、該データ取得履歴を基に、削除可能な前記時系列データのバージョン及びその時間範囲を計算し、
    　前記削除可能データ表示手段は、前記削除不可データ発見手段の計算結果を前記管理者端末へ提示する
    ことを特徴とするデータベースサーバ。
  7. 　請求項６において、
    　前記削除不可データ発見手段は、前記時系列データを削除できない理由になっている過去のデータ取得要求に共通するデータ取得パターンを計算し、
    　前記削除可能データ表示手段は、該削除不可データ発見手段の計算結果を、前記管理者端末へ提示する
    ことを特徴とするデータベースサーバ。
  8. 　請求項６において、
    　前記データベース管理サーバは、削除可能という結果が得られた前記時系列データを自動的に削除する
    ことを特徴とするデータベースサーバ。
  9. 　請求項６において、
    　前記データベース管理サーバは、前記マージポリシを含むデータ取得履歴を基に、停止可能な前記分析プログラムのバージョンを特定し、
    　該特定した分析プログラムのバージョンを前記管理者端末へ提示する
    ことを特徴とするデータベースサーバ。
  10. 　請求項６において、
    　前記データベース管理サーバは、前記マージポリシを含むデータ取得履歴を基に、ディスク使用量を削減可能なマージ方法の変更案を作成し、該マージ方法の変更案を、前記管理者端末へ提示する
    ことを特徴とするデータベースサーバ。
  11. 　請求項１０において、
    　前記データベース管理サーバは、停止可能という結果が得られた古いバージョンの前記分析プログラムを自動的に停止すると共に、
    　該停止可能という結果を、前記管理者端末へ自動的に提示する
    ことを特徴とするデータベースサーバ。
  12. 　請求項１０において、
    　前記計算結果に基づいて、前記分析プログラムから送られるデータ取得要求のうち一部について、前記マージポリシを自動的に変更し、
    　該マージ方法の変更案に関連付けられた前記分析プログラムの変更案を、前記管理者端末へ自動的に提示する
    ことを特徴とするデータベースサーバ。
  13. 　データベース管理サーバによる、データベースの管理方法であって、
    　前記データベースは、各種の時系列データについて、複数のバージョンのデータを格納可能であり、
    　前記データベース管理サーバは、
    　前記データベースの検索条件に加えて、前記複数バージョンのデータをマージする方法が定義されたマージポリシの指定を受け付け、
    　前記指定されたマージポリシに基づいて、前記検索条件に含まれる時間の範囲内で、前記複数バージョンのデータをマージした結果をデータ取得履歴として生成し、
    　該データ取得履歴を前記データベースに記録し、
    　該データ取得履歴を基に、削除可能な前記時系列データのバージョン及びその時間範囲を計算し、該計算結果を管理者端末へ提示する
    ことを特徴とするデータベースの管理方法。
  14. 　請求項１３において、
    　前記データベース管理サーバは、
    　前記データ取得履歴を基に、前記時系列データを削除できない理由になっている過去のデータ取得要求に共通するデータ取得パターンを計算し、
    　該データ取得パターンを前記管理者端末へ提示する
    ことを特徴とするデータベースの管理方法。
  15. 　請求項１３において、
    　前記データベース管理サーバは、
    　前記データ取得履歴を基に、停止可能な前記分析プログラムのバージョンを特定し、
    　該特定した分析プログラムのバージョンを前記管理者端末へ提示する
    ことを特徴とするデータベースの管理方法。
PCT/JP2013/063213 2013-05-10 2013-05-10 複数バージョンのデータを格納するデータベースサーバ、及び、データベース管理方法 WO2014181475A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2013/063213 WO2014181475A1 (ja) 2013-05-10 2013-05-10 複数バージョンのデータを格納するデータベースサーバ、及び、データベース管理方法
US14/768,078 US20150379065A1 (en) 2013-05-10 2013-05-10 Database server storing plurality of versions of data, and database management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/063213 WO2014181475A1 (ja) 2013-05-10 2013-05-10 複数バージョンのデータを格納するデータベースサーバ、及び、データベース管理方法

Publications (1)

Publication Number Publication Date
WO2014181475A1 true WO2014181475A1 (ja) 2014-11-13

Family

ID=51866974

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/063213 WO2014181475A1 (ja) 2013-05-10 2013-05-10 複数バージョンのデータを格納するデータベースサーバ、及び、データベース管理方法

Country Status (2)

Country Link
US (1) US20150379065A1 (ja)
WO (1) WO2014181475A1 (ja)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008043082A2 (en) 2006-10-05 2008-04-10 Splunk Inc. Time series search engine
WO2013136718A1 (ja) * 2012-03-16 2013-09-19 日本電気株式会社 時系列データ処理装置、時系列データ処理方法及び時系列データ処理プログラム記憶媒体
US10324942B2 (en) * 2013-07-26 2019-06-18 Snap Inc. Segment data visibility and management in a distributed database of time stamped records
US10417258B2 (en) 2013-12-19 2019-09-17 Exposit Labs, Inc. Interactive multi-dimensional nested table supporting scalable real-time querying of large data volumes
US10229128B2 (en) * 2014-11-19 2019-03-12 Rubrik, Inc. Method and apparatus for the generation, organization, storage and retrieval of time stamped blocks of data
US10452651B1 (en) 2014-12-23 2019-10-22 Palantir Technologies Inc. Searching charts
US9672257B2 (en) 2015-06-05 2017-06-06 Palantir Technologies Inc. Time-series data storage and processing database system
TWI546728B (zh) * 2015-09-09 2016-08-21 群暉科技股份有限公司 用來對一儲存系統進行版本管理之方法與裝置
US9753935B1 (en) 2016-08-02 2017-09-05 Palantir Technologies Inc. Time-series data storage and processing database system
GB201708818D0 (en) 2017-06-02 2017-07-19 Palantir Technologies Inc Systems and methods for retrieving and processing data
US9990389B1 (en) 2017-06-08 2018-06-05 Visier Solutions, Inc. Systems and methods for generating event stream data
US11288255B2 (en) * 2017-06-08 2022-03-29 Visier Solutions, Inc. Systems and methods for generating event stream data
US10417224B2 (en) 2017-08-14 2019-09-17 Palantir Technologies Inc. Time series database processing system
US10216695B1 (en) 2017-09-21 2019-02-26 Palantir Technologies Inc. Database system for time series data storage, processing, and analysis
US11281726B2 (en) 2017-12-01 2022-03-22 Palantir Technologies Inc. System and methods for faster processor comparisons of visual graph features
US11016986B2 (en) 2017-12-04 2021-05-25 Palantir Technologies Inc. Query-based time-series data display and processing system
US11360955B2 (en) * 2018-03-23 2022-06-14 Ebay Inc. Providing custom read consistency of a data object in a distributed storage system
US11263193B2 (en) * 2018-11-19 2022-03-01 Clover Health Generating tables using data records

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011174795A (ja) * 2010-02-24 2011-09-08 Nec Corp データ処理装置、および、プログラム
JP2012503260A (ja) * 2008-09-22 2012-02-02 クゥアルコム・インコーポレイテッド 通信ネットワーク内のメディアコンテンツリストのバージョンを調整する方法および機器

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8786624B2 (en) * 2009-06-02 2014-07-22 Cyberonics, Inc. Processing for multi-channel signals
WO2013136718A1 (ja) * 2012-03-16 2013-09-19 日本電気株式会社 時系列データ処理装置、時系列データ処理方法及び時系列データ処理プログラム記憶媒体

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012503260A (ja) * 2008-09-22 2012-02-02 クゥアルコム・インコーポレイテッド 通信ネットワーク内のメディアコンテンツリストのバージョンを調整する方法および機器
JP2011174795A (ja) * 2010-02-24 2011-09-08 Nec Corp データ処理装置、および、プログラム

Also Published As

Publication number Publication date
US20150379065A1 (en) 2015-12-31

Similar Documents

Publication Publication Date Title
WO2014181475A1 (ja) 複数バージョンのデータを格納するデータベースサーバ、及び、データベース管理方法
JP7369153B2 (ja) 処理環境の統合監視および制御
US7624394B1 (en) Software installation verification
JP6346377B2 (ja) １つまたは複数のクラウドシステムにアプリケーションを移動可能にデプロイする方法及びシステム
RU2419854C2 (ru) Основанное на шаблоне управление службами
US6909992B2 (en) Automatically identifying replacement times for limited lifetime components
US11706084B2 (en) Self-monitoring
JP2014048673A (ja) ワークフロー生成サーバ、及び方法
US20150222731A1 (en) Computer, guide information providing method and recording medium
CA2852760A1 (en) Migration assessment for cloud computing platforms
EP1955235A2 (en) System and method of managing data protection resources
JP2012069118A (ja) プロセス制御の検索結果を管理するための方法および装置
WO2013038489A1 (ja) 計算機システム、クライアント計算機の管理方法及び記憶媒体
JP5614843B2 (ja) ソフトウェア設計・運用統合管理システム
JP2007316905A (ja) アプリケーションプログラムを監視する計算機システム及びその方法
WO2018098478A1 (en) System and method for analyzing and associating elements of a computer system by shared characteristics
US20220374285A1 (en) Topology-based migration assessment
JP2009217455A (ja) 情報処理装置、情報処理プログラム及び方法
EP3367241B1 (en) Method, computer program and system for providing a control signal for a software development environment
US20220164703A1 (en) Model acceptance determination support system and model acceptance determination support method
JP2011039884A (ja) 文書を収集するためのシステムおよびプログラム
US20130218928A1 (en) Information processing device
Xu et al. ECL-watch: a big data application performance tuning tool in the HPCC systems platform
JP7036603B2 (ja) 運用管理システム
JP7475086B1 (ja) 編集方法、編集装置及びプログラム

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: 13883975

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14768078

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13883975

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP