JP6889254B2 - Database system, method and program - Google Patents

Description

The present disclosure relates to a technique for managing and modifying the contents of a database.

Conventionally, as a synchronization method in a multiplexed database system, in a multiplexed database system in which an intermediary device transfers a processing request from a client to a plurality of servers and returns a valid response result received from each server to the client. , A technique has been proposed in which an intermediary device assigns a sequence number to a processing request, each server sorts the processing request based on the sequence number, and controls the input order to the DBMS so that a lock conflict or the like does not occur in the server. (See Patent Document 1).

In addition, when a mobile agent is used for the data replication function and the database is updated at site A, this update is detected, update transaction data is generated from the updated contents, the data is moved to site B, the update transaction is executed, and the database is executed. A distributed database system for updating is proposed (see Patent Document 2).

In addition, various data management methods have been proposed in which data operation logs are accumulated and data is managed in the log format (see Non-Patent Documents 1 and 2).

JP-A-2007-219598 Japanese Unexamined Patent Publication No. 2001-350777

Hoang Tam Vo, Sheng Wang, Divyakant Agrawal, Gang Chen, Beng Chin Ooi, “LogBase: A Scalable Log-Structured Database System” Philip A. Bernstein, Colin W. Red, Sudipto Das, "Hyder-A Transitional Record Manager for Shared Flash"

Conventionally, in a database management system (DBMS), in order to improve the efficiency of a search process, a view as a search result according to a predetermined search condition is created in advance to improve the efficiency of the search process. However, to modify such a view, first modify the table used to create the view, search the modified table to extract the information needed to modify the view, and then modify the view. The process of doing is required. Such processing is executed, for example, by using a table change as a trigger, but the processing content is complicated and the processing load on the entire system is large.

Here, in order to reduce the processing load required to change the view, a system using a logical view in which the content of the view as an entity is not generated / retained can be considered. However, in such a logical view, it is difficult to reduce the load of the search process because the table is referenced each time the view is referenced.

In view of the above problems, the technique according to the present disclosure has an object of providing a view as a search result according to a predetermined search condition while suppressing both the processing load for changing the view and the processing load for referencing the view. To do.

In the present disclosure, the following means are adopted in order to solve the above-mentioned problems. That is, the database system according to the present disclosure is a database system including one or more session management nodes, one or more data store management nodes, and at least one view management node, and each of the session management nodes. Is a data set generation means for generating a data set including the target identification information that can uniquely grasp the data unit to be changed when the contents of the database are changed and the changed contents of the data unit. A data set transmission means for transmitting the data set to at least one of the data store management nodes, each of the data store management nodes sending the received data set in a time series of transactions. A database management means that sets and stores a transaction identifier that can grasp the position, and a view data set that includes data that matches preset search conditions based on the data set stored by the database management means. The view management node includes a view data generation means for generating data and a view data transmission means for transmitting the view data set to the view management node, and the view management node matches the preset search condition. The view data acquisition means for acquiring the view data set including the data from the data store management node and the set of data included in the view data set acquired by the view data acquisition means are set in advance. A view management means for holding the view as a view corresponding to the search condition and a view search means for searching the view according to a specified search condition are provided, and the view management means includes data included in the view data set. Among them, a set of data before the time specified by the view transaction identifier, which is a transaction identifier indicating a snapshot corresponding to the view, is retained as a view corresponding to the preset search condition and the view transaction identifier. It is a database system.

The present disclosure can be understood as a method executed by an information processing device, a system, a computer, or a program executed by a computer. Further, the present disclosure can be grasped as if such a program is recorded on a recording medium that can be read by a computer or other device, a machine, or the like. Here, a recording medium that can be read by a computer or the like is a recording medium that can be read from a computer or the like by accumulating information such as data or programs by electrical, magnetic, optical, mechanical or chemical action. Say.

According to the technique according to the present disclosure, it is possible to provide a view as a search result according to a predetermined search condition while suppressing both the processing load for changing the view and the processing load for referencing the view.

It is a figure which illustrates the structure of the database system which concerns on embodiment. It is a figure which shows the outline of the hardware configuration of the node which concerns on embodiment. It is a figure which shows the outline of the functional structure of the node which concerns on embodiment. It is a figure which shows the structure of the change data set generated in an embodiment. It is a flowchart (1) which shows the flow of the database management process in an embodiment. It is a flowchart (2) which shows the flow of the database management process in an embodiment. It is a figure which shows the flow of instruction processing and data set generation / update processing for change executed by the session manager in embodiment. It is a flowchart (3) which shows the flow of the database management process in an embodiment. It is a flowchart (4) which shows the flow of the database management process in an embodiment. It is a flowchart (5) which shows the flow of the database management process in an embodiment. It is a flowchart which shows the flow of the data search process in the data store manager which concerns on embodiment. It is a flowchart which shows the flow of the data search process in the view manager which concerns on embodiment. It is a flowchart which shows the flow of the truncated process in the data store manager which concerns on embodiment. It is a flowchart which shows the flow of the view creation process which concerns on embodiment. It is a flowchart (1) which shows the flow of view change processing which concerns on embodiment. It is a flowchart (2) which shows the flow of view change processing which concerns on embodiment. It is a flowchart (3) which shows the flow of view change processing which concerns on embodiment.

Hereinafter, embodiments of the system, information processing apparatus, method, and program according to the present disclosure will be described with reference to the drawings. However, the embodiments described below are merely examples of the embodiments, and the system, information processing apparatus, method, and program according to the present disclosure are not limited to the specific configurations described below. In the implementation, a specific configuration according to the embodiment may be appropriately adopted, and various improvements and modifications may be made.

<System configuration>
Hereinafter, in a database system having a plurality of nodes, when a transaction including a database content change instruction (INSERT instruction, DELETE instruction, UPDATE instruction, etc.) is processed, the change content related to the change instruction is transmitted to the database system. The technology to be managed in each data store managed by a plurality of nodes belonging to is described. Here, the data store is a term indicating a record of a part or all of the database managed by the database system according to the present disclosure, or a place where a part or all of the database is held. The database management technique according to the present disclosure is applicable not only to the system exemplified in the present embodiment but also to a database system having a plurality of nodes. Further, the database system to which the database management technology according to the present disclosure can be adopted is not limited to a specific type of database system.

FIG. 1 is a diagram illustrating the structure of the database system according to the present embodiment. In the database system according to the present embodiment, a plurality of information processing devices (nodes) are connected to each other so as to be able to communicate with each other via a network. In the database system according to the present embodiment, at least one of the plurality of nodes is a transaction management node having a role as a transaction manager. In addition, some of the other plurality of nodes are nodes that have a role as a session manager and operate as a session management node. In addition, some of the other plurality of nodes are nodes that have a role as a data store manager and operate as a data store management node. Further, some of the other plurality of nodes are nodes that have a role as a view manager and operate as a view management node.

However, the database system to which the database management technology according to the present disclosure can be applied is not limited to the database system having the configuration illustrated in the present embodiment. For example, the session manager and the data store manager may operate on the same node. In addition, when constructing a database system that does not refer to views, the view manager may be omitted. In any case, the database system according to the present embodiment includes a plurality of session management nodes, a plurality of data store management nodes, and at least one transaction management node.

In the present embodiment, each data store management node has a data store managed by a data store manager operating by itself, and these data stores are of a database managed by the database system according to the present disclosure. I have some or all of the data. In the database management technology according to the present disclosure, a change dataset containing the contents of changes made to the database is generated by one of the session managers and propagated to one or more data store managers belonging to the system. By assigning a transaction ID to the change data set and managing it in each data store, the change of the entire database is completed. Therefore, in the system according to the present embodiment, when the change data set is generated, the same change data set is transmitted to a plurality of data store managers, so that the data store management can be made redundant and the database replication can be performed. Can be realized. Redundancy of data store management can be realized by, for example, specifying multiple node IDs of destinations of the data set for change, and preparing multiple data store management nodes for a single node ID. But it is feasible. Details of the database management technology will be described later.

Further, in the present embodiment, each view management node has a view managed by a view manager that operates on its own. In the present embodiment, the view is a view that narrows down the data at the time specified by a certain transaction ID according to the search conditions and organizes the data into a form suitable for the search. This search condition is notified to the data store manager and the session manager together with information that can identify the view related to the search condition. The format in which the view holds data is not limited. The view can hold data in the form of, for example, a table or a graph. In this embodiment, it is assumed that one view manager manages one view. Therefore, in the present embodiment, the view manager can be identified by the ID of the view, and the search condition (view search condition) used to generate the view is to identify the view and the view manager. It can also be used as information for. However, a plurality of views may be managed by one view manager.

Further, the range of data covered by the views can be arbitrarily set, and the data covered by the plurality of views may overlap with each other, or some data may not be covered by any of the views. Even if the data is not covered by the view, the data store manager manages it in the form of a change dataset, so it is possible to search all the data. That is, according to the system according to the present embodiment, it is possible to cover the data for which the search speed is desired to be covered by the view while reducing the processing load of the data change by the data management by the data set for change.

In the present embodiment, a plurality of views or view managers (view management nodes) have a hierarchical relationship, and the upper view can be constructed by referring to the data covered by the lower view. When the hierarchical relationship of the views extends to three or more layers and the upper layer views refer to the lower layer views, the layers to which these views belong do not have to be adjacent (for example, the third layer view is the first layer). You can see the view of the layer).

Further, the user terminal 9 is connected to the network. The database system disclosed in the present embodiment is a database system in which any session manager can receive and execute a query transmitted from a user terminal 9 or the like.

