JP2018049394A - Database management device, database management method, and database management program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a database management device capable of improving responce performance to a writing request from plural clients, and a database management method and database management program.SOLUTION: A large unit lock is executed in a first mode with a restriction by an execution part other than the execution part which has execute the large unit lock, which a series of processing provided for writing to a first unit area included in an area where the large unit lock is allowed to be carried out.SELECTED DRAWING: Figure 8

Description

  Embodiments described herein relate generally to a database management apparatus, a database management method, and a database management program.

  In a database management apparatus used by a plurality of clients, there is a case where an operation called “lock” is performed in which one or both of the right to write to a certain area and the right to read are exclusively used. A mechanism for avoiding a deadlock that may occur due to a combination of lock types when a plurality of types exist is disclosed.

  In addition, there are cases where the lock is performed in small units such as records and the lock performed in large units such as pages, tables, and blocks. The method of switching the lock unit as needed is called lock escalation.

  In the conventional technique, when a lock performed in a large unit is executed, writing to the small unit included in the large unit is rejected at the lock request stage, so until the large unit lock is released, The processing necessary for writing to the small unit could not be performed. As a result, the responsiveness of the database management apparatus may be deteriorated when writing from a plurality of clients is requested redundantly.

Japanese Patent No. 5621904

  The problem to be solved by the present invention is to provide a database management apparatus, a database management method, and a database management program capable of improving the responsiveness when writing from a plurality of clients is requested.

  The database management apparatus according to the embodiment is configured to activate a plurality of database management units corresponding to a plurality of clients, respectively. Each of the plurality of database management units has an execution unit that executes processing for the shared storage shared by the plurality of database management units in accordance with a command acquired from a corresponding client. Each of the plurality of execution units includes a small unit lock that locks a part of the shared storage area in a first unit before performing a write process on the shared storage, or a part of the shared storage area or A large-unit lock is performed in which everything is locked in a second unit larger than the first unit. The large-unit lock allows, with restriction, processing for preparing for writing to the first unit area included in the area where the large-unit lock is performed by an execution unit other than the execution unit that performed the large-unit lock. In the first mode.

The figure which shows an example of a function structure and use environment of the database management apparatus 1 which concerns on 1st Embodiment. The figure which shows the management division of the shared storage 100 by the database management apparatus 1. FIG. The figure which shows an example of the content of the lock table. The figure which shows the effect of three modes regarding a table lock. The figure which shows an example of the hardware constitutions of the database management apparatus 1. The figure for demonstrating the advantage of a table lock. The figure which shows the scene where the table lock was made | formed by shared mode or exclusive mode. The figure which shows the scene where the table lock was made | formed by cooperation mode. 5 is a flowchart illustrating an example of a flow of processing executed by the lock control unit 22. 6 is a flowchart illustrating an example of a flow of processing executed by each thread 10 in response to a lock request result. The figure which shows transition etc. of the lock table 24 in 1st Embodiment. The figure which shows transition etc. of the lock table 24 in 1st Embodiment. The figure which shows transition etc. of the lock table 24 in 1st Embodiment. The figure which shows an example of the functional composition and use environment of 1 A of database management apparatuses which concern on a modification. The figure which shows an example of the content of the lock table 24B used in 2nd Embodiment. The figure which shows transition etc. of the lock table 24 in 2nd Embodiment. The figure which shows an example of a function structure and use environment of 1 C of database management apparatuses which concern on 3rd Embodiment. The figure which shows typically operation | movement of 1 C of database management apparatuses which concern on 3rd Embodiment.

  Hereinafter, a database management device, a database management method, and a database management program according to embodiments will be described with reference to the drawings. The database management apparatus according to the embodiment is realized by one or more processors. The database management device is a device that can start a plurality of threads (database management units) respectively corresponding to a plurality of clients and can respond to access requests to the shared storage from the plurality of clients. Each thread executes processing for the shared storage according to a command acquired from the corresponding client.

  In addition, when writing to the shared storage, each thread locks a small unit lock that locks a part of the shared storage area in the first unit, or a part or all of the shared storage area from the first unit. Perform a large unit lock that locks on a large second unit. In the following description, the first unit is assumed to be “record”, and the small unit lock is referred to as “record lock”. The second unit is assumed to be a “table”, and the large unit lock is referred to as a “table lock”.

  Also, in the following explanation, the thread requesting the lock is called “requester”, and the state where the lock is recognized and requested is called “acquiring”. The thread that acquires the lock is referred to as “acquirer”.

