WO2022038790A1 - Database selection device, database selection method, and program - Google Patents

Database selection device, database selection method, and program Download PDF

Info

Publication number
WO2022038790A1
WO2022038790A1 PCT/JP2020/031728 JP2020031728W WO2022038790A1 WO 2022038790 A1 WO2022038790 A1 WO 2022038790A1 JP 2020031728 W JP2020031728 W JP 2020031728W WO 2022038790 A1 WO2022038790 A1 WO 2022038790A1
Authority
WO
WIPO (PCT)
Prior art keywords
database
data
delay requirement
unit
terminal
Prior art date
Application number
PCT/JP2020/031728
Other languages
French (fr)
Japanese (ja)
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 JP2022543261A priority Critical patent/JPWO2022038790A1/ja
Priority to PCT/JP2020/031728 priority patent/WO2022038790A1/en
Publication of WO2022038790A1 publication Critical patent/WO2022038790A1/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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Definitions

  • the present invention relates to a database selection device, a database selection method and a program.
  • the time required for the response of the database management system (hereinafter referred to as "DBM") mainly consists of the data search algorithm and the access time to the storage device.
  • DBM database management system
  • the on-disk database is a method in which data is managed by a disk storage mechanism such as an HDD, and while the device cost can be suppressed compared to an in-memory database, the access time is long (several milliseconds to several tens of milliseconds). Has.
  • the in-memory database is a method of managing data on memory such as main memory, and has the characteristic that the access time is shorter (several nanoseconds) than the on-disk database, but the equipment cost is high.
  • the hybrid database is a method of managing data by using both an on-disk database and an in-memory database.
  • MySQL Non-Patent Document 1
  • SQLite Non-Patent Document 2
  • the on-disk database and the in-memory database are stored in table units. Can be selected.
  • the term hybrid database is sometimes used to mean that different types of DBM (SQL or NoSQL) can be used together, but the hybrid database here is slow like the above-mentioned on-disk and in-memory. It is limited to the meaning of using DB and high-speed DB together.
  • MySQL "16.3 The MEMORY Storage Engine”, [online], Internet ⁇ URL: https://dev.mysql.com/doc/refman/8.0/en/memory-storage-engine.html> SQLite, "In-Memory Databases", [online], Internet ⁇ URL: https://www.sqlite.org/inmemorydb.html>
  • the present invention has been made in view of the above points, and an object of the present invention is to increase the possibility of accessing an appropriate database in response to a request from a terminal.
  • the database selection device is determined by a determination unit that determines a delay requirement for the storage request and a determination unit that determines the delay requirement for the storage request based on the data storage request in the database transmitted from the terminal. It has a selection unit for selecting a database as a storage destination of the data from a plurality of databases based on a delay requirement.
  • FIG. 1 is a diagram showing an example of a system configuration according to the first embodiment.
  • the system shown in FIG. 1 includes a plurality of terminals 20 on an IP network, an application server 10, a DBM 30 (database management system), and the like.
  • the terminal 20 is an information processing device that transmits a data storage request or a data acquisition request to the application server 10.
  • the application server 10 is one or more computers that perform application processing, data storage in the DBM 30, and data acquisition from the DBM 30 in response to a request from the terminal 20.
  • the DBM 30 is one or more computers that manage a high-speed DB 31 which is a database having a relatively short access time and a low-speed DB 32 which is a database having a relatively long access time.
  • the DBM30 may be constructed using hybrid database technology.
  • the difference in access time is not limited to the difference in device type. Specifically, this embodiment can be applied even in a case where a database located near the network topology and a database located far away are used properly.
  • the application server 10 and the DBM 30 are represented by different figures, but the theory structure is not limited to this. Specifically, there are cases where the application server 10 and the DBM 30 exist as physically separate devices, and cases where the application server 10 and the DBM 30 exist logically separately in the physically same device.
  • the delay requirement for the request from the terminal 20 may differ depending on the request.
  • FIG. 2 is a diagram showing a hardware configuration example of the application server 10 according to the first embodiment.
  • the application server 10 of FIG. 2 has a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, and the like, which are connected to each other by a bus B, respectively.
  • the program that realizes the processing in the application server 10 is provided by a recording medium 101 such as a CD-ROM.
  • a recording medium 101 such as a CD-ROM.
  • the program is installed in the auxiliary storage device 102 from the recording medium 101 via the drive device 100.
  • the program does not necessarily have to be installed from the recording medium 101, and may be downloaded from another computer via the network.
  • the auxiliary storage device 102 stores the installed program and also stores necessary files, data, and the like.
  • the memory device 103 reads the program from the auxiliary storage device 102 and stores it when there is an instruction to start the program.
  • the CPU 104 executes the function related to the application server 10 according to the program stored in the memory device 103.
  • the interface device 105 is used as an interface for connecting to a network.
  • FIG. 3 is a diagram showing a functional configuration example of the application server 10 in the first embodiment.
  • the application server 10 includes a storage request receiving unit 11, a delay requirement determination unit 12, a storage destination DB selection unit 13, a data storage unit 14, an acquisition request receiving unit 15, a possession DB specifying unit 16, a data response unit 17, and the like.
  • Each of these parts is realized by a process of causing the CPU 104 to execute one or more programs installed in the application server 10.
  • the application server 10 also uses the delay requirement storage unit 121, the selection condition storage unit 122, and the like.
  • Each of these storage units can be realized by using, for example, an auxiliary storage device 102, a storage device that can be connected to the application server 10 via a network, or the like.
  • FIG. 4 is a flowchart for explaining an example of the processing procedure of the data storage processing in the first embodiment.
  • the delay requirement determination unit 12 refers to the delay requirement storage unit 121. Then, the delay requirement for the request (hereinafter referred to as “target request”) is determined (S102).
  • FIG. 5 is a diagram showing a configuration example of the delay requirement storage unit 121 in the first embodiment.
  • the delay requirement storage unit 121 of the first embodiment stores the delay requirement in association with the terminal ID of each terminal 20.
  • the record of the delay requirement storage unit 121 may be registered by a system administrator or the like.
  • the terminal ID is an arbitrary character string for identifying each terminal 20, and for example, the serial number of the terminal 20, IMEI, IMSI of the mobile network SIM, and the like can be considered.
  • the delay requirement may be, for example, a value (for example, 0 or 1) indicating two values of "low delay” and "non-low delay".
  • "non-low delay" means that low delay is not required.
  • the delay requirement determination unit 12 refers to the delay requirement storage unit 121 as shown in FIG. 5, and determines the delay requirement corresponding to the terminal ID assigned to the target request as the delay requirement of the target request. That is, the delay requirement associated with the terminal 20 that is the source of the target request is determined as the delay requirement of the target request.
  • the target terminal 20 transmits a data storage request to which the terminal ID is assigned to the application server 10. In the data storage request, the position where the terminal ID is stored depends on the implementation, but for example, the IMSI, IMEI, HTTP header portion, body portion, etc. of the mobile terminal can be considered.
  • the storage destination DB selection unit 13 is a database of storage destinations of data related to the target request based on the delay requirement determined by the delay requirement determination unit 12 and the information stored in the selection condition storage unit 122. Is selected (S103).
  • FIG. 6 is a diagram showing a configuration example of the selection condition storage unit 122 in the first embodiment.
  • the selection condition storage unit 122 stores the database identifier associated with the device access speed.
  • the value of the device access speed is 0 or 1.
  • 0 means low speed and 1 means high speed.
  • the database identifier refers to a value or character string used to distinguish between the high-speed DB 31 and the low-speed DB 32, such as a SQL table name.
  • the record of the selection condition storage unit 122 may be registered by a system administrator or the like.
  • the storage destination DB selection unit 13 selects a value indicating "high speed” as the device access speed and corresponds to the value. Select the database identifier as the storage destination identifier. On the other hand, if the delay requirement is a value indicating "non-low delay”, the storage destination DB selection unit 13 selects a value indicating "low speed” as the device access speed, and stores the database identifier corresponding to the value. Select as the identifier for.
  • the data storage unit 14 transmits the data related to the target request to the database related to the database identifier selected by the storage destination DB selection unit 13 (S104).
  • the data for which low delay is required is stored in the high-speed DB 31, the delay time is suppressed, and the data for which low delay is not required is stored in the low-speed DB 32, and the device cost is suppressed.
  • FIG. 7 is a flowchart for explaining an example of the processing procedure of the data acquisition processing in the first embodiment.
  • the acquisition request receiving unit 15 receives a data acquisition request from any terminal 20 (hereinafter referred to as "target terminal 20") (S201)
  • the possessed DB specifying unit 16 receives the data acquisition request (hereinafter referred to as "target terminal 20").
  • the database specifying process (hereinafter referred to as “retained DB specifying process”) from which the data related to the target request (hereinafter referred to as “target data”) is acquired is executed (hereinafter referred to as "retained DB specifying process”).
  • the index information (hereinafter referred to as "DB selection index") for associating the data primary key with the location of the data (high-speed DB31 or low-speed DB32) is provided by the application server 10 as the high-speed DB31. Created in the area.
  • the DB selection index is different from the index used for speeding up the database search process (hereinafter referred to as “search process speeding up index”).
  • search process speeding up index The data structure of the index for DB selection may be a B + tree, a hash index, or the like, similarly to the index for speeding up the search process.
  • the possessed DB specifying unit 16 refers to the DB selection index and identifies the database (held DB) holding the target data from the high-speed DB 31 and the low-speed DB 32.
  • the data response unit 17 acquires the data related to the target request from the database and sends the response including the data to the target terminal 20. Send (S204).
  • the data response unit 17 transmits a response indicating that the data does not exist to the target terminal 20 (S205). ).
  • the second embodiment will explain the differences from the first embodiment.
  • the points not particularly mentioned in the second embodiment may be the same as those in the first embodiment.
  • the terminal 20 transmits a data storage request including data to which a tag (identification information) associated with the delay requirement is attached to the application server 10.
  • the tag attached to the data is determined by the terminal 20 according to a predetermined naming convention (for example, a #LowLatency tag is attached to the data whose delay requirement is "low delay") and the delay requirement.
  • the naming convention is shared in advance between the terminal 20 and the application server 10.
  • step S101 of FIG. 4 the storage request receiving unit 11 receives the data storage request including the data tagged as described above (hereinafter referred to as “target data”).
  • the delay requirement determination unit 12 determines the delay requirement based on the tag attached to the target data.
  • the tag and the delay requirement may be associated and stored in the delay requirement storage unit 121.
  • the delay requirement determination unit 12 may determine the delay requirement with reference to the delay requirement storage unit 121.
  • the association between the tag and the delay requirement may be implemented as the logic of the delay requirement determination unit 12.
  • the third embodiment will explain the differences from the first or second embodiment.
  • the points not particularly mentioned in the third embodiment may be the same as those in the first or second embodiment.
  • the method of selecting the storage destination database in step S103 of FIG. 4 is different from each of the above embodiments.
  • the average access speed depends only on the device type, for example, when the high-speed DB 31 and the low-speed DB 32 are present on the same hardware, which is faster and which is slower. This is an effective method when it is obvious.
  • the database is distributed and deployed on a plurality of hardware such as a distributed database, it is difficult to grasp the average access speed in advance due to the hardware performance and network delay. Therefore, in the third embodiment, a method in which the periodic delay measurement is actually performed and the selection condition storage unit 122 is updated based on the result will be described.
  • the storage destination DB selection unit 13 accesses each database (high-speed DB 31 and low-speed DB 32) a plurality of times in advance (asynchronously with the data storage request), and measures the average access speed of each.
  • the storage destination DB selection unit 13 records information in which the database identifier of each database is associated with the average access speed of the database in the selection condition storage unit 122. Therefore, the selection condition storage unit 122 in the third embodiment has a configuration as shown in FIG.
  • the storage destination DB selection unit 13 measures the average access speed of each database every time a predetermined fixed time elapses. As a result of the measurement, when the low speed / high speed is switched, the selection condition storage unit 122 is updated by exchanging the data by performing mutual replication.
  • step S103 of FIG. 4 if the delay requirement determined by the delay requirement determination unit 12 is a value indicating "low delay”, the storage destination DB selection unit 13 has a higher average access speed in the selection condition storage unit 122. (In FIG. 8, the average access speed is "1") Select the database identifier of the record. On the other hand, if the delay requirement is a value indicating "non-low delay", the storage destination DB selection unit 13 has the lower average access speed in the selection condition storage unit 122 (the average access speed is "0" in FIG. 8). ) Select the database identifier for the record.
  • the data acquisition process of FIG. 7 is different from each of the above embodiments.
  • the fourth embodiment shows a method of enabling a high-speed response to a data acquisition request whose delay requirement is "low delay" without using the DB selection index.
  • FIG. 9 is a flowchart for explaining an example of the processing procedure of the data acquisition processing in the fourth embodiment.
  • the same steps as those in FIG. 7 are designated by the same reference numerals, and the description thereof will be omitted.
  • steps S202 and later in FIG. 7 are replaced with steps S211 and later.
  • step S211 the possessed DB specifying unit 16 first posts (sends) a search query corresponding to the data acquisition request to the high-speed DB 31. If there is data that matches the search query (Yes in S212), the data response unit 17 transmits a response including the data to the target terminal 20 (S213). On the other hand, when there is no data matching the search query (No in S212), the possessed DB specifying unit 16 posts the search query to the low-speed DB 32 (S214). If there is data that matches the search query (Yes in S215), the data response unit 17 transmits a response including the data to the target terminal 20 (S216).
  • the data response unit 17 transmits a response indicating that the data does not exist to the target terminal 20 (S217).
  • the high-speed DB 31 is preferentially specified as the database of the data acquisition source.
  • the time until the data stored in the low-speed DB 32 is acquired increases, but there is an advantage that the implementation is easy.
  • the fifth embodiment will explain the differences from the fourth embodiment.
  • the points not particularly mentioned in the fifth embodiment may be the same as those in the fourth embodiment.
  • the method of specifying the possessed DB is different from the fourth embodiment.
  • the time until the data stored in the low-speed DB 32 is acquired increases.
  • a method of preventing an increase in the data acquisition time from the low-speed DB 32 by posting the search query to the low-speed DB 32 speculatively at the same time as posting the search query to the high-speed DB 31 will be shown.
  • the number of search queries in the entire system increases and the processing load increases, there is an advantage that the implementation is easy and the increase in data acquisition time from the low-speed DB 32 can be prevented.
  • FIG. 10 is a flowchart for explaining an example of the processing procedure of the data acquisition processing in the fifth embodiment.
  • the same steps as those in FIG. 9 are designated by the same reference numerals, and the description thereof will be omitted.
  • steps S211 and later in FIG. 9 are replaced with steps S221 and later.
  • step S211 the possessed DB specifying unit 16 posts the search query corresponding to the data acquisition request to both the high-speed DB 31 and the low-speed DB 32 at the same time (in parallel).
  • the data response unit 17 transmits a response including the data to the target terminal 20 (S223).
  • the data response unit 17 transmits a response including the data to the target terminal 20 when the data is first acquired.
  • the data response unit 17 transmits a response indicating that the data does not exist to the target terminal 20 (S225).
  • the sixth embodiment will explain the differences from the fifth embodiment.
  • the points not particularly mentioned in the sixth embodiment may be the same as those in the fifth embodiment.
  • the method of specifying the possessed DB is different from the fifth embodiment.
  • the number of search queries in the entire system increases and the processing load increases. Therefore, in the sixth embodiment, a method of determining the delay requirement for each data at the time of data acquisition as well as at the time of data storage and transmitting the search query to only one of the high-speed DB 31 and the low-speed DB 32 will be described.
  • the method for identifying the delay requirement may be the same as the method for storing data.
  • FIG. 11 is a flowchart for explaining an example of the processing procedure of the data acquisition processing in the sixth embodiment.
  • the same steps as those in FIG. 10 are designated by the same reference numerals, and the description thereof will be omitted.
  • step S221 and subsequent steps in FIG. 10 are replaced with steps S231 and subsequent steps.
  • step S231 the possession DB specifying unit 16 determines the delay requirement of the data acquisition request.
  • the method for determining the delay requirement may be the same as the method described in the first embodiment or the second embodiment.
  • the possessed DB specifying unit 16 posts a search query corresponding to the data acquisition request to the high-speed DB 31 (S233). If there is data that matches the search query (Yes in S234), the data response unit 17 transmits a response including the data to the target terminal 20 (S235). On the other hand, when there is no data matching the search query (No in S234), or when the determination result by the possessed DB specifying unit 16 is "non-low delay" (No in S232), the possessed DB specifying unit 16 is the low-speed DB 32. Post the search query to (S236).
  • the data response unit 17 transmits a response including the data to the target terminal 20 (S238).
  • the data response unit 17 transmits a response indicating that the data does not exist to the target terminal 20 (S239).
  • the application server 10 is an example of a database selection device.
  • the delay requirement determination unit 12 is an example of the determination unit.
  • the storage destination DB selection unit 13 is an example of the selection unit.
  • the possessed DB specific unit 16 is an example of the specific unit.
  • the data response unit 17 is an example of a response unit.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing 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

A database selection device has: a determination unit for determining, on the basis of a storing request of data into a database, which is transmitted from a terminal, a delay requirement for the storing request; and a selection unit for selecting, on the basis of the delay requirement determined by the determination unit, a database as a storing destination of the data from among a plurality of databases, thereby increasing a possibility of access to an appropriate database in response to the request from the terminal.

Description

データベース選択装置、データベース選択方法及びプログラムDatabase selection device, database selection method and program
　本発明は、データベース選択装置、データベース選択方法及びプログラムに関する。 The present invention relates to a database selection device, a database selection method and a program.
　データベースマネジメントシステム（以下「ＤＢＭ」という。）の応答にかかる時間は、主にデータの検索アルゴリズムとストレージデバイスへのアクセス時間からなる。ここではストレージデバイスへのアクセス時間について考える。 The time required for the response of the database management system (hereinafter referred to as "DBM") mainly consists of the data search algorithm and the access time to the storage device. Here, consider the access time to the storage device.
　既存技術として、ストレージデバイスのアクセス時間を考慮した方式として、オンディスクデータベース、インメモリデータベース及びハイブリッドデータベースが存在する。 As an existing technology, there are on-disk database, in-memory database and hybrid database as a method considering the access time of the storage device.
　オンディスクデータベースとは、データをＨＤＤ等のディスクストレージ機構で管理する方式であり、インメモリデータベースに比べて装置コストを抑制できる一方、アクセス時間が長い（数ミリ秒～数十ミリ秒）という特性を有する。 The on-disk database is a method in which data is managed by a disk storage mechanism such as an HDD, and while the device cost can be suppressed compared to an in-memory database, the access time is long (several milliseconds to several tens of milliseconds). Has.
　インメモリデータベースは、データをメインメモリ等のメモリ上で管理する方式であり、オンディスクデータベースに比べてアクセス時間が短い（数ナノ秒）一方、装置コストが高いという特性を有する。 The in-memory database is a method of managing data on memory such as main memory, and has the characteristic that the access time is shorter (several nanoseconds) than the on-disk database, but the equipment cost is high.
　ハイブリッドデータベースは、オンディスクデータベースとインメモリデータベースを併用してデータを管理する方式であり、ＭｙＳＱＬ（非特許文献１）やＳＱＬｉｔｅ（非特許文献２）では、テーブル単位でオンディスクデータベースとインメモリデータベースを選択可能である。なお、ハイブリッドデータベースという用語は、異なる種類のＤＢＭ（ＳＱＬやＮｏＳＱＬ）を併用可能という意味で使われることもあるが、ここでのハイブリッドデータベースは、上述のオンディスクとインメモリのように、低速なＤＢと高速なＤＢの併用という意味に限定される。 The hybrid database is a method of managing data by using both an on-disk database and an in-memory database. In MySQL (Non-Patent Document 1) and SQLite (Non-Patent Document 2), the on-disk database and the in-memory database are stored in table units. Can be selected. The term hybrid database is sometimes used to mean that different types of DBM (SQL or NoSQL) can be used together, but the hybrid database here is slow like the above-mentioned on-disk and in-memory. It is limited to the meaning of using DB and high-speed DB together.
　従来技術のハイブリットＤＢにおいては、データを扱うアプリケーション、すなわちＤＢＭにクエリを送信するクライアント（データベースクライアント）がデータ格納に使用する方式（データベース）を選択する必要があった。この場合、ＩＰネットワークの端末からのクエリでは、アクセス先のデータベースとして、ネットワークによる遅延や、分散ＤＢによるハードウェア性能による差なども考慮した適切なデータベースの選択が困難であるという問題が有った。 In the hybrid DB of the prior art, it was necessary to select a method (database) used for data storage by an application that handles data, that is, a client (database client) that sends a query to DBM. In this case, in the query from the terminal of the IP network, there is a problem that it is difficult to select an appropriate database as the access destination database in consideration of the delay due to the network and the difference due to the hardware performance due to the distributed DB. ..
　本発明は、上記の点に鑑みてなされたものであって、端末からの要求に対して適切なデータベースへのアクセスの可能性を高めることを目的とする。 The present invention has been made in view of the above points, and an object of the present invention is to increase the possibility of accessing an appropriate database in response to a request from a terminal.
　そこで上記課題を解決するため、データベース選択装置は、端末から送信される、データベースへのデータの格納要求に基づいて、前記格納要求に対する遅延要件を判定する判定部と、前記判定部によって判定された遅延要件に基づいて、複数のデータベースの中から前記データの格納先とするデータベースを選択する選択部と、を有する。 Therefore, in order to solve the above problem, the database selection device is determined by a determination unit that determines a delay requirement for the storage request and a determination unit that determines the delay requirement for the storage request based on the data storage request in the database transmitted from the terminal. It has a selection unit for selecting a database as a storage destination of the data from a plurality of databases based on a delay requirement.
　端末からの要求に対して適切なデータベースへのアクセスの可能性を高めることができる。 It is possible to increase the possibility of accessing an appropriate database in response to a request from the terminal.
第１の実施の形態におけるシステム構成例を示す図である。It is a figure which shows the system configuration example in 1st Embodiment. 第１の実施の形態におけるアプリケーションサーバ１０のハードウェア構成例を示す図である。It is a figure which shows the hardware configuration example of the application server 10 in 1st Embodiment. 第１の実施の形態におけるアプリケーションサーバ１０の機能構成例を示す図である。It is a figure which shows the functional configuration example of the application server 10 in 1st Embodiment. 第１の実施の形態におけるデータ格納処理の処理手順の一例を説明するためのフローチャートである。It is a flowchart for demonstrating an example of the processing procedure of the data storage process in 1st Embodiment. 第１の実施の形態における遅延要件記憶部１２１の構成例を示す図である。It is a figure which shows the structural example of the delay requirement storage part 121 in 1st Embodiment. 第１の実施の形態における選択条件記憶部１２２の構成例を示す図である。It is a figure which shows the structural example of the selection condition storage part 122 in 1st Embodiment. 第１の実施の形態におけるデータ取得処理の処理手順の一例を説明するためのフローチャートである。It is a flowchart for demonstrating an example of the processing procedure of the data acquisition processing in 1st Embodiment. 第３の実施の形態における選択条件記憶部１２２の構成例を示す図である。It is a figure which shows the structural example of the selection condition storage part 122 in 3rd Embodiment. 第４の実施の形態におけるデータ取得処理の処理手順の一例を説明するためのフローチャートである。It is a flowchart for demonstrating an example of the processing procedure of the data acquisition processing in 4th Embodiment. 第５の実施の形態におけるデータ取得処理の処理手順の一例を説明するためのフローチャートである。It is a flowchart for demonstrating an example of the processing procedure of the data acquisition processing in 5th Embodiment. 第６の実施の形態におけるデータ取得処理の処理手順の一例を説明するためのフローチャートである。It is a flowchart for demonstrating an example of the processing procedure of the data acquisition processing in the 6th Embodiment.
　以下、図面に基づいて本発明の実施の形態を説明する。図１は、第１の実施の形態におけるシステム構成例を示す図である。図１に示されるシステムは、ＩＰネットワーク上の複数の端末２０、アプリケーションサーバ１０、及びＤＢＭ３０（データベースマネジメントシステム）等を含む。 Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram showing an example of a system configuration according to the first embodiment. The system shown in FIG. 1 includes a plurality of terminals 20 on an IP network, an application server 10, a DBM 30 (database management system), and the like.
　端末２０は、アプリケーションサーバ１０に対して、データ格納要求又はデータ取得要求を送信する情報処理装置である。 The terminal 20 is an information processing device that transmits a data storage request or a data acquisition request to the application server 10.
　アプリケーションサーバ１０は、端末２０からの要求に応じて、アプリケーション処理やＤＢＭ３０へのデータ格納やＤＢＭ３０からのデータ取得を行う１以上のコンピュータである。 The application server 10 is one or more computers that perform application processing, data storage in the DBM 30, and data acquisition from the DBM 30 in response to a request from the terminal 20.
　ＤＢＭ３０は、アクセス時間が相対的に短いデータベースである高速ＤＢ３１と、アクセス時間が相対的に長いデータベースである低速ＤＢ３２とを管理する１以上のコンピュータである。ＤＢＭ３０は、ハイブリッドデータベースの技術を用いて構築されてもよい。 The DBM 30 is one or more computers that manage a high-speed DB 31 which is a database having a relatively short access time and a low-speed DB 32 which is a database having a relatively long access time. The DBM30 may be constructed using hybrid database technology.
　なお、本実施の形態では、アクセス時間の違いをデバイス種別の違いだけに限定しない。具体的には、ネットワークトポロジ的に近傍にあるデータベースと遠方にあるデータベースを使い分けるようなケースにおいても、本実施の形態は適用できる。 In this embodiment, the difference in access time is not limited to the difference in device type. Specifically, this embodiment can be applied even in a case where a database located near the network topology and a database located far away are used properly.
　また、図１では、アプリケーションサーバ１０とＤＢＭ３０とが別の図形で表現されているが、論物構成はこれに限定されない。具体的にはアプリケーションサーバ１０及びＤＢＭ３０が物理的に別の装置として存在する場合と、物理的に同一な装置内でそれぞれが論理的に分かれて存在する場合とが考えられる。 Further, in FIG. 1, the application server 10 and the DBM 30 are represented by different figures, but the theory structure is not limited to this. Specifically, there are cases where the application server 10 and the DBM 30 exist as physically separate devices, and cases where the application server 10 and the DBM 30 exist logically separately in the physically same device.
　本実施の形態では、端末２０からの要求に対する遅延要件が、要求によって異なりうる場合が想定される。 In this embodiment, it is assumed that the delay requirement for the request from the terminal 20 may differ depending on the request.
　図２は、第１の実施の形態におけるアプリケーションサーバ１０のハードウェア構成例を示す図である。図２のアプリケーションサーバ１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。 FIG. 2 is a diagram showing a hardware configuration example of the application server 10 according to the first embodiment. The application server 10 of FIG. 2 has a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, and the like, which are connected to each other by a bus B, respectively.
　アプリケーションサーバ１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。 The program that realizes the processing in the application server 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 storing the program is set in the drive device 100, the program is installed in the auxiliary storage device 102 from the recording medium 101 via the drive device 100. However, the program does not necessarily have to be installed from the recording medium 101, and may be downloaded from another computer via the network. The auxiliary storage device 102 stores the installed program and also stores necessary files, data, and the like.
　メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってアプリケーションサーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。 The memory device 103 reads the program from the auxiliary storage device 102 and stores it when there is an instruction to start the program. The CPU 104 executes the function related to the application server 10 according to the program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network.
　図３は、第１の実施の形態におけるアプリケーションサーバ１０の機能構成例を示す図である。図３において、アプリケーションサーバ１０は、格納要求受信部１１、遅延要件判定部１２、格納先ＤＢ選択部１３、データ格納部１４、取得要求受信部１５、保有ＤＢ特定部１６及びデータ応答部１７等を有する。これら各部は、アプリケーションサーバ１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。アプリケーションサーバ１０は、また、遅延要件記憶部１２１及び選択条件記憶部１２２等を利用する。これら各記憶部は、例えば、補助記憶装置１０２、又はアプリケーションサーバ１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。 FIG. 3 is a diagram showing a functional configuration example of the application server 10 in the first embodiment. In FIG. 3, the application server 10 includes a storage request receiving unit 11, a delay requirement determination unit 12, a storage destination DB selection unit 13, a data storage unit 14, an acquisition request receiving unit 15, a possession DB specifying unit 16, a data response unit 17, and the like. Has. Each of these parts is realized by a process of causing the CPU 104 to execute one or more programs installed in the application server 10. The application server 10 also uses the delay requirement storage unit 121, the selection condition storage unit 122, and the like. Each of these storage units can be realized by using, for example, an auxiliary storage device 102, a storage device that can be connected to the application server 10 via a network, or the like.
　以下、アプリケーションサーバ１０が実行する処理手順について説明する。図４は、第１の実施の形態におけるデータ格納処理の処理手順の一例を説明するためのフローチャートである。 Hereinafter, the processing procedure executed by the application server 10 will be described. FIG. 4 is a flowchart for explaining an example of the processing procedure of the data storage processing in the first embodiment.
　格納要求受信部１１が、いずれかの端末２０（以下、「対象端末２０」という。）からのデータ格納要求を受信すると（Ｓ１０１）、遅延要件判定部１２は、遅延要件記憶部１２１を参照して、当該要求（以下、「対象要求」という。）に対する遅延要件を判定する（Ｓ１０２）。 When the storage request receiving unit 11 receives the data storage request from any terminal 20 (hereinafter referred to as "target terminal 20") (S101), the delay requirement determination unit 12 refers to the delay requirement storage unit 121. Then, the delay requirement for the request (hereinafter referred to as “target request”) is determined (S102).
　図５は、第１の実施の形態における遅延要件記憶部１２１の構成例を示す図である。図５に示されるように、第１の実施の形態の遅延要件記憶部１２１には、各端末２０の端末ＩＤに対応付けられて遅延要件が記憶されている。例えば、システム管理者等によって遅延要件記憶部１２１のレコードが登録されてもよい。なお、端末ＩＤは、各端末２０を識別するための任意の文字列であり、例えば、端末２０の製造番号やＩＭＥＩ、モバイル網ＳＩＭのＩＭＳＩなどが考えられる。また、遅延要件は、例えば、「低遅延」、「非低遅延」の２値を示す値（例えば、０又は１）であってもよい。なお、「非低遅延」は、低遅延を求めないことをいう。 FIG. 5 is a diagram showing a configuration example of the delay requirement storage unit 121 in the first embodiment. As shown in FIG. 5, the delay requirement storage unit 121 of the first embodiment stores the delay requirement in association with the terminal ID of each terminal 20. For example, the record of the delay requirement storage unit 121 may be registered by a system administrator or the like. The terminal ID is an arbitrary character string for identifying each terminal 20, and for example, the serial number of the terminal 20, IMEI, IMSI of the mobile network SIM, and the like can be considered. Further, the delay requirement may be, for example, a value (for example, 0 or 1) indicating two values of "low delay" and "non-low delay". In addition, "non-low delay" means that low delay is not required.
　遅延要件判定部１２は、図５に示されるような遅延要件記憶部１２１を参照して、対象要求に付与されている端末ＩＤに対応する遅延要件を、対象要求の遅延要件と判定する。すなわち、対象要求の送信元の端末２０に関連付けられた遅延要件が対象要求の遅延要件として判定される。なお、対象端末２０は、端末ＩＤが付与されたデータ格納要求をアプリケーションサーバ１０へ送信する。データ格納要求において、端末ＩＤが格納される位置は実装に依存するが、例えば、モバイル端末のＩＭＳＩやＩＭＥＩ、ＨＴＴＰのヘッダ部やボディ部等が考えられる。 The delay requirement determination unit 12 refers to the delay requirement storage unit 121 as shown in FIG. 5, and determines the delay requirement corresponding to the terminal ID assigned to the target request as the delay requirement of the target request. That is, the delay requirement associated with the terminal 20 that is the source of the target request is determined as the delay requirement of the target request. The target terminal 20 transmits a data storage request to which the terminal ID is assigned to the application server 10. In the data storage request, the position where the terminal ID is stored depends on the implementation, but for example, the IMSI, IMEI, HTTP header portion, body portion, etc. of the mobile terminal can be considered.
　続いて、格納先ＤＢ選択部１３は、遅延要件判定部１２によって判定された遅延要件と、選択条件記憶部１２２に記憶されている情報とに基づいて、対象要求に係るデータの格納先のデータベースを選択する（Ｓ１０３）。 Subsequently, the storage destination DB selection unit 13 is a database of storage destinations of data related to the target request based on the delay requirement determined by the delay requirement determination unit 12 and the information stored in the selection condition storage unit 122. Is selected (S103).
　図６は、第１の実施の形態における選択条件記憶部１２２の構成例を示す図である。図６に示されるように、第２の実施の形態において、選択条件記憶部１２２には、デバイスアクセス速度に対応付けられてデータベース識別子が記憶されている。デバイスアクセス速度の値は、０又は１である。０は低速を意味し、１は高速を意味する。データベース識別子は、ＳＱＬのテーブル名といった、高速ＤＢ３１と低速ＤＢ３２とを識別するために使用される値又は文字列をいう。例えば、システム管理者等によって選択条件記憶部１２２のレコードが登録されてもよい。 FIG. 6 is a diagram showing a configuration example of the selection condition storage unit 122 in the first embodiment. As shown in FIG. 6, in the second embodiment, the selection condition storage unit 122 stores the database identifier associated with the device access speed. The value of the device access speed is 0 or 1. 0 means low speed and 1 means high speed. The database identifier refers to a value or character string used to distinguish between the high-speed DB 31 and the low-speed DB 32, such as a SQL table name. For example, the record of the selection condition storage unit 122 may be registered by a system administrator or the like.
　格納先ＤＢ選択部１３は、遅延要件判定部１２によって判定された遅延要件が「低遅延」を示す値であれば、デバイスアクセス速度として「高速」を示す値を選択し、当該値に対応するデータベース識別子を格納先の識別子として選択する。一方、当該遅延要件が「非低遅延」を示す値であれば、格納先ＤＢ選択部１３は、デバイスアクセス速度として「低速」を示す値を選択し、該値に対応するデータベース識別子を格納先の識別子として選択する。 If the delay requirement determined by the delay requirement determination unit 12 is a value indicating "low delay", the storage destination DB selection unit 13 selects a value indicating "high speed" as the device access speed and corresponds to the value. Select the database identifier as the storage destination identifier. On the other hand, if the delay requirement is a value indicating "non-low delay", the storage destination DB selection unit 13 selects a value indicating "low speed" as the device access speed, and stores the database identifier corresponding to the value. Select as the identifier for.
　続いて、データ格納部１４は、格納先ＤＢ選択部１３が選択したデータベース識別子に係るデータベースに対して対象要求に係るデータを送信する（Ｓ１０４）。その結果、低遅延性が求められるデータは高速ＤＢ３１に格納されて、遅延時間が抑制され、低遅延性が求められないデータは低速ＤＢ３２に格納されて、装置コストが抑制される。 Subsequently, the data storage unit 14 transmits the data related to the target request to the database related to the database identifier selected by the storage destination DB selection unit 13 (S104). As a result, the data for which low delay is required is stored in the high-speed DB 31, the delay time is suppressed, and the data for which low delay is not required is stored in the low-speed DB 32, and the device cost is suppressed.
　次に、データ取得処理について説明する。図７は、第１の実施の形態におけるデータ取得処理の処理手順の一例を説明するためのフローチャートである。 Next, the data acquisition process will be described. FIG. 7 is a flowchart for explaining an example of the processing procedure of the data acquisition processing in the first embodiment.
　取得要求受信部１５が、いずれかの端末２０（以下、「対象端末２０」という。）からのデータ取得要求を受信すると（Ｓ２０１）、保有ＤＢ特定部１６は、当該データ取得要求（以下、「対象要求」という。）に基づいて、対象要求に係るデータ（以下、「対象データ」という。）の取得元とするデータベースの特定処理（以下、「保有ＤＢ特定処理」という。）を実行する（Ｓ２０２）。 When the acquisition request receiving unit 15 receives a data acquisition request from any terminal 20 (hereinafter referred to as "target terminal 20") (S201), the possessed DB specifying unit 16 receives the data acquisition request (hereinafter referred to as "target terminal 20"). Based on the "target request"), the database specifying process (hereinafter referred to as "retained DB specifying process") from which the data related to the target request (hereinafter referred to as "target data") is acquired is executed (hereinafter referred to as "retained DB specifying process"). S202).
　第１の実施の形態では、データの主キーとデータの所在（高速ＤＢ３１又は低速ＤＢ３２）を紐づけるためのインデックス情報（以下、「ＤＢ選択用インデックス」という。）が、アプリケーションサーバ１０によって高速ＤＢ３１領域に作成されている。なお、ＤＢ選択用インデックスは、データベースの検索処理の高速化に用いられるインデックス（以下、「検索処理高速化用インデックス」という。）とは別のものである。ＤＢ選択用インデックスのデータ構造は、検索処理高速化用インデックスと同様に、Ｂ＋木やハッシュインデックスなどでよい。 In the first embodiment, the index information (hereinafter referred to as "DB selection index") for associating the data primary key with the location of the data (high-speed DB31 or low-speed DB32) is provided by the application server 10 as the high-speed DB31. Created in the area. The DB selection index is different from the index used for speeding up the database search process (hereinafter referred to as "search process speeding up index"). The data structure of the index for DB selection may be a B + tree, a hash index, or the like, similarly to the index for speeding up the search process.
　保有ＤＢ特定処理において、保有ＤＢ特定部１６は、ＤＢ選択用インデックスを参照して、対象データを保有するデータベース（保有ＤＢ）を高速ＤＢ３１及び低速ＤＢ３２の中から特定する。 In the possessed DB specifying process, the possessed DB specifying unit 16 refers to the DB selection index and identifies the database (held DB) holding the target data from the high-speed DB 31 and the low-speed DB 32.
　ＤＢ選択用インデックスから対象データを保有するデータベースが特定できた場合（Ｓ２０３でＹｅｓ）、データ応答部１７は、当該データベースから対象要求に係るデータを取得し、当該データを含む応答を対象端末２０へ送信する（Ｓ２０４）。一方、ＤＢ選択用インデックスに一致する情報が無く、対象データを特定できなかった場合（Ｓ２０３でＮｏ）、データ応答部１７は、データが存在しないことを示す応答を対象端末２０へ送信する（Ｓ２０５）。 When the database holding the target data can be identified from the DB selection index (Yes in S203), the data response unit 17 acquires the data related to the target request from the database and sends the response including the data to the target terminal 20. Send (S204). On the other hand, when there is no information matching the DB selection index and the target data cannot be specified (No in S203), the data response unit 17 transmits a response indicating that the data does not exist to the target terminal 20 (S205). ).
　次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。 Next, the second embodiment will be described. The second embodiment will explain the differences from the first embodiment. The points not particularly mentioned in the second embodiment may be the same as those in the first embodiment.
　第２の実施の形態では、図４のステップＳ１０２における遅延要件の判定方法が第１の実施の形態と異なる。第１の実施の形態における、端末ＩＤに基づく遅延要件の判定方法は、端末２０と遅延要件が１：１で対応する場合に有効となるが、同一の端末２０から遅延要件の異なる複数の要求が送信される場面には対応できない。第２の実施の形態では、同一の端末２０から遅延要件の異なる複数の要求が送信される場面に対応可能とする方法について説明する。 In the second embodiment, the method of determining the delay requirement in step S102 of FIG. 4 is different from that of the first embodiment. The method for determining the delay requirement based on the terminal ID in the first embodiment is effective when the terminal 20 and the delay requirement correspond 1: 1 but a plurality of requests having different delay requirements from the same terminal 20. Cannot be handled when is sent. In the second embodiment, a method of making it possible to handle a situation in which a plurality of requests having different delay requirements are transmitted from the same terminal 20 will be described.
　第２の実施の形態において、端末２０は、遅延要件に紐づくタグ（識別情報）が付与されたデータを含むデータ格納要求をアプリケーションサーバ１０へ送信する。データに付与されるタグは、予め定められた命名規則（例えば、遅延要件が「低遅延」であるデータには＃ＬｏｗＬａｔｅｎｃｙタグが付与される等）と遅延要件に従って端末２０によって決定される。命名規則は事前に端末２０とアプリケーションサーバ１０との間で共有される。 In the second embodiment, the terminal 20 transmits a data storage request including data to which a tag (identification information) associated with the delay requirement is attached to the application server 10. The tag attached to the data is determined by the terminal 20 according to a predetermined naming convention (for example, a #LowLatency tag is attached to the data whose delay requirement is "low delay") and the delay requirement. The naming convention is shared in advance between the terminal 20 and the application server 10.
　したがって、格納要求受信部１１は、図４のステップＳ１０１において、上記のようなタグが付与されたデータ（以下、「対象データ」という。）を含むデータ格納要求を受信する。 Therefore, in step S101 of FIG. 4, the storage request receiving unit 11 receives the data storage request including the data tagged as described above (hereinafter referred to as “target data”).
　ステップＳ１０２において、遅延要件判定部１２は、対象データに付与されたタグに基づいて、遅延要件を判定する。例えば、第２の実施の形態では、タグと遅延要件とが対応付けられて遅延要件記憶部１２１に記憶されていてもよい。この場合、遅延要件判定部１２は、遅延要件記憶部１２１を参照して遅延要件を判定すればよい。又は、タグと遅延要件との対応付けは、遅延要件判定部１２のロジックとして実装されていてもよい。 In step S102, the delay requirement determination unit 12 determines the delay requirement based on the tag attached to the target data. For example, in the second embodiment, the tag and the delay requirement may be associated and stored in the delay requirement storage unit 121. In this case, the delay requirement determination unit 12 may determine the delay requirement with reference to the delay requirement storage unit 121. Alternatively, the association between the tag and the delay requirement may be implemented as the logic of the delay requirement determination unit 12.
　その他は、第１の実施の形態と同様でよい。 Others may be the same as in the first embodiment.
　次に、第３の実施の形態について説明する。第３の実施の形態では第１又は第２の実施の形態と異なる点について説明する。第３の実施の形態において特に言及されない点については、第１又は第２の実施の形態と同様でもよい。 Next, the third embodiment will be described. The third embodiment will explain the differences from the first or second embodiment. The points not particularly mentioned in the third embodiment may be the same as those in the first or second embodiment.
　第３の実施の形態では、図４のステップＳ１０３における格納先のデータベースの選択方法が上記各実施の形態と異なる。上記各実施の形態における選択方法は、例えば、高速ＤＢ３１及び低速ＤＢ３２が同一ハードウェア上に存在する場合のように、平均アクセス速度がデバイス種別のみに依存し、どちらが高速であり、どちらが低速であるかが自明な場合に有効な方法である。一方、分散データベースのように、データベースが複数のハードウェアに分散配備される環境では、ハードウェアの性能やネットワーク遅延により平均アクセス速度を事前に把握することは難しい。そこで、第３の実施の形態では、実際に定期的な遅延測定が行われ、その結果に基づいて選択条件記憶部１２２が更新される方法について示す。 In the third embodiment, the method of selecting the storage destination database in step S103 of FIG. 4 is different from each of the above embodiments. In the selection method in each of the above embodiments, the average access speed depends only on the device type, for example, when the high-speed DB 31 and the low-speed DB 32 are present on the same hardware, which is faster and which is slower. This is an effective method when it is obvious. On the other hand, in an environment where the database is distributed and deployed on a plurality of hardware such as a distributed database, it is difficult to grasp the average access speed in advance due to the hardware performance and network delay. Therefore, in the third embodiment, a method in which the periodic delay measurement is actually performed and the selection condition storage unit 122 is updated based on the result will be described.
　例えば、格納先ＤＢ選択部１３は、事前に（データ格納要求とは非同期に）各データベース（高速ＤＢ３１及び低速ＤＢ３２）に複数回アクセスし、それぞれの平均アクセス速度を測定する。格納先ＤＢ選択部１３は、各データベースのデータベース識別子に当該データベースの平均アクセス速度を対応付けた情報を選択条件記憶部１２２に記録する。したがって、第３の実施の形態における選択条件記憶部１２２は、図８に示されるような構成を有する。格納先ＤＢ選択部１３は、予め定めた一定時間が経過するごとに各データベースの平均アクセス速度を測定する。測定の結果、低速／高速が入れ替わった場合は相互にレプリケーションを行うことでデータを入れ替えることで、選択条件記憶部１２２を更新する。 For example, the storage destination DB selection unit 13 accesses each database (high-speed DB 31 and low-speed DB 32) a plurality of times in advance (asynchronously with the data storage request), and measures the average access speed of each. The storage destination DB selection unit 13 records information in which the database identifier of each database is associated with the average access speed of the database in the selection condition storage unit 122. Therefore, the selection condition storage unit 122 in the third embodiment has a configuration as shown in FIG. The storage destination DB selection unit 13 measures the average access speed of each database every time a predetermined fixed time elapses. As a result of the measurement, when the low speed / high speed is switched, the selection condition storage unit 122 is updated by exchanging the data by performing mutual replication.
　図４のステップＳ１０３において、格納先ＤＢ選択部１３は、遅延要件判定部１２によって判定された遅延要件が「低遅延」を示す値であれば、選択条件記憶部１２２において平均アクセス速度が高い方の（図８において平均アクセス速度が「１」である。）レコードのデータベース識別子を選択する。一方、当該遅延要件が「非低遅延」を示す値であれば、格納先ＤＢ選択部１３は、選択条件記憶部１２２において平均アクセス速度が低い方の（図８において平均アクセス速度が「０」である。）レコードのデータベース識別子を選択する。 In step S103 of FIG. 4, if the delay requirement determined by the delay requirement determination unit 12 is a value indicating "low delay", the storage destination DB selection unit 13 has a higher average access speed in the selection condition storage unit 122. (In FIG. 8, the average access speed is "1") Select the database identifier of the record. On the other hand, if the delay requirement is a value indicating "non-low delay", the storage destination DB selection unit 13 has the lower average access speed in the selection condition storage unit 122 (the average access speed is "0" in FIG. 8). ) Select the database identifier for the record.
　その他は上記各実施の形態と同様でよい。 Others may be the same as in each of the above embodiments.
　次に、第４の実施の形態について説明する。第４の実施の形態では上記各実施の形態と異なる点について説明する。第４の実施の形態において特に言及されない点については、上記各実施の形態と同様でもよい。 Next, the fourth embodiment will be described. In the fourth embodiment, the points different from each of the above embodiments will be described. The points not particularly mentioned in the fourth embodiment may be the same as those in the above-described embodiments.
　第４の実施の形態では、図７のデータ取得処理が上記各実施の形態と異なる。 In the fourth embodiment, the data acquisition process of FIG. 7 is different from each of the above embodiments.
　上記したＤＢ選択用インデックスによる保有ＤＢの特定方法は、目的のデータを検索する前にＤＢ選択用インデックスの検索が実行されるため、応答までに当該検索の分の時間が増加する。そこで、第４の実施の形態では、ＤＢ選択用インデックスを用いず、かつ、遅延要件が「低遅延」であるデータ取得要求に対しては高速な応答を可能とする方法を示す。 In the above-mentioned method of specifying the retained DB by the DB selection index, since the search of the DB selection index is executed before the target data is searched, the time for the search is increased by the time of the response. Therefore, the fourth embodiment shows a method of enabling a high-speed response to a data acquisition request whose delay requirement is "low delay" without using the DB selection index.
　図９は、第４の実施の形態におけるデータ取得処理の処理手順の一例を説明するためのフローチャートである。図９中、図７と同一ステップには同一符号を付し、その説明は省略する。図９では、図７のステップＳ２０２以降がステップＳ２１１以降に置き換わる。 FIG. 9 is a flowchart for explaining an example of the processing procedure of the data acquisition processing in the fourth embodiment. In FIG. 9, the same steps as those in FIG. 7 are designated by the same reference numerals, and the description thereof will be omitted. In FIG. 9, steps S202 and later in FIG. 7 are replaced with steps S211 and later.
　ステップＳ２１１において、保有ＤＢ特定部１６は、まず、高速ＤＢ３１に対してデータ取得要求に応じた検索クエリをポスト（送信）する。検索クエリに一致するデータが有れば（Ｓ２１２でＹｅｓ）、データ応答部１７は、当該データを含む応答を対象端末２０へ送信する（Ｓ２１３）。一方、検索クエリに一致するデータが無い場合（Ｓ２１２でＮｏ）、保有ＤＢ特定部１６は、低速ＤＢ３２に検索クエリをポストする（Ｓ２１４）。検索クエリに一致するデータがあれば（Ｓ２１５でＹｅｓ）、データ応答部１７は、当該データを含む応答を対象端末２０へ送信する（Ｓ２１６）。検索クエリに一致するデータが無い場合（Ｓ２１５でＮｏ）、データ応答部１７は、データが存在しないことを示す応答を対象端末２０へ送信する（Ｓ２１７）。このように、第４の実施の形態では、高速ＤＢ３１が優先的にデータの取得元のデータベースとして特定される。 In step S211 the possessed DB specifying unit 16 first posts (sends) a search query corresponding to the data acquisition request to the high-speed DB 31. If there is data that matches the search query (Yes in S212), the data response unit 17 transmits a response including the data to the target terminal 20 (S213). On the other hand, when there is no data matching the search query (No in S212), the possessed DB specifying unit 16 posts the search query to the low-speed DB 32 (S214). If there is data that matches the search query (Yes in S215), the data response unit 17 transmits a response including the data to the target terminal 20 (S216). When there is no data matching the search query (No in S215), the data response unit 17 transmits a response indicating that the data does not exist to the target terminal 20 (S217). As described above, in the fourth embodiment, the high-speed DB 31 is preferentially specified as the database of the data acquisition source.
　第４の実施の形態では、低速ＤＢ３２に格納されたデータを取得するまでの時間は増加するが、実装が簡単であるという長所がある。 In the fourth embodiment, the time until the data stored in the low-speed DB 32 is acquired increases, but there is an advantage that the implementation is easy.
　次に、第５の実施の形態について説明する。第５の実施の形態では第４の形態と異なる点について説明する。第５の実施の形態において特に言及されない点については、第４の実施の形態と同様でもよい。 Next, the fifth embodiment will be described. The fifth embodiment will explain the differences from the fourth embodiment. The points not particularly mentioned in the fifth embodiment may be the same as those in the fourth embodiment.
　第５の実施の形態では、保有ＤＢの特定方法が第４の実施の形態と異なる。第４の実施の形態における、高速ＤＢ３１及び低速ＤＢ３２を逐次検索する方法は、低速ＤＢ３２に格納されたデータを取得するまでの時間が増加する。 In the fifth embodiment, the method of specifying the possessed DB is different from the fourth embodiment. In the method of sequentially searching the high-speed DB 31 and the low-speed DB 32 in the fourth embodiment, the time until the data stored in the low-speed DB 32 is acquired increases.
　そこで、第５の実施の形態では、高速ＤＢ３１への検索クエリのポストと同時に、低速ＤＢ３２へも投機的に検索クエリをポストすることで低速ＤＢ３２からのデータ取得時間増加を防止する方法を示す。システム全体における検索クエリ数が増加し、処理負荷が高まるが、実装が簡単かつ低速ＤＢ３２からのデータ取得時間増加を防止できるというメリットが有る。 Therefore, in the fifth embodiment, a method of preventing an increase in the data acquisition time from the low-speed DB 32 by posting the search query to the low-speed DB 32 speculatively at the same time as posting the search query to the high-speed DB 31 will be shown. Although the number of search queries in the entire system increases and the processing load increases, there is an advantage that the implementation is easy and the increase in data acquisition time from the low-speed DB 32 can be prevented.
　図１０は、第５の実施の形態におけるデータ取得処理の処理手順の一例を説明するためのフローチャートである。図１０中、図９と同一ステップには同一符号を付し、その説明は省略する。図１０では、図９のステップＳ２１１以降がステップＳ２２１以降に置き換わる。 FIG. 10 is a flowchart for explaining an example of the processing procedure of the data acquisition processing in the fifth embodiment. In FIG. 10, the same steps as those in FIG. 9 are designated by the same reference numerals, and the description thereof will be omitted. In FIG. 10, steps S211 and later in FIG. 9 are replaced with steps S221 and later.
　ステップＳ２１１において、保有ＤＢ特定部１６は、データ取得要求に応じた検索クエリを、高速ＤＢ３１及び低速ＤＢ３２の双方に、同時に（並列的に）ポストする。 In step S211 the possessed DB specifying unit 16 posts the search query corresponding to the data acquisition request to both the high-speed DB 31 and the low-speed DB 32 at the same time (in parallel).
　少なくともいずれか一方のＤＢから検索クエリに一致するデータが取得された場合（Ｓ２２２でＹｅｓ）、データ応答部１７は、当該データを含む応答を対象端末２０へ送信する（Ｓ２２３）。なお、双方からデータが取得された場合、データ応答部１７は、最初にデータを取得した時点で、当該データを含む応答を対象端末２０へ送信する。 When data matching the search query is acquired from at least one of the DBs (Yes in S222), the data response unit 17 transmits a response including the data to the target terminal 20 (S223). When data is acquired from both sides, the data response unit 17 transmits a response including the data to the target terminal 20 when the data is first acquired.
　一方、双方のＤＢに一致するデータが無いことが判明すると（Ｓ２２４でＹｅｓ）、データ応答部１７は、データが存在しないことを示す応答を対象端末２０へ送信する（Ｓ２２５）。 On the other hand, when it is found that there is no matching data in both DBs (Yes in S224), the data response unit 17 transmits a response indicating that the data does not exist to the target terminal 20 (S225).
　次に、第６の実施の形態について説明する。第６の実施の形態では第５の形態と異なる点について説明する。第６の実施の形態において特に言及されない点については、第５の実施の形態と同様でもよい。 Next, the sixth embodiment will be described. The sixth embodiment will explain the differences from the fifth embodiment. The points not particularly mentioned in the sixth embodiment may be the same as those in the fifth embodiment.
　第６の実施の形態では、保有ＤＢの特定方法が第５の実施の形態と異なる。第５の実施の形態における、検索クエリを双方のＤＢに並列的にポストする方法の場合、システム全体における検索クエリ数が増加し、処理負荷が高まる。そこで、第６の実施の形態では、データ取得時にもデータ格納時と同様にデータ毎の遅延要件を判定し、高速ＤＢ３１及び低速ＤＢ３２のいずれか一方にのみ検索クエリを送信する方法について示す。遅延要件の識別方法はデータ格納時の方法と同様でよい。 In the sixth embodiment, the method of specifying the possessed DB is different from the fifth embodiment. In the case of the method of posting the search queries in parallel to both DBs in the fifth embodiment, the number of search queries in the entire system increases and the processing load increases. Therefore, in the sixth embodiment, a method of determining the delay requirement for each data at the time of data acquisition as well as at the time of data storage and transmitting the search query to only one of the high-speed DB 31 and the low-speed DB 32 will be described. The method for identifying the delay requirement may be the same as the method for storing data.
　図１１は、第６の実施の形態におけるデータ取得処理の処理手順の一例を説明するためのフローチャートである。図１１中、図１０と同一ステップには同一符号を付し、その説明は省略する。図１１では、図１０のステップＳ２２１以降がステップＳ２３１以降に置き換わる。 FIG. 11 is a flowchart for explaining an example of the processing procedure of the data acquisition processing in the sixth embodiment. In FIG. 11, the same steps as those in FIG. 10 are designated by the same reference numerals, and the description thereof will be omitted. In FIG. 11, step S221 and subsequent steps in FIG. 10 are replaced with steps S231 and subsequent steps.
　ステップＳ２３１において、保有ＤＢ特定部１６は、データ取得要求の遅延要件を判定する。遅延要件の判定方法は、第１の実施の形態又は第２の実施の形態において説明した方法と同じでよい。 In step S231, the possession DB specifying unit 16 determines the delay requirement of the data acquisition request. The method for determining the delay requirement may be the same as the method described in the first embodiment or the second embodiment.
　保有ＤＢ特定部１６による判定結果が「低遅延」である場合（Ｓ２３２でＹｅｓ）、保有ＤＢ特定部１６は、高速ＤＢ３１に対してデータ取得要求に応じた検索クエリをポストする（Ｓ２３３）。検索クエリに一致するデータが有れば（Ｓ２３４でＹｅｓ）、データ応答部１７は、当該データを含む応答を対象端末２０へ送信する（Ｓ２３５）。一方、検索クエリに一致するデータが無い場合（Ｓ２３４でＮｏ）、又は保有ＤＢ特定部１６による判定結果が「非低遅延」である場合（Ｓ２３２でＮｏ）、保有ＤＢ特定部１６は、低速ＤＢ３２に検索クエリをポストする（Ｓ２３６）。検索クエリに一致するデータがあれば（Ｓ２３７でＹｅｓ）、データ応答部１７は、当該データを含む応答を対象端末２０へ送信する（Ｓ２３８）。検索クエリに一致するデータが無い場合（Ｓ２３７でＮｏ）、データ応答部１７は、データが存在しないことを示す応答を対象端末２０へ送信する（Ｓ２３９）。 When the determination result by the possessed DB specifying unit 16 is "low delay" (Yes in S232), the possessed DB specifying unit 16 posts a search query corresponding to the data acquisition request to the high-speed DB 31 (S233). If there is data that matches the search query (Yes in S234), the data response unit 17 transmits a response including the data to the target terminal 20 (S235). On the other hand, when there is no data matching the search query (No in S234), or when the determination result by the possessed DB specifying unit 16 is "non-low delay" (No in S232), the possessed DB specifying unit 16 is the low-speed DB 32. Post the search query to (S236). If there is data that matches the search query (Yes in S237), the data response unit 17 transmits a response including the data to the target terminal 20 (S238). When there is no data matching the search query (No in S237), the data response unit 17 transmits a response indicating that the data does not exist to the target terminal 20 (S239).
　上述したように、上記各形態によれば、端末２０からの要求に対して適切なデータベースへのアクセスの可能性を高めることができる。 As described above, according to each of the above forms, it is possible to increase the possibility of accessing an appropriate database in response to a request from the terminal 20.
　なお、本実施の形態において、アプリケーションサーバ１０は、データベース選択装置の一例である。遅延要件判定部１２は、判定部の一例である。格納先ＤＢ選択部１３は、選択部の一例である。保有ＤＢ特定部１６は、特定部の一例である。データ応答部１７は、応答部の一例である。 In the present embodiment, the application server 10 is an example of a database selection device. The delay requirement determination unit 12 is an example of the determination unit. The storage destination DB selection unit 13 is an example of the selection unit. The possessed DB specific unit 16 is an example of the specific unit. The data response unit 17 is an example of a response unit.
　以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。 Although the embodiments of the present invention have been described in detail above, the present invention is not limited to such specific embodiments, and various modifications are made within the scope of the gist of the present invention described in the claims.・ Can be changed.
１０　　　　　アプリケーションサーバ
１１　　　　　格納要求受信部
１２　　　　　遅延要件判定部
１３　　　　　格納先ＤＢ選択部
１４　　　　　データ格納部
１５　　　　　取得要求受信部
１６　　　　　保有ＤＢ特定部
１７　　　　　データ応答部
２０　　　　　端末
３０　　　　　ＤＢＭ
３１　　　　　高速ＤＢ
３２　　　　　低速ＤＢ
１００　　　　ドライブ装置
１０１　　　　記録媒体
１０２　　　　補助記憶装置
１０３　　　　メモリ装置
１０４　　　　ＣＰＵ
１０５　　　　インタフェース装置
１２１　　　　遅延要件記憶部
１２２　　　　選択条件記憶部
Ｂ　　　　　　バス 10 Application server 11 Storage request reception unit 12 Delay requirement determination unit 13 Storage destination DB selection unit 14 Data storage unit 15 Acquisition request reception unit 16 Owned DB specific unit 17 Data response unit 20 Terminal 30 DBM
31 High-speed DB
32 Low speed DB
100 Drive device 101 Recording medium 102 Auxiliary storage device 103 Memory device 104 CPU
105 Interface device 121 Delay requirement storage unit 122 Selection condition storage unit B Bus