FIG. 2 is a diagram showing an outline of the hardware configuration of the node according to the present embodiment. The node includes a control unit 10 including a CPU (Central Processing Unit) 11, a RAM (Random Access Memory) 12, a ROM (Read Only Memory) 13, a storage (auxiliary storage device) 14, and a communication interface 15. It is a computer. However, the specific hardware configuration of the node can be omitted, replaced, or added as appropriate depending on the embodiment. Also, the node is not limited to a single device. A node may be realized by a plurality of devices using so-called cloud or distributed computing technology. The data store managed by each node may be built on the storage 14 or the RAM 12, and the location where the data store is built is not limited.

Various programs are stored in the storage 14 together with the operating system, and the CPU 11 reads and executes the programs via the bus and the RAM 12, thereby realizing the above-mentioned function as a node. The node on which each manager operates may have the same hardware configuration.

FIG. 3 is a diagram showing an outline of the functional configuration of the node according to the present embodiment. As described above, in the present embodiment, each node has one of the roles of session manager, transaction manager, data store manager, and view manager.

First, the functional configuration of the session management node will be described. In the present embodiment, each of the plurality of nodes having a role as a session manager reads and executes the session manager program by the CPU 11 via the bus and the RAM 12, so that the query reception unit 21, the query processing unit 22, and the snap are executed. It functions as a session management node including a shot identification information acquisition unit 23, a processing data acquisition unit 24, a data set generation unit 25, and a data set transmission unit 26.

The query reception unit 21 receives a query for the database system sent from the user terminal 9. In the database system according to the present embodiment, there are a plurality of session management nodes that execute the session manager, and any of these plurality of session management nodes can accept queries from the user terminal 9.

The query processing unit 22 processes the query received by the query receiving unit 21.

The snapshot identification information acquisition unit 23 acquires information that can identify the snapshot used for processing from the transaction manager. Here, the snapshot is a word indicating the contents of the database at a certain point in time in a time series in which the contents of the database change as the transactions are committed sequentially. In the present embodiment, the information acquired by the snapshot identification information acquisition unit 23 is a transaction ID (hereinafter, referred to as “snapshot identification transaction ID”). However, since the acquired information is for guaranteeing the consistency of the data used for the transaction processing, the information may be any information that can identify the snapshot, and is not limited to the transaction ID. For example, the information that can identify the snapshot may not be the transaction ID but the information that can specify a logical point in time in the time series in which a plurality of transactions are sequentially processed.

The processing data acquisition unit 24 acquires data used for query processing from at least one of a plurality of data store managers and a plurality of view managers. At this time, the processing data acquisition unit 24 specifies the information (snapshot identification transaction ID) acquired by the snapshot identification information acquisition unit 23 to the data store manager or the view manager, thereby determining a predetermined value. Take the data in the snapshot.

When the transaction related to the acquired data includes a change instruction for changing the contents of the database, the data set generation unit 25 does not make a change based on the change instruction to the database, and the tuple ID of the taple to be changed. And generate a change dataset that contains the changes. That is, in the database system according to the present embodiment, the fact that the data set for change is generated by the data set generation unit 25 of the session manager does not mean that the changed contents are reflected in the database. In the database system according to the present embodiment, the change data set generated by the data set generation unit 25 of the session manager is transmitted to the data store manager, and the data store manager assigns a transaction ID to the change data set. Then, the changes are reflected in the database.

In the present embodiment, the data unit treated as an individual record in the database is described as a tuple, but the data unit to which the present invention can be applied is called a tuple in a general database system. Not limited to. In the data store of the database system according to the present disclosure, the data is managed in the format of the data set for modification, not in the tabular format used in the relational database. Therefore, in the present invention, data units other than tuples in a relational database can be handled in a unified manner. The tuple ID is (unique) target identification information that can uniquely grasp the tuple (data unit) to be changed among a plurality of data stores managed by a plurality of data store managers. In the present embodiment, the data set generation unit 25 generates a unique tuple ID by including a different value (for example, a node ID) for each of a plurality of session management nodes in the tuple ID. However, the change data set only needs to include the change contents of the database based on the change instruction and the information that can uniquely grasp the tuple to be changed in the database system, and this information is used in the present implementation. It is not limited to the examples in the form.

FIG. 4 is a diagram showing the structure of the modification data set generated in the present embodiment. However, the specific configuration, format, or generation method of the modification data set is not limited to the examples in the present embodiment. The change data set in the present embodiment is information generated by reading data including taples to be changed based on the change instruction onto the RAM 12 and performing an operation based on the change instruction on the data. , DELETE dataset (DELETE instruction target tuple list) and ENCERT data set (ENCERT instruction target tuple list) are included.

In addition, a transaction ID for specifying a snapshot and a data set ID are set in the change data set. The data set ID is identification information that can uniquely identify the change data set, and is given when the change data set is generated.

The DELETE and INSERT datasets contain information that indicates the tuple that is the target of the change instruction. Specifically, the DELETE dataset contains the tuple ID of the tuple to be deleted (2 in the example shown in FIG. 4), and the ENCERT dataset contains the tuple ID of the tuple to be added (FIG. 4). In the example shown in, 13) and the content of the data to be added are included. In the present embodiment, the UPDATE instruction is treated as a combination of the INSERT instruction and the DELETE instruction, and the tapple ID of the taple including the data before the update by the UPDATE instruction is included in the DELETE data set, and the data after the update by the UPDATE instruction and the data The tuple ID of the tuple containing the data is included in the INSERT dataset. However, the data set in which the tuple ID including the data before the update by the UPDATE command and the tuple ID of the updated data and the tuple including the data are stored is not limited to the example disclosed in the present embodiment. .. For example, these tuple IDs and data related to the UPDATE instruction may be configured to be collectively included in the UPDATE dataset.

The data set transmission unit 26 transmits the data set for change so as to reach at least the data store manager that manages the data store including the data to be changed. Further, the data set transmission unit 26 sets the deletion target taple ID (taple ID described in the DELETE data set) and the dataset ID indicating at least the data unit to be deleted among the tuple IDs included in the data set as the transaction manager. Send to.

Next, the functional configuration of the transaction management node will be described. In the present embodiment, the node having a role as a transaction manager reads and executes the transaction manager program by the CPU 11 via the bus and the RAM 12, thereby causing the information acquisition unit 31, the conflict determination unit 32, and the change data unit information storage. It functions as a transaction management node including a unit 33, an identifier generation unit 34, and an identifier transmission unit 35.

The information acquisition unit 31 acquires the deletion target tuple ID (tuple ID described in the DELETE data set) and the data set ID transmitted by the data set transmission unit 26 of the session manager.

The conflict determination unit 32 includes a tuple ID to be deleted described in the DELETE data set acquired by the information acquisition unit 31, and information indicating the changed tuple accumulated by the change data unit information storage unit 33 (the present embodiment). Then, by comparing with the deleted tuple ID) and confirming whether or not a matching tuple ID exists, it is determined whether or not there is a conflict to be deleted. When the conflict determination unit 32 determines that there is a conflict to be deleted, the change based on the change data set is canceled.

When the conflict determination unit 32 determines that there is no conflict to be deleted, the change data unit information storage unit 33 uses the tuple ID acquired by the information acquisition unit 31 as the tuple changed in the database system. It is accumulated as the information to be shown (information that can grasp which tuple was changed at what time).

When the conflict determination unit 32 determines that there is no conflict to be deleted, the identifier generation unit 34 generates a transaction ID for identifying the transaction related to the change data set (for the change data set). Numbering). The transaction ID generated here is an identifier that can grasp the position in the logical time series related to the transaction processing. In this embodiment, ascending integers are used as the transaction ID.

The identifier transmission unit 35 sets the identifier set including the data set ID and the transaction ID corresponding to the data set ID to the data corresponding to the data set ID by at least the data set transmission unit 26 among the plurality of data store managers. Send the set to the data store manager to which it was sent. The identifier set may be sent to all data store managers.

Next, the functional configuration of the data store management node will be described. In the present embodiment, each of the plurality of nodes having a role as a data store manager reads and executes the data store manager program by the CPU 11 via the bus and the RAM 12, thereby performing the processing data transmission unit 41 and the data set. / It functions as a data store management node including an identifier receiving unit 42, a database management unit 43, a set data set generation unit 44, a data extraction unit 45, a view data generation unit 46, and a view data transmission unit 47.

When the processing data transmission unit 41 receives a data request for which information that can identify a snapshot (in this embodiment, a transaction ID for specifying a snapshot) is received from the session manager, up to the specified snapshot. Send the processing data generated based on the modification data set to the session manager.

The data set / identifier receiving unit 42 receives the modification data set transmitted by the session manager and the identifier set transmitted by the transaction manager.

The database management unit 43 manages a part or all of the database managed by the database management technique according to the present disclosure as a data store. Here, the database management unit 43 according to the present embodiment manages the database by setting the transaction ID and accumulating the received data set. More specifically, when the identifier set is received by the data set / identifier receiving unit 42, the database management unit 43 identifies the data set indicated by the data set ID included in the identifier set, and applies the data set to the data set. A transaction ID corresponding to the data set ID is set.

The aggregate data set generation unit 44 concatenates the data set at the time specified by the predetermined transaction ID and the changes contained in the older data set, and removes the data shown in the DELETE data set to remove the data indicated in the DELETE data set, thereby performing a predetermined transaction. The data set at the time specified by the ID and the older data set are integrated to generate a collective data set. When the set data set is generated, the database management unit 43 manages the set data set as one of the accumulated data sets by setting a transaction ID in the set data set. In the present embodiment, two transaction IDs, a transaction ID indicating a start point and a transaction ID indicating an end point, are set in the set data set to indicate the range of transactions included in the set data set. Here, the transaction ID indicating the start point is the ID of the oldest transaction among the original transactions concatenated in the aggregate data set, and the transaction ID indicating the end point is the ID of the original transaction concatenated in the aggregate data set. This is the ID of the newest transaction. Further, the database management unit 43 deletes the data set used for generating the set data set in accordance with the setting of the transaction ID in the set data set.