(First embodiment)
[Constitution]
FIG. 1 is a diagram illustrating an example of a functional configuration and usage environment of a database management apparatus 1 according to the first embodiment. The database management apparatus 1 accepts access requests from a plurality of clients CL-A, CL-B,. Hereinafter, when the client is not distinguished, it is simply referred to as a client CL. The client CL may be another computer device that communicates with the database management device 1 or may be a virtual processing entity in the database management device 1. In the former case, the client CL and the database management apparatus 1 communicate via a communication network such as a WAN (Wide Area Network), a LAN (Local Area Network), the Internet, or a dedicated line.

  The access request is a request for writing data to the shared storage 100 or reading data from the shared storage 100. The shared storage 100 is a disk device such as an HDD (Hard Disk Drive), a flash memory, another storage device, or a hybrid storage device in which a plurality of storage devices are combined.

  The database management device 1 activates the threads 10-A, 10-B,... For each client CL. Hereinafter, the thread 10-A may be abbreviated as thread A, the thread 10-B as thread B, and so on. In addition, when it is not distinguished which thread, the symbols below the hyphen that distinguish threads are omitted. The thread 10 includes a command analysis unit 12 and an execution unit 14. Each thread 10 secures a memory area used by itself in a working memory (described later).

  The command analysis unit 12 analyzes the content of the command received from the corresponding client CL, and provides it to the execution unit 14. The command is described in a format such as SQL. The command analysis unit 12 may not be included in the thread 10 but may distribute the analysis result to each thread 10.

  The execution unit 14 executes processing for the shared storage 100 according to the command acquired from the corresponding client and analyzed by the command analysis unit 12. The execution unit 14 executes record lock or table lock before performing write processing on the shared storage 100.

  FIG. 2 is a diagram showing management divisions of the shared storage 100 by the database management apparatus 1. As shown in the figure, a collection of records as a unit of writing is a page. A page is a unit to be committed. The commit will be described later. A collection of pages is a table.

  A lock request (hereinafter referred to as a lock request) by the execution unit 14 is output to the lock control unit 22 of the master management unit 20. The lock control unit 22 manages the lock table 24 based on the lock request input from the execution unit 14 of the thread 10 that is the requester.

  FIG. 3 is a diagram illustrating an example of the contents of the lock table 24. The lock table 24 is a table in which, for example, a table, table lock mode and acquirer identification information, and records included in each table and record lock acquirer identification information are associated with each other. Different table lock modes have different table lock effectiveness.

  In the present embodiment, the table lock mode includes at least a “cooperative mode”. The cooperative mode is a mode in which a process for writing to a record in the table by a thread 10 other than the person who acquires the table lock is allowed with a restriction. Further, in the cooperative mode, reading from the record in the table by the thread 10 other than the table lock acquirer may be permitted. Details will be described later.

  Further, the table lock mode may include an “exclusive mode” as illustrated. The exclusive mode is a mode that prohibits both writing and reading of records in the table by a thread 10 other than the table lock acquirer. The table lock mode may include a “shared mode”. The sharing mode is a mode in which writing by the thread 10 other than the table lock acquirer to the record in the table is prohibited and reading is permitted. FIG. 4 is a diagram showing the effectiveness of the three modes related to table lock.

  FIG. 5 is a diagram illustrating an example of a hardware configuration of the database management apparatus 1. Here, description will be made using reference numerals different from those in FIG. The database management apparatus 1 includes, for example, a client interface 50, a multi-core processor 60, a storage interface 70, a program memory 80, and a working memory 90. In addition, the example provided with a multi-core processor is an example to the last, and if it is provided with a plurality of processors as a processing subject, it can be suitably used.

  The client interface 50 includes a network interface such as a NIC (Network Interface Card).

  The multi-core processor 60 includes n processor cores 62 (1) to 62 (n). The processor core 62 (1) functions as a master core that executes the thread management program 82 stored in the program memory 80 and manages the execution status of the threads. The master core manages the relationship between the client CL and the thread 10 by the thread definition file 92 in the working memory 90. The master core corresponds to the master management unit 20 in FIG. It should be noted that the function for managing the execution status of the thread and the function for managing the lock may be realized by separate processor cores 62.

  The processor cores 62 (2) to 62 (n) function as slave cores by executing the thread execution program 84 stored in the program memory 80. Each of the slave cores is assigned to each thread area (slave core area) 96 (2) to 96 (n) in the working memory 90. Difference management information 98 is stored in each thread area 96 (2) to 96 (n).

  The program memory 80 is realized by, for example, a non-volatile memory such as a ROM (Read Only Memory), an HDD, or a flash memory. The working memory 90 is realized by a readable / writable memory such as a RAM (Random Access Memory), an HDD, a flash memory, or a register. The boundary between the program memory 80 and the working memory 90 need not be clear, and they may refer to different areas in the flash memory, for example.

  With such a configuration, the database management apparatus 1 can operate the plurality of threads 10 independently and asynchronously with each other. The advantage of this will be described later.