Claims (6)

  1. 　端末から送信される、データベースへのデータの格納要求に基づいて、前記格納要求に対する遅延要件を判定する判定部と、
    　前記判定部によって判定された遅延要件に基づいて、複数のデータベースの中から前記データの格納先とするデータベースを選択する選択部と、
    を有することを特徴とするデータベース選択装置。     A determination unit that determines a delay requirement for the storage request based on a data storage request sent from the terminal to the database.
    A selection unit that selects a database to store the data from a plurality of databases based on the delay requirement determined by the determination unit.
    A database selection device characterized by having.
  2. 　前記判定部は、前記格納要求の送信元の端末に関連付けられている遅延要件を、前記格納要求に対する遅延要件として判定する、又は前記格納要求に含まれている、前記遅延要件に対応付く識別情報に基づいて、前記格納要求に対する遅延要件を判定する、
    ことを特徴とする請求項１記載のデータベース選択装置。     The determination unit determines the delay requirement associated with the terminal from which the storage request is transmitted as the delay requirement for the storage request, or the identification information corresponding to the delay requirement included in the storage request. To determine the delay requirement for the storage request based on
    The database selection device according to claim 1.
  3. 　前記選択部は、前記複数のデータベースのそれぞれについて予め測定されているアクセス速度と前記遅延要件とに基づいて、前記格納先とするデータベースを選択する、
    ことを特徴とする請求項１又は２記載のデータベース選択装置。     The selection unit selects a database to be stored in the database based on the access speed measured in advance for each of the plurality of databases and the delay requirement.
    The database selection device according to claim 1 or 2, wherein the database selection device is characterized by the above.
  4. 　端末から送信される、データベースからのデータの取得要求に基づいて、複数のデータベースの中から前記データの取得元のデータベースを特定する特定部と、
    　前記特定部が特定したデータベースから取得される前記データを前記端末へ応答する応答部と、
    を有し、
    　前記特定部は、
    　予め作成されているインデックス情報を参照して、前記取得元のデータベースを特定する、
    　又は、相対的に高速なデータベースを優先的に前記取得元のデータベースとして特定する、
    　又は、前記複数のデータベースに並列的に検索クエリを送信し、最初に前記データを応答したデータベースを前記取得元のデータベースとして特定する、
    　又は、前記取得要求に対する遅延要件を判定し、当該遅延要件に基づいて前記取得元のデータベースを特定する、
    ことを特徴とするデータベース選択装置。     Based on the data acquisition request from the database sent from the terminal, a specific part that identifies the database from which the data is acquired from among multiple databases, and a specific unit.
    A response unit that responds to the terminal with the data acquired from the database specified by the specific unit, and
    Have,
    The specific part is
    Identify the acquisition source database by referring to the index information created in advance.
    Alternatively, the relatively high-speed database is preferentially specified as the acquisition source database.
    Alternatively, a search query is sent to the plurality of databases in parallel, and the database that first responds to the data is specified as the acquisition source database.
    Alternatively, the delay requirement for the acquisition request is determined, and the acquisition source database is specified based on the delay requirement.
    A database selection device characterized by that.
  5. 　端末から送信される、データベースへのデータの格納要求に基づいて、前記格納要求に対する遅延要件を判定する判定手順と、
    　前記判定手順において判定された遅延要件に基づいて、複数のデータベースの中から前記データの格納先とするデータベースを選択する選択手順と、
    をコンピュータが実行することを特徴とするデータベース選択方法。     A determination procedure for determining a delay requirement for a storage request based on a data storage request sent from a terminal to a database, and a determination procedure.
    A selection procedure for selecting a database to store the data from a plurality of databases based on the delay requirement determined in the determination procedure, and a selection procedure.
    A database selection method characterized by a computer running.
  6. 　請求項１乃至４いずれか一項記載のデータベース選択装置としてコンピュータを機能させることを特徴とするプログラム。 A program characterized by operating a computer as the database selection device according to any one of claims 1 to 4.