Among the data sets accumulated by the database management unit 43, the data extraction unit 45 sets the desired search conditions from the data set at the time specified by the desired transaction ID and the data set in which the older transaction ID is set. Extract matching data. Specifically, the data extraction unit 45 selects the data indicated in the deletion target tuple ID described in the DELETE data set from the data retrieved by searching the changed contents of the tuple included in the INSERT data set. By excluding, data matching the desired search conditions is extracted. Here, when the search target transaction ID is newer than the specific transaction ID indicating the range of the data set that is not reflected thereafter (in the present embodiment, the latest transaction ID), the data extraction unit 45 determines that the search target transaction ID is the specific. The extraction is performed after waiting for the transaction ID to be the same as or older than the transaction ID.

The view data generation unit 46 generates a view data set including data that matches the preset search conditions based on the data set accumulated by the database management unit 43. The structure of the view data set generated here is substantially the same as the structure of the change data set described with reference to FIG. 4, and the corresponding transaction ID is set in the generated view data set. Will be done.

The view data transmission unit 47 transmits to the view manager a view data set including data that matches the preset search conditions, which is generated based on the data set accumulated by the database management unit 43.

Next, the functional configuration of the view management node will be described. In the present embodiment, each of the plurality of nodes having a role as a view manager has the view data acquisition unit 51 and the view management unit 52 by reading and executing the view manager program by the CPU 11 via the bus and the RAM 12. View management including a view data generation unit 53, a view data transmission unit 54, a view transaction ID update unit 55, a view change unit 56, a view search unit 57, a view search result correction unit 58, and a specific transaction ID determination unit 59. Acts as a node.

The view data acquisition unit 51 acquires a view data set including data that matches the preset search conditions from the data store manager or another view manager.

The view management unit 52 presets a set of data at the time specified by the view transaction ID and older data among the data included in the view data set acquired by the view data acquisition unit 51. It is retained as a view corresponding to the search condition and the transaction ID for the view. Here, the view transaction ID is a transaction ID indicating a snapshot corresponding to the view. Further, the view management unit 52 holds the changed view as a view corresponding to the updated transaction ID for the view even when the view is changed by the view changing unit 56.

The view data generation unit 53 is data that matches search conditions preset for other views (in the present embodiment, search conditions preset for a view higher than the view including the view data transmission unit 54). Generate a second view dataset that contains. Here, the second view data set is generated for changing the view managed by the upper view.

Further, the view data generation unit 53 may generate a second view data set based on the view managed by the view manager, or the view data acquisition unit 51 may generate a second view data set. A second view dataset may be generated based on the set. When the second view data set is generated based on the view data set, the view data generation unit 53 sets the transaction ID newer than the view transaction ID among the acquired view data sets. Generate a second view dataset based on the set.

The view data transmission unit 54 manages the view related to the search condition used to generate the second view data set for the second view data set (in the present embodiment, the upper view is used as the upper view). Send to the view manager to manage).

The view transaction ID update unit 55 updates the view transaction ID.

The view change unit 56 changes the view managed by the view management unit 52 by using the view data set at the time specified by the updated view transaction ID and the older view data set.

The view search unit 57 searches for a view according to a designated search condition.

The view search result correction unit 58 corrects the search result by the view search unit 57 when the search target transaction ID indicating the snapshot of the search target is newer than the view transaction ID. The view search result correction unit 58 uses the view data set up to the search target transaction ID among the view data sets acquired by the view data acquisition unit 51 but not reflected in the view to correct the search result. However, if the view search result correction unit 58 is newer than the specific transaction ID indicating the range of the view data set that is not acquired thereafter, is the search target transaction ID the same as the specific transaction ID? Alternatively, the correction is performed after waiting for the transaction ID to become older.

The specific transaction ID determination unit 59 collects transaction IDs indicating the progress time of the view data set generation process by the view data set generation units 46 and 53 for each node from each node that generates the view data set. The transaction ID indicating the progress time in the node in which the progress of the view data set generation process is the most delayed is determined as the specific transaction ID. That is, the specific transaction ID determination unit 59 collects transaction IDs indicating the current processing progress time of each node from each node, manages this value for each node, compares the latest values for each node, and compares them. The minimum value (value indicating the oldest processing time point) determined as a result of is determined as a specific transaction ID.

<Processing flow>
Next, the details of the processing according to the present embodiment will be described. The specific contents and order of the processes described in the present embodiment are examples in carrying out the processes. The specific processing content, order, and the like may be appropriately selected depending on the embodiment.

5 to 10 are flowcharts showing a flow of database management processing in the present embodiment. The process shown in the flowchart of FIG. 5 includes a query sent from the user terminal 9 by the query reception unit 21 of any session management node belonging to the database system, and also includes an instruction to change the contents of the database. It is started when the transaction start command is received.

In steps S101 to S105, a transaction is started, and a snapshot identification transaction ID used for processing is acquired. When the transaction start command is received (step S101), the snapshot identification information acquisition unit 23 inquires the transaction manager of the snapshot identification transaction ID used for processing (step S102 and step S103). Then, the transaction manager transmits the transaction ID finally assigned at the time of reply to the session manager (step S104), and the snapshot identification information acquisition unit 23 of the session manager acquires this transaction ID (step S105). ). In the present embodiment, the transaction manager transmits the transaction ID last given (that is, the latest) at the time of reply, but the transaction ID transmitted at this time is the latest one. Not limited. After that, the process shown in this flowchart ends.

The process shown in the flowchart of FIG. 6 is started when the snapshot identification transaction ID is acquired in the process shown in FIG.

In step S106, the instruction included in the transaction is read out. The processing data acquisition unit 24 reads the instruction to be processed next included in the query received by the query receiving unit. After that, the process proceeds to step S107.

In step S107, it is determined whether or not to end the change data set generation / update process related to the transaction. Specifically, when the next instruction in the transaction is a commit instruction, the query processing unit 22 ends the change data set generation / update process related to the transaction. If the next instruction in the transaction is not a commit instruction, the process proceeds to step S108.

In steps S108 to S112, data necessary for processing the instruction read in step S106 is acquired. In steps S108 to S112, the processing data acquisition unit 24 requests data from a view manager suitable for data acquisition at a higher speed than the data store manager. The processing data acquisition unit 24 notifies the view manager of the search condition created based on the read instruction and the snapshot identification transaction ID acquired in step S105, and requests data (step S108). ). Then, the transmitted data request is received by the view manager (step S109).

The view manager who received the data request in step S109 acquires the data according to the search condition and the transaction ID for specifying the snapshot from the view managed by the view manager (step S110). The flow of the process in which the view manager that receives the data request acquires the data will be described later with reference to FIG.

The view manager that has received the data request transmits the processing data acquired in step S110 to the session manager that sends the data request (step S111). After that, the processing data acquisition unit 24 of the data request transmission source session manager acquires the processing data by receiving the transmitted data (step S112). After that, the process proceeds to step S113.

In step S113, it is determined whether or not it is necessary to acquire data from the data store manager. The session manager determines whether or not all the data necessary for the processing by the query processing unit 22 is prepared in the processing data acquisition processing from the view manager up to step S112. This is because there may be some data that is not covered by the view and the data needed for processing may not be available from the view manager.

