WO2013161076A1 - データベース管理システム、計算機、データベース管理方法 - Google Patents

データベース管理システム、計算機、データベース管理方法 Download PDF

Info

Publication number
WO2013161076A1
WO2013161076A1 PCT/JP2012/061436 JP2012061436W WO2013161076A1 WO 2013161076 A1 WO2013161076 A1 WO 2013161076A1 JP 2012061436 W JP2012061436 W JP 2012061436W WO 2013161076 A1 WO2013161076 A1 WO 2013161076A1
Authority
WO
WIPO (PCT)
Prior art keywords
context
thread
task
query
threads
Prior art date
Application number
PCT/JP2012/061436
Other languages
English (en)
French (fr)
Inventor
清水　晃
晴介 徳田
美智子 吉田
茂木　和彦
藤原　真二
信男 河村
喜連川　優
和生 合田
Original Assignee
株式会社日立製作所
国立大学法人東京大学
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 株式会社日立製作所, 国立大学法人東京大学 filed Critical 株式会社日立製作所
Priority to PCT/JP2012/061436 priority Critical patent/WO2013161076A1/ja
Priority to JP2014512271A priority patent/JP5858307B2/ja
Priority to EP12875146.8A priority patent/EP2843559A4/en
Priority to US14/397,076 priority patent/US10417227B2/en
Publication of WO2013161076A1 publication Critical patent/WO2013161076A1/ja
Priority to US16/531,256 priority patent/US11636107B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24534—Query rewriting; Transformation
    • G06F16/24542—Plan optimisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24532—Query optimisation of parallel queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system

