JPWO2018203377A1 - Database system, method and program - Google Patents

Abstract

An object of the present invention is to provide a view while suppressing the processing load in changing a view and the processing load in referencing a view. Each of the session managers generates a data set including a tuple ID and a change content, and generates a data set. Transmitting the data to the data store manager, each of the data store managers generates a view data set including data that matches a preset search condition based on the consulted and accumulated data set, and Is transmitted to the view manager, and the view manager extracts a set of data before the time point designated by the view transaction ID which is a transaction ID indicating a snapshot corresponding to the view among the data included in the view data set. , A preset detection It was decided to retain as a view corresponding to the transaction ID for conditions and views.

Description

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

  Conventionally, as a synchronization method in a multiplexed database system, in a multiplexed database system, 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 rearranges the processing request based on the sequence number, and controls the order of input to the DBMS so that lock conflicts do not occur in the server. (See Patent Document 1).

  Also, when a mobile agent is used for the data replication function and the database is updated at the site A, this update is detected, update transaction data is generated from the updated contents, and the site is moved to the site B to execute the update transaction. Has been proposed (see Patent Document 2).

  Various data management methods have been proposed for accumulating logs of data operations and managing data in the log format (see Non-Patent Documents 1 and 2).

JP 2007-219598 A JP 2001-350777 A

Hoang Tam Vo, Sheng Wang, Divakant Agrawal, Gang Chen, Beng Chin Ooi, “LogBase: A Scalable Log-structured Database System” Philip A. Bernstein, Colin W.S. Reid, Sudipto Das, “Hyder-A Transactional Record Manager for Shared Flash”

  2. Description of the Related Art Conventionally, in a database management system (DBMS), a view as a search result based on a predetermined search condition is created in advance to improve the efficiency of a search process, thereby improving the efficiency of the search process. However, to modify such a view, first, the table used to create the view is changed, the changed table is searched to extract information necessary for changing the view, and the view is changed. Is required. Such processing is executed, for example, with a change in a table as a trigger, but the processing content is complicated and the processing load on the entire system is large.

  Here, in order to suppress the processing load required for changing the view, a system that uses a logical view in which the content of the view as an entity is not generated and held may be considered. However, in such a logical view, the table is referred to each time the view is referred to, so it is difficult to reduce the load of the search processing.

  In view of the above-described problems, it is an object of the technology according to the present disclosure to provide a view as a search result based on a predetermined search condition while suppressing both a processing load in changing a view and a processing load in referencing a view. I do.

  In the present disclosure, the following means are employed in order to solve the above-described problem. That is, a database system according to the present disclosure is a database system including one or a plurality of session management nodes, one or a plurality of data store management nodes, and at least one view management node. A data set generating means for generating a data set including target identification information capable of uniquely grasping a data unit to be changed when the content of the database is changed, and a change content of the data unit; , Transmitting the data set to at least one of the data store management nodes, and a data set transmission unit, wherein each of the data store management nodes converts the received data set in a time series of transactions. Data to be stored by setting a transaction identifier that can identify the location A base management unit; a view data generation unit configured to generate a view data set including data that matches a preset search condition based on the data set stored by the database management unit; View data transmitting means for transmitting a data set to the view management node, wherein the view management node converts the view data set including data matching the preset search condition into the data store management data. View data acquisition means for acquiring from a node, and view management means for holding 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 search for searching for the view according to a specified search condition And a view management unit, wherein, among the data included in the view data set, data of a data before a time point designated by a view transaction identifier which is a transaction identifier indicating a snapshot corresponding to the view is provided. A database system for holding a set as a view corresponding to the preset search condition and the view transaction identifier.

  The present disclosure can be understood as an information processing device, a system, a method executed by a computer, or a program executed by a computer. Further, the present disclosure can be understood as such a program recorded on a recording medium readable by a computer, other devices, machines, and the like. Here, a recording medium readable by a computer or the like refers to a recording medium that can store information such as data and programs by electrical, magnetic, optical, mechanical, or chemical actions and can be read from a computer or the like. Say.

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