For example, if the range of data covered by the view is part of the table for which data is to be acquired, the data contained in the table that is covered by the view will be acquired by querying the view manager. Will be done. On the other hand, among the tables to be acquired, the data that is not covered by the view needs to be acquired from the data store manager. Here, as a specific method of determination in step S113, information such as a list indicating the range covered by the view in the table (for example, the tuple ID, the content of the tuple such as the primary key of the table, etc. is used by the view. By setting (it can indicate the presence or absence of a cover) and referring to this list, a method of determining whether or not all the necessary data are available may be adopted only by inquiring to the view manager.

Further, when the range of data covered by the view is set for each table, a simpler determination method can be adopted. For example, information that can determine whether or not a table is covered by a view may be set for each table, and for a table that is not covered by a view, a method of inquiring to the data store manager may be adopted.

As a result of the determination, if it is determined that all the data necessary for the processing is complete (data acquisition from the data store manager is unnecessary), the processing proceeds to step S119. On the other hand, if it is determined as a result of the determination that the data required for the process is insufficient (data acquisition from the data store manager is necessary), the process proceeds to step S114.

In steps S114 to S118, data necessary for processing the instruction read in step S106 is acquired. The processing data acquisition unit 24 notifies the data store manager of the search condition and the transaction ID for specifying the snapshot, and requests the data (step S114).

Upon receiving the data request (step S115), the processing data transmission unit 41 of the data store manager receives the change data set at the time specified by the received snapshot identification transaction ID and the older change data set. The search is performed based on the search conditions (step S116), and the processing data obtained as a result of the search is transmitted to the session manager (step S117). Here, the details of the process flow for the data store manager receiving the data request to acquire the data will be described later with reference to FIG. After that, the processing data acquisition unit 24 acquires the desired processing data by receiving the data transmitted from the data store manager (step S118). After that, the process proceeds to step S119.

In step S119, instruction processing and change data set generation / update processing are executed. The details of the processing executed in this step will be described in detail with reference to FIG. 7. After that, the process returns to step S106.

FIG. 7 is a diagram showing a flow of instruction processing and data set generation / update processing for change executed by the session manager in the present embodiment. This flowchart shows in detail the contents of the process of step S119 shown in FIG.

In step S121, duplicate data is deleted from the acquired processing data. As described above, since the view is generated using the data obtained from the data store manager or the like based on the search conditions, the data acquired from the view manager in step S112 and the data from the data store manager in step S118 The acquired data may have duplicate data related to the same taple. Therefore, when the data acquired in steps S112 and S118 contains duplicate data related to the same tuple, the processing data acquisition unit 24 deletes one of the duplicated data. Eliminate data duplication. After that, the process proceeds to step S122.

In the present embodiment, a method of eliminating duplication after acquiring data is adopted, but instead of such a method, in step S108 and step S114 so that duplication does not occur at the time of data request. A method of changing the content of the data request to be transmitted may be adopted.

In steps S122 and S123, adjustments are made to the data acquired for instruction processing based on the change dataset generated in the transaction. This is a process for correctly reflecting the execution result of the instruction already executed in the same transaction for the instruction execution in step S124. When the change data set generation / change process has already been executed once or more for the transaction and the change data set related to the transaction has been generated, the query processing unit 22 displays the contents of the change data set. It is used to adjust the data acquired in the processes up to step S118.

More specifically, the query processing unit 22 searches the INSERT set in the change data set with the search conditions (search conditions used in steps S108 and S114), and extracts the tuples extracted as a result of the search. It is added to the acquired data obtained up to step S118 (step S122). Further, the query processing unit 22 excludes the tuple shown in the DELETE set in the change data set from the acquired data (step S123). After that, the process proceeds to step S124.

In step S124, the instruction is executed. The query processing unit 22 processes the instruction read in step S106 by using the acquired data acquired in the processes from step S108 to step S118 and adjusted in steps S122 and S123. That is, the query processing unit 22 processes the instruction based on the data acquired from the data store manager and / or the view manager, and the change data set generated in the transaction. After that, the process proceeds to step S125.

From step S125 to step S127, the change data set is generated or updated. The data set generation unit 25 generates or updates a change data set (see FIG. 4) including the tuple ID to be changed and the change contents without reflecting the change obtained as a result of the instruction execution in step S124 in the database. To do.

Here, the new tuples to be deleted generated as a result of instruction execution include those that target the tuples newly added in the processing so far of the transaction and those that do not. Therefore, the data set generation unit 25 uses the tuples existing in the INSERT set in the change data set related to the transaction among the new tuples to be deleted generated as a result of instruction execution (new in the processing so far of the transaction). The tuples added to) are deleted from the INSERT set (step S125). In addition, the data set generation unit 25 changes the new deletion target taples generated as a result of instruction execution for the new deletion target taples that are not in the INSERT set in the change data set related to the transaction. Add to the INSERT set in the data set for use (step S126). Then, the data set generation unit 25 adds the newly added tuple (tuple ID and data content of the tuple) generated as a result of instruction execution to the INSERT set in the change data set related to the transaction (step). S127).

Here, when the change instruction is an UPDATE instruction or an INSERT instruction, the tapple ID of the INSERT data set is managed by a newly assigned database system as a whole (more specifically, by a plurality of data store managers). A unique tapple ID is written (between multiple data stores). When a change data set related to the transaction is newly generated, the snapshot identification transaction ID acquired in step S105 is set in the change data set. After that, the process shown in this flowchart ends.

In the present embodiment, when the new deletion target taple generated as a result of instruction execution is a taple existing in the INSERT set in the change data set related to the transaction, the new deletion target taple is deleted each time the instruction is executed. Is deleted from the INSERT set in the change data set (see step S125). However, instead of the above-mentioned method, another method may be adopted. For example, the delete target taples generated by the execution of instructions in a transaction are stored in the DELETE set while the instructions are sequentially executed, and before the INSERT set is transmitted to the data store manager (step S206 described later). , The INSERT set and the INSERT set may be compared to offset the overlapping taples between the INSERT set and the INSERT set.

The process shown in the flowchart of FIG. 8 is executed when the commit instruction related to the change data set generated by the session manager is read.

In step S201 and step S202, the ENCERT data set (change content) included in the change data set and the data set ID set in the change data set are transmitted to the data store manager. Here, the data set transmission unit 26 of each session manager determines at least the data store manager that manages the data store to which data is added by the ENCERT instruction among the plurality of data store managers (step S201), and determines the data set. The ID and INSERT data sets are transmitted to the determined data store manager (step S202). Here, the INSERT dataset may be transmitted directly to the target data store manager or indirectly via a plurality of nodes. Then, the data set / identifier receiving unit 42 of the data store manager acquires the data set ID and the ENCERT data set (change contents) transmitted by the session manager. After that, the process proceeds to step S203.

In step S203, it is determined whether or not the change data set includes the DELETE data set. When the change data set does not include the DELETE data set and only the INSERT data set is included in the change data set, the instruction does not change the existing taple, and the transaction manager does not need to determine the conflict. Therefore, if it is determined that the change data set does not include the DELETE data set, the process proceeds to step S204.

In step S204, the dataset ID is transmitted. The data set transmission unit 26 of the session manager transmits the data set ID to the transaction manager. The information acquisition unit 31 of the transaction manager acquires the data set ID transmitted by the session manager. After that, the process shown in this flowchart ends.

On the other hand, if it is determined in step S203 that the change data set includes the DELETE data set, the process proceeds to step S205.

In step S205 and step S206, the data set ID and the DELETE data set (change contents) set in the change data set are transmitted to the data store manager. Here, the data set transmission unit 26 of each session manager determines, among the plurality of data store managers, at least the data store manager that manages the data store including the data to be changed by the DELETE instruction as the transmission destination (step S205). ), The data set ID and the DELETE data set are transmitted to the data store manager determined as the destination (step S206). Here, the DELETE data set may be transmitted directly to the target data store manager, or may be indirectly transmitted via a plurality of nodes. Then, the data set / identifier receiving unit 42 of the data store manager acquires the data set ID and the DELETE data set (change contents) transmitted by the session manager. After that, the process proceeds to step S207.

In step S207, the data set ID, the snapshot identification transaction ID, and the DELETE data set are transmitted to the transaction manager. The data set transmission unit 26 of the session manager transmits the data set ID and the DELETE data set (delete target taple ID) transmitted in step S206 to the transaction manager together with the transaction ID for specifying the snapshot. The transaction manager information acquisition unit 31 acquires the data set ID, the snapshot identification transaction ID, and the DELETE data set (delete target taple ID) transmitted by the session manager. After that, the process shown in this flowchart ends.

The processing shown in the flowcharts of FIGS. 9 and 10 is executed when the data set ID transmitted by the session manager is received by the transaction manager.

In step S301, the dataset ID is received. Here, when the transmitted data set ID is the one transmitted in step S204, the information acquisition unit 31 of the transaction manager receives the data set ID transmitted by the session manager. On the other hand, when the transmitted data set ID is the one transmitted in step S207, the information acquisition unit 31 of the transaction manager acquires the snapshot identification transaction ID and the DELETE data set in addition to the data set ID. After that, the process proceeds to step S302.

In step S302, it is determined whether or not the received data set ID is received together with the DELETE data set. When the received data set ID is combined with the DELETE data set, the process proceeds to the conflict determination in step S304. On the other hand, when the received data set ID is not combined with the DELETE data set, the change data set indicated by the data set ID does not change the existing tuple, so that the transaction manager does not need to determine the conflict. .. Therefore, if the received data set ID is not combined with the DELETE data set, the process proceeds to step S303.

In step S303, the transaction ID is numbered. When there is no conflict to be deleted, the identifier generation unit 34 assigns a transaction ID for identifying the transaction related to the change data set indicated by the data set ID. As described above, the transaction ID is an identifier that can grasp the position in the logical time series related to the transaction processing, and in the present embodiment, the numerical values of integers in ascending order are in ascending order in the order in which it is confirmed that there is no conflict. It will be numbered. After that, the process proceeds to step S314.

In step S304, a conflict determination is performed. The conflict determination unit 32 compares the deletion target tuple ID described in the DELETE data set acquired in step S301 with the conflict determination tuple ID accumulated when step S313, which will be described later, is executed before. By confirming whether or not a matching tuple ID exists, it is determined whether or not there is a conflict to be deleted.

Further, the tuple ID for conflict determination is a tuple ID accumulated in step S313 described later when the database management process according to this flowchart is previously executed. As described above, the snapshot identification transaction ID acquired in step S105 is set in the change data set, and the conflict determination unit 32 has the conflict accumulated after the transaction specified by the transaction ID. The determination tuple ID and the deletion target tuple ID are compared.

If it is determined as a result of the conflict determination that the tuple ID to be deleted and the tuple ID for conflict determination conflict (there is a matching tuple ID), the process proceeds to step S305. On the other hand, if it is determined as a result of the conflict determination that the tuple ID to be deleted and the tuple ID for conflict determination do not conflict (there is no matching tuple ID), the process proceeds to step S312.

In steps S305 to S311 the transaction related to the change data set is interrupted, and the change based on the change data set is stopped. If it is determined in the conflict determination in step S304 that there is a conflict to be deleted, the transaction manager, the session manager, and the data store manager stop the modification of the database based on the modification data set including the corresponding tuple to be deleted.

Specifically, the transaction manager sends an abort notification to the source session manager of the dataset ID (step S305). Upon receiving the abort notification (step S306), the session manager suspends (above) the transaction related to the change dataset (step S307), and at least to the data store management node to which the change dataset was sent. Instruct the destruction of the modification data set (step S308). The data store manager that has received the instruction to destroy the change data set (step S309) discards the received change data set (step S310). In addition, the session manager notifies the user of the interruption of the transaction (step S311).