Definitions

  • the present invention relates to data management technology.
  • DB database
  • DBMS database management system
  • Patent Document 1 A technique disclosed in Patent Document 1 is known as a technique for shortening a data read waiting time in processing of one query.
  • the DBMS generates a plan (hereinafter referred to as a query execution plan) in which a plurality of database operations (DB operations or processing steps) necessary for executing a query are combined.
  • a task for executing a step is dynamically generated, and data read requests are multiplexed by executing the tasks in parallel.
  • any execution environment such as a process or thread managed by the OS or a pseudo process or pseudo thread implemented by an application or middleware can be used for task implementation.
  • tens of thousands of tasks may be generated for one query processing.
  • a task is implemented by a thread (or process)
  • tens of thousands of threads are generated.
  • the arbitrary processor core updates the management structure of the thread. This increases the overhead for managing the execution of threads. As a result, there is a problem that the execution time of the query increases.
  • an object of the present invention is to use a plurality of processor cores in the DBMS and reduce the thread management overhead.
  • the DBMS is realized by a computer having a processor core and manages the DB.
  • the DBMS is a query execution plan that generates a query execution plan that includes a query reception unit that receives a query to the DB, processing steps necessary to execute the received query, and execution procedures of the processing steps.
  • the generation unit and the received query are executed based on the generated query execution plan, and a task for executing a processing step is dynamically generated in the execution of the received query.
  • a query execution unit for executing the task is realized by a computer having a processor core and manages the DB.
  • the DBMS is a query execution plan that generates a query execution plan that includes a query reception unit that receives a query to the DB, processing steps necessary to execute the received query, and execution procedures of the processing steps.
  • the generation unit and the received query are executed based on the generated query execution plan, and a task for executing a processing step is dynamically generated in the execution of the received query.
  • the query execution unit executes a task in a plurality of threads executed by the processor core in executing the accepted query, and executes a plurality of tasks in one thread executed by the processor core.
  • the query execution unit may dynamically generate a task for executing the database operation and execute the dynamically generated task in executing the query.
  • the query execution unit (a) generates a task for executing a database operation, and (b) executes the generated task, so that it is necessary for a database operation corresponding to the task.
  • the context includes first information indicating which one of one or more processing steps represented by the query execution plan is a processing step that starts execution in the newly generated task, and the first information Information including the second information related to the access destination of the data required for the processing step indicated by and the third information related to the data necessary for generating a result by the newly generated task.
  • one thread executes a plurality of tasks, and a query is executed by the plurality of threads, so that a plurality of processor cores are used and the thread management overhead is reduced. As a result, the query execution time can be shortened.
  • FIG. 1 is a diagram for explaining the outline of the DBMS according to the first embodiment.
  • FIG. 2 is a diagram for explaining execution of a query in the DBMS according to the first embodiment.
  • FIG. 3 is a configuration diagram of the computer system according to the first embodiment.
  • FIG. 4 is a diagram for explaining the definitions of the DB tables and indexes according to the first embodiment.
  • FIG. 5 is a diagram illustrating an example of a DB Part table according to the first embodiment.
  • FIG. 6 is a diagram illustrating an example of the line item table of the DB according to the first embodiment.
  • FIG. 7 is a schematic diagram illustrating an example of a data structure of a Part index and a Part table in the DB according to the first embodiment.
  • FIG. 1 is a diagram for explaining the outline of the DBMS according to the first embodiment.
  • FIG. 2 is a diagram for explaining execution of a query in the DBMS according to the first embodiment.
  • FIG. 3 is a configuration diagram of the
  • FIG. 8 is a diagram illustrating an example of a DB query according to the first embodiment.
  • FIG. 9 is a diagram illustrating an example of a query execution plan according to the first embodiment.
  • FIG. 10 is a diagram illustrating an example of a data structure of task management information according to the first embodiment.
  • FIG. 11 is a diagram illustrating an example of task execution state information according to the first embodiment.
  • FIG. 12 is a diagram illustrating a first example of process step execution state information according to the first embodiment.
  • FIG. 13 is a diagram illustrating a second example of the process step execution state information according to the first embodiment.
  • FIG. 14 is a diagram illustrating a third example of the processing step execution state information according to the first embodiment.
  • FIG. 15 is a schematic diagram illustrating an example of a data structure of context management information according to the first embodiment.
  • FIG. 16 is a diagram illustrating an example of a search table for thread # 1 according to the first embodiment.
  • FIG. 17 is a diagram illustrating an example of a search table for thread # 2 according to the first embodiment.
  • FIG. 18 is a diagram illustrating an example of a search table for thread # 3 according to the first embodiment.
  • FIG. 19 is a diagram illustrating an example of a context according to the first embodiment.
  • FIG. 20 is a flowchart of a query reception process according to the first embodiment.
  • FIG. 21 is a flowchart of the query execution plan generation process according to the first embodiment.
  • FIG. 22 is a flowchart of the inter-thread sharing flag setting process according to the first embodiment.
  • FIG. 23 is a schematic diagram illustrating another example of the query execution plan according to the first embodiment.
  • FIG. 24 is a flowchart of the result transmission process according to the first embodiment.
  • FIG. 25 is a flowchart of thread execution processing according to the first embodiment.
  • FIG. 26 is a flowchart of task execution processing according to the first embodiment.
  • FIG. 27 is a flowchart of the context search process according to the first embodiment.
  • FIG. 28 is a flowchart of query execution plan execution processing according to the first embodiment.
  • FIG. 29 is a flowchart of DB page acquisition processing according to the first embodiment.
  • FIG. 30 is a flowchart of the new task addition process according to the first embodiment.
  • FIG. 31 is a flowchart of the context sharing determination process according to the first embodiment.
  • FIG. 32 is a flowchart of the context registration process according to the first embodiment.
  • FIG. 33 is a flowchart of task generation processing according to the first embodiment.
  • FIG. 34 is a flowchart of the load distribution process according to the modification.
  • FIG. 35 illustrates a configuration of a computer system according to the second embodiment.
  • FIG. 1 is a diagram for explaining the outline of the DBMS according to the first embodiment.
  • the DBMS 141 includes a client communication control unit 142, a query execution plan 143, a query execution unit 144, an execution task management unit 145, a thread management unit 146, and a DB buffer management unit 147.
  • the query execution unit 144 includes a query execution plan execution unit 151, a context management unit 152, and a context sharing determination unit 153.
  • the DBMS 141 (query execution unit 144) dynamically generates a task for executing a processing step in executing a query, and executes the dynamically generated task. Specifically, for example, the DBMS 141 (query execution unit 144) generates (a) a task for executing a processing step in executing a query, and (b) executes the generated task. Issuing a data read request to the DB to read data necessary for the processing step corresponding to the task, (c) based on the execution result of the Nth processing step corresponding to the task executed in (b) above.
  • the DBMS 141 (query execution unit 144) uses a plurality of threads (kernel threads) provided by the operating system (OS) when executing a task, and each of the plurality of threads has one or a plurality of processors. Alternatively, it is executed by a plurality of processor cores. When the processor core executes the thread, the task assigned to the thread is executed.
  • expressions such as the processor core executing a task or the DBMS 141 executing a task mean that the processor core executes a task assigned to the thread by executing the thread.
  • the DBMS 141 receives a query via the client communication control unit 142.
  • the query execution plan generation unit 143 generates a query execution plan PL for executing the received query.
  • the query execution plan execution unit 151 executes the generated query execution plan PL.
  • the thread management unit 146 manages a plurality of threads executed by the processor core of the processor in the computer in which the DBMS 141 is constructed.
  • the execution task management unit 145 manages tasks executed by threads. In this embodiment, the execution task management unit 145 can assign a plurality of tasks to one thread. As a result, the overhead required for thread management can be reduced.
  • the context management unit 152 manages the context used when executing the task.
  • contexts there are shared contexts that are managed so that they can be used from a plurality of threads, and non-shared contexts that are managed so that they can be used from one thread.
  • a thread that can use a non-shared context between threads uses the context preferentially over other threads.
  • context # 0 and context # 1 are shared contexts between threads
  • context # 2 context # 3
  • context # 4 are non-shared contexts between threads.
  • the context # 0 and the context # 1 are used.
  • context # 2 is used.
  • context # 3 is used.
  • the context # 4 uses the context # 4 when executing the task assigned to the thread # 3.
  • the context sharing determination unit 153 may use a context related to the first processing step of the query execution plan as a thread sharing context.
  • the context sharing determination unit 153 may use a context related to the first processing step of each processing block as a context for sharing between threads. good.
  • the context sharing determination unit 153 may use a context related to a processing step in which the number of subsequent processing steps is a predetermined number or more in one processing block as a context for sharing between threads.
  • a processing block may be composed of one or more processing steps. An example of a query execution plan composed of a plurality of processing blocks that can be executed in parallel will be described later.
  • FIG. 2 is a diagram for explaining the execution of the query in the DB management system according to the first embodiment. In the figure, the passage of time is expressed from top to bottom.
  • the thread management unit 146 generates a thread # 1, a thread # 2, and a thread # 3. These threads # 1 to # 3 can be executed in parallel by different processor cores, for example.
  • the query execution plan execution unit 151 (specifically, one processor core) generates a context # 0 for starting execution of a query and generates a task # 1. Since context # 0 is a context related to processing step # 1 which is the head of the query execution plan, it is shared among threads.
  • the query execution plan execution unit 151 assigns task # 1 to thread # 1. Thread # 1 uses context # 0 and executes task # 1. When task # 1 is executed, context # 1 is generated, and task # 2 and task # 3 are generated.
  • Thread # 1 is a context related to the processing step # 1 which is the head of the query execution plan, it is shared between threads. Thread # 1 assigns task # 2 to thread # 2, and assigns task # 3 to thread # 3. Thread # 2 uses context # 1 and executes task # 2. Thread # 3 uses context # 1 and executes task # 3.
  • Thread # 1 executes task # 1 and executes DB access processing. As a result, a new context is generated. For example, the context # 2 related to the processing step # 3 is generated. Since the processing step of context # 2 is not the head of the query execution plan, it is not shared among threads. That is, the context # 2 is basically used by the thread # 1. Thread # 1 creates task # 4 and assigns it to thread # 1. The thread # 1 uses the context # 2 and executes the task # 4.
  • Thread # 2 executes task # 2 and executes DB access processing. As a result, a new context is generated. For example, context # 3 related to process step # 3 is generated. Since the processing step of context # 3 is not the head of the query execution plan, it is not shared between threads. That is, the context # 3 is basically used by the thread # 2. Thread # 2 creates task # 5 and task # 6 and assigns them to thread # 2. Thread # 2 uses context # 3 and executes task # 5. Further, the thread # 2 executes the task # 6 using the context # 3.
  • Thread # 3 executes task # 3 and executes DB access processing. As a result, a new context is generated. For example, context # 4 related to process step # 3 is generated. Since the processing step of context # 4 is not the head of the query execution plan, it is not shared between threads. That is, the context # 4 is basically used by the thread # 3. Thread # 3 creates task # 7 and task # 8 and assigns them to thread # 3. Thread # 3 executes task # 7 using context # 4. Furthermore, the thread # 3 executes the task # 8 using the context # 4.
  • one thread executes a plurality of tasks, and a query is executed by a plurality of the threads.
  • a plurality of processor cores are used and the thread management overhead is reduced, the query execution time can be shortened.
  • FIG. 3 is a configuration diagram of the computer system according to the first embodiment.
  • the computer system includes a computer 100 and an external storage device 200.
  • the computer 100 and the external storage apparatus 200 are connected via a communication network 300.
  • a protocol for communication through the communication network 300 for example, FC (Fibre Channel), SCSI (Small Computer System Interface), IB (Infini Band), or TCP / IP (Transmission Control Protocol / Internet Protocol) is adopted. Good.
  • the computer 100 is, for example, a personal computer, a workstation, or a main frame.
  • the computer 100 includes a network adapter 110, a processor (typically a microprocessor (for example, a CPU (Central Processing Unit))) 120, a local storage device 130, and a memory 140.
  • the processor 120 executes a computer program such as an OS (Operating System) (not shown) and the DBMS 141.
  • the one or more processors 120 have one or more processor cores. Each processor core can execute processing independently.
  • the processor core has a cache with a shorter access latency than the memory 140.
  • the processor core holds data recorded in the memory 140 in a cache and processes the data.
  • each processor core can execute one thread (kernel thread) at a certain point in time.
  • the memory 140 temporarily stores a program executed by the processor 120 and data used by the program.
  • the memory 140 stores a DBMS 141 that is a program for performing DB management and a series of related processes and data.
  • the memory 141 may store an AP (Application Program) 148 for issuing a query to the DBMS 141.
  • the local storage device 130 stores a program and data used by the program.
  • the network adapter 110 connects the communication network 300 and the computer 100.
  • the processor 120 may be an element included in a control device connected to the network adapter 110, the memory 140, and the like.
  • the control device may include dedicated hardware circuitry (eg, circuitry that encrypts and / or decrypts data).
  • the computer 100 may include a plurality of at least one of the network adapter 110, the processor 120, the local storage device 130, and the memory 140 from the viewpoint of performance and redundancy.
  • the computer 100 may include an input device (for example, a keyboard and a pointing device) and a display device (for example, a liquid crystal display) not shown.
  • the input device and the display device may be integrated.
  • the DBMS 141 executes a query issued to the DBMS 141.
  • This query is issued by an AP 148 executed by the computer 100 or an AP executed by a computer (client) (not shown) connected to the communication network 300.
  • the DBMS 141 executes a query issued by the AP 148, and transmits an I / O request for the DB 206 stored in the external storage apparatus 200 to the external storage apparatus 200 via the OS in accordance with the execution of the query.
  • the OS may be an OS that operates on a virtual machine created and executed by a virtualization program.
  • External storage device 200 stores data used by computer 100.
  • the external storage apparatus 200 receives an I / O request from the computer 100, executes processing corresponding to the I / O request, and transmits the processing result to the computer 100.
  • the external storage apparatus 200 includes a network adapter 201, a storage device group 203, and a controller 202 connected to them.
  • the network adapter 201 connects the external storage device 200 to the communication network 300.
  • the storage device group 203 includes one or more storage devices.
  • the storage device is a non-volatile storage medium, for example, a magnetic disk, a flash memory, or other semiconductor memory.
  • the storage device group 203 may be a group that stores data at a predetermined RAID level according to RAID (Redundant ARRAY of Independent Disks).
  • a logical storage device (logical volume) based on the storage space of the storage device group 203 may be provided to the computer 100.
  • the storage device group 203 stores the DB 206.
  • the DB 206 includes one or more tables 204 and indexes 205.
  • a table is a set of one or more records, and a record is composed of one or more columns.
  • An index is a data structure created for one or more columns in a table, and speeds up access to the table by a selection condition that includes the columns targeted by the index.
  • the index is a data structure that holds information (RowID) for specifying a record in a table including the value for each value of a target column, and a B-tree structure or the like is used.
  • RowID information
  • An example of a DB table configuration and an example of the relationship between tables will be described later.
  • the controller 202 includes, for example, a memory and a processor, and inputs / outputs data to / from the storage device group 203 storing the DB 206 in accordance with an I / O request from the computer 100.
  • the controller 202 stores data to be written in accordance with a write request from the computer 100 in the storage device group 203, reads data to be read in accordance with a read request from the computer 100 from the storage device group 203, and stores the data in the computer To 100.
  • the external storage apparatus 200 may include a plurality of elements such as the controller 202 from the viewpoint of ensuring performance and ensuring redundancy.
  • a plurality of external storage devices 200 may be provided.
  • the DBMS 141 manages the DB 206 including business data.
  • the DBMS 141 includes a client communication control unit 142, a query execution plan generation unit 143, a query execution unit 144, an execution task management unit 145, a thread management unit 146, and a DB buffer management unit 147.
  • the client communication control unit 142 controls communication with a client or AP 148 connected to the communication network 300. Specifically, the client communication control unit 142 receives (accepts) a query issued from the client or the AP 148, and executes a process of transmitting the query processing result to the client or the AP 148.
  • the query is described in, for example, SQL (Structured Query Language).
  • the query execution plan generation unit 143 generates a query execution plan having one or more processing steps necessary for executing the query received by the client communication control unit 142.
  • the query execution plan is, for example, information in which the execution order of processing steps to be performed at the time of executing a query is defined in a tree structure, and is stored in the memory 140. An example of the query execution plan will be described later.
  • the DB buffer management unit 147 manages a storage area (DB buffer) for temporarily storing data in the DB 206.
  • the DB buffer is constructed on the memory 140.
  • the DB buffer may be constructed on the local storage device 130.
  • the query execution unit 144 executes the query according to the query execution plan generated by the query execution plan generation unit 143, and returns the generated result to the query issuer.
  • the query execution unit 144 includes a query execution plan execution unit 151, a context management unit 152, and a context sharing determination unit 153.
  • the query execution plan execution unit 151 dynamically generates a task for executing a processing step in the query execution plan, assigns the task to a thread, and executes the query by the thread executing the task.
  • the context management unit 152 manages a context including information necessary for executing the generated task.
  • the context includes a first information indicating which one of one or more processing steps represented by the query execution plan is a processing step that starts execution in a task, and a processing step indicated by the first information.
  • This is information including second information relating to an access destination of necessary data and third information relating to data necessary for generating a result by a task.
  • the structure of context management information which is information for managing the context, will be described later.
  • the context sharing determination unit 153 determines whether to share a context among a plurality of threads.
  • the execution task management unit 145 manages tasks executed by threads.
  • the task is, for example, a pseudo process or pseudo thread (user level thread) implemented by the DBMS 412.
  • the task may be a set of pointers (function pointers) to a function in which each process is collected as a function.
  • the structure of task management information which is information for managing tasks, will be described later.
  • the thread management unit 146 manages a thread for executing a query.
  • the thread is a thread (kernel thread) provided by the OS.
  • the thread assigned by the processor core the task assigned to the thread is executed.
  • a process may be used instead of a thread.
  • At least a part of processing performed by at least one processing unit of the client communication control unit 142, the query execution plan generation unit 143, the query execution unit 144, and the DB buffer management unit 147 may be performed by hardware.
  • the processing unit when the processing unit is the subject, the processing is actually performed by the processor 120 that executes the processing unit, but at least a part of the processing unit is realized by hardware.
  • the hardware may be the subject instead of or in addition to the processor 120.
  • a computer program for realizing the DBMS 141 may be installed in the computer 100 from a program source.
  • the program source may be, for example, a storage medium readable by the computer 100 or another computer.
  • the configuration of the DBMS 141 shown in FIG. 3 is an example.
  • a certain processing unit may be divided into a plurality of processing units, or a single processing unit in which functions of a plurality of processing units are integrated may be constructed.
  • FIG. 4 is a diagram for explaining definitions of DB tables and indexes according to the first embodiment.
  • the DB 206 has, as the table 205, for example, a Part table including the column c1 and the column c2, and a Lineitem table including the column c3 and the column c4.
  • the DB 206 includes, as the index 204, an index related to the Part table based on the value of the column c1 (Part index) and an index related to the Lineitem table based on the value of the column c3 (Lineitem index).
  • FIG. 5 is a diagram illustrating an example of a DB Part table according to the first embodiment.
  • the Part table of the DB 206 is logically a table in which, for example, the value of the column c1 is associated with the value of the corresponding column c2.
  • FIG. 6 is a diagram illustrating an example of a DB line item table according to the first embodiment.
  • the Lineitem table of the DB 206 is a table in which, for example, the value of the column c3 is associated with the value of the corresponding column c4.
  • FIG. 7 is a diagram for explaining an example of the data structure of the part index and part table in the DB according to the first embodiment.
  • the Part index has, for example, a B-tree structure for searching for a page and a slot of the part table storing the value of the corresponding column c2 based on the value of the column c1.
  • a page is a minimum data unit in input / output with respect to the DB 206.
  • the Part index manages the page P as a hierarchical structure.
  • the Part index there are a leaf page that is the lowest page and an upper page that is an upper page of the leaf page.
  • the highest page among the upper pages is referred to as a root page.
  • the page P1 includes a pointer to a page P2 that manages the correspondence with the value of the column c1 of “100” or less, and a page that manages the correspondence with the value of the column c1 that is greater than “100” and less than or equal to “200”.
  • a pointer to P3 and a pointer to page P4 that manages the correspondence relationship between the value of column c1 greater than “200” and less than or equal to “300” are stored.
  • the upper page there is an entry that associates a pointer to the page one level below each page with the maximum value of the column c1 managed in the page one level below.
  • One or more are provided.
  • the leaf page corresponds to the value of the column c1 and the storage position in the Part table that stores the value of the column c2 corresponding to the value (for example, the page number of the Part table and the slot number in the page).
  • page P8 which is a leaf page, corresponds to a row including the page and slot number in which the value of column c2 corresponding to the value “110” of column c1 is stored, and the value “130” of column c1.
  • the page storing the value of the column c2 and the row including the slot number are stored.
  • a row including the page and slot number in which the value of the column c2 corresponding to the value “130” of the column c1 is stored includes slot 2 of the page P100, slot 1 of the page P120, and slot 4 of the page P200. Is stored.
  • the value of the column c2 corresponding to the value “130” of the column c1 becomes “id131” from the record of the slot 2 of the page P100 of the Part table, and “id132” from the record of the slot 1 of the page 120 of the Part table.
  • “id133” is obtained from the record in the slot 4 of the page 200 of the Part table.
  • FIG. 8 is a diagram illustrating an example of a DB query according to the first embodiment.
  • the query shown in FIG. 8 is an example of a query for the DB 206 having the structure shown in FIGS.
  • the query shown in FIG. 8 is obtained from the Part table and the Lineitem table with respect to the column c1 value “130” and the value of the column c2 and the value of the column c3 are the same. Means to extract the value of.
  • FIG. 9 is a diagram illustrating an example of a query execution plan according to the first embodiment.
  • the query execution plan shown in the figure indicates a query execution plan generated by the query execution plan generation unit 143 when the DBMS 141 receives the query shown in FIG.
  • the query execution plan corresponding to the query shown in FIG. 8 includes processing step # 1 for performing index search using the Part index, processing step # 2 for acquiring records from the Part table, and indexing using the Lineitem index. Processing step # 3 for performing a search, processing step # 4 for acquiring a record from the Lineitem table, and processing step # 5 for combining these results with a nested loop are included.
  • FIG. 10 is a diagram illustrating an example of a data structure of task management information according to the first embodiment.
  • the task management information has a main data structure 71.
  • the main data structure 71 stores thread specifying information (for example, thread number) for specifying a plurality of threads and a pointer to a list management structure 72 for managing tasks executed by the threads in association with each thread. .
  • the list management structure 72 stores an executable list 72a for managing tasks that can be executed in the corresponding thread, and a waiting list 72b for managing tasks that are waiting for execution in the corresponding thread.
  • the executable list 72a has a pointer to execution status information (task execution status information) 73 relating to tasks that can be executed in the corresponding thread.
  • the task execution state information 73 has a pointer to the task execution state information 73 related to other tasks that can be executed in the corresponding thread.
  • the execution state information 73 regarding the executable task in the thread # 2 is managed, and the execution waiting state in the thread # 2
  • the execution state information 73 related to the task task execution state information 73 of task # 5 and task # 6 is managed. If there is a task bias among a plurality of threads, the task (that is, task execution state information 73) may be moved to another thread list.
  • the executable list and the waiting list are managed for each thread, but the executable list and the waiting list may be shared among a plurality of threads. Further, the executable list and the waiting list may be managed for each processing step.
  • FIG. 11 is a diagram illustrating an example of task execution state information according to the first embodiment.
  • the task execution state information 73 stores a work area 73a, a processing step 73b, and a processing step execution state 73c.
  • the work area 73a stores a pointer indicating the work area.
  • the processing step 73b stores information for identifying a processing step to be executed by the corresponding task, for example, a processing step number.
  • the processing step execution state 73c stores execution state information (processing step execution state information) 74 of the corresponding processing step. A specific example of the processing step execution state information 74 will be described later.
  • FIG. 12 is a diagram illustrating a first example of processing step execution state information according to the first embodiment.
  • FIG. 12 shows processing step execution state information for a task that uses the upper page in the index search.
  • the processing step execution state information 74A includes a search condition 74a, a page number 74b, and a slot number 74c.
  • the search condition 74a stores the search condition.
  • the search condition 74a stores a key value range “115 or more and 195 or more and 195” that is a search condition included in the query.
  • the page number 74b stores the number of the upper page (page number) used in task processing.
  • the slot number 74c stores a slot number (slot number) in a page used in task processing.
  • FIG. 13 is a diagram illustrating a second example of the process step execution state information according to the first embodiment.
  • FIG. 13 shows processing step execution state information for a task that uses a leaf page in index search.
  • the processing step execution state information 74B includes a search condition 74d, a page number 74e, a slot number 74f, and a processing row ID number 74g.
  • the search condition 74d stores the search condition.
  • the search condition 74d stores a key value range “115 or more and 195 or more and 195” that is a search condition.
  • the page number 74e stores the page number of the leaf page used in task processing.
  • the slot number 74f stores the slot number of the slot in the page used for task processing.
  • the processing row ID number 74g stores the ID number of the row in the slot processed by the corresponding task (processing row ID number).
  • FIG. 14 is a diagram illustrating a third example of the processing step execution state information according to the first embodiment.
  • FIG. 14 shows processing step execution state information for a task for acquiring a record.
  • the processing step execution state information 74C includes a page number 74h and a slot number 74i.
  • the page number 74h stores the page number of the page used in task processing.
  • the slot number 74i stores the slot number of the slot in the page used for task processing.
  • FIG. 15 is a schematic diagram illustrating an example of a data structure of context management information according to the first embodiment.
  • the context management information 80 includes a main structure 81 of a management list and a plurality of contexts 82.
  • a pointer to the context 82 is stored in the main structure 81.
  • Each context 82 stores a pointer to another context 82.
  • the thread executing the task locks (locks) each context 82 as a unit. The locked context cannot be used by other threads.
  • the context management information 80 stores search tables (thread search tables) 83, 84, 85, etc. corresponding to the thread executing the query.
  • the search table 83 for the thread # 1 manages a pointer to the context 82 that can be used by the thread # 1.
  • the search table 84 for thread # 2 manages a pointer to a context 82 that can be used by thread # 2.
  • the search table 85 for the thread # 3 manages a pointer to the context 82 that can be used by the thread # 3.
  • FIG. 16 is a diagram illustrating an example of a search table for thread # 1 according to the first embodiment.
  • FIG. 17 is a diagram illustrating an example of a search table for thread # 2 according to the first embodiment.
  • FIG. 18 is a diagram illustrating an example of a search table for thread # 3 according to the first embodiment.
  • the thread # 1 search table 83 is a table that manages pointers to contexts that can be used by the thread # 1, and manages pointers to contexts related to each processing step in a list.
  • a context pointer 83a related to the processing step # 1 a context pointer 83b related to the processing step # 2
  • a context pointer 83c related to the processing step # 3 and a processing step # 4.
  • a pointer to the context # 1 is stored in the pointer 83a
  • a pointer to the context # 2 is stored in the pointer 83c.
  • the thread # 2 search table 84 is a table that manages pointers to contexts that can be used by the thread # 2, and manages pointers to contexts related to each processing step in a list. As shown in FIG. 17, the pointer 84a to the context related to the processing step # 1, the pointer 84b to the context related to the processing step # 2, the pointer 84c to the context related to the processing step # 3, and the processing step # 4. A pointer 84d to a context related to In this embodiment, a pointer to the context # 1 is stored in the pointer 84a, and a pointer to the context # 3 is stored in the pointer 84c.
  • the search table 85 for the thread # 3 is a table that manages pointers to contexts that can be used by the thread # 3, and manages pointers to contexts related to each processing step in a list.
  • the pointer 85a to the context related to the processing step # 1 the pointer 85b to the context related to the processing step # 2
  • the pointer 85c to the context related to the processing step # 3 and the processing step # 4.
  • a pointer 85d to the context related to In this embodiment, a pointer to the context # 1 is stored in the pointer 85a, and a pointer to the context # 4 is stored in the pointer 85c.
  • the context # 1 can be used in the thread # 1, the thread # 2, or the thread # 3.
  • context # 2 can be used in thread # 1.
  • Context # 3 can be used in thread # 2
  • context # 4 can be used in thread # 3.
  • the state in which the pointer to the context 82 is registered in the search table for a plurality of threads is called the context is shared between threads, and the pointer to the context is registered in the search table for one specific thread. A state is said to be non-shared between threads.
  • a context that can be used by a processor core that executes a thread by using the thread-specific search table is referred to as a context that can be used by the thread.
  • context # 1 is used by thread # 1, thread # 2, and thread # 3
  • context # 2 is used by thread # 1
  • context # 3 is used by thread # 2
  • context # 4 is thread Used by # 3.
  • the processing time associated with the use of the context can be shortened by the cache of the processor core.
  • a thread search table for other threads may be referred to in order to equalize the amount of tasks executed by the threads.
  • a thread-specific search table for other threads other threads are not shared among threads (context # 2, context # 3, context Use # 4).
  • thread # 1 refers to the search table for thread # 2 or the search table for thread # 3
  • context # 3 or context # 4 is assigned to thread # 2. Used by tasks assigned to 1.
  • FIG. 19 is a diagram illustrating an example of a context according to the first embodiment.
  • the context 82 includes a start step 82a, an intermediate result 82b, an execution state 82c, and a number 82d that can be generated.
  • the start step 82a the number of the corresponding processing step is stored.
  • the intermediate result 82b a pointer indicating a work area for storing an intermediate result necessary for a task executing the corresponding processing step is stored.
  • the intermediate result is acquired data necessary for generating a query result.
  • the execution state 82c the task execution state in the corresponding processing step, for example, information (for example, page number 820, slot number 821, and processing row ID number 822) specifying the processing content of the task to be executed next is specified. Store.
  • the page number 820 stores the page number of the leaf page used in the processing of the next task.
  • the slot number 821 stores the slot number in the page used in the processing of the next task.
  • the processing row ID number 822 stores the ID number (processing row ID number) of the row in the slot used in the processing of the next task.
  • the number of tasks that can be generated (number of tasks that can be generated) is stored in the number of possible generations 82d.
  • the number of tasks that can be generated is the number of processes that are not generated as tasks out of the number of processes that logically branch. For example, when the key value “130” is a condition in the index search by the Part index shown in FIG. 7, there are three row IDs as entries corresponding to the key value “130” on the page P8.
  • FIG. 20 is a flowchart of the query reception process according to the first embodiment.
  • step S1 when the client communication control unit 142 receives a query from the AP 148 (step S1), the received query is passed to the query execution plan generation unit 143, and the query execution plan generation unit 143 performs the query execution plan generation process. (See FIG. 21) is executed (step S2).
  • the thread management unit 146 After executing the query execution plan generation process, the thread management unit 146 generates a thread (step S3).
  • the number of threads to be generated may be an arbitrary number, for example, the same number as the number of processor cores of the processor 120.
  • the processor core on which the thread operates may be designated as a specific processor core for each thread. That is, processor affinity may be set.
  • the same number of threads as the number of processor cores may be generated, and one of the threads may be set to be executed by each processor core. In this way, the efficiency of processing by each thread is good.
  • a method of generating a thread there is a method of using a thread generation interface (function) provided by the OS, specifically, pthread_create ().
  • the query execution plan execution unit 151 generates a context for starting execution of the query, generates a task for processing using the context, and assigns it to any one thread (step S4).
  • the task is assigned to the thread created first by the thread management unit 146.
  • the processor core of the processor 120 executes the thread, and the thread executes the task assigned to the thread.
  • FIG. 21 is a flowchart of the query execution plan generation process according to the first embodiment.
  • the query execution plan generation process is a process corresponding to step S2 of the query reception process shown in FIG.
  • the query execution plan generation unit 143 generates a query execution plan from the query passed from the client communication control unit 142 (step S5). For example, when the query shown in FIG. 8 is received, the query execution plan shown in FIG. 9 is generated.
  • the query execution plan generation unit 143 executes the inter-thread sharing flag setting process (see FIG. 22) (step S6), and ends the query execution plan generation process.
  • FIG. 22 is a flowchart of the inter-thread sharing flag setting process according to the first embodiment.
  • the inter-thread sharing flag setting process is a process corresponding to step S6 of the query execution plan generation process shown in FIG.
  • the inter-thread sharing flag setting process is a process for setting, for a predetermined processing step in the query execution plan, an inter-thread sharing flag indicating that a context related to the processing step should be shared between threads.
  • the query execution plan generation unit 143 performs processing while moving the pointer in order to trace the query execution plan having a tree structure.
  • a pointer is set at the first processing step of the query execution plan (step S11).
  • the query execution plan generation unit 143 determines whether or not there is a processing step indicated by the pointer in the query execution plan (step S12). As a result, when there is no processing step pointed to by the pointer ("No" in step S12), it means that processing has been performed for all processing steps of the query execution plan, so the query execution plan generation unit 143 Ends the inter-thread sharing flag setting process.
  • step S12 when there is a processing step indicated by the pointer in the processing step of the query execution plan (“Yes” in step S12), the query execution plan generation unit 143 determines whether or not the processing step is the head of the processing block. Determination is made (step S13).
  • the processing block refers to the set when one or more processing steps that must be sequentially executed in the query execution plan are divided into sets that can be executed in parallel.
  • the query execution plan shown in FIG. 9 includes one processing block.
  • the processing block will be described using another query execution plan.
  • FIG. 23 is a diagram for explaining another example of the query execution plan according to the first embodiment.
  • the query execution plan shown in FIG. 23 includes processing step # 1 for performing index search using the Part index, processing step # 2 for acquiring a record from the Part table, and processing step # 3 for executing a table scan on the Lineitem table. And processing step # 4 for hash-joining the results of processing step # 2 and processing step # 3.
  • processing step # 1, processing step # 2, and processing step # 3 are processes that can be executed in parallel.
  • This query execution plan includes a processing block # 1 including processing step # 1 and processing step # 2, and a processing block # 2 including processing step # 3 and processing step # 4.
  • processing step # 1 and processing step # 3 are the first processing step of the processing block.
  • a query execution plan corresponding to a query including a subquery or a derived table also includes a plurality of processing blocks.
  • step S14 the query execution plan generation unit 143 performs inter-thread processing on the processing step.
  • a sharing flag is set (step S14).
  • the inter-thread sharing flag is set in process step # 1.
  • an inter-thread sharing flag is set in process step # 1 and process step # 3.
  • the process proceeds to step S15.
  • the processing step is the head of the processing block, the context should be shared by a plurality of threads in order to distribute the starting task to the plurality of threads at an early stage of the processing block.
  • step S13 if the result of step S13 is that the processing step is not the head of the processing block (“No” in step S13), the query execution plan generation unit 143 advances the processing to step S15.
  • step S15 the query execution plan generation unit 143 moves the pointer to the next processing step, and the process proceeds to step S12.
  • the inter-thread sharing flag is set for the first processing step of the processing block. For example, the number of subsequent processing steps in the processing block is predetermined. An inter-thread sharing flag may be set for a plurality of processing steps.
  • FIG. 24 is a flowchart of a result transmission process according to the first embodiment.
  • the result transmission process is started by the client communication control unit 142 after the client communication control unit 142 receives the query.
  • the client communication control unit 142 confirms whether or not there is a result of the accepted query in the query execution unit 144 (step S21).
  • step S21 when there is a query result (“Yes” in step S21), the client communication control unit 142 acquires the query result from the query execution unit 144 (step S22), and the AP 148 that is the query issuer. The result of the query is transmitted to (Step S26).
  • the client communication control unit 142 determines whether the query end flag of the query execution unit 144 is “end” indicating the end of the query, or the query ends. It is determined whether it is “not finished” indicating that it has not been performed (step S23). As a result, when the query end flag is “end” (“end” in step S23), “NOROW” (no corresponding record) is set in the result (step S24), and the query is issued to AP148. The result of the query is transmitted (step S26).
  • step S23 when the query end flag of the query execution unit 144 is “not finished” indicating that the query is not finished (“not finished” in step S23), the client communication control unit 142 indicates that the query execution unit 144 displays the result. Waiting for generation for a predetermined time (step S25), the process proceeds to step S21.
  • FIG. 25 is a flowchart of thread execution processing according to the first embodiment.
  • the thread execution process is realized by the processor core of the processor 120 executing the thread generated in step S3 of FIG.
  • another processor core can perform thread execution processing for another thread in parallel.
  • the processor core selects a task to be executed in the corresponding thread (step S31). Specifically, the processor core selects a task included in the executable list of the corresponding thread in the task management information managed by the execution task management unit 145.
  • step S32 determines whether or not there is a task to be executed. If there is no task to be executed ("No" in step S32), the process proceeds to step S34 while there is a task to be executed. ("Yes” in step S32) starts the task or restarts the task (step S33). Specifically, the following processing is performed.
  • the processor core selects one of the tasks included in the ready list.
  • the processor core confirms the task execution state information of the selected task, and starts the task or restarts the task. If the task execution status information processing step is not set, task processing is started. Specifically, a task execution process (see FIG. 26) is executed. If the task execution state information processing step is set, the task processing is resumed.
  • execution is resumed from the process where the task was interrupted.
  • the process is resumed from step S66 of FIG.
  • the processor core advances the process to step S31 after the execution of the task is completed or after the execution of the task is in a waiting state.
  • step S34 the processor core checks whether or not there is another thread (step S34), and if there is no other thread (“No” in step S34), the processor core sets end to the query end flag of the query execution unit 144. (Step S35), and the thread execution process is terminated. As a result, the thread disappears. On the other hand, when there is another thread (“Yes” in step S34), the processor core ends the thread execution process. As a result, the thread disappears.
  • FIG. 26 is a flowchart of task execution processing according to the first embodiment.
  • the task execution process corresponds to the process when the task process is started in step S33 of FIG. This task execution process is realized by the processor core executing a task in a thread.
  • the processor core executes a context search process (see FIG. 27) (step S36), and checks whether there is a context searched by the context search process (step S37). As a result, when there is no context (“none” in step S37), it means that there is no operation to the DB to be executed, and the task execution process is terminated.
  • the processor core sets task execution state information 73 (see FIG. 11) of the task (step S38). Specifically, the processor core copies the value of the start step 82 a of the searched context 82 to the processing step 73 b of the task execution state information 73. Data in the work area indicated by the pointer of the context intermediate result 82 b is copied to the work area indicated by the pointer in the work area 73 a of the task execution state information 73. Further, the processor core copies the value of the execution state 82 c of the context 82 to the processing step execution state 73 c of the task execution state information 73. For example, in the case of the context 82 shown in FIG.
  • the value “8” of the page number 820 of the context 82 is stored as the page number in the processing step execution state 73c of the task execution state information 73, and the slot number is The value “2” of the slot number 821 of the context 82 is stored, and the value “2” of the processing row ID number 822 of the context 82 is stored as the processing row ID number.
  • the processor core updates the execution state 82c of the context 82 so as to correspond to the processing content in the next task. For example, in the context 82 shown in FIG. 19, the value of the processing row ID number 822 is incremented by 1 to “3”.
  • this task starts processing in the subsequent processing by referring to the record (record having id 132) stored in the slot number “1” of the page “P120” indicated by the corresponding row ID. It becomes.
  • step S38 the processor core executes query execution plan execution processing (see FIG. 28). If the task processing is finished, step 39 is finished and the processing proceeds to step S36.
  • FIG. 27 is a flowchart of context search processing according to the first embodiment.
  • the context search process is a process corresponding to step S36 in FIG.
  • the processor core searches for a context using the pointer of the thread search table (83, 84, or 85) for the executing thread (self thread) (step S41).
  • the processor core searches for contexts in order from the last processing step to the first processing step.
  • the processor core checks whether or not there is a context that can be searched (step S42). As a result, when the context is found (“Yes” in step S42), the context search process is terminated.
  • step S42 if there is no context (“No” in step S42), it means that the number of available contexts may be uneven among threads, so threads other than the own thread (other threads) ) Is searched for using the pointer of the thread-oriented search table (step S43).
  • the processor core when acquiring a context from a thread-oriented search table for other threads, the processor core searches for the context in the order of the first processing step to the last processing step. Here, searching for the context from the first processing step is more likely to generate more tasks the closer to the first processing step, so the load can be distributed to each thread at an early stage. It is.
  • step S43 the processor core ends the context search process.
  • thread # 1 searches for a context in the search table for thread # 1.
  • Thread # 1 searches in the order from processing step # 4 to processing step # 1 in the search table for thread # 1.
  • thread # 1 finds a pointer to context # 2 and uses context # 2.
  • context # 2 disappears, a pointer to the context # 1 is found and the context # 1 is used.
  • context # 1 disappears, there is no available context in the search table for thread # 1, and thread # 1 searches for a context in the search table for threads other than its own thread. In this case, search is performed in the order of processing step # 1 to processing step # 4.
  • Thread # 1 is processing step # 1 of search table for thread # 2, processing step # 1 of search table for thread # 3, processing step # 2 of search table for thread # 2, processing step of search table for thread # 3 # 2, search table processing step # 3 for thread # 2, search table processing step # 3 for thread # 3, search table processing step # 4 for thread # 2, search table processing step # 4 for thread # 3 Search in the order of. 17 and 18, when the pointer to the context # 1 disappears, the thread # 1 finds a pointer to the context # 3 in the search table for the thread # 2, and uses the context # 3.
  • the context search is made by referring to the thread search table for other threads.
  • the context may be searched by referring to a thread-specific search table for other threads.
  • step S43 of the context search process it is possible to reduce the load imbalance between threads based on the number of available contexts between the threads. You may make it adjust with the load distribution thread
  • FIG. 28 is a flowchart of the query execution plan execution process according to the first embodiment.
  • the query execution plan execution process corresponds to step S39 in FIG.
  • This query execution plan execution process is realized by executing a task assigned by a processor core to a thread.
  • a logical function unit that executes the query execution plan execution process corresponds to the query execution plan execution unit 151.
  • the processor core acquires a page in the DB 206 by executing a DB page acquisition process (see FIG. 29) (step S51).
  • the processor core determines whether there is data that matches the search condition for the data in the page (step S52). For example, if it is an upper page of the index, it is a search process in the upper page, and if it is a leaf page, it is a search process of a leaf page.
  • the processor ends the query execution plan execution process.
  • step S52 when there is data that matches the search condition (“true” in step S52), the processor core determines whether there is one data or two or more data that match the search condition (step S52). S53). As a result, when the number of data matching the search condition is one (“1” in step S53), the processor core advances the process to step S55. On the other hand, when there are two or more data that match the search condition (“two or more” in step s53), the processor core executes a new task addition process (see FIG. 30) (step S54). Advances to step S55.
  • step S55 the processor core executes processing for the DB page in the processing step by the task.
  • the process for the DB page is, for example, a process of reading a page number that matches the search condition if it is an upper page of the index, and a process of reading a row ID that matches the search condition if it is a leaf page. If it is a table page, this is a process of reading a record column.
  • step S56 the processor core determines the next DB page and processing for the DB page (step S56), and proceeds to step S57.
  • step S57 the processor core releases the acquired DB page.
  • step S58 the processor core determines whether or not there is a next process. Specifically, it is determined as “None” when the currently performed process step is completed and there is no next process step in the process block including the process step. As a result, when there is a next process (“Yes” in step S58), the processor core advances the process to step S51. On the other hand, when there is no next process (“No” in step S58), the processor core The result is passed to the query execution unit 144 (step S59), and the query execution plan execution process ends.
  • the processor core determines the index root page (the page with the page number “P1”) as the next DB page, and assigns the key “130” to the page.
  • the search process in the upper page to be searched is determined as the process for the DB page, and the process is started.
  • the processor core reads page P1, and in step S52 searches for an entry including c1 “130” in the page P1. Since one entry including c1 “200” is found, in step S55 and step 56, the search process in the upper page is determined as the process for the DB page for the page P3 as the next process.
  • step 51 to step S55 the process for page P3 is performed.
  • the processor core reads the page P3, searches the page P3 for an entry including c1 “130”, and finds a pointer to the page P8 in the entry including c1 “130”. As a result, the page P8 is determined as the next DB page, and the search process in the leaf page for the page P8 is determined as the process for the DB page.
  • step 51 to step S53 the processor core reads page P8, searches the page P8 for an entry including c1 “130”, and finds page “P100” in the Part table and slot number “2”.
  • a new task addition process (step 54) is performed in order to process two data other than the data to be processed by the task.
  • the data to be processed by the task is the first data
  • the page P100 of the Part table is determined as the next DB page in step 56
  • the record in the slot number 2 is acquired for the page P100. Is determined to be the process for the DB page.
  • FIG. 29 is a flowchart of DB page acquisition processing according to the first embodiment.
  • the DB page acquisition process corresponds to step S51 of the query execution plan execution process (FIG. 28).
  • This DB page acquisition processing is realized by executing a task assigned to a thread by a processor core.
  • the processor core searches the buffer page (DB buffer page) corresponding to the DB page to be acquired in the DB buffer management unit 147 (step S61), and checks whether there is a corresponding DB buffer page (step S62).
  • step S63 determines whether or not reading of the page from the DB 206 has been completed. If it has been completed (“completed” in step S63), the DB page acquisition process ends. On the other hand, if the reading has not been completed (“incomplete” in step S63), the process proceeds to step S66.
  • step S62 when there is no corresponding DB buffer page (“No” in step S62), the processor core acquires a free DB buffer page from the DB buffer management unit 147 (step S64), and the corresponding page for the DB 206.
  • a DB page read request for reading the data into the empty DB buffer page is issued (step S65), and the process proceeds to step S66.
  • step S66 the processor core waits for page reading to be completed.
  • the processor core waits until the reading of the page is completed, that is, a method that does not adopt the synchronous I / O and executes other processing without reading the page, that is, asynchronous I / O. / O may be adopted.
  • the processor core interrupts the processing of the task being executed to enter a wait state, and changes the task execution state information to the wait list. Then, the completion of reading the corresponding page is confirmed by another thread (or another task). Then, when the other thread (the processor core that executes another thread) confirms the completion of reading the page, the task execution state information of the task is changed to the executable list, and the processing of the task is resumed. You may do it.
  • the processor core can execute other tasks without waiting for completion of page reading, and the processing efficiency in the DBMS 141 can be improved. Note that when the reading is completed, the processor core ends the DB page acquisition process.
  • FIG. 30 is a flowchart of new task addition processing according to the first embodiment.
  • the new task addition process corresponds to step S54 of the query execution plan execution process (FIG. 28).
  • This new task addition processing is executed for data other than one data (for example, the first data) in the matching data when there are two or more data matching the condition in step S53.
  • the processor core creates a context 82 based on the data to be processed (step S71).
  • the processor core executes a context sharing determination process (see FIG. 31) for determining whether or not the created context 82 is shared between threads (step S72).
  • the processor core executes a context registration process (see FIG. 32) for registering the created context 82 in the context management information 80 (step S73).
  • the processor core determines whether or not a new task can be generated (step S74). Whether or not a new task can be generated is determined, for example, by determining whether or not the number of tasks generated in the DBMS 141 has reached the upper limit of the number of tasks that can be generated. it can.
  • step S74 when a task can be generated (“Yes” in step S74), the processor core executes a task generation process (see FIG. 33) for generating a new task (step S75). The task addition process is terminated. On the other hand, if the task cannot be generated (“No” in step S74), the new task addition process is terminated without generating the task.
  • FIG. 31 is a flowchart of the context sharing determination process according to the first embodiment.
  • the context sharing determination process corresponds to step S72 of the new task addition process (FIG. 30). This context sharing determination process is realized by executing a task assigned by the processor core to a thread.
  • the processor core refers to the inter-thread sharing flag of the processing step related to the generated context (step S81).
  • the processor core determines that the context is shared among a plurality of threads.
  • the context sharing determination process is terminated.
  • the processor core determines that the context is not shared between threads that can be used by one thread. (Step S83), the context sharing determination process ends.
  • the processor core may determine whether or not to share the generated context between threads based on the execution state of the DBMS 141.
  • the number of existing tasks of the DBMS 141 is adopted as the execution state of the DBMS 141.
  • the processor core determines that the context to be generated is shared among threads, and when the number of existing tasks is not less than or equal to the predetermined number, the generated context is not shared between threads. May be determined.
  • the processor core determines the generated context between threads. If it is determined to be shared and the data amount of the intermediate result 82b included in the context is not equal to or less than a predetermined amount, the generated context may be determined to be non-shared between threads.
  • FIG. 32 is a flowchart of the context registration process according to the first embodiment.
  • the context registration process corresponds to step S73 of the new task addition process (FIG. 30). This context registration process is realized by executing a task assigned to a thread by the processor core.
  • the processor core registers the created context in the management list of the context management information 80 (step S91). Specifically, the processor core connects the created context after the last context connected to the management list.
  • step S92 the processor core confirms the result of the context sharing determination process (see FIG. 31) (step S92). If this result is sharing between threads (“shared” in step S92), a pointer to the created context is registered in a plurality of thread search tables, and the context registration processing is terminated.
  • context pointers are registered in the search tables for all threads that execute DB access processing (step S93).
  • a pointer to a context may be registered in a search table for a specific thread.
  • the search table for threads to be registered is specified based on the hardware configuration information of the computer.
  • the hardware configuration information may be a processor configuration, a cache configuration, or a memory configuration.
  • a thread management table for a thread corresponding to the plurality of threads corresponding to the plurality of threads with the smallest total number of available context tasks can be generated. sign up.
  • the processor core executing the thread # 2 and the processor core executing the thread # 3 are the same processor, and the processor is different from the processor executing the thread # 1, and the context # 1
  • a new context # 4 is generated for the processing step # 1, it is registered in a thread thread search table executed by a processor core of a processor with a small number of contexts. In this case, it is registered in the thread search table for thread # 1. In this example, it is registered in the search table for one thread. However, if the processor of the processor core that executes thread # 1 is executing another thread that executes DB access processing, the search table for multiple threads is used. I will register.
  • the thread management table for threads corresponding to a plurality of threads corresponding to the processor including the processor core that generated the context.
  • the total number of available contexts may be registered in a thread management table for threads corresponding to the plurality of threads.
  • it may be registered in a thread management table for a plurality of threads executed by processor cores sharing a cache within the processor.
  • it may be registered in the thread management table of a plurality of threads executed by a processor core close to the memory for recording the context.
  • it may be registered in a thread management table of a plurality of threads executed by a processor core close to a memory in which a DB buffer page to be referred to when using a context is recorded.
  • the processor core registers a pointer in the search table for one thread and ends the context registration processing.
  • a pointer to the created context is registered in the thread search table for the thread (self thread) being executed (step S94), and the context registration process is terminated.
  • it may be registered in the search table for threads having the smallest available context, or may be registered in the search table for threads having the smallest total number of tasks that can be used in the context that can be generated.
  • FIG. 33 is a flowchart of task generation processing according to the first embodiment.
  • the task generation process corresponds to step S75 of the new task addition process (FIG. 30). This task generation processing is realized by executing a task assigned to a thread by the processor core.
  • step S101 the processor core confirms the result of the context sharing determination process (see FIG. 31) (step S101). If this result is sharing between threads (“sharing between threads” in step S101), the processor core generates a task and adds two or more threads corresponding to the thread search table in which context pointers are registered. A task is assigned (step S102). The total number of tasks to be generated is limited to the number of contexts that can be generated. The number of tasks assigned to each thread is the number of contexts that can be generated divided by the number of threads. Thereafter, the processor core ends the task generation process.
  • the processor core generates a task and registers one context search table corresponding to the registered thread pointer.
  • a task is assigned to the thread (step S103).
  • the number of tasks to be generated is limited to the number of contexts that can be generated.
  • the thread to which the task is assigned may be the own thread executed by the processor core, or may be a thread other than the own thread.
  • the processor core ends the task generation process.
  • the query execution unit 144 may execute the following load distribution process.
  • FIG. 34 is a flowchart of the load distribution process according to the modification.
  • the load distribution process is executed by the query execution unit 144.
  • the processor core can be realized by executing a thread (load distribution thread) other than a thread for performing DB processing. This load distribution process is started after the client communication control unit 142 receives a query.
  • the processor core determines whether or not the query processing is finished (step S111), and when the query processing is finished (“end” in step S111), the load distribution processing is finished.
  • the processor core calculates the sum of the number of tasks that can be generated in the context that can be used from the search table for each thread (step S112). .
  • the processor core determines whether or not there is a bias in the total number of tasks that can be generated by each thread (step S113).
  • the processor core may determine that there is a bias when the number of tasks that can be generated is a predetermined number (for example, 0) or less.
  • step S113 if there is no bias in the total number of tasks that can be generated by each thread (“No” in step S113), the process proceeds to step S115.
  • the processor core changes the position of the context, that is, a pointer that references the context is stored.
  • the bias of the total number of tasks that can be generated in each thread can be reduced.
  • a context pointer that can be used by a thread search table for a thread having the largest total task generation number is registered in a thread search table for threads having a small total task generation number.
  • step S115 the processor core sleeps the load distribution process for a predetermined time, and advances the process to step S111.
  • This load distribution process can distribute the load on each thread appropriately.
  • the threads that use the context are changed based on the bias of the total number of tasks that can be generated by each thread.
  • the thread load may be grasped and the thread using the context may be changed.
  • the cost calculation for each thread may be performed, and the thread using the context may be changed based on the cost.
  • the following values can be considered as examples of cost calculation.
  • the context cost is the product of the number of processing steps processed from the context and the number that can be generated, and the total cost of the context available from the thread is the cost of the thread.
  • the load balancing process may be executed by a thread for performing DB processing. For example, it may be executed at the end of the thread (when it is determined “None” at step S32) or at the end of the task (when it is determined “None” at step S37). In this case, the load distribution process executes steps S112 to S114.
  • Example 2 will be described. At that time, differences from the first embodiment will be mainly described, and description of common points with the first embodiment will be omitted or simplified.
  • FIG. 35 shows a configuration of a computer system according to the second embodiment.
  • Application server (hereinafter referred to as AP server) 3502 is connected to a computer (hereinafter referred to as DB server) 100 on which DBMS 141 operates so as to communicate via communication network 3512.
  • the DB server 100 is connected to the external storage device 200 so as to be able to communicate via the communication network 300.
  • a user terminal (client terminal) 3501 is connected to an AP server 3502 so as to be able to communicate via a communication network arc 3511.
  • the DB server 100 executes a DBMS 141 that manages the DB 206.
  • the external storage device 200 stores the DB 206.
  • the AP server 3502 executes an AP that issues a query to the DBMS 141 executed by the DB server 100.
  • the user terminal 3501 issues a request to the AP executed by the AP server 3502.
  • a plurality of user terminals 3501 or AP servers 3502 may exist.
  • the AP server management terminal 3503 is connected to the AP server 3502 via the communication network 3514.
  • the DB server management terminal 3504 is connected to the DB server 100 via the communication network 3515.
  • the storage management terminal 3505 is connected to the external storage device 200 via the communication network 3516.
  • the AP server management terminal 3503 is a terminal that manages the AP server 3502.
  • the DB server management terminal 3504 is a terminal that manages the DB server 100.
  • the storage management terminal 3505 is a terminal that manages the external storage apparatus 200.
  • the DB server administrator or user may make settings related to the DBMS 141 from the DB server management terminal 3504. Note that at least two of the management terminals 3503 to 3505 may be common (integrated). Moreover, at least two of the communication networks 3511, 3512, 3514, 3515, 3516, and 300 may be common (integrated).
  • the user terminal 3501 issues a request (hereinafter referred to as a user request) to the AP server 3502.
  • the AP server 3502 generates a query according to the user request received in S121. Then, the generated query is issued to the DB server 100.
  • the DB server 100 accepts a query from the AP server 3502, and executes the accepted query.
  • the DB server 100 issues a data input / output request (for example, a data read request) necessary for executing the accepted query to the external storage device 200.
  • the DB server 100 may issue a plurality of data input / output requests in parallel in the execution of one query.
  • the DB server 100 may make the request of S123 in parallel several times in the execution of one query.
  • the external storage apparatus 200 responds to the DB server 100 with respect to the data input / output request issued in S123.
  • the external storage apparatus 200 may perform the response of S124 in parallel several times.
  • the DB server 100 generates a query execution result and transmits it to the AP server 3502.
  • the AP server 3502 receives the query execution result. Then, the response to the user request received in S121 according to the execution result is transmitted to the user terminal 3501.
  • DBMS Database management system