[Operation]
Hereinafter, the operation centering on the lock control of the database management apparatus 1 will be described. First, the advantages of table lock will be described. FIG. 6 is a diagram for explaining the advantages of the table lock. The left diagram in FIG. 6 shows the operation when the record lock is performed, and the right diagram shows the operation when the table lock is performed. Also, in the drawing, the stages of update processing, committing, and post-commitment are shown in order from the top. It is assumed that time flows in this order. FIG. 6 shows a case where the thread 10 writes the change data 1 and 2 to the record [002] of a certain page in the shared storage 100.

  When performing the record lock, first, the execution unit 14 of the thread 10 stores the change data 1 and 2 in the working memory 90 as the difference management information 98 and waits until it commits itself. Then, the execution unit 14 writes the change data 1 and 2 stored as the difference management information 98 to the shared storage 100 together with the execution of the commit. The change data is data obtained by integrating data to be changed with existing data when only a part of the record is changed. The change data may be the data itself to be changed when changing the whole record.

  The reason why the execution unit 14 does not directly write to the shared storage 100 when performing record locking is that, if writing directly to the shared storage 100, during the writing, the same page including the record to be written is included. This is because other threads may commit. In this case, there is a possibility that the data being written (in the shared mode) may be read by another thread 10 (that is, by a client CL different from the writing subject).

  When this phenomenon occurs, inconvenience occurs particularly when executing transaction processing. The transaction process is a process that includes a plurality of instructions and requires that all of the plurality of instructions have been executed (process consistency). For example, when considering processing in a bank, when there is a withdrawal from the account of user A and the deposit is made to the account of user B, it must be avoided that only one of them is stored in the shared storage. For example, in the example of FIG. 6, the data related to the withdrawal of the user A corresponds to the change data 1, and the data related to the payment of the user B corresponds to the change data 2. If the consistency of processing is not maintained, there is a possibility that user A will withdraw money and user B may refer to data that has not been deposited. In order to avoid such inconvenience, when record locking is performed, there is a process in which data stored as the difference management information 98 is not immediately written to the shared storage 100 but is written to the shared storage 100 in accordance with the execution of the commit. Done.

  On the other hand, when table locking is performed, locking is performed on a table basis, which is a unit larger than a page, so there is no concern that the above phenomenon will occur. For this reason, as shown in the right diagram of FIG. 6, the changed data can be written in the shared storage 100 as it is. The table lock also has an advantage that the lock table 24 can be easily managed.

  However, if the table lock is frequently used, writing by other threads 10 over a plurality of pages is excluded, so that the responsiveness may be adversely affected. FIG. 7 is a diagram illustrating a scene in which the table lock is performed in the shared mode or the exclusive mode. In this figure, the lock is acquired by the thread A, and a write command is transmitted from each client to the threads B, C, and D during the lock. In this case, the threads B, C, and D generate the difference management information 98 after waiting for the lock to be released by the thread A. Furthermore, if writing to the same page, writing to the shared storage 100 of other threads is possible. You must wait for it to finish before writing.

  On the other hand, in the table lock in the cooperative mode, the process of generating the difference management information 98 as a record in the table during the table lock by the thread 10 other than the table lock acquirer is allowed. When it is satisfied, the difference management information 98 generated during the table lock is allowed to be reflected in the shared storage 100. The predetermined condition will be described later.

  FIG. 8 is a diagram illustrating a scene where the table lock is performed in the cooperative mode. As shown in the figure, in the cooperative mode, threads B, C, and D that are not the table lock acquirer can generate the difference management information at an arbitrary timing even during the table lock. As a result, compared with the scene shown in FIG. 7, the overall processing time can be shortened, and the responsiveness can be improved.

  In the cooperative mode, the thread 10 attempting to write data in record units outputs a record lock request to the lock control unit 22. The lock control unit 22 writes the table lock status and the record lock status in the lock table 24. When a table lock is acquired in the shared mode or the exclusive mode, the lock control unit 22 rejects a lock request for a record in the table.

  Here, the above-mentioned “predetermined condition” will be described. Hereinafter, the thread 10 for which the predetermined condition is determined is referred to as a target thread 10 #. The predetermined condition is that the execution unit 14 (second execution unit) of the target thread 10 # receives data before the table lock is released by the execution unit 14 (first execution unit) of the thread 10 that is the table lock acquirer. This includes the fact that no record lock was made for the record to be written.

  In addition, the predetermined condition includes that the record to be written by the execution unit 14 of the target thread 10 # is not locked by another thread 10 before the target thread 10 #. May be. That is, it may be defined by a predetermined condition that the record lock can be acquired in the first-come-first-served basis among the threads 10 other than the table lock acquirer.

  The predetermined condition is determined by, for example, the lock control unit 22, and control based on this is performed. FIG. 9 is a diagram illustrating an example of a flow of processing executed by the lock control unit 22. The process of this flowchart is started when the lock control unit 22 receives a lock request from the execution unit 14 of any thread 10. In the following flowchart, when the lock request is rejected or the lock is executed, the lock control unit 22 notifies the requester of the result.

  First, the lock control unit 22 determines whether the lock target is a table or a record (step S100). When the lock target is a table, the lock control unit 22 determines whether a table lock by a thread other than the requester or a lock of a record included in the target table has been acquired (step S102).

  When the table lock by the thread other than the requester or the lock of the record included in the target table has been acquired, the lock control unit 22 rejects the table lock request (step S104). As described above, in the present embodiment, when a lock has already been acquired for a target table of a table lock or a record included in the target table, the table lock request is rejected.

  If the table lock by the thread other than the requester or the lock of the record included in the target table has not been acquired, the lock control unit 22 executes the table lock by the requester (step S106). In this case, the lock control unit 22 writes the table lock mode and the identification information of the acquirer in the items of the target table in the lock table 24. As the table lock mode, the current mode may be set for the entire database management apparatus 1, or the mode may be designated for each request by the table lock requester.

  On the other hand, when the lock target is a record, the lock control unit 22 determines whether or not the requester has acquired a table lock for the table including the target record (step S108). When the requester has acquired the table lock, the lock control unit 22 determines whether or not the record lock by the thread 10 other than the requester has been acquired for the record lock target record (step S110).

  When the record lock by the thread 10 other than the requester has been acquired, the lock control unit 22 issues a conflict notification to the thread 10 originally registered in the lock table 24, and the item of the target record in the lock table 24 Is overwritten with the identification information of the requester (step S112). As a result, the thread 10 that is the table lock acquirer deprives the record lock right from the other thread 10 that originally acquired the record lock. When the record lock by the thread 10 other than the requester has not been acquired, the lock control unit 22 executes the record lock by the requester (step S114). Note that step S114 is reached when the table lock acquirer makes a lock request for a record included in the table lock target table, and the acquired table lock mode is the cooperative mode. Limited to cases.

  If it is determined in step S108 that the requester has not acquired a table lock for the table including the target record, the lock control unit 22 determines whether a table lock has been acquired for the table to which the target record belongs. Is determined (step S116). When the table lock has been acquired for the table to which the target record belongs, the lock control unit 22 determines whether or not the table lock has been acquired in the cooperative mode (step S118). When the table lock is not acquired in the cooperative mode, the lock control unit 22 rejects the record lock request (step S122).

  When a negative determination is obtained in step S116, or when a positive determination is obtained in step S118, the lock control unit 22 determines whether or not a record lock has been acquired for the target record by a person other than the requester. (Step S120). The lock control unit 22 rejects the record lock request when the record lock has been acquired by a party other than the requester (step S122), and executes the record lock by the requester when the record lock has not been acquired by a party other than the requester. (Step S124). At this time, the lock control unit 22 notifies the requester of the table lock status for the table to which the target record to which the record lock is performed belongs.

  The manner in which the lock control unit 22 performs the processing shown in FIG. 9 in an integrated manner is merely an example, and each thread 10 makes its own determination with reference to the lock table 24, and as a result, the processing shown in FIG. You may implement | achieve the process equivalent to.

  FIG. 10 is a flowchart illustrating an example of the flow of processing executed by each thread 10. The process of this flowchart is started when, for example, the thread 10 tries to write to the shared storage 100 and issues a lock request. Therefore, the process shown in FIG. 9 and the process shown in FIG. 10 are executed in parallel by the thread 10 and the lock control unit 22.

  First, the thread 10 acquires the table to which the lock target record belongs, or the lock status of the lock target table from the lock control unit 22 (step S200).

  Next, the thread 10 determines whether or not itself is in the table lock (step S202). If the table itself is locked, the thread 10 reflects the write data in the shared storage 100 and commits (step S204).

  If the table 10 is not locked, the thread 10 determines whether or not the record 10 is locked (step S206). If the thread itself is in record lock, the thread 10 generates difference management information (step S208). Next, the thread 10 determines whether or not a table lock is acquired in the cooperative mode by another thread 10 and is in a release waiting state (step S210).

  When a negative determination is obtained in step S210, the thread 10 reflects the generated difference management information in the shared storage 100 and commits (step S212). On the other hand, when a positive determination is obtained in step S210, the thread 10 waits for the table lock to be released (step S214), and reflects the generated difference management information in the shared storage 100 (step S212). If a conflict notification is received before the table lock is released (step S216), the thread 10 discards the difference management information (step S218), and ends the processing of this flowchart. Further, an upper limit may be set for the time for waiting for release in the cooperative mode (or the number of clocks, the number of cycles, etc.), and the process may proceed to step S218 when the upper limit is reached.

  If it is determined in step S206 that the thread itself is not locked, that is, if a table lock (non-emphasis mode) or a record lock has been acquired by another thread 10, the thread 10 ends the processing of this flowchart. . When the difference management information is discarded in step S218 and when it is determined in step S206 that the difference management information is not locked, the thread 10 returns an error response to the client CL and waits again until a write command is received.

  Hereinafter, scenes that occur as a result of the processing of the flowcharts shown in FIGS. 9 and 10 will be described. FIG. 11 is a diagram illustrating the transition of the lock table 24 when the requester of the record lock is not the acquirer of the table lock and the lock is not acquired for the record lock target record.

  As shown in the figure, first, a table lock is acquired by the thread A in the cooperative mode. For example, the thread A further acquires a record lock for the record [001] and then starts writing. At this time, since the thread A has acquired the table lock, the write data is directly reflected in the shared storage 100.

  While the table lock is acquired by the thread A, the record lock is acquired for the record [002] by the thread B. The thread B generates difference management information, waits for the release of the table lock, and reflects the difference management information in the shared storage 100.

  FIG. 12 is a diagram showing the transition of the lock table 24 when the requester of the record lock is not the acquirer of the table lock and the lock is acquired for the record lock target record.

  In this case, while the table lock is acquired by the thread A, the record lock is acquired for the record [002] by the thread C. Thereafter, a lock request is made to the record [002] by the thread B, but is rejected because the record lock has already been acquired by the thread C. After the thread C acquires the record lock, the thread C generates difference management information, waits for the release of the table lock, and reflects the difference management information in the shared storage 100.

  FIG. 13 shows that the requester of the record lock is not the acquirer of the table lock and the lock can be acquired for the target record of the record lock, but the target record is acquired by the acquirer of the table lock until the release of the table lock. It is a figure which shows transition etc. of the lock table 24 when a record lock is requested | required.

  In this case, while the table lock is acquired by the thread A, the record lock is acquired for the record [002] by the thread B. The thread B starts to generate the difference management information, but before the table lock is released, the lock request is made to the same record [002] by the thread A who is the table lock acquirer. In this case, the thread A is replaced and becomes the acquirer of the record [002], and the difference management information of the thread B is discarded.

  As described above, according to the first embodiment, the table lock is a limited process for preparing for writing to the record included in the table on which the table lock is performed by the thread 10 other than the table lock acquirer. It is executed in an allowed cooperative mode. As a result, it is possible to improve responsiveness when writing from a plurality of clients CL is requested.

  In the first embodiment, it is preferable that the cooperative mode and the exclusive mode are switched based on, for example, an instruction from the client CL or an operation by an operator. FIG. 14 is a diagram illustrating an example of the functional configuration and usage environment of the database management device 1A according to the modification. As illustrated, the master management unit 20 includes a mode selection unit 26. The mode selection unit 26 switches the table lock mode between at least the cooperative mode and the exclusive mode based on an instruction from the client CL or an operation by the operator. Regarding switching of the table lock mode, it may be instructed to maintain a constant mode regardless of the command, or may be instructed for each command. Such a configuration may be applied to a second embodiment or a third embodiment described later.

