WO2013132628A1 - データベースの管理方法 - Google Patents

データベースの管理方法 Download PDF

Info

Publication number
WO2013132628A1
WO2013132628A1 PCT/JP2012/055923 JP2012055923W WO2013132628A1 WO 2013132628 A1 WO2013132628 A1 WO 2013132628A1 JP 2012055923 W JP2012055923 W JP 2012055923W WO 2013132628 A1 WO2013132628 A1 WO 2013132628A1
Authority
WO
WIPO (PCT)
Prior art keywords
master node
database
lower master
update
node
Prior art date
Application number
PCT/JP2012/055923
Other languages
English (en)
French (fr)
Inventor
山田 浩之
Original Assignee
株式会社Murakumo
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社Murakumo filed Critical 株式会社Murakumo
Priority to PCT/JP2012/055923 priority Critical patent/WO2013132628A1/ja
Priority to EP15162210.7A priority patent/EP2933739B1/en
Priority to EP12870808.8A priority patent/EP2824576B1/en
Priority to JP2014503377A priority patent/JP5960798B2/ja
Publication of WO2013132628A1 publication Critical patent/WO2013132628A1/ja
Priority to US14/478,610 priority patent/US10102263B2/en
Priority to US16/117,860 priority patent/US11151157B2/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • G06F16/211Schema design and management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2308Concurrency control
    • G06F16/2336Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
    • G06F16/2343Locking methods, e.g. distributed locking or locking implementation details