Landscapes

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

Abstract

　データベース管理システム（ＤＢＭＳ）は、クエリを実行するために必要な１以上のデータベース（ＤＢ）オペレーションを表す情報を含むクエリ実行プランを生成し、そのクエリ実行プランに基づいて、クエリを実行する。ＤＢＭＳは、そのクエリの実行において、ＤＢオペレーションを実行するためのタスクを動的に生成し、動的に生成されたタスクを実行する。ＤＢＭＳは、プロセッサコアにより実行される複数のスレッドにおいてタスクを実行する。

Description

データベース管理システム、計算機、データベース管理方法
　本発明は、データ管理技術に関する。
　企業活動において、大量に生じる業務データの活用は不可欠になっている。そのため、大量の業務データを蓄積したデータベース（以下、「ＤＢ」）を解析処理するシステムが既に考案されている。
　この解析処理において、データベース管理システム（以下、「ＤＢＭＳ」）は、クエリを受け付け、ＤＢを格納する記憶デバイスにデータ読出し要求を発行する。
　１つのクエリの処理におけるデータ読出しの待ち時間の短縮化を図る技術として、特許文献１に開示の技術が知られている。特許文献１によれば、ＤＢＭＳは、クエリを実行するために必要な複数のデータベースオペレーション（ＤＢオペレーション、または、処理ステップと呼ぶ）を組合せたプラン（以下、クエリ実行プラン）を生成し、前記処理ステップを実行するタスクを動的に生成し、前記タスクを並行実行することでデータ読出し要求を多重化する。特許文献１によれば、タスクの実装としては、ＯＳが管理するプロセスやスレッド、または、アプリケーションやミドルウェアが実装する擬似プロセスや擬似スレッドなど任意の実行環境が利用できる。
特開２００７－３４４１４号公報
　ＤＢに蓄積したデータの数が数万ある場合、１つのクエリの処理に対して数万のタスクを生成する場合がある。このような場合にタスクをスレッド（またはプロセス）で実装するとスレッドが数万も生成される。複数のプロセッサコアを持つ計算機では、スレッドが任意のプロセッサコア上で実行するため、任意のプロセッサコアがスレッドの管理構造体を更新する。このため、スレッドの実行を管理するオーバヘッドが大きくなる。その結果、クエリの実行時間が伸びてしまう問題がある。
　一方、擬似スレッド（または擬似プロセス）で実装すると、1つのスレッド（またはプロセス）で実装することになる。数万もの擬似スレッドを生成しても、擬似スレッドの管理構造体は１つのスレッドしか更新しないため、管理オーバヘッドは小さい。しかし、計算機が複数のプロセッサコアを持つ場合、スレッドが１つのためプロセッサコアを１つしか使わない。このため、処理ステップを実行するために必要となるプロセッサコアの処理が多い場合にプロセッサコアを１つしか使えないため、クエリの実行時間が伸びてしまう問題がある。
　そこで、本発明の目的は、ＤＢＭＳが複数のプロセッサコアを使い、かつ、スレッドの管理オーバヘッドを小さくすることである。
　ＤＢＭＳは、プロセッサコアを有する計算機により実現され、ＤＢを管理する。ＤＢＭＳは、ＤＢへのクエリを受け付けるクエリ受付部と、前記受け付けたクエリを実行するために必要な処理ステップと前記処理ステップの実行手順とを表す情報を含んだクエリ実行プランを生成するクエリ実行プラン生成部と、前記生成したクエリ実行プランに基づいて前記受け付けたクエリを実行し、前記受け付けたクエリの実行において、処理ステップを実行するためのタスクを動的に生成し、前記動的に生成されたタスクを実行するクエリ実行部とを有する。
　前記クエリ実行部は、前記受け付けたクエリの実行において、プロセッサコアにより実行される複数のスレッドにおいてタスクを実行し、前記プロセッサコアにより実行される一つのスレッドにおいて複数のタスクを実行する。例えば、クエリ実行部は、クエリの実行において、データベースオペレーションを実行するためのタスクを動的に生成し、動的に生成されたタスクを実行して良い。例えば、クエリ実行部は、クエリの実行において、（ａ）データベースオペレーションを実行するためのタスクを生成すること、（ｂ）生成されたタスクを実行することで、当該タスクに対応したデータベースオペレーションに必要なデータを読み出すためにデータベースへデータ読出し要求を発行すること、（ｃ）上記（ｂ）で実行されたタスクに対応したＮ番目のデータベースオペレーションの実行結果に基づき（Ｎ＋１）番目のデータベースオペレーションを実行する場合には、当該実行結果に基づくタスクを新たに生成すること（Ｎは１以上の整数）、及び、（ｄ）その新たに生成したタスクについて（ｂ）及び（ｃ）を行うこと、を行い、（ｂ）及び（ｄ）において、２以上の実行可能なタスクが存在する場合には、それら２以上のタスクのうちの少なくとも２つのタスクを並行して実行するようになっていて良い。
　タスクを新たに生成する場合に、コンテキストを生成して、前記生成したコンテキストに基づいて前記生成されたタスクを実行する。前記コンテキストは、前記新たに生成するタスクにおいて実行を開始する処理ステップが、前記クエリ実行プランが表す１以上の処理ステップのうちのいずれであるかを示す第１の情報と、前記第１の情報が示す処理ステップに要するデータのアクセス先に関する第２の情報と、前記新たに生成するタスクにより結果を生成するために必要なデータに関する第３の情報とを含む情報である。
　本発明によれば、一つのスレッドが複数のタスクを実行し、複数の前記スレッドでクエリを実行することにより、複数のプロセッサコアを使い、かつ、スレッドの管理オーバヘッドが小さくなる。その結果、クエリの実行時間が短縮できる。
図１は、実施例１に係るＤＢＭＳの概要を説明する図である。 図２は、実施例１に係るＤＢＭＳにおけるクエリの実行を説明する図である。 図３は、実施例１に係る計算機システムの構成図である。 図４は、実施例１に係るＤＢの表及び索引の定義を説明する図である。 図５は、実施例１に係るＤＢのＰａｒｔ表の一例を示す図である。 図６は、実施例１に係るＤＢのＬｉｎｅｉｔｅｍ表の一例を示す図である。 図７は、実施例１に係るＤＢにおけるＰａｒｔ索引及びＰａｒｔ表のデータ構造の一例を説明する図である。 図８は、実施例１に係るＤＢのクエリの一例を示す図である。 図９は、実施例１に係るクエリ実行プランの一例を示す図である。 図１０は、実施例１に係るタスク管理情報のデータ構造の一例を示す図である。 図１１は、実施例１に係るタスク実行状態情報の一例を示す図である。 図１２は、実施例１に係る処理ステップ実行状態情報の第１の例を示す図である。 図１３は、実施例１に係る処理ステップ実行状態情報の第２の例を示す図である。 図１４は、実施例１に係る処理ステップ実行状態情報の第３の例を示す図である。 図１５は、実施例１に係るコンテキスト管理情報のデータ構造の一例を説明する図である。 図１６は、実施例１に係るスレッド＃１向け検索テーブルの一例を示す図である。 図１７は、実施例１に係るスレッド＃２向け検索テーブルの一例を示す図である。 図１８は、実施例１に係るスレッド＃３向け検索テーブルの一例を示す図である。 図１９は、実施例１に係るコンテキストの一例を示す図である。 図２０は、実施例１に係るクエリ受付時処理のフローチャートである。 図２１は、実施例１に係るクエリ実行プラン生成処理のフローチャートである。 図２２は、実施例１に係るスレッド間共有フラグ設定処理のフローチャートである。 図２３は、実施例１に係るクエリ実行プランの他の例を説明する図である。 図２４は、実施例１に係る結果送信処理のフローチャートである。 図２５は、実施例１に係るスレッド実行処理のフローチャートである。 図２６は、実施例１に係るタスク実行処理のフローチャートである。 図２７は、実施例１に係るコンテキスト検索処理のフローチャートである。 図２８は、実施例１に係るクエリ実行プラン実行処理のフローチャートである。 図２９は、実施例１に係るＤＢページ取得処理のフローチャートである。 図３０は、実施例１に係る新規タスク追加処理のフローチャートである。 図３１は、実施例１に係るコンテキスト共有判定処理のフローチャートである。 図３２は、実施例１に係るコンテキスト登録処理のフローチャートである。 図３３は、実施例１に係るタスク生成処理のフローチャートである。 図３４は、変形例に係る負荷分散処理のフローチャートである。 図３５は、実施例２に係る計算機システムの構成を示す。
　まず、実施例１の概要について説明する。
　図１は、実施例１に係るＤＢＭＳの概要を説明する図である。
　ＤＢＭＳ１４１は、クライアント通信制御部１４２と、クエリ実行プラン１４３と、クエリ実行部１４４と、実行タスク管理部１４５と、スレッド管理部１４６と、ＤＢバッファ管理部１４７とを有する。クエリ実行部１４４は、クエリ実行プラン実行部１５１と、コンテキスト管理部１５２と、コンテキスト共有判定部１５３とを有する。
　ＤＢＭＳ１４１（クエリ実行部１４４）は、クエリの実行において、処理ステップを実行するためのタスクを動的に生成し、動的に生成されたタスクを実行する。具体的には、例えば、ＤＢＭＳ１４１（クエリ実行部１４４）は、クエリの実行において、（ａ）処理ステップを実行するためのタスクを生成すること、（ｂ）生成されたタスクを実行することで、前記タスクに対応した処理ステップに必要なデータを読み出すためにＤＢへデータ読出し要求を発行すること、（ｃ）上記（ｂ）で実行されたタスクに対応したＮ番目の処理ステップの実行結果に基づき（Ｎ＋１）番目の処理ステップを実行する場合には、前記実行結果に基づくタスクを新たに生成すること（Ｎは１以上の整数）、及び、（ｄ）前記新たに生成したタスクについて上記（ｂ）及び上記（ｃ）を行うこと、を行い、上記（ｂ）及び（ｄ）において、２以上の実行可能なタスクが存在する場合には、それら２以上のタスクのうちの少なくとも２つのタスクを並行して実行することができる。
　ＤＢＭＳ１４１（クエリ実行部１４４）は、タスクを実行する際に、オペレーティングシステム（ＯＳ）が提供するスレッド（カーネルスレッド）を複数利用し、それら複数のスレッドが、それぞれ、１又は複数のプロセッサが有する１又は複数のプロセッサコアにより実行される。プロセッサコアがスレッドを実行することで、スレッドに割当たったタスクを実行する。以下、プロセッサコアがタスクを実行する、或いは、ＤＢＭＳ１４１がタスクを実行する、のような表現は、プロセッサコアがスレッドを実行することにより前記スレッドに割当たったタスクを実行することを意味する。
　ＤＢＭＳ１４１は、クライアント通信制御部１４２を介して、クエリを受信する。クエリ実行プラン生成部１４３は、受信したクエリを実行するためのクエリ実行プランＰＬを生成する。クエリ実行プラン実行部１５１は、生成されたクエリ実行プランＰＬを実行する。スレッド管理部１４６は、ＤＢＭＳ１４１が構築された計算機におけるプロセッサのプロセッサコアにて実行されるスレッドを複数管理する。実行タスク管理部１４５は、スレッドで実行するタスクを管理する。本実施例では、実行タスク管理部１４５は、スレッド１つに対して、複数のタスクを割り当てることができる。これにより、スレッドの管理に要するオーバヘッドを低減することができる。
　コンテキスト管理部１５２は、タスクを実行する際に利用するコンテキストを管理する。コンテキストとしては、複数のスレッドから利用できるように管理するスレッド間共有のコンテキストと、１つのスレッドから利用できるように管理するスレッド間非共有のコンテキストがある。スレッド間非共有のコンテキストを利用できるスレッドは、他のスレッドに比べ前記コンテキストを優先的に利用する。
　図１の例では、コンテキスト＃０とコンテキスト＃１がスレッド間共有のコンテキストであり、コンテキスト＃２、コンテキスト＃３、及びコンテキスト＃４がスレッド間非共有のコンテキストである。スレッド＃１およびスレッド＃２およびスレッド＃３に割当たったタスクを実行する際に、コンテキスト＃０とコンテキスト＃１を利用する。スレッド＃１に割当たったタスクを実行する際に、コンテキスト＃２を利用する。スレッド＃２に割当たったタスクを実行する際に、コンテキスト＃３を利用する。コンテキスト＃４は、スレッド＃３に割当たったタスクを実行する際に、コンテキスト＃４を利用する。
　コンテキストを、スレッド間共有とするか、スレッド間非共有とするかは、コンテキスト共有判定部１５３による判定結果に基づいて決定する。例えば、コンテキスト共有判定部１５３は、クエリ実行プランの先頭の処理ステップに関わるコンテキストを、スレッド間共有のコンテキストとして良い。また、コンテキスト共有判定部１５３は、クエリ実行プランが並行実行可能な複数の処理ブロックにより構成されている場合には、各処理ブロックの最初の処理ステップに関わるコンテキストを、スレッド間共有のコンテキストとしても良い。また、コンテキスト共有判定部１５３は、１つの処理ブロックにおいて後続の処理ステップ数が所定数以上である処理ステップに関わるコンテキストを、スレッド間共有のコンテキストとして良い。処理ブロックは、１以上の処理ステップで構成されていて良い。並行実行可能な複数の処理ブロックにより構成されているクエリ実行プランの一例は、後述する。
　図２は、実施例１に係るＤＢ管理システムにおけるクエリの実行を説明する図である。なお、同図においては、上から下方向に時間の経過を表現している。
　まず、スレッド管理部１４６が、スレッド＃１、スレッド＃２、スレッド＃３を生成する。これらスレッド＃１～＃３は、例えば、異なるプロセッサコアにより並行して実行可能である。クエリ実行プラン実行部１５１（具体的には、１つのプロセッサコア）が、クエリの実行を開始するコンテキスト＃０を生成し、タスク＃１を生成する。コンテキスト＃０は、クエリ実行プランの先頭である処理ステップ＃１に関するコンテキストであるのでスレッド間共有となる。クエリ実行プラン実行部１５１は、タスク＃１をスレッド＃１に割り当てる。スレッド＃１は、コンテキスト＃０を利用し、タスク＃１を実行する。タスク＃１を実行すると、コンテキスト＃１を生成し、タスク＃２とタスク＃３を生成する。コンテキスト＃１は、クエリ実行プランの先頭である処理ステップ＃１に関するコンテキストであるので、スレッド間共有となる。スレッド＃１は、タスク＃２をスレッド＃２に割り当て、タスク＃３をスレッド＃３に割り当てる。スレッド＃２は、コンテキスト＃１を利用し、タスク＃２を実行する。スレッド＃３は、コンテキスト＃１を利用し、タスク＃３を実行する。
　スレッド＃１がタスク＃１を実行し、ＤＢへのアクセス処理を実行する。その結果、新たなコンテキストを生成する。例えば、処理ステップ＃３に関するコンテキスト＃２を生成する。コンテキスト＃２の処理ステップは、クエリ実行プランの先頭ではないため、スレッド間非共有となっている。すなわち、コンテキスト＃２は、基本的には、スレッド＃１によって利用される。スレッド＃１がタスク＃４を生成し、スレッド＃１に割り当てる。スレッド＃１は、コンテキスト＃２を利用し、タスク＃４を実行する。
　スレッド＃２がタスク＃２を実行し、ＤＢへのアクセス処理を実行する。その結果、新たなコンテキストを生成する。例えば、処理ステップ＃３に関するコンテキスト＃３を生成する。コンテキスト＃３の処理ステップは、クエリ実行プランの先頭ではないため、スレッド間非共有となっている。すなわち、コンテキスト＃３は、基本的には、スレッド＃２によって利用される。スレッド＃２がタスク＃５とタスク＃６を生成し、スレッド＃２に割り当てる。スレッド＃２は、コンテキスト＃３を利用し、タスク＃５を実行する。さらに、スレッド＃２は、コンテキスト＃３を利用し、タスク＃６を実行する。
　スレッド＃３がタスク＃３を実行し、ＤＢへのアクセス処理を実行する。その結果、新たなコンテキストを生成する。例えば、処理ステップ＃３に関するコンテキスト＃４を生成する。コンテキスト＃４の処理ステップは、クエリ実行プランの先頭ではないため、スレッド間非共有となっている。すなわち、コンテキスト＃４は、基本的には、スレッド＃３によって利用される。スレッド＃３がタスク＃７とタスク＃８を生成し、スレッド＃３に割り当てる。スレッド＃３は、コンテキスト＃４を利用し、タスク＃７を実行する。さらに、スレッド＃３は、コンテキスト＃４を利用し、タスク＃８を実行する。
　このように、一つのスレッドが複数のタスクを実行し、複数の前記スレッドでクエリを実行する。その結果、複数のプロセッサコアを使い、かつ、スレッドの管理オーバヘッドが小さくなるため、クエリの実行時間が短縮できる。
　以下、実施例１を詳細に説明する。
　図３は、実施例１に係る計算機システムの構成図である。
　計算機システムは、計算機１００と、外部ストレージ装置２００とを有する。計算機１００と、外部ストレージ装置２００とは、通信ネットワーク３００を介して接続されている。通信ネットワーク３００を介した通信のプロトコルとしては、例えば、ＦＣ（Fibre　Channel）、ＳＣＳＩ（Small　Computer　System　Interface）、ＩＢ（Infini　Band）、又は、ＴＣＰ／ＩＰ（Transmission　Control　Protocol／Internet　Protocol）が採用されて良い。
　計算機１００は、例えば、パーソナルコンピュータ、ワークステーション又はメインフレームである。計算機１００は、ネットワークアダプタ１１０、プロセッサ（典型的にはマイクロプロセッサ（例えばＣＰＵ（Central　Processing　Unit）））１２０、ローカル記憶デバイス１３０、及びメモリ１４０を有する。プロセッサ１２０は、コンピュータプログラム、例えば、図示しないＯＳ（Operating　System）や、ＤＢＭＳ１４１を実行する。１又は複数のプロセッサ１２０は、１又は複数のプロセッサコアを有する。各プロセッサコアがそれぞれ独立して処理を実行することができるようになっている。プロセッサコアは、メモリ１４０よりもアクセスレイテンシの短いキャッシュを持つ。プロセッサコアは、メモリ１４０に記録されたデータをキャッシュに保持し、当該データの処理を行う。一つのプロセッサコアが同じデータを連続して処理する場合は、キャッシュに保持したデータが利用できるため、別々のプロセッサコアが同じデータを連続して処理した場合に比べ処理時間は短い。本実施例では、基本的には、各プロセッサコアは、ある時点で見ると、スレッド（カーネルスレッド）を１つ実行することができる。メモリ１４０は、プロセッサ１２０によって実行されるプログラムと、プログラムが使用するデータとを一時的に記憶する。本実施例では、メモリ１４０は、ＤＢの管理や関連する一連の処理を行うプログラムであるＤＢＭＳ１４１及びデータを記憶する。メモリ１４１は、ＤＢＭＳ１４１にクエリを発行するためのＡＰ（Application　Program）１４８を記憶するようにしても良い。ローカル記憶デバイス１３０は、プログラム、及びプログラムが使用するデータを格納する。ネットワークアダプタ１１０は、通信ネットワーク３００と計算機１００とを接続する。また、プロセッサ１２０は、ネットワークアダプタ１１０及びメモリ１４０等に接続された制御デバイスに含まれている要素で良い。制御デバイスは、プロセッサ１２０の他に、専用ハードウェア回路（例えば、データの暗号化及び／又は復号化を行う回路）を含んで良い。
　なお、計算機１００は、性能面や冗長性の観点から、ネットワークアダプタ１１０、プロセッサ１２０、ローカル記憶デバイス１３０、及びメモリ１４０のうちの少なくとも１つの要素を複数備えていても良い。また、計算機１００は、図示しない入力デバイス（例えば、キーボード及びポインティングデバイス）と表示デバイス（例えば液晶ディスプレイ）とを有して良い。入力デバイスと表示デバイスは一体になっていても良い。
　計算機１００では、ＤＢＭＳ１４１が、ＤＢＭＳ１４１に対して発行されたクエリを実行する。このクエリは、計算機１００で実行されるＡＰ１４８又は、通信ネットワーク３００に接続された図示しない計算機（クライアント）で実行されるＡＰにより発行される。ＤＢＭＳ１４１は、ＡＰ１４８により発行されたクエリを実行し、前記クエリの実行に伴い、外部ストレージ装置２００に格納されたＤＢ２０６に対するＩ／Ｏ要求を、ＯＳを介して外部ストレージ装置２００に送信する。なお、ＯＳは、仮想化プログラムが作成し実行する仮想マシン上で動作するＯＳであっても良い。
　外部ストレージ装置２００は、計算機１００が使用するデータを記憶する。外部ストレージ装置２００は、計算機１００からＩ／Ｏ要求を受信し、Ｉ／Ｏ要求に対応した処理を実行し、処理結果を計算機１００に送信する。
　外部ストレージ装置２００は、ネットワークアダプタ２０１、記憶デバイス群２０３及びそれらに接続されたコントローラ２０２を有する。
　ネットワークアダプタ２０１は、外部ストレージ装置２００を通信ネットワーク３００に接続する。
　記憶デバイス群２０３は、１つ以上の記憶デバイスを含む。記憶デバイスは、不揮発性の記憶媒体であって、例えば、磁気ディスク、フラッシュメモリ、その他半導体メモリである。記憶デバイス群２０３は、ＲＡＩＤ（Redundant　ARRAY　of　Independent　Disks）に従い所定のＲＡＩＤレベルでデータを記憶するグループであっても良い。記憶デバイス群２０３の記憶空間に基づく論理的な記憶デバイス（論理ボリューム）が計算機１００に提供されても良い。記憶デバイス群２０３は、ＤＢ２０６を記憶する。ＤＢ２０６は、１つ以上の表２０４や索引２０５を含む。表は１つ以上のレコードの集合であり、レコードは１つ以上のカラムから構成される。索引は、表の中の１つ以上のカラムを対象に作成されるデータ構造であり、当該索引が対象とするカラムを含む選択条件による表へのアクセスを高速化する。例えば、索引は、対象とするカラムの値毎に前記値を含む表の中のレコードを特定する情報（ＲｏｗＩＤ）を保持するデータ構造であり、Ｂ木構造などが用いられる。ＤＢの表の構成例や表同士の関連性の一例は、後述する。
　コントローラ２０２は、例えば、メモリ及びプロセッサを含んでおり、計算機１００からのＩ／Ｏ要求に従って、ＤＢ２０６を記憶した記憶デバイス群２０３にデータを入出力する。例えば、コントローラ２０２は、計算機１００からの書込み要求に従う書込み対象のデータを記憶デバイス群２０３に格納したり、計算機１００からの読出し要求に従う読出し対象のデータを記憶デバイス群２０３から読み出し、前記データを計算機１００に送信したりする。
　なお、外部ストレージ装置２００は、性能面や冗長性確保の観点から、コントローラ２０２などの要素を複数備えても良い。また、外部ストレージ装置２００を複数備えても良い。
　ＤＢＭＳ１４１は、業務データを含んだＤＢ２０６を管理する。ＤＢＭＳ１４１は、クライアント通信制御部１４２、クエリ実行プラン生成部１４３、クエリ実行部１４４、実行タスク管理部１４５、スレッド管理部１４６、及びＤＢバッファ管理部１４７を含む。
　クライアント通信制御部１４２は、通信ネットワーク３００に接続されたクライアントまたはＡＰ１４８との間の通信を制御する。具体的には、クライアント通信制御部１４２は、クライアントまたはＡＰ１４８から発行されたクエリを受信し（受け付け）、クエリの処理結果をクライアントまたはＡＰ１４８に送信する処理を実行する。クエリは、例えばＳＱＬ（Structured　Query　Language）で記述されている。
　クエリ実行プラン生成部１４３は、クライアント通信制御部１４２が受け付けたクエリを実行するために必要な１つ以上の処理ステップを有するクエリ実行プランを生成する。クエリ実行プランは、例えば、クエリの実行の際に行うべき処理ステップの実行順序を木構造で定義した情報であり、メモリ１４０に格納される。クエリ実行プランの一例は、後述する。
　ＤＢバッファ管理部１４７は、ＤＢ２０６内のデータを一時的に格納するための記憶領域（ＤＢバッファ）を管理する。ＤＢバッファは、メモリ１４０上に構築される。また、ＤＢバッファは、ローカル記憶デバイス１３０上に構築されても良い。
　クエリ実行部１４４は、クエリ実行プラン生成部１４３が生成したクエリ実行プランに従ってクエリを実行し、生成した結果をクエリの発行元に返す。クエリ実行部１４４は、クエリ実行プラン実行部１５１と、コンテキスト管理部１５２と、コンテキスト共有判定部１５３とを有する。
　クエリ実行プラン実行部１５１は、クエリ実行プラン内の処理ステップを実行するためのタスクを動的に生成し、スレッドにタスクを割り当て、スレッドがタスクを実行することでクエリを実行する。
　コンテキスト管理部１５２は、生成するタスクの実行に必要な情報を含むコンテキストを管理する。ここで、コンテキストは、タスクにおいて実行を開始する処理ステップが、クエリ実行プランが表す１以上の処理ステップのうちのいずれであるかを示す第１の情報と、第１の情報が示す処理ステップに要するデータのアクセス先に関する第２の情報と、タスクにより結果を生成するために必要なデータに関する第３の情報とを含む情報である。コンテキストを管理するための情報であるコンテキスト管理情報の構造については後述する。
　コンテキスト共有判定部１５３は、コンテキストを複数のスレッド間で共有するか否かを判定する。
　実行タスク管理部１４５は、スレッドが実行するタスクを管理する。タスクは、例えば、ＤＢＭＳ４１２で実装される疑似プロセス又は疑似スレッド（ユーザレベルスレッド）である。なお、タスクは、各処理を関数としてまとめた関数へのポインタ（関数ポインタ）の集合であってもよい。タスクを管理するための情報であるタスク管理情報の構造については、後述する。
　スレッド管理部１４６は、クエリを実行するためのスレッドを管理する。ここで、スレッドとは、ＯＳが提供するスレッド（カーネルスレッド）である。前述したように、プロセッサコアが割当たったスレッドを実行することにより、スレッドに割当たったタスクが実行される。なお、スレッドの代わりにプロセスを使用してもよい。
　クライアント通信制御部１４２、クエリ実行プラン生成部１４３、クエリ実行部１４４、及びＤＢバッファ管理部１４７の少なくとも１つの処理部が行う処理の少なくとも一部が、ハードウェアで行われても良い。また、本実施例の説明において、処理部が主語になる場合は、実際には前記処理部を実行するプロセッサ１２０によって処理が行われるが、処理部の少なくとも一部がハードウェアで実現されている場合は、プロセッサ１２０に代えて又は加えて、前記ハードウェアも、主語とされ得る。ＤＢＭＳ１４１を実現するコンピュータプログラムは、プログラムソースから計算機１００にインストールされて良い。プログラムソースは、例えば、計算機１００が読み取り可能な記憶メディアで良いし、他の計算機でも良い。
　また、図３に示したＤＢＭＳ１４１の構成は、一例である。例えば、或る処理部が複数の処理部に分割されたり、複数の処理部の機能を統合した１つの処理部が構築されたりしても良い。
　図４は、実施例１に係るＤＢの表及び索引の定義を説明する図である。
　ＤＢ２０６は、表２０５として、例えば、カラムｃ１及びカラムｃ２を含むＰａｒｔ表と、カラムｃ３及びカラムｃ４を含むＬｉｎｅｉｔｅｍ表とを有する。また、ＤＢ２０６は、索引２０４として、カラムｃ１の値に基づいたＰａｒｔ表に関する索引（Ｐａｒｔ索引）と、カラムｃ３の値に基づいたＬｉｎｅｉｔｅｍ表に関する索引（Ｌｉｎｅｉｔｅｍ索引）とを有する。
　図５は、実施例１に係るＤＢのＰａｒｔ表の一例を示す図である。
　ＤＢ２０６のＰａｒｔ表は、論理的には、例えば、カラムｃ１の値と、対応するカラムｃ２の値とを対応付けた表となっている。
　図６は、実施例１に係るＤＢのＬｉｎｅｉｔｅｍ表の一例を示す図である。
　ＤＢ２０６のＬｉｎｅｉｔｅｍ表は、例えば、カラムｃ３の値と、対応するカラムｃ４の値とを対応付けた表となっている。
　図７は、実施例１に係るＤＢにおけるｐａｒｔ索引及びｐａｒｔ表のデータ構造の一例を説明する図である。
　Ｐａｒｔ索引は、例えば、カラムｃ１の値に基づいて、対応するカラムｃ２の値を格納するｐａｒｔ表のページ及びスロットを検索するためのＢ木構造となっている。ページとは、ＤＢ２０６に対する入出力における最小のデータ単位である。本実施例では、Ｐａｒｔ索引は、ページＰを階層構造として管理している。Ｐａｒｔ索引においては、最下位のページであるリーフページと、リーフページの上位のページである上位ページとがある。ここで、上位ページの中の最上位のページをルートページということとする。
　Ｐａｒｔ索引のルートページ（ページＰ１）には、一つ下の階層のページに対するポインタと、当該一つ下の階層のページが管理対象とするカラムｃ１の値の最大値とを対応付けたエントリが１以上設けられる。例えば、ページＰ１には、「１００」以下のカラムｃ１の値に対する対応関係を管理するページＰ２へのポインタと、「１００」より大きく「２００」以下のカラムｃ１の値に対する対応関係を管理するページＰ３へのポインタと、「２００」より大きく「３００」以下のカラムｃ１の値に対する対応関係を管理するページＰ４へのポインタとが格納される。同様に、上位ページにおいては、それぞれのページの一つ下の階層のページに対するポインタと、当該１つ下の階層のページに管理されているカラムｃ１の値の最大値とを対応付けたエントリが１以上設けられる。
　一方、リーフページには、カラムｃ１の値と、当該値に対応するカラムｃ２の値を格納するＰａｒｔ表における格納位置（例えば、Ｐａｒｔ表のページ番号及びの当該ページ中のスロット番号）とを対応付けたロー（行：レコード）を１以上格納する。
　例えば、リーフページであるページＰ８には、カラムｃ１の値「１１０」に対応するカラムｃ２の値が格納されているページ及びスロットの番号を含むローと、カラムｃ１の値「１３０」に対応するカラムｃ２の値が格納されているページ及びスロットの番号を含むローとが格納される。例えば、カラムｃ１の値「１３０」に対応するカラムｃ２の値が格納されているページ及びスロットの番号を含むローとしては、ページＰ１００のスロット２、ページＰ１２０のスロット１、ページＰ２００のスロット４とを示すローが格納される。従って、カラムｃ１の値「１３０」に対応するカラムｃ２の値は、Ｐａｒｔ表のページＰ１００のスロット２のレコードから「ｉｄ１３１」となり、また、Ｐａｒｔ表のページ１２０のスロット１のレコードから「ｉｄ１３２」となり、Ｐａｒｔ表のページ２００のスロット４のレコードから「ｉｄ１３３」となる。
　図８は、実施例１に係るＤＢのクエリの一例を示す図である。
　図８に示すクエリは、図４～図７に示す構造のＤＢ２０６に対するクエリの一例である。図８に示すクエリは、Ｐａｒｔ表及びＬｉｎｅｉｔｅｍ表から、カラムｃ１の値が「１３０」であり、且つカラムｃ２の値とカラムｃ３の値とが同じであるものについて、カラムｃ１の値とカラムｃ４の値とを抽出することを意味している。
　図９は、実施例１に係るクエリ実行プランの一例を示す図である。
　同図に示すクエリ実行プランは、ＤＢＭＳ１４１が図８に示すクエリを受け付けた場合に、クエリ実行プラン生成部１４３により生成されるクエリ実行プランを示している。
　図８に示すクエリに対応するクエリ実行プランは、図９に示すように、Ｐａｒｔ索引による索引検索を行う処理ステップ＃１と、Ｐａｒｔ表からレコードを取得する処理ステップ＃２と、Ｌｉｎｅｉｔｅｍ索引による索引検索を行う処理ステップ＃３と、Ｌｉｎｅｉｔｅｍ表からレコードを取得する処理ステップ＃４と、これらの結果をネストループ結合する処理ステップ＃５とを含む。
　図１０は、実施例１に係るタスク管理情報のデータ構造の一例を示す図である。
　タスク管理情報は、メインデータ構造体７１を有する。メインデータ構造体７１は、複数のスレッドを特定するスレッド特定情報（例えば、スレッド番号）と、スレッドが実行するタスクを管理するリスト管理構造体７２へのポインタを、スレッドごとに対応付けて記憶する。
　リスト管理構造体７２は、対応するスレッドにおける実行可能なタスクを管理するための実行可能リスト７２ａと、対応するスレッドにおける実行待ち状態であるタスクを管理するための待ちリスト７２ｂとを記憶する。実行可能リスト７２ａは、対応するスレッドにおいて実行可能なタスクに関する実行状態情報（タスク実行状態情報）７３へのポインタを有する。また、タスク実行状態情報７３は、対応するスレッドにおける実行可能な他のタスクに関するタスク実行状態情報７３へのポインタを有する。
　図１０においては、例えば、スレッド＃２における実行可能なタスクに関するタスク実行状態情報７３としては、タスク＃２に対する実行状態情報（タスク＃２実行状態情報）が管理され、スレッド＃２における実行待ち状態であるタスクに関するタスク実行状態情報７３としては、タスク＃５及びタスク＃６のタスク実行状態情報７３が管理されている。なお、複数のスレッド間においてタスクの偏りがある場合には、タスク（すなわち、タスク実行状態情報７３）を別のスレッドのリストに移動させるようにしてもよい。
　なお、本実施例では、スレッド毎に、実行可能リスト及び待ちリストを管理するようにしているが、実行可能リスト及び待ちリストを複数のスレッド間で共有しても良い。また、処理ステップごとに、実行可能リスト及び待ちリストを管理するようにしても良い。
　図１１は、実施例１に係るタスク実行状態情報の一例を示す図である。
　タスク実行状態情報７３は、ワーク領域７３ａと、処理ステップ７３ｂと、処理ステップ実行状態７３ｃとを格納する。ワーク領域７３ａには、ワーク領域を示すポインタが格納される。処理ステップ７３ｂには、対応するタスクにより実行する処理ステップを識別する情報、例えば、処理ステップ番号が格納される。処理ステップ実行状態７３ｃには、対応する処理ステップの実行状態情報（処理ステップ実行状態情報）７４が格納される。処理ステップ実行状態情報７４の具体例については、後述する。
　図１２は、実施例１に係る処理ステップ実行状態情報の第１の例を示す図である。図１２は、索引検索における上位ページを使用するタスクについての処理ステップ実行状態情報を示す。
　処理ステップ実行状態情報７４Ａは、検索条件７４ａと、ページ番号７４ｂと、スロット番号７４ｃとを含む。検索条件７４ａには、検索条件を格納する。同図の例では、検索条件７４ａには、クエリに含まれる検索条件であるｋｅｙ値の範囲「１１５以上ｋｅｙ以上１９５」を格納する。ページ番号７４ｂには、タスクの処理で使用する上位ページの番号（ページ番号）を格納する。スロット番号７４ｃには、タスクの処理で使用するページにおけるスロットの番号（スロット番号）を格納する。
　図１３は、実施例１に係る処理ステップ実行状態情報の第２の例を示す図である。図１３は、索引検索におけるリーフページを使用するタスクについての処理ステップ実行状態情報を示す。
　処理ステップ実行状態情報７４Ｂは、検索条件７４ｄと、ページ番号７４ｅと、スロット番号７４ｆと、処理ローＩＤ数７４ｇとを含む。検索条件７４ｄには、検索条件を格納する。同図の例では、検索条件７４ｄには、検索条件であるｋｅｙ値の範囲「１１５以上Ｋｅｙ以上１９５」を格納する。ページ番号７４ｅには、タスクの処理で使用するリーフページのページ番号を格納する。スロット番号７４ｆには、タスクの処理で使用するページにおけるスロットのスロット番号を格納する。処理ローＩＤ番号７４ｇには、対応するタスクで処理するスロット内のローのＩＤ番号（処理ローＩＤ番号）を格納する。
　図１４は、実施例１に係る処理ステップ実行状態情報の第３の例を示す図である。図１４は、レコード取得を行うタスクについての処理ステップ実行状態情報を示す。
　処理ステップ実行状態情報７４Ｃは、ページ番号７４ｈと、スロット番号７４ｉとを含む。ページ番号７４ｈには、タスクの処理で使用するページのページ番号を格納する。スロット番号７４ｉには、タスクの処理で使用するページにおけるスロットのスロット番号を格納する。
　図１５は、実施例１に係るコンテキスト管理情報のデータ構造の一例を説明する図である。
　コンテキスト管理情報８０は、管理リストのメイン構造体８１と、複数のコンテキスト８２を含む。メイン構造体８１には、コンテキスト８２へのポインタを格納する。また、各コンテキスト８２には、他のコンテキスト８２へのポインタを格納する。本実施例では、タスクの処理でコンテキスト８２を利用する場合には、タスクを実行しているスレッドが各コンテキスト８２を単位として排他（ロック）をかける。ロック状態のコンテキストは他のスレッドからは利用できない。
　また、コンテキスト管理情報８０は、クエリを実行するスレッドに対応する検索テーブル（スレッド向け検索テーブル）８３、８４、８５等を記憶する。スレッド＃１向け検索テーブル８３は、スレッド＃１が利用可能なコンテキスト８２へのポインタを管理する。スレッド＃２向け検索テーブル８４は、スレッド＃２が利用可能なコンテキスト８２へのポインタを管理する。スレッド＃３向け検索テーブル８５は、スレッド＃３が利用可能なコンテキスト８２へのポインタを管理する。
　図１６は、実施例１に係るスレッド＃１向け検索テーブルの一例を示す図である。図１７は、実施例１に係るスレッド＃２向け検索テーブルの一例を示す図である。図１８は、実施例１に係るスレッド＃３向け検索テーブルの一例を示す図である。
　スレッド＃１向け検索テーブル８３は、スレッド＃１が利用可能なコンテキストへのポインタを管理するテーブルであり、各処理ステップに関わるコンテキストへのポインタをリストで管理する。図１６に示すように、処理ステップ＃１に関わるコンテキストへのポインタ８３ａと、処理ステップ＃２に関わるコンテキストへのポインタ８３ｂと、処理ステップ＃３に関わるコンテキストへのポインタ８３ｃと、処理ステップ＃４に関わるコンテキストへのポインタ８３ｄとを含む。本実施例では、ポインタ８３ａにはコンテキスト＃１へのポインタを格納し、ポインタ８３ｃにコンテキスト＃２へのポインタを格納する。
　スレッド＃２向け検索テーブル８４は、スレッド＃２が利用可能なコンテキストへのポインタを管理するテーブルであり、各処理ステップに関わるコンテキストへのポインタをリストで管理する。図１７に示すように、処理ステップ＃１に関わるコンテキストへのポインタ８４ａと、処理ステップ＃２に関わるコンテキストへのポインタ８４ｂと、処理ステップ＃３に関わるコンテキストへのポインタ８４ｃと、処理ステップ＃４に関わるコンテキストへのポインタ８４ｄとを含む。本実施例では、ポインタ８４ａにコンテキスト＃１へのポインタを格納し、ポインタ８４ｃにコンテキスト＃３へのポインタを格納する。
　スレッド＃３向け検索テーブル８５は、スレッド＃３が利用可能なコンテキストへのポインタを管理するテーブルであり、各処理ステップに関わるコンテキストへのポインタをリストで管理する。図１８に示すように、処理ステップ＃１に関わるコンテキストへのポインタ８５ａと、処理ステップ＃２に関わるコンテキストへのポインタ８５ｂと、処理ステップ＃３に関わるコンテキストへのポインタ８５ｃと、処理ステップ＃４に関わるコンテキストへのポインタ８５ｄとを含む。本実施例では、ポインタ８５ａにコンテキスト＃１へのポインタを格納し、ポインタ８５ｃにコンテキスト＃４へのポインタを格納する。
　スレッド＃１向け検索テーブル８３、スレッド＃２向け検索テーブル８４、及びスレッド＃３向け検索テーブル８５によると、コンテキスト＃１は、スレッド＃１、スレッド＃２、又はスレッド＃３において利用可能である。一方、コンテキスト＃２は、スレッド＃１において利用可能である。コンテキスト＃３は、スレッド＃２において利用可能であり、コンテキスト＃４は、スレッド＃３において利用可能である。ここで、コンテキスト８２へのポインタが複数のスレッド向け検索テーブルに登録してある状態を、コンテキストがスレッド間共有であるといい、コンテキストへのポインタが特定の一つのスレッド向け検索テーブルに登録してある状態をコンテキストがスレッド間非共有であるという。ここで、あるスレッドを実行するプロセッサコアが当該スレッド向けのスレッド向け検索テーブルを用いて利用可能なコンテキストのことを、当該スレッドが利用可能なコンテキストという。
　この状態では、コンテキスト＃１はスレッド＃１、スレッド＃２、スレッド＃３が利用し、コンテキスト＃２はスレッド＃１が利用し、コンテキスト＃３はスレッド＃２が利用し、コンテキスト＃４はスレッド＃３が利用する。この状態の下では、スレッド間非共有のコンテキストは一つのスレッドが連続利用するため、プロセッサコアのキャッシュによりコンテキスト利用に伴う処理の処理時間が短くできる。
　なお、本実施例では、利用可能なコンテキストがスレッド間で偏った場合に、スレッドが実行するタスクの量を均等にする目的で、他のスレッド向けのスレッド向け検索テーブルを参照してもよい。具体的には、スレッドが利用可能なコンテキストがない場合、他のスレッド向けのスレッド向け検索テーブルを参照することにより、他のスレッドがスレッド間非共有のコンテキスト（コンテキスト＃２、コンテキスト＃３、コンテキスト＃４）を利用する。例えば、スレッド＃１においてスレッド＃１が利用可能なコンテキストがなくなった場合、スレッド＃１がスレッド＃２向け検索テーブルやスレッド＃３向け検索テーブルを参照し、コンテキスト＃３やコンテキスト＃４をスレッド＃１に割当たったタスクが利用する。
　図１９は、実施例１に係るコンテキストの一例を示す図である。
　コンテキスト８２は、開始ステップ８２ａと、中間結果８２ｂと、実行状態８２ｃと、生成可能数８２ｄとを含む。開始ステップ８２ａには、対応する処理ステップの番号を格納する。中間結果８２ｂには、対応する処理ステップを実行するタスクに必要な中間結果を格納するワーク領域を示すポインタを格納する。ここで、中間結果とは、クエリの結果を生成するために必要な取得済みのデータである。実行状態８２ｃには、対応する処理ステップにおけるタスクの実行状態、例えば、次に実行するタスクの処理の内容を特定する情報（例えば、ページ番号８２０、スロット番号８２１、及び処理ローＩＤ番号８２２）を格納する。ここで、ページ番号８２０には、次のタスクの処理で使用するリーフページのページ番号を格納する。スロット番号８２１には、次のタスクの処理で使用するページにおけるスロット番号を格納する。処理ローＩＤ番号８２２には、次のタスクの処理で使用するスロット内のローのＩＤ番号（処理ローＩＤ番号）を格納する。生成可能数８２ｄには、対応する処理ステップにおいて、さらに生成することのできるタスクの数（タスク生成可能数）を格納する。このタスク生成可能数は、論理的に分岐する処理の数の内で、タスクとして生成されていない処理の数である。例えば、図７に示すＰａｒｔ索引による索引検索でキー値「１３０」を条件としている場合に、ページＰ８においては、キー値「１３０」に対応するエントリとしては、ローＩＤが３個あるので、全体として３つのローＩＤを用いてＰａｒｔ表のレコードを取得する３つのタスクを生成することができる。ここで、一つのローＩＤはコンテキストを生成するタスクで処理するので、生成したコンテキストから残りの２つのタスクを生成することができる。このため、タスク生成可能数は、「２」となる。
　図２０は、実施例１に係るクエリ受付時処理のフローチャートである。
　クエリ受付時処理においては、クライアント通信制御部１４２が、ＡＰ１４８からクエリを受け付けると（ステップＳ１）、受け付けたクエリをクエリ実行プラン生成部１４３に渡し、クエリ実行プラン生成部１４３がクエリ実行プラン生成処理（図２１参照）を実行する（ステップＳ２）。
　クエリ実行プラン生成処理の実行後に、スレッド管理部１４６がスレッドを生成する（ステップＳ３）。ここで、生成するスレッド数は、任意の数であってよく、例えば、プロセッサ１２０のプロセッサコアの数と同じ数であっても良い。ここで、スレッドが動作するプロセッサコアをスレッドごとに特定のプロセッサコアに指定しても良い。すなわち、プロセッサアフィニティを設定するようにしても良い。例えば、プロセッサコアの数と同数のスレッドを生成し、各プロセッサコアでいずれか一つのスレッドが実行されるように設定しても良い。このようにすると、各スレッドによる処理の効率が良い。ここで、スレッドを生成する方法としては、ＯＳが提供するスレッド生成のインタフェース（関数）、具体的には、pthread_create()を利用する方法がある。
　次いで、クエリ実行プラン実行部１５１がクエリの実行を開始するコンテキストを生成し、前記コンテキストを利用して処理を行うタスクを生成し、いずれか一つのスレッドに割り当てる（ステップＳ４）。例えば、スレッド管理部１４６が最初に作成したスレッドにタスクを割り当てる。これにより、以降において、プロセッサ１２０のプロセッサコアがスレッドを実行し、前記スレッドに割り当てられたタスクを前記スレッドが実行する。
　図２１は、実施例１に係るクエリ実行プラン生成処理のフローチャートである。
　クエリ実行プラン生成処理は、図２０に示すクエリ受付時処理のステップＳ２に対応する処理である。クエリ実行プラン生成部１４３は、クライアント通信制御部１４２から渡されたクエリからクエリ実行プランを生成する（ステップＳ５）。例えば、図８に示すクエリを受け付けた場合には、図９に示すクエリ実行プランを生成する。次いで、クエリ実行プラン生成部１４３は、スレッド間共有フラグ設定処理（図２２参照）を実行し（ステップＳ６）、クエリ実行プラン生成処理を終了する。
　図２２は、実施例１に係るスレッド間共有フラグ設定処理のフローチャートである。
　スレッド間共有フラグ設定処理は、図２１に示すクエリ実行プラン生成処理のステップＳ６に対応する処理である。スレッド間共有フラグ設定処理は、クエリ実行プランにおける所定の処理ステップに対して、当該処理ステップに関わるコンテキストをスレッド間共有とすべきことを示すスレッド間共有フラグを設定するための処理である。
　クエリ実行プラン生成部１４３は、木構造となっているクエリ実行プランを辿るために、ポインタを移動させながら処理を行う。クエリ実行プランの最初の処理ステップにポインタを設定する（ステップＳ１１）。次いで、クエリ実行プラン生成部１４３は、クエリ実行プランにポインタが指し示す処理ステップがあるか否かを判定する（ステップＳ１２）。この結果、ポインタが指し示す処理ステップがない場合（ステップＳ１２で「ない」）には、クエリ実行プランの全ての処理ステップを対象に処理をしたことを意味するので、クエリ実行プラン生成部１４３は、スレッド間共有フラグ設定処理を終了する。一方、クエリ実行プランの処理ステップにポインタが指し示す処理ステップがある場合（ステップＳ１２で「ある」）には、クエリ実行プラン生成部１４３は、処理ステップが、処理ブロックの先頭であるか否かを判定する（ステップＳ１３）。
　ここで、処理ブロックとは、クエリ実行プランにおける逐次的に実行しなければならない１つ以上の処理ステップを、並行して実行できる集合に区分した場合における当該集合のことをいう。例えば、図９に示すクエリ実行プランには、１つの処理ブロックが含まれる。ここで、処理ブロックについて、他のクエリ実行プランを用いて説明する。
　図２３は、実施例１に係るクエリ実行プランの他の例を説明する図である。
　図２３に示すクエリ実行プランは、Ｐａｒｔ索引による索引検索を行う処理ステップ＃１と、Ｐａｒｔ表からレコードを取得する処理ステップ＃２と、Ｌｉｎｅｉｔｅｍ表に対してテーブルスキャンを実行する処理ステップ＃３と、処理ステップ＃２及び処理ステップ＃３の結果をハッシュ結合する処理ステップ＃４とを有する。ここで、処理ステップ＃１及び処理ステップ＃２と、処理ステップ＃３とは並行して実行可能な処理である。このクエリ実行プランは、処理ステップ＃１及び処理ステップ＃２が含まれる処理ブロック＃１と、処理ステップ＃３及び処理ステップ＃４が含まれる処理ブロック＃２とを含む。このクエリ実行プランにおいては、処理ステップ＃１と、処理ステップ＃３とが処理ブロックの先頭の処理ステップである。
　なお、このようなクエリ実行プランの他に、例えば、副問合せや、導出表が含まれるクエリに対応するクエリ実行プランにおいても、複数の処理ブロックが含まれる。
　図２２の説明に戻り、ステップＳ１３の結果、処理ステップが処理ブロックの先頭である場合（ステップＳ１３で「はい」）には、クエリ実行プラン生成部１４３は、当該処理ステップに対して、スレッド間共有フラグを設定する（ステップＳ１４）。例えば、図９に示すクエリ実行プランでは、処理ステップ＃１にスレッド間共有フラグを設定する。図２３に示すクエリ実行プランでは、処理ステップ＃１と処理ステップ＃３にスレッド間共有フラグを設定する。そして、処理をステップＳ１５に進める。ここで、処理ステップが処理ブロックの先頭である場合においてコンテキストを複数のスレッドで共有すべきとするのは、処理ブロックの早い段階において、起点となるタスクを複数のスレッドに分散させるためである。
　一方、ステップＳ１３の結果、処理ステップが処理ブロックの先頭でない場合（ステップＳ１３で「いいえ」）には、クエリ実行プラン生成部１４３は、処理をステップＳ１５に進める。
　ステップＳ１５では、クエリ実行プラン生成部１４３が次の処理ステップにポインタを移動させ、処理をステップＳ１２に進む。
　なお、図２２に示すスレッド間共有フラグ設定処理においては、処理ブロックの先頭の処理ステップについて、スレッド間共有フラグを設定するようにしていたが、例えば、処理ブロックにおける後続の処理ステップの数が所定数以上ある処理ステップについて、スレッド間共有フラグを設定するようにしても良い。
　図２４は、実施例１に係る結果送信処理のフローチャートである。
　結果送信処理は、クライアント通信制御部１４２がクエリを受け付けた後に、クライアント通信制御部１４２により開始される。クライアント通信制御部１４２は、クエリ実行部１４４における受け付けたクエリの結果の有無を確認する（ステップＳ２１）。
　この結果、クエリの結果がある場合（ステップＳ２１で「有」）には、クライアント通信制御部１４２は、クエリ実行部１４４からクエリの結果を取得し（ステップＳ２２）、クエリの発行元であるＡＰ１４８に対してクエリの結果を送信する（ステップＳ２６）。
　一方、クエリの結果がない場合（ステップＳ２１で「無」）には、クライアント通信制御部１４２は、クエリ実行部１４４のクエリ終了フラグがクエリの終了を示す「終了」であるか、クエリが終了していないことを示す「未終了」であるかを判定する（ステップＳ２３）。この結果、クエリ終了フラグが「終了」である場合（ステップＳ２３で「終了」）には、結果にＮＯＲＯＷ（該当レコードなし）を設定し（ステップＳ２４）、クエリの発行元であるＡＰ１４８に対してクエリの結果を送信する（ステップＳ２６）。
　一方、クエリ実行部１４４のクエリ終了フラグがクエリの未終了を示す「未終了」である場合（ステップＳ２３で「未終了」）には、クライアント通信制御部１４２は、クエリ実行部１４４が結果を生成するのを所定時間待って（ステップＳ２５）、処理をステップＳ２１に進める。
　図２５は、実施例１に係るスレッド実行処理のフローチャートである。
　スレッド実行処理は、プロセッサ１２０のプロセッサコアが、図２０のステップＳ３において生成されたスレッドを実行することにより実現される。なお、複数のスレッドが存在する場合には、別のプロセッサコアが別のスレッドに対するスレッド実行処理を並行して行うことができる。
　プロセッサコアは、対応するスレッドにおいて実行するタスクを選択する（ステップＳ３１）。具体的には、プロセッサコアは、実行タスク管理部１４５が管理するタスク管理情報の対応するスレッドの実行可能リストに含まれるタスクを選択する。
　次いで、プロセッサコアは、実行するタスクの有無を判定し（ステップＳ３２）、実行するタスクがない場合（ステップＳ３２で「無」）には、処理をステップＳ３４に進める一方、実行するタスクがある場合（ステップＳ３２で「有」）には、タスクの開始又はタスクの再開を行う（ステップＳ３３）。具体的には次の処理を行う。プロセッサコアは、実行可能リストに含まれるタスクの一つを選ぶ。プロセッサコアは、選んだタスクのタスク実行状態情報を確認し、タスクの開始またはタスクの再開を行う。タスク実行状態情報の処理ステップが設定していない場合はタスクの処理を開始する。具体的には、タスク実行処理（図２６参照）を実行する。タスク実行状態情報の処理ステップが設定してある場合はタスクの処理を再開する。具体的には、タスクの中断した処理から実行を再開する。本実施例では、図２９のステップＳ６６からの処理から再開する。なお、タスクの実行が終了した後、又はタスクの実行が待ち状態となった後、プロセッサコアは、処理をステップＳ３１に進める。
　ステップＳ３４では、プロセッサコアは、他のスレッドの有無を確認し（ステップＳ３４）、他のスレッドがない場合（ステップＳ３４で「無」）には、クエリ実行部１４４のクエリ終了フラグに終了を設定し（ステップＳ３５）、スレッド実行処理を終了する。これにより、当該スレッドが消滅することとなる。一方、他のスレッドがある場合（ステップＳ３４で「有」）には、プロセッサコアは、スレッド実行処理を終了する。これにより、当該スレッドが消滅することとなる。
　図２６は、実施例１に係るタスク実行処理のフローチャートである。
　タスク実行処理は、図２５のステップＳ３３において、タスクの処理を開始する場合における処理に対応する。このタスク実行処理は、プロセッサコアがスレッドにおけるタスクを実行することにより実現される。
　プロセッサコアは、コンテキスト検索処理（図２７参照）を実行し（ステップＳ３６）、コンテキスト検索処理により検索されたコンテキストの有無を確認する（ステップＳ３７）。この結果、コンテキストがない場合（ステップＳ３７で「なし」）には、実行すべきＤＢへのオペレーションがないことを意味するので、タスク実行処理を終了する。
　一方、コンテキストがある場合（ステップＳ３７で「あり」）には、プロセッサコアは、当該タスクのタスク実行状態情報７３（図１１参照）を設定する（ステップＳ３８）。具体的には、プロセッサコアは、検索されたコンテキスト８２の開始ステップ８２ａの値を、タスク実行状態情報７３の処理ステップ７３ｂにコピーする。コンテキストの中間結果８２ｂのポインタが示すワーク領域のデータを、タスク実行状態情報７３のワーク領域７３ａのポインタが示すワーク領域にコピーする。さらに、プロセッサコアは、コンテキスト８２の実行状態８２ｃの値を、タスク実行状態情報７３の処理ステップ実行状態７３ｃにコピーする。例えば、図１９に示すコンテキスト８２である場合には、タスク実行状態情報７３の処理ステップ実行状態７３ｃには、ページ番号として、コンテキスト８２のページ番号８２０の値「８」が格納され、スロット番号として、コンテキスト８２のスロット番号８２１の値「２」が格納され、処理ローＩＤ番号として、コンテキスト８２の処理ローＩＤ番号８２２の値「２」が格納される。この後、プロセッサコアは、コンテキスト８２の実行状態８２ｃを次のタスクにおける処理内容に対応するように更新する。例えば、図１９に示すコンテキスト８２においては、処理ローＩＤ番号８２２の値を１つ進めて「３」とする。
　このように設定された図１９に示すタスク実行状態情報７３によると、当該タスクの処理で、ページ番号「８」のページ（図７のページＰ８）のスロット番号「２」の処理ローＩＤ番号「２」のローＩＤを参照していることを意味している。この結果、このタスクは、以降の処理において、該当するローＩＤが示すページ「Ｐ１２０」のスロット番号「１」に格納されているレコード（ｉｄ１３２を持つレコード）を参照することから処理を開始することとなる。
　ステップＳ３８の後に、プロセッサコアは、クエリ実行プラン実行処理（図２８参照）を実行する。タスクの処理が終了した場合にステップ３９が終了し、処理をステップＳ３６に進める。
　図２７は、実施例１に係るコンテキスト検索処理のフローチャートである。
　コンテキスト検索処理は、図２６のステップＳ３６に対応する処理である。プロセッサコアは、実行しているスレッド（自スレッド）向けのスレッド向け検索テーブル（８３、８４、又は８５）のポインタを用いて、コンテキストを探す（ステップＳ４１）。本実施例では、プロセッサコアは、最後の処理ステップから最初の処理ステップの順にコンテキストを探す。次いで、プロセッサコアは、探索できたコンテキストの有無を確認する（ステップＳ４２）。この結果、コンテキストが見つかった場合（ステップＳ４２で「有」）には、コンテキスト検索処理を終了する。一方、コンテキストがない場合（ステップＳ４２で「無」）には、利用可能なコンテキストの数がスレッド間で偏っている可能性があることを意味しているので、自スレッド以外のスレッド（他スレッド）向けのスレッド向け検索テーブルのポインタを用いて、コンテキストを探す（ステップＳ４３）。本実施例では、他スレッド向けのスレッド向け検索テーブルからコンテキストを取得する場合には、プロセッサコアは、最初の処理ステップから最後の処理ステップの順にコンテキストを探す。ここで、最初の処理ステップからコンテキストを探すのは、最初の処理ステップに近いものほど、生成するタスク数が多くなる可能性が高いので、早い段階で各スレッドに負荷を分散することができるためである。ステップＳ４３の後、プロセッサコアは、コンテキスト検索処理を終了する。
　例えば、スレッド＃１でコンテキスト検索処理を実行している場合は、スレッド＃１はスレッド＃１向け検索テーブルでコンテキストを探す。スレッド＃１は、スレッド＃１向け検索テーブルでは処理ステップ＃４から処理ステップ＃１の順に探す。図１６の状態では、スレッド＃１はコンテキスト＃２へのポインタを見つけ、コンテキスト＃２を利用する。コンテキスト＃２がなくなった場合、コンテキスト＃１へのポインタを見つけ、コンテキスト＃１を利用する。さらに、コンテキスト＃１がなくなった場合、スレッド＃１向け検索テーブルには利用可能なコンテキストがない状態となり、スレッド＃１は自スレッド以外のスレッド向けの検索テーブルでコンテキストを探す。この場合、処理ステップ＃１から処理ステップ＃４の順に探す。スレッド＃１は、スレッド＃２向け検索テーブルの処理ステップ＃１、スレッド＃３向け検索テーブルの処理ステップ＃１、スレッド＃２向け検索テーブルの処理ステップ＃２、スレッド＃３向け検索テーブルの処理ステップ＃２、スレッド＃２向け検索テーブルの処理ステップ＃３、スレッド＃３向け検索テーブルの処理ステップ＃３、スレッド＃２向け検索テーブルの処理ステップ＃４、スレッド＃３向け検索テーブルの処理ステップ＃４の順に探す。図１７と図１８でコンテキスト＃１へのポインタがなくなっている場合は、スレッド＃１はスレッド＃２向け検索テーブルでコンテキスト＃３へのポインタを見つけ、コンテキスト＃３を利用する。
　上記コンテキスト検索処理においては、コンテキストがない場合、すなわち、コンテキストが０の場合、他スレッド向けのスレッド向け検索テーブルを参照して、コンテキストを探すようにしていたが、例えば、コンテキストが所定数以下である場合に、他スレッド向けのスレッド向け検索テーブルを参照して、コンテキストを探すようにしてもよい。
　また、上記コンテキスト検索処理のステップＳ４３によると、各スレッド間の利用可能なコンテキストの数に基づいて、スレッド間の負荷の偏りを低減することができるが、この処理以外に、後述する変形例（図３４参照）に示す負荷分散スレッドにより調整するようにしてもよい。
　図２８は、実施例１に係るクエリ実行プラン実行処理のフローチャートである。
　クエリ実行プラン実行処理は、図２６のステップＳ３９に対応する。このクエリ実行プラン実行処理は、プロセッサコアがスレッドに割当たったタスクを実行することにより実現される。なお、このクエリ実行プラン実行処理を実行する論理的な機能部が、クエリ実行プラン実行部１５１に相当する。
　プロセッサコアは、ＤＢページ取得処理（図２９参照）を実行する（ステップＳ５１）ことにより、ＤＢ２０６におけるページを取得する。次いで、プロセッサコアは、ページにおけるデータについて検索条件と合致するものがあるかの真偽を判定する（ステップＳ５２）。例えば、索引の上位ページであれば、上位ページ内の検索処理であり、リーフページであればリーフページの検索処理である。この結果、ページにおけるデータに、検索条件と合致するデータがない場合（ステップＳ５２で「偽」）には、プロセッサは、クエリ実行プラン実行処理を終了する。
　一方、検索条件に合致するデータがある場合（ステップＳ５２で「真」）には、プロセッサコアは、検索条件に合致するデータが１つであるか、２つ以上であるかを判定する（ステップＳ５３）。この結果、検索条件に合致するデータが１つである場合（ステップＳ５３で「１つ」）には、プロセッサコアは、処理をステップＳ５５に進める。一方、検索条件に合致するデータが２つ以上である場合（ステップｓ５３で「２つ以上」）には、プロセッサコアは、新規タスク追加処理（図３０参照）を実行し（ステップＳ５４）、処理をステップＳ５５に進める。
　ステップＳ５５では、プロセッサコアは、当該タスクによる処理ステップにおけるＤＢのページに対する処理を実行する。ここで、ＤＢのページに対する処理とは、例えば、索引の上位ページであれば検索条件に合致するページ番号を読み出す処理であり、リーフページであれば検索条件に合致するローＩＤを読み出す処理であり、表のページであればレコードのカラムを読み出す処理である。
　次いで、プロセッサコアは、次のＤＢのページと、当該ＤＢページに対する処理を決定し（ステップＳ５６）、ステップＳ５７に処理を進める。
　ステップＳ５７では、プロセッサコアは、取得しているＤＢページを開放する。次いで、ステップＳ５８では、プロセッサコアは、次の処理があるか否かを判定する。具体的には、現在行っている処理ステップが完了しており、当該処理ステップを含む処理ブロックにおいて次の処理ステップがない場合に「無」と判定する。この結果、次の処理がある場合（ステップＳ５８で「有」）には、プロセッサコアは、処理をステップＳ５１に進める一方、次の処理がない場合（ステップＳ５８で「無」）には、処理結果をクエリ実行部１４４に渡し（ステップＳ５９）、クエリ実行プラン実行処理を終了する。
　ここで、次のＤＢページと、当該ＤＢページに対する処理の決定について、図４～図７に示すＤＢ２０６に対して、ｃ１＝１３０を検索条件として、Ｐａｒｔ索引を索引検索する場合を例に説明する。
　最初に索引検索を開始している場合においては、プロセッサコアは、索引のルートページ（ページ番号「Ｐ１」のページ）を次のＤＢページと決定し、当該ページに対して「１３０」というキーを探す上位ページ内の検索処理をＤＢページに対する処理として決定し、処理を開始する。ステップＳ５１で、プロセッサコアはページＰ１を読み込み、ステップＳ５２で当該ページＰ１の中でｃ１「１３０」を含むエントリを探す。ｃ１「２００」を含むエントリを１つ見つけるので、ステップＳ５５とステップ５６で、次の処理としてページＰ３に対して上位ページ内の検索処理をＤＢページに対する処理と決定する。また、ステップ５１からステップＳ５５で、ページＰ３に対する処理を行う。プロセッサコアは、ページＰ３を読み込み、当該ページＰ３でｃ１「１３０」を含むエントリを探し、ｃ１「１３０」を含むエントリにおいてページＰ８へのポインタを見つける。この結果、ページＰ８を次のＤＢページと決定し、当該ページＰ８に対してリーフページ内の検索処理をＤＢページに対する処理と決定する。
　プロセッサコアは、ステップ５１からステップＳ５３で、ページＰ８を読み込み、当該ページＰ８でｃ１「１３０」を含むエントリを探し、Ｐａｒｔ表のページ「Ｐ１００」と、スロット番号「２」を見つける。ここで条件に合致するデータが３つあるので、当該タスクで処理するデータ以外の２つのデータの処理を行うために、新規タスク追加処理（ステップ５４）を行う。本実施例では、当該タスクで処理するデータを最初のデータとし、ステップ５６でＰａｒｔ表のページＰ１００を次のＤＢページと決定し、当該ページＰ１００に対してスロット番号２にあるレコードを取得する処理をＤＢページに対する処理と決定する。
　図２９は、実施例１に係るＤＢページ取得処理のフローチャートである。
　ＤＢページ取得処理は、クエリ実行プラン実行処理（図２８）のステップＳ５１に対応する。このＤＢページ取得処理は、プロセッサコアがスレッドに割当たったタスクを実行することにより実現される。
　プロセッサコアは、ＤＢバッファ管理部１４７において、取得対象のＤＢページに対応するバッファページ（ＤＢバッファページ）を検索し（ステップＳ６１）、対応するＤＢバッファページの有無を確認する（ステップＳ６２）。
　この結果、対応するＤＢバッファページがある場合（ステップＳ６２で「有」）には、プロセッサコアは、ＤＢ２０６からの当該ページの読込みが完了しているか否かを判定し（ステップＳ６３）、読み込みが完了している場合（ステップＳ６３で「完了」）には、ＤＢページ取得処理を終了する一方、読み込みが完了していない場合（ステップＳ６３で「未完」）には、ステップＳ６６に処理を進める。
　一方、対応するＤＢバッファページがない場合（ステップＳ６２で「無」）には、プロセッサコアは、ＤＢバッファ管理部１４７から空きＤＢバッファページを取得し（ステップＳ６４）、ＤＢ２０６に対して対応するページを空きＤＢバッファページに読込むためのＤＢページ読込み要求を発行し（ステップＳ６５）、処理をステップＳ６６に進める。
　ステップＳ６６では、プロセッサコアは、ページの読込みが完了するのを待つ。ここで、プロセッサコアは、ページの読込みが完了するまで待つ方式、すなわち、同期Ｉ／Ｏを採用せずに、ページの読込みが完了していなくて他の処理を実行する方式、すなわち、非同期Ｉ／Ｏを採用しても良い。例えば、プロセッサコアは、実行中のタスクの処理を中断して待ち状態とし、タスク実行状態情報を待ちリストにつけかえる。そして、別のスレッド（又は、別タスク）により対応するページの読込みの完了を確認する。そして、当該別のスレッド（別のスレッドを実行するプロセッサコア）がページの読込みの完了を確認した場合には、当該タスクのタスク実行状態情報を実行可能リストにつけかえ、当該タスクの処理を再開させるようにしてもよい。このように、非同期Ｉ／Ｏを採用すると、プロセッサコアは、ページの読込み完了を待たずに、他のタスクの実行を行うことができるようになり、ＤＢＭＳ１４１における処理効率を向上することができる。なお、読み込みが完了した場合には、プロセッサコアは、ＤＢページ取得処理を終了する。
　図３０は、実施例１に係る新規タスク追加処理のフローチャートである。
　新規タスク追加処理は、クエリ実行プラン実行処理（図２８）のステップＳ５４に対応する。この新規タスク追加処理は、ステップＳ５３で条件に合致するデータが２以上ある場合に、合致するデータ中の１つのデータ（例えば、最初のデータ）以外のデータを対象にして実行される。
　プロセッサコアは、処理対象のデータに基づいて、コンテキスト８２を作成する（ステップＳ７１）。次いで、プロセッサコアは、作成したコンテキスト８２をスレッド間で共有するか否かを判定するためのコンテキスト共有判定処理（図３１参照）を実行する（ステップＳ７２）。次いで、プロセッサコアは、作成したコンテキスト８２をコンテキスト管理情報８０に登録するコンテキスト登録処理（図３２参照）を実行する（ステップＳ７３）。
　次いで、プロセッサコアは、新たなタスクを生成することが可能であるか否かを判定する（ステップＳ７４）。新たなタスクを生成することが可能であるか否かは、例えば、ＤＢＭＳ１４１において生成されているタスクの数が、生成可能なタスクの数の上限値に達しているか否かを判定することにより判定できる。
　この結果、タスクを生成可能である場合（ステップＳ７４で「可」）には、プロセッサコアは、新たなタスクを生成するためのタスク生成処理（図３３参照）を実行し（ステップＳ７５）、新規タスク追加処理を終了する。一方、タスクを生成可能でない場合（ステップＳ７４で「否」）には、タスクを生成することなく新規タスク追加処理を終了する。
　図３１は、実施例１に係るコンテキスト共有判定処理のフローチャートである。
　コンテキスト共有判定処理は、新規タスク追加処理（図３０）のステップＳ７２に対応する。このコンテキスト共有判定処理は、プロセッサコアがスレッドに割当たったタスクを実行することにより実現される。
　プロセッサコアは、生成したコンテキストに関する処理ステップのスレッド間共有フラグを参照する（ステップＳ８１）。その結果、処理ステップにスレッド間共有フラグが設定されている場合（ステップＳ８１で「フラグ設定あり」）には、プロセッサコアは、当該コンテキストを複数のスレッドから利用可能とするスレッド間共有と判断し（ステップＳ８２）、コンテキスト共有判定処理を終了する。一方、処理ステップにスレッド間共有フラグが設定されていない場合（ステップＳ８１で「フラグ設定なし」）には、プロセッサコアは、当該コンテキストを一つのスレッドにより利用可能とするスレッド間非共有と判断し（ステップＳ８３）、コンテキスト共有判定処理を終了する。
　なお、コンテキスト共有判定処理は、スレッド間共有フラグに基づいて、生成するコンテキストをスレッド間共有するかしないかを判定していたが、これに限られない。例えば、プロセッサコアが、ＤＢＭＳ１４１の実行状態に基づいて、生成するコンテキストをスレッド間共有するかしないかを判定するようにしてもよい。
　例えば、ＤＢＭＳ１４１の実行状態として、ＤＢＭＳ１４１の現存のタスク数を採用する。プロセッサコアは、現存のタスク数が所定数以下である場合には、生成するコンテキストをスレッド間共有と判定し、現存のタスク数が所定数以下でない場合には、生成するコンテキストをスレッド間非共有と判定しても良い。
　また、ＤＢＭＳの実行状態として、コンテキストに含まれる中間結果８２ｂを採用し、プロセッサコアは、前記コンテキストに含まれる中間結果８２ｂのデータ量が所定量以下である場合には、生成するコンテキストをスレッド間共有すると判定し、前記コンテキストに含まれる中間結果８２ｂのデータ量が所定量以下でない場合には、生成するコンテキストをスレッド間非共有と判定しても良い。
　図３２は、実施例１に係るコンテキスト登録処理のフローチャートである。
　コンテキスト登録処理は、新規タスク追加処理（図３０）のステップＳ７３に対応する。このコンテキスト登録処理は、プロセッサコアがスレッドに割当たったタスクを実行することにより実現される。
　プロセッサコアは、作成されたコンテキストをコンテキスト管理情報８０の管理リストに登録する（ステップＳ９１）。具体的には、プロセッサコアは、管理リストに接続された最後のコンテキストの後ろに作成されたコンテキストを接続する。
　次いで、プロセッサコアは、コンテキスト共有判定処理（図３１参照）の結果を確認する（ステップＳ９２）。この結果がスレッド間共有である場合（ステップＳ９２で「共有」）には、複数のスレッド向け検索テーブルに、作成されたコンテキストへのポインタを登録し、コンテキスト登録処理を終了する。本実施例では、ＤＢアクセス処理を実行する全てのスレッド向け検索テーブルにコンテキストへのポインタを登録する（ステップＳ９３）。この他に、特定のスレッド向け検索テーブルにコンテキストへのポインタを登録してもよい。
　特定のスレッド向け検索テーブルにコンテキストへのポインタを登録するケースを説明する。例えば、計算機のハードウェア構成情報に基づき、登録するスレッド向け検索テーブルを特定する。ハードウェア構成情報には、プロセッサ構成やキャッシュ構成やメモリ構成が考えられる。例えば、一つのプロセッサにある複数のプロセッサコアが実行している複数のスレッドにおいて、利用可能なコンテキストのタスク生成可能数の総和が最も少ない前記複数のスレッドに対応するスレッド向けのスレッド向け管理テーブルに登録する。本実施例において、スレッド＃２を実行しているプロセッサコアとスレッド＃３を実行しているプロセッサコアが同じプロセッサであり、前記プロセッサはスレッド＃１を実行しているプロセッサと異なり、コンテキスト＃１へのポインタがスレッド＃２のスレッド向け検索テーブルとスレッド＃３のスレッド向け検索テーブルに登録されている状況を考える。処理ステップ＃１に対する新しいコンテキスト＃４が生成された場合には、コンテキストが少ないプロセッサのプロセッサコアが実行しているスレッドスレッド向け検索テーブルに登録する。このケースでは、スレッド＃１のスレッド向け検索テーブルに登録する。この例では、１つのスレッド向け検索テーブルに登録したが、スレッド＃１を実行するプロセッサコアのプロセッサが他にＤＢアクセス処理を実行するスレッドを実行している場合は、複数のスレッド向け検索テーブルに登録することになる。
　このほか、コンテキストを生成したプロセッサコアを含むプロセッサに対応する複数のスレッドに対応するスレッド向けのスレッド向け管理テーブルに登録してもよい。また、一つのプロセッサにある複数のプロセッサコアが実行している複数のスレッドにおいて、利用可能なコンテキストの総数が少ない前記複数のスレッドに対応するスレッド向けのスレッド向け管理テーブルに登録してもよい。また、プロセッサ内でキャッシュを共有しているプロセッサコアが実行している複数のスレッドのスレッド向け管理テーブルに登録してもよい。また、コンテキストを記録するメモリに近いプロセッサコアが実行している複数のスレッドのスレッド向け管理テーブルに登録してもよい。また、コンテキストを利用する際に参照するＤＢバッファページが記録されているメモリに近いプロセッサコアが実行している複数のスレッドのスレッド向け管理テーブルに登録してもよい。
　一方、この結果がスレッド間非共有である場合（ステップＳ９２で「非共有」）には、プロセッサコアは、１つのスレッド向け検索テーブルにポインタを登録し、コンテキスト登録処理を終了する。本実施例では、自身が実行しているスレッド（自スレッド）向けのスレッド向け検索テーブルに、作成されたコンテキストへのポインタを登録し（ステップＳ９４）、コンテキスト登録処理を終了する。このほかに、利用可能なコンテキストが最も少ないスレッド向け検索テーブルに登録してもよく、また、利用可能なコンテキストのタスク生成可能数の総和が最も少ないスレッド向け検索テーブルに登録してもよい。
　図３３は、実施例１に係るタスク生成処理のフローチャートである。
　タスク生成処理は、新規タスク追加処理（図３０）のステップＳ７５に対応する。このタスク生成処理は、プロセッサコアがスレッドに割当たったタスクを実行することにより実現される。
　次いで、プロセッサコアは、コンテキスト共有判定処理（図３１参照）の結果を確認する（ステップＳ１０１）。この結果がスレッド間共有である場合（ステップＳ１０１で「スレッド間共有」）には、プロセッサコアは、タスクを生成し、コンテキストのポインタを登録したスレッド向け検索テーブルに対応する２つ以上のスレッドにタスクを割り当てる（ステップＳ１０２）。生成するタスクの合計はコンテキストの生成可能数を上限とする。各スレッドに割り当てるタスクの数は、コンテキストの生成可能数をスレッド数で割った数とする。その後、プロセッサコアは、タスク生成処理を終了する。
　一方、この結果がスレッド間非共有である場合（ステップＳ１０１で「スレッド間非共有」）には、プロセッサコアは、タスクを生成し、コンテキストのポインタを登録したスレッド向け検索テーブルに対応する１つのスレッドにタスクを割り当てる（ステップＳ１０３）。生成するタスクの数はコンテキストの生成可能数を上限とする。ここで、タスクを割り当てるスレッドとしては、プロセッサコアが実行している自スレッドであっても良く、自スレッド以外のスレッドであっても良い。ステップＳ１０３の後、プロセッサコアは、タスク生成処理を終了する。
　次に、本実施例の変形例について説明する。
　上記実施例において、クエリ実行部１４４が以下に示す負荷分散処理を実行するようにしてもよい。
　図３４は、変形例に係る負荷分散処理のフローチャートである。
　負荷分散処理は、クエリ実行部１４４により実行されるが、具体的には、プロセッサコアが、ＤＢ処理を行うためのスレッド以外のスレッド（負荷分散スレッド）を実行することにより実現することができる。この負荷分散処理は、クライアント通信制御部１４２がクエリを受け付けた後に開始される。
　プロセッサコアは、クエリ処理が終了したか否かを判定し（ステップＳ１１１）、クエリ処理が終了した場合（ステップＳ１１１で「終了」）には、負荷分散処理を終了する。
　一方、クエリ処理が終了していない場合（ステップＳ１１１で「未終了」）には、プロセッサコアは、各スレッド向け検索テーブルから利用可能なコンテキストにおけるタスク生成可能数の総和を計算する（ステップＳ１１２）。
　次いで、プロセッサコアは、各スレッドが生成可能なタスク生成可能数の総和に偏りがあるか否かを判定する（ステップＳ１１３）。ここで、プロセッサコアは、例えば、タスク生成可能数が所定数（例えば、０）以下である場合に偏りがあると判定しても良い。
　この結果、各スレッドが生成可能なタスク生成可能数の総和に偏りがない場合（ステップＳ１１３で「無」）には、処理をステップＳ１１５に進める。
　一方、各スレッドで生成可能なタスク生成可能数の総和に偏りがある場合（ステップＳ１１３で「有」）には、プロセッサコアは、コンテキストの位置を変更、すなわち、コンテキストを参照するポインタが格納されるスレッド向け検索テーブルを別のスレッド向け検索テーブルに変更することにより、各スレッドで生成可能なタスク生成可能数の総和の偏りを減らすようにする。具体的には、タスク生成可能数の総和が最大のスレッド向けのスレッド向け検索テーブルにより利用可能なコンテキストのポインタを、タスク生成可能数の総和が少ないスレッド向けのスレッド向け検索テーブルに登録する。この後、プロセッサコアは、処理をステップＳ１１５に進める。
　ステップＳ１１５では、プロセッサコアは、当該負荷分散処理を所定時間スリープし、処理をステップＳ１１１に進める。
　この負荷分散処理により、各スレッドに対する負荷を適切に分散させることができる。
　なお、上記負荷分散処理では、各スレッドで生成可能なタスク生成可能数の総和の偏りに基づいて、コンテキストを利用するスレッドの変更を行うようにしていたが、タスク生成可能数の総和の偏りと異なる、スレッドに関わる実行状態に基づいて、スレッドの負荷を把握し、コンテキストを利用するスレッドを変更するようにしてもよい。例えば、各スレッドにおけるコスト計算を行い、前記コストに基づいて、コンテキストを利用するスレッドを変更するようにしても良い。コスト計算の例として次のような値が考えられる。コンテキスのコストを当該コンテキストから処理する処理ステップ数と生成可能数の積とし、当該スレッドから利用可能なコンテキストのコストの総和を当該スレッドのコストとする。
　なお、上記負荷分散処理は、ＤＢ処理を行うためのスレッドが実行してもよい。例えば、スレッドの終了時（ステップＳ３２の「無」と判定した場合）や、タスクの終了時（ステップＳ３７で「なし」と判定した場合）に実行してもよい。この場合、負荷分散処理は、ステップＳ１１２からステップＳ１１４までを実行する。
　以下、実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。
　図３５は、実施例２に係る計算機システムの構成を示す。
　アプリケーションサーバ（以下、ＡＰサーバ）３５０２は、ＤＢＭＳ１４１が動作する計算機（以下、ＤＢサーバ）１００に、通信ネットワーク３５１２を介して通信できるように接続されている。また、ＤＢサーバ１００は、外部ストレージ装置２００に、通信ネットワーク３００を介して通信できるように接続されている。ユーザ端末（クライアント端末）３５０１は、ＡＰサーバ３５０２に、通信ネットアーク３５１１を介して通信できるように接続されている。ＤＢサーバ１００は、ＤＢ２０６を管理するＤＢＭＳ１４１を実行する。外部ストレージ装置２００は、ＤＢ２０６を格納する。ＡＰサーバ３５０２は、ＤＢサーバ１００で実行されるＤＢＭＳ１４１に対してクエリを発行するＡＰを実行する。ユーザ端末３５０１は、ＡＰサーバ３５０２で実行されるＡＰに要求を出す。なお、ユーザ端末３５０１、又は、ＡＰサーバ３５０２は、複数存在しても良い。
　ＡＰサーバ管理端末３５０３は、通信ネットワーク３５１４を介してＡＰサーバ３５０２に接続されている。ＤＢサーバ管理端末３５０４は、通信ネットワーク３５１５を介してＤＢサーバ１００に接続されている。ストレージ管理端末３５０５は、通信ネットワーク３５１６を介して外部ストレージ装置２００に接続されている。ＡＰサーバ管理端末３５０３は、ＡＰサーバ３５０２を管理する端末である。ＤＢサーバ管理端末３５０４は、ＤＢサーバ１００を管理する端末である。ストレージ管理端末３５０５は、外部ストレージ装置２００を管理する端末である。ＤＢサーバ管理者又はユーザは、ＤＢサーバ管理端末３５０４から、ＤＢＭＳ１４１に関する設定を行っても良い。なお、管理端末３５０３～３５０５のうちの少なくとも二つが共通（一体）であっても良い。また、通信ネットワーク３５１１、３５１２、３５１４、３５１５、３５１６、及び３００のうちの少なくとも二つが共通（一体）であっても良い。
　実施例２では、例えば、下記の通り処理が実行される。
（Ｓ１２１）ユーザ端末３５０１は、ＡＰサーバ３５０２に要求（以下、ユーザ要求）を発行する。
（Ｓ１２２）ＡＰサーバ３５０２は、Ｓ１２１で受信したユーザ要求に従いクエリを生成する。そして、生成したクエリをＤＢサーバ１００に発行する。
（Ｓ１２３）ＤＢサーバ１００は、ＡＰサーバ３５０２からのクエリを受け付け、受け付けたクエリを実行する。ＤＢサーバ１００は、受け付けたクエリの実行において必要なデータ入出力要求（例えばデータ読出し要求）を外部ストレージ装置２００に発行する。ＤＢサーバ１００は、一つのクエリの実行において、複数のデータ入出力要求を並行して発行することがある。そのため、ＤＢサーバ１００は、一つのクエリの実行において、Ｓ１２３の要求を複数回並行して行うことがある。
（Ｓ１２４）外部ストレージ装置２００は、Ｓ１２３で発行されたデータ入出力要求について、ＤＢサーバ１００に応答する。外部ストレージ装置２００は、Ｓ１２４の応答を複数回並行して行うことがある。
（Ｓ１２５）ＤＢサーバ１００は、クエリの実行結果を生成し、ＡＰサーバ３５０２に送信する。
（Ｓ１２６）ＡＰサーバ３５０２は、クエリの実行結果を受信する。そして、該実行結果に従う、Ｓ１２１で受信したユーザ要求に対する回答を、ユーザ端末３５０１に送信する。
　なお、ＡＰサーバ３５０２に発行されるユーザ要求、又は、ＤＢサーバへ発行されるクエリは、同時に複数あっても良い。
　以上、実施例に基づいて説明したが、本発明は上述した実施例に限られず、他の様々な態様に適用可能である。
１４１…データベース管理システム（ＤＢＭＳ）