(Second Embodiment)
Hereinafter, the second embodiment will be described. FIG. 15 is a diagram illustrating an example of the contents of the lock table 24B used in the second embodiment. In the second embodiment, the table lock in the cooperative mode can be acquired by a plurality of threads 10 for the same target table. However, the table lock has an order, and the thread 10 having the higher order can write preferentially. In FIG. 15, this is expressed as a first table lock, a second table lock,. The acquirer of the first table lock has the same effect as the acquirer of the table lock in the first embodiment for all other threads 10. The acquirer of the second table lock has the same effect as the acquirer of the table lock in the first embodiment for the thread 10 other than the acquirer of the first table lock. The same applies to the third table lock and below. Each table lock is acquired on a first-come-first-served basis. Even in the cooperative mode, if a record lock has already been acquired for a record belonging to the target table, no table lock can be acquired.

  That is, the acquirer of the first table lock has a priority regarding the record lock with respect to all other threads 10. Further, the acquirer of the second table lock has a priority regarding the record lock with respect to the thread 10 other than the acquirer of the first table lock.

  FIG. 16 is a diagram illustrating the transition of the lock table 24 in the second embodiment. As shown in the figure, first, the first table lock is acquired by the thread B in the cooperative mode. For example, the thread B further acquires a record lock for the record [001] and then starts writing. At this time, since the thread B has acquired the table lock, the write data is directly reflected in the shared storage 100. Subsequently, the second table lock is acquired by the thread A.

  While the first table lock is acquired by the thread B and the second table lock is acquired by the thread A, the record lock is acquired for the record [002] by the thread C. The thread C generates difference management information. On the other hand, the thread A who is the acquirer of the second table lock makes a lock request for the record [001], but since the record lock has already been acquired by the thread B who is the acquirer of the first table lock, Rejected.

  Thereafter, the lock request for the same record [002] as the thread C is made by the thread A who is the acquirer of the second table lock until the first table lock is released. In this case, the thread A is replaced and becomes the acquirer of the record [002], and the difference management information of the thread C is discarded. The thread A generates difference management information, and reflects the difference management information in the shared storage 100 along with the release of the first table lock.

  According to the second embodiment described above, the same effects as those of the first embodiment can be obtained, and multilayer management can be realized particularly when the table size is large.