Definitions

  • the present invention relates to a database management method, and more particularly to a database management method in which a plurality of master nodes are hierarchically connected by a network.
  • Patent Document 1 Japanese Patent Laid-Open No. 2006-293910
  • Patent Document 2 International Publication No. 2010/106991 proposes a 1-to-N (N is a positive integer) master-slave data synchronization method.
  • the transaction log is a technology that realizes high-speed operation while maintaining the persistence of changes by recording the history of changes made to the database in an area different from the recording area of the database. is there.
  • Patent Document 1 focuses on realizing a replication system using a transaction log
  • Patent Document 2 transmits a request message to a master node from a slave node that has received a search instruction from a client.
  • the master node requests a transaction log up to the latest version for updating the master database, and the master node that has received the request sends the transaction log to the slave node.
  • the transaction log is transmitted, and the slave node updates its replica database by referring to this log.
  • the node configuration is a network configuration including a plurality of mirror nodes for a single master node.
  • the mirror node does not independently execute data update commands (INSERT, UPDATE, DELETE), so it was only necessary to update its own database by referring to the transaction log from the master node.
  • the present inventor has made the present invention in view of such points, and the master node is constructed hierarchically, and the hierarchical structure is used to update the plurality of tables of the lower master node. Even in this case, it is a technical problem to realize a database management method capable of reliably and efficiently updating a database between nodes.
  • Claim 1 of the present invention is a method for managing a write-once database having hierarchically upper and lower master nodes capable of record update, and an update command for a plurality of database tables is generated at a predetermined lower master node.
  • the database processing unit of the lower-level master node writes to the upper-level master node a table-by-table writing set that combines a combination of a shadow copy and a heap tuple map for each table of the database expanded in its own memory.
  • the heap tuple map for each table in the write-by-table set received from the lower master node is compared with its own database and registered as a target.
  • the corresponding row of the corresponding table in the database is another table A step of verifying whether or not the writing set is updated, and when the updating is performed, the entire writing set by table transmitted from the predetermined lower master node is aborted, and when the updating is not performed. Updating the corresponding row of the corresponding table in the database of the upper master node using the shadow copy for each table in the writing set for each table, and generating an update record including the table number of the upper master node as a transaction log And the step of delivering the transaction log to a lower-level master node including the lower-level master node of the transmission source, and the transaction log processing unit of the lower-level master node is based on the transaction log received in the corresponding table of its own database. Update the corresponding row of A database management method comprising the steps.
  • Claim 2 of the present invention is a method for managing a write-once database having hierarchically upper and lower master nodes capable of record update, and an update instruction for a plurality of database tables is generated at a predetermined lower master node.
  • the database processing unit of the lower master node generates a shadow copy including the table number of the database expanded in its own memory and a heap tuple map as a single integrated writing set for the upper master node.
  • the heap tuple map in the integrated writing set received from the lower master node is compared with its own database, and the table number of the database registered as the target is supported. The corresponding row of the table to be updated is updated with another integrated write set, etc.
  • the database management method includes a step of distributing to a node and a step in which the transaction log processing unit of the lower master node updates a corresponding row of a corresponding table of its own database based on the received transaction log.
  • Claim 3 of the present invention is the database management method according to claim 1, wherein the shadow copy for each table included in the write-by-table set in the lower-level master node is composed of only new additional rows.
  • a fourth aspect of the present invention is the database management method according to the second aspect, wherein the shadow copy of the integrated writing set in the lower master node is configured by only a new additional row.
  • the database of the lower master node when a search process is performed on a table of a master database of the lower master node in a stage where the writing set for each table is generated in the lower master node, the database of the lower master node
  • the processing unit refers to the step of referring to the master database table, and refers to the heap tuple map corresponding to the table to determine whether or not the corresponding row number is entered in the search process. If the table of the master database is directly searched for and the corresponding row number is entered, it is determined whether the entry is a delete instruction or an update instruction. If the entry is a delete instruction, the corresponding row number is searched. If it is an update instruction, the table in the heap tuple map It is a management method of a database according to claim 1 or 3 to perform the step of the search target entry shadow copy that corresponds to the table.
  • the database process of the lower master node is performed.
  • the section refers to the table of the master database, and refers to the heap tuple map to determine whether or not the corresponding row number of the corresponding table is entered in the search process.
  • the relevant line number is entered as a direct search target, it is determined whether the entry is a delete instruction or an update instruction. If the entry is a delete instruction, the relevant line number is excluded from the search target and updated. If so, search for a shadow copy entry in the heap tuple map. It is a management method of a database according to claim 2 or 4 to execute a step of the elephants.
  • the database of the lower master node when a search process is executed on a table of a master database of the lower master node in a stage where the writing set for each table is generated in the lower master node, the database of the lower master node
  • the processing unit refers to the table of the master database, refers to the entire heap tuple map corresponding to the table, extracts the entry of the row number to be searched, and the row number entered.
  • the shadow copy corresponding to the table is referenced, the row number of the entry added in the shadow copy is referenced, and only that row number is selected as the search target.
  • the database process of the lower master node is performed.
  • the section refers to the table of the master database, refers to the entire heap tuple map, extracts an entry having a table number and a row number to be searched, and determines the row number entered. Excluding all deleted items from the search target, referring to the shadow copy, and referring to the row number of the entry of the search target table added in the shadow copy, 5.
  • the database management method according to claim 2 or 4 wherein the step to be searched is executed.
  • the region of the back-end memory (BEM) in the lower master node that registers them is at least the upper
  • a transaction log processing unit that executes an update command based on transaction data distributed from a master node can be referred to, and the transaction log processing unit refers to the back-end memory (BEM) and tries to update by this update command.
  • the heap tuple map (HTM) It is a management method of a database according to any one of claims 1 to 4 for aborting the Nzakushon.
  • Claim 10 of the present invention is a write-once database management method that hierarchically has upper and lower master nodes that can be updated, and in a session of any lower master node, The step of registering the table information to be updated in the database of the lower master node in the writing set and transmitting it to the upper master node, and when the lock acquisition command for the database table is generated in the upper master node, Informing the lower master node of the lock acquisition information and holding the lock acquisition information in the upper master node; in the upper master node, the table information in the write set received from the lower master node and the Compare with the lock acquisition information held in Sometimes, in the step of aborting the write set and in the lower master node that has received the lock acquisition information from the upper master node, if there is a transaction that conflicts with the lock acquisition information, the lower master node Is a write-once database management method comprising: a step of discarding a target table, and a step of acquiring a lock of a target table based on lock acquisition information from the
  • a multi-master node is constructed hierarchically, and a shadow copy and a heap tuple map developed in its own memory are transmitted as a writing set from a lower master node to an upper master node.
  • the upper master node that has received this verifies whether the row has already been updated by another writing set, and updates the database using the shadow copy and the heap tuple map if it has not been updated.
  • Process. By sending the update record as a transaction log to the lower-level master node, it is possible to efficiently update the database from the lower-level master node to the upper-level master node and from the higher-level master node to the lower-level master node under control efficiently. Become. This is particularly effective when a plurality of tables are updated in the upper master node and the lower master node.
  • the conceptual diagram which shows the database structure of the hierarchical master node which is Embodiment 1 of this invention Functional block diagram of a master node according to the first embodiment Hardware block diagram of master node of embodiment 1
  • HTM Heap tuple map
  • and shadow copy (SC) shadow copy
  • Explanatory drawing in the case of adding a table number in a single writing set (integrated writing set) in a modification of the first embodiment Diagram showing transaction log corresponding to multiple tables
  • Functional block diagram of a master node according to the second embodiment The figure which shows the relationship between the database page of the subordinate master node of Embodiment 2, and the write set (Heap tuple map (HTM) and shadow copy (SC)) produced
  • Explanatory drawing which shows the transaction log produced
  • Explanatory drawing when creating a writing set for each table in the second embodiment Explanatory drawing when recording table information during writing set in the second embodiment
  • FIG. 1 shows the structure of the hierarchical master node of this embodiment.
  • the node configuration has hierarchically lower master nodes (MS201, MS202... MS20n, MS301, MS302... MS30n) below the upper master node (MS101).
  • Each node (information processing apparatus) has a database.
  • the upper master node (MS101) has a slave, but other lower master nodes may have slaves.
  • the update management technology described in PCT / JP2010 / 054311 by the present applicant prior application related to Patent Document 2 by the present applicant
  • Patent Document 2 by the present applicant
  • FIG. 2 is a functional block diagram of the lower master node (MS201), but the upper master node (MS101) also has the same function.
  • the database processing unit (11b) when a database update command is input from the client (CL), the database processing unit (11b) writes a set on the back-end memory (BEM) built on the main memory (MM). Is generated. As shown in FIG. 4, this writing set includes a heap tuple map (HTM) and a shadow copy (SC).
  • HTM heap tuple map
  • SC shadow copy
  • the database processing unit 11b does not write directly to the master database (11a) while referring to the master database (11a), but stores the write set generated in the back-end memory (BEM) as a communication module ( 11d) to the higher master.
  • FIG. 3 shows a hardware configuration for realizing the above functions.
  • the upper master node (MS101) is a general-purpose information processing device, and a large-scale storage device (HD) and a master database (11a) connected by a bus (BUS) around a central processing unit (CPU) and a main memory (MM). ), And a communication interface (I / O) (communication module 11d) for communication with the outside.
  • a client terminal (CL) is connected via the bus (BUS) or communication interface (I / O), and receives commands.
  • the master database (11a) may be constructed on a large-scale storage device (HD) or may be constructed on a main memory (MM). In short, the construction location of the master database (11a) is not limited.
  • An application program is stored in the large-scale storage device (HD) together with an operating system (OS), and the program is stored in a central processing unit (CPU) via a bus (BUS) and a main storage device (MM). ) Is read and sequentially executed, so that the function as the master node is realized.
  • the subordinate master nodes MS201, MS202... MS20n, MS301, MS302... MS30n
  • MS201, MS202... MS20n MS301, MS302... MS30n
  • the master database (11a) is composed of line numbers, instruction contents, and pointers, and is a write-once database in which line numbers are added each time a new instruction is issued from the client terminal (CL).
  • CL client terminal
  • HTM heap tuple map
  • SC shadow copy
  • HTM heap tuple map
  • the original line number (ctid) and the line number (sctid) of the new line are associated and registered.
  • a heap tuple map (HTM) is additionally generated every time the database is updated. Note that since the line number in which the instruction content (sc1) of line number 5 is written is still unknown at this stage, a new instruction (sc1) is written in sctid.
  • the database processing unit (11b) of the lower level master node (MS201) uses the line number 4 to which the DELETE instruction is applied by generating the heap tuple map (HTM) and the old line number 5 to which the UPDATE instruction is applied. Since it is already known that the command is deleted, only a new command (sc1) may be written as the shadow copy (SC).
  • the writing set generated in this way is transmitted from the lower master node (MS201) to the upper master node (MS101).
  • the transaction log processing unit (11c) To start transaction log generation. Then, the heap tuple map (HTM) is read from the received writing set and compared with its own master database (11a). Here, it is verified whether or not the contents of the target tuple (here, line numbers 4, 5, and 7) are updated on the master database (11a). In FIG. 5, since the line numbers 4 to 6 are not updated, a deletion pointer is assigned to the line number 4 and a deletion pointer is also assigned to the old number 5 to be rewritten. Then, a new command (sc1) is written in the new line number 7.
  • sc1 is written in the new line number 7.
  • the heap tuple map (HTM) in the writing set from the lower master node (M201) is compared with its own database, and the row is already updated by another writing set in the upper master node (M201). If so, the processing by the writing set is aborted.
  • FIG. 6 is an example of a transaction log generated by the transaction log processing unit (11c) when the master database (11a) of the upper master node (MS101) is updated as described above.
  • This transaction log is a file in which at least instructions and transaction contents (line numbers and execution process contents corresponding thereto) are continuously recorded in time series.
  • a log in which the instruction number and the line number are paired is sequentially generated. For example, line number 4 is deleted first as a DELETE instruction (D1) (D14), line number 5 is then deleted as UPDATE instruction (U1), line number 7 is added (U157), and finally these commit instructions Issue (XC1).
  • D1 DELETE instruction
  • U1 UPDATE instruction
  • U157 U157
  • XC1 commit instructions Issue
  • This transaction log is distributed from the communication module (11d) to the lower master node (MS201) of the transmission source and all lower master nodes (MS202 ... MS20n, MS301, MS302 ... MS30n).
  • the lower master node that receives the transaction log replicates the transaction log to its own database.
  • the transaction log processing unit (11c) is activated and this transaction log is stored in its own master database ( Replication to 11a). As a result, deletion pointers are assigned to the line numbers 4 and 5, and a new line number 7 is added.
  • the database is managed in a unified manner by replication of transaction logs transmitted from the upper master node in the lower master node.
  • FIG. 7 and 8 correspond to such a plurality of tables.
  • FIG. 7 shows a combination of heap tuple maps (HTM) and shadow copies (SC) for each table (T1 to T4 in the figure). It shows a method of transmitting to a higher-order master node as a written set (hereinafter referred to as “table-by-table write set”).
  • FIG. 8 shows the table number in the combination of the heap tuple map (HTM) and the shadow copy (SC), and sends it to the upper master node as a single writing set (hereinafter referred to as “integrated writing set”). Shows how to do.
  • each of the tables T1 and T2 is updated at a predetermined lower master node by a certain transaction, for example, a heap tuple map (HTM) and a shadow copy (SC) for each of the tables T1 and T2 Are generated, and this bundle becomes a table-specific writing set.
  • a heap tuple map HTM
  • SC shadow copy
  • the upper master node When the table-specific writing set is received by the upper master node, the upper master node reflects the contents of the table writing set in its own database. At this time, first, the own database is accessed based on the heap tuple map (HTM) for each table, and the tuple is already in another table-specific writing set (including a normal writing set or an integrated writing set described later). To check if it has been updated. At this time, if not updated, the shadow copy for each table in the writing set for each table is referred to and the tuple is updated. On the other hand, when it is detected that the table has already been updated, the entire writing set for each table is aborted.
  • HTM heap tuple map
  • the integrated write set in which the table number is described in the combination of the heap tuple map (HTM) and the shadow copy (SC) shown in FIG. 8 is applied to the upper master node. That is, when the integrated write set of FIG. 8 is received by the upper master node, for each entry of the heap tuple map (HTM), the corresponding row of the table corresponding to the table number included in the entry is already another integrated write. It is checked whether it has been updated by a set or the like (normal writing set or the above-mentioned writing set by table). At this time, if not updated, the tuple of the table is updated with reference to the shadow copy of the integrated writing set.
  • a set or the like normal writing set or the above-mentioned writing set by table
  • the entire integrated writing set is aborted. For example, when the corresponding row of the heap tuple map (HTM) of table T1 has already been updated by another integrated writing set or the like (including the normal writing set or the above-mentioned table-specific writing set), this integrated document The entire set is aborted.
  • HTM heap tuple map
  • the upper master node when the upper master node is updated by the table-specific writing set or the integrated writing set (in the case of FIGS. 7 and 8) including a plurality of table information in the lower master node, it is generated in the upper master node.
  • the transaction log also has a format with a table number added.
  • FIG. 9 shows an example.
  • the format of the transaction log is “XB1”, “D114”, “U1257”, “XC1”, which have the following meanings.
  • a log in which the command number, table number, and row number are combined is sequentially generated. For example, first, the line number 4 of the table 1 is deleted as the DELETE instruction (D1) of the transaction 1 (D114), and then the line number 5 of the table 2 is deleted as the UPDATE instruction (U1) of the transaction 1. Add (U1257) and finally issue these commit instructions (XC1).
  • D1 DELETE instruction
  • U1 UPDATE instruction
  • This transaction log is distributed from the communication module (11d) to the lower master node (MS201) of the transmission source and all lower master nodes (MS202 ... MS20n, MS301, MS302 ... MS30n).
  • the lower master node that receives the transaction log replicates the transaction log to its own database.
  • the transaction log processing unit (11c) is activated and the transaction log is stored in its own master database ( Replication to 11a).
  • a deletion pointer is assigned to the line number 4 of the table 1 as the transaction 1
  • a deletion pointer is assigned to the line number 5 of the table 2
  • a new line number 7 is added.
  • the processing when a master database update command is generated in a lower master node is a heap tuple map (HTM, heap file) and shadow copy on the back-end memory (BEM).
  • SC is generated (in the case of a plurality of tables, the table-specific writing set shown in FIG. 7 or the integrated writing set shown in FIG. 8) is generated by the master database (MS101).
  • the update instruction is generated, it is not necessary to notify the upper node, and therefore the writing set is not generated. That is, in such a case, the upper node (MS 101) writes update data directly to the master database (11a) as shown in the left diagram of FIG.
  • a transaction log shown in FIG. 9 is generated. This transaction log is distributed to the lower master node, and the lower master node receiving the transaction log replicates the transaction log to its own master database.
  • the database processing unit (11b) refers to the heap tuple map (HTM) after referring to the master database (11a). Then, it is checked whether or not the retrieval relevant line number is entered on the heap tuple map (HTM). If there is an entry, it is determined whether the entry is deleted or updated. If the entry is updated, the shadow copy (SC) entry (sc1) is further searched with reference to the shadow copy (SC). .
  • the database processing unit (11 b) uses the heap in the writing set on the back-end memory (BEM) built on the main memory (MM).
  • the search target is line number 4
  • the database processing unit (11b) refers to the heap tuple map (HTM) in the writing set, the corresponding line (line number 4). Detect that is entered.
  • the database processing unit (11b) refers to the heap tuple map (HTM) and detects that the corresponding line (line number 4) has been deleted.
  • the database processing unit (11b) does not set the corresponding line as the search target.
  • the shadow copy (SC) corresponding to the corresponding line (line number 5) is referred to the heap tuple map (HTM) as described above. It detects that the entry (sc1) has been created.
  • the database processing unit (11b) may refer to the shadow copy (SC) and search for the entry (sc1) in which the line number 5 is rewritten.
  • HTM heap tuple map
  • SC shadow copy
  • the heap tuple map (HTM) corresponding to the table is referenced to check whether or not the corresponding row number has been entered. If no entry exists, the corresponding row in the search target table of the master database is set as the search target. If there is an entry, it is determined whether the entry is deleted or updated. If the entry is updated, the shadow copy (SC) entry is further searched with reference to the shadow copy (SC). In the case of deletion, the corresponding line is not searched.
  • HTM heap tuple map
  • the entry assigned the table number corresponding to the search target table is extracted from the heap tuple map (HTM) and shadow copy (SC) entries and used.
  • HTM heap tuple map
  • SC shadow copy
  • the entry of the heap tuple map (HTM) corresponding to the search target table extracted above is referred to and it is checked whether or not the search corresponding row number is included. If no entry is included, the corresponding row in the search target table of the master database is set as the search target. If the entry is included, it is determined whether the entry is deleted or updated. If the entry is updated, the entry of the shadow copy (SC) extracted as described above is further referred to as a search target. In the case of deletion, the corresponding line is not a search target.
  • HTM heap tuple map
  • the database processing unit (11b) first refers to the master database (11a) and then refers to the entire heap tuple map (HTM). At this time, it is checked whether or not the search target line has been entered, and all the entered line numbers (here, line numbers 4 and 5) are deleted (excluded from the search target). ). Next, the database processing unit 11b refers to the shadow copy (SC), refers to the added entry (sc1) in the shadow copy, and sets this as a search target.
  • SC shadow copy
  • the entries with the table number corresponding to the search target table are extracted from the entries of the heap tuple map (HTM) and the shadow copy (SC), and these entries are used. The same processing is performed.
  • a write set (heap tuple map (HTM) and shadow copy (SC)) is generated in the lower master node
  • HTM write set
  • SC shadow copy
  • BEM back-end memory
  • the write set inconsistent with the update instruction is referred to by the lower master node by referring to the write set on the back-end memory (BEM).
  • the transaction log processing unit 11c refers to the back-end memory (BEM)
  • the corresponding row to be updated by this update instruction is included in the heap tuple map (HTM)
  • a transaction generating the heap tuple map (HTM) is aborted.
  • the writing set generated in the lower master node corresponds to a plurality of tables (shown in FIGS. 7 and 8).
  • a write-by-table set (a bundle of heap tuple maps (HTM) and shadow copies (SC)) is generated in the lower master node, these are stored in the lower master node. May be registered on the back-end memory (BEM), and these areas may be referred to by two or more processes (specifically, a replication process and a table-specific write set generation process).
  • BEM back-end memory
  • these areas may be referred to by two or more processes (specifically, a replication process and a table-specific write set generation process).
  • the case of the integrated writing set shown in FIG. 8 is the same as the case of the single table configuration.
  • the table number is registered in the heap tuple map, when the integrated write set (heap tuple map (HTM) and shadow copy (SC)) is generated, these are used as the back end in the lower master node.
  • the processing after registration on the memory (BEM) is the same as in the case of a single table configuration.
  • HTM heap tuple map
  • FIG. 10 shows the structure of the hierarchical master node of this embodiment.
  • a node configuration having a middle-order master node (MS201, MS202... MS20n) and a lower-order master node (MS301, MS302... MS30n) hierarchically under the upper master node (MS101). It has become.
  • Each node (information processing apparatus) has a database.
  • the upper master node (MS101) has a slave (SL), but other middle / lower master nodes may have slaves.
  • the update management technique described in Japanese Patent Laid-Open No. 2006-293910 published prior application by the present applicant
  • the present applicant may be applied to update the database between the two. it can.
  • PCT / JP2011-0608057 (unpublished application by the present applicant) is a hierarchical multi-master node. If the update command is also executed in the lower-level master node in the configured database, pay attention to the fact that the consistency of all the lower-level nodes cannot be maintained only by referring to the transaction log from the upper level. The feature was that the shadow copy of the database expanded on the memory and the heap tuple map were sent as a writing set to the upper master node to update the upper master node. However, these prior arts do not assume a case where the table itself is deleted or the table structure is changed at the upper master node.
  • This embodiment is a technique for maintaining consistency in the entire multi-master node structure by utilizing a database lock function in such a case. This will be described below.
  • FIG. 11 is a functional block diagram of the intermediate master node (MS201) and the lower master node (MS301), but the upper master node (MS101) also has the same function.
  • the database processing unit (11b) when a database update command is input from a client (CL), the database processing unit (11b) performs a write set on a back-end memory (BEM) built on a main memory (not shown). Generate.
  • This writing set is composed of a heap tuple map (HTM) and a shadow copy (SC) as shown in FIG.
  • HTM heap tuple map
  • SC shadow copy
  • the database processing unit 11b does not write directly to the master database (11a) while referring to the master database (11a), but stores the write set generated in the back-end memory (BEM) as a communication module ( 11d) to the upper master.
  • the generation / transmission of such a writing set is the same in the intermediate master nodes (MS201, MS202... MS20n) and the lower master nodes (MS301, MS302... MS30n).
  • a lock acquisition instruction is executed for that table and the corresponding action is taken. Hold the lock number to be used. For example, when lock acquisition instructions for table 1, table 3, table 2, table 4,... Are sequentially executed, the lock number for table 1 is 1, the lock number for table 3 is 2, and the lock number for table 2. No. 3 and the lock number for the table 4 is No. 4, and these lock numbers (1 to 4) are held.
  • a lock acquisition command for a database table is generated in the upper master node
  • the lower master node that has received the lock acquisition information from the upper master node checks whether or not there is a transaction competing with the lock acquisition information, for example, a transaction updating the table targeted by the lock acquisition information.
  • the lock acquisition information generated at the upper master node is given priority, and the transaction at this lower master node is discarded.
  • the transaction conflict is not limited to this.
  • the lock acquisition information notified from the upper master node is the lock acquisition information acquired when the table is deleted, there is a transaction that simply refers to the corresponding table in the lower master node. Even so, since the contention is in conflict with the lock acquisition information, the transaction in such a lower master node is discarded.
  • a transaction log (see FIG. 14) storing the lock acquisition information is generated.
  • the transaction log shown in the figure means that an instruction starts with XB1, locks table 1 with LT1, deletes the table 1 with DT1, and commits with XC1.
  • Such a group of instructions is repeatedly stored in the transaction log.
  • a sequential number is assigned and managed for each lock acquisition information.
  • LT1 is for table 1 and is the first lock acquisition instruction
  • LT3 is for table 3 and is the second lock acquisition instruction
  • LT2 is for table 2 and is the third lock acquisition instruction. That is, in this example, lock acquisition numbers 1 to 4 are sequentially assigned and managed in the order of LT 1 ⁇ LT 3 ⁇ LT 2 ⁇ LT 4.
  • LSN log sequence number assigned to each log.
  • the transaction log is transmitted from the upper master node (MS101) to the middle / lower master nodes (MS201, MS202, MS20n, MS301, MS302, MS30n,).
  • each middle / lower master node Upon receiving the transaction log, each middle / lower master node replicates the contents of the transaction log to its own database.
  • the lock acquisition commands LT1, LT3, LT2, and LT4 are sequentially executed to set the table in its own shared memory to the exclusive lock state, and the other master node and other master nodes can Limit memory access by transactions.
  • a transaction that conflicts with the lock acquisition instruction for example, a transaction that updates the table targeted by the lock acquisition instruction is checked, and such a transaction exists.
  • the lock acquisition command generated in the upper master node is given priority, the transaction in the lower master node is discarded.
  • FIG. 12 shows the relationship between the master database (11a) in the lower master node (MS301) and the writing set.
  • the master database (11a) in the subordinate master node is composed of line numbers, instruction contents, and pointers, and a write-once type in which line numbers are added each time a new instruction is issued from the client terminal (CL). It is a database.
  • line number 4 is deleted (DELETE) and line number 5 is rewritten with new instruction contents (UPDATE to sc1) is shown.
  • HTM heap tuple map
  • the original line number (ctid) and the line number (sctid) of the new line are associated and registered.
  • a heap tuple map (HTM) is additionally generated every time the database is updated. Note that since the line number in which the instruction content (sc1) of line number 5 is written is still unknown at this stage, a new instruction (sc1) is written in sctid.
  • the database processing unit (11b) of the lower master node (MS301) uses the line number 4 to which the DELETE instruction is applied by generating the heap tuple map (HTM) and the old line number 5 to which the UPDATE instruction is applied. Since it is already known that the command is deleted, only a new command (sc1) may be written as the shadow copy (SC).
  • Such a writing set is created for each table as shown in FIG. 16, but is related to the row number (ctid) of the heater pull map (HTM) in a single writing set as shown in FIG.
  • the table number (T) may be registered.
  • the aforementioned node lock number (NLKN) is also stored in the writing set. As described above, this node lock number (NLKN) is stored in the lock acquisition command (LT1, LT3, LT2, LT4) stored in the transaction log (see FIG. 14) distributed (notified) from the upper master node (MS101). This is the maximum value of the lock acquisition number executed correspondingly.
  • the lower level master node (MS301) receives the transaction log as shown in FIG. 14, and the third lock based on the transaction log lock acquisition command (LT1, LT3, LT2, LT4).
  • the writing set generated in this way is transmitted from the lower master node (MS301, MS302) to the upper master node (MS101).
  • the writing set passes through the intermediate master node (MS202) in the meantime, but the intermediate master node (MS202) does not perform any processing on the writing set.
  • the database processing unit 11b central processing unit (CPU)
  • the database processing unit 11b central processing unit (CPU)
  • the database processing unit 11b central processing unit (CPU)
  • it reads the heap tuple map (HTM) therefrom.
  • HTM heap tuple map
  • FIG. 12 it is verified whether or not the contents of the target tuple (here, line numbers 4, 5, and 7) are updated on the master database (11a).
  • line numbers 4 to 6 are not updated, a deletion pointer is assigned to line number 4 and a deletion pointer is also assigned to old number 5 to be rewritten. Then, a new command (sc1) is written in the new line number 7.
  • not all writing sets are compared with the master database (11a). That is, prior to the comparison step described above, the node lock number (NLKN) stored in the writing set is read, and the lock acquisition information corresponding to the lock number larger than the node lock number (NLKN) is referred to. It is verified whether the lock acquisition information and the table to be corrected by the write set are in conflict. If there is a conflict, the writing set is aborted and the writing set is excluded from the comparison target. The reason for such verification is that although the lock is acquired in the upper master node (MS101), the tuple is updated in the lower master node based on the table before the lock is acquired.
  • the upper master node (MS101) When the information reaches the upper master node (MS101) as a writing set and the table including the tuple is updated, the upper master node (MS101) changes or deletes the table structure during the lock acquisition. This is because the consistency of the master database (11a) is lost due to contention.
  • the lock acquisition result information corresponding to the lock acquisition command replicated in the transaction log is transmitted via the intermediate master node (MS202).
  • a mechanism notified to the node (MS 101) will be described with reference to FIG.
  • the lock acquisition commands (LT1, LT3, LT2, LT4%) Stored in the transaction log are replicated sequentially to obtain the lock acquisition result information.
  • management may be performed using lock acquisition command numbers assigned in the order of lock acquisition commands. That is, the lock acquisition command number of the lock acquisition command (LT1) of Table 1 is “1”, the lock acquisition command number of the lock acquisition command (LT3) of the next table 3 is “2”, and the lock acquisition command of the next table 2 ( The lock acquisition command number of LT2) is “3”, and the lock number of the lock acquisition command (LT4) of the next table 4 is “4”.
  • the maximum value of the lock acquisition command number that acquired the lock is managed by the node lock number (NLKN).
  • the node lock number (NLKN) is transmitted from each lower master node (MS301, MS302) to the upper middle master node (MS202).
  • the upper master node (MS 101) recognizes that a lock acquisition command having a lock number equal to or smaller than the cluster lock number has been acquired.
  • the node lock number (NLKN) of the lower master node (MS301, 302) stored in the writing set is as follows.
  • the lock acquisition result information (node lock number: NLKN) executed in the lower master node (MS301, 302) reaches the upper master node (MS101) while updating the tree lock number (TLKN) of the middle node.
  • NLKN node lock number
  • the processing efficiency is greatly reduced due to the arrival delay.
  • NLKN 2
  • the cluster lock number (CLKN) cannot take a large value indefinitely. All write sets must be checked.
  • the present invention has been described based on the embodiments, the present invention is not limited to this.
  • a three-layer structure (FIGS. 10, 15, and 16) of an upper master node, a middle master node, and a lower master node is illustrated. It may be of a structure. Further, the intermediate master node may be two or more layers.
  • the embodiment has been described in which the node lock number (NLKN) is notified to the middle and upper master nodes, and the tree lock number (TLKN) and the cluster lock number (CLKN) are sequentially updated.
  • the upper master node (MS101) assigns the node lock number (NLKN) included in the write set transmitted from the intermediate master node (MS201, MS202) or the lower master node (MS301, MS302) to the lower master / middle respectively.
  • the minimum value of all the node lock numbers (NLKN) may be regarded as the cluster lock number (CLKN).
  • the node lock number (NLKN) is assigned to the middle / upper master separately from these write sets. Since it is not necessary to notify the node and update each tree lock number (TLKN) while transmitting to the upper layer, the notification system can be simplified. On the other hand, in this method, since the upper master node (MS101) has to perform node lock number (NLKN) counting work from all writing sets, the load increases.
  • the present invention can be used for a database management system having a multi-master node structure having a hierarchical structure.

