WO2015118662A1 - 情報処理装置及び方法 - Google Patents

情報処理装置及び方法 Download PDF

Info

Publication number
WO2015118662A1
WO2015118662A1 PCT/JP2014/052918 JP2014052918W WO2015118662A1 WO 2015118662 A1 WO2015118662 A1 WO 2015118662A1 JP 2014052918 W JP2014052918 W JP 2014052918W WO 2015118662 A1 WO2015118662 A1 WO 2015118662A1
Authority
WO
WIPO (PCT)
Prior art keywords
update
data
storage medium
column
request
Prior art date
Application number
PCT/JP2014/052918
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 JP2015561117A priority Critical patent/JP6158361B2/ja
Priority to PCT/JP2014/052918 priority patent/WO2015118662A1/ja
Publication of WO2015118662A1 publication Critical patent/WO2015118662A1/ja
Priority to US15/222,172 priority patent/US10303680B2/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/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • 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/23—Updating

Definitions

  • Embodiments of the present invention generally relate to an information processing apparatus and method.
  • RDB Relational Database
  • KVS Key Value Store
  • a table including desired data is searched from a large number of tables stored in the RDB in accordance with access from a client terminal, and the desired data is retrieved from this table. It needs to be acquired, and it takes time until the client terminal acquires desired data.
  • the in-memory KVS stores a key for obtaining desired data and the desired data in a one-to-one correspondence. Therefore, if the desired data is stored as a cache, the client The terminal can acquire desired data much faster than the data management method using only the RDB. If the desired data is not stored as a cache, the client terminal changes the access target to the RDB and obtains the desired data from the RDB. By registering as an in-memory KVS cache, it is possible to reduce the time from the next time until the client terminal acquires desired data.
  • the time required for the client terminal to acquire desired data is shorter than the data management method using only the RDB. It can be shortened.
  • An object of one embodiment of the present invention is to provide an information processing apparatus and method capable of realizing a suitable data management method using a combination of RDB and in-memory KVS.
  • the information processing apparatus includes a client terminal, a first storage medium that includes a plurality of tables having a plurality of column names and columns corresponding to the column names and identified by table names; Applicable to a data management system, communicably connected to a second storage medium that stores a part of the data stored in each table stored in the first storage medium in association with a key used when reading the data. Is done.
  • the information processing apparatus searches the first storage medium and updates the update request
  • An acquisition unit for acquiring a column name and a column of the target data, a first writing unit for writing data in which the acquired column name and the column are associated with each other in a temporary memory, and the received update request Therefore, upon receiving an update confirmation request for confirming the update from the client terminal after the update, and an update means for updating the column of the data to be updated, the update target stored in the first storage medium And confirming the update to the data including the column of the data to be updated stored in the temporary memory.
  • Update confirmation means for giving update confirmation information to the effect
  • deletion means for deleting data including the column name and column of the data to which the update confirmation information is given from the data group stored in the second storage medium It comprises.
  • FIG. 1 is a block diagram illustrating a schematic configuration example of a data management system to which the information processing apparatus according to the first embodiment is applied.
  • FIG. 2 is a flowchart illustrating an example of a procedure of data update processing executed by the information processing apparatus according to the embodiment.
  • FIG. 3 is a block diagram illustrating a schematic configuration example of a data management system to which the information processing apparatus according to the second embodiment is applied.
  • FIG. 4 is a flowchart illustrating an example of a procedure of data update processing executed by the information processing apparatus according to the embodiment.
  • FIG. 1 is a block diagram illustrating a schematic configuration example of a data management system to which the information processing apparatus according to the first embodiment is applied.
  • the data management system 1 includes an RDB 11, an in-memory KVS 12, a client terminal 13, an information processing device 14, and the like.
  • the RDB 11 includes a plurality of tables identified by table names having a plurality of column names and columns corresponding to the respective column names, and an acquisition request received from the client terminal 13 via the information processing device 14 When SQL is received, it has a function of sending a return value according to the acquisition request SQL.
  • the RDB 11 is configured by a so-called hard disk drive (HDD: “Hard” Disk “Drive”) or the like.
  • the in-memory KVS 12 is a storage medium that stores a key for identifying data (for example, an acquisition request SQL) and the data in a one-to-one correspondence.
  • the in-memory KVS 12 is not a KVS that uses a so-called HDD as a data storage area, but is assumed to be a KVS that can perform high-speed processing by placing the data storage area on the memory.
  • the client terminal 13 has a function of issuing an acquisition request SQL for acquiring data stored in the RDB 11 and receiving a return value corresponding to the acquisition request SQL. Further, the client terminal 13 has a function of issuing an update request SQL (for example, a change request SQL, an insertion request SQL, etc.) for updating data stored in the RDB 11. Further, the client terminal 13 has a function of issuing a confirmation request SQL for confirming the update executed according to the update request SQL and a rewind request SQL for returning the above-described update.
  • an update request SQL for example, a change request SQL, an insertion request SQL, etc.
  • the information processing apparatus 14 further includes a client communication unit 141, a cache control unit 142, an RDB communication unit 143, an update work memory 144, and the like.
  • a client communication unit 141 the functions of the units 141 to 144 in the information processing apparatus 14 used during the data acquisition process are described first, and then the functions of the units 141 to 144 in the information processing apparatus 14 used during the data update process are described. explain. First, functions of the units 141 to 144 in the information processing apparatus 14 used during the data acquisition process will be described.
  • the client communication unit 141 receives the acquisition request SQL issued by the client terminal 13, and sends the acquisition request SQL to the cache control unit 142 and a return value corresponding to the acquisition request SQL to the client terminal 13. It has a function.
  • the cache control unit 142 Upon receipt of the acquisition request SQL sent from the client communication unit 141, the cache control unit 142 has a function of searching the in-memory KVS 12 using the acquisition request SQL as a key. Further, the cache control unit 142 has a function of sending the return value to the client communication unit 141 when a return value corresponding to the acquisition request SQL is obtained from the in-memory KVS 12 as a result of the search. Further, the cache control unit 142 has a function of sending (transferring) the acquisition request SQL to the RDB communication unit 143 when a return value corresponding to the acquisition request SQL is not obtained from the in-memory KVS 12 as a result of the search. .
  • the RDB communication unit 143 When the RDB communication unit 143 receives the acquisition request SQL sent from the cache control unit 142, the RDB communication unit 143 sends the acquisition request SQL to the RDB 11, acquires a return value corresponding to the acquisition request SQL, and cache control unit 142.
  • the acquired return value is registered in the in-memory KVS 12 using the acquisition request SQL as a key.
  • the acquired return value is sent to the client communication unit 141.
  • update work memory 144 is not used during the data acquisition process.
  • the data update process includes a data update process executed in accordance with the change request SQL and a data update process executed in accordance with the insertion request SQL.
  • the functions of the units 141 to 144 used in the data update process executed in accordance with the change request SQL will be described, and then the data update process executed in accordance with the insert request SQL will be described.
  • the functions of the units 141 to 144 in the information processing apparatus 14 to be used will be described.
  • functions of the units 141 to 144 in the information processing apparatus 14 used during data update processing executed according to the change request SQL will be described.
  • the client communication unit 141 has a function of receiving the row lock request SQL issued by the client terminal 13 and sending the row lock request SQL to the RDB communication unit 143.
  • the row lock request SQL is mainly a request SQL issued from the client terminal 13 before the data stored in the RDB 11 is changed (updated), and other than the row (or table) including the data to be updated. It is required to restrict access to resources.
  • the RDB communication unit 143 receives the row lock request SQL sent from the client communication unit 141, the RDB communication unit 143 sends the row lock request SQL to the RDB 11, and accesses other resources to the row including the data to be updated. And lock information indicating the locked row is written in the update work memory 144.
  • the client communication unit 141 has a function of receiving the change request SQL issued by the client terminal 13 and sending the change request SQL to the RDB communication unit 143.
  • the RDB communication unit 143 When the RDB communication unit 143 receives the change request SQL sent from the client communication unit 141, the RDB communication unit 143 refers to the update work memory 144 and updates the row (in the RDB 11) including data (or in the RDB 11). (Table) has a function to check whether it is locked in advance.
  • the RDB communication unit 143 restricts the access of other resources to the row including the data to be updated according to the change request SQL, and then stores the plurality of resources stored in the RDB 11. Search the table for the row that contains the data to be updated. At this time, the RDB communication unit 143 writes lock information indicating the locked row in the update work memory 144. On the other hand, if the result of confirmation indicates that the data is locked in advance, the RDB communication unit 143 executes only processing for searching for a row including data to be updated.
  • the RDB communication unit 143 has a function of writing a column name and a column of the update target data in the update work memory 144 when searching for a row including the update target data.
  • the RDB communication unit 143 has a function of sending a change request SQL to the RDB 11 and updating data to be updated.
  • the RDB communication unit 143 executes a process for confirming the update executed according to the above-described change request SQL, and the update.
  • the process of giving update confirmation information indicating that the update is confirmed to the column name and the column of the data before update stored in the work memory 144 is executed.
  • the RDB communication unit 143 receives the rewind request SQL issued from the client terminal 13 via the client communication unit 141, the RDB communication unit 143 executes a process for restoring the update executed according to the above-described change request SQL. .
  • the cache control unit 142 has a function of deleting data including a column name and a column to which update confirmation information is assigned in the update work memory 144 from the data group stored in the in-memory KVS 12. Further, the cache control unit 142 has a function of appropriately deleting the lock information stored in the update work memory 144 and the data to which the update confirmation information is added.
  • the RDB communication unit 143 may have a function of deleting various data stored in the update work memory 144 as described above.
  • the client communication unit 141 has a function of receiving the insertion request SQL issued by the client terminal 13 and sending the insertion request SQL to the RDB communication unit 143.
  • the RDB communication unit 143 When the RDB communication unit 143 receives the insertion request SQL sent from the client communication unit 141, the RDB communication unit 143 sends the insertion request SQL to the RDB 11, and has a function of inserting the data to be inserted into a desired table stored in the RDB 11. Yes. Further, the RDB communication unit 143 has a function of writing all the column names and columns of the inserted data in the update work memory 144 when the insertion target data is inserted according to the insertion request SQL (when the insertion is successful).
  • the RDB communication unit 143 executes a process for confirming the update executed according to the above-described insertion request SQL, The process of giving update confirmation information indicating that the update is confirmed to the column name and the column of the data to be inserted stored in the work memory 144 is executed.
  • the RDB communication unit 143 receives the rewind request SQL issued from the client terminal 13 via the client communication unit 141, the RDB communication unit 143 executes a process for restoring the update executed according to the above-described insertion request SQL. .
  • the cache control unit 142 has a function of appropriately deleting data to which update confirmation information stored in the update work memory 144 is added.
  • the RDB communication unit 143 may have a function of deleting various data stored in the update work memory 144 as described above.
  • the client communication unit 141 receives the change request SQL issued by the client terminal 13, and sends this change request SQL to the RDB communication unit 143 (step S1).
  • the RDB communication unit 143 when the RDB communication unit 143 receives the change request SQL sent from the client communication unit 141, the RDB communication unit 143 refers to the update work memory 144 and includes data to be updated (in the RDB 11) according to the change request SQL. It is confirmed whether or not the row (or table) is locked in advance (step S2).
  • step S2 When the result of the confirmation in step S2 indicates that it has been locked in advance (YES in step S2), the RDB communication unit 143 searches for a row including data to be updated from a plurality of tables stored in the RDB 11 ( Step S3). When the process of step S3 is completed, the process proceeds to the process of step S5 described later.
  • step S2 when the result of the confirmation in step S2 indicates NO (NO in step S2), the RDB communication unit 143 locks a row including data to be updated according to the change request SQL, and then stores a plurality of tables stored in the RDB 11. Search the row that contains the data to be updated. Then, the RDB communication unit 143 writes lock information indicating the locked row in the update work memory 144 (step S4).
  • the RDB communication unit 143 searches for a row including data to be updated, the RDB communication unit 143 writes the column name and column of the data to be updated in the update work memory 144 (step S5).
  • the RDB communication unit 143 sends a change request SQL to the RDB 11, and updates the update target data (step S6).
  • the client communication unit 141 responds to the client terminal 13 (step S7). In other words, the client communication unit 141 notifies the client terminal 13 that the process to be executed according to the change request SQL has been completed.
  • the client communication unit 141 receives the request SQL issued from the client terminal 13 and confirms whether the request SQL is a rewind request SQL or a confirmation request SQL (step S8). If the confirmation result in step S8 is the confirmation request SQL, the process proceeds to step S13 described later.
  • step S8 If the result of the confirmation in step S8 is a rewind request SQL (rewind request SQL in step S8), the client communication unit 141 sends this rewind request SQL to the RDB communication unit 143 (step S9).
  • the RDB communication unit 143 when the RDB communication unit 143 receives the rewind request SQL sent from the client communication unit 141, the RDB communication unit 143 sends the rewind request SQL to the RDB 11, and restores the update executed according to the change request SQL. Execute the process.
  • the RDB 11 side automatically releases the lock performed on the row including the update target data (step S10).
  • the RDB communication unit 143 deletes the lock information and the column name and column of the update target data stored in the update work memory 144 (step S11).
  • the client communication unit 141 responds to the client terminal 13, that is, notifies the client terminal 13 that the process to be executed in accordance with the rewind request SQL is completed (step S12), and ends the data update process.
  • step S8 When the confirmation result in step S8 is the confirmation request SQL (confirmation request SQL in step S7), the client communication unit 141 sends the confirmation request SQL to the RDB communication unit 143 (step S13).
  • the RDB communication unit 143 when the RDB communication unit 143 receives the confirmation request SQL sent from the client communication unit 141, the RDB communication unit 143 sends the confirmation request SQL to the RDB 11, and executes a process for confirming the update executed according to the change request SQL. To do.
  • the RDB 11 side automatically releases the lock performed on the row including the data to be updated (step S14).
  • the RDB communication unit 143 gives update confirmation information indicating that the update has been confirmed for the column name and the column of the update target data stored in the update work memory 144 (step S15).
  • the client communication unit 141 responds to the client terminal 13 (step S16). In other words, the client communication unit 141 notifies the client terminal 13 that the process to be executed according to the confirmation request SQL has been completed.
  • the cache control unit 142 deletes the data including the column name and the column to which the update confirmation information is given in the update work memory 144 from the data group stored in the in-memory KVS 12 (Step S17).
  • the cache control unit 142 deletes the column name and column of the data to which the lock information and the update confirmation information are stored, which is stored in the update work memory 144 (Step S18), and ends the data update process.
  • the information processing apparatus 14 first checks the in-memory KVS 12 and accesses the RDB 11 when desired data cannot be obtained from the in-memory KVS 12. Therefore, the user operating the client terminal 13 can quickly obtain desired data without having to change the access target.
  • the information processing apparatus 14 executes a process of deleting the pre-update data stored in the in-memory KVS 12, so that after the data update process, the client terminal 13 It is possible to prevent the pre-update data from being acquired from the memory KVS 12.
  • FIG. 3 is a block diagram illustrating a schematic configuration example of a data management system to which the information processing apparatus according to the second embodiment is applied.
  • the data management system 1 shown in FIG. 3 includes a KVS journal 15 in addition to the configuration shown in FIG. 1, and the information processing apparatus 14 further includes a delayed update processing unit 145.
  • functions different from those of the first embodiment described above will be mainly described.
  • the KVS journal 15 is a storage medium that stores a log file related to data update processing executed by the information processing apparatus 14 and is communicably connected to the in-memory KVS 12.
  • the KVS journal 15 is configured by a so-called HDD or the like, similar to the RDB 11. For this reason, even if the data stored in the in-memory KVS 12 is deleted due to the stop of the data management system 1 or the like, the log file stored in the KVS journal 15 is not deleted.
  • the KVS journal 15 is provided outside the information processing apparatus 14, but the KVS journal 15 may be provided within the information processing apparatus 14.
  • the delayed update processing unit 145 receives various requests SQL (for example, change request SQL, confirmation request SQL, etc.) that have been issued from the client terminal 13 and once stored in the in-memory KVS 12 when the data management system 1 is stopped.
  • the in-memory KVS 12 has a function of requesting reconfiguration based on the log file stored in the KVS journal 15. Further, the delayed update processing unit 145 has a function of executing again the data update processing that has been interrupted due to the stop of the data management system 1 in accordance with various requests SQL reconfigured by the in-memory KVS 12.
  • the client communication unit 141 receives the change request SQL issued by the client terminal 13, and sends this change request SQL to the RDB communication unit 143 (step S21).
  • the client communication unit 141 appropriately sends the received change request SQL to the cache control unit 142.
  • the RDB communication unit 143 when the RDB communication unit 143 receives the change request SQL sent from the client communication unit 141, the RDB communication unit 143 refers to the update work memory 144 and includes data to be updated (in the RDB 11) according to the change request SQL. It is confirmed whether or not the row (or table) is locked in advance (step S22).
  • step S22 When the result of the confirmation in step S22 indicates that it is locked in advance (YES in step S22), the RDB communication unit 143 searches for a row including the update target data from a plurality of tables stored in the RDB 11 ( Step S23). When the process of step S23 is completed, the process proceeds to step S25 described later.
  • step S22 when the result of the confirmation in step S22 indicates NO (NO in step S22), the RDB communication unit 143 locks a row including data to be updated according to the change request SQL, and then stores a plurality of tables stored in the RDB 11. Search the row that contains the data to be updated. Then, the RDB communication unit 143 writes lock information indicating the locked row in the update work memory 144 (step S24).
  • the RDB communication unit 143 retrieves a row including the update target data
  • the RDB communication unit 143 writes the column name and column of the update target data in the update work memory 144 (step S25).
  • the cache control unit 142 When the column name and column of the data to be updated are written to the update work memory 144, the cache control unit 142 writes the received change request SQL sent from the client communication unit 141 to the in-memory KVS 12 (step S26). .
  • the change request SQL is written to the in-memory KVS 12
  • a log file indicating that the change request SQL is written to the in-memory KVS 12 is appropriately recorded in the KVS journal 15.
  • the client communication unit 141 responds to the client terminal 13 (step S27). In other words, the client communication unit 141 notifies the client terminal 13 that the process to be executed according to the change request SQL has been completed.
  • the client communication unit 141 receives the request SQL issued from the client terminal 13, and confirms whether the request SQL is a rewind request SQL or a confirmation request SQL (step S28). If the confirmation result in step S28 is the confirmation request SQL, the process proceeds to step S33 described later.
  • step S28 When the confirmation result in step S28 is a rewind request SQL (rewind request SQL in step S28), the client communication unit 141 sends this rewind request SQL to the RDB communication unit 143. Note that when the rewind request SQL is sent to the RDB communication unit 143, on the RDB 11 side, the lock performed on the row including the data to be updated is automatically released (step S29).
  • the RDB communication unit 143 when the RDB communication unit 143 receives the rewind request SQL sent from the client communication unit 141, the RDB communication unit 143 stores the lock information and update target data stored in the update work memory 144 according to the rewind request SQL.
  • the column name and column are deleted (step S30).
  • the cache control unit 142 deletes the change request SQL stored in the in-memory KVS 12 (step S31).
  • the client communication unit 141 responds to the client terminal 13, that is, notifies the client terminal 13 that the process to be executed according to the rewind request SQL is completed (step S32), and ends the data update process.
  • step S28 If the result of the confirmation in step S28 described above is a confirmation request SQL (confirmation request SQL in step S28), the client communication unit 141 sends this confirmation request SQL to the cache control unit 142 (step S33).
  • Step S34 upon receiving the confirmation request SQL sent from the client communication unit 141, the cache control unit 142 writes the confirmation request SQL in the in-memory KVS 12 (Step S34).
  • the confirmation request SQL is written in the in-memory KVS 12
  • a log file indicating that the confirmation request SQL is written in the in-memory KVS 12 is appropriately recorded in the KVS journal 15.
  • the RDB communication unit 143 updates the update to indicate that the update is confirmed for the column name and the column of the update target data stored in the update work memory 144. Information is given (step S35).
  • the client communication unit 141 responds to the client terminal 13 (step S36). In other words, the client communication unit 141 notifies the client terminal 13 that the process to be executed according to the confirmation request SQL has been completed.
  • the delayed update processing unit 145 acquires the change request SQL and the confirmation request SQL stored in the in-memory KVS 12 via the cache control unit 142 asynchronously with the response to the client terminal 13 described above.
  • a request SQL is sent to the RDB 11, the update target data stored in the RDB 11 is updated, and a process for confirming the update is executed.
  • the RDB 11 side automatically releases the lock performed on the row including the data to be updated (step S37).
  • the delayed update processing unit 145 deletes the change request SQL and the confirmation request SQL stored in the in-memory KVS 12 (step S38). Further, the delayed update processing unit 145 deletes the data including the column name and the column of the data to which the update confirmation information is given in the update work memory 144 from the data group stored in the in-memory KVS (Step S39). ).
  • the delayed update processing unit 145 deletes the column name and column of the data to which the lock information and the update confirmation information are stored, which is stored in the update work memory 144 (Step S40), and ends the data update process. .
  • the data management system 1 is stopped in the middle of the data update process, it is stored in the in-memory KVS 12 based on the log file stored in the KVS journal 15 after the system is restarted.
  • the change request SQL and the confirmation request SQL that have been made can be reconfigured. Accordingly, the data update process can be executed again without having the client terminal 13 reissue various requests SQL. Further, the response time to the client terminal 13 is executed by executing the data update process and the data update confirmation process that take the longest response time as data update for the RDB 11 after the response to the client terminal 13 while ensuring the data change. Can be expedited.
  • a suitable data management method using the RDB 11 and the in-memory KVS 12 in combination can be realized.
  • the processing of the present embodiment can be realized by a computer program. Therefore, the computer program can be installed and executed on a computer through a computer-readable storage medium storing the computer program. Similar effects can be easily realized.