(Third embodiment)
Hereinafter, a third embodiment will be described. FIG. 17 is a diagram illustrating an example of a functional configuration and usage environment of a database management apparatus 1C according to the third embodiment. As illustrated, the database management device 1C is different from the first embodiment in that the thread 10 has a difference aggregation unit 30 and a function related thereto.

  FIG. 18 is a diagram schematically illustrating the operation of the database management apparatus 1C according to the third embodiment. As illustrated, each thread 10 according to the third embodiment outputs the generated difference management information to the difference aggregating unit 30 when generating the difference management information. The difference aggregating unit 30 aggregates the difference management information input from each thread 10 and, for example, rearranges them in the order of stored addresses, and writes them together in the shared storage 100 when the table lock is released.

  As a result, it is possible to perform more efficient processing than when each thread 10 independently writes to the shared storage 100. If only one storage interface 70 shown in FIG. 5 is provided, the order in which the storage interfaces 70 are used among the threads 10 must be arbitrated. Further, if a plurality of storage interfaces 70 are provided, the cost increases. On the other hand, according to the configuration shown in the third embodiment, the difference aggregating unit 30 manages the data to be written to the shared storage 100 in an integrated manner, so that the above arbitration processing is not necessary, and address reference is performed. Since the order can be determined in an efficient order, efficient processing can be realized.

  According to the third embodiment described above, the same effects as those of the first embodiment can be obtained, and efficient write processing to the shared storage 100 can be performed.

  In each of the embodiments described above, the first unit is “record”, the small unit lock is “record lock”, the second unit is “table”, and the large unit lock is “table lock”. Not limited to. As long as the first unit and the second unit have a relationship in which the second unit is larger than the first unit, “record group in which a plurality of records are collected”, “page”, “page group”, “block”, It can be arbitrarily selected from units such as “block group” and “whole database”. Further, the small unit lock and the large unit lock may correspond to arbitrarily selected first unit and second unit.

  According to at least one of the embodiments described above, the table lock allows the processing for preparing for writing to the record included in the table on which the table lock is performed, by the thread 10 other than the table lock acquirer, with limitation. It is executed in cooperative mode. As a result, it is possible to improve responsiveness when writing from a plurality of clients CL is requested.

  Although several embodiments of the present invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the spirit of the invention. These embodiments and their modifications are included in the scope and gist of the invention, and are also included in the invention described in the claims and the equivalents thereof.

