JP2010033599A - Unshared database management system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method of adding a database server with little effect on a table from a user or application to an unshared database management system, and a method of removing therefrom. <P>SOLUTION: A server is added according to a schedule for separately treating addition of a CPU resource and addition of a storage I/O using a scheduler module (4). The server is removed at optional timing using a shared disc. The data region is previously fragmented on the shared disc for dispensing with data transfer due to addition of the server. When applied in an operating method determining addition and removal of new servers in response to a load of the database server, a threshold of a load following determination is set highly, and there are effects such as improving an operating ratio of the servers, and reducing the number of pool servers. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a non-shared database management system that does not share data to be processed between database servers constituting the database management system.

<Background explanation, definition of terms>
"Non-shared database management system"
The non-shared database management system is one of the construction methods of a large-scale database system composed of a plurality of database servers. In the non-shared database management system, the processor, memory and storage, which are the main elements of the computer, are allocated to each database server and do not share components other than the network. Data constituting the database is also distributed to each database server and stored in the allocated storage. Therefore, each database server takes charge of a disjoint subset of the database as processing target data, and performs processing for each subset.

  Due to the characteristics of such a configuration, the non-shared database management system does not require exclusive control processing for shared resources, and has an advantage of high scalability against an increase in the number of database servers. However, if there is an imbalance in the amount of data handled between database servers due to system configuration changes, etc., the execution time of the database server with a large amount of data will become relatively long, and the entire query processing will be efficient. No longer done. For this reason, the non-shared database system has a disadvantage in that when changing the number of database servers, it is necessary to change the allocation of data to the servers in order to balance the data handled among the database servers. .

"Database Server Resources"
When a new database server is added to the non-shared database management system, a new server machine is generally added and the database server is executed on the new server machine. By adding a new server machine, resources for executing the database server increase, leading to performance improvement. In the present invention, among the resources, those related to improving the computing ability are referred to as “CPU resources”. In addition, a storage I / O performance improvement is called a “storage I / O resource”.

"Data Relocation"
As described above, when adding a new database server to the non-shared database management system or removing a database server from the non-shared database management system, it is necessary to balance data among the database servers. In the present invention, this operation is hereinafter referred to as “data rearrangement”.

"Storage Virtualization"
Storage virtualization is one means for improving the usability of storage on a network. There are multiple storage units on the network, and when using them from a single server, it is possible to consolidate operation management into one by making it appear as if a single storage is being used. It leads to reduction of. In the present invention, a place where storage virtualization is performed is referred to as a “(storage) virtualization layer”. The storage virtualization layer generally exists on the storage, storage management middleware, and file system. The operating system manages storage in units of volumes. Therefore, in the present invention, the virtualized storage is referred to as a “logical volume”. Further, individual storages constituting the logical volume are referred to as “unit volumes”.

<Description of conventional method>
As a conventional method, there is a method of using an ALTER NODEGROUP statement described in the online manual “Administrator's Guide Chapter 30” attached to DB2 version 7.2. In this method, as shown in FIG. 2A, when a new database server is added, a data area is added to the storage allocated to the new database server (21), and a non-shared database management consisting of a plurality of database servers is performed. After adding a new database server (22) to the system, the data is rearranged between the database servers (23) in order to balance the amount of data. When the database server shown in FIG. 2B is removed, data is rearranged to empty the data area of the database server to be removed (24), and then the database server is removed (25). It was.

  As another conventional method, there is a parallel database management method described in JP-A-11-282734. In this method, the database managed by a plurality of database processing devices can be directly accessed from a specific database processing device by changing the association between the database and the database processing device without interrupting the online operation. In addition, this method is characterized in that the number of database divisions is unchanged.