Landscapes

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

Abstract

　実施形態によれば、情報処理装置は、クライアント端末から更新要求を受けると、第１記憶媒体を検索して、更新要求による更新対象のデータのカラム名とカラムとを取得する取得手段と、取得されたカラム名とカラムとが対応付けられたデータを一時メモリに書き込む第１書込手段と、更新要求にしたがって、更新対象のデータのカラムを更新する更新手段と、更新の後に、クライアント端末から更新を確定させる旨の更新確定要求を受けると、第１記憶媒体に格納された更新対象のデータのカラムへの更新を確定させると共に、一時メモリに格納された更新対象のデータのカラムを含むデータに対して更新を確定させた旨の更新確定情報を付与する更新確定手段と、第２記憶媒体に格納されたデータ群から、更新確定情報が付与されたデータのカラム名とカラムとを含むデータを削除する削除手段とを具備する。

Description

情報処理装置及び方法
　本発明の実施形態は、一般的に情報処理装置及び方法に関する。
　近年、データの管理方法として、リレーショナルデータベース（RDB: Relational Database）とインメモリのキーバリューストア（KVS: Key Value Store）とを組み合せて使用するデータ管理方法が普及しつつある。このデータ管理方法によれば、ＲＤＢだけを使用したデータ管理方法にくらべて、クライアント端末が所望のデータを取得するまでに要する時間を短縮することができる。
　一般に、ＲＤＢだけを使用したデータ管理方法の場合、クライアント端末からのアクセスに応じて、ＲＤＢに格納された多量のテーブルの中から所望のデータを含むテーブルを検索し、このテーブルから所望のデータを取得する必要があり、クライアント端末が所望のデータを取得するまでに時間がかかってしまう。
　一方で、ＲＤＢとインメモリのＫＶＳとを組み合せて使用するデータ管理方法の場合、まずインメモリのＫＶＳに所望のデータがキャッシュとして格納されているか否かを確認する。インメモリのＫＶＳには、所望のデータを取得するためのキーと所望のデータとが１対１に対応付けられて格納されているため、所望のデータがキャッシュとして格納されている場合は、クライアント端末は、ＲＤＢだけを使用したデータ管理方法にくらべて格段に早く所望のデータを取得することができる。また、所望のデータがキャッシュとして格納されていない場合は、クライアント端末は、アクセス対象をＲＤＢに変更して、ＲＤＢから所望のデータを取得することになるが、このときに取得した所望のデータをインメモリのＫＶＳのキャッシュとして登録しておくことにより、クライアント端末が所望のデータを取得するまでにかかる次回以降の時間を短縮することができる。
　以上のように、ＲＤＢとインメモリのＫＶＳとを組み合せて使用するデータ管理方法によれば、ＲＤＢだけを使用したデータ管理方法にくらべて、クライアント端末が所望のデータを取得するまでに要する時間を短縮することができる。
　しかしながら、上述したように、ＲＤＢとインメモリのＫＶＳとを組み合せて使用する場合であって、インメモリのＫＶＳにキャッシュとして所望のデータが格納されていない場合に、クライアント端末自身が、アクセス対象をＲＤＢに変更する必要があるという不都合がある。すなわち、アクセス対象をインメモリのＫＶＳからＲＤＢに変更するというクライアント端末の動作の記述を、クライアント端末を操作するユーザが行う必要があるという不都合がある。
　また、ＲＤＢとインメモリのＫＶＳとを組み合せて使用するデータ管理方法の場合、ＲＤＢに格納されたデータを更新した際に不都合が生じる恐れがある。一般に、ＲＤＢに格納されたデータを更新した際には、もし更新前のデータがインメモリのＫＶＳにキャッシュとして格納されている場合はこのキャッシュのデータも更新する必要がある。しかしながら、ＲＤＢに格納されたデータの更新に応じて、インメモリのＫＶＳのキャッシュの更新を行わせるという動作の記述は複雑であり、この動作が一般的には行われていないという現状がある。これにより、ＲＤＢに格納されたデータが更新されているにも関わらず、インメモリのＫＶＳのキャッシュのデータが更新されていないことに起因して、クライアント端末に更新前のデータを取得させてしまう恐れがある。
特開２０１３－１５２５５７号公報
　本発明の一形態の目的は、ＲＤＢとインメモリのＫＶＳとを組み合せて使用する好適なデータ管理方法を実現し得る情報処理装置及び方法を提供することである。
　実施形態によれば、情報処理装置は、クライアント端末と、複数のカラム名と各カラム名に対応するカラムとを有してテーブル名により識別される複数のテーブルを備えた第１記憶媒体と、前記第１記憶媒体に格納された各テーブル内の一部のデータと当該データを読み出す際に用いるキーとを対応付けて格納する第２記憶媒体とに通信可能に接続され、データ管理システムに適用される。この情報処理装置は、前記クライアント端末から前記第１記憶媒体に格納された各テーブル内のデータを書きかえる旨の更新要求を受けると、前記第１記憶媒体を検索して、前記更新要求による更新対象のデータのカラム名とカラムとを取得する取得手段と、前記取得されたカラム名とカラムとが対応付けられたデータを一時メモリに書き込む第１書込手段と、前記受信された更新要求にしたがって、前記更新対象のデータのカラムを更新する更新手段と、更新の後に、前記クライアント端末から前記更新を確定させる旨の更新確定要求を受けると、前記第１記憶媒体に格納された前記更新対象のデータのカラムへの更新を確定させると共に、前記一時メモリに格納された前記更新対象のデータのカラムを含むデータに対して更新を確定させた旨の更新確定情報を付与する更新確定手段と、前記第２記憶媒体に格納されたデータ群から、前記更新確定情報が付与されたデータのカラム名とカラムとを含むデータを削除する削除手段とを具備する。
図１は、第１実施形態に係る情報処理装置を適用するデータ管理システムの概略構成例を示すブロック図である。 図２は、同実施形態に係る情報処理装置によって実行されるデータ更新処理の手順の一例を示すフローチャートである。 図３は、第２実施形態に係る情報処理装置を適用するデータ管理システムの概略構成例を示すブロック図である。 図４は、同実施形態に係る情報処理装置によって実行されるデータ更新処理の手順の一例を示すフローチャートである。
　以下、実施の形態について図面を参照して説明する。　
［第１実施形態］
　図１は、第１実施形態に係る情報処理装置を適用するデータ管理システムの概略構成例を示すブロック図である。データ管理システム１は、ＲＤＢ１１、インメモリＫＶＳ１２、クライアント端末１３及び情報処理装置１４等を備えている。
　ＲＤＢ１１は、複数のカラム名と、各カラム名に対応するカラムとを有してテーブル名により識別される複数のテーブルを備えており、クライアント端末１３から情報処理装置１４を介して受けた取得要求ＳＱＬを受けると、この取得要求ＳＱＬに応じた戻り値を送出する機能をもっている。ＲＤＢ１１は、所謂ハードディスクドライブ（HDD: Hard Disk Drive）等によって構成される。
　インメモリＫＶＳ１２は、データを識別するためのキー（例えば、取得要求ＳＱＬ等）とデータとを１対１に対応付けて格納する記憶媒体である。尚、本実施形態では、インメモリＫＶＳ１２はデータ保存領域として所謂ＨＤＤを使用するＫＶＳではなく、データ保存領域をメモリ上に置くことにより高速に処理が可能なＫＶＳを想定する。
　クライアント端末１３は、ＲＤＢ１１に格納されたデータを取得するための取得要求ＳＱＬを発行し、この取得要求ＳＱＬに応じた戻り値を受信する機能をもっている。また、クライアント端末１３は、ＲＤＢ１１に格納されたデータを更新するための更新要求ＳＱＬ（例えば、変更要求ＳＱＬ、挿入要求ＳＱＬ等）を発行する機能をもっている。さらに、クライアント端末１３は、更新要求ＳＱＬにしたがって実行された更新を確定させるための確定要求ＳＱＬや、上述の更新を元に戻すための巻き戻し要求ＳＱＬを発行する機能をもっている。
　情報処理装置１４は、図１に示すように、クライアント通信部１４１、キャッシュ制御部１４２、ＲＤＢ通信部１４３及び更新用ワークメモリ１４４等をさらに含む。以下の説明では、まずデータ取得処理時に使用される情報処理装置１４内の各部１４１～１４４の機能について述べた後に、データ更新処理時に使用される情報処理装置１４内の各部１４１～１４４の機能について説明する。　
　まずデータ取得処理時に使用される情報処理装置１４内の各部１４１～１４４の機能について説明する。
　クライアント通信部１４１は、クライアント端末１３によって発行された取得要求ＳＱＬを受信し、この取得要求ＳＱＬをキャッシュ制御部１４２に送出する機能と、取得要求ＳＱＬに応じた戻り値をクライアント端末１３に送出する機能とをもっている。
　キャッシュ制御部１４２は、クライアント通信部１４１から送出された取得要求ＳＱＬを受けると、当該取得要求ＳＱＬをキーとしてインメモリＫＶＳ１２を検索する機能をもっている。また、キャッシュ制御部１４２は、検索の結果、取得要求ＳＱＬに応じた戻り値がインメモリＫＶＳ１２から得られた場合に、当該戻り値をクライアント通信部１４１に送出する機能をもっている。さらに、キャッシュ制御部１４２は、検索の結果、取得要求ＳＱＬに応じた戻り値がインメモリＫＶＳ１２から得られなかった場合に、当該取得要求ＳＱＬをＲＤＢ通信部１４３に送出（転送）する機能をもっている。
　ＲＤＢ通信部１４３は、キャッシュ制御部１４２から送出された取得要求ＳＱＬを受けると、当該取得要求ＳＱＬをＲＤＢ１１に送出して、当該取得要求ＳＱＬに応じた戻り値を取得すると共に、キャッシュ制御部１４２を介して、当該取得した戻り値を当該取得要求ＳＱＬをキーとしてインメモリＫＶＳ１２に登録する。取得された戻り値はクライアント通信部１４１に送出される。
　尚、更新用ワークメモリ１４４は、データ取得処理時には使用されないものとする。
　次に、データ更新処理時に使用される情報処理装置１４内の各部１４１～１４４の機能について説明する。尚、データ更新処理には、変更要求ＳＱＬにしたがって実行されるデータ更新処理と、挿入要求ＳＱＬにしたがって実行されるデータ更新処理とがある。以下の説明では、まず変更要求ＳＱＬにしたがって実行されるデータ更新処理時に使用される情報処理装置１４内の各部１４１～１４４の機能について説明した後に、挿入要求ＳＱＬにしたがって実行されるデータ更新処理時に使用される情報処理装置１４内の各部１４１～１４４の機能について説明する。　
　まず変更要求ＳＱＬにしたがって実行されるデータ更新処理時に使用される情報処理装置１４内の各部１４１～１４４の機能について説明する。
　クライアント通信部１４１は、クライアント端末１３によって発行された行ロック要求ＳＱＬを受信し、この行ロック要求ＳＱＬをＲＤＢ通信部１４３に送出する機能をもっている。行ロック要求ＳＱＬとは、主に、ＲＤＢ１１に格納されたデータを変更（更新）する前にクライアント端末１３から発行される要求ＳＱＬであり、更新対象のデータを含む行（又はテーブル）への他のリソースのアクセスを制限することを要求するものである。尚、ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された行ロック要求ＳＱＬを受けると、当該行ロック要求ＳＱＬをＲＤＢ１１に送出して、更新対象のデータを含む行への他のリソースのアクセスを制限する（当該行をロックする）と共に、ロックした行を示すロック情報を更新用ワークメモリ１４４に書き込む。
　また、クライアント通信部１４１は、クライアント端末１３によって発行された変更要求ＳＱＬを受信し、この変更要求ＳＱＬをＲＤＢ通信部１４３に送出する機能をもっている。
　ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された変更要求ＳＱＬを受けると、更新用ワークメモリ１４４を参照して、当該変更要求ＳＱＬにしたがって更新する（ＲＤＢ１１内の）データを含む行（又はテーブル）が事前にロックされているか否かを確認する機能をもっている。
　確認の結果、事前にロックされていない場合には、ＲＤＢ通信部１４３は、変更要求ＳＱＬにしたがって更新するデータを含む行への他のリソースのアクセスを制限した後に、ＲＤＢ１１に格納された複数のテーブルから更新対象のデータを含む行を検索する。このとき、ＲＤＢ通信部１４３は、ロックした行を示すロック情報を更新用ワークメモリ１４４に書き込む。一方で、確認の結果、事前にロックされている場合には、ＲＤＢ通信部１４３は、更新対象のデータを含む行を検索する処理だけを実行する。
　ＲＤＢ通信部１４３は、更新対象のデータを含む行を検索すると、当該更新対象のデータのカラム名とカラムとを更新用ワークメモリ１４４に書き込む機能をもっている。また、ＲＤＢ通信部１４３は、変更要求ＳＱＬをＲＤＢ１１に送出して、更新対象のデータを更新する機能をもっている。
　さらに、ＲＤＢ通信部１４３は、クライアント端末１３から発行された確定要求ＳＱＬをクライアント通信部１４１を介して受けると、上述の変更要求ＳＱＬにしたがって実行された更新を確定させる処理を実行すると共に、更新用ワークメモリ１４４に格納された更新前のデータのカラム名とカラムとに対して更新が確定された旨を示す更新確定情報を付与する処理を実行する。一方で、ＲＤＢ通信部１４３は、クライアント端末１３から発行された巻き戻し要求ＳＱＬをクライアント通信部１４１を介して受けると、上述の変更要求ＳＱＬにしたがって実行された更新を元に戻す処理を実行する。
　キャッシュ制御部１４２は、インメモリＫＶＳ１２に格納されたデータ群から、更新用ワークメモリ１４４内で更新確定情報が付与されたカラム名とカラムとを含むデータを削除する機能をもっている。また、キャッシュ制御部１４２は、更新用ワークメモリ１４４に格納されたロック情報と更新確定情報が付与されたデータとを適宜削除する機能をもっている。尚、上述のような更新用ワークメモリ１４４に格納された各種データを削除する機能は、ＲＤＢ通信部１４３が有していてもよい。
　次に、挿入要求ＳＱＬにしたがって実行されるデータ更新処理時に使用される情報処理装置１４内の各部１４１～１４４の機能について説明する。
　クライアント通信部１４１は、クライアント端末１３によって発行された挿入要求ＳＱＬを受信し、この挿入要求ＳＱＬをＲＤＢ通信部１４３に送出する機能をもっている。
　ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された挿入要求ＳＱＬを受けると、当該挿入要求ＳＱＬをＲＤＢ１１に送出して、挿入対象のデータをＲＤＢ１１に格納された所望のテーブルに挿入する機能をもっている。また、ＲＤＢ通信部１４３は、挿入対象のデータを挿入要求ＳＱＬにしたがって挿入すると（挿入が成功すると）、挿入されたデータのカラム名とカラムとを全て更新用ワークメモリ１４４に書き込む機能をもっている。
　さらに、ＲＤＢ通信部１４３は、クライアント端末１３から発行された確定要求ＳＱＬをクライアント通信部１４１を介して受けると、上述の挿入要求ＳＱＬにしたがって実行された更新を確定させる処理を実行すると共に、更新用ワークメモリ１４４に格納された挿入対象のデータのカラム名とカラムとに対して更新が確定された旨を示す更新確定情報を付与する処理を実行する。一方で、ＲＤＢ通信部１４３は、クライアント端末１３から発行された巻き戻し要求ＳＱＬをクライアント通信部１４１を介して受けると、上述の挿入要求ＳＱＬにしたがって実行された更新を元に戻す処理を実行する。
　キャッシュ制御部１４２は、更新用ワークメモリ１４４に格納された更新確定情報が付与されたデータを適宜削除する機能をもっている。尚、上述のような更新用ワークメモリ１４４に格納された各種データを削除する機能は、ＲＤＢ通信部１４３が有していてもよい。
　次に、以上のように構成された情報処理装置１４によって実行されるデータ更新処理の手順の一例について、図２のフローチャートを参照しながら説明する。ここでは、変更要求ＳＱＬにしたがって実行されるデータ更新処理の手順について説明する。
　始めに、クライアント通信部１４１は、クライアント端末１３によって発行された変更要求ＳＱＬを受信し、この変更要求ＳＱＬをＲＤＢ通信部１４３に送出する（ステップＳ１）。
　次に、ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された変更要求ＳＱＬを受けると、更新用ワークメモリ１４４を参照して、当該変更要求ＳＱＬにしたがって更新する（ＲＤＢ１１内の）データを含む行（又はテーブル）が事前にロックされているか否かを確認する（ステップＳ２）。
　ステップＳ２の確認の結果が事前にロックされている旨を示す場合（ステップＳ２のＹＥＳ）、ＲＤＢ通信部１４３は、ＲＤＢ１１に格納された複数のテーブルから更新対象のデータを含む行を検索する（ステップＳ３）。尚、ステップＳ３の処理が終了すると、後述するステップＳ５の処理に進む。
　一方、ステップＳ２の確認の結果が否を示す場合（ステップＳ２のＮＯ）、ＲＤＢ通信部１４３は、変更要求ＳＱＬにしたがって更新するデータを含む行をロックした後に、ＲＤＢ１１に格納された複数のテーブルから更新対象のデータを含む行を検索する。そして、ＲＤＢ通信部１４３は、ロックした行を示すロック情報を更新用ワークメモリ１４４に書き込む（ステップＳ４）。
　続いて、ＲＤＢ通信部１４３は、更新対象のデータを含む行を検索すると、当該更新対象のデータのカラム名とカラムとを更新用ワークメモリ１４４に書き込む（ステップＳ５）。次に、ＲＤＢ通信部１４３は、変更要求ＳＱＬをＲＤＢ１１に送出して、更新対象のデータを更新する（ステップＳ６）。
　上述のステップＳ１～Ｓ６の処理が実行されると、クライアント通信部１４１は、クライアント端末１３に応答する（ステップＳ７）。すなわち、クライアント通信部１４１は、変更要求ＳＱＬにしたがって実行する処理が終了した旨をクライアント端末１３に通知する。
　続いて、クライアント通信部１４１は、クライアント端末１３から発行された要求ＳＱＬを受信し、当該要求ＳＱＬが巻き戻し要求ＳＱＬ又は確定要求ＳＱＬのどちらであるかを確認する（ステップＳ８）。尚、ステップＳ８の確認の結果が確定要求ＳＱＬである場合は、後述するステップＳ１３の処理に進む。
　ステップＳ８の確認の結果が巻き戻し要求ＳＱＬである場合（ステップＳ８の巻き戻し要求ＳＱＬ）、クライアント通信部１４１は、この巻き戻し要求ＳＱＬをＲＤＢ通信部１４３に送出する（ステップＳ９）。
　次に、ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された巻き戻し要求ＳＱＬを受けると、当該巻き戻し要求ＳＱＬをＲＤＢ１１に送出して、変更要求ＳＱＬにしたがって実行された更新を元に戻す処理を実行する。なお、巻き戻し要求ＳＱＬにしたがって更新を元に戻す処理が実行されると、ＲＤＢ１１側では、更新対象のデータを含む行に対して行われたロックが自動的に解放される（ステップＳ１０）。続いて、ＲＤＢ通信部１４３は、更新用ワークメモリ１４４に格納されたロック情報及び更新対象のデータのカラム名とカラムとを削除する（ステップＳ１１）。
　しかる後、クライアント通信部１４１は、クライアント端末１３に応答する、すなわち、巻き戻し要求ＳＱＬにしたがって実行する処理が終了した旨をクライアント端末１３に通知し（ステップＳ１２）、データ更新処理を終了させる。
　ステップＳ８の確認の結果が確定要求ＳＱＬである場合（ステップＳ７の確定要求ＳＱＬ）、クライアント通信部１４１は、この確定要求ＳＱＬをＲＤＢ通信部１４３に送出する（ステップＳ１３）。
　続いて、ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された確定要求ＳＱＬを受けると、当該確定要求ＳＱＬをＲＤＢ１１に送出して、変更要求ＳＱＬにしたがって実行された更新を確定させる処理を実行する。なお、確定要求ＳＱＬにしたがって更新を確定させる処理が実行されると、ＲＤＢ１１側では、更新対象のデータを含む行に対して行われたロックが自動的に解放される（ステップＳ１４）。次に、ＲＤＢ通信部１４３は、更新用ワークメモリ１４４に格納された更新対象のデータのカラム名とカラムとに対して更新が確定された旨を示す更新確定情報を付与する（ステップＳ１５）。
　上述のステップＳ８，Ｓ１３～Ｓ１５の処理が実行されると、クライアント通信部１４１は、クライアント端末１３に応答する（ステップＳ１６）。すなわち、クライアント通信部１４１は、確定要求ＳＱＬにしたがって実行する処理が終了した旨をクライアント端末１３に通知する。
　続いて、キャッシュ制御部１４２は、インメモリＫＶＳ１２に格納されたデータ群から、更新用ワークメモリ１４４内で更新確定情報が付与されたカラム名とカラムとを含むデータを削除する（ステップＳ１７）。
　しかる後、キャッシュ制御部１４２は、更新用ワークメモリ１４４に格納されたロック情報及び更新確定情報が付与されたデータのカラム名とカラムとを削除し（ステップＳ１８）、データ更新処理を終了させる。
　以上説明した第１実施形態によれば、データ取得処理時に、まずインメモリＫＶＳ１２を確認し、インメモリＫＶＳ１２から所望のデータが得られない場合にはＲＤＢ１１にアクセスするという処理を情報処理装置１４が実行するため、クライアント端末１３を操作するユーザがわざわざアクセス対象を変更しなくても所望のデータを素早く取得することができる。
　また、本実施形態によれば、データ更新処理時に、インメモリＫＶＳ１２に格納された更新前のデータを削除するという処理を情報処理装置１４が実行するため、データ更新処理後に、クライアント端末１３がインメモリＫＶＳ１２から更新前のデータを取得してしまうことを防ぐことができる。
［第２実施形態］
　図３は、第２実施形態に係る情報処理装置を適用するデータ管理システムの概略構成例を示すブロック図である。図３のデータ管理システム１は、図１に示した構成に加えて、ＫＶＳジャーナル１５をさらに備えると共に、情報処理装置１４が遅延更新処理部１４５をさらに含む構成になっている。ここでは主に、上述した第１実施形態とは異なる機能について説明する。
　まずＫＶＳジャーナル１５について説明する。　
　ＫＶＳジャーナル１５は、情報処理装置１４によって実行されるデータ更新処理に関するログファイルを格納する記憶媒体であり、インメモリＫＶＳ１２と通信可能に接続される。尚、ＫＶＳジャーナル１５は、ＲＤＢ１１と同様に、所謂ＨＤＤ等によって構成される。このため、データ管理システム１の停止等に起因して、インメモリＫＶＳ１２に格納されたデータが削除されてしまったとしても、ＫＶＳジャーナル１５に格納されたログファイルが削除されることはない。本実施形態では、ＫＶＳジャーナル１５は情報処理装置１４外に設けられるとしたが、ＫＶＳジャーナル１５は情報処理装置１４内に設けられるとしてもよい。
　遅延更新処理部１４５は、データ管理システム１が停止した際に、クライアント端末１３から既に発行されて、インメモリＫＶＳ１２に一度格納された各種要求ＳＱＬ（例えば、変更要求ＳＱＬ、確定要求ＳＱＬ等）を、ＫＶＳジャーナル１５に格納されたログファイルに基づいて再構成するようインメモリＫＶＳ１２に要求する機能をもっている。また、遅延更新処理部１４５は、インメモリＫＶＳ１２により再構成された各種要求ＳＱＬにしたがって、データ管理システム１の停止に起因して中断されてしまったデータ更新処理を再度実行する機能をもっている。
　次に、本実施形態に係る情報処理装置１４によって実行されるデータ更新処理の手順の一例について、図４のフローチャートを参照しながら説明する。ここでは、変更要求ＳＱＬにしたがって実行されるデータ更新処理の手順について説明する。
　始めに、クライアント通信部１４１は、クライアント端末１３によって発行された変更要求ＳＱＬを受信し、この変更要求ＳＱＬをＲＤＢ通信部１４３に送出する（ステップＳ２１）。尚、ここでは、クライアント通信部１４１は、受信した変更要求ＳＱＬをキャッシュ制御部１４２にも適宜送出するものとする。
　次に、ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された変更要求ＳＱＬを受けると、更新用ワークメモリ１４４を参照して、当該変更要求ＳＱＬにしたがって更新する（ＲＤＢ１１内の）データを含む行（又はテーブル）が事前にロックされているか否かを確認する（ステップＳ２２）。
　ステップＳ２２の確認の結果が事前にロックされている旨を示す場合（ステップＳ２２のＹＥＳ）、ＲＤＢ通信部１４３は、ＲＤＢ１１に格納された複数のテーブルから更新対象のデータを含む行を検索する（ステップＳ２３）。尚、ステップＳ２３の処理が終了すると、後述するステップＳ２５の処理に進む。
　一方、ステップＳ２２の確認の結果が否を示す場合（ステップＳ２２のＮＯ）、ＲＤＢ通信部１４３は、変更要求ＳＱＬにしたがって更新するデータを含む行をロックした後に、ＲＤＢ１１に格納された複数のテーブルから更新対象のデータを含む行を検索する。そして、ＲＤＢ通信部１４３は、ロックした行を示すロック情報を更新用ワークメモリ１４４に書き込む（ステップＳ２４）。
　続いて、ＲＤＢ通信部１４３は、更新対象のデータを含む行を検索すると、当該更新対象のデータのカラム名とカラムとを更新用ワークメモリ１４４に書き込む（ステップＳ２５）。
　更新対象のデータのカラム名とカラムとが更新用ワークメモリ１４４に書き込まれると、キャッシュ制御部１４２は、クライアント通信部１４１から送出され、受信した変更要求ＳＱＬをインメモリＫＶＳ１２に書き込む（ステップＳ２６）。尚、インメモリＫＶＳ１２に変更要求ＳＱＬが書き込まれると、ＫＶＳジャーナル１５には、変更要求ＳＱＬがインメモリＫＶＳ１２に書き込まれた旨のログファイルが適宜記録される。
　上述のステップＳ２１～Ｓ２６の処理が実行されると、クライアント通信部１４１は、クライアント端末１３に応答する（ステップＳ２７）。すなわち、クライアント通信部１４１は、変更要求ＳＱＬにしたがって実行する処理が終了した旨をクライアント端末１３に通知する。
　次に、クライアント通信部１４１は、クライアント端末１３から発行された要求ＳＱＬを受信し、当該要求ＳＱＬが巻き戻し要求ＳＱＬ又は確定要求ＳＱＬのどちらであるかを確認する（ステップＳ２８）。尚、ステップＳ２８の確認の結果が確定要求ＳＱＬである場合、後述するステップＳ３３の処理に進む。
　ステップＳ２８の確認の結果が巻き戻し要求ＳＱＬである場合（ステップＳ２８の巻き戻し要求ＳＱＬ）、クライアント通信部１４１は、この巻き戻し要求ＳＱＬをＲＤＢ通信部１４３に送出する。なお、巻き戻し要求ＳＱＬがＲＤＢ通信部１４３に送出されると、ＲＤＢ１１側では、更新対象のデータを含む行に対して行われたロックが自動的に解放される（ステップＳ２９）。
　続いて、ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された巻き戻し要求ＳＱＬを受けると、当該巻き戻し要求ＳＱＬにしたがって、更新用ワークメモリ１４４に格納されたロック情報及び更新対象のデータのカラム名とカラムとを削除する（ステップＳ３０）。
　更新用ワークメモリ１４４に格納された各種データが削除されると、キャッシュ制御部１４２は、インメモリＫＶＳ１２に格納された変更要求ＳＱＬを削除する（ステップＳ３１）。
　しかる後、クライアント通信部１４１は、クライアント端末１３に応答する、すなわち、巻き戻し要求ＳＱＬにしたがって実行する処理が終了した旨をクライアント端末１３に通知し（ステップＳ３２）、データ更新処理を終了させる。
　上述したステップＳ２８の確認の結果が確定要求ＳＱＬである場合（ステップＳ２８の確定要求ＳＱＬ）、クライアント通信部１４１は、この確定要求ＳＱＬをキャッシュ制御部１４２に送出する（ステップＳ３３）。
　次に、キャッシュ制御部１４２は、クライアント通信部１４１から送出された確定要求ＳＱＬを受けると、当該確定要求ＳＱＬをインメモリＫＶＳ１２に書き込む（ステップＳ３４）。尚、インメモリＫＶＳ１２に確定要求ＳＱＬが書き込まれると、ＫＶＳジャーナル１５には、確定要求ＳＱＬがインメモリＫＶＳ１２に書き込まれた旨のログファイルが適宜記録される。
　確定要求ＳＱＬがインメモリＫＶＳ１２に書き込まれると、ＲＤＢ通信部１４３は、更新用ワークメモリ１４４に格納された更新対象のデータのカラム名とカラムとに対して更新が確定された旨を示す更新確定情報を付与する（ステップＳ３５）。
　上述のステップＳ２８，Ｓ３３～Ｓ３５の処理が実行されると、クライアント通信部１４１は、クライアント端末１３に応答する（ステップＳ３６）。すなわち、クライアント通信部１４１は、確定要求ＳＱＬにしたがって実行する処理が終了した旨をクライアント端末１３に通知する。
　続いて、遅延更新処理部１４５は、上述したクライアント端末１３への応答とは非同期に、キャッシュ制御部１４２を介して、インメモリＫＶＳ１２に格納された変更要求ＳＱＬ及び確定要求ＳＱＬを取得し、これら要求ＳＱＬをＲＤＢ１１に送出して、ＲＤＢ１１に格納された更新対象のデータを更新し、この更新を確定させる処理を実行する。なお、確定要求ＳＱＬにしたがって更新を確定させる処理が実行されると、ＲＤＢ１１側では、更新対象のデータを含む行に対して行われたロックが自動的に解放される（ステップＳ３７）。
　更新対象のデータの更新処理及び更新確定処理が実行されると、遅延更新処理部１４５は、インメモリＫＶＳ１２に格納された変更要求ＳＱＬ及び確定要求ＳＱＬを削除する（ステップＳ３８）。また、遅延更新処理部１４５は、インメモリＫＶＳに格納されたデータ群から、更新用ワークメモリ１４４内で更新確定情報が付与されたデータのカラム名とカラムとを含むデータを削除する（ステップＳ３９）。
　しかる後、遅延更新処理部１４５は、更新用ワークメモリ１４４に格納されたロック情報及び更新確定情報が付与されたデータのカラム名とカラムとを削除し（ステップＳ４０）、データ更新処理を終了させる。
　以上説明した第２実施形態によれば、データ更新処理の途中でデータ管理システム１が停止したとしても、システム再起動後に、ＫＶＳジャーナル１５に格納されたログファイルに基づいて、インメモリＫＶＳ１２に格納されていた変更要求ＳＱＬや確定要求ＳＱＬを再構成することができる。これに伴い、クライアント端末１３から各種要求ＳＱＬを再度発行し直してもらわなくても、データ更新処理を再度実行することができる。また、ＲＤＢ１１に対するデータ更新として最も応答時間がかかるデータ更新処理とデータ更新確定処理とを、データの変更を保障したまま、クライアント端末１３に対する応答の後に実行させることにより、クライアント端末１３への応答時間を早めることができる。
　以上説明した少なくとも１つの実施形態によれば、ＲＤＢ１１とインメモリのＫＶＳ１２とを組み合せて使用する好適なデータ管理方法を実現させることができる。
　なお、本実施形態の処理は、コンピュータプログラムによって実現することができるので、このコンピュータプログラムを格納したコンピュータ読み取り可能な記憶媒体を通じてこのコンピュータプログラムをコンピュータにインストールして実行するだけで、本実施形態と同様の効果を容易に実現することができる。
　なお、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