In the present embodiment, the instruction to destroy the data set to the data store manager is transmitted from the session manager, but the transaction manager may directly send the abort notification to the data store manager. At this time, the transaction manager may acquire the destination of the abort notification (the data store manager that received the data set to be aborted) from the session manager, or broadcast the abort notification to all the data store managers. It may be that. After that, the process shown in this flowchart ends.

In step S312, the transaction ID is numbered. When it is determined in step S304 that there is no conflict to be deleted, the identifier generation unit 34 assigns a transaction ID for identifying the transaction related to the change data set indicated by the data set ID. The specific mode of the transaction ID adopted is as described in step S303. After that, the process proceeds to step S313.

In step S313, the tuple ID for conflict determination is accumulated. The change data unit information storage unit 33 stores the deletion target tuple ID described in the DELETE data set acquired in step S301 as a conflict determination tuple ID in association with the transaction ID numbered in step S312. .. The tuple ID for conflict determination accumulated here will be referred to in step S304 when the database management process according to this flowchart is executed from the next time onward. After that, the process proceeds to step S314.

In step S314 and step S315, the data set ID and the transaction ID are recorded, and the data set ID and the transaction ID are transmitted. The transaction manager associates the numbered transaction ID with the data set ID and records them in the storage of the transaction management node (step S314). Then, the transaction manager identifier transmission unit 35 transmits the identifier set, which is a set of the data set ID and the transaction ID associated with each other, to all the data store managers (step S315).

That is, in the present embodiment, the transaction manager notifies the numbered transaction ID as the latest transaction ID even to the data store manager which does not have the corresponding data set. Upon receiving the notification of the latest transaction ID, the data store manager uses the latest transaction ID for comparison with the search target transaction ID in the data search process described later with reference to FIG.

However, at the time of the process of step S315, if the numbered transaction ID is at least transmitted to the data store manager that manages the data store to be changed of the data set for change indicated by the data set ID. Good. If the transaction ID is not notified to the data store manager that does not have the corresponding dataset at the time of processing in step S315, for example, the transaction manager does not notify each time the transaction ID is numbered. By notifying regularly (for example, every second), the amount of communication can be reduced.

In step S315, when adopting a configuration in which the identifier set is transmitted only to the data store manager that manages the data store to be changed, the transaction manager selects the data store manager that has received the corresponding ENCERT data set and the DELETE data set. , You can know by receiving the notification from the session manager. However, the means for determining the data store manager to which the identifier set is transmitted is not limited, and various means may be adopted.

Further, the identifier transmission unit 35 may transmit a plurality of identifier sets at once. By transmitting a plurality of identifier sets at once, the communication load in the database system can be reduced. After that, the process proceeds to step S316.

From step S316 to step S318, the commit notification is performed. The transaction manager sends a commit notification to the source session manager of the change dataset (step S316). Upon receiving the commit notification (step S317), the session manager notifies the user terminal 9 that is the source of the query that the commit has been completed (step S318). In the database management technique according to the present disclosure, the commit notification to the user may be performed without waiting for the transaction ID to be assigned to the data set in the data store (step S321 described later), or may be performed after waiting. ..

In step S319, the dataset ID and transaction ID are received. The data set / identifier receiving unit 42 of the data store manager receives an identifier set which is a set of a data set ID and a transaction ID. After that, the process proceeds to step S320.

In step S320 and step S321, the transaction ID is attached to the change data set. The database management unit 43 of the data store manager sets the data set ID set in the change data set (INSERT data set and / or DELETE data set) received in advance in the process described with reference to FIG. 8, and the step. By comparing with the data set ID received in S319, the data set for change corresponding to the received data set ID is specified (step S320). When the data store manager has received the change data set corresponding to the data set ID, the database management unit 43 puts it in the ENCERT data set and / or the DELETE data set indicated by the data set ID included in the identifier set. , Set the transaction ID corresponding to the data set ID (S321). After that, the process proceeds to step S322.

In step S322, the specific transaction ID is updated. The database management unit 43 of the data store manager updates the specific transaction ID managed by the data store manager with the transaction ID received in step S319. The specific transaction ID updated here is a transaction ID indicating the range of the data set that is not reflected in the database by the data store manager thereafter, and is used to determine whether or not to wait for the search process in the data search process described later. Used. After that, the process shown in this flowchart ends.

In the database system according to the present embodiment, the contents of the database are not changed by rewriting the table or the like having a predetermined format, but the data set for change including the changed contents is associated with the transaction ID and stored in the data store. By accumulating, the contents of the database are changed. Therefore, according to the database system according to the present embodiment, it is possible to reduce the processing load associated with changing (updating and deleting) the contents of the database. Further, in the database system according to the present embodiment, since the basic part of the database does not depend on the organized table or the like, a mechanism (checkpoint or the like) for dealing with a problem such as a broken table can be omitted.

FIG. 11 is a flowchart showing the flow of data search processing in the data store manager according to the present embodiment. FIG. 11 describes in detail the data search process executed in steps S116, S710, and the like.

In steps S401 and S402, it is possible that the dataset required for the search has not yet been reflected in the database by the data store manager, in other words, the dataset that has not yet been assigned a transaction ID by the data store manager. It is determined that the data set required for the search may be included. As a result of the determination, if there is a possibility that the data set required for the search has not been reflected yet, the search process is waited. Specifically, in order to determine the necessity of waiting, the data extraction unit 45 has a search target transaction ID indicating a snapshot of the search target and a specific transaction ID indicating the current processing progress time in the entire database system. , Are compared (step S401). Here, the search target transaction ID is a snapshot identification transaction ID when the data search process is the process related to step S116, and the view transaction ID when the data search process is the process related to step S710. Is.

Further, in the present embodiment, the specific transaction ID to be compared with the search target transaction ID is the specific transaction ID updated in step S322 of FIG.

The target to be compared with the search target transaction ID in order to determine whether or not the data set necessary for correcting the search result may not be reflected is not limited to the example disclosed in this embodiment. The specific transaction ID to be compared with the transaction ID to be searched may be a transaction ID indicating a range of data sets that is not reflected thereafter by the data store manager that performs the search. That is, in the present embodiment, the specific transaction ID in the data store manager is a transaction ID (that is, a transaction ID smaller than that value) in the data set (all already received or received in the future) by the data store manager performing the search. It is a transaction ID that is guaranteed not to be assigned an older transaction ID). Further, the method by which the data store manager making the judgment acquires the information for the judgment (for example, the latest transaction ID) is not limited. In the present embodiment, the latest transaction ID is notified from the transaction manager (step S315), so that the data store manager acquires the information for judgment, but the data store manager searches for the information for judgment. It may be obtained by contacting the transaction manager or another data store manager during processing.

As a result of the determination in step S401, when it is determined that the transaction ID to be searched is a (new) transaction ID after the specific transaction ID, the data set required for the search is still reflected in the database by the data store manager. May not be. Therefore, the data extraction unit 45 waits until the specific transaction ID becomes the same transaction ID as the search target transaction ID or a new transaction ID (in other words, until there is no possibility that the data set required for the search is acquired). (Step S402). On the other hand, if it is determined that the transaction ID to be searched is the same as or older than the specific transaction ID, the process proceeds to step S403.

In steps S403 to S405, data is extracted according to the search conditions. First, the data extraction unit 45 desires from the data set accumulated by the database management unit 43 from the data set in which the transaction ID equal to or older than the search target transaction ID indicating the snapshot of the search target is set. Data that matches the search condition (for example, the search condition notified from another node) (specifically, the changed content of the taple included in the INSERT data set) is extracted (step S403).

Next, the data extraction unit 45 sets the DELETE, which is the tuple ID of the tuple retrieved from the INSERT dataset in step S403, and has the same or older transaction ID as the search target transaction ID indicating the snapshot to be searched. Search the dataset (step S404). Then, the data extraction unit 45 excludes the data related to the tuple ID found in the DELETE data set in step S404 from the search result in step S403 (step S405). By doing so, the data extraction unit 45 sets the data that matches the desired search conditions and the desired snapshot from the change data set (including the ENCERT data set and the DELETE data set) accumulated in the data store manager. Is extracted. After that, the process shown in this flowchart ends.

FIG. 12 is a flowchart showing the flow of data search processing in the view manager according to the present embodiment. FIG. 12 describes in detail the data search process executed in step S110, step S703, and the like.

In steps S501 and S502, it is determined that the view data set required for correction of the search result may not have been received by the view manager, and the required data set may not have been received yet. The search process is waiting. Specifically, the view search result correction unit 58 determines a search target transaction ID indicating a snapshot of the search target and the progress of the current view data set generation process in the entire database system in order to determine the necessity of waiting. Compare with the specific transaction ID indicating the time point (step S501).

In the present embodiment, the specific transaction ID indicating the progress time of the current view data set generation process in the entire database system is determined as follows. That is, the specific transaction ID determination unit 59 performs the view data set generation process (see FIGS. 15 and 16) for each node from each node (including the data store manager and the view manager) that generates the view data set. A transaction ID indicating a progress time is collected, and a transaction ID indicating a progress time in the node in which the progress of processing is the latest is determined as a specific transaction ID. Therefore, in the present embodiment, each node (including the data store manager and the view manager) that generates the view data set has a transaction ID in the system indicating the progress time of the view data set generation process of the own node. Notify the relevant view manager (the notification process will be described later with reference to FIGS. 15 and 16).