Japanese Patent Laid-Open No. 11-282734

  The above-mentioned prior art does not consider the case where database servers are frequently added or removed in a non-shared database management system, and database servers can be added or removed without long-time data relocation. There was no problem. Furthermore, since data rearrangement is a processing with a high load, the performance of access processing to a table from a user or an application is lowered when it is simply executed. Therefore, when applied to a system in which the number of servers can be changed according to the load, there is a problem that the addition of servers is not reflected in the improvement in processing performance without causing a delay, but rather may cause a decrease in processing performance. It was. Further, since data rearrangement is performed after deciding to remove the server, there is a problem that there is a delay until the server can be actually removed.

  In addition, in the method described in Japanese Patent Application No. 10-81097, when the load distribution is corrected by converting the correspondence between the database and the database processing device, the number of database divisions does not change, so the database processing It is difficult to balance the load between devices. Even with this method, it is possible to balance the load by dividing the database in advance, but in this case, a large number of databases are created, which increases operational management costs such as vacuum and backup. An object of the present invention is to provide a method for adding and removing a database server that has little influence on the performance of access processing to a table from a user or an application.

  The non-shared database management system of the present invention includes a plurality of back-end modules for searching and calculating data, and a plurality of unit volumes each storing a fragmented part of the data constituting the database. A plurality of units are associated with the shared storage shared by the back-end modules and the plurality of virtual volumes each accessible from any one of the plurality of back-end modules so that at least one of the unit volumes does not overlap. Storage virtualization means for associating a unit volume with a virtual volume so that each of the volumes can be accessed from any one of a plurality of back-end modules, and the correspondence between the data held in the unit volume and the back-end module Mapping that manages the stored correspondence table Module and a front-end module that accepts queries to the database and creates a query plan for the back-end module by referring to the mapping module mapping information, and changes the association between the unit volume and the virtual volume Thus, the data area allocated to the back-end module is changed.

  According to the present invention, by combining data relocation associated with addition and removal processing of database server resources in a non-shared database management system with a storage virtualization layer, data movement is replaced with virtual volume update, Data relocation without data movement is possible, and a non-shared database management system capable of increasing the server operation rate can be realized.

  In addition, by taking a method of subdividing the data area on the shared disk in advance, CPU resources and storage I / O can be added and removed without delay, and data relocation and unnecessary extras are required. Since no load is generated, the load threshold when deciding whether to add or remove a new server can be set high according to the load on the database server, as in the previous case, improving the server operation rate and the number of pool servers The effect is to reduce.

It is a block diagram which shows the outline of the non-shared database management system of the Example of this invention. It is a flowchart of addition and removal of a database server by a conventional method. It is a block diagram at the time of assigning one data area per backend module of the said Example. It is a flowchart which shows the addition procedure of the server which corresponds to the said Example. It is a flowchart which shows the procedure of the removal of the server which corresponds to the said Example. It is a block diagram of the back end module of another Example of this invention using the data area subdivided on the shared storage. It is a data structure figure of the hash-module ID correspondence table | surface in the said Example. It is a flowchart which shows the addition procedure of the server of the said Example. It is a flowchart which shows the procedure of removal of the server of the said Example. It is a block diagram of further another Example of this invention using the virtualization layer on shared storage. It is a block diagram of further another Example of this invention using the virtualization layer on storage management middleware. It is a block diagram of another Example of this invention using the virtualization layer on a shared file system. It is a block diagram of another Example of this invention using the virtualization layer on a database management system.

  An embodiment of the present invention will be described below with reference to FIG.

  The non-shared database management system (1) in the present embodiment includes a front-end module (2) mainly serving as a user interface, a back-end module (3) for searching and calculating data, and database server addition and removal operations. A scheduler module (4) for creating a schedule, a server monitoring module (5) for monitoring the load on the database server, a shared storage (6) shared among a plurality of back-end modules, and between the back-end module and the shared storage It has a mapping module (7) that manages the mapping.

  Further, the back-end module is logically divided into an active server group (8) and a pool server group (9) for management. The front-end module (2) is a module that accepts queries from users or programs, creates query plans for a plurality of database servers, and returns the results. In this embodiment, since the configuration of the active server group is dynamically changed, the front-end module also has a function of issuing a query corresponding to the configuration of the active server group correspondingly.

  The back-end module (3) is a module that operates on the database server, searches for data on the storage, and calculates the result. In this embodiment, one back-end module is activated per server. The detailed structure will be described later. The scheduler module (4) is a module for creating a schedule for adding and removing database servers. In accordance with the schedule created by the scheduler module, the server monitoring module issues an instruction to the back-end module. The server monitoring module (5) monitors the CPU load of each database server and further serves as a coordinator for database server addition and removal processing. Allocation of storage resources to the database server is delegated to the mapping module.

  The shared storage (6) is logically configured on a storage dedicated network. For each back-end module, a dedicated data area is secured on the shared storage, so no resource contention occurs between the back-end modules. Upon receiving a request from the server monitoring module, the mapping module (7) links the back-end module and the storage area on the shared storage.

  Communication between these modules 2 to 5 and 7 is performed asynchronously. In this embodiment, asynchronous communication using a queue is performed. Two queues are prepared to give priority to communication, and a normal queue and a special queue with high priority are used.

  The active server group (8) represents a set of servers currently involved in data processing among a plurality of database servers, and the pool server group (9) is not currently involved in data processing, and the entire system is in a high load state. It represents a set of spare servers at that time. The pool server group can be shared among a plurality of non-shared database management systems. This method is effective in increasing the server operation rate.