PCT/JP2020/031728 2020-08-21 2020-08-21 Database selection device, database selection method, and program WO2022038790A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2022543261A JPWO2022038790A1 (en) 2020-08-21 2020-08-21
PCT/JP2020/031728 WO2022038790A1 (en) 2020-08-21 2020-08-21 Database selection device, database selection method, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/031728 WO2022038790A1 (en) 2020-08-21 2020-08-21 Database selection device, database selection method, and program

Publications (1)

Publication Number Publication Date
WO2022038790A1 true WO2022038790A1 (en) 2022-02-24

Family

ID=80322610

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/031728 WO2022038790A1 (en) 2020-08-21 2020-08-21 Database selection device, database selection method, and program

Country Status (2)

Country Link
JP (1) JPWO2022038790A1 (en)
WO (1) WO2022038790A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006332825A (en) * 2005-05-24 2006-12-07 Fujitsu Ltd Program, method, and device for dispersing load
JP2018023018A (en) * 2016-08-04 2018-02-08 日本電信電話株式会社 Storage server device, network information sharing system, network information sharing method and network information sharing program
CN111371857A (en) * 2012-10-05 2020-07-03 甲骨文国际公司 Load balancing access to replicated databases

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006332825A (en) * 2005-05-24 2006-12-07 Fujitsu Ltd Program, method, and device for dispersing load
CN111371857A (en) * 2012-10-05 2020-07-03 甲骨文国际公司 Load balancing access to replicated databases
JP2018023018A (en) * 2016-08-04 2018-02-08 日本電信電話株式会社 Storage server device, network information sharing system, network information sharing method and network information sharing program