Claims (16)

  1. 　プロセッサコアを有する計算機により実現されデータベースを管理するデータベース管理システムであって、
    　前記データベースへのクエリを受け付けるクエリ受付部と、
    　前記受け付けたクエリを実行するために必要な処理ステップと前記処理ステップの実行手順とを表す情報を含んだクエリ実行プランを生成するクエリ実行プラン生成部と、
    　前記生成したクエリ実行プランに基づいて前記受け付けたクエリを実行し、前記受け付けたクエリの実行において、処理ステップを実行するためのタスクを動的に生成し、前記動的に生成されたタスクを実行するクエリ実行部と
    を有し、
    　前記クエリ実行部は、前記受け付けたクエリの実行において、プロセッサコアにより実行される複数のスレッドにおいてタスクを実行し、
    　前記プロセッサコアにより実行される一つのスレッドにおいて複数のタスクを実行し、
    　タスクを新たに生成する場合に、コンテキストを生成して、前記生成したコンテキストに基づいて前記生成されたタスクを実行し、
    　前記コンテキストは、前記新たに生成するタスクにおいて実行を開始する処理ステップが、前記クエリ実行プランが表す１以上の処理ステップのうちのいずれであるかを示す第１の情報と、前記第１の情報が示す処理ステップに要するデータのアクセス先に関する第２の情報と、前記新たに生成するタスクにより結果を生成するために必要なデータに関する第３の情報とを含む情報である
    データベース管理システム。
  2. 　前記クエリ実行プラン生成部は、各前記処理ステップに関わるコンテキストを、複数のスレッド間で共有するか、複数のスレッド間で共有しないかを判定し、
    　前記クエリ実行部は、前記判定結果に基づいて前記コンテキストを管理する
    請求項１に記載のデータベース管理システム。
  3. 　前記クエリ実行プラン生成部は、前記処理ステップの前記クエリ実行プランにおける他の処理ステップとの先行又は後続関係に基づいて、前記処理ステップに関わるコンテキストを複数のスレッド間で共有するか、又は共有しないかを判定する
    請求項２に記載のデータベース管理システム。
  4. 　前記プロセッサコアにより実行されるスレッドに割当たったタスクにおいて、前記データベースに対して非同期Ｉ／Ｏによるデータ読み込み要求を発行し、
    　前記スレッドを実行するプロセッサコアは、前記タスクにおけるデータ読み込み要求発行後に、前記データ読み込み要求に対応するデータの読み込みが完了する前に、実行可能な他のタスクの実行を行い、
    　前記スレッドを実行するプロセッサコアは、前記タスクにおける前記データ読み込み要求に対応するデータの読み込みが完了した後に、前記タスクの実行を再開する
    請求項２に記載のデータベース管理システム。
  5. 　前記処理ステップを実行するためのタスクを割り当て可能な前記スレッドは、前記プロセッサコアと同数であり、各スレッドを実行するプロセッサコアは、それぞれ別のプロセッサコアに設定されている
    請求項２に記載のデータベース管理システム。
  6. 　前記クエリ実行プラン生成部は、前記クエリ実行プランに、並行して実行可能な処理ステップを含む複数の処理ブロックが含まれる場合に、前記処理ブロックの先頭の処理ステップに関わるコンテキストを、複数のスレッド間で共有すると判定し、前記処理ブロックの他の処理ステップに関わるコンテキストを、スレッド間で共有しないと判定する
    請求項２に記載のデータベース管理システム。
  7. 　前記クエリ実行プラン生成部は、前記クエリ実行プランに、並行して実行可能な処理ステップを含む複数の処理ブロックが含まれる場合に、前記処理ブロックにおける後続の処理ステップの数が所定数以上ある処理ステップに関わるコンテキストを、複数のスレッド間で共有すると判定し、後続の処理ステップの数が所定数未満の処理ステップに関わるコンテキストを、スレッド間で共有しないと判定する
    請求項２に記載のデータベース管理システム。
  8. 　前記クエリ実行部は、一つのスレッドの利用可能なコンテキストの数が所定数を下回った場合に、他のスレッドの利用可能なコンテキストを、前記一つのスレッドに割当たったタスクで利用する
    請求項２に記載のデータベース管理システム。
  9. 　前記クエリ実行部は、前記複数のスレッドに関わる実行状態が所定の状態となった場合に、スレッド間の利用可能なコンテキストの数の差が所定数より小さくなるように、一つのスレッドの利用可能なコンテキストを、他のスレッドの利用可能なコンテキストに変更する
    請求項２に記載のデータベース管理システム。
  10. 　前記複数のスレッドの実行状態が所定の状態とは、前記スレッド間の利用可能なコンテキストの数の差が所定数以上となった状態である
    請求項９に記載のデータベース管理システム。
  11. 　前記クエリ実行部は、データベース管理システムの実行状態に基づいて、コンテキストを複数のスレッドで共有とするか否かを判定し、
    　前記コンテキストを複数のスレッド間で共有すると判定されている場合には、前記コンテキストを複数のスレッド間で共有するようにし、前記コンテキストを複数のスレッド間で共有しないと判定されている場合には、前記コンテキストを一つのスレッドが利用するようにする
    請求項１に記載のデータベース管理システム
  12. 　前記データベース管理システムの実行状態とは、前記データベース管理システムにおいて現存するタスク数であり、
    　前記クエリ実行部は、現存する前記タスク数が所定数以下である場合には、前記コンテキストを複数のスレッドで共有とすると判定し、現存する前記タスク数が所定数以下でない場合には、前記コンテキストを共有しないと判定する
    請求項１１に記載のデータベース管理システム。
  13. 　前記データベース管理システムの実行状態とは、コンテキストに含まれる第３の情報であり、
    　前記クエリ実行部は、前記コンテキストに含まれる第３の情報のデータ量が所定量以下である場合には、前記コンテキストを複数のスレッドで共有とすると判定し、前記コンテキストに含まれる第３の情報のデータ量が所定量以下でない場合には、前記コンテキストを共有しないと判定する
    請求項１２に記載のデータベース管理システム。
  14. 　前記クエリ実行部は、前記コンテキストをいずれか一つのスレッドにより利用可能とし、
    　前記クエリ実行部は、前記スレッド間の利用可能なコンテキストの数の差が所定数以上となった場合に、前記スレッド間の利用可能なコンテキストの数の差が所定数より小さくなるように、一つのスレッドの利用可能なコンテキストを、他のスレッドの利用可能なコンテキストに変更する
    請求項１に記載のデータベース管理システム。
  15. 　記憶資源と、
    　前記記憶資源に接続され１以上のプロセッサコアを有する１以上のプロセッサを含んだ制御デバイスを有し、
    　前記制御デバイスが、
    　前記データベースへのクエリを受け付け、
    　前記受け付けたクエリを実行するために必要な処理ステップと前記処理ステップの実行手順とを表す情報を含んだクエリ実行プランを生成し、
    　前記生成したクエリ実行プランに基づいて前記受け付けたクエリを実行し、前記受け付けたクエリの実行において、処理ステップを実行するためのタスクを動的に生成し、前記動的に生成されたタスクを実行し、
    　前記制御デバイスは、前記受け付けたクエリの実行において、プロセッサコアにより実行される複数のスレッドにおいてタスクを実行し、
    　前記プロセッサコアにより実行される一つのスレッドにおいて複数のタスクを実行し、
    　タスクを新たに生成する場合に、コンテキストを生成して、前記生成したコンテキストに基づいて前記生成されたタスクを実行し、
    　前記コンテキストは、前記新たに生成するタスクにおいて実行を開始する処理ステップが、前記クエリ実行プランが表す１以上の処理ステップのうちのいずれであるかを示す第１の情報と、前記第１の情報が示す処理ステップに要するデータのアクセス先に関する第２の情報と、前記新たに生成するタスクにより結果を生成するために必要なデータに関する第３の情報とを含む情報である
    計算機。
  16. 　データベースを管理するデータベース管理方法であって、
    　（ａ）前記データベースへのクエリを受け付け、
    　（ｂ）前記受け付けたクエリを実行するために必要な複数の１以上の処理ステップと、前記１以上の処理ステップの実行手順とを表す情報を含んだクエリ実行プランを生成し、
    　（ｃ）前記生成したクエリ実行プランに基づいて、処理ステップを実行するためのタスクを動的に生成し、前記動的に生成されたタスクを実行することで、前記受け付けたクエリを実行し、
    　前記（ｃ）では、前記受け付けたクエリの実行において、プロセッサコアにより実行される複数のスレッドにおいてタスクを実行し、
    　前記プロセッサコアにより実行される一つのスレッドにおいて複数のタスクを実行し、
    　タスクを新たに生成する場合に、コンテキストを生成して、前記生成したコンテキストに基づいて前記生成されたタスクを実行し、
    　前記コンテキストは、前記新たに生成するタスクにおいて実行を開始する処理ステップが、前記クエリ実行プランが表す１以上の処理ステップのうちのいずれであるかを示す第１の情報と、前記第１の情報が示す処理ステップに要するデータのアクセス先に関する第２の情報と、前記新たに生成するタスクにより結果を生成するために必要なデータに関する第３の情報とを含む情報である
    データベース管理方法。