FIG. 1 is a diagram illustrating a structure of a database system according to an embodiment. FIG. 3 is a diagram illustrating an outline of a hardware configuration of a node according to the embodiment. FIG. 2 is a diagram illustrating an outline of a functional configuration of a node according to the embodiment. FIG. 4 is a diagram illustrating a structure of a change data set generated in the embodiment. It is a flowchart (1) which shows the flow of database management processing in embodiment. It is a flowchart (2) which shows the flow of database management processing in embodiment. FIG. 7 is a diagram illustrating a flow of an instruction process and a data set for change / update process executed by a session manager in the embodiment. It is a flowchart (3) which shows the flow of database management processing in embodiment. It is a flowchart (4) which shows the flow of database management processing in embodiment. It is a flowchart (5) which shows the flow of database management processing in embodiment. 9 is a flowchart illustrating a flow of a data search process in the data store manager according to the embodiment. 9 is a flowchart illustrating a flow of a data search process in the view manager according to the embodiment. 9 is a flowchart illustrating a flow of a truncation process in the data store manager according to the embodiment. 9 is a flowchart illustrating a flow of a view creation process according to the embodiment. 6 is a flowchart (1) illustrating a flow of a view change process according to the embodiment. 9 is a flowchart (2) illustrating a flow of a view change process according to the embodiment. It is a flowchart (3) which shows the flow of a view change process concerning embodiment.

  Hereinafter, embodiments of a system, an information processing apparatus, a method, and a program according to the present disclosure will be described with reference to the drawings. However, the embodiments described below exemplify the embodiments, and do not limit the system, the information processing apparatus, the method, and the program according to the present disclosure to the specific configurations described below. In the implementation, a specific configuration according to the embodiment is 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 an instruction to change the contents of a database (such as an INSERT instruction, a DELETE instruction, and an UPDATE instruction) is processed, the contents of the change related to the change instruction are stored in the database system. A technique for managing data in respective data stores managed by a plurality of nodes belonging to a. Here, the data store is a word indicating a record of part or all of the database managed by the database system according to the present disclosure, or a place where part or all of the database is held. Note that the database management technology according to the present disclosure is not limited to the system illustrated in the present embodiment, but is applicable to a database system having a plurality of nodes. Further, the database system that can adopt the database management technology according to the present disclosure 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 communicably connected to 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. Some of the other nodes are nodes having a role as a session manager, and operate as a session management node. Some of the other nodes are nodes having a role as a data store manager, and operate as data store management nodes. Further, some of the other nodes are nodes having a role as a view manager, and operate as view management nodes.

  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. Also, when constructing a database system that does not refer to a view, 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 of the data store management nodes has a data store managed by a data store manager operating on itself, and these data stores are stored in a database managed by the database system according to the present disclosure. It has some or all of the data. In the database management technique according to the present disclosure, a change data set including the content of a change to be made to a database is generated by any session manager, propagated to one or more data store managers belonging to the system, and propagated. When the transaction ID is assigned to the change data set and managed by each data store, the change of the entire database is completed. For this reason, in the system according to the present embodiment, when a change data set occurs, the same change data set is transmitted to a plurality of data store managers, so that data store management can be made redundant, and database replication can be performed. Can be realized. Redundancy of data store management can be realized, for example, by specifying a plurality of node IDs of the transmission destination of the change data set, or preparing a plurality of data store management nodes for a single node ID. But it is feasible. Details of the database management technology will be described later.

  In the present embodiment, each view management node has a view managed by a view manager operating on itself. In the present embodiment, a view is data obtained by narrowing down data at a time point specified by a certain transaction ID by a search condition and organizing the data in a form suitable for a search. The search condition is notified to the data store manager and the session manager together with information capable of identifying the view related to the search condition. Note that the format in which the view holds data is not limited. The view can hold data in the form of, for example, a table (table) or a graph. The present embodiment will be described on the assumption that one view manager manages one view. For this reason, in the present embodiment, the view manager can be identified by the view ID, and the search condition (view search condition) used to generate the view is to identify the view and the view manager. Can also be used as information. However, a plurality of views may be managed by one view manager.

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

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

  Further, a 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 the user terminal 9 or the like.

  FIG. 2 is a diagram illustrating an outline of a hardware configuration of a 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, and the like, 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 according to the embodiment. Further, the node is not limited to a single device. The node may be realized by a plurality of devices using a so-called cloud or distributed computing technique. The data store managed by each node may be constructed on the storage 14 or on the RAM 12, and the construction location of the data store is not limited.

  The storage 14 stores various programs together with the operating system, and the CPU 11 reads and executes the programs via the bus and the RAM 12 to realize the function as the above-described node. The nodes on which each manager operates may have the same hardware configuration.

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

  First, a functional configuration of the session management node will be described. In the present embodiment, each of the plurality of nodes having the role of the session manager reads and executes the session manager program via the bus and the RAM 12 to execute the query accepting unit 21, the query processing unit 22, and the snap processing unit. It functions as a session management node including a shot specifying 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 receiving unit 21 receives a query for the database system transmitted from the user terminal 9. In the database system according to the present embodiment, there are a plurality of session management nodes that execute a session manager, and any of the plurality of session management nodes can receive a query from the user terminal 9.

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

  The snapshot specifying information obtaining unit 23 obtains, from the transaction manager, information capable of specifying a snapshot used for processing. Here, the snapshot is a word indicating the content of the database at a certain point in time series in which the content of the database changes as transactions are sequentially committed. In the present embodiment, the information acquired by the snapshot identifying information acquiring unit 23 is a transaction ID (hereinafter, referred to as “snapshot identifying transaction ID”). However, the acquired information is for guaranteeing the consistency of data used in the processing of the transaction, and thus may be any information that can specify the snapshot, and is not limited to the transaction ID. For example, the information that can specify a snapshot may be information that can specify a logical point in time in a time series in which a plurality of transactions are sequentially processed, instead of the transaction ID.

  The processing data acquisition unit 24 acquires data used for processing a query from at least one of a plurality of data store managers and a plurality of view managers. At this time, the processing data obtaining unit 24 specifies the information (snapshot specifying transaction ID) obtained by the snapshot specifying information obtaining unit 23 to the data store manager or the view manager, and Get 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 performs the tuple ID of the tuple to be changed without making a change based on the change instruction to the database. And a change data set including the change contents. 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 content of the change is reflected in the database. In the database system according to the present embodiment, the data set for change 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 data set for change. The changes are reflected in the database.

  In the present embodiment, a data unit treated as an individual record in a database is described as a tuple. However, a data unit to which the present invention can be applied is a data unit referred to as a tuple in a general database system. It is not limited to. In the data store of the database system according to the present disclosure, data is managed in the form of a data set for change, not in a table format or the like used in a 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 target identification information that allows a tuple (data unit) to be changed to be uniquely identified 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 the plurality of session management nodes in the tuple ID. However, the data set for the change only needs to include the contents of the change of the database based on the change command and the information that can uniquely grasp the tuple to be changed in the database system. It is not limited to the example in the form.

  FIG. 4 is a diagram illustrating a structure of a change data set generated in the present embodiment. However, the specific configuration, format, or generation method of the change data set is not limited to the example in the present embodiment. The change data set according to the present embodiment is information generated by reading out data including a tuple to be changed based on a change instruction onto the RAM 12 and performing an operation on the data based on the change instruction. , DELETE data set (tuple list for DELETE instruction) and INSERT data set (tuple list for INSERT instruction).

  In addition, a snapshot identification transaction ID and a data set ID are set in the change data set. The data set ID is identification information capable of uniquely identifying the change data set, and is given when the change data set is generated.

  The DELETE data set and the INSERT data set include information indicating a tuple targeted for a change instruction. Specifically, the DELETE data set includes the tuple ID of the tuple to be deleted (2 in the example shown in FIG. 4), and the INSERT data set includes the tuple ID of the tuple to be added (FIG. 4). In the example shown in (1), 13) and the content of data to be added are included. In this embodiment, the UPDATE instruction is treated as a combination of the INSERT instruction and the DELETE instruction. The tuple ID of the tuple 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 tuple ID of the tuple containing the data is included in the INSERT data set. However, the data set in which the tuple ID of the tuple including the data before the update by the UPDATE instruction and the tuple ID of the tuple including the updated data and the data are not limited to the example disclosed in the present embodiment. . For example, the tuple ID and data related to the UPDATE instruction may be configured to be collectively included in the UPDATE data set.

  The data set transmission unit 26 transmits the change data set 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 transmitting unit 26 transmits the deletion target tuple ID (tuple ID described in the DELETE data set) and the data set ID indicating at least the data unit to be deleted among the tuple IDs included in the data set, to the transaction manager. Send to

  Next, a functional configuration of the transaction management node will be described. In this embodiment, the node having the role of the transaction manager reads and executes the transaction manager program via the bus and the RAM 12 to execute 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 transmission unit 26 of the session manager.

  The conflict determination unit 32 includes a deletion target tuple ID described in the DELETE data set acquired by the information acquisition unit 31 and information indicating the changed tuple accumulated by the modified data unit information accumulation unit 33 (this embodiment Then, the tuple ID of the deleted tuple is compared with the corresponding tuple ID to confirm whether or not a matching tuple ID exists, thereby determining 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 stopped.

  When the conflict determination unit 32 determines that there is no conflict of the deletion target, the change data unit information storage unit 33 replaces the tuple ID acquired by the information acquisition unit 31 with the tuple changed in the database system. The information is accumulated as information indicating which tuple was changed at which 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 capable of grasping a position in a logical chronological order related to the processing of the transaction. In this embodiment, an ascending integer is used as the transaction ID.

  The identifier transmitting unit 35 transmits the identifier set including the data set ID and the transaction ID corresponding to the data set ID to at least the data corresponding to the data set ID by the data set transmitting unit 26 among the plurality of data store managers. Send to the datastore manager where the set 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 the role of the data store manager reads and executes the data store manager program via the bus and the RAM 12 so that the processing data transmission unit 41 and the data set It functions as a data store management node including a / identifier receiving unit 42, a database management unit 43, an aggregate 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, from the session manager, a data request specifying information that can specify a snapshot (in this embodiment, a transaction ID for specifying a snapshot), the processing data transmission unit 41 performs processing up to the specified snapshot. The processing data generated based on the change data set is transmitted to the session manager.

  The data set / identifier receiving unit 42 receives the change 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 technology 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 a transaction ID and storing the received data set. More specifically, when the data set / identifier receiving unit 42 receives the identifier set, the database management unit 43 specifies the data set indicated by the data set ID included in the identifier set, and A transaction ID corresponding to the data set ID is set.

  The aggregate data set generation unit 44 concatenates the changes contained in the data set at the time point designated by the predetermined transaction ID and the older data set, and removes the data indicated in the DELETE data set to thereby execute the predetermined transaction. The data set at the point in time specified by the ID and the older data set are integrated to generate an aggregated data set. When the aggregate dataset is generated, the database management unit 43 manages the aggregate dataset as one of the stored datasets by setting a transaction ID to the aggregate dataset. In the present embodiment, by setting two transaction IDs, a transaction ID indicating a start point and a transaction ID indicating an end point, in a set data set, the range of transactions included in the set data set is indicated. Here, the transaction ID indicating the start point is the ID of the oldest transaction among the original transactions linked to the aggregate data set, and the transaction ID indicating the end point is the ID of the original transaction linked to the aggregate data set. This is the ID of the newest transaction. In addition, 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 for the set data set.

  The data extracting unit 45 converts a data set designated by a desired transaction ID and a data set in which an older transaction ID is set from data sets stored by the database management unit 43 into a desired search condition. Extract matching data. Specifically, the data extracting unit 45 extracts data indicated by the deletion target tuple ID described in the DELETE data set from the data searched out by searching for the changed contents of the tuple included in the INSERT data set. By removing the data, data matching the desired search condition is extracted. Here, when the search target transaction ID is newer than the specific transaction ID (in this embodiment, the latest transaction ID) indicating the range of the data set that is not reflected thereafter, the data extraction unit 45 determines that the search target transaction ID is Extraction is performed after waiting for a transaction ID equal to or older than the transaction ID.

  The view data generation unit 46 generates a view data set including data that matches a preset search condition based on the data set stored by the database management unit 43. The configuration of the view data set generated here is substantially the same as the configuration of the change data set described with reference to FIG. 4, and the generated transaction data set has a corresponding transaction ID. Is done.

  The view data transmitting unit 47 transmits, to the view manager, a view data set including data that matches a preset search condition and is generated based on the data set stored by the database management unit 43.

  Next, a functional configuration of the view management node will be described. In the present embodiment, each of the plurality of nodes serving as the view manager reads and executes the view manager program via the bus and the RAM 12 to execute the view data acquisition unit 51 and the view management unit 52. 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. Act as a node.

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

  The view management unit 52 sets a set of data at the time point specified by the view transaction ID and older data among data included in the view data set acquired by the view data acquisition unit 51 in advance. It is held as a view corresponding to the search condition and the view transaction ID. Here, the view transaction ID is a transaction ID indicating a snapshot corresponding to the view. In addition, even when the view is changed by the view changing unit 56, the view managing unit 52 holds the changed view as a view corresponding to the updated view transaction ID.

  The view data generation unit 53 generates data that matches search conditions set in advance for other views (in this embodiment, search conditions set in advance for views higher than the view including the view data transmission unit 54). Generate a second view data set containing Here, the second view data set is generated to change the view managed by the upper view.

  In addition, the view data generation unit 53 may generate the second view data set based on the view managed by the view manager, or the view data acquired by the view data acquisition unit 51. A second view data set may be generated based on the set. When generating the second view data set based on the view data set, the view data generation unit 53 sets, in the acquired view data set, data in which a transaction ID newer than the view transaction ID is set. A second view data set is generated based on the set.

  The view data transmitting unit 54 converts the second view data set into a view manager (in this embodiment, a higher-level view, which manages a view related to the search condition used to generate the second view data set). View manager).

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

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

  The view search unit 57 searches for a view according to the specified 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 search target snapshot is newer than the view transaction ID. The view search result correction unit 58 uses the view data sets 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 views to correct the search results. However, here, the view search result correction unit 58 determines whether the search target transaction ID is the same as the specific transaction ID when the search target transaction ID is newer than the specific transaction ID indicating the range of the view data set that is not acquired thereafter. Alternatively, the correction is performed after waiting for an older transaction ID.

  The specific transaction ID determination unit 59 collects, from each node that generates a view data set, a transaction ID indicating the progress time of the view data set generation processing by the view data set generation units 46 and 53 for each node, The transaction ID indicating the progress point at the node where the progress of the view data set generation process is the least delayed is determined as the specific transaction ID. That is, the specific transaction ID determination unit 59 collects the transaction ID indicating the current processing progress time for each node from each node, manages this value for each node, compares the latest value for each node, Is determined as the specific transaction ID.