Landscapes

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

Abstract

 マスタノードを階層的に構築するとともに、一つのトランザクションが複数のテーブルを更新するような場合にもそのデータベースの更新を効率的に行うことのできるデータベースの管理方法を実現する。下位マスタノードから上位マスタノードに対しては、自身のデータベースのシャドウコピーと自身のメモリ上に展開されたヒープタプルマップとの組み合わせの束ををテーブル別書込セットとして送信し、これを受信した上位マスタノードでは、当該更新が既実行であるか否かを検証してその更新記録をテーブル番号を含むトランザクションログとして下位マスタノードに送信することで、下位マスタノードから上位マスタノード、さらに上位マスタノードから配下の下位マスタノードに対して効率的に矛盾のないデータベース更新が可能となる。

Description

データベースの管理方法
 本発明は、データベースの管理方法、特に複数のマスタノードがネットワークにより階層的に接続されているデータベースの管理方法に関する。
 本出願人は、トランザクションログを用いてデータベースを管理する技術に着目し、特開2006-293910号公報(特許文献1)において、1対1のマスタ・スレーブ方式のデータ同期方法について提案し、さらにその後国際公開第2010/106991号(特許文献2)において、1対N個(Nは正整数)のマスタ・スレーブ方式のデータ同期方法の提案を行っている。
 ここで、トランザクションログとは、データベースに加えられた変更の履歴を、データベースの記録領域とは異なる領域に記録することにより、変更の永続性を維持しながら同時に操作の高速性を実現する技術である。
 特に特許文献1は、トランザクションログを利用してレプリケーションシステムを実現する点に着目しており、一方特許文献2は、クライアントより検索指示を受領したスレーブノードがマスタノードにリクエストメッセージを送信し、所定時間以内にマスタノードから返信メッセージを受領しなかったときに、マスタノードに対してマスタデータベースの更新にかかる最新バージョンまでのトランザクションログを要求し、該要求を受領したマスタノードは、スレーブノードへ該トランザクションログを送信し、このログを参照してスレーブノードは自身のレプリカデータベースを更新するものであった。