PCT/JP2012/061436 2012-04-27 2012-04-27 データベース管理システム、計算機、データベース管理方法 WO2013161076A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
PCT/JP2012/061436 WO2013161076A1 (ja) 2012-04-27 2012-04-27 データベース管理システム、計算機、データベース管理方法
JP2014512271A JP5858307B2 (ja) 2012-04-27 2012-04-27 データベース管理システム、計算機、データベース管理方法
EP12875146.8A EP2843559A4 (en) 2012-04-27 2012-04-27 DATABASE MANAGEMENT SYSTEM, COMPUTERS AND DATABASE MANAGEMENT PROCEDURES
US14/397,076 US10417227B2 (en) 2012-04-27 2012-04-27 Database management system, computer, and database management method
US16/531,256 US11636107B2 (en) 2012-04-27 2019-08-05 Database management system, computer, and database management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/061436 WO2013161076A1 (ja) 2012-04-27 2012-04-27 データベース管理システム、計算機、データベース管理方法

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US14/397,076 A-371-Of-International US10417227B2 (en) 2012-04-27 2012-04-27 Database management system, computer, and database management method
US16/531,256 Continuation US11636107B2 (en) 2012-04-27 2019-08-05 Database management system, computer, and database management method

Publications (1)

Publication Number Publication Date
WO2013161076A1 true WO2013161076A1 (ja) 2013-10-31