Claims (8)

  1. 　クライアント端末と、複数のカラム名と各カラム名に対応するカラムとを有してテーブル名により識別される複数のテーブルを備えた第１記憶媒体と、前記第１記憶媒体に格納された各テーブル内の一部のデータと当該データを読み出す際に用いるキーとを対応付けて格納する第２記憶媒体とに通信可能に接続され、データ管理システムに適用される情報処理装置であって、
    　前記クライアント端末から前記第１記憶媒体に格納された各テーブル内のデータを書きかえる旨の更新要求を受けると、前記第１記憶媒体を検索して、前記更新要求による更新対象のデータのカラム名とカラムとを取得する取得手段と、
    　前記取得されたカラム名とカラムとが対応付けられたデータを一時メモリに書き込む第１書込手段と、
    　前記受信された更新要求にしたがって、前記更新対象のデータのカラムを更新する更新手段と、
    　更新の後に、前記クライアント端末から前記更新を確定させる旨の更新確定要求を受けると、前記第１記憶媒体に格納された前記更新対象のデータのカラムへの更新を確定させると共に、前記一時メモリに格納された前記更新対象のデータのカラムを含むデータに対して更新を確定させた旨の更新確定情報を付与する更新確定手段と、
    　前記第２記憶媒体に格納されたデータ群から、前記更新確定情報が付与されたデータのカラム名とカラムとを含むデータを削除する削除手段と
    　を具備する情報処理装置。
  2. 　更新の後に、前記クライアント端末から前記更新を巻き戻す旨の巻き戻し要求を受けると、前記更新対象のデータのカラムを更新前のカラムに戻す巻き戻し手段をさらに具備する請求項１に記載の情報処理装置。
  3. 　前記データ管理システムは、データ更新処理に関するログファイルを格納する第３記憶媒体をさらに含み、
    　前記情報処理装置は、
    　前記更新要求及び前記更新確定要求を受信した際に、当該更新要求及び当該更新確定要求を前記第２記憶媒体に各々書き込む第２書込手段と、
    　前記データ管理システムが停止した際に、前記第２記憶媒体に前記更新要求及び前記更新確定要求を書き込んだ旨の前記第３記憶媒体内のログファイルに基づいて、当該更新要求及び当該更新確定要求を再構成する再構成手段と、
    　前記再構成された更新要求及び更新確定要求にしたがってデータ更新処理を再度実行する再実行手段と
    　をさらに具備する請求項１に記載の情報処理装置。
  4. 　前記クライアント端末からの取得要求を受けると、当該取得要求を前記キーとして前記第２記憶媒体を検索する検索手段と、
    　検索の結果、前記取得要求に応じた戻り値が前記第２記憶媒体から得られた場合、当該戻り値を前記クライアント端末に送出する送出手段と、
    　検索の結果、前記取得要求に応じた戻り値が前記第２記憶媒体から得られなかった場合、当該戻り値を前記第１記憶媒体から取得して、前記クライアント端末に送出すると共に、当該戻り値を前記取得要求と対応付けて前記第２記憶媒体に書き込む第３書込手段と
    　をさらに具備する請求項１に記載の情報処理装置。
  5. 　クライアント端末と、複数のカラム名と各カラム名に対応するカラムとを有してテーブル名により識別される複数のテーブルを備えた第１記憶媒体と、前記第１記憶媒体に格納された各テーブル内の一部のデータと当該データを読み出す際に用いるキーとを対応付けて格納する第２記憶媒体とに通信可能に接続され、データ管理システムに適用される情報処理装置が実行する方法であって、
    　前記クライアント端末から前記第１記憶媒体に格納された各テーブル内のデータを書きかえる旨の更新要求を受けると、前記第１記憶媒体を検索して、前記更新要求による更新対象のデータのカラム名とカラムとを取得することと、
    　前記取得されたカラム名とカラムとが対応付けられたデータを一時メモリに書き込むことと、
    　前記受信された更新要求にしたがって、前記更新対象のデータのカラムを更新することと、
    　更新の後に、前記クライアント端末から前記更新を確定させる旨の更新確定要求を受けると、前記第１記憶媒体に格納された前記更新対象のデータのカラムへの更新を確定させると共に、前記一時メモリに格納された前記更新対象のデータのカラムを含むデータに対して更新を確定させた旨の更新確定情報を付与することと、
    　前記第２記憶媒体に格納されたデータ群から、前記更新確定情報が付与されたデータのカラム名とカラムとを含むデータを削除することと
    　を具備する方法。
  6. 　更新の後に、前記クライアント端末から前記更新を巻き戻す旨の巻き戻し要求を受けると、前記更新対象のデータのカラムを更新前のカラムに戻すことをさらに具備する請求項５に記載の方法。
  7. 　前記データ管理システムは、データ更新処理に関するログファイルを格納する第３記憶媒体をさらに含み、
    　前記更新要求及び前記更新確定要求を受信した際に、当該更新要求及び当該更新確定要求を前記第２記憶媒体に各々書き込むことと、
    　前記データ管理システムが停止した際に、前記第２記憶媒体に前記更新要求及び前記更新確定要求を書き込んだ旨の前記第３記憶媒体内のログファイルに基づいて、当該更新要求及び当該更新確定要求を再構成することと、
    　前記再構成された更新要求及び更新確定要求にしたがってデータ更新処理を再度実行することと
    　をさらに具備する請求項５に記載の方法。
  8. 　前記クライアント端末からの取得要求を受けると、当該取得要求を前記キーとして前記第２記憶媒体を検索することと、
    　検索の結果、前記取得要求に応じた戻り値が前記第２記憶媒体から得られた場合、当該戻り値を前記クライアント端末に送出することと、
    　検索の結果、前記取得要求に応じた戻り値が前記第２記憶媒体から得られなかった場合、当該戻り値を前記第１記憶媒体から取得して、前記クライアント端末に送出すると共に、当該戻り値を前記取得要求と対応付けて前記第２記憶媒体に書き込むことと
    　をさらに具備する請求項５に記載の方法。