“Configuration of back-end module when one data area is allocated per back-end module”
FIG. 3 shows the configuration of the back-end module when one data area is allocated per back-end module. The back end module (31) is associated with one data area (33) on the shared storage (32). Also, consider a back-end module (34) that is not assigned to a data area under this configuration. The back-end module (31) is assigned a shared data area on the shared storage by the mapping module. Each back-end module stores data to be processed in the assigned data area and performs a search. It also performs data operations such as sorting and merging. This may be done while exchanging data between multiple backend modules.

  The data area (33) mainly stores a sparse subset of the database. In addition, intermediate results of data calculations, data operation histories, and the like are also stored. The back-end module (34) having no data area does not search for data, and is set exclusively for operations such as sorting and merging with high CPU load. Data to be operated is transferred from other backend modules via the network. A back-end module that does not have a data area provides only CPU resources to the active server group. On the other hand, the normal back-end module shown at 31 provides both CPU resources and storage I / O.

<Description of operation when one data area is allocated per backend module>
"Adding Servers"
When the server monitoring module detects a high load, a server addition process is started, and a process flow shown in FIG. 4 is created by the scheduler module (4). In the processing flow, first, a new addition server is prepared (41). Here, an appropriate server is selected from the pool server group, and the configuration information of the active server group is transmitted.

  Next, the prepared server is added from the pool server group to the active server group (42). Here, since a server is added as a back-end module (34) having no data area, data is not moved. Therefore, it is performed very quickly as compared with the case where the conventional method is used. By adding a back-end module having no data area in 42, the load on the active server group is reduced. From the load reduction rate and past statistical information, it is determined whether the high load detected this time is transient or it means a long-term shortage of resources in the active server group (43).

  If this means a shortage of resources in the active server group, it is desirable to add a storage I / O together by assigning a data area to a back-end module that does not have a data area added in 42. However, as described above, data rearrangement is a heavy operation. Therefore, it waits until the load on the active server group is sufficiently reduced (44). Then, data rearrangement is performed after the load is reduced (45).

  On the other hand, if it is determined in 43 that the high load on the active server group is transient, the server on which the back-end module that does not have the data area added this time operates is returned to the pool server group. In this case, after waiting (46) until the load is sufficiently reduced, the back-end module having no data area added in 42 is removed, and the corresponding server is returned to the pool server group (47). This reduces the total number of pool servers when the pool server group is shared among a plurality of database management systems, and increases the actual operation rate of the servers. When changing the configuration of the active server group (42), it is necessary to guarantee the ACID characteristics of the transaction. In the database management system of this embodiment, the ACID characteristic is guaranteed by waiting for the end of the transaction currently being executed without starting a new transaction, and then performing a configuration change by synchronizing all back-end modules.

"Removing the Server"
When the server monitoring module detects a low load, the server removal process is started, and the scheduler module (4) creates the process flow shown in FIG.

  In the processing flow, first, the configuration of the active server group is changed (51). Here, the back-end module running on the server together with an arbitrary database server is removed from the active server group, and the corresponding data area is assigned to the other back-end module (51-A). This operation leads to data imbalance. Further, the removed database server is returned to the pool server group in order to increase the actual operation rate of the server. Next, data rearrangement is performed (52). The purpose of the data rearrangement here is to empty the data area allocated to the other back-end module (51-A) at 51. By this operation, the amount of data allocated to the active server group is substantially balanced. Note that the processing flow shown in FIG. 5 is performed in a state where the active server group has a low load, and therefore, the influence of the load increase due to the data rearrangement does not matter. After the data rearrangement is completed, the data area emptied in 52 is completely deleted (53).