特開2006-293910号公報 国際公開第2010/106991号
 ところで、前記特許文献2では、そのノード構成が単一のマスタノードに対して複数のミラーノードを備えたネットワーク構成であることが前提だった。
 そのためミラーノードが独自にデータ更新命令(INSERT、UPDATE、DELETE)を実行することはないため、マスタノードからのトランザクションログを参照して自身のデータベースをアップデートしてやればよかった。
 一方、データベースの多様化・複雑化にともなって、マスタノードを複数有する所謂マルチマスタ方式が注目されるようになってきている。この点について、マスタノード同士に対称性があるネットワーク構成(マスタノード同士が並列関係にあるとき)では、マスタノード間の更新情報に順位付けを行い、マスタノード間の同期をとるための理論等が提案されているが全ノードの同期をとるための手続きが複雑となり、競合時の解決策が現実的でなかった。
 本発明者はこのような点に鑑みて本発明をなし得たものであり、マスタノードを階層的に構築するとともに、その階層構造を利用して下位マスタノードの複数テーブルで更新が行われた場合でもノード間のデータベースの更新を確実かつ効率的に行うことのできるデータベースの管理方法を実現することを技術的課題とする。
 本発明は、前記課題を解決するために、以下の手段を採用した。
 本発明の請求項1は、レコード更新が可能な上位と下位のマスタノードを階層的に有する追記型データベースの管理方法であって、所定の下位マスタノードでデータベースの複数テーブルに対する更新命令が生じたときに、当該下位マスタノードのデータベース処理部が上位マスタノードに対して、自身のメモリ上に展開されたデータベースのテーブル毎のシャドウコピーとヒープタプルマップとの組み合わせを束にしたテーブル別書込セットとして生成・送信するステップと、前記上位マスタノードにおいて、前記下位マスタノードから受信した前記テーブル別書込セット中のテーブル毎のヒープタプルマップと自身のデータベースとを比較して、ターゲットとして登録されているデータベースの該当するテーブルの該当行が別のテーブル別書込セット等で更新されているか否かを検証するステップと、前記更新がなされているときには前記所定の下位マスタノードから送信されたテーブル別書込セット全体をアボートし、更新がなされていないときには前記テーブル別書込セット中のテーブル毎の前記シャドウコピーを用いて上位マスタノードのデータベースの該当テーブルの該当行を更新するとともに、上位マスタノードのテーブル番号を含む更新記録をトランザクションログとして生成するステップと、前記トランザクションログを前記送信元の下位マスタノードを含む下位マスタノードに配信するステップと、前記下位マスタノードのトランザクションログ処理部は、前記で受信したトランザクションログに基づいて自身のデータベースの該当テーブルの該当行を更新するステップとからなるデータベースの管理方法である。
 本発明の請求項2は、レコード更新が可能な上位と下位のマスタノードを階層的に有する追記型データベースの管理方法であって、所定の下位マスタノードでデータベースの複数テーブルに対する更新命令が生じたときに、当該下位マスタノードのデータベース処理部が上位マスタノードに対して、自身のメモリ上に展開されたデータベースのテーブル番号を含むシャドウコピーとヒープタプルマップとを単一の統合書込セットとして生成・送信するステップと、前記上位マスタノードにおいて、前記下位マスタノードから受信した統合書込セット中のヒープタプルマップと自身のデータベースとを比較して、ターゲットとして登録されているデータベースのテーブル番号に対応するテーブルの該当行が別の統合書込セット等で更新されているか否かを検証するステップと、いずれかのテーブルで前記更新がなされているときには当該統合書込セット全体をアボートし、更新がなされていないときには前記統合書込セットのシャドウコピーを用いて上位マスタノードのデータベースのテーブル番号に対応するテーブルを更新するとともに、上位マスタノードでテーブル番号を含む更新記録をトランザクションログとして生成するステップと、前記トランザクションログを前記送信元の下位マスタノードを含む下位マスタノードに配信するステップと、前記下位マスタノードのトランザクションログ処理部は、前記で受信したトランザクションログに基づいて自身のデータベースの該当テーブルの該当行を更新するステップとからなるデータベースの管理方法である。
 本発明の請求項3は、前記下位マスタノードにおけるテーブル別書込セットに含まれるテーブル毎のシャドウコピーは、新規の追加行のみで構成する請求項1記載のデータベースの管理方法である。
 本発明の請求項4は、前記下位マスタノードにおける統合書込セットのシャドウコピーは、新規の追加行のみで構成する請求項2記載のデータベースの管理方法である。
 本発明の請求項5は、前記下位マスタノードで前記テーブル別書込セットを生成している段階で当該下位マスタノードのマスタデータベースのテーブルに検索処理が実行されたとき、前記下位マスタノードのデータベース処理部は、前記マスタデータベースのテーブルを参照するステップと、前記テーブルに対応するヒープタプルマップを参照して検索処理において該当行番号がエントリされているか否かを判定し、エントリされていないときには前記マスタデータベースのテーブルを直接の検索対象とし、前記該当行番号がエントリされているときには、前記エントリが削除指示であるか更新指示であるかを判定し、削除指示であるときには該当行番号を検索対象から除外し、更新指示である場合には前記ヒープタプルマップ内の前記テーブルに対応するシャドウコピーのエントリを検索対象とするステップを実行する請求項1または3に記載のデータベースの管理方法である。
 本発明の請求項6は、前記下位マスタノードで前記統合書込セットを生成している段階で当該下位マスタノードのマスタデータベースのテーブルに検索処理が実行されたとき、前記下位マスタノードのデータベース処理部は、前記マスタデータベースのテーブルを参照するステップと、ヒープタプルマップを参照して検索処理において該当テーブルの該当行番号がエントリされているか否かを判定し、エントリされていないときには前記マスタデータベースを直接の検索対象とし、前記該当行番号がエントリされているときには、前記エントリが削除指示であるか更新指示であるかを判定し、削除指示であるときには該当行番号を検索対象から除外し、更新指示である場合には前記ヒープタプルマップ内のシャドウコピーのエントリを検索対象とするステップを実行する請求項2または4に記載のデータベースの管理方法である。
 本発明の請求項7は、前記下位マスタノードで前記テーブル別書込セットを生成している段階で当該下位マスタノードのマスタデータベースのテーブルに検索処理が実行されたとき、前記下位マスタノードのデータベース処理部は、前記マスタデータベースのテーブルを参照するステップと、前記テーブルに対応するヒープタプルマップの全体を参照して、検索対象となっている行番号のエントリを抽出してエントリされている行番号を全て削除されたものとして検索対象から除外するステップと、前記テーブルに対応するシャドウコピーを参照して、シャドウコピー内で追加されたエントリの行番号を参照して当該行番号のみを検索対象とするステップとを実行する請求項1または3に記載のデータベースの管理方法である。
 本発明の請求項8は、前記下位マスタノードで前記統合書込セットを生成している段階で当該下位マスタノードのマスタデータベースのテーブルに検索処理が実行されたとき、前記下位マスタノードのデータベース処理部は、前記マスタデータベースのテーブルを参照するステップと、前記ヒープタプルマップの全体を参照して、検索対象となっているテーブル番号と行番号を持つエントリを抽出してエントリされている行番号を全て削除されたものとして検索対象から除外するステップと、前記シャドウコピーを参照して、シャドウコピー内で追加された検索対象となっているテーブルのエントリの行番号を参照して当該行番号のみを検索対象とするステップとを実行する請求項2または4に記載のデータベースの管理方法である。
 本発明の請求項9は、前記下位マスタノードにおいてテーブル別書込セットまたは統合書込セットを生成したときに、これらを登録する下位マスタノード内のバックエンドメモリ(BEM)の領域は、少なくとも上位マスタノードから配信されたトランザクションデータによる更新命令を実行するトランザクションログ処理部が参照できるようにし、前記トランザクションログ処理部は、前記バックエンドメモリ(BEM)を参照して、この更新命令によって更新しようとしているテーブルの該当行が前記テーブル別書込セットの対応するテーブルのヒープタプルマップ(HTM)に含まれている場合、または統合書込セットのヒープタプルマップ(HTM)に含まれている場合には、当該ヒープタプルマップ(HTM)を生成しているトランザクションをアボートさせる請求項1~4のいずれか1項に記載のデータベースの管理方法である。
 本発明の請求項10は、更新が可能な上位と下位のマスタノードを階層的に有する追記型データベースの管理方法であって、いずれかの下位マスタノードのセッションにおいて、上位マスタノードに対して、当該下位のマスタノードのデータベースの更新対象となったテーブル情報を書込セットに登録して上位マスタノードに送信するステップと、前記上位マスタノードにおいて、データベースのテーブルに対するロック獲得命令が発生したときには、当該ロック獲得情報を下位マスタノードに通知するとともに、そのロック獲得情報を上位マスタノードに保持するステップと、前記上位マスタノードにおいて、前記下位マスタノードから受信した前記書込セット中のテーブル情報と前記で保持されたロック獲得情報とを比較して、競合するときには、前記書込セットをアボートするステップと、前記上位マスタノードからロック獲得情報を受信した前記下位マスタノードでは、ロック獲得情報と競合するトランザクションが存在しているときには、前記下位マスタノードにおいて当該トランザクションを廃棄するステップと、前記下位マスタノードにおいて前記上位マスタノードからのロック獲得情報に基づいて対象となるテーブルのロックを獲得するステップとからなる追記型データベースの管理方法である。
 本発明によれば、マルチマスタノードを階層的に構築し、下位マスタノードから上位マスタノードに対しては、自身のメモリ上に展開されたシャドウコピーとヒープタプルマップとを書込セットとして送信し、これを受信した上位マスタノードでは、当該行が既に別の書込セットによって更新されているか否かを検証して、更新されていないときには前記シャドウコピーとヒープタプルマップとを用いてデータベースの更新処理を行う。そして、その更新記録をトランザクションログとして下位マスタノードに送信することで、下位マスタノードから上位マスタノード、さらに上位マスタノードから配下の下位マスタノードに対して効率的に矛盾のないデータベース更新が可能となる。特に、上位マスタノードおよび下位マスタノードで複数のテーブルが更新されている場合に有効である。