Family

ID=49482442

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/061436 WO2013161076A1 (ja) 2012-04-27 2012-04-27 データベース管理システム、計算機、データベース管理方法

Country Status (4)

Country Link
US (2) US10417227B2 (ja)
EP (1) EP2843559A4 (ja)
JP (1) JP5858307B2 (ja)
WO (1) WO2013161076A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017013701A1 (ja) * 2015-07-17 2017-01-26 株式会社日立製作所 計算機システム及びデータベース管理方法

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2510426A (en) * 2013-02-05 2014-08-06 Ibm Workload balancing in a distributed database
JP6081031B2 (ja) * 2014-09-17 2017-02-15 三菱電機株式会社 攻撃観察装置、及び攻撃観察方法
US9727648B2 (en) 2014-12-19 2017-08-08 Quixey, Inc. Time-box constrained searching in a distributed search system
WO2018219440A1 (en) 2017-05-31 2018-12-06 Huawei Technologies Co., Ltd. System and method for dynamic determination of a number of parallel threads for a request
JP7197794B2 (ja) 2019-03-28 2022-12-28 富士通株式会社 情報処理装置および実行制御プログラム
US20220012238A1 (en) * 2020-07-07 2022-01-13 AtScale, Inc. Datacube access connectors

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007034414A (ja) 2005-07-22 2007-02-08 Masaru Kiregawa データベース管理システム及び方法
JP2007065978A (ja) * 2005-08-31 2007-03-15 Hitachi Ltd 計算機システム及びデータベース管理システムプログラム
JP2011159107A (ja) * 2010-02-01 2011-08-18 Nec Corp スレッド数制限装置、スレッド数制限方法およびスレッド数制限プログラム
WO2012026140A1 (ja) * 2010-08-25 2012-03-01 株式会社日立製作所 データベース処理方法、データベース処理システム及びデータベースサーバ

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5742806A (en) * 1994-01-31 1998-04-21 Sun Microsystems, Inc. Apparatus and method for decomposing database queries for database management system including multiprocessor digital data processing system
US5893912A (en) 1997-08-13 1999-04-13 International Business Machines Corporation Thread context manager for relational databases, method and computer program product for implementing thread context management for relational databases
US6205441B1 (en) * 1999-03-31 2001-03-20 Compaq Computer Corporation System and method for reducing compile time in a top down rule based system using rule heuristics based upon the predicted resulting data flow
US7966475B2 (en) * 1999-04-09 2011-06-21 Rambus Inc. Parallel data processing apparatus
US6678672B1 (en) * 2000-05-31 2004-01-13 Ncr Corporation Efficient exception handling during access plan execution in an on-line analytic processing system
US6996556B2 (en) * 2002-08-20 2006-02-07 International Business Machines Corporation Metadata manager for database query optimizer
US7383389B1 (en) * 2004-04-28 2008-06-03 Sybase, Inc. Cache management system providing improved page latching methodology
US8126870B2 (en) 2005-03-28 2012-02-28 Sybase, Inc. System and methodology for parallel query optimization using semantic-based partitioning
US20060294058A1 (en) * 2005-06-28 2006-12-28 Microsoft Corporation System and method for an asynchronous queue in a database management system
US8032522B2 (en) * 2006-08-25 2011-10-04 Microsoft Corporation Optimizing parameterized queries in a relational database management system
US9009187B2 (en) * 2006-12-19 2015-04-14 Ianywhere Solutions, Inc. Assigning tasks to threads requiring limited resources using programmable queues
US20120066683A1 (en) * 2010-09-09 2012-03-15 Srinath Nadig S Balanced thread creation and task allocation
US8336051B2 (en) * 2010-11-04 2012-12-18 Electron Database Corporation Systems and methods for grouped request execution
KR20120055089A (ko) * 2010-11-23 2012-05-31 이화여자대학교 산학협력단 부하분산을 이용한 병렬형 충돌검사 방법과 병렬형 거리계산 방법
US8473484B2 (en) * 2011-06-01 2013-06-25 International Business Machines Corporation Identifying impact of installing a database patch
US8417689B1 (en) * 2011-11-21 2013-04-09 Emc Corporation Programming model for transparent parallelization of combinatorial optimization
US8914353B2 (en) * 2011-12-20 2014-12-16 Sap Se Many-core algorithms for in-memory column store databases
US9703566B2 (en) * 2011-12-29 2017-07-11 Intel Corporation Sharing TLB mappings between contexts
US8683296B2 (en) * 2011-12-30 2014-03-25 Streamscale, Inc. Accelerated erasure coding system and method
JP5858308B2 (ja) * 2012-05-24 2016-02-10 株式会社日立製作所 データベース管理システム、計算機、データベース管理方法
US9146609B2 (en) * 2012-11-20 2015-09-29 International Business Machines Corporation Thread consolidation in processor cores

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007034414A (ja) 2005-07-22 2007-02-08 Masaru Kiregawa データベース管理システム及び方法
JP2007065978A (ja) * 2005-08-31 2007-03-15 Hitachi Ltd 計算機システム及びデータベース管理システムプログラム
JP2011159107A (ja) * 2010-02-01 2011-08-18 Nec Corp スレッド数制限装置、スレッド数制限方法およびスレッド数制限プログラム
WO2012026140A1 (ja) * 2010-08-25 2012-03-01 株式会社日立製作所 データベース処理方法、データベース処理システム及びデータベースサーバ

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HIDEOMI IDEI ET AL.: "QUERY PLAN RIYO SAKIYOMI GIJUTSU NI OKERU TAJU SHORI JIKKOJI NO SEINO MODEL KENTO - PERFORMANCE MODEL OF PREFETCH TECHNOLOGY USING QUERY PLAN ON MULTIPLEX QUERY EXECUTION", THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS DAI 18 KAI DATA KOGAKU WORKSHOP RONBUNSHU, vol. DEWS2007 E2-4, no. E2-4, 1 June 2007 (2007-06-01), XP055171025 *
See also references of EP2843559A4

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017013701A1 (ja) * 2015-07-17 2017-01-26 株式会社日立製作所 計算機システム及びデータベース管理方法
JPWO2017013701A1 (ja) * 2015-07-17 2018-03-22 株式会社日立製作所 計算機システム及びデータベース管理方法
US11321302B2 (en) 2015-07-17 2022-05-03 Hitachi, Ltd. Computer system and database management method