PCT/JP2014/052918 2014-02-07 2014-02-07 情報処理装置及び方法 WO2015118662A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2015561117A JP6158361B2 (ja) 2014-02-07 2014-02-07 情報処理装置及び方法
PCT/JP2014/052918 WO2015118662A1 (ja) 2014-02-07 2014-02-07 情報処理装置及び方法
US15/222,172 US10303680B2 (en) 2014-02-07 2016-07-28 Data processing apparatus and data processing method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/052918 WO2015118662A1 (ja) 2014-02-07 2014-02-07 情報処理装置及び方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/222,172 Continuation US10303680B2 (en) 2014-02-07 2016-07-28 Data processing apparatus and data processing method

Publications (1)

Publication Number Publication Date
WO2015118662A1 true WO2015118662A1 (ja) 2015-08-13

Family

ID=53777492

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/052918 WO2015118662A1 (ja) 2014-02-07 2014-02-07 情報処理装置及び方法

Country Status (3)

Country Link
US (1) US10303680B2 (ja)
JP (1) JP6158361B2 (ja)
WO (1) WO2015118662A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110442558B (zh) * 2019-07-30 2023-12-29 深信服科技股份有限公司 数据处理方法、分片服务器、存储介质及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4392676B1 (ja) * 2009-06-25 2010-01-06 修平 西山 キー・バリュー・ストアによるデータベース・キャッシュ装置
JP2010198200A (ja) * 2009-02-24 2010-09-09 Nippon Telegr & Teleph Corp <Ntt> プロファイル情報管理装置、プロファイル情報管理方法、及びプログラム

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6564215B1 (en) * 1999-12-16 2003-05-13 International Business Machines Corporation Update support in database content management
US7321898B1 (en) * 2002-04-04 2008-01-22 Ncr Corp. Locking mechanism for materialized views in a database system
JP2006059191A (ja) * 2004-08-20 2006-03-02 Canon Inc データ処理装置、データ処理方法及びプログラム
JP4313845B2 (ja) * 2004-09-27 2009-08-12 修平 西山 マルチインスタンス・インメモリ・データベース
JP4385387B1 (ja) 2009-07-02 2009-12-16 修平 西山 属性付きキー・バリュー・ストアによるデータベース・システム
US8495044B2 (en) * 2009-09-02 2013-07-23 Microsoft Corporation File system node updates
JP5454201B2 (ja) 2010-02-15 2014-03-26 富士通株式会社 データストア切替装置、データストア切替方法およびデータストア切替プログラム
JP5811703B2 (ja) 2011-09-02 2015-11-11 富士通株式会社 分散制御プログラム、分散制御方法、および情報処理装置
JP2013152557A (ja) 2012-01-24 2013-08-08 Nippon Telegr & Teleph Corp <Ntt> メタデータ付与装置、メタデータ付与方法およびメタデータ付与プログラム
US9165010B2 (en) * 2012-04-30 2015-10-20 Sap Se Logless atomic data movement

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010198200A (ja) * 2009-02-24 2010-09-09 Nippon Telegr & Teleph Corp <Ntt> プロファイル情報管理装置、プロファイル情報管理方法、及びプログラム
JP4392676B1 (ja) * 2009-06-25 2010-01-06 修平 西山 キー・バリュー・ストアによるデータベース・キャッシュ装置