本発明の実施形態1である階層的マスタノードのデータベース構造を示す概念図 実施形態1のマスタノードの機能ブロック図 実施形態1のマスタノードのハードウエアブロック図 実施形態1の下位マスタノードのデータベースのページと生成される書込セット(ヒープタプルマップ(HTM)とシャドウコピー(SC))の関係を示す図 実施形態1において、下位マスタノードから送信された書込セットを用いて上位マスタノードを更新する際の説明図 実施形態1の上位マスタノードで生成されるトランザクションログを示す図 実施形態1の変形例で、書込セットをテーブル(テーブル別書込セット)毎に生成する場合の説明図 実施形態1の変形例で、単一の書込セット中にテーブル番号を付加した場合(統合書込セット)の説明図 複数テーブルに対応したトランザクションログを示す図 実施形態2の階層的マスタノードのデータベース構造を示す概念図 実施形態2のマスタノードの機能ブロック図 実施形態2の下位マスタノードのデータベースのページと生成される書込セット(ヒープタプルマップ(HTM)とシャドウコピー(SC))の関係を示す図 実施形態2の書込セットとマスタデータベース(11a)との関係を示す図 実施形態2の上位マスタノードで生成されるトランザクションログを示す説明図 実施形態2の階層的マスタノードのデータベース構造において、ロック獲得情報の伝搬方法の説明図 実施形態2においてテーブル毎に書込セットを作成する場合の説明図 実施形態2において書込セット中にテーブル情報を記録する場合の説明図
<実施形態1>
 本発明を図に基づいて説明する。
 図1は、本実施形態の階層的マスタノードの構造を示している。同図に示すように、上位マスタノード(MS101)の下に階層的に下位マスタノード(MS201,MS202・・・MS20nや、MS301,MS302・・・MS30n)を有するノード構成となっている。各ノード(情報処理装置)にはデータベースを有している。また上位マスタノード(MS101)にはスレーブを有しているが、他の下位マスタノードにもスレーブを有していてもよい。このようなマスタ・スレーブ構成の場合には両者間のデータベースの更新には本出願人によるPCT/JP2010/054311(本出願人による特許文献2に係る先行出願)に記載された更新管理技術を適用することができる。
 上記特許文献2がマスタノードのトランザクションログを下位のノードに複製(レプリケーション)すればよかったのに対して、本実施形態では、階層的なマルチマスタノードで構成されており下位マスタノードでもアップデート命令が実行されていた場合、上位からのトランザクションログの参照だけでは全下位ノードの整合性を保つことができない点に着目した点が特徴である。以下に説明する。
 図2は、下位マスタノード(MS201)の機能ブロック図であるが、上位マスタノード(MS101)も同様の機能を有している。
 同図に示すように、クライアント(CL)からデータベースの更新命令が入力されるとデータベース処理部(11b)は、メインメモリ(MM)上に構築されたバックエンドメモリ(BEM)上で書込セットを生成する。この書込セットは図4に示すようにヒープタプルマップ(HTM)とシャドウコピー(SC)とで構成される。ここでは、マスタデータベース(11a)の行番号4を削除(DELETE)し、行番号5を新たな値(sc1)に書き換える(UPDATE)する更新命令が入力されたものと仮定する。
 このとき、データベース処理部11bは、マスタデータベース(11a)を参照しながら当該マスタデータベース(11a)に直接書き込むことは行わずに、バックエンドメモリ(BEM)で生成された書込セットを通信モジュール(11d)より上位マスタに送信する。
 このような処理は上位マスタノード(MS101)においても、下位マスタノード(MS201,MS202・・・MS20nや、MS301,MS302・・・MS30n)においても同様である。
 図3は、前記機能を実現するためのハードウエア構成を示している。上位マスタノード(MS101)は汎用の情報処理装置であり、中央処理装置(CPU)およびメインメモリ(MM)を中心にバス(BUS)で接続された大規模記憶装置(HD)、マスタデータベース(11a)、外部との通信のための通信インターフェース(I/O)(通信モジュール11d)を有している。なお、当該バス(BUS)又は通信インターフェース(I/O)を介してクライアント端末(CL)が接続されており、命令を受け付けるようになっている。なお、マスタデータベース(11a)は、大規模記憶装置(HD)上に構築されていてもよいし、メインメモリ(MM)上に構築されていてもよい。要するにマスタデータベース(11a)の構築場所は限定されるものではない。
 大規模記憶装置(HD)には、オペレーティングシステム(OS)とともに、アプリケーションプログラム(APL)が格納されており、当該プログラムをバス(BUS)および主記憶装置(MM)を介して中央処理装置(CPU)が読み込んで順次実行処理することによって、前述のマスタノードとしての機能が実現される。なお、説明は省略するが、下位マスタノード(MS201,MS202・・・MS20nや、MS301,MS302・・・MS30n)も同様の構成である。
 次に、図2で説明したデータベース処理部(11b)による処理を図4を用いてさらに詳細に説明する。なお、以下の説明では、下位マスタノードにおける書込セットの生成を簡略して説明するために、下位マスタノードにおいて所定のトランザクションに基づいて単一のテーブル上でしか更新が実行されていないことを前提として説明するが、巨大なデータベースシステムでは一つのトランザクションで複数のテーブルが更新される場合が通例であり、上位マスタノードはもとより下位マスタノードでも一つのトランザクションによって複数のテーブルが更新される。この点については図7~図9を用いて後述する。
 同図は、下位マスタノード(MS201)におけるマスタデータベース(11a)と、書込セットとの関係を示している。マスタデータベース(11a)は行番号と、命令内容と、ポインタとによって構成されており、新たな命令がクライアント端末(CL)からなされる毎に行番号が追加されていく追記型のデータベースである。同図の場合、前記で説明したように、行番号4を削除(DELETE)し、行番号5を新たな命令内容に書き換える(sc1にUPDATE)する場合を示している。
 下位マスタノード(MS201)においてクライアント端末(CL)からの命令によりマスタデータベースに対してこのような更新命令がなされると、前述のように、バックエンドメモリ(BEM)上でヒープタプルマップ(HTM、ヒープファイル)とシャドウコピー(SC)とからなる書込セットが生成される。
 ヒープタプルマップ(HTM)には、元の行番号(ctid)と、新しい行の行番号(sctid)が関係付けられて登録されるようになっている。このようにヒープタプルマップ(HTM)はデータベースの更新毎に追加生成されていく。なお、行番号5の命令内容(sc1)が書き込まれる行番号はこの段階ではまだ不明であるため、sctidには新しい命令(sc1)を書き込んでおく。
 一方、シャドウコピー(SC)には、マスタデータベース(11a)を参照して書き換えられるべき行番号のシャドウコピーを生成する。このとき、新たに追加される行番号はこの段階では不明であるので、行番号には新たな命令(sc1)を書き込んでおく。
 なお、この段階で下位マスタノード(MS201)のデータベース処理部(11b)は、ヒープタプルマップ(HTM)の生成によりDELETE命令が適用される行番号4と、UPDATE命令が適用される旧行番号5は削除されることが既にわかるため、シャドウコピー(SC)としては新たな命令(sc1)だけを書き込んでおいてもよい。
 このようにして生成された書込セットは、当該下位マスタノード(MS201)から上位マスタノード(MS101)に送信される。
 上位マスタノード(MS101)において、データベース処理部11b(中央処理装置(CPU))は、前記下位マスタノード(MS201)から前記書込セットを受信すると、前記更新命令にともなってトランザクションログ処理部(11c)を起動してトランザクションログの生成を開始する。そして、前記で受信した書込セットからヒープタプルマップ(HTM)を読み出して、自身のマスタデータベース(11a)と比較する。ここで、ターゲットとなっているタプル(ここでは行番号4,5および7)の内容がマスタデータベース(11a)上で更新されているか否かを検証する。図5では、行番号4~6については未更新であるため、行番号4に削除ポインタを付与し、書き換えられる旧番号5にも削除ポインタを付与する。そして、新たな行番号7に新しい命令(sc1)が書き込まれる。
 一方、下位マスタノード(M201)からの書込セット中のヒープタプルマップ(HTM)と自身のデータベースを比較して、上位マスタノード(M201)において既に別の書込セットによって当該行が更新されているときには、当該書込セットによる処理はアボート(中断)される。
 図6は、上位マスタノード(MS101)のマスタデータベース(11a)が上記により更新されたときにトランザクションログ処理部(11c)で生成されるトランザクションログの一例である。このトランザクションログは、少なくとも命令とトランザクション内容(行番号とそれに対する実行処理内容)が時系列で連続的に記録されたファイルである。
 同図によればトランザクションの開始命令(XB1)に続いて、命令番号と行番号とが対になったログが順次生成されている。たとえば、最初にDELETE命令(D1)として行番号4を削除し(D14)、次にUPDATE命令(U1)として行番号5を削除し行番号7を追加し(U157)、最後にこれらのコミット命令(XC1)を発行する。
 このトランザクションログは、通信モジュール(11d)より前記送信元の下位マスタノード(MS201)をはじめ、すべての下位マスタノード(MS202・・・MS20nや、MS301,MS302・・・MS30n)に対して配信される。
 前記トランザクションログを受信した下位マスタノードでは、当該トランザクションログを自身のデータベースに複製(レプリケーション)する。
 具体的には、下位マスタノード(たとえばM202)が図6に示したトランザクションログを通信モジュール(11d)で受信すると、トランザクションログ処理部(11c)を起動してこのトランザクションログを自身のマスタデータベース(11a)にレプリケーションする。この結果、行番号4と5に削除ポインタが付与され、新たな行番号7が追加される。
 このように、下位マスタノードでは上位マスタノードから送信されるトランザクションログのレプリケーションによって統一的にデータベースが管理されることになる。
 以上の説明では、下位マスタノードにおける書込セットの生成を簡略して説明するために、下位マスタノードにおいて所定のトランザクションに基づいて単一のテーブル上でしか更新が実行されていないことを前提としたが、次に図7~図9を用いて複数テーブルが更新された場合について説明する。
 図7および図8はこのような複数のテーブルに対応したものであり、図7はテーブル別(図ではT1~T4)のヒープタプルマップ(HTM)とシャドウコピー(SC)との組み合わせを束にした書込セット(以下、「テーブル別書込セット」という)として上位マスタノードに送信する方法を示している。また、図8はヒープタプルマップ(HTM)とシャドウコピー(SC)の組み合わせ中にテーブル番号を記入して単一の書込セット(以下、「統合書込セット」という)として上位マスタノードに送信する方法を示している。
 このようなテーブル別書込セット(図7)および統合書込セット(図8)においても、ヒープタプルマップ(HTM)の生成によりDELETE命令が適用される行番号とUPDATE命令が適用される旧行番号は削除されることが既にわかるため、シャドウコピー(SC)としては新たな命令だけを書き込んでおいてもよいことは単一テーブルの場合と同様である。
 図7に示す例において、たとえばあるトランザクションによってテーブルT1およびT2のそれぞれが所定の下位マスタノードで更新されたとすると、このテーブルT1とT2のそれぞれについてヒープタプルマップ(HTM)とシャドウコピー(SC)との組み合わせが生成され、この束がテーブル別書込セットとなる。
 テーブル別書込セットが上位マスタノードで受信されると、上位マスタノードではこのテーブル別書込セットの内容を自身のデータベースに反映させる。このとき、まずテーブル毎のヒープタプルマップ(HTM)に基づいて自身のデータベースにアクセスして当該タプルが既に別のテーブル別書込セット(通常の書込セットまたは後述の統合書込セットを含む)により更新されていないかをチェックする。このとき、更新されていない場合は、このテーブル別書込セット中のテーブル毎のシャドウコピーを参照し、当該タプルを更新する。他方、既に更新されていることを検出した場合には、このテーブル別書込セット全体をアボートする。具体的には、一つのテーブル(たとえばT1)のヒープタプルマップ(HTM)に対する上位マスタノードの該当行との間の競合が検出された場合、つまりテーブルT1のヒープタプルマップ(HTM)の該当行が既に他の書込セット等により更新されているときは、当該テーブル別書込セット全体(T1に対するヒープタプルマップ(HTM)とシャドウコピー(SC)の組み合わせ、およびテーブルT2に対するヒープタプルマップ(HTM)とシャドウコピー(SC)の組み合わせの双方)をアボートする。この理由は、テーブル別書込セットに含まれるテーブル毎のヒープタプルマップ(HTM)とシャドウコピー(SC)の組み合わせは単一のトランザクションに基づいて生成されているので、そのトランザクションの全ての処理が上位マスタノードのデータベースに反映されるか、あるいは全く反映されないものでなければデータベース内容に矛盾を生じてしまう。したがって、たとえ一つのテーブル(T1)についてのヒープタプルマップ(HTM)でも上位マスタノードのデータベースの更新情報と競合することが検出された場合には、テーブル別書込セット(T1およびT2それぞれに対するヒープタプルマップ(HTM)とシャドウコピー(SC)の組み合わせ)全体をアボートしなければならない。
 図8に示すヒープタプルマップ(HTM)とシャドウコピー(SC)の組み合わせ中にテーブル番号を記載した統合書込セットを上位マスタノードに適用する場合にも同様である。すなわち、図8の統合書込セットが上位マスタノードで受信されると、ヒープタプルマップ(HTM)のエントリそれぞれについて、エントリに含まれるテーブル番号に該当するテーブルの該当行がすでに別の統合書込セット等(通常の書込セットまたは前述のテーブル別書込セット)により更新されていないかをチェックする。このとき、更新されていない場合は、この統合書込セットのシャドウコピーを参照して、当該テーブルの当該タプルを更新する。他方、すでに更新されていることを検出した場合には、この統合書込セット全体をアボートする。たとえばテーブルT1のヒープタプルマップ(HTM)の該当行が既に他の統合書込セット等(通常の書込セットまたは前述のテーブル別書込セットを含む)により更新されているときは、この統合書込セット全体がアボートされる。
 以上のように下位マスタノードで複数のテーブル情報を含むテーブル別書込セットまたは統合書込セット(図7および図8の場合)によって上位マスタノードが更新された場合、上位マスタノードで生成されるトランザクションログもテーブル番号が付加されたフォーマットとなる。図9はその一例を示したものである。
 同図によれば、トランザクションログのフォーマットは「XB1」、「D114」、「U1257」、「XC1」であるが、これはそれぞれ以下の意味を有している。
 トランザクション1の開始命令(XB1)に続いて、命令番号とテーブル番号と行番号とが組み合わされたログが順次生成されている。たとえば、最初にトランザクション1のDELETE命令(D1)としてテーブル1の行番号4を削除し(D114)、次にトランザクション1のUPDATE命令(U1)としてテーブル2の行番号5を削除し行番号7を追加し(U1257)最後にこれらのコミット命令(XC1)を発行する。
 このトランザクションログは、通信モジュール(11d)より前記送信元の下位マスタノード(MS201)をはじめ、すべての下位マスタノード(MS202・・・MS20nや、MS301,MS302・・・MS30n)に対して配信される。
 前記トランザクションログを受信した下位マスタノードでは、当該トランザクションログを自身のデータベースに複製(レプリケーション)する。
 具体的には、下位マスタノード(たとえばM202)が図9に示したトランザクションログを通信モジュール(11d)で受信すると、トランザクションログ処理部(11c)を起動してこのトランザクションログを自身のマスタデータベース(11a)にレプリケーションする。この結果、トランザクション1としてテーブル1の行番号4に削除ポインタが付与され、テーブル2の行番号5に削除ポインタが付与されるとともに新たな行番号7が追加される。
 以上、本発明を実施形態に基づいて説明したが、本発明はこれに限定されるものではない。以下、その変形例について説明する。
 <上位マスタノードMS101でデータベースの更新が行われる場合>
 下位マスタノード(たとえばMS201)でマスタデータベースの更新命令が発生した場合の処理については、図2で説明したように、バックエンドメモリ(BEM)上でヒープタプルマップ(HTM、ヒープファイル)とシャドウコピー(SC)とからなる書込セット(複数テーブルの場合には図7に示すテーブル別書込セットまたは図8に示す統合書込セット)が生成されるが、上位マスタノード(MS101)でマスタデータベースの更新命令が発生した場合には、上位ノードに通知する必要がないため、書込セットは生成されない。すなわち、このような場合、上位ノード(MS101)では、図5の左図に示すようにマスタデータベース(11a)に対して直接更新データの書込が行われるとともに、図6に示すトランザクションログ(複数テーブルの場合には図9に示すトランザクションログ)が生成される。このトランザクションログは下位マスタノードに配信され、前記トランザクションログを受信した下位マスタノードでは、当該トランザクションログを自身のマスタデータベースにレプリケーションする。
 <下位マスタノードで書込セットを生成している段階で検索処理が実行されたとき>
 下位マスタノード(たとえばMS201)において、図4に示すような書込セットを生成している段階で、当該下位マスタノードのマスタデータベースに対して検索が実行されたとき、書込セットの生成された行番号以外の行番号を対象とした検索であれば問題はないが、該当行(ここでは行番号4および行番号5)に対する検索が実行された場合、これらの行番号は既に削除されているため、検索対象にはできない。
 このとき、下位マスタノードで生成されている書込セットが図7や図8に示すような複数テーブルを前提としている場合も同様であるので、検索対象にはできない。
 このような場合には以下の2通りの対応が考えられる。
 第1の類型は、データベース処理部(11b)は、マスタデータベース(11a)を参照した後に、ヒープタプルマップ(HTM)を参照する。そしてこのヒープタプルマップ(HTM)上で検索該当行番号がエントリされているか否かをチェックする。そしてエントリがあった場合には当該エントリが削除か更新かを判定し、更新の場合にはさらにシャドウコピー(SC)を参照して当該シャドウコピー(SC)のエントリ(sc1)を検索対象とする。たとえば図4に示す例で、検索対象が行番号3である場合、データベース処理部(11b)は、メインメモリ(MM)上に構築されたバックエンドメモリ(BEM)上の書込セット内のヒープタプルマップ(HTM)を参照して、該当行(行番号3)がエントリされているか否かを判定する。図4の例では、該当行はエントリされていない。その場合には、マスタデータベース11aに直接アクセスして該当行(行番号3)を検索する。
 一方、図4に示す例で、検索対象が行番号4である場合、データベース処理部(11b)は書込セット内のヒープタプルマップ(HTM)を参照したときに、該当行(行番号4)がエントリされていることを検出する。この場合、マスタデータベース11aにアクセスしても、残存する該当行は既に削除する更新命令の対象となっているため、検索対象とはならない。データベース処理部(11b)は、ヒープタプルマップ(HTM)を参照して該当行(行番号4)が削除されていることを検出する。このように、検索対象行が削除されているため、データベース処理部(11b)は該当行を検索対象とはしない。
 一方、図4に示す例で、検索対象が行番号5である場合、上記と同様に、ヒープタプルマップ(HTM)を参照して該当行(行番号5)に対応するシャドウコピー(SC)のエントリ(sc1)が作成されていることを検出する。
 このとき、データベース処理部(11b)は、シャドウコピー(SC)を参照して、行番号5を書き換えたエントリ(sc1)を検索対象とすればよい。
 以上単一のテーブルを更新する場合について説明したが、複数テーブルを更新する場合についても同様である。
 具体的には、図7のテーブル別書込セットの場合には、検索の対象とするテーブルに対応するヒープタプルマップ(HTM)とシャドウコピー(SC)の組み合わせを取り出して用いる。
 マスタデータベースの検索対象のテーブルを参照した後に、そのテーブルに対応するヒープタプルマップ(HTM)を参照し、検索該当行番号がエントリされているか否かをチェックする。エントリが存在しない場合は、マスタデータベースの検索対象テーブルの該当行を検索対象とする。そしてエントリがあった場合には当該エントリが削除か更新かを判定し、更新の場合にはさらにシャドウコピー(SC)を参照して当該シャドウコピー(SC)のエントリを検索対象とする。削除の場合には、該当行を検索対象とはしない。
 図8の統合書込セットの場合には、ヒープタプルマップ(HTM)とシャドウコピー(SC)のエントリのうち、検索対象テーブルに対応するテーブル番号が付与されたエントリを取り出して用いる。
 マスタデータベースの検索対象のテーブルを参照した後に、上記で取り出した検索対象テーブルに対応するヒープタプルマップ(HTM)のエントリを参照し、検索該当行番号が含まれているか否かをチェックする。エントリが含まれていない場合には、マスタデータベースの検索対象テーブルの該当行を検索対象とする。そしてエントリが含まれている場合には当該エントリが削除か更新かを判定し、更新の場合にはさらに上記で取り出したシャドウコピー(SC)のエントリを参照して当該エントリを検索対象とする。また、削除の場合には、該当行を検索対象とはしない。
 第2の類型では、データベース処理部(11b)はまずマスタデータベース(11a)を参照した後に、ヒープタプルマップ(HTM)の全体を参照する。このとき、検索対象となっている行がエントリされているか否かをチェックし、エントリされている行番号(ここでは行番号4および5)を全て削除されたものとする(検索対象から除外する)。次に、データベース処理部11bは、シャドウコピー(SC)を参照して、シャドウコピー内の追加されたエントリ(sc1)を参照しこれを検索対象とすればよい。
 図7のテーブル別書込セットの場合は、検索対象テーブルに対応するヒープタプルマップ(HTM)とシャドウコピー(SC)の組み合わせについて同様の処理を行う。
 図8の統合書込セットの場合は、ヒープタプルマップ(HTM)とシャドウコピー(SC)のエントリのうち、検索対象テーブルに対応するテーブル番号が付与されたエントリを取り出して、それらのエントリを用いて同様の処理を行う。
 <下位マスタで上位マスタからのトランザクションログによる更新が行われているときの競合が生じた場合>
 上位マスタから配信されたトランザクションログによって下位マスタノードのデータベースにレプリケーションが行われているときに、該当行に対して下位マスタのデータベースの更新命令が実行されている場合、競合が発生することになる。
 具体的には、下位マスタノードへの更新命令に基づいて行番号4と5とを更新しているときに、上位マスタから行番号5がエントリされたトランザクションログが配信されてきたときがこれに該当する。
 このような場合には、下位マスタノードで作成された書込セットが上位マスタノードに送信されたとしても、上位マスタノードでは既に該当行に関するトランザクションログが配信されているため、前記書込セットは上位マスタノードで競合が検出されてアボートされることになる。したがって、当該下位マスタノードにおける競合は無視して差し支えない。なお、下位マスタノードで生成されている書込セットが複数テーブルに対応している場合(図7および図8に示す)でも同様である。
 一方、このような下位マスタノードでの競合を解決する別の方法としては、下位マスタノードにおいて書込セット(ヒープタプルマップ(HTM)とシャドウコピー(SC))を生成したときに、これらを当該下位マスタノード内のバックエンドメモリ(BEM)上に登録し、これらの領域を2以上のプロセス(具体的にはレプリケーションプロセスと書込セットの生成プロセス)から参照できるようにしておいてもよい。つまり、下位マスタノードにおいて、書込セット、さらに限定すればヒープタプルマップ(図7および図8に示したテーブル別書込セットおよび統合書込セットも含む)のみを共有メモリに配置しておくことが望ましい。
 この場合には、下位マスタノードがマスタデータベース11aのレプリケーションを実行する際に、バックエンドメモリ(BEM)上の書込セットを参照することによって、更新命令と矛盾する書込セットを下位マスタノードの段階でアボートさせることができる。具体的には、トランザクションログ処理部11cは、前記バックエンドメモリ(BEM)を参照して、この更新命令によって更新しようとしている該当行がヒープタプルマップ(HTM)に含まれている場合には、当該ヒープタプルマップ(HTM)を生成しているトランザクションをアボートさせる。
 下位マスタノードで生成されている書込セットが複数テーブルに対応している場合(図7および図8に示す)でも同様である。図7に示すテーブル別書込セットの場合、下位マスタノードにおいてテーブル別書込セット(ヒープタプルマップ(HTM)とシャドウコピー(SC)の束)を生成したときに、これらを当該下位マスタノード内のバックエンドメモリ(BEM)上に登録し、これらの領域を2以上のプロセス(具体的にはレプリケーションプロセスとテーブル別書込セットの生成プロセス)から参照できるようにしておいてもよい。つまり、下位マスタノードにおいて、テーブル別書込セット、さらに限定すればテーブル毎のヒープタプルマップのみを共有メモリに配置しておくことが望ましい。
 この場合には、下位マスタノードがマスタデータベース11aのレプリケーションを実行する際に、バックエンドメモリ(BEM)上のテーブル別書込セットを参照することによって、更新命令と矛盾するテーブル別書込セットを下位マスタノードの段階でアボートさせることができる。
 図8に示す統合書込セットの場合、単一のテーブル構成の場合と同様である。すなわち、ヒープタプルマップ中にテーブル番号が登録されているため、統合書込セット(ヒープタプルマップ(HTM)とシャドウコピー(SC))を生成したときに、これらを当該下位マスタノード内のバックエンドメモリ(BEM)上に登録し、その後の処理は単一のテーブル構成の場合と同じである。
 このように、ヒープタプルマップ(HTM)を共有メモリに配置して、複数プロセスから参照できるようにしたことにより、マルチマスタ方式のデータベースにおいても下位マスタノードの段階で、競合を防止できる。さらに、ヒープタプルマップ(HTM)のみを共有メモリに配置しておけばよいので、貴重な共有メモリを占有してしまうこともない。
 <実施形態2>
 本発明の別の実施形態(実施形態2)を図に基づいて説明する。
 図10は、本実施形態の階層的マスタノードの構造を示している。同図に示すように、上位マスタノード(MS101)の下に階層的に中位マスタノード(MS201,MS202・・・MS20n)や、下位マスタノード(MS301,MS302・・・MS30n)を有するノード構成となっている。各ノード(情報処理装置)にはデータベースを有している。また上位マスタノード(MS101)にはスレーブ(SL)を有しているが、他の中位・下位マスタノードにもスレーブを有していてもよい。このようなマスタ・スレーブ構成の場合、両者間のデータベースの更新には本出願人による特開2006-293910号公報(本出願人による公開先行出願)に記載された更新管理技術を適用することができる。
 上記先行出願がマスタノードのトランザクションログデータを下位のノードに複製(レプリケーション)すればよかったのに対して、PCT/JP2011/068057号(本出願人による未公開出願)では階層的なマルチマスタノードで構成されたデータベースにおいて下位マスタノードでもアップデート命令が実行されていた場合、上位からのトランザクションログの参照だけでは全下位ノードの整合性を保つことができない点に着目して、下位マスタノードで自身のメモリ上に展開されたデータベースのシャドウコピーとヒープタプルマップとを書込セットとして上位マスタノードに送信して上位マスタノードの更新を行う点が特徴だった。しかしこれらの先行技術では上位マスタノードでテーブル自体を削除したりテーブル構造に変更を加えるような場合は想定していなかった。そのために書込セットによる更新によってデータベースの整合性がとれなくなる事態を生じる可能性があった。本実施形態はこのような場合にデータベースのロック機能を利用してマルチマスタノード構造全体で整合性を保つ技術である。以下に説明する。
 図11は、中位マスタノード(MS201)・下位マスタノード(MS301)の機能ブロック図であるが、上位マスタノード(MS101)も同様の機能を有している。
 同図に示すように、クライアント(CL)からデータベースの更新命令が入力されるとデータベース処理部(11b)は、図示しないメインメモリ上に構築されたバックエンドメモリ(BEM)上で書込セットを生成する。この書込セットは図12に示すようにヒープタプルマップ(HTM)とシャドウコピー(SC)とで構成される。ここでは、マスタデータベース(11a)の行番号4を削除(DELETE)し、行番号5を新たな値(sc1)に書き換える(UPDATE)する更新命令が入力されたものと仮定する。
 このとき、データベース処理部11bは、マスタデータベース(11a)を参照しながら当該マスタデータベース(11a)に直接書き込むことは行わずに、バックエンドメモリ(BEM)で生成された書込セットを通信モジュール(11d)を介して上位マスタに送信する。
 このような書込セットの生成・送信は、中位マスタノード(MS201,MS202・・・MS20n)や下位マスタノード(MS301,MS302・・・MS30n)においても同様である。
 ここで、上位マスタノード(MS101)で、テーブルを排他的に制御しなければならいような命令、たとえばテーブルの構造変更やテーブルの削除が発生したときには、そのテーブルに対するロック獲得命令を実行しそれに対応するロック番号を保持する。たとえば、テーブル1とテーブル3とテーブル2とテーブル4・・・に対するロック獲得命令が順次実行されたときには、テーブル1に対するロック番号は1番、テーブル3に対するロック番号は2番、テーブル2に対するロック番号は3番、テーブル4に対するロック番号は4番となり、これらのロック番号(1~4)が保持される。
 このように、上位マスタノードでデータベースのテーブルに対するロック獲得命令が発生したときには、これをロック獲得情報として中位マスタノードおよび下位マスタノードに単独で通知するようにしてもよいし、後述のように上位マスタノードで生成されるトランザクションログに格納して中位マスタノードおよび下位マスタノードに通知してもよい。そして、前記上位マスタノードからロック獲得情報を受信した前記下位マスタノードでは、ロック獲得情報と競合するトランザクション、たとえばロック獲得情報が対象としているテーブルに対して更新を行っているトランザクションの有無をチェックして、そのようなトランザクションが存在しているときには、上位マスタノードで発生したロック獲得情報が優先されるため、この下位マスタノードにおけるトランザクションが廃棄される。
 以上、トランザクションが競合する場合の一例として、ロック獲得情報が対象としているテーブルに対して更新を行っているトランザクションが存在している場合を説明したが、トランザクションの競合とはこれに限られない。たとえば、上位マスタノードから通知されたロック獲得情報がテーブルを削除する際に獲得するロック獲得情報である場合には、下位マスタノードにおいて該当するテーブルを単に参照するだけのトランザクションが存在しているだけであっても、前記ロック獲得情報とは競合することになるため、このような下位マスタノードにおけるトランザクションは廃棄される。
 そして、当該ロック獲得情報を格納したトランザクションログ(図14参照)を生成する。同図に示したトランザクションログは、XB1で命令開始、LT1でテーブル1のロック、DT1で当該テーブル1のデリート、XC1でそのコミットを意味している。トランザクションログにはこのような一群の命令が繰り返されて格納されている。本実施形態では、ロック獲得情報毎にシーケンシャルな番号を付与して管理している。たとえば、LT1はテーブル1に対するもので1番目のロック獲得命令、LT3はテーブル3に対するもので2番目のロック獲得命令、LT2はテーブル2に対するもので3番目のロック獲得命令。すなわち、この例ではLT1→LT3→LT2→LT4の順番でシーケンシャルにロック獲得番号1~4が付与されて管理されている。
 しかし、このようなロック獲得命令をシーケンシャルに管理する方法としては、ログ毎に付与されているログシーケンス番号(LSN)を用いてもよい。図14では、LT1はLSN=2,LT3はLSN=8、LT2はLSN=13、LT4はLSN=18となる。
 このトランザクションログは、前記上位マスタノード(MS101)から中位・下位マスタノード(MS201,MS202,MS20n,MS301,MS302,MS30n・・・)に送信される。
 それぞれの中位・下位マスタノードでは、前記トランザクションログを受信すると、前記トランザクションログの内容を自身のデータベースに対してレプリケーションする。
 ここで、ロック獲得命令についてのみ説明すれば、ロック獲得命令LT1,LT3,LT2,LT4を順次実行して自身の共有メモリ上のテーブルを排他ロック状態として、中位・下位マスタノードでの他のトランザクションによるメモリアクセスを制限する。このとき、ロック獲得命令(ロック獲得情報)と競合するトランザクション、たとえばロック獲得命令が対象としているテーブルに対して更新を行っているトランザクションの有無をチェックして、そのようなトランザクションが存在しているときには、上位マスタノードで発生したロック獲得命令が優先されるため、この下位マスタノードにおけるトランザクションが廃棄される。
 下位マスタノードにおいて、前記ロック獲得命令(LT1,LT3,LT2,LT4・・・)に基づいて順番にロックが獲得されると、当該下位マスタノードにおいてロックが獲得された最大値のロック獲得番号をノードロック番号(NLKN)として中位・上位マスタノードに通知する。図15では、下位マスタノード(MS301)は3番目のロック獲得命令(LT2)まで完了しているのでNLKN=3(図15では丸付き数字の3)、下位マスタノード(MS302)は2番目のロック獲得命令(LT3)まで完了しているのでNLKN=2(図15で丸付き数字の2)となる。
 図12は、下位マスタノード(MS301)におけるマスタデータベース(11a)と、書込セットとの関係を示している。下位マスタノードにおけるマスタデータベース(11a)は行番号と、命令内容と、ポインタとによって構成されており、新たな命令がクライアント端末(CL)からなされる毎に行番号が追加されていく追記型のデータベースである。同図の場合、前記で説明したように、行番号4を削除(DELETE)し、行番号5を新たな命令内容に書き換える(sc1にUPDATE)する場合を示している。
 下位マスタノード(MS301)においてクライアント端末(CL)からの命令によりマスタデータベース(11a)に対してこのような更新命令がなされると、前述のように、バックエンドメモリ(BEM)上でヒープタプルマップ(HTM、ヒープファイル)とシャドウコピー(SC)とからなる書込セットが生成される。
 ヒープタプルマップ(HTM)には、元の行番号(ctid)と、新しい行の行番号(sctid)が関係付けられて登録されるようになっている。このようにヒープタプルマップ(HTM)はデータベースの更新毎に追加生成されていく。なお、行番号5の命令内容(sc1)が書き込まれる行番号はこの段階ではまだ不明であるため、sctidには新しい命令(sc1)を書き込んでおく。
 一方、シャドウコピー(SC)には、マスタデータベース(11a)を参照して書き換えられるべき行番号のシャドウコピーを生成する。このとき、新たに追加される行番号はこの段階では不明であるので、行番号には新たな命令(sc1)を書き込んでおく。
 なお、この段階で下位マスタノード(MS301)のデータベース処理部(11b)は、ヒープタプルマップ(HTM)の生成によりDELETE命令が適用される行番号4と、UPDATE命令が適用される旧行番号5は削除されることが既にわかるため、シャドウコピー(SC)としては新たな命令(sc1)だけを書き込んでおいてもよい。
 このような書込セットは、図16に示すようにテーブル毎に作成されるが、図17に示すように単一の書込セット中のヒータプルマップ(HTM)の行番号(ctid)に関係付けてテーブル番号(T)を登録するようにしてもよい。
 前記書込セットには、前述のノードロック番号(NLKN)も格納される。このノードロッック番号(NLKN)は、前述のように、上位マスタノード(MS101)から配信(通知)されたトランザクションログ(図14参照)に格納されたロック獲得命令(LT1,LT3,LT2,LT4)に対応して実行されたロック獲得番号の最大値である。
 前述の説明を繰り返すと、下位マスタノード(MS301)が図14に示すようなトランザクションログを受信して、このトランザクションログのロック獲得命令(LT1,LT3,LT2,LT4)に基づいて3番目のロック獲得命令(LT2)まで完了している場合、このノードロック番号(NLKN)は「3」となり(NLKN=3)、図15に示すように下位マスタノード(MS301)で生成される書込セットに格納される。一方、下位マスタノード(MS302)は、2番目のロック獲得命令(LT3)まで完了している場合、このノードロック番号(NLKN)は「2」となり(NLKN=2)、同図に示すように下位マスタノード(MS302)で生成される書込セットに格納される。
 このようにして生成された書込セットは、当該下位マスタノード(MS301,MS302)から上位マスタノード(MS101)に送信される。当該書込セットは、その間の中位マスタノード(MS202)を経由するが、当該中位マスタノード(MS202)は当該書込セットに対して何らの処理は行わない。
 上位マスタノード(MS101)において、データベース処理部11b(中央処理装置(CPU))は、前記下位マスタノード(MS301,MS302)から前記書込セットを受信すると、そこからヒープタプルマップ(HTM)を読み出して、自身のマスタデータベース(11a)と比較する。図12ではターゲットとなっているタプル(ここでは行番号4,5および7)の内容がマスタデータベース(11a)上で更新されているか否かを検証する。ここでは行番号4~6については未更新であるため、行番号4に削除ポインタを付与し、書き換えられる旧番号5にも削除ポインタを付与する。そして、新たな行番号7に新しい命令(sc1)が書き込まれる。
 このとき、本実施形態では全ての書込セットをマスタデータベース(11a)と比較するものではない。つまり、前述の比較ステップに先立って、書込セットに格納されたノードロック番号(NLKN)を読み出しておき、ノードロック番号(NLKN)よりも大きなロック番号に該当するロック獲得情報を参照し、そのロック獲得情報と書込セットが修正しようとしているテーブルとが競合していないかどうかを検証する。競合している場合には書込セットをアボートして当該書込セットを比較対象から除外する。このような検証を行う理由は、上位マスタノード(MS101)でロックが獲得されているにもかかわらず、下位マスタノードで前記ロックの獲得前のテーブルに基づいてそのテーブルに対してタプルの更新を行いその情報が書込セットとして上位マスタノード(MS101)に届いて当該タプルを含むテーブルを更新してしまった場合、上位マスタノード(MS101)がロック獲得中に行ったテーブルの構造の変更や削除と競合してマスタデータベース(11a)の整合性が損なわれてしまうためである。
 後述のヒープタプルマップ(HTM)を用いた競合の検出方法では、このようなデータベースの整合性の破壊を検出できないため、このようにロック獲得情報との比較を行い、事前に競合を検出しておく必要がある。
 一方、前記のロック番号との比較でアボートされなかった書込セットであっても、書込セット中のヒープタプルマップ(HTM)と上位マスタノードのマスタデータベース(11a)とを比較した結果、マスタデータベース(11a)の該当行が既に別の書込セットによって更新されているときには、マスタデータベース(11a)の更新が競合することになるため当該書込セットはアボートされる。
 次に、前記書込セットとは別に、下位マスタノード(MS301,MS302)において、トランザクションログでレプリケーションされたロック獲得命令に対応するロック獲得結果情報が中位マスタノード(MS202)を介して上位マスタノード(MS101)に通知される機構について図15を用いて説明する。
 下位マスタノード(MS301,302)では、前述のトランザクションログに格納されたロック獲得命令(LT1,LT3,LT2,LT4・・・)を順次レプリケーションして、そのロック獲得結果情報を得る。ここでは、具体的にはロック獲得命令順に付与されたロック獲得命令番号で管理すればよい。すなわちテーブル1のロック獲得命令(LT1)のロック獲得命令番号は「1」、次のテーブル3のロック獲得命令(LT3)のロック獲得命令番号は「2」、次のテーブル2のロック獲得命令(LT2)のロック獲得命令番号は「3」、さらに次のテーブル4のロック獲得命令(LT4)のロック番号は「4」となる。
 そして、それぞれの下位マスタノード(MS301,MS302)では、ロックが獲得されたロック獲得命令番号の数値の最大値をノードロック番号(NLKN)で管理していることは前述の通りである。
 各下位マスタノード(MS301,MS302)からそれぞれのノードロック番号(NLKN)を上層の中位マスタノード(MS202)に送信する。中位マスタノード(MS202)では、自身が保有しているノードロック番号(NLKN=2)と、各下位マスタノードから通知されたノードロック番号(NLKN=3,2)とを比較して、その最も小さい値(ここでは2)を自身のツリーロック番号(TLKN=2)として更新する。
 なお、図15において、中位マスタノード(MS201)ではその配下の下位マスタノードが存在しないため、自身のノードロック番号(NLKN=3)がそのまま当該中位マスタノード(MS201)を頂点としたツリーロック番号(TLKN=3)となる。
 各中位マスタノード(MS201,MS202)は、それぞれのツリーロック番号(TLKN=3,2)を上位マスタノード(MS101)に送信する。これを受信した上位マスタノード(MS101)では、これらの中から最小値(ここではTLKN=2)をクラスタロック番号(CLKN=2)として更新する。
 このクラスタロック番号(CLKN=2)は、前述のように全階層から収集されたクラスタ全体の全てのノードロック番号(NLKN)の最小値であるため、上位マスタノード(MS101)ではこのクラスタロック番号(CLKN=2)によってクラスタ全体のロック獲得状況を把握することができる。すなわち、クラスタロック番号(CLKN)が2である場合、この番号と等しいか小さいロック獲得命令は全てのノードで完了していることを意味する。
 したがって、上位マスタノード(MS101)はクラスタロック番号と等しいか小さいロック番号を持つロック獲得命令は、獲得が完了したと認識する。
 ここで、中位・下位マスタノードから順次受信したツリーロック番号(TLKN)との比較の他に、前記書込セットに格納された下位マスタノード(MS301,302)のノードロック番号(NLKN)と上位マスタノードにおいて自身が保持しているロック獲得命令番号との比較をも行う理由は以下の通りである。
 一般に下位マスタノード(MS301,302)で実行されたロック獲得結果情報(ノードロック番号:NLKN)が中位ノードのツリーロック番号(TLKN)を更新しながら上位マスタノード(MS101)に到達するまでには時間を要する。特にツリー階層構造が複雑なデータベースであればその到達遅延により処理効率が大幅に低下してしまう。特に各階層で最小値の比較を行っているため、どれか1個でも小さいNLKN(たとえばNLKN=2)があるとクラスタロック番号(CLKN)はいつまでも大きな値をとれないため、上位マスタノードでは、全ての書込セットをチェックしなければならない。
 一方、書込セットを発行した下位マスタノード(MS301)はNLKN=3が設定されているため、3番目のロック獲得命令までは既に完了していることになる。つまり、このノード(MS301)に関する限り、これよりも大きいロック番号「4」(LT4)に該当するロック獲得情報のみを前記書込セット中のテーブル情報との比較対象とすれば、上位マスタノード(MS101)における比較処理による負荷を低減できることになる。
 以上本発明を実施形態に基づいて説明したが、本願発明はこれに限定されるものではない。たとえば、ノードの階層構造については、上位マスタノード、中位マスタノードおよび下位マスタノードの3層構造(図10,図15および図16)を例示したが、上位マスタノードと下位マスタノードの2層構造のものであってもよい。また、中位マスタノードが2層以上のものであってもよい。
 また、以上の説明では、ノードロック番号(NLKN)を中位、上位マスタノードに通知して順次ツリーロック番号(TLKN)、クラスタロック番号(CLKN)を更新する実施例を説明したが、これに限定されることはない。たとえば、上位マスタノード(MS101)は、中位マスタノード(MS201,MS202)または下位マスタノード(MS301,MS302)から送信される書込セットに含まれるノードロック番号(NLKN)をそれぞれの下位・中位マスタノードのノードロック番号(NLKN)とみなし、上位マスタノード(MS101)では、各中位・下位マスタノードから発行される書込セットを収集して、その書込セット中に格納されている全てのノードロック番号(NLKN)の最小値をクラスタロック番号(CLKN)とみなしてもよい。
 このように書込セットのノードロック番号(NLKN)を収集してクラスタロック番号(CLKN)を更新する利点としては、これらの書込セットとは別にノードロック番号(NLKN)を中位・上位マスタノードに通知してそれぞれのツリーロック番号(TLKN)を更新しながらさらに上層に送信する必要がないため、通知システムを簡略化できる。一方、この方法では、上位マスタノード(MS101)が全ての書込セットからノードロック番号(NLKN)の集計作業をしなければならないため、負荷が大きくなってしまう。
 本発明は、階層構造を備えたマルチマスタノード構造のデータベース管理システムに利用できる。