<Process flow>
Next, details of the processing according to the present embodiment will be described. Note that the specific contents, order, and the like of the processing described in the present embodiment are examples of implementation. Specific processing contents, order, and the like may be appropriately selected according to the embodiment.

  5 to 10 are flowcharts illustrating the flow of the database management process according to the present embodiment. The process illustrated in the flowchart of FIG. 5 includes a query transmitted from the user terminal 9 by the query receiving unit 21 of any session management node belonging to the database system, and includes a command to change the content of the database. It is started when a transaction start command is received.

  In steps S101 to S105, a transaction is started, and a snapshot identification transaction ID used for processing is obtained. When a transaction start command is received (step S101), the snapshot specifying information acquisition unit 23 inquires of the transaction manager about a snapshot specifying transaction ID used for processing (steps S102 and S103). Then, the transaction manager transmits the transaction ID last given at the time of the reply to the session manager (step S104), and the snapshot specifying 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 (ie, the latest) at the time of reply, but the transaction ID transmitted at this time is set to the latest transaction ID. Not limited. Thereafter, the processing shown in this flowchart ends.

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

  In step S106, an instruction included in the transaction is read. The processing data acquisition unit 24 reads an instruction to be processed next, which is included in the query received by the query reception unit. Thereafter, the process proceeds to step S107.

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

  In steps S108 to S112, data necessary for processing the instruction read in step S106 is obtained. In steps S108 to S112, the processing data acquisition unit 24 requests data from a view manager suitable for acquiring data 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 command 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 that has received the data request in step S109 acquires data corresponding to the search condition and the snapshot identification transaction ID from the view managed by the view manager (step S110). The flow of the process in which the view manager that has received 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 transmitted the data request (step S111). Thereafter, the processing data acquisition unit 24 of the session manager that has transmitted the data request acquires the processing data by receiving the transmitted data (step S112). Thereafter, the process proceeds to step S113.

  In step S113, it is determined whether data acquisition from the data store manager is necessary. The session manager determines whether or not all the data necessary for the processing by the query processing unit 22 has been obtained in the processing of acquiring the processing data from the view manager up to step S112. This is because there is a possibility that there is data that is not covered by the view, and there is a possibility that data necessary for processing cannot be obtained from the view manager.

  For example, if the range of data covered by a view is a part of the table from which data is to be acquired, of the data contained in the table, the data covered by the view is acquired by inquiring the view manager. Is done. On the other hand, among the tables for which data is to be acquired, data not covered by the view needs to be acquired from the data store manager. Here, as a specific method of the determination in step S113, information such as a list indicating a range covered by the view in the table (for example, a tuple ID or a view using a tuple content such as a primary key of the table) is used. A method of determining whether all necessary data has been prepared only by inquiring of the view manager by referring to this list may be adopted.

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

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

  In steps S114 to S118, data necessary for processing the instruction read in step S106 is obtained. The processing data acquisition unit 24 notifies the data store manager of the search condition and the snapshot identification transaction ID, and requests 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 point specified by the received snapshot specifying transaction ID and the older change data set. A search is performed using the searched 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 flow of the process in which the data store manager receives the data request to acquire the data will be described later with reference to FIG. Thereafter, the processing data acquisition unit 24 acquires desired processing data by receiving the data transmitted from the data store manager (step S118). Thereafter, the process proceeds to step S119.

  In step S119, an instruction process and a change data set generation / update process are executed. Details of the processing executed in this step will be described in detail with reference to FIG. Thereafter, the process returns to step S106.

  FIG. 7 is a diagram showing the flow of the command processing and the data set generation / update processing for change executed by the session manager in the present embodiment. This flowchart shows the details of the processing in 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 condition, the data obtained from the view manager in step S112 and the data obtained from the data store manager in step S118. In the acquired data, data duplication for the same tuple may occur. For this reason, when the data acquired in step S112 and step S118 includes data related to the same tuple redundantly, the processing data acquisition unit 24 deletes one of the duplicated data, Eliminate data duplication. Thereafter, the process proceeds to step S122.

  In the present embodiment, a method of eliminating duplication after acquiring data is adopted. However, instead of such a method, steps S108 and S114 are performed so that duplication does not occur at the time of a data request. A technique for changing the content of the transmitted data request may be adopted.

  In steps S122 and S123, the data acquired for the instruction processing is adjusted based on the change data set generated in the transaction. This is a process for making the instruction execution in step S124 correctly reflect the execution result of the instruction already executed in the same transaction. If the change data set generation / change processing has already been executed at least once for the transaction and the change data set related to the transaction has been generated, the query processing unit 22 deletes the contents of the change data set. To adjust the data acquired in the processing up to step S118.

  More specifically, the query processing unit 22 searches the INSERT set in the change data set using search conditions (the search conditions used in step S108 and step S114), and searches the tuple 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 indicated in the DELETE set in the change data set from the obtained data (step S123). Thereafter, the processing proceeds to step S124.

  In step S124, the command is executed. The query processing unit 22 processes the command read in step S106 by using the obtained data obtained in the processing from step S108 to step S118 and obtained as a result of the adjustment in step S122 and step S123. That is, the query processing unit 22 processes the command based on the data acquired from the data store manager and / or the view manager and the change data set generated in the transaction. Thereafter, the process proceeds to step S125.

  In steps S125 to S127, a data set for change 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 content without reflecting the change obtained as a result of the instruction execution in step S124 in the database. I do.

  Here, the new tuple to be deleted generated as a result of the instruction execution includes a tuple newly added in the processing so far of the transaction and a tuple that is not. For this reason, the data set generation unit 25 selects, from among the new deletion target tuples generated as a result of the instruction execution, the tuples existing in the INSERT set in the change data set related to the transaction (the new tuples in the previous processing of the transaction). Is deleted from the INSERT set (step S125). In addition, among the new deletion target tuples generated as a result of the instruction execution, the data set generation unit 25 changes the new deletion target tuple that is not included in the INSERT set in the change data set related to the transaction. It is added to the DELETE 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 the 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 tuple ID of the INSERT data set includes the newly numbered entire database system (more specifically, managed by a plurality of data store managers). A unique tuple ID is written between a plurality of data stores. Further, when a change data set relating to the transaction is newly generated, the snapshot identification transaction ID acquired in step S105 is set in the change data set. Thereafter, the processing shown in this flowchart ends.

  In the present embodiment, if the new tuple to be deleted generated as a result of the instruction execution is a tuple that exists in the INSERT set in the change data set related to the transaction, a new tuple to be deleted is executed every time the instruction is executed. Is deleted from the INSERT set in the data set for change (see step S125). However, another method may be adopted instead of the above method. For example, tuples to be deleted generated by the execution of an instruction in a transaction are accumulated in the DELETE set while the instruction is sequentially executed, and before transmission of the INSERT set to the data store manager (step S206 described later). , INSERT set and DELETE set may be compared to cancel out duplicate tuples between the DELETE set and the INSERT set.

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

  In steps S201 and S202, the INSERT 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 a data store manager that manages a data store to which data is added by an INSERT instruction among a plurality of data store managers (step S201), The ID and the INSERT data set are transmitted to the determined data store manager (step S202). Here, the INSERT data set may be transmitted directly to a target data store manager, or may be transmitted 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 INSERT data set (change contents) transmitted by the session manager. Thereafter, the process proceeds to step S203.

  In step S203, it is determined whether the DELETE data set is included in the change data set. When the DELETE data set is not included in the change data set and only the INSERT data set is included in the change data set, since the instruction does not change an existing tuple, it is unnecessary to determine a conflict by the transaction manager. Therefore, if it is determined that the DELETE data set is not included in the change data set, the process proceeds to step S204.

  In step S204, the data set ID is transmitted. The data set transmitting 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. Thereafter, the processing shown in this flowchart ends.

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

  In steps S205 and 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, as a transmission destination, at least a data store manager that manages a data store including data to be changed by the DELETE instruction among a plurality of data store managers (Step S205). ), The data set ID and the DELETE data set are transmitted to the data store manager determined as the transmission destination (step S206). Here, the DELETE data set may be transmitted directly to a target data store manager, or may be transmitted 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 DELETE data set (change contents) transmitted by the session manager. Thereafter, the process proceeds to step S207.

  In step S207, the data set ID, the snapshot specifying 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 (deletion target tuple ID) transmitted in step S206 to the transaction manager together with the snapshot identification transaction ID. The information acquisition unit 31 of the transaction manager acquires the data set ID, the snapshot identification transaction ID, and the DELETE data set (deletion target tuple ID) transmitted by the session manager. Thereafter, the processing 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, a data set 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 transaction ID for snapshot identification and the DELETE data set in addition to the data set ID. Thereafter, the process proceeds to step S302.

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

  In step S303, a transaction ID is assigned. When there is no conflict of the deletion target, the identifier generation unit 34 assigns a transaction ID for identifying a transaction related to the change data set indicated by the data set ID. As described above, the transaction ID is an identifier capable of grasping a position in a logical chronological order related to the processing of the transaction. In the present embodiment, the integer numerical values are assigned in ascending order in the order in which no conflict exists. Numbered. Thereafter, the process proceeds to step S314.

  In step S304, a conflict determination is performed. The conflict determination unit 32 compares the tuple ID to be deleted described in the DELETE data set acquired in step S301 with the conflict determination tuple ID accumulated when step S313 described below was previously executed. By checking whether a matching tuple ID exists, it is determined whether 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 was executed before. As described above, the transaction ID for snapshot identification acquired in step S105 is set in the data set for change, and the conflict determination unit 32 determines that the conflict ID stored after the transaction identified by the transaction ID is The tuple ID for determination and the tuple ID to be deleted are compared.

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

  In steps S305 to S311, the transaction related to the data set for change is interrupted, and the change based on the data set for change 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 changing the database based on the change dataset including the corresponding tuple to be deleted.

  Specifically, the transaction manager transmits an abort notification to the session manager that transmitted the data set ID (step S305). Upon receiving the abort notification (step S306), the session manager suspends (aborts) the transaction related to the change data set (step S307), and at least sends the change data set to the data store management node to which the change data set has been sent. An instruction to discard the data set for change is issued (step S308). The data store manager that has received the instruction to discard the change data set (step S309) discards the received change data set (step S310). Further, the session manager notifies the user of the interruption of the transaction (step S311).

  In the present embodiment, the data set discard instruction to the data store manager is transmitted from the session manager, but the transaction manager may directly transmit 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 has received the aborted data set) from the session manager, or broadcasts the abort notification to all data store managers. It may be that. Thereafter, the processing shown in this flowchart ends.

  In step S312, a transaction ID is assigned. If 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 a transaction related to the change data set indicated by the data set ID. The specific form of the transaction ID employed is as described in step S303. Thereafter, the process proceeds to step S313.

  In step S313, the tuple ID for conflict determination is accumulated. The change data unit information accumulation unit 33 accumulates 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 accumulated tuple ID for conflict determination stored here is referred to in step S304 when the database management process according to this flowchart is executed next time or later. Thereafter, the process proceeds to step S314.

  In steps S314 and 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 it in the storage of the transaction management node (step S314). Then, the identifier transmission unit 35 of the transaction manager transmits an identifier set, which is a set of the data set ID and the transaction ID linked to each other, to all the data store managers (Step S315).

  That is, in the present embodiment, the transaction manager notifies the numbered transaction ID to the data store manager having no corresponding data set as the latest transaction ID. The data store manager that has received the notification of the latest transaction ID uses the latest transaction ID for comparison with the search target transaction ID in a data search process described later with reference to FIG.

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

  Note that 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 in step S315, the transaction manager sets the data store manager that has received the corresponding INSERT data set and DELETE data set , By receiving notification from the session manager. However, means for determining the data store manager to which the identifier set is to be transmitted is not limited, and various means may be employed.

  The identifier transmitting unit 35 may transmit a plurality of identifier sets collectively. By transmitting a plurality of identifier sets collectively, the communication load on the database system can be reduced. Thereafter, the process proceeds to step S316.

  In steps S316 to S318, a commit notification is performed. The transaction manager transmits a commit notification to the source session manager of the data set for change (step S316). Upon receiving the commit notification (step S317), the session manager notifies the user terminal 9 that has transmitted 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 assignment to the data set in the data store (step S321 described later), or may be performed after waiting. .

  In step S319, the data set ID and the 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. Thereafter, the process proceeds to step S320.

  In steps S320 and S321, a transaction ID is assigned 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 processing described with reference to FIG. By comparing the received data set ID with the received data set ID in S319, the change data set corresponding to the received data set ID is specified (Step S320). When the data store manager has received the data set for change corresponding to the data set ID, the database management unit 43 stores the INSERT data set and / or the DELETE data set indicated by the data set ID included in the identifier set. Then, a transaction ID corresponding to the data set ID is set (S321). Thereafter, 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 to be updated here is a transaction ID indicating a range of a data set that is not reflected in the database by the data store manager thereafter. Used. Thereafter, the processing shown in this flowchart ends.

  In the database system according to the present embodiment, the content of the database is not changed by rewriting a table or the like having a predetermined format, but the data set for change including the content of the change is associated with the transaction ID and stored in the data store. The accumulation changes the contents of the database. For this reason, 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 tables 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 illustrating a flow of a data search process in the data store manager according to the present embodiment. FIG. 11 explains in detail the data search processing executed in step S116, step S710, and the like.

  In steps S401 and S402, the possibility that the data set required for the search has not yet been reflected in the database by the data store manager, in other words, the data set to which the transaction ID has not yet been assigned by the data store manager, It is determined that the data set necessary for the search is included. If the result of the determination is that there is a possibility that the data set required for the search has not yet been reflected, the search processing is awaited. Specifically, the data extraction unit 45 determines a search target transaction ID indicating the search target snapshot and a specific transaction ID indicating the progress point of the current process in the entire database system in order to determine the need for standby. Are compared (step S401). Here, the search target transaction ID is a snapshot identification transaction ID when the data search process is a process according to step S116, and a view transaction ID when the data search process is a process according to step S710. It 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 in FIG.

  The target to be compared with the search target transaction ID to determine whether there is a possibility that the data set required for correcting the search result has not yet been reflected is not limited to the example disclosed in the present embodiment. The specific transaction ID to be compared with the search target transaction ID may be a transaction ID indicating a range of a data set that is not reflected by the data store manager performing 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 that is smaller than that value) in the data set (all data already received or received in the future). This is a transaction ID that is guaranteed not to be assigned an older transaction ID. Further, the method by which the data store manager that makes the determination obtains information for determination (for example, the latest transaction ID) is not limited. In this embodiment, when the latest transaction ID is notified from the transaction manager (step S315), the data store manager obtains information for determination, but the data store manager searches for information for determination. It may be obtained by inquiring the transaction manager or another data store manager at the time of processing.

  As a result of the determination in step S401, when it is determined that the search target transaction ID is a (newer) 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 or a new transaction ID as the search target transaction ID (in other words, until there is no possibility that a data set required for the search is acquired). (Step S402). On the other hand, when it is determined that the search target transaction ID is the same or older than the specific transaction ID, the process proceeds to step S403.

  In steps S403 to S405, data is extracted in accordance with the search condition. First, the data extraction unit 45 selects a desired data set from among the data sets stored by the database management unit 43, in which the same or older transaction ID as the search target transaction ID indicating the search target snapshot is set. (Specifically, the change contents of the tuple included in the INSERT data set) that matches the search condition (for example, the search condition notified from another node) (step S403).

  Next, the data extraction unit 45 sets the DELETE in which the same or older transaction ID as the search target transaction ID indicating the search target snapshot is set in the tuple ID of the tuple retrieved from the INSERT dataset in step S403. A data set is searched (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 extracting unit 45 can extract, from the data set for change (including the INSERT data set and the DELETE data set) stored in the data store manager, data matching the desired search condition and the desired snapshot. Is extracted. Thereafter, the processing shown in this flowchart ends.

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

  In steps S501 and S502, it is determined that the view data set necessary for the search result correction has not yet been received by the view manager, and if there is a possibility that the necessary data set has not yet been received, Search processing is awaited. Specifically, the view search result correction unit 58 determines the necessity of standby by searching for the search target transaction ID indicating the search target snapshot and the progress of the current view data set generation process in the entire database system. The specific transaction ID indicating the time point is compared (step S501).

  In the present embodiment, the specific transaction ID indicating the progress point 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 processing (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. The transaction ID indicating the progress point is collected, and the transaction ID indicating the progress point at the node where the processing progresses most late is determined as the specific transaction ID. For this reason, in the present embodiment, each node (including the data store manager and the view manager) that generates a view data set assigns a transaction ID indicating the progress point of the view data set generation process of its own node to the transaction ID in the system. The notification is sent to the relevant view manager (notification processing will be described later with reference to FIGS. 15 and 16).

  Note that other methods may be employed to determine whether a data set required for correcting the search result has not been received yet. The specific transaction ID to be compared with the search target transaction ID may be a transaction ID that indicates a range of a view data set that is not acquired for the view to be searched. That is, in the present embodiment, a specific transaction ID in a view is a view in which a view manager performing a search assigns a transaction ID smaller than that value (ie, an earlier transaction ID) to a view to be searched. This is a transaction ID that is guaranteed not to acquire a data set. Further, there is no limitation on the method by which the view manager that makes the determination collects information for the determination (in this embodiment, the transaction ID indicating the progress point of the view data set generation process for each node). The view manager may collect information for determination by inquiring the data store manager or another view manager during the search processing.

  As a result of the determination in step S501, when it is determined that the search target transaction ID is a (newer) transaction ID after the specific transaction ID, a 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 determines that the specific transaction ID is the same as or new to the search target transaction ID (in other words, there is a possibility that a data set required for correcting the search result may be obtained). The process waits (until it disappears) (step S502). On the other hand, if it is determined that the search target transaction ID is the same 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 there is a possibility that the data set required for correcting the search result may not be received yet. 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 search target transaction ID is a transaction ID older than the view transaction ID, it is difficult to search for the search target snapshot in the view held by the view manager. Therefore, the view manager notifies the transmission source of the search request that the search has failed (step S504). On the other hand, if it is determined that the search target transaction ID is the same as or newer than the view transaction ID, the process proceeds to step S505.

  In step S505, a view is searched according to the specified search condition. The view search unit 57 searches for a view using a specified search condition in a method according to a data format (for example, a table format or a graph format) in which the view is stored. As described above, the data format of the view adopted when implementing the present disclosure is not limited, and the search method is not limited. As the data format of the view, those related to the conventional database technology such as the table format and the graph format can be adopted, and the same retrieval method as the conventional one can be adopted. Detailed description is omitted. Thereafter, 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 includes a specified search condition included in the view data sets 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 contents of the tuple included in the INSERT data set) (step S506). Then, the view search result correction unit 58 uses the tuple ID of the tuple found in steps S505 and S506, and deletes the DELETE data of the unreflected view data set after the view transaction ID and before the search target transaction ID. A set is searched (step S507).

  In step S506, duplicate data is deleted from the data obtained by the search. Since the view data set is notified from a plurality of nodes, data included in the view data set may have data duplication relating to the same tuple. For this reason, if the data obtained from the INSERT data set as a result of the search includes duplicate data related to the same tuple, the view search result correction unit 58 deletes one of the duplicated data. , To eliminate duplication of data.

  Although the present embodiment employs a method of resolving duplication after searching for data, 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 out in step S506 to the data searched out in step S505, and then adds the data to be deleted to the tuple ID searched out 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. Thereafter, the processing shown in this flowchart ends.

  The processing described with reference to the flowcharts of FIGS. 5 to 12 can reduce the load due to the database change as described above. Also, by preparing a plurality of data store managers, the search load can be distributed. However, in the above-described processing, as the INSERT data set and the DELETE data set are accumulated in the data store manager, the processing amount and the data set of the data search processing in the data store manager shown in FIG. More storage space is used. For this reason, in the database system according to the present embodiment, the truncation process is performed, and the storage is used efficiently. Here, the truncation process is performed by a method of transforming a data set (INSERT data set and DELETE data set).

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

  In step S601, a predetermined transaction ID (Xi) serving as a reference for processing is determined. The aggregate data set generation unit 44 determines a predetermined transaction ID (Xi) as a processing reference based on the necessity of a snapshot before a predetermined point in a query process or a view change process that can occur thereafter. . The predetermined transaction ID (Xi) serving as a reference for 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 the transaction ID for snapshot identification in the future. It is preferable that the transaction ID is older than both of the oldest ID with the oldest ID and the oldest ID that may be used as a transaction ID for views in the future.

  Various methods may be adopted as a specific method for determining the predetermined transaction ID (Xi). For example, a method may be adopted in which the transaction IDs of the referenced snapshots are totaled and updated according to the oldest one. Alternatively, for example, a transaction ID that is older than a view transaction ID by a predetermined period or more in a transaction time series may be used. Thereafter, processing proceeds to step S602.

  In steps S602 and S603, the tuple changes included in the data set specified by the predetermined transaction ID and the older data set are linked, and the data indicated by the deletion target tuple ID is removed. , An aggregated data set is generated by integrating the data set at the time point specified by the predetermined transaction ID (Xi) and the older data set. Specifically, the aggregate data set generation unit 44 specifies an INSERT data set at the time point designated by a predetermined transaction ID (Xi) and an older INSERT data set among the data sets stored in the data store manager. Then, a set INSERT data set is generated (step S602).

  Then, from the set INSERT data set generated by the concatenation, the set data set generation unit 44 extracts tuples specified as the DELETE data set at the time point specified by the predetermined transaction ID (Xi) and the older DELETE data set. Excluded (step S603). Thereafter, the process proceeds to step S604.

  In step S604 and step S605, management of the generated set INSERT data set is started as a part of the data store. The database management unit 43 sets two transaction IDs (X0 and Xi), a transaction ID (X0) indicating the start point and a transaction ID (Xi) indicating the end point, in the newly generated set INSERT dataset. (Step S604). In this way, the newly generated aggregate data set is managed as one of the stored data sets. Then, the database management unit 43 checks the data set used for generating the set data set, that is, the INSERT data set and the DELETE data set at the time point designated by the predetermined transaction ID (Xi), and the older INSERT data set. And the DELETE data set are deleted (however, except for the newly generated set INSERT data set) (step S605). Thereafter, the processing shown in this flowchart ends.

  In the database system according to the present embodiment, the views are managed by the view manager in order to reduce the search load on the data store manager. Hereinafter, with reference to FIGS. 14 to 17, a view creation and change process according to the present embodiment will be described.

  FIG. 14 is a flowchart illustrating the flow of the view creation processing according to the present embodiment. The processing illustrated in the flowchart of FIG. 14 is started when the view manager is instructed to generate a view and a search condition for generating the view. This instruction may be performed by an administrator, a user, or the like, or may be performed by another node such as a view manager or a session manager that manages the upper view. As described above, in the present embodiment, a plurality of views have a hierarchical relationship, and an upper view can be constructed with reference to data covered by a 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. And instructions for search conditions, data requests, and the like.

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

  The view search unit 57 of the lower-level view manager that has received the data request in step S702 searches for a view according to the specified search condition, and acquires data according to the search condition and the view transaction ID (step S703). Here, the flow of the process of acquiring data by the lower-level view manager that has received the data request 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 (tuple) that matches the search condition set in advance for the upper view as an INSERT set. Further, the lower-level view manager stores the search condition received in step S702 in association with information that can identify the view managed by the upper-level view manager of the transmission source (step S704).

  The view data transmitting 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 has transmitted the data request (step S705). After that, the view data acquisition unit 51 of the higher-level view manager that is the transmission source of the data request acquires the view data set by receiving the transmitted data (step S706). Thereafter, processing proceeds to step S707.

  In step S707, it is determined whether data acquisition from the data store manager is necessary. The view manager determines whether or not all the data necessary for creating a view has been obtained in the processing for acquiring the view data set from the lower-level view manager up to step S706. This is because there is a possibility that there is data that is not covered by the lower view, and there is a possibility that data necessary for processing cannot be obtained from the lower view manager.

  For example, if the range of data covered by the lower view is a part of the table from which data is to be acquired, of the data included in the table, the data covered by the lower view is sent to the lower view manager. Obtained by inquiry. On the other hand, among the data acquisition target tables, data not covered by the lower view needs to be acquired from the data store manager. The specific method of the determination in step S707 is substantially the same as the method described in step S113, and thus the description is omitted.

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

  In steps S708 to S713, data (view data set) 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 condition and view transaction ID, and requests data (step S708).

  Upon receiving the data request (step S709), the data extraction unit 45 of the data store manager extracts data that matches a preset search condition based on the data set stored 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 flow of the process in which the data store manager that has received the data request obtains the data is as described with reference to FIG. 11 (in this case, the transaction ID for view is “search” in the description of FIG. 11). Target transaction ID ”). Then, the data store manager stores the search condition received in step S709 in association with information that can identify the view managed by the transmission source view manager (step S711).

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

  In steps S714 and 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 which is a data set in a predetermined format (for example, a table format, a graph format, or the like) (step). S714). When a view is generated, duplicate data is deleted from the data included in the view data set. As described above, since the view is generated using the data obtained from the data store manager or the like based on the search condition, the data obtained from the lower-level view manager in step S706 and the data store manager in step S713 , The data obtained from the same tuple may cause data duplication. For this reason, if the data acquired in step S706 and step S713 includes duplicate data related to the same tuple, the view management unit 52 deletes one of the duplicated data, Eliminate duplication.

  In the present embodiment, a method for eliminating duplication after data is acquired is adopted. However, instead of such a method, steps S701 and S708 are performed so that duplication does not occur at the time of a data request. A technique for changing the content of the transmitted data request may be adopted.

  When the view is generated, the view management unit 52 holds the generated view as a view corresponding to a preset search condition and view transaction ID (step S715). Thereafter, the processing shown in this flowchart ends.

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

  In steps S801 and S802, a data set is searched in the data store manager. The search condition used here is the search condition set for the view managed by the view manager, and is the search condition saved in step S711 in FIG. The view data generation unit 46 of the data store manager searches for an INSERT data set to which a new transaction ID is assigned using preset search conditions, and extracts changes that match the search conditions (step S801). . Further, the view data generation unit 46 searches the tuple indicated by the tuple ID included in the DELETE data set to which the transaction ID is newly added, based on the search condition, and obtains the tuple ID of the tuple having the content matching the search condition. Is specified (step S802). Thereafter, processing 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 tuple ID corresponding to the set search condition (step S805). And step S806). In the present embodiment, as a method of searching for a deleted tuple ID corresponding to the set search condition, a past INSERT data set is checked with a tuple ID in the DELETE data set of the data store manager, and a hit is performed. It is determined whether or not the set tuple matches the search condition of the view (see step S802). However, as a method of searching for a deleted tuple ID corresponding to the set search condition, other methods such as holding a list of tuple IDs sent to the view and collating with this are adopted. You may. Further, when the data store manager transmits the DELETE data set to the view manager for updating the view, all the DELETE data sets may be transmitted.

  In steps S803 and S804, the presence or absence of a search result is determined, and if no search result is obtained, a transaction ID is transmitted. As a result of the search in steps S801 and S802, if a tuple that matches the search condition is not found (NO in step S803), the data store manager replaces the transaction ID assigned to the search target data set with the transaction ID. The transaction ID is transmitted to the view manager as a transaction ID indicating the progress point of the view data set generation processing of the own node (step S804).

  Here, the view manager that is the transmission destination of the transaction ID is a view manager that holds the view corresponding to the search condition used for the search, and the view associated with the view when the search condition was saved in step S711. It is specified by referring to identifiable information. The view manager that has received the transmitted transaction ID manages the transaction ID as a transaction ID that indicates the progress point of the view data set generation process of the transmission source node. That is, the transaction ID received here is referred to in step S501 to determine a specific transaction ID.

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

  In steps S805 to S807, a data set for a view is generated in the data store manager. The view data generation unit 46 generates a view data set including the change content extracted in step S801 in the INSERT data set and the tuple ID specified in step S802 in the DELETE data set (step S805). Then, the view data transmitting unit 47 transmits the generated view data set to the view manager in association with the transaction ID (step S806). Here, the view manager that is the transmission destination is a view manager that holds a view corresponding to the search condition used for the search, and is information associated with the view when the search condition was saved in step S711 and that can identify the view. Is specified 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 point of the view data set generation processing of the transmission source node, and step S501. Will be referred to in order to determine a specific transaction ID. Thereafter, processing proceeds to step S808.

  In steps S808 and S809, the view manager searches for a data set. The search condition used here is a search condition set in a view higher than the view managed by the view manager, and is the search condition saved in step S704 in FIG. Therefore, the processing from step S808 to step S813 is not executed when the view manager does not hold the search condition of the upper view. The view data generating unit 53 of the view manager searches the INSERT data set included in the view data set received in step S807 under the preset search condition, and extracts the change content that matches the search condition. (Step S808). In addition, the view data generation unit 53 searches the tuple indicated by the tuple ID included in the DELETE data set included in the view data set received in step S807 based on the search condition, and searches the contents that match the search condition. The tuple ID of the tuple included is specified (step S809). Thereafter, processing proceeds to step S810.

  In steps S810 and S811, the presence or absence of a search result is determined, and if no search result is obtained, a transaction ID is transmitted. As a result of the search in step S808 and step S809, if no tuple that matches the search condition is found (NO in step S810), the view manager sets the transaction ID assigned to the view data set searched for. Is transmitted to the upper-level view manager as a transaction ID indicating the progress point of the view data set generation processing of the own node (step S811).

  Here, the upper-level view manager that is the transmission destination of the transaction ID is the upper-level 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. It is specified by referring to information that can identify the view. The upper-level view manager that has received the transmitted transaction ID manages the transaction ID as a transaction ID indicating the progress point of the view data set generation process of the transmission source node, and determines the specific transaction ID in step S501. refer.

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

  In steps S812 and S813, a second view data set is generated in the view manager. The view data generation unit 53 generates a second view data set including the change content extracted in step S808 in the INSERT data set and the tuple ID specified in step S809 in the DELETE data set (step S812). ). Then, the view data transmitting unit 54 transmits the generated second view data set to the upper-level view manager in association with the transaction ID (step S813). Here, the upper-level view manager that is the transmission destination is the upper-level view manager that holds the view corresponding to the search condition used for the search, and can identify the view associated when the search condition was saved in step S704. It is specified by referring to important 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 data set is used for changing the view, similarly to the other view data sets transmitted from the data store manager (see FIG. 17). In addition, the view manager that has received the transmitted second view data set uses the transaction ID received together with the view data set as a transaction ID indicating the progress point 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. Thereafter, the processing shown in this flowchart ends.

  If the view manager that has received the view data set transmitted in step S813 has a higher-level view manager, the view manager that has received the view data set performs the processing shown in steps S807 to S813. By executing, a view data set for a higher-level view manager as viewed from the view manager is generated and transmitted. In other words, the processing shown in steps S807 to S813 is executed in each view manager while passing the generated view data set from lower to higher in the hierarchy between the view managers.

  The processing illustrated 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 updating unit 55 updates the view transaction ID. Various methods can be adopted as a specific method of determining a transaction ID for a new view. For example, transaction IDs of snapshots referred to by a plurality of session managers are aggregated, and the snapshot ID is determined according to the oldest. A method such as updating may be adopted. At this time, an extremely old snapshot may rarely be referred to, but such a snapshot may be excluded from the totaling by setting a threshold value for the transaction ID or the like. When a new view transaction ID is determined, the process proceeds to step S902.

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

  According to the database system according to the present embodiment, a view is not created and changed based on a table or the like like a relational database, but a view is created and changed with reference to a change history (for example, a data set). Therefore, it is possible to reduce the processing load for creating and changing views. Further, in order to reduce the processing load related to the creation and modification of views, a technique of using a logical view having no view substance on a memory or a storage device has been conventionally proposed. Each time a view is searched, an access to the link destination (entity) of the view occurs, so that the processing load at the time of the search is not reduced. On the other hand, according to the database system according to the present embodiment, since the view exists as an entity in the memory or the storage device, the processing load at the time of the search can be reduced.

  Further, according to the database system according to the present embodiment, the processing load when performing a search in the database system using the accumulated change history (for example, a data set) as a basic part of the database is reduced by the view manager as described above. , It can be reduced. Therefore, the database management based on the accumulated data set described with reference to FIGS. 5 to 11 and 13 and the creation of the view based on the data set described with reference to FIGS. 12 and 14 to 17 are performed. By combining and changing, it is possible to achieve both a reduction in processing load associated with a change (update and deletion) in the contents of the database and a reduction in processing load at the time of retrieval. However, the database management relying on the accumulated data set and the creation and modification of a view based on the data set do not necessarily need to be used in combination, and may be individually adopted in another database system. .

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

  In the database system according to the present embodiment, rules (such as a hash function) for determining a destination data store manager to which the INSERT data set and the DELETE data set are transmitted when the content of the database is changed are determined in advance. Is also 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-described embodiment, an example in which the view update is performed at a predetermined timing (for example, periodically) has been described. However, the view update timing may be intentionally delayed. For example, when some or all of the views managed by the view management unit 52 are read into the memory of the view manager, the part of the view that is read into the memory may be changed. At this time, the view change unit 56 reflects all related view data sets up to the updated view transaction ID in the block read into the memory.

  Further, for example, the view change unit 56 may be triggered by the fact that the view managed by the view management unit 52 has been subjected to the process specified by the snapshot that is the same as or newer than the updated view transaction ID. As such, the view may be changed. When these methods are adopted, the timing of changing views is sporadic.