Also Published As

Publication number Publication date
JPWO2022038790A1 (en) 2022-02-24

Similar Documents

Publication Publication Date Title
US11132365B2 (en) Query plan based on a data storage relationship
US8447827B2 (en) Providing local access to managed content
US9411840B2 (en) Scalable data structures
US8423581B2 (en) Proxy support for special subtree entries in a directory information tree using attribute rules
US10210191B2 (en) Accelerated access to objects in an object store implemented utilizing a file storage system
CN110321325B (en) File index node searching method, terminal, server, system and storage medium
US7676553B1 (en) Incremental web crawler using chunks
US9229960B2 (en) Database management delete efficiency
US11093446B2 (en) Duplicate request checking for file system interfaces
US9081784B2 (en) Delta indexing method for hierarchy file storage
CN109766318B (en) File reading method and device
WO2013172405A1 (en) Storage system and data access method
US9208234B2 (en) Database row access control
US20080133493A1 (en) Method for maintaining database clustering when replacing tables with inserts
CN110352410A (en) Track the access module and preextraction index node of index node
CN112306957A (en) Method and device for acquiring index node number, computing equipment and storage medium
US20150309929A1 (en) Computer system, data management method, and recording medium for storing program
JP6084700B2 (en) Search system and search method
US20180203908A1 (en) Distributed database system and distributed data processing method
WO2022038790A1 (en) Database selection device, database selection method, and program
US10762139B1 (en) Method and system for managing a document search index
US20200249876A1 (en) System and method for data storage management
WO2021017655A1 (en) Method, apparatus, and computing device for obtaining inode number, and storage medium
Cheng et al. Improving LSM‐trie performance by parallel search
Zhou et al. HDKV: supporting efficient high‐dimensional similarity search in key‐value stores

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022543261

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

Country of ref document: EP

Kind code of ref document: A1