MS101 上位マスタノード
SL スレーブ
MS201,MS202・・・MS20n 下位マスタノード(中位マスタノード)
MS301,MS302・・・MS30n 下位マスタノード
CL クライアント端末
11a マスタデータベース
11b データベース処理部
11c トランザクションログ処理部
11d 通信モジュール
CPU 中央処理装置
MM 主記憶装置
BUS バス
HD 大規模記憶装置
I/O 通信インターフェース
HTM ヒープタプルマップ
SC シャドウコピー

Claims (10)

  1.  レコード更新が可能な上位と下位のマスタノードを階層的に有する追記型データベースの管理方法であって、
     所定の下位マスタノードでデータベースの複数テーブルに対する更新命令が生じたときに、当該下位マスタノードのデータベース処理部が上位マスタノードに対して、自身のメモリ上に展開されたデータベースのテーブル毎のシャドウコピーとヒープタプルマップとの組み合わせを束にしたテーブル別書込セットとして生成・送信するステップと、
     前記上位マスタノードにおいて、前記下位マスタノードから受信した前記テーブル別書込セット中のテーブル毎のヒープタプルマップと自身のデータベースとを比較して、ターゲットとして登録されているデータベースの該当するテーブルの該当行が別のテーブル別書込セット等で更新されているか否かを検証するステップと、
     前記更新がなされているときには前記所定の下位マスタノードから送信されたテーブル別書込セット全体をアボートし、更新がなされていないときには前記テーブル別書込セット中のテーブル毎の前記シャドウコピーを用いて上位マスタノードのデータベースの該当テーブルの該当行を更新するとともに、上位マスタノードのテーブル番号を含む更新記録をトランザクションログとして生成するステップと、
     前記トランザクションログを前記送信元の下位マスタノードを含む下位マスタノードに配信するステップと、前記下位マスタノードのトランザクションログ処理部は、前記で受信したトランザクションログに基づいて自身のデータベースの該当テーブルの該当行を更新するステップと
    からなるデータベースの管理方法。
  2.  レコード更新が可能な上位と下位のマスタノードを階層的に有する追記型データベースの管理方法であって、
     所定の下位マスタノードでデータベースの複数テーブルに対する更新命令が生じたときに、当該下位マスタノードのデータベース処理部が上位マスタノードに対して、自身のメモリ上に展開されたデータベースのテーブル番号を含むシャドウコピーとヒープタプルマップとを単一の統合書込セットとして生成・送信するステップと、
     前記上位マスタノードにおいて、前記下位マスタノードから受信した統合書込セット中のヒープタプルマップと自身のデータベースとを比較して、ターゲットとして登録されているデータベースのテーブル番号に対応するテーブルの該当行が別の統合書込セット等で更新されているか否かを検証するステップと、
     いずれかのテーブルで前記更新がなされているときには当該統合書込セット全体をアボートし、更新がなされていないときには前記統合書込セットのシャドウコピーを用いて上位マスタノードのデータベースのテーブル番号に対応するテーブルを更新するとともに、上位マスタノードでテーブル番号を含む更新記録をトランザクションログとして生成するステップと、
     前記トランザクションログを前記送信元の下位マスタノードを含む下位マスタノードに配信するステップと、
     前記下位マスタノードのトランザクションログ処理部は、前記で受信したトランザクションログに基づいて自身のデータベースの該当テーブルの該当行を更新するステップと
     からなるデータベースの管理方法。
  3.  前記下位マスタノードにおけるテーブル別書込セットに含まれるテーブル毎のシャドウコピーは、新規の追加行のみで構成する請求項1記載のデータベースの管理方法。
  4.  前記下位マスタノードにおける統合書込セットのシャドウコピーは、新規の追加行のみで構成する請求項2記載のデータベースの管理方法。
  5.  前記下位マスタノードで前記テーブル別書込セットを生成している段階で当該下位マスタノードのマスタデータベースのテーブルに検索処理が実行されたとき、
     前記下位マスタノードのデータベース処理部は、前記マスタデータベースのテーブルを参照するステップと、
     前記テーブルに対応するヒープタプルマップを参照して検索処理において該当行番号がエントリされているか否かを判定し、エントリされていないときには前記マスタデータベースのテーブルを直接の検索対象とし、
     前記該当行番号がエントリされているときには、前記エントリが削除指示であるか更新指示であるかを判定し、削除指示であるときには該当行番号を検索対象から除外し、更新指示である場合には前記ヒープタプルマップ内の前記テーブルに対応するシャドウコピーのエントリを検索対象とするステップ  
     を実行する請求項1または3に記載のデータベースの管理方法。
  6.  前記下位マスタノードで前記統合書込セットを生成している段階で当該下位マスタノードのマスタデータベースのテーブルに検索処理が実行されたとき、
     前記下位マスタノードのデータベース処理部は、前記マスタデータベースのテーブルを参照するステップと、
     ヒープタプルマップを参照して検索処理において該当テーブルの該当行番号がエントリされているか否かを判定し、エントリされていないときには前記マスタデータベースを直接の検索対象とし、
     前記該当行番号がエントリされているときには、前記エントリが削除指示であるか更新指示であるかを判定し、削除指示であるときには該当行番号を検索対象から除外し、更新指示である場合には前記ヒープタプルマップ内のシャドウコピーのエントリを検索対象とするステップ  
     を実行する請求項2または4に記載のデータベースの管理方法。
  7.  前記下位マスタノードで前記テーブル別書込セットを生成している段階で当該下位マスタノードのマスタデータベースのテーブルに検索処理が実行されたとき、
     前記下位マスタノードのデータベース処理部は、前記マスタデータベースのテーブルを参照するステップと、
     前記テーブルに対応するヒープタプルマップの全体を参照して、検索対象となっている行番号のエントリを抽出してエントリされている行番号を全て削除されたものとして検索対象から除外するステップと、
     前記テーブルに対応するシャドウコピーを参照して、シャドウコピー内で追加されたエントリの行番号を参照して当該行番号のみを検索対象とするステップと
     を実行する請求項1または3に記載のデータベースの管理方法。
  8.  前記下位マスタノードで前記統合書込セットを生成している段階で当該下位マスタノードのマスタデータベースのテーブルに検索処理が実行されたとき、
     前記下位マスタノードのデータベース処理部は、前記マスタデータベースのテーブルを参照するステップと、
     前記ヒープタプルマップの全体を参照して、検索対象となっているテーブル番号と行番号を持つエントリを抽出してエントリされている行番号を全て削除されたものとして検索対象から除外するステップと、
     前記シャドウコピーを参照して、シャドウコピー内で追加された検索対象となっているテーブルのエントリの行番号を参照して当該行番号のみを検索対象とするステップと
     を実行する請求項2または4に記載のデータベースの管理方法。
  9.  前記下位マスタノードにおいてテーブル別書込セットまたは統合書込セットを生成したときに、これらを登録する下位マスタノード内のバックエンドメモリ(BEM)の領域は、少なくとも上位マスタノードから配信されたトランザクションデータによる更新命令を実行するトランザクションログ処理部が参照できるようにし、
     前記トランザクションログ処理部は、前記バックエンドメモリ(BEM)を参照して、この更新命令によって更新しようとしているテーブルの該当行が前記テーブル別書込セットの対応するテーブルのヒープタプルマップ(HTM)に含まれている場合、または統合書込セットのヒープタプルマップ(HTM)に含まれている場合には、当該ヒープタプルマップ(HTM)を生成しているトランザクションをアボートさせる請求項1~4のいずれか1項に記載のデータベースの管理方法。
  10.  更新が可能な上位と下位のマスタノードを階層的に有する追記型データベースの管理方法であって、
     いずれかの下位マスタノードのセッションにおいて、上位マスタノードに対して、当該下位のマスタノードのデータベースの更新対象となったテーブル情報を書込セットに登録して上位マスタノードに送信するステップと、
     前記上位マスタノードにおいて、データベースのテーブルに対するロック獲得命令が発生したときには、当該ロック獲得情報を下位マスタノードに通知するとともに、そのロック獲得情報を上位マスタノードに保持するステップと、
     前記上位マスタノードにおいて、前記下位マスタノードから受信した前記書込セット中のテーブル情報と前記で保持されたロック獲得情報とを比較して、競合するときには、前記書込セットをアボートするステップと、
     前記上位マスタノードからロック獲得情報を受信した前記下位マスタノードでは、ロック獲得情報と競合するトランザクションが存在しているときには、前記下位マスタノードにおいて当該トランザクションを廃棄するステップと、
     前記下位マスタノードにおいて前記上位マスタノードからのロック獲得情報に基づいて対象となるテーブルのロックを獲得するステップと
    からなる追記型データベースの管理方法。