"Configuration of back-end module using data area segmented on shared storage"
FIG. 6 shows the configuration of another embodiment of the present invention. FIG. 6 shows only the relationship between the back-end module and each area in the shared storage, but the components of the entire database management system are the same as those in the previous embodiment shown in FIG. In this embodiment, the data area 63 of the shared storage 62 is subdivided into smaller units rather than corresponding to the back-end module 61 in charge of the data search processing and arithmetic processing. The subdivision is performed by, for example, a hash division method using a hash value of a region identifier. However, the allocation of the data area to each back-end module is not directly determined by the hash value, but is determined by a hash value / module ID correspondence table that records and manages the correspondence between the hash value and the back-end module in charge. With this configuration, it is possible to change the allocation of the data area required when additional back-end modules are added or reduced by simply updating the hash value / module ID correspondence table. This allocation change can be performed instantaneously because it does not involve actual movement of data. Therefore, when adding or deleting a back-end module, it is possible to avoid the performance degradation of the access processing inherent in the database management system, compared to the previous embodiment.

  FIG. 7 shows an example of the hash-module ID correspondence table so that the front-end module can transfer the query to an appropriate back-end module when the back-end module to which the data area belongs changes. A back-end module ID 73 is set corresponding to each hash value 71 of the identifier of the data area. The setting may be distributed so that the total data amount in the data area in charge or the frequency of data access is made as uniform as possible between the back-end modules. This hash-module ID correspondence table is managed by a mapping module (see FIG. 1). When the front-end module makes a schedule, it queries the mapping module and selects an appropriate back-end module.

<Explanation of operation when subdivided data area is used on shared storage>
"Adding Servers"
When the server monitoring module detects a high load, server addition processing is started, and a processing flow shown in FIG. 8 is created by the scheduler module (4).

  In the processing flow, a new addition server is first prepared (81). Here, as in 41, an appropriate server is selected from the pool server group, and the configuration information of the active server group is transmitted. Next, the configuration of the active server group is changed (82). Here, the server prepared in 81 is added, and the back-end module is added. Furthermore, the allocation data area is changed in order to balance the allocation data amount among all back-end modules. As described above, the allocation data area is changed instantaneously.

"Removing the Server"
When the server monitoring module detects a low load, a server addition process is started, and a process flow shown in FIG. 9 is created by the scheduler module (4).

  In the processing flow, the configuration of the active server group is changed (91). Here, an appropriate back-end module is removed, and the corresponding server is returned to the pool server group. Furthermore, the allocation data area is changed in order to balance the allocation data amount among all back-end modules. As described above, the allocation data area is changed instantaneously.

"Explanation of operation when using virtualization layer on shared storage"
FIG. 10 shows a configuration of an embodiment using a virtual volume virtualized by the storage virtualization layer (103) on the shared storage. Each of the plurality of back-end modules 101 performs data search and data calculation. The target of the data search is each virtual volume 105. The storage virtualization layer 103 provided in the shared storage 102 associates a plurality of unit volumes 106 on the shared storage with the virtual volume 105. A map 10A is used for the association. Again, hash partitioning is used to distribute data between back-end modules. That is, data with the same hash value of the data identifier handled by the backend module is regarded as data belonging to the same data group 107. These data groups are arranged in the unit volume 106 without duplication. The minimum unit of data movement that occurs when a new back-end module is added or deleted is the above data group.

  In this embodiment, the data movement (108) in units of data groups can be replaced with the movement of the corresponding unit volume (106) in the database. After the replacement, the map is transferred to the storage virtualization layer (103) on the storage, and the storage virtualization layer rewrites the map (10A) so as to correspond to the data movement (108) (109). In this way, data movement without physical movement is realized by using the storage virtualization layer (103).

"Explanation of operation when using virtualization layer on storage management middleware"
In FIG. 11, reference numeral 111 denotes a back-end module when the storage (115) virtualized by the storage virtualization layer (113) on the storage management middleware is used. The storage management middleware enters between the backend module (111) and the shared storage (112), manages the data area allocation for each backend module, and allocates the virtual volume (115). The data area allocation is realized as an association between the unit volume (116) on the shared storage (112) and the virtual volume (115). A map (11A) is used for the association. Again, hash partitioning is used to distribute data between back-end modules. Furthermore, the thing with the same hash value shall be arrange | positioned in the same data group (117), and let it be the minimum unit of data movement. Each data group is arranged in the unit volume (116) without duplication.

  Also in this embodiment, the data movement (118) in units of data groups can be replaced with the movement of the corresponding unit volume (116) in the database. After the replacement, the map is transferred to the storage virtualization layer (113) on the storage management middleware, and the storage virtualization layer rewrites the map (11A) so as to correspond to the data movement (118) (119). In this way, data movement without physical movement is realized by using the storage virtualization layer (113) on the storage management middleware.