Also Published As

Publication number Publication date
JPWO2015118662A1 (ja) 2017-03-23
US20160335313A1 (en) 2016-11-17
US10303680B2 (en) 2019-05-28
JP6158361B2 (ja) 2017-07-05

Similar Documents

Publication Publication Date Title
US10706036B2 (en) Systems and methods to optimize multi-version support in indexes
US9779127B2 (en) Integrating database management system and external cache
US9563636B2 (en) Allowing writes to complete without obtaining a write lock to a file
US9965497B2 (en) Moving data between partitions
US9892183B2 (en) Computer system, computer system management method, and program
US10025710B2 (en) Pattern for integrating primary and secondary data stores in a sharded data domain
JP2020503588A (ja) コミットされていないトランザクションを有するデータベース・レコードのマルチバージョン同時制御
US20120259863A1 (en) Low Level Object Version Tracking Using Non-Volatile Memory Write Generations
US8832022B2 (en) Transaction processing device, transaction processing method and transaction processing program
US9514041B2 (en) Memory controller and memory system
US20220382712A1 (en) Minimizing data volume growth under encryption changes
US20200034472A1 (en) Asynchronous cache coherency for mvcc based database systems
US20170357680A1 (en) System and method for maintaining a multi-level data structure
US11061889B2 (en) Systems and methods of managing manifest refresh in a database
US20220382915A1 (en) Processing log entries under group-level encryption
US20140006348A1 (en) Opportunistic clearing of sync states associated with a database
JP6158361B2 (ja) 情報処理装置及び方法
US20170177615A1 (en) TRANSACTION MANAGEMENT METHOD FOR ENHANCING DATA STABILITY OF NoSQL DATABASE BASED ON DISTRIBUTED FILE SYSTEM
JP2017167654A (ja) データ管理装置及びデータベースの管理方法
US10685014B1 (en) Method of sharing read-only data pages among transactions in a database management system
US8521776B2 (en) Accessing data in a multi-generation database
JP2016194826A (ja) データベースの処理制御方法、処理制御プロラム及びデータベースサーバ
US20120317076A1 (en) DDL Command Filtering
KR101542299B1 (ko) 하둡 기반의 질의 처리 방법 및 장치
KR101690282B1 (ko) 테이블스페이스 속성 변경 방법 및 그 장치

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015561117

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14881806

Country of ref document: EP

Kind code of ref document: A1