DESCRIPTION OF SYMBOLS 1 ... Database management apparatus, 10 ... Thread, 12 ... Command analysis part, 14 ... Execution part, 20 ... Master management part, 22 ... Lock control part, 24 ... Lock table, 26 ... Mode selection part, 30 ... Difference aggregation part, 60 ... multi-core processor, 62 ... processor core, 100 ... shared storage

Claims (12)

A database management device configured to start a plurality of database management units corresponding to a plurality of clients,
Each of the plurality of database management units has an execution unit that executes processing for the shared storage shared by the plurality of database management units according to a command acquired from a corresponding client,
Each of the plurality of execution units includes a small unit lock that locks a part of the shared storage area in a first unit before performing a write process on the shared storage, or a part of the shared storage area or Performing a large unit lock that locks all in a second unit greater than the first unit;
The large-unit lock allows, with restriction, processing for preparing for writing to the first unit area included in the area where the large-unit lock is performed by an execution unit other than the execution unit that performed the large-unit lock. Executed in the first mode,
Database management device. The plurality of execution units can operate asynchronously with each other using distributed hardware resources.
The database management apparatus according to claim 1. When the large unit lock is executed in the first mode by the first execution unit among the plurality of execution units, a second execution unit other than the first execution unit among the plurality of execution units is predetermined. If the condition is satisfied, difference management information for writing to the shared storage in the first unit is generated and stored in the memory, and when the large unit lock in the first mode is released, the memory Reflect the difference management information stored in the shared storage,
The database management apparatus according to claim 1 or 2. Each of the plurality of execution units executes the small unit lock for the first unit included in the second unit that is a target of the large unit lock when the large unit lock is being executed. Sometimes
The predetermined condition includes that a small unit lock is not executed by the first execution unit with respect to a first unit to which the second execution unit attempts to write,
The database management apparatus according to claim 3. The predetermined condition further includes that the small unit lock is not executed first by another second execution unit with respect to the first unit to which the second execution unit is to write.
The database management apparatus according to claim 3 or 4. The difference management information generated by the plurality of execution units is aggregated, and when the large-unit lock in the first mode is released, the aggregated difference management information is shared on behalf of the plurality of execution units It further includes a difference aggregation unit to be reflected in the storage,
The plurality of execution units respectively output the generated difference management information to the difference aggregation unit.
The database management device according to any one of claims 3 to 5. The large unit lock according to the first mode is acquired by a plurality of execution units with a priority based on a first-come-first-served basis.
The database management apparatus according to any one of claims 1 to 6. The large unit lock in the first mode is rejected when the lock in the first unit has already been acquired for the target second unit region,
The database management device according to claim 1. A mode switching unit for switching the mode of the large unit lock between the first mode and another mode;
The database management device according to claim 1. A commit is executed in a third unit larger than the first unit;
The third unit of data in the shared storage is read in the state before update until a commit is executed.
The database management apparatus according to any one of claims 1 to 9. The database management device
Start multiple database managers corresponding to multiple clients,
Each of the plurality of database management units includes an execution unit that executes processing for the shared storage shared by the plurality of database management units according to a command acquired from a corresponding client.
Before each of the plurality of execution units performs a write process on the shared storage, a small unit lock that locks a part of the shared storage area in a first unit, or a part of the shared storage area or Performing a large unit lock that locks all in a second unit greater than the first unit;
Allowing the large-unit lock to be processed with a restriction by the execution unit other than the execution unit that has performed the large-unit lock with a limitation in preparation for writing to the first unit area included in the large-unit lock area. Running in the first mode,
Database management method. In the database management unit,
Start multiple database managers corresponding to multiple clients,
Each of the plurality of database management units includes an execution unit that executes processing for the shared storage shared by the plurality of database management units according to a command acquired from a corresponding client.
Before each of the plurality of execution units performs a write process on the shared storage, a small unit lock that locks a part of the shared storage area in a first unit, or a part of the shared storage area or Performing a large unit lock that locks all in a second unit greater than the first unit;
Allowing the large-unit lock to be processed with a restriction by the execution unit other than the execution unit that has performed the large-unit lock with a limitation in preparation for writing to the first unit area included in the large-unit lock area. To run in the first mode
Database management program.

Images