PCT/JP2012/055923 2012-03-08 2012-03-08 データベースの管理方法 WO2013132628A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
PCT/JP2012/055923 WO2013132628A1 (ja) 2012-03-08 2012-03-08 データベースの管理方法
EP15162210.7A EP2933739B1 (en) 2012-03-08 2012-03-08 Database management method
EP12870808.8A EP2824576B1 (en) 2012-03-08 2012-03-08 Method for managing database
JP2014503377A JP5960798B2 (ja) 2012-03-08 2012-03-08 データベースの管理方法
US14/478,610 US10102263B2 (en) 2012-03-08 2014-09-05 Database management method
US16/117,860 US11151157B2 (en) 2012-03-08 2018-08-30 Database management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/055923 WO2013132628A1 (ja) 2012-03-08 2012-03-08 データベースの管理方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/478,610 Continuation US10102263B2 (en) 2012-03-08 2014-09-05 Database management method

Publications (1)

Publication Number Publication Date
WO2013132628A1 true WO2013132628A1 (ja) 2013-09-12

Family

ID=49116144

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/055923 WO2013132628A1 (ja) 2012-03-08 2012-03-08 データベースの管理方法

Country Status (4)

Country Link
US (2) US10102263B2 (ja)
EP (2) EP2824576B1 (ja)
JP (1) JP5960798B2 (ja)
WO (1) WO2013132628A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2824576B1 (en) * 2012-03-08 2018-11-21 Murakumo Corporation Method for managing database
CN113761059A (zh) * 2021-08-03 2021-12-07 阿里云计算有限公司 数据处理方法及装置
CN114048269B (zh) * 2022-01-12 2022-04-22 北京奥星贝斯科技有限公司 在分布式数据库中同步更新元数据的方法及装置
CN117453648A (zh) * 2023-10-08 2024-01-26 广州新赫信息科技有限公司 基于可信链高性能关系型数据库构建方法

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1185597A (ja) * 1997-09-04 1999-03-30 Fuji Electric Co Ltd 階層化された複数オブジェクトのロック制御方法
JPH11143762A (ja) * 1997-11-12 1999-05-28 Mitsubishi Electric Corp データ処理装置
JP2002149459A (ja) * 2000-11-10 2002-05-24 Mitsubishi Electric Corp 冗長化データベース管理・検索システム
JP2003296171A (ja) * 2002-03-29 2003-10-17 Fujitsu Ltd 電子帳票管理方法及びプログラム
JP2006293910A (ja) 2005-04-14 2006-10-26 Kokolink:Kk 安全で高速なデータベース・レプリケーション技術
JP2009230404A (ja) * 2008-03-21 2009-10-08 Nomura Research Institute Ltd データベースシステム及びデータベースシステムにおけるレプリカデータの更新方法
WO2010106991A1 (ja) 2009-03-19 2010-09-23 株式会社ココリンク データの複製管理方法及びシステム
JP2011248584A (ja) * 2010-05-26 2011-12-08 Nippon Telegr & Teleph Corp <Ntt> 分散データ管理システム、データサーバ、トランザクションサーバ、分散データ管理方法、プログラム

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5504899A (en) * 1991-10-17 1996-04-02 Digital Equipment Corporation Guaranteeing global serializability by applying commitment ordering selectively to global transactions
JPH05143434A (ja) 1991-11-18 1993-06-11 Toshiba Corp 分散データベースシステム
US6772154B1 (en) * 2000-11-16 2004-08-03 Sun Microsystems, Inc. Implementation of nested databases using flexible locking mechanisms
JP2003058404A (ja) * 2001-08-10 2003-02-28 Oki Electric Ind Co Ltd 分散データベースの同時実行制御システム
US6990503B1 (en) * 2002-04-12 2006-01-24 Ncr Corporation Rescheduling transactions in a database system
US7233947B2 (en) * 2003-05-22 2007-06-19 Microsoft Corporation Timestamping in databases
JP3660667B2 (ja) * 2003-07-29 2005-06-15 株式会社東芝 データ処理装置、データ処理方法およびプログラム
JP2005071238A (ja) 2003-08-27 2005-03-17 Nippon Telegr & Teleph Corp <Ntt> ファイル共有システム及び端末装置
JP4419824B2 (ja) 2004-12-10 2010-02-24 日本電気株式会社 レプリケーション制御システム、基幹サーバ、部門サーバ、更新ロック管理装置およびプログラム
US9400814B2 (en) * 2007-11-13 2016-07-26 Oracle International Corporation Hierarchy nodes derived based on parent/child foreign key and/or range values on parent node
US7962458B2 (en) * 2008-06-12 2011-06-14 Gravic, Inc. Method for replicating explicit locks in a data replication engine
GB2472620B (en) * 2009-08-12 2016-05-18 Cloudtran Inc Distributed transaction processing
US8396880B2 (en) * 2009-11-30 2013-03-12 Red Hat, Inc. Systems and methods for generating an optimized output range for a data distribution in a hierarchical database
US8620868B2 (en) * 2011-05-31 2013-12-31 Conexant Systems, Inc. Database hierarchical inheritance
WO2013076819A1 (ja) 2011-11-22 2013-05-30 株式会社Murakumo データベースの管理方法
JP5731015B2 (ja) * 2011-12-26 2015-06-10 株式会社日立製作所 データベースシステム及びデータベース管理方法
EP2824576B1 (en) * 2012-03-08 2018-11-21 Murakumo Corporation Method for managing database
US8612450B1 (en) * 2012-11-20 2013-12-17 Limelight Networks, Inc. Content tagging using multi-node hierarchical content assignments

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1185597A (ja) * 1997-09-04 1999-03-30 Fuji Electric Co Ltd 階層化された複数オブジェクトのロック制御方法
JPH11143762A (ja) * 1997-11-12 1999-05-28 Mitsubishi Electric Corp データ処理装置
JP2002149459A (ja) * 2000-11-10 2002-05-24 Mitsubishi Electric Corp 冗長化データベース管理・検索システム
JP2003296171A (ja) * 2002-03-29 2003-10-17 Fujitsu Ltd 電子帳票管理方法及びプログラム
JP2006293910A (ja) 2005-04-14 2006-10-26 Kokolink:Kk 安全で高速なデータベース・レプリケーション技術
JP2009230404A (ja) * 2008-03-21 2009-10-08 Nomura Research Institute Ltd データベースシステム及びデータベースシステムにおけるレプリカデータの更新方法
WO2010106991A1 (ja) 2009-03-19 2010-09-23 株式会社ココリンク データの複製管理方法及びシステム
JP2011248584A (ja) * 2010-05-26 2011-12-08 Nippon Telegr & Teleph Corp <Ntt> 分散データ管理システム、データサーバ、トランザクションサーバ、分散データ管理方法、プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TAKASHI INOUE: "System Kanri no Genba de Sugu ni Tsukaeru Jissen Knowhow! Shin Kino Quick Master Windows Server2003 Dai 11 Kai Shadow Copy Kino de Ukkari Sakujo ni Taisho suru", WINDOWS SERVER WORLD, vol. 9, no. 9, 1 September 2004 (2004-09-01), pages 128 - 131, XP008174819 *