"Explanation of operation when using virtualization layer on shared file system"
In FIG. 12, reference numeral 121 denotes a back-end module when the storage (125) virtualized by the storage virtualization layer (123) on the shared file system is used. Here, a server-client type file system such as NFS is assumed as the file system. The file system enters between the back-end module (121) and the shared storage (122), manages the data area allocation for each back-end module, and allocates the virtual volume (125). The data area allocation is realized as an association between the unit volume (126) on the shared storage (125) and the virtual volume (125). A map (12A) on the file server is used for the association. Again, hash partitioning is used to distribute data between back-end modules. Furthermore, the thing with the same hash value shall be arrange | positioned in the same data group (127), and let it be the minimum unit of data movement. Each data group is arranged in the unit volume (126) without duplication.

  Also in this embodiment, the data movement (128) in units of data groups can be replaced with the movement of the corresponding unit volume (126) in the database. After the replacement, the map is transferred to the storage virtualization layer (123) on the file system, and the storage virtualization layer rewrites the map (12A) so as to correspond to the data movement (128) (129). In this way, data movement without physical movement is realized by using the storage virtualization layer (123) on the file system.

"Explanation of operation when using virtualization layer on database management system"
In FIG. 13, reference numeral 131 denotes a back-end module when the virtual volume (135) on the storage (134) virtualized by the storage virtualization layer (133) built in the database management system is used. The storage virtualization layer associates a plurality of unit volumes (136) on the shared storage (132) on the shared storage with the virtual volume. For the association, the map (13A) on the map management module (13B) is used. Again, hash partitioning is used to distribute data between back-end modules. Furthermore, the thing with the same hash value shall be arrange | positioned in the same data group (137), and it is set as the minimum unit of data movement. Each data group is arranged in the unit volume (136) without duplication.

  Also in this embodiment, the data movement (138) in units of data groups can be replaced with the movement of the corresponding unit volume (136) in the database. After the replacement, the map is transferred to the storage virtualization layer (133), and the storage virtualization layer rewrites the map (13A) so as to correspond to the data movement (138) (139). In this way, data movement without physical movement is realized by using the storage virtualization layer (133) on the storage management middleware.

  According to the present invention, it is possible to avoid an increase in load due to processing by shifting data relocation associated with addition and removal processing of database server resources in a non-shared database management system at low load. The load threshold when determining whether to add or remove a server according to the load of the server can be set high, which has the effect of improving the server operating rate and reducing the number of pool servers.

  Furthermore, when combined with the storage virtualization layer, data movement can be replaced with virtual volume updates, and data relocation without physical data movement is possible, further improving server availability. .

  In addition, by taking a method of subdividing the data area on the shared disk in advance, CPU resources and storage I / O can be added and removed without delay, and data relocation and unnecessary extras are required. Since no load is generated, the load threshold when deciding whether to add or remove a new server can be set high according to the load on the database server, as in the previous case, improving the server operation rate and the number of pool servers The effect is to reduce.

1. 1. Non-shared database management system 2. Front-end module Backend module4. 4. Scheduler module Server monitoring module6. 6. Shared storage Mapping module8. 8. Active server group Pool server group.

Claims (1)

Multiple back-end modules for searching and calculating data,
A plurality of unit volumes each storing a fragmented portion of the data constituting the database, and shared storage shared from the plurality of back-end modules;
Each of the unit volumes is associated with a plurality of virtual volumes accessible from any one of the plurality of back-end modules so as not to overlap, and each of the plurality of unit volumes is associated with the plurality of back-end modules. Storage virtualization means for associating the plurality of unit volumes with the plurality of virtual volumes so as to be accessed from any one of the modules;
A mapping module that manages a correspondence table that holds correspondence between the data held in the plurality of unit volumes and the plurality of back-end modules;
A front-end module that accepts an inquiry to the database, creates a query plan for the plurality of back-end modules with reference to the mapping module mapping information, and
A database management system characterized by changing data areas allocated to the plurality of back-end modules by changing associations between the plurality of unit volumes and the plurality of virtual volumes.

Images