<Effect>
In the database system according to the present embodiment, since the contents of the database are changed by storing the change data set in the data store in association with the transaction ID, the processing load associated with the change of the contents of the database can be reduced. . In addition, in the database system according to the present embodiment, the basic part of the database does not depend on a table such as a relational database, so that 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, a view is created and changed based on the change history, so that 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 in the memory or the storage device, the processing load at the time of the search can be reduced.

Furthermore, according to the database system according to the present embodiment, by providing the view manager, it is possible to reduce the processing load of the search, to manage the database using the data set, and to create and change the view based on the data set. , It is possible to achieve both a reduction in processing load associated with a change (update and deletion) in the contents of the database and a reduction in processing load at the time of retrieval. However, database management using a data set and creation and change of a view based on the data set do not always need to be used in combination, and may be individually adopted in another database system.

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, data set generation means for generating a data set including target identification information capable of uniquely grasping a data unit to be changed, and a change content of the data unit,
Transmitting the data set to at least one of the data store management nodes, comprising:
Each of the data store management nodes,
Database management means for storing the received data set by setting a transaction identifier capable of grasping the position of the transaction in time series, and
A view data generation unit that generates a view data set including data that matches a preset search condition based on the data set stored by the database management unit;
View data transmission means for transmitting the view data set to the view management node,
The view management node includes:
A view data acquisition unit that acquires a view data set including data that matches the preset search condition from the data store management node;
A view management unit that holds a set of data included in the view data set acquired by the view data acquisition unit as a view corresponding to the preset search condition;
View search means for searching for the view according to a specified search condition,
The view management means sets, in the data included in the view data set, a set of data before a time point designated by a view transaction identifier which is a transaction identifier indicating a snapshot corresponding to the view, in advance. Held as a view corresponding to the retrieved search condition and the view transaction identifier,
Database system. The view management node includes:
View data generating means for generating a second view data set including data that matches search conditions preset for another view based on the view data set acquired by the view data acquiring means When,
A view data transmitting unit that transmits the second view data set to a view management node that manages the another view,
The database system according to claim 1. The database system includes a plurality of views having a hierarchical relationship,
The view data generating unit, based on the view data set acquired by the view data acquisition unit, manages a view higher than a view managed by a view management node including the view data transmission unit. Generate a second view data set including data that matches search conditions set in advance in the view management node,
The view data transmitting unit transmits the second view data set to the upper-level view management node,
The database system according to claim 2. The view data generation unit further generates a view data set including data that matches the preset search condition, based on the data set in which a transaction identifier newer than the view transaction identifier is set,
The view management node includes:
View transaction identifier updating means for updating the view transaction identifier,
View change means for changing the view managed by the view management means using a view data set before the time point designated by the updated view transaction identifier,
The view management means holds the view changed by the view change means as a view corresponding to the updated view transaction identifier,
The database system according to claim 1. The view change unit, when a part or all of the view managed by the view management unit is read into a memory of the view management node, a part of the view that is read into the memory. change,
The database system according to claim 4. The view change unit changes the view managed by the view management unit when a snapshot after the updated view transaction identifier becomes a target of a designated process. Do
The database system according to claim 4. The view management node includes, among the view data sets acquired by the view data acquisition unit but not reflected in the view, the view data sets up to a search target transaction identifier indicating a search target snapshot. Further comprising a view search result correction unit for correcting a search result by the view search unit.
The database system according to any one of claims 1 to 6. The view search result correction means, for a search result by the view search means,
Adding, to the search results by the view search means, changes included in the view data sets up to the search target transaction identifier among the unreflected view data sets and matching the specified search conditions. Processing,
Among the target identification information included in the view data set up to the search target transaction identifier in the unreflected view data set, the data indicated in the deletion target identification information indicating the data unit to be deleted, Exclusion processing to be excluded from the result of the additional processing;
Correcting the search result by the view search means,
The database system according to claim 7. The view search result correction unit is configured to, when a specific transaction identifier indicating a range of a view data set that is not subsequently obtained by the view data obtaining unit is older than the search target transaction identifier, the specific transaction identifier is set to the search target Waiting for the transaction identifier to be the same or a new identifier, and then performing the correction,
The database system according to claim 7. The view management node collects, from each of the nodes that generate the view data sets, a transaction identifier indicating the progress point of the view data set generation processing for each node. Determining a transaction identifier indicating a progress point as the specific transaction identifier, further comprising a specific transaction identifier determining means,
The database system according to claim 9. The target identification information is information capable of uniquely grasping 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 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,
A data set generation step of generating a data set including target identification information capable of uniquely grasping a data unit to be changed when the content of the database is changed, and a change content of the data unit;
Transmitting the data set to at least one of the data store management nodes, a data set transmission step,
Each of the data store management nodes,
A database management step of storing the received data set by setting a transaction identifier capable of grasping the position of the transaction in time series, and
A view data generation step of generating a view data set including data that matches a preset search condition based on the data set accumulated in the database management step;
Transmitting the view data set to the view management node, and performing a view data transmission step;
The view management node includes:
A view data set including data that matches the preset search condition, a view data acquisition step of acquiring from the data store management node,
A view management step of retaining 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;
Performing a view search step of searching for the view according to specified search conditions;
In the view management step, among the data included in the view data set, a set of data before a time point designated by a view transaction identifier which is a transaction identifier indicating a snapshot corresponding to the view is set in advance. Held as a view corresponding to the retrieved search condition and the view transaction identifier,
Method. In 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, data set generation means for generating a data set including target identification information capable of uniquely grasping a data unit to be changed, and a change content of the data unit,
Transmitting the data set to at least one of the data store management nodes, and functioning as a data set transmission unit;
Each of the data store management nodes,
Database management means for storing the received data set by setting a transaction identifier capable of grasping the position of the transaction in time series, and
A view data generation unit that generates a view data set including data that matches a preset search condition based on the data set stored by the database management unit;
The view data set, and view data transmission means for transmitting to the view management node, and function as,
The view management node,
A view data acquisition unit that acquires a view data set including data that matches the preset search condition from the data store management node;
A view management unit that holds a set of data included in the view data set acquired by the view data acquisition unit as a view corresponding to the preset search condition;
Functioning as view search means for searching the view according to specified search conditions;
The view management means sets, in the data included in the view data set, a set of data before a time point designated by a view transaction identifier which is a transaction identifier indicating a snapshot corresponding to the view, in advance. Held as a view corresponding to the retrieved search condition and the view transaction identifier,
program.

Images