Also Published As

Publication number Publication date
US10417227B2 (en) 2019-09-17
JP5858307B2 (ja) 2016-02-10
US20190354527A1 (en) 2019-11-21
EP2843559A1 (en) 2015-03-04
JPWO2013161076A1 (ja) 2015-12-21
EP2843559A4 (en) 2016-01-13
US11636107B2 (en) 2023-04-25
US20150112967A1 (en) 2015-04-23

Similar Documents

Publication Publication Date Title
JP5858307B2 (ja) データベース管理システム、計算機、データベース管理方法
EP3108374B1 (en) Data management systems and methods
JP4659888B2 (ja) データベース処理システム、計算機及びデータベース処理方法
Richter et al. Towards zero-overhead static and adaptive indexing in Hadoop
JP5950267B2 (ja) データベース管理装置、データベース管理方法及び記憶媒体
US11086841B1 (en) Streams on shared database objects
Wang et al. Fast and concurrent {RDF} queries using {RDMA-assisted}{GPU} graph exploration
US20180075080A1 (en) Computer System and Database Management Method
Tang et al. A data skew oriented reduce placement algorithm based on sampling
JP6168635B2 (ja) データベース管理システム、計算機、データベース管理方法
JP6707797B2 (ja) データベース管理システム及びデータベース管理方法
US7756827B1 (en) Rule-based, event-driven, scalable data collection
JP6108418B2 (ja) データベース管理システム、計算機、データベース管理方法
US20210149903A1 (en) Successive database record filtering on disparate database types
US11561953B2 (en) Cosharding and randomized cosharding
JP2009223572A (ja) 変換装置、サーバシステム、変換方法およびプログラム
JP5978297B2 (ja) 管理システム及び管理方法
Chang et al. Resilient distributed computing platforms for big data analysis using Spark and Hadoop
US20160335321A1 (en) Database management system, computer, and database management method
Spiegelberg et al. Hyperspecialized Compilation for Serverless Data Analytics.
Yu et al. Consistent and Efficient Batch Operations for NoSQL Databases with Hybrid Timestamp
Yuan et al. High Performance RDF Updates with TripleBit+
Shen et al. Efficient Query Algorithm of Coallocation-Parallel-Hash-Join in the Cloud Data Center

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: 12875146

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014512271

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: 2012875146

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 14397076

Country of ref document: US