Also Published As

Publication number Publication date
EP2824576A4 (en) 2015-09-09
JPWO2013132628A1 (ja) 2015-07-30
EP2933739B1 (en) 2019-10-09
EP2824576A1 (en) 2015-01-14
US20180373775A1 (en) 2018-12-27
US11151157B2 (en) 2021-10-19
US10102263B2 (en) 2018-10-16
EP2824576B1 (en) 2018-11-21
EP2933739A1 (en) 2015-10-21
JP5960798B2 (ja) 2016-08-02
US20140379644A1 (en) 2014-12-25

Similar Documents

Publication Publication Date Title
CN110196871B (zh) 数据入库方法和系统
CN109416694A (zh) 包括资源有效索引的键值存储系统
CN108509462B (zh) 一种同步活动事务表的方法及装置
US9020916B2 (en) Database server apparatus, method for updating database, and recording medium for database update program
US9922086B1 (en) Consistent query of local indexes
US11151157B2 (en) Database management method
JP4951138B2 (ja) データベースの管理方法
JP6008947B2 (ja) データベースの管理方法、データベースシステム、及び、プログラム
JP6239697B2 (ja) データベースの管理方法
JP5283769B2 (ja) データベースの管理方法、データベース管理システム、およびプログラム
WO2013076819A1 (ja) データベースの管理方法
WO2012169080A1 (ja) データベースの管理方法
dos Santos Almeida Geo-Replication in Large Scale Cloud Computing Applications

Legal Events

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

Ref document number: 12870808

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014503377

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2012870808

Country of ref document: EP