In addition, other methods may be adopted for determining the possibility that the data set necessary for correcting the search result has not yet been received. The specific transaction ID to be compared with the search target transaction ID may be a transaction ID indicating the range of the view data set that is not subsequently acquired for the view to be searched. That is, in the present embodiment, the specific transaction ID in the view is a view in which the view manager performing the search is given a transaction ID smaller than the value (that is, a transaction ID older than that) for the view to be searched thereafter. It is a transaction ID that is guaranteed not to acquire the data set for use. Further, the method in which the view manager making the judgment collects the information for the judgment (in the present embodiment, the transaction ID indicating the progress time of the view data set generation process for each node) is not limited. The view manager may collect information for judgment by contacting the data store manager or another view manager during the search process.

As a result of the determination in step S501, when it is determined that the transaction ID to be searched is a (new) transaction ID after the specific transaction ID, the data set necessary for correcting the search result is still received by the view manager. May not be. Therefore, the view search result correction unit 58 may acquire the data set necessary for correcting the search result until the specific transaction ID becomes the same transaction ID as the search target transaction ID or a new transaction ID (in other words, the search result correction unit 58). Wait (until it disappears) (step S502). On the other hand, if it is determined that the transaction ID to be searched is the same as or older than the specific transaction ID, the process proceeds to step S503.

In the present embodiment, by comparing the search target transaction ID with the specific transaction ID, it is determined whether or not there is a possibility that the data set necessary for correcting the search result has not yet been received. , This determination may be made using other methods.

In step S503, the search target transaction ID indicating the search target snapshot is compared with the view transaction ID. Here, when it is determined that the transaction ID to be searched is a transaction ID older than the transaction ID for view, it is difficult to search the snapshot to be searched in the view held in the view manager. Therefore, the view manager notifies the sender of the search request of the search failure (step S504). On the other hand, if it is determined that the transaction ID to be searched is the same as or newer the transaction ID for the view, the process proceeds to step S505.

In step S505, the view is searched according to the designated search condition. The view search unit 57 searches for a view by a method according to a data format (for example, a table format, a graph format, etc.) in which the view is held, using the designated search conditions. As described above, the data format of the view adopted when implementing the present disclosure is not limited, and the search method thereof is also not limited. As the view data format, those related to conventional database technology such as table format and graph format can be adopted, and the same search method as before can be adopted. Therefore, details on the view search method can be adopted. The explanation will be omitted. After that, the process proceeds to step S506.

In steps S506 to S508, the search result in step S505 is corrected. The view search result correction unit 58 is a designated search condition included in the view data set up to the search target transaction ID among the view data sets acquired by the view data acquisition unit 51 but not reflected in the view. (Specifically, the change content of the taple included in the INSERT data set) that matches the above is searched for (step S506). Then, the view search result correction unit 58 is the tuple ID of the tuples searched in step S505 and step S506, and among the unreflected view data sets, the DELETE data after the transaction ID of the view and before the transaction ID to be searched. Search for a set (step S507).

In step S506, duplicate data is deleted from the data acquired by the search. Since the view dataset is notified from a plurality of nodes, the data included in the view dataset may have duplicate data related to the same tuple. Therefore, when the data acquired from the search result INSERT dataset contains duplicate data related to the same taple, the view search result correction unit 58 deletes one of the duplicated data. , Eliminate data duplication.

In the present embodiment, a method of eliminating duplication after searching for data is adopted, but instead of such a method, a method of adjusting search conditions so that duplication does not occur at the time of data search. May be adopted.

After that, the view search result correction unit 58 adds the data searched in step S506 to the data searched in step S505, and from there to the tuple ID to be deleted searched from the DELETE data set in step S507. Such data is excluded (step S508). The view search unit 57 uses the data obtained in step S508 as a search result. After that, the process shown in this flowchart ends.

By the process described with reference to the flowcharts of FIGS. 5 to 12, the load associated with the change of the database can be reduced as described above. In addition, the search load can be distributed by preparing a plurality of data store managers. However, in the process described above, as the ENCERT data set and the DELETE data set are accumulated in the data store manager, in order to retain the processing amount and the data set of the data search process in the data store manager shown in FIG. More storage space is used. Therefore, in the database system according to the present embodiment, it is decided to perform the truncated process and use the storage efficiently. Here, the truncated process is performed by a method of transforming the data set (INSERT data set and DELETE data set).

FIG. 13 is a flowchart showing the flow of the truncated process in the data store manager according to the present embodiment. The process shown in the flowchart of FIG. 13 is, for example, periodically executed in the background.

In step S601, a predetermined transaction ID (Xi) as a reference for processing is determined. The aggregate data set generation unit 44 determines a predetermined transaction ID (Xi) as a reference for processing based on the necessity of a snapshot before a predetermined time point in the query processing or view change processing that may occur thereafter. .. The predetermined transaction ID (Xi) that is the basis of processing is the oldest ID currently used as the transaction ID for snapshot identification or the transaction ID for view, and the transaction manager may notify it as the transaction ID for snapshot identification in the future. It is preferable that the transaction ID is older than any of the oldest ID having a transaction ID and the oldest ID that may be used as a transaction ID for viewing in the future.

Various methods may be adopted as a specific method for determining a predetermined transaction ID (Xi). For example, a method of aggregating the transaction IDs of the referenced snapshots and updating them according to the oldest one may be adopted. Further, for example, a transaction ID older than a predetermined period in the transaction time series may be used, which is older than the view transaction ID described later. After that, the process proceeds to step S602.

In steps S602 and S603, the changes in the tapple contained in the data set at the time specified by the predetermined transaction ID and the older data set are concatenated, and the data indicated in the taple ID to be deleted is removed. , A collective dataset is generated that integrates the dataset at the time specified by the given transaction ID (Xi) and the older dataset. Specifically, the aggregate data set generation unit 44 identifies the INSERT data set and the older INSERT data set at the time specified by the predetermined transaction ID (Xi) among the data sets stored in the data store manager. And concatenate them to generate a set INSERT data set (step S602).

Then, the set data set generation unit 44 selects the DELETE data set at the time specified by the predetermined transaction ID (Xi) and the taple specified in the older DELETE data set from the set INSERT data set generated by the concatenation. Exclude (step S603). After that, the process proceeds to step S604.

In step S604 and step S605, the generated aggregate INSERT dataset is started to be managed as part of the data store. The database management unit 43 sets two transaction IDs (X0 and Xi), a transaction ID (X0) indicating a start point and a transaction ID (Xi) indicating an end point, in the newly generated set INSERT data set. (Step S604). In this way, the newly generated aggregate data set is managed as one of the accumulated data sets. Then, the database management unit 43 determines the data set used to generate the aggregate data set, that is, the ENCERT data set and the DELETE data set at the time specified by the predetermined transaction ID (Xi), and the older INSERT data set. And the DELETE data set is deleted (except for the newly generated set INSERT data set) (step S605). After that, the process shown in this flowchart ends.

Further, in the database system according to the present embodiment, the view is managed by the view manager in order to reduce the search load by the data store manager. Hereinafter, the view creation and modification processing in the present embodiment will be described with reference to FIGS. 14 to 17.

FIG. 14 is a flowchart showing the flow of the view creation process according to the present embodiment. The process shown in the flowchart of FIG. 14 is started when the view manager is instructed to generate a view and search conditions for generating the view. This instruction may be given by an administrator, a user, or the like, or may be given by another node such as a view manager or a session manager that manages the upper view. As described above, in the present embodiment, the plurality of views have a hierarchical relationship, and the upper view can be constructed by referring to the data covered by the lower view. Therefore, the view manager that manages the upper view (hereinafter referred to as "upper view manager") instructs the view manager that manages the lower view (hereinafter referred to as "lower view manager") to generate a view. , Search condition instructions, data request, etc. can be performed.

In steps S701 to S706, data (view data set) necessary for creating a view is acquired from the lower view manager. The view data acquisition unit 51 of the upper view manager notifies the lower view manager of the preset search conditions and the view transaction ID (transaction ID indicating the snapshot corresponding to the view), and requests the data (step). S701). Then, the transmitted data request is received by the lower view manager (step S702).

The view search unit 57 of the lower view manager that received the data request in step S702 searches the view according to the designated search condition, and acquires the data according to the search condition and the transaction ID for the view (step S703). Here, the flow of the process in which the lower view manager that receives the data request acquires the data is as described with reference to FIG. Then, the view data generation unit 53 of the lower view manager generates a view data set including data (tuples) matching the search conditions preset in the upper view as an INSERT set. Further, the lower view manager saves the search condition received in step S702 in association with the view managed by the upper view manager of the source in association with the identifiable information (step S704).

The view data transmission unit 54 of the lower view manager that has received the data request transmits the view data set generated in step S703 to the upper view manager that is the source of the data request (step S705). After that, the view data acquisition unit 51 of the upper view manager, which is the transmission source of the data request, acquires the view data set by receiving the transmitted data (step S706). After that, the process proceeds to step S707.

In step S707, it is determined whether or not it is necessary to acquire data from the data store manager. The view manager determines whether or not all the data necessary for creating the view are available in the process of acquiring the view data set from the lower view manager up to step S706. This is because there may be some data that is not covered by the lower view and the data required for processing may not be available from the lower view manager.

For example, when the range of data covered by the lower view is a part of the table to be acquired, the data included in the table that is covered by the lower view is sent to the lower view manager. Obtained by inquiry. On the other hand, among the tables to be acquired, the data that is not covered by the lower view needs to be acquired from the data store manager. Since the specific method of determination in step S707 is substantially the same as the method described in step S113, the description thereof will be omitted.

As a result of the determination, if it is determined that all the data necessary for creating the view are available (data acquisition from the data store manager is unnecessary), the process proceeds to step S714. On the other hand, if it is determined as a result of the determination that the data required for the process is insufficient (data acquisition from the data store manager is necessary), the process proceeds to step S708.

In steps S708 to S713, data (view dataset) necessary for creating a view is acquired from the data store manager. The view data acquisition unit 51 of the view manager notifies the data store manager of the preset search conditions and the view transaction ID, and requests the data (step S708).

Upon receiving the data request (step S709), the data extraction unit 45 of the data store manager extracts data that matches the preset search conditions based on the data set accumulated by the database management unit 43. The view data generation unit 46 generates a view data set including the extracted data (tuple) as an INSERT set (step S710). Here, the details of the process flow for the data store manager receiving the data request to acquire the data are as described with reference to FIG. 11 (in this case, the view transaction ID is the “search” in the description of FIG. Used as "target transaction ID"). Then, the data store manager saves the search condition received in step S709 in association with the view managed by the source view manager with the identifiable information (step S711).

The view data transmission unit 47 transmits the view data set generated in step S710 to the view manager (step S712). After that, the view data acquisition unit 51 acquires desired data by receiving the data transmitted from the data store manager (step S713). After that, the process proceeds to step S714.

In step S714 and step S715, view management is started. The view management unit 52 generates the data included in the view data set acquired by the view data acquisition unit 51 as a view that is a data set in a predetermined format (for example, table format, graph format, etc.) (step). S714). When the view is generated, duplicate data is deleted from the data included in the view data set. As described above, since the view is generated by using the data obtained from the data store manager or the like based on the search conditions, the data acquired from the lower view manager in step S706 and the data store manager in step S713. Data obtained from can be duplicated for the same taple. Therefore, when the data acquired in step S706 and step S713 include duplicate data related to the same tuple, the view management unit 52 deletes one of the duplicated data to obtain the data. Eliminate duplication.

In the present embodiment, a method of eliminating duplication after acquiring data is adopted, but instead of such a method, in step S701 and step S708 so that duplication does not occur at the time of data request. A method of changing the content of the data request to be transmitted may be adopted.

When the view is generated, the view management unit 52 holds the generated view as a view corresponding to the preset search conditions and the transaction ID for the view (step S715). After that, the process shown in this flowchart ends.

15 to 17 are flowcharts showing a flow of view change processing according to the present embodiment. The processes shown in FIGS. 15 and 16 are executed when the data store manager starts managing a new data set (in other words, a transaction ID is assigned to the data set). The assignment of the transaction ID to the data set is as described in step S321 of FIG. However, the processes shown in FIGS. 15 and 16 may be batch-processed at a timing independent of the assignment of the transaction ID, for example, periodically.

In step S801 and step S802, the data set is retrieved in the data store manager. The search condition used here is a search condition set in the view managed by the view manager, and is a search condition saved in step S711 or the like in FIG. The view data generation unit 46 of the data store manager searches the INSERT dataset with a new transaction ID using the preset search conditions, and extracts the changed contents that match the search conditions (step S801). .. Further, the view data generation unit 46 searches for the tuple indicated by the tuple ID included in the DELETE dataset to which the transaction ID is newly added by the search condition, and the tuple ID of the tuple having the content matching the search condition. (Step S802). After that, the process proceeds to step S803.

In the present embodiment, when the data store manager transmits the DELETE data set to the view manager, the data store manager transmits only the deleted tapple ID corresponding to the set search condition (step S805). And step S806). Then, in the present embodiment, as a method of searching for the deleted tuple ID corresponding to the set search condition, the past INSERT data set is checked with the tuple ID in the DELETE data set of the data store manager, and a hit is obtained. It is determined whether or not the tuple is matched with the search condition of the view (see step S802). However, as a method of searching for the deleted tuple ID corresponding to the set search condition, another method such as holding a list of tuple IDs sent to the view and collating with this is adopted. You may. Also, if the data store manager sends a DELETE dataset to the view manager to update the view, it may send all the DELETE datasets.

In step S803 and step S804, the presence / absence of the search result is determined, and if the search result is not obtained, the transaction ID is transmitted. As a result of the search in step S801 and step S802, when a taple matching the search condition is not found (NO in step S803), the data store manager determines the transaction ID attached to the data set to be searched. , Is transmitted to the view manager as a transaction ID indicating the progress time of the view data set generation process of the own node (step S804).

Here, the view manager to which the transaction ID is sent is a view manager that holds the view corresponding to the search condition used for the search, and the view associated with the search condition saved in step S711 is displayed. It is identified by reference to identifiable information. The view manager that has received the transmitted transaction ID manages the transaction ID as a transaction ID indicating the progress time of the view data set generation process of the source node. That is, the transaction ID received here is referred to in step S501 to determine the specific transaction ID.

On the other hand, if a tuple matching the search condition is found as a result of the search in steps S801 and S802 (YES in step S803), the process proceeds to step S805.

From step S805 to step S807, the view dataset is generated in the data store manager. The view data generation unit 46 includes the changes extracted in step S801 in the INSERT data set, and generates a view data set including the taple ID specified in step S802 in the DELETE data set (step S805). Then, the view data transmission unit 47 associates the generated view data set with the transaction ID and transmits the generated view data set to the view manager (step S806). The view manager to be sent here is a view manager that holds the view corresponding to the search condition used for the search, and the view identifiable information associated with the view when the search condition is saved in step S711. It is identified by referring to. The view data acquisition unit 51 of the view manager receives the transmitted view data set (step S807). The view manager that has received the transmitted view data set manages the transaction ID received together with the view data set as a transaction ID indicating the progress time of the view data set generation process of the source node, and steps S501. Refer to in order to determine a specific transaction ID. After that, the process proceeds to step S808.

In step S808 and step S809, the data set is retrieved in the view manager. The search condition used here is a search condition set in a view higher than the view managed by the view manager, and is a search condition saved in step S704 or the like in FIG. Therefore, the processing of steps S808 to S813 is not executed if the view manager does not hold the search condition of the upper view. The view data generation unit 53 of the view manager searches the INSERT data set included in the view data set received in step S807 with the preset search conditions, and extracts the changed contents that match the search conditions. (Step S808). Further, the view data generation unit 53 searches for the tuple indicated by the tuple ID included in the DELETE data set included in the view data set received in step S807 in the search condition, and searches for the content matching the search condition. The tuple ID of the tuple to have is specified (step S809). After that, the process proceeds to step S810.

In step S810 and step S811, the presence or absence of the search result is determined, and if the search result is not obtained, the transaction ID is transmitted. As a result of the search in step S808 and step S809, when a taple matching the search condition is not found (NO in step S810), the view manager is assigned a transaction ID attached to the view data set to be searched. Is transmitted to the upper view manager as a transaction ID indicating the progress time of the view data set generation process of the own node (step S811).

Here, the upper view manager to which the transaction ID is sent is the upper view manager that holds the view corresponding to the search condition used for the search, and is associated when the search condition is saved in step S704. The view is identified by reference to identifiable information. The upper view manager that has received the transmitted transaction ID manages the transaction ID as a transaction ID indicating the progress time of the view data set generation process of the source node, and determines the specific transaction ID in step S501. refer.

On the other hand, if a tuple matching the search condition is found as a result of the search in step S808 and step S809 (YES in step S810), the process proceeds to step S812.

In step S812 and step S813, the view manager generates a second view dataset. The view data generation unit 53 includes the changes extracted in step S808 in the INSERT data set, and generates a second view data set including the taple ID specified in step S809 in the DELETE data set (step S812). ). Then, the view data transmission unit 54 associates the generated second view data set with the transaction ID and transmits the generated second view data set to the upper view manager (step S813). The upper view manager that is the destination here is the upper view manager that holds the view corresponding to the search condition used for the search, and can identify the view associated with the search condition when the search condition is saved in step S704. It is identified by referring to various information. The view data acquisition unit 51 of the upper view manager receives the transmitted second view data set (not shown). The received second view dataset is used to change the view in the same manner as the other view datasets sent from the data store manager (see FIG. 17). Further, the view manager receiving the transmitted second view data set uses the transaction ID received together with the view data set as the transaction ID indicating the progress time of the view data set generation process of the source node. It is managed and referred to in step S501 to determine a specific transaction ID. After that, the process shown in this flowchart ends.

When the view manager receiving the view data set transmitted in step S813 has a higher-level view manager, the view manager receiving the view data set performs the processes shown in steps S807 to S813. By executing, the view data set for the view manager higher than the view manager is generated and transmitted. That is, the processes shown in steps S807 to S813 are executed in each view manager while passing the generated view data set from the lower level to the upper level in the hierarchy between the view managers.

The process shown in FIG. 17 is executed at a predetermined timing (for example, periodically).

In step S901, a new view transaction ID is determined. The view transaction ID update unit 55 updates the view transaction ID. Various specific methods can be adopted to determine the transaction ID for a new view. For example, the transaction IDs of snapshots referenced by multiple session managers are aggregated and matched to the oldest one. A method such as updating may be adopted. At this time, an extremely old snapshot may be referred to in rare cases, but such a snapshot may be excluded from the aggregation by setting a threshold value for the transaction ID or the like. When the new view transaction ID is determined, the process proceeds to step S902.

In step S902, the view is changed. The view change unit 56 changes the view managed by the view management unit 52 by using the view data set at the time specified by the updated new view transaction ID and the older view data set. At this time, the view changing unit 56 reflects all the view data sets up to the updated view transaction ID. After that, the process shown in this flowchart ends.

According to the database system according to the present embodiment, the view is not created and modified by relying on a table or the like such as a relational database, but is created and modified by referring to a change history (for example, a data set). Therefore, the processing load related to view creation and modification can be reduced. Further, in order to reduce the processing load related to the creation and modification of the view, a technique of using a logical view having no actual view on the memory or storage device has been conventionally proposed, but such a view has been proposed. Since the access to the link destination (entity) of the view occurs every time the view is searched, the processing load at the time of searching is not reduced. On the other hand, according to the database system according to the present embodiment, since the view exists as an entity on the memory or the storage device, the processing load at the time of searching can be reduced.

Further, according to the database system according to the present embodiment, the processing load when performing a search in a database system that uses the accumulated change history (for example, a data set) as the basic part of the database is determined by the view manager as described above. It can be reduced by providing. Therefore, the database management that relies on the accumulated data set described with reference to FIGS. 5 to 11 and 13 and the creation of the data set-based view described with reference to FIGS. 12 and 14 to 17. By combining and change, it is possible to achieve both reduction of the processing load due to database content change (update and deletion) and reduction of the processing load at the time of search. However, database management that relies on accumulated datasets and view creation and modification based on datasets do not necessarily have to be used in combination, and may be adopted individually in other database systems. ..

<Variation>
Next, variations when implementing the system, information processing device, method, and program according to the present disclosure will be described.

In the database system according to the present embodiment, further, rules (hash function, etc.) for determining the destination data store manager to which the ENCERT data set and the DELETE data set are transmitted when the contents of the database are changed are determined in advance. May be good. By doing so, the database system can be a distributed database system in which the arrangement of data is managed.

Further, in the above embodiment, the example in which the view update is executed at a predetermined timing (for example, periodically) has been described, but the view update timing may be intentionally delayed. For example, when a part or all of the views managed by the view management unit 52 are read in the memory of the view manager, the part of the view that is read in the memory may be changed. At this time, the view change unit 56 reflects all the related view data sets up to the updated view transaction ID in the block read in the memory.

Further, for example, the view changing unit 56 takes the opportunity that the view managed by the view management unit 52 becomes the target of the process in which the same or newer snapshot as the updated transaction ID for the view is specified. The view may be changed. When these techniques are adopted, the timing of view changes will be sporadic.

<Effect>
In the database system according to the present embodiment, the contents of the database are changed by accumulating the data set for change in association with the transaction ID in the data store, so that the processing load associated with the change of the contents of the database can be reduced. .. Further, in the database system according to the present embodiment, since the basic part of the database does not depend on a table or the like such as a relational database, a mechanism for dealing with a problem such as a broken table can be omitted.

Further, according to the database system according to the present embodiment, since the view is created and changed based on the change history, the processing load related to the creation and change of the view can be reduced. Further, according to the database system according to the present embodiment, since the view exists as an entity on the memory or the storage device, the processing load at the time of searching can be reduced.

Further, according to the database system according to the present embodiment, by providing the view manager, the processing load of the search can be reduced, the database management using the data set, and the creation and modification of the view based on the data set can be performed. By combining,, it is possible to achieve both reduction of the processing load due to database content change (update and deletion) and reduction of the processing load at the time of search. However, database management using a data set and creation and modification of a view based on the data set do not necessarily have to be used in combination, and may be adopted individually in other database systems.

Claims (13)

A database system comprising one or more session management nodes, one or more data store management nodes, and at least one view management node.
Each of the session management nodes
When the contents of the database are changed, the target identification information that can uniquely grasp the data unit to be changed, the data set generation means for generating the data set including the changed contents of the data unit, and the data set generation means.
A data set transmission means for transmitting the data set to at least one of the data store management nodes.
Each of the data store management nodes
A database management means for accumulating the received data set by setting a transaction identifier that can grasp the position of the transaction in the time series.
A view data generation means that generates a view data set including data that matches preset search conditions based on the data set accumulated by the database management means, and a view data generation means.
A view data transmission means for transmitting the view data set to the view management node is provided.
The view management node is
A view data acquisition means for acquiring a view data set containing data matching the preset search conditions from the data store management node, and a view data acquisition means.
A view management means that holds a set of data included in the view data set acquired by the view data acquisition means as a view corresponding to the preset search condition, and a view management means.
A view search means for searching the view according to a specified search condition is provided.
The view management means presets a set of data included in the view data set before the time specified by the view transaction identifier, which is a transaction identifier indicating a snapshot corresponding to the view. It is retained as a view corresponding to the search condition and the transaction identifier for the view.
Database system. The view management node is
View data generation means for generating a second view data set containing data matching preset search conditions for other views based on the view data set acquired by the view data acquisition means. When,
A view data transmission means for transmitting the second view data set to the view management node that manages the other views is further provided.
The database system according to claim 1. The database system includes a plurality of views having a hierarchical relationship.
The view data generation means manages a view higher than the view managed by the view management node including the view data transmission means based on the view data set acquired by the view data acquisition means. Generate a second view dataset that contains data that matches the preset search criteria in the view management node.
The view data transmission means transmits the second view data set to the upper view management node.
The database system according to claim 2. The view data generation means further generates a view data set including data matching the preset search conditions based on a data set in which a transaction identifier newer than the view transaction identifier is set.
The view management node is
A view transaction identifier update means for updating the view transaction identifier, and a view transaction identifier update means.
A view changing means for changing the view managed by the view management means by using the view data set before the time specified by the updated view transaction identifier is further provided.
The view management means holds the view changed by the view changing means as a view corresponding to the updated view transaction identifier.
The database system according to any one of claims 1 to 3. When a part or all of the view managed by the view management means is read in the memory of the view management node, the view changing means reads a part of the view that is read in the memory. change,
The database system according to claim 4. The view changing means changes the view when the view managed by the view management means becomes a target of a process in which a snapshot after the updated view transaction identifier is specified. To do
The database system according to claim 4. The view management node captures the view data set up to the search target transaction identifier indicating the search target snapshot among the view data sets acquired by the view data acquisition means but not reflected in the view. A view search result correction means for correcting the search result by the view search means is further provided.
The database system according to any one of claims 1 to 6. The view search result correction means refers to the search result by the view search means.
Addition of changes that match the specified search conditions included in the view data set up to the search target transaction identifier among the unreflected view data sets to the search result by the view search means. Processing and
Of the target identification information included in the view data set up to the search target transaction identifier of the unreflected view data set, the data shown in the deletion target identification information indicating the data unit to be deleted is used. , Exclusion processing excluded from the result of the additional processing,
By executing, the search result by the view search means is corrected.
The database system according to claim 7. In the view search result correction means, when the specific transaction identifier indicating the range of the view data set that is not subsequently acquired by the view data acquisition means is older than the search target transaction identifier, the specific transaction identifier is the search target. After waiting for the same or new identifier as the transaction identifier, the correction is performed.
The database system according to claim 7 or 8. The view management node collects transaction identifiers indicating the progress time of the view data set generation process for each node from each node that generates the view data set, and the node in which the process progresses the most is the slowest. A means for determining a specific transaction identifier, which determines a transaction identifier indicating a progress time point as the specific transaction identifier, is further provided.
The database system according to claim 9. The target identification information is information that can uniquely grasp the data unit to be changed among a plurality of data stores managed by a plurality of data store management nodes.
The database system according to any one of claims 1 to 10. In a database system with one or more session management nodes, one or more data store management nodes, and at least one view management node.
Each of the session management nodes
When the contents of the database are changed, the data set generation step for generating a data set including the target identification information that can uniquely grasp the data unit to be changed and the changed contents of the data unit, and the data set generation step.
Performing a dataset transmission step, which transmits the dataset to at least one of the data store management nodes,
Each of the data store management nodes
A database management step that stores the received data set by setting a transaction identifier that can grasp the position of the transaction in the time series, and
A view data generation step that generates a view data set containing data that matches preset search conditions based on the data set accumulated in the database management step, and a view data generation step.
A view data transmission step of transmitting the view data set to the view management node is executed.
The view management node is
A view data acquisition step for acquiring a view data set containing data matching the preset search conditions from the data store management node, and a view data acquisition step.
A view management step that holds a set of data included in the view data set acquired in the view data acquisition step as a view corresponding to the preset search condition, and a view management step.
A view search step, which searches for the view according to the specified search conditions, is executed.
In the view management step, among the data included in the view data set, a set of data before the time specified by the view transaction identifier, which is a transaction identifier indicating a snapshot corresponding to the view, is preset. It is retained as a view corresponding to the search condition and the transaction identifier for the view.
Method. In a database system with one or more session management nodes, one or more data store management nodes, and at least one view management node.
Each of the session management nodes
When the contents of the database are changed, the target identification information that can uniquely grasp the data unit to be changed, the data set generation means for generating the data set including the changed contents of the data unit, and the data set generation means.
Acting as a dataset transmitting means that transmits the dataset to at least one of the data store management nodes.
Each of the data store management nodes
A database management means for accumulating the received data set by setting a transaction identifier that can grasp the position of the transaction in the time series.
A view data generation means that generates a view data set including data that matches preset search conditions based on the data set accumulated by the database management means, and a view data generation means.
The view data set is made to function as a view data transmission means for transmitting to the view management node.
The view management node
A view data acquisition means for acquiring a view data set containing data matching the preset search conditions from the data store management node, and a view data acquisition means.
A view management means that holds a set of data included in the view data set acquired by the view data acquisition means as a view corresponding to the preset search condition, and a view management means.
To function as a view search means for searching the view according to specified search conditions,
The view management means presets a set of data included in the view data set before the time specified by the view transaction identifier, which is a transaction identifier indicating a snapshot corresponding to the view. It is retained as a view corresponding to the search condition and the transaction identifier for the view.
program.

Images