WO2017212714A1 - 情報処理システム及び方法、並びにプログラム - Google Patents

情報処理システム及び方法、並びにプログラム Download PDF

Info

Publication number
WO2017212714A1
WO2017212714A1 PCT/JP2017/008806 JP2017008806W WO2017212714A1 WO 2017212714 A1 WO2017212714 A1 WO 2017212714A1 JP 2017008806 W JP2017008806 W JP 2017008806W WO 2017212714 A1 WO2017212714 A1 WO 2017212714A1
Authority
WO
WIPO (PCT)
Prior art keywords
search
query
types
execution
data
Prior art date
Application number
PCT/JP2017/008806
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 KR1020187037501A priority Critical patent/KR102156275B1/ko
Priority to CN201780035755.7A priority patent/CN109313641B/zh
Publication of WO2017212714A1 publication Critical patent/WO2017212714A1/ja
Priority to US16/215,163 priority patent/US10990591B2/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/90—Details of database functions independent of the retrieved data types
    • G06F16/903—Querying
    • G06F16/9032—Query formulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24534—Query rewriting; Transformation
    • G06F16/24535—Query rewriting; Transformation of sub-queries or views
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/903—Querying
    • G06F16/90335—Query processing

Definitions

  • the present invention relates to an information processing system and method, and a program.
  • this index technique is a technique aimed at speeding up the execution of a query when a search is performed with an unspecified search condition.
  • this index technique is not a technique optimized for a data structure in which the types of operations that trigger data search, such as those used in games, that is, a data structure in which a query is finite.
  • a technique for speeding up the database search using the query state there is a technique for caching a query result for a database.
  • Last Recently Used that discards the least recently used search results first
  • Most Recently Used that discards the most recently used search results first
  • Algorithms such as Last Frequently Used (LFU) are well known (see, for example, Patent Document 2).
  • these algorithms manage the cache depending on the frequency of query use, and do not function effectively in applications where there is no locality of search, such as in online games.
  • the problem to be solved by the present invention is to speed up search / reference processing to a fixed data set that stores online game parameters, scenario development, and the like.
  • the game system searches for necessary items from static data very frequently as battles and game scenarios progress.
  • Such search processing is an operation that is always performed during game execution, and has a great influence on the response performance of the entire game.
  • it is difficult to install data in advance on the client side, and in games that run on a Web browser, searching for CSV has become one of the bottlenecks in performance. It is an important issue.
  • the present invention efficiently and speeds up the search and reference processing of static data such as online game parameters and scenario development, thereby enabling a huge number of requests on terminals that have limited computing power, such as smartphones.
  • the purpose is to achieve extremely high response performance even on servers where processing power is tight.
  • an information processing system includes: Search for data to be searched using query conditions that can be input from a predetermined user interface and satisfy the three conditions of reduction, idempotency, and exchangeability between the conditions that make up the query.
  • the preprocessing execution means includes Query extraction means for extracting a plurality of types of subqueries from a set of query conditions that can be used in the search target data; Query execution means for executing each of the plurality of types of subqueries extracted by the query extraction means; For each of the plurality of types of subqueries extracted by the query extraction unit, data that associates an execution result by the query execution unit with information that can identify a subquery of a type corresponding to the execution result is associated data.
  • Associating means generated as Management means for managing the association data for each of the plurality of types of sub-queries generated by the association means;
  • Including The search processing means includes: Accepting means for accepting a query condition input for search from the user interface as a search query condition; A dividing unit that divides the search query condition received by the receiving unit into an aggregate of one or more types of sub-queries; Based on information capable of identifying each of the one or more types of subqueries belonging to the aggregate divided by the dividing unit, each execution result of the one or more types of subqueries is extracted from the association data.
  • Execution result extraction means Search result generating means for generating a search result for the search query condition accepted by the accepting means based on the extraction result of the execution result extracting means;
  • An information processing system comprising:
  • FIG. 4 It is a block diagram which shows the structure of the information system which concerns on one Embodiment of this invention. It is a block diagram which shows the hardware constitutions of the player terminal of one Embodiment of this invention among the information processing systems of FIG. It is a block diagram which shows the hardware constitutions of one Embodiment of this invention among the information processing systems of FIG. It is a functional block diagram which shows the functional structural example of the player terminal of FIG. 2, and the server of FIG. 4 is a flowchart of information processing executed by the player terminal of FIG. 4 and the server of FIG. 3. It is a flowchart of the information processing which the server of FIG. 4 performs. It is a figure which shows an example of the screen for user interfaces displayed on the player terminal of FIG.
  • FIG. 5 is a diagram illustrating an example of a search cost estimation process and an execution order optimization process performed in the calculation order determination unit of FIG. 4.
  • FIG. 1 shows the configuration of an information processing system according to an embodiment of the present invention.
  • the information processing system shown in FIG. 1 is a system including player terminals 1-1 to 1-w used by w players (w is an arbitrary integer value of 1 or more), and a server 2.
  • Each of the player terminals 1-1 to 1-w and the server 2 are connected to each other via a predetermined network N such as the Internet.
  • the server 2 provides an environment in which static data used in a game or the like executed on each of the player terminals 1-1 to 1-w can be searched efficiently and at high speed. Thereby, extremely high response performance is achieved in the game or the like.
  • player terminal 1 when it is not necessary to individually distinguish each of the player terminals 1-1 to 1-w, these are collectively referred to as “player terminal 1”.
  • FIG. 2 is a block diagram showing a hardware configuration of the player terminal 1 according to the embodiment of the present invention in the information processing system of FIG.
  • the player terminal 1 is composed of a smartphone or the like.
  • the player terminal 1 includes a CPU (Central Processing Unit) 21, a ROM (Read Only Memory) 22, a RAM (Random Access Memory) 23, a bus 24, an input / output interface 25, a touch operation input unit 26, a display Unit 27, input unit 28, storage unit 29, communication unit 30, and drive 31.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • the CPU 21 executes various processes according to a program recorded in the ROM 22 or a program loaded from the storage unit 29 to the RAM 23.
  • the RAM 23 appropriately stores data necessary for the CPU 21 to execute various processes.
  • the CPU 21, ROM 22, and RAM 23 are connected to each other via a bus 24.
  • An input / output interface 25 is also connected to the bus 24.
  • a touch operation input unit 26, a display unit 27, an input unit 28, a storage unit 29, a communication unit 30, and a drive 31 are connected to the input / output interface 25.
  • the touch operation input unit 26 includes, for example, a capacitance type or resistive film type (pressure sensitive) position input sensor stacked on the display surface of the display unit 27, and detects coordinates of a position where the touch operation is performed.
  • the touch operation refers to an operation of touching or approaching an object with respect to the touch operation input unit 26.
  • the object that contacts or approaches the touch operation input unit 26 is, for example, a player's finger or a touch pen.
  • the display unit 27 includes a display such as a liquid crystal display, and displays various images such as an image related to a game.
  • the touch operation input unit 26 and the display unit 27 constitute a touch panel.
  • the input unit 28 is configured with various hardware buttons and the like, and inputs various information according to the player's instruction operation.
  • the storage unit 29 is configured by a DRAM (Dynamic Random Access Memory) or the like and stores various data.
  • the communication unit 30 controls communication performed with other devices (the server 2 and other player terminals 1 in the example of FIG. 1) via the network N including the Internet.
  • the drive 31 is provided as necessary.
  • a removable medium 41 composed of a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is appropriately attached to the drive 31.
  • the program read from the removable medium 41 by the drive 31 is installed in the storage unit 29 as necessary.
  • the removable medium 41 can also store various data stored in the storage unit 29 in the same manner as the storage unit 29.
  • FIG. 3 is a block diagram showing a hardware configuration of the server 2 according to an embodiment of the present invention in the information processing system of FIG.
  • the server 2 includes a CPU 51, a ROM 52, a RAM 53, a bus 54, an input / output interface 55, an output unit 56, an input unit 57, a storage unit 58, a communication unit 59, and a drive 60. . Since the configuration of the server 2 is basically the same as the configuration excluding the touch panel of the player terminal 1, the description thereof is omitted here.
  • the information processing system has a “development (data introduction)” phase for generating a database for high-speed search, and “execution (game play) in which a search is actually performed during game play.
  • a series of processes consisting of a “secondary” phase can be executed.
  • the information processing system is configured as a series of processes in the phase of “development (during data introduction)” (hereinafter referred to as “data introduction process”).
  • data introduction process The following processing is executed. That is, the server 2 extracts a plurality of types of minimum units of queries (hereinafter referred to as “sub-queries”) by analyzing a set of queries that can be executed in the game in advance.
  • the server 2 executes each of the extracted types of subqueries, and generates data that associates each of these execution results with information that can identify the corresponding types of subqueries, as associated data.
  • the server 2 stores and manages association data for each of a plurality of types of subqueries in a predetermined database (hereinafter referred to as “PL data DB”).
  • PL data DB predetermined database
  • the information processing system thus performs a data search process (hereinafter referred to as “the time of game play”) in the state in which the correspondence data for each of a plurality of types of sub-queries is stored in the PL data DB.
  • the following processing is executed. That is, when the player operates the player terminal 1 and inputs a query condition via a predetermined user interface, the player terminal 1 transmits the query condition to the server 2.
  • the server 2 Upon receiving the transmitted search query condition, the server 2 divides the search query condition into a set of one or more types of subqueries, and based on the information that can identify each of the one or more types of subqueries, the one or more types of subqueries Each execution result is extracted from the associated data. Then, the server 2 generates a search result based on the extraction result and presents it to the player terminal 1.
  • FIG. 4 is a functional block diagram showing a functional configuration at the time of data introduction processing and search processing, among the functional configurations of the player terminal 1 and the server 2.
  • a user interface control unit 100 In the CPU 21 of the player terminal 1 in FIG. 4, a user interface control unit 100, a query condition transmission control unit 101, a search result acquisition unit 102, and a search result display control unit 104 function.
  • the data introduction processing unit 151 functions during execution of data introduction processing
  • the search processing unit 152 functions during search processing.
  • a query set DB 200 In one area of the storage unit 58 of the server 2, a query set DB 200, a search target data DB 300, and a PL data DB 400 are provided.
  • the data introduction processing unit 151 includes a subquery extraction unit 110, a subquery execution unit 111, and a PL data generation unit 112.
  • a set of queries is a set of query conditions that can be used in a game to be introduced.
  • a set of query conditions is defined by the following expression.
  • qH: ⁇ a, b, c, d, e,..., h ⁇ (1)
  • qH means a set of query conditions corresponding to the Hth condition.
  • the search condition such as the attack power search condition corresponds to the target attribute.
  • Elements a, b, c, d, e,..., H that are elements of this set are values used as search conditions. For example, in the case of an attack power search condition whose maximum value is 15, ⁇ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 ⁇ Are set elements.
  • the subquery extraction unit 110 of the CPU 51 of the server 2 analyzes a set of queries that can be executed in the game based on a set of queries stored in the query set DB 200, and determines a plurality of types of subqueries based on the analysis result. Extract.
  • search target data in the game to be introduced is stored in the search target data DB 300.
  • search target data used in the present embodiment is any data to be searched in the game, and is not limited to a specific format.
  • a wide range of data such as JSON format, CSV format, etc. is targeted.
  • a specific example of the search target data will be described later with reference to FIG.
  • the sub-query execution unit 111 executes each of a plurality of types of sub-queries extracted by the sub-query extraction unit 110 for the search target data stored in the search target data DB 300.
  • the PL data generation unit 112 associates, for each of a plurality of types of subqueries extracted by the subquery extraction unit 110, an execution result by the subquery execution unit 111 and information that can identify the type of subquery corresponding to the execution result. Data is generated as association data (PL data (association data). Note that such association data is hereinafter referred to as “Pre-Linked data” or “PL data” for short.
  • the PL data management unit 120 stores and manages the PL data for each of the plurality of types of subqueries generated in this way in the PL data DB 400.
  • the PL data DB 400 stores PL data for each of a plurality of types of subqueries.
  • the PL data of a predetermined type of subquery is data that associates information that can identify the predetermined type of subquery with an execution result of the predetermined type of subquery.
  • the information that can identify the predetermined type of subquery is sufficient if it can identify the predetermined type of subquery as its name, and the form thereof is not particularly limited.
  • PL data of the predetermined type of subquery is configured.
  • the search processing unit 152 includes a PL data management unit 120, a query condition acquisition unit 121, a division unit 122, an execution result extraction unit 123, a search result generation unit 124, and a search result transmission control unit 125. It has been.
  • the user interface control unit 100 of the CPU 21 of the player terminal 1 executes control to display a predetermined user interface screen (see FIG. 7 described later) on the display unit 27 during the execution of the game.
  • the user interface control unit 100 accepts the content of the touch operation performed by the player on the above-described screen (touch operation input unit 26).
  • the query condition receiving unit 131 in the user interface control unit 100 receives a search condition input by the player to the touch operation input unit 26 by a touch operation as a query condition.
  • the query condition transmission control unit 101 performs control to transmit the query condition received by the query condition reception unit 131 to the server 2 via the communication unit 30.
  • the query condition acquisition unit 121 of the server 2 acquires the query condition transmitted from the player terminal 1 in this way via the communication unit 59.
  • the dividing unit 122 divides the query condition acquired by the query condition acquiring unit 12 into an aggregate of one or more types of subqueries.
  • This aggregate has a form of a logical operation expression configured by connecting one or more types of subqueries belonging to the aggregate by, for example, OR, AND, NOT, and the like.
  • the execution result extraction unit 123 extracts the execution results of one or more types of sub-queries divided by the division unit 122 from the PL data management unit 120.
  • the search result generation unit 124 generates a search result based on an aggregate of execution results of one or more types of sub-queries extracted by the execution result extraction unit 123.
  • this aggregate has a form of a logical operation expression configured by connecting each of execution results of one or more types of sub-queries belonging to the aggregate by, for example, OR, AND, NOT, and the like. Therefore, the search result generation unit 124 generates a search result by solving (calculating) the logical operation expression.
  • a calculation order determination unit 141 is provided in one area in the search result generation unit 124.
  • the operation order determination unit 141 can estimate the set operation cost when integrating the sub-queries (a set operation of logical operation expressions) when the search result generation unit 124 generates the search result.
  • the calculation order determination unit 141 proposes the most efficient order for applying the set operation by sorting the sub-queries in descending order as a result of estimation.
  • the search result transmission control unit 125 executes control for transmitting the search result generated by the search result generation unit 124 to the player terminal 1 via the communication unit 59.
  • the search result acquisition unit 102 of the player terminal 1 acquires the search result transmitted from the server 2 in this way via the communication unit 30.
  • the search result display control unit 103 performs control for causing the display unit 27 to display the search result acquired by the search result acquisition unit 102 (more precisely, an image indicating the search result).
  • FIG. 5 is a flowchart for explaining an example of a flow of data introduction processing executed by the server 2 having the functional configuration of FIG.
  • step S1 the subquery extraction unit 110 of the server 2 in FIG. 4 extracts a plurality of subqueries based on query conditions that can be used in the game to be introduced.
  • step S2 the subquery execution unit 111 executes each of the plurality of subqueries extracted in the process of step S1.
  • step S3 the PL data generation unit 112 associates, for each of the plurality of subqueries extracted in step S1, the execution result of the predetermined type of subquery in step S2 with information that can identify the predetermined type of subquery.
  • Data is generated as PL data.
  • step S4 the PL data management unit 120 stores the PL data generated in step S3 in the PL data DB 400. As a result, the data introduction process ends, and thereafter, the PL data stored in the PL data DB 400 for each of the plurality of subqueries is managed by the PL data management unit 120.
  • FIG. 6 is a flowchart for explaining an example of the flow of search processing executed by the player terminal 1 and the server 2 having the functional configuration of FIG.
  • the player controls the user interface control unit 100 of the player terminal 1 to use a predetermined user interface (a specific example will be described later with reference to FIG. 7) to obtain a desired one.
  • a search condition for example, a condition such as a card having an attack power of 15 or more
  • the process proceeds to step S21.
  • step S21 the query condition receiving unit 131 of the player terminal 1 receives a search condition input by the player as a query condition.
  • step S ⁇ b> 22 the query condition transmission control unit 101 transmits the query condition accepted in step S ⁇ b> 21 to the server 2 via the communication unit 30.
  • step S ⁇ b> 41 the query condition acquisition unit 121 of the server 2 acquires the query condition transmitted from the player terminal 1 via the communication unit 59.
  • step S42 the dividing unit 122 divides the query condition acquired in step S41 into a plurality of types of subqueries.
  • step S43 the execution result extraction unit 123 extracts the execution result of the subquery divided in step S42 from the PL data DB 400 via the PL data management unit 120.
  • step S44 the search result generation unit 124 generates a search result based on the execution result extracted in step S43.
  • the calculation order determination unit 141 in the search result generation unit 124 estimates the search cost of the subquery. By such optimization by execution order control, the search process in step S44 is much more efficient than the conventional process. Details of the processing of the calculation order determination unit 141 will be described later using a specific example of FIG.
  • step S ⁇ b> 45 the search result transmission control unit 125 causes the search result generated in step S ⁇ b> 44 to be transmitted to the player terminal 1 via the communication unit 59.
  • step S23 the search result acquisition unit 102 of the player terminal 1 acquires the search result transmitted from the server 2 in step S45 via the communication unit 30.
  • step S24 the search result display control unit 103 causes the display unit 27 to display the search result acquired in step S23.
  • FIG. 7 is a diagram illustrating an example of a search screen constituting the user interface.
  • the search function in the game for realizing the search processing in the present embodiment is a function for selecting a predetermined search item from a pull-down menu or the like and searching for a combination of them using an AND condition or an OR condition as a query. is there.
  • the search items in the example of FIG. 7 are “class”, “cost”, “card type”, “rarety”, “attack”, “physical strength”, “type”, “keyword ability”, “Include token” and “card text search” exist.
  • one of the search items indicates a predetermined one type of attribute. There are multiple types of subqueries for one attribute.
  • FIG. 7 is a diagram illustrating an example of a search screen constituting the user interface.
  • the search function in the game for realizing the search processing in the present embodiment is a function for selecting a predetermined search item from a pull-down menu or the like and searching for a combination of them using an AND condition or an OR condition as a
  • Class is the class of the card to be searched. In the example of FIG. 7, “Royal”, “Dragon”, and “Bishop” are selected as subqueries. “Cost” is the cost of a card to be searched, and any numerical value can be input as a subquery as long as it is a cost existing as a card in the game. “Card type” means the type of card to be searched, such as “unit”, “spell”, “field”, and the like. In the example of FIG. 7, two sub-queries “unit” and “spell” are selected.
  • “Rarity” is, for example, the rarity of a search target card such as “bronze rare”, “silver rare”, “gold rare”, “legend”, and the like.
  • “Legend” is selected as the subquery.
  • “Attack power” is a parameter of the attack power of the search target card.
  • “Physical strength” is a parameter of physical strength to be searched. In the example of FIG.
  • each numerical value (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11) , 12, 13, 14, 15) are selected as subqueries. That is, since the range of all data values can be verified in advance for static data, for example, if the search condition is set in a range such as “attack power 3 or less”, the OR condition for the value range Can be defined. That is, if “attack power is 3 or less”, it can be defined as “3 or 2 or 1”. That is, the search condition “attack power 3 or less” can be expressed as a collection of or conditions of the subqueries “3”, “2”, and “1”.
  • Presence / absence of token is whether or not a token of “token” is included as a search target.
  • “ON” is not selected, “token” is not included in the search target.
  • “Card text search” is a search based on “keywords” included in the card text, and several “keywords” are set and selected in advance.
  • the keyword “having special ability” becomes a subquery, and only a card having the subquery (keyword) becomes a search target.
  • both the search object data and the search condition can be modeled as a set of combinations of n characters.
  • the search condition can be expressed as a combination of a finite number of primitive subqueries.
  • the search condition input by such a player is divided into sub-queries of the minimum unit with high reusability, and each of the search conditions is obtained in advance.
  • the search target data set (search target data DB 300 in FIG. 4) and the minimum unit sub-query set constituting the query (query set DB 200 in FIG. 4) are divided into two.
  • the execution results (search results) of all the sub-queries can be identified by unique identifiers.
  • the search target data Di can be composed of a combination of a unique identifier and a search target attribute group as shown in the following equation (2).
  • IDi is an identifier that can uniquely identify the search object Di.
  • an identifier can be implemented using a serial number, but in the present embodiment, it does not depend on a specific identifier assigning method.
  • attr1 to attrI are I (I is an arbitrary integer value) attribute data associated with the search object Di.
  • FIG. 8 is a diagram showing a specific example of search target data.
  • each row corresponds to unique in-game data (search target data) having a unique identifier.
  • the data in the first row in FIG. 8 is data corresponding to the conditions of class “Royal”, rarity “Legend”, and attack power “10”, and is data with ID “0001”.
  • the data in the second row is data corresponding to the conditions of class “witch”, rarity “legend”, and attack power “7”, and is data of ID “0002”.
  • “class”, “rareness”, and “attack power” are search target attributes, and these attributes can of course be freely replaced or added. There are u pieces of these data (u is an arbitrary integer greater than or equal to 1) in the game, and all of the data can be covered as search target data in the game.
  • each of a plurality of types of subqueries extracted from a set of queries is executed (searched) for the search target data in the game having the structure shown in FIG. Then, for each of a plurality of types of subqueries, PL data in which the execution result of the subquery is associated with information that can identify the subquery is generated and stored in the PL data DB 400.
  • FIG. 9 is a diagram showing an example of the structure of such PL data DB 400.
  • the y-axis indicates the table attribute type axis
  • the x-axis indicates the subquery type axis
  • the z-axis indicates the corresponding subquery search result (one of the answers).
  • the attribute type of the table represents an arbitrary attribute type. For example, in the example of FIG. 7, it corresponds to each search item in the vertical direction. For example, in the example of FIG. 8, “class”, “rareness”, “attack power”, and the like correspond.
  • there are n types of table attributes (n is an arbitrary integer value of 1 or more). For example, in the example of FIG.
  • the subquery type corresponds to a horizontal item or the like, and represents an arbitrary subquery type.
  • a possible value for the attribute “attack power”, specifically, for example, “10” corresponds to the first line.
  • m types of subqueries there are m types of subqueries (m is an arbitrary integer greater than or equal to 1).
  • the search result of the corresponding subquery indicates the execution result (search result) of the subquery corresponding to the predetermined subquery type (for example, “10”) among the predetermined types (for example, “attack power”) of the table attributes.
  • the predetermined subquery type for example, “10”
  • the search result of the corresponding subquery is an array having q elements (q is an arbitrary integer value of 1 or more) starting from 0, and the size of each array differs for each subquery.
  • the cube CPKR shown in FIG. 9 is one of the answers when a specific attribute type “K” is queried with a specific subquery type “Y” (of the collection of search results). 1).
  • FIG. 10 is a diagram illustrating an example of a search cost estimation process and an execution order optimization process executed by the calculation order determination unit 141 provided in the search result generation unit 124 of the server 2.
  • the operation order determination unit 141 calculates the set operation cost when integrating the execution results of the subqueries extracted by the execution result extraction unit 123 (when performing a set operation using a logical operation expression), and the number of elements of the set of execution results of the subquery. It can be estimated by referring. In this way, by estimating the calculation cost, the calculation order determination unit 141 optimizes the calculation order, and even if the query conditions are complex, the set calculation can be performed with only a small number of comparison operations. Will be able to.
  • a query is created as an array of a set of a search target attribute (attribute) and its value (subquery) column (condition). Each value is connected by an OR condition.
  • the search target attribute is “char_type”, and the value (subquery) column is “1”.
  • the calculation order determining unit 141 executes the subquery so that the subquery having the lowest selection rate, in other words, the subquery is executed in order from the narrowing-down condition in which the most restrictive and the number of applicable data is the minimum. It sorts the columns.
  • the operation order determination unit 141 refers to the number of elements in the set of search results corresponding to the subquery in the PL data DB 400 (the number of execution results of the subquery), and is a kind of type having a small number of elements in the set. By sorting in order from the sub-query, the most efficient order is obtained when the set operation is applied.
  • the attribute “cost” added in the lower diagram of FIG. 10 indicates the number of results returned under the condition (the number of elements in the set of search results corresponding to the subquery in the PL data DB 400), and the calculation order is determined. The part proposes the most efficient order when applying the set operation based on the value of “cost”.
  • the functional configuration of FIG. 4 is merely an example, and is not particularly limited. That is, it is sufficient that the information processing system has a function capable of executing the above-described series of processes as a whole, and what functional block is used to realize this function is not particularly limited to the example of FIG. Further, the location of the functional block is not particularly limited to that in FIG. 4 and may be arbitrary.
  • the functional block of the server 2 may be transferred to the player terminal 1 or the like. Conversely, the functional blocks of the player terminal 1 may be transferred to the server 2 or the like.
  • one functional block may be constituted by hardware alone, software alone, or a combination thereof.
  • a program constituting the software is installed on a computer or the like from a network or a recording medium.
  • the computer may be a computer incorporated in dedicated hardware.
  • the computer may be a computer capable of executing various functions by installing various programs, for example, a general-purpose smartphone or personal computer other than a server.
  • the recording medium including such a program is not only constituted by a removable medium (not shown) distributed separately from the apparatus main body in order to provide the program to the player, but is also provided to the player in a state of being preinstalled in the apparatus main body. It is composed of a provided recording medium or the like.
  • the step of describing the program recorded on the recording medium is not limited to the processing performed in time series along the order, but is not necessarily performed in time series, either in parallel or individually.
  • the process to be executed is also included.
  • the term “system” means an overall apparatus configured by a plurality of devices, a plurality of means, and the like.
  • the search target data static data mainly used in an online game or the like is employed in the above-described embodiment, but is not particularly limited thereto.
  • the static analysis technology to which the present invention is applied is also used for an offline car navigation system, offline content such as an offline electronic dictionary, a full-text search engine for a fixed sentence set on the Web, and the like. You can also.
  • the static analysis technique to which the present invention is applied is not limited to simple character string search or numerical search. Specifically, since the present invention does not depend on a specific search means such as a character string search, it can be solved statically even if extremely complicated conditions such as an image search are introduced.
  • the search target It can be adopted as data.
  • “decreasing” means that the search result is always smaller than the search target. Idempotency always results in the same subquery, no matter how many times the same data is executed. In other words, it can be cached. That is, there is no condition such as “search by current time”.
  • the exchangeability means that the calculation result of the condition A and the condition B is always the same as the search result of the condition B and the condition A.
  • the subquery The comparison order of the set operation is rearranged, and the search result can be obtained with the minimum number of comparisons.
  • the information processing system to which the present invention is applied can take various embodiments having the following configurations, including the information processing system as the embodiment of FIGS. 1 and 4 described above.
  • a plurality of information processing systems to which the present invention is applied include: Search for data to be searched using query conditions that can be input from a predetermined user interface and satisfy the three conditions of reduction, idempotency, and exchangeability between the conditions that make up the query.
  • An information processing system that executes the process of Pre-processing execution means for example, the data introduction time processing unit 151 in FIG. 4 for executing processing before search processing;
  • Search processing means for example, the search processing unit 152 in FIG.
  • the preprocessing execution means includes Query extraction means (for example, the subquery extraction unit 110 in FIG. 4) that extracts a plurality of types of subqueries from a set of query conditions that can be used in the search target data; Query execution means (for example, the subquery execution unit 111 in FIG. 4) that executes each of the plurality of types of subqueries extracted by the query extraction means; For each of the plurality of types of subqueries extracted by the query extraction unit, data that associates an execution result by the query execution unit with information that can identify a subquery of a type corresponding to the execution result is associated data. Associating means (for example, the PL data generating unit 112 in FIG.
  • Management means for example, the PL data management unit 120 in FIG. 4 that manages the association data for each of the plurality of types of sub-queries generated by the association means;
  • Including The search processing means includes: Accepting means (for example, the user interface control unit 100 in FIG. 4) for receiving a query condition input for search from the user interface as a search query condition; A dividing unit (for example, the dividing unit 122 in FIG. 4) that divides the search query condition received by the receiving unit into an aggregate of one or more types of sub-queries; Based on information capable of identifying each of the one or more types of subqueries belonging to the aggregate divided by the dividing unit, each execution result of the one or more types of subqueries is extracted from the association data.
  • Execution result extraction means for example, the execution result extraction unit 123 in FIG. 4
  • Search result generation means for example, search result generation unit 124 of FIG. 4 that generates a search result for the search query condition received by the reception means based on the extraction result of the execution result extraction means; Is an information processing system including
  • the search result generation means executes each of the one or more types of subqueries according to a predetermined order determined for each execution result of the one or more types of subqueries extracted by the execution result extraction means.
  • a search result for the search query condition received by the receiving means is generated,
  • a search cost is calculated according to the amount of the subquery execution result in the search target data, and the search is performed based on the search cost.
  • a processing order determining means for example, the arithmetic order determining unit 141 in FIG. 4) for determining the predetermined order of the logical operations in the result generating means, Furthermore, it can be provided.
  • the present invention can perform search processing much more efficiently than the conventional method.
  • the predetermined user interface has an operation function for selecting one predetermined type from a plurality of types of subqueries for each of a plurality of types of attributes. Furthermore, it can be provided.
  • the execution result by the query execution unit for a predetermined type of subquery of a predetermined type of attribute is the predetermined type of the predetermined type of attribute in the predetermined type of attribute, the predetermined type of subquery, and the search target data.
  • the amount of subquery execution results for Further can be included.

Landscapes

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

Abstract

極めて高いレスポンス性能を達成すること。　サブクエリ抽出部１１０は、サブクエリを抽出する。ＰＬデータ生成部１１２は、ＰＬデータを生成する。ＰＬデータ管理部１２０は、ＰＬデータを管理し、ＰＬデータＤＢに格納する。ユーザインターフェイス制御部１００は、ユーザにより入力されたクエリ条件を受け付ける。クエリ条件送信制御部１０１は、クエリ条件をサーバ２へ送信させる。クエリ条件取得部１２１は送信されてきたクエリ条件を取得する。実行結果抽出部１２３は、サブクエリの実行結果を抽出する。検索結果生成部１２４は、抽出された実行結果から、検索結果を生成する。検索結果送信制御部１２５は、検索結果をプレイヤー端末１へ送信させる。検索結果取得部１０２は送信されてきた検索結果を取得する。検索結果表示制御部１０３は、検索結果を表示させる。

Description

情報処理システム及び方法、並びにプログラム
　本発明は、情報処理システム及び方法、並びにプログラムに関する。
　従来から、データベースの高速化を行う技術としてはインデックス技術がある（例えば特許文献１参照）。
　しかしながら、このインデックス技術は、不特定の検索条件で検索された場合においてクエリの実行を高速化することを目的とした技術である。
　例えばゲームに用いられるような、データ検索を起動するきっかけとなる操作の種類が有限であるデータ構造、即ち、クエリが有限となるデータ構造に最適化された技術ではない。
　一方、クエリの状態を利用したデータベース検索の高速化の技術としては、データベース用のクエリ結果のキャッシュ技術が挙げられる。
　例えば、最近最も使われていない検索結果を最初に捨てるＬｅａｓｔ　Ｒｅｃｅｎｔｌｙ　Ｕｓｅｄ（ＬＲＵ）、最近最も使われた検索結果を最初に捨てるＭｏｓｔ　Ｒｅｃｅｎｔｌｙ　Ｕｓｅｄ（ＭＲＵ）、最近最も使われる頻度の少ない検索結果から捨てるＬｅａｓｔ　Ｆｒｅｑｕｅｎｔｌｙ　Ｕｓｅｄ（ＬＦＵ）等のアルゴリズムがよく知られている（例えば特許文献２参照）。
　しかし、これらのアルゴリズムは、クエリ使用頻度に依存してキャッシュを管理するものであり、例えばオンラインゲームのように検索の局所性が全く存在しない用途では有効に機能しない。
特開平１１－２１２９８０号公報 特開２００９－２６６１４７号公報
　本発明が解決する問題は、オンラインゲームのパラメタやシナリオ展開等を格納する、固定的なデータセットへの検索・参照処理を高速化することである。
　ゲームシステムは、バトルやゲームシナリオの進行に応じて、静的なデータから必要な項目を極めて高頻度に検索する。このような検索処理は、ゲーム実行中、常に行われる操作であり、ゲーム全体のレスポンス性能に大きな影響を及ぼしている。
　特にクライアント側に予めデータをインストールすることが難しい、Ｗｅｂブラウザ上で動作するゲームにおいてはＣＳＶの検索が性能上のボトルネックの一つとなっており、静的データの検索の高速化は本質的に重要な問題である。
　しかし、長期間運用されるオンラインゲームでは、アイテムやカードの属性等ゲーム内で使用するデータが膨大な数になり、時にはゲーム内の文字や数値だけで１００メガバイトを超えるような静的データが存在することも珍しくはない。
　さらに言えば、例えば、英語版をはじめ、多言語・他国市場への展開時には、自然言語のデータは、サポートする言語や進出する市場の数だけ増加することになる。
　本発明は、オンラインゲームのパラメタやシナリオ展開等の静的データの検索・参照処理を効率的かつ高速化することによって、スマートフォンという限られた計算能力しか持ちえない端末上や膨大な数のリクエストを受け付け、処理能力が逼迫するサーバ上においても、極めて高いレスポンス性能を達成することを目的とする。
　上記目的を達成するため、本発明の一態様の情報処理システムは、
　所定のユーザインターフェイスから入力可能であり、かつ、クエリを構成する夫々の条件間において、減少性、冪等性、交換可能性の３つを満たすクエリ条件を用いて、検索対象データに対して検索の処理を実行する情報処理システムにおいて、
　検索の処理前に処理を実行する前処理実行手段と、
　検索の処理を実行する検索処理手段と、
　を備え、            
　前記前処理実行手段は、
　　前記検索対象データで使用され得るクエリ条件の集合から、複数種類のサブクエリを抽出するクエリ抽出手段と、
　　前記クエリ抽出手段により抽出された前記複数種類のサブクエリの夫々を実行するクエリ実行手段と、
　　前記クエリ抽出手段により抽出された前記複数種類のサブクエリ毎に、前記クエリ実行手段による実行結果と、当該実行結果に対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付データとして生成する対応付け手段と、
　　前記対応付け手段により生成された、前記複数種類のサブクエリ毎の対応付データを管理する管理手段と、
　を含み、
　前記検索処理手段は、
　　前記ユーザインターフェイスから検索用に入力されたクエリ条件を、検索クエリ条件として受け付ける受付手段と、
　　前記受付手段により受け付けられた前記検索クエリ条件を、１種類以上のサブクエリの集合体に分割する分割手段と、
　　前記分割手段により分割された前記集合体に属する前記１種類以上のサブクエリの夫々を識別可能な情報に基づいて、当該１種類以上のサブクエリの夫々の実行結果を前記対応付データの中から抽出する実行結果抽出手段と、
　　前記実行結果抽出手段の抽出結果に基づいて、前記受付手段により受け付けられた前記検索クエリ条件に対する検索結果を生成する検索結果生成手段と、
　を備える情報処理システム。
　本発明によれば、オンラインゲームのパラメタやシナリオ展開等の静的データの検索・参照処理を効率的かつ高速化することによって、スマートフォンという限られた計算能力しか持ちえない端末上や膨大な数のリクエストを受け付け、処理能力が逼迫するサーバ上においても、極めて高いレスポンス性能を達成することができる。
本発明の一実施形態に係る情報システムの構成を示すブロック図である。 図１の情報処理システムのうち、本発明の一実施形態のプレイヤー端末のハードウェア構成を示すブロック図である。 図１の情報処理システムのうち、本発明の一実施形態のハードウェア構成を示すブロック図である。 図２のプレイヤー端末及び図３のサーバの機能的構成例を示す機能ブロック図である。 図４のプレイヤー端末及び図３のサーバが実行する情報処理のフローチャートである。 図４のサーバが実行する情報処理のフローチャートである。 図４のプレイヤー端末に表示されるユーザインターフェイス用の画面の一例を示す図である。 図４の検索対象データＤＢに格納される検索対象データの一例を示す図である。 図４のＰＬデータＤＢの構造例を示す図である。 図４の演算順番決定部において実行される、検索コストの見積もり処理及び実行順序の最適化処理の一例を示す図である。
　以下、本発明の実施形態について、図面を用いて説明する。
　図１は、本発明の一実施形態に係る情報処理システムの構成を示している。
　図１に示す情報処理システムは、ｗ人（ｗは１以上の任意の整数値）のプレイヤーの夫々により使用されるプレイヤー端末１－１乃至１－ｗと、サーバ２とを含むシステムである。プレイヤー端末１－１乃至１－ｗの夫々と、サーバ２とは、インターネット等の所定のネットワークＮを介して相互に接続されている。
　サーバ２は、プレイヤー端末１－１乃至１－ｗの夫々において実行されるゲーム等において用いられる静的データを効率的かつ高速に検索等できる環境を提供する。これにより、当該ゲーム等において極めて高いレスポンス性能が達成される。
　なお、以下、プレイヤー端末１－１乃至１－ｗの夫々を個々に区別する必要がない場合、これらをまとめて「プレイヤー端末１」と呼ぶ。
　図２は、図１の情報処理システムのうち、本発明の一実施形態に係るプレイヤー端末１のハードウェア構成を示すブロック図である。
　プレイヤー端末１は、スマートフォン等で構成される。
　プレイヤー端末１は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）２１と、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）２２と、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）２３と、バス２４と、入出力インターフェース２５と、タッチ操作入力部２６と、表示部２７と、入力部２８と、記憶部２９と、通信部３０と、ドライブ３１と、を備えている。
　ＣＰＵ２１は、ＲＯＭ２２に記録されているプログラム、又は、記憶部２９からＲＡＭ２３にロードされたプログラムに従って各種の処理を実行する。
　ＲＡＭ２３には、ＣＰＵ２１が各種の処理を実行する上において必要なデータ等も適宜記憶される。
　ＣＰＵ２１、ＲＯＭ２２及びＲＡＭ２３は、バス２４を介して相互に接続されている。このバス２４にはまた、入出力インターフェース２５も接続されている。入出力インターフェース２５には、タッチ操作入力部２６、表示部２７、入力部２８、記憶部２９、通信部３０及びドライブ３１が接続されている。
　タッチ操作入力部２６は、例えば表示部２７の表示面に積層される静電容量式又は抵抗膜式（感圧式）の位置入力センサにより構成され、タッチ操作がなされた位置の座標を検出する。
　ここで、タッチ操作とは、タッチ操作入力部２６に対する物体の接触又は近接の操作をいう。タッチ操作入力部２６に対して接触又は近接する物体は、例えばプレイヤーの指やタッチペン等である。
　表示部２７は、液晶等のディスプレイにより構成され、ゲームに関する画像等、各種画像を表示する。
　このように、本実施形態では、タッチ操作入力部２６と表示部２７とにより、タッチパネルが構成されている。
　入力部２８は、各種ハードウェア釦等で構成され、プレイヤーの指示操作に応じて各種情報を入力する。
　記憶部２９は、ＤＲＡＭ（Ｄｙｎａｍｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
　通信部３０は、インターネットを含むネットワークＮを介して他の装置（図１の例ではサーバ２や他のプレイヤー端末１）との間で行う通信を制御する。
　ドライブ３１は、必要に応じて設けられる。ドライブ３１には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア４１が適宜装着される。ドライブ３１によってリムーバブルメディア４１から読み出されたプログラムは、必要に応じて記憶部２９にインストールされる。また、リムーバブルメディア４１は、記憶部２９に記憶されている各種データも、記憶部２９と同様に記憶することができる。
　図３は、図１の情報処理システムのうち、本発明の一実施形態に係るサーバ２のハードウェア構成を示すブロック図である。
　サーバ２は、ＣＰＵ５１と、ＲＯＭ５２と、ＲＡＭ５３と、バス５４と、入出力インターフェース５５と、出力部５６と、入力部５７と、記憶部５８と、通信部５９と、ドライブ６０とを備えている。
　サーバ２の構成は、プレイヤー端末１のタッチパネルを除いた構成と基本的に同様であるので、ここではその説明は省略する。
　このような図２のプレイヤー端末１及び図３のサーバ２の各種ハードウェアと各種ソフトウェアとの協働により、プレイヤー端末１及びサーバ２において、静的データの検索等について高速処理の実行が可能になる。
　即ち、本実施形態の情報処理システムは、高速検索のためのデータベースを生成する「開発時（データ導入時）」のフェイズと、ゲームのプレイ中等に実際に検索が行われる「実行時（ゲームプレイ中等）」のフェイズと、から構成される一連の処理を実行することができる。
　より具体的に言えば、本実施形態において、情報処理システムは、「開発時（データ導入時）」のフェイズの一連の処理（以下、「データ導入時処理」と呼ぶ）として、本実施形態では、次のような処理を実行する。
　即ち、サーバ２は、事前にゲーム内で実行され得るクエリの集合を分析することで、クエリの最小単位（以下、「サブクエリ」と呼ぶ）を複数種類抽出する。
　サーバ２は、抽出された複数種類のサブクエリの夫々を実行し、これらの実行結果の夫々と、対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付データとして生成する。
　サーバ２は、複数種類のサブクエリ毎の対応付データを、所定のデータベース（以下、「ＰＬデータＤＢ」と呼ぶ）へ格納して管理する。
　情報処理システムは、このようにしてＰＬデータＤＢに複数種類のサブクエリ毎の対応付データが格納されている状態で、「実行時（ゲームプレイ中等）」のフェイズにおけるデータの検索処理（以下、「検索処理」と呼ぶ）として、本実施形態では次のような処理を実行する。
　即ち、プレイヤーがプレイヤー端末１を操作して、所定のユーザインターフェイスを介してクエリ条件を入力すると、プレイヤー端末１は、そのクエリ条件をサーバ２へ送信する。
　サーバ２は、送信されてきた検索クエリ条件を受信すると、１種類以上のサブクエリの集合体に分割し、当該１種類以上のサブクエリの夫々を識別可能な情報に基づいて、当該１種類以上のサブクエリの夫々の実行結果を対応付データの中から抽出する。そして、サーバ２は、その抽出結果に基づいて、検索結果を生成して、プレイヤー端末１に提示する。
　以下、このようなデータ導入時処理及び検索処理を実行可能な情報処理システムについて、その機能的構成及び処理の流れの一例について説明していく。
　図４は、プレイヤー端末１とサーバ２の機能的構成のうち、データ導入時処理及び検索処理の実行時の機能的構成を示す機能ブロック図である。
　図４のプレイヤー端末１のＣＰＵ２１においては、ユーザインターフェイス制御部１００と、クエリ条件送信制御部１０１と、検索結果取得部１０２と、検索結果表示制御部１０４と、が機能する。
　サーバ２のＣＰＵ５１においては、データ導入時処理の実行時にはデータ導入時処理部１５１が機能し、検索処理時には検索処理部１５２が機能する。
　サーバ２の記憶部５８の一領域には、クエリ集合ＤＢ２００と、検索対象データＤＢ３００と、ＰＬデータＤＢ４００とが設けられる。
　先ず、データ導入時処理の機能的構成について説明する。
　データ導入時処理においては、プレイヤー端末１は特に機能せず、サーバ２のうちデータ導入時処理部１５１のみが機能する。
　データ導入時処理部１５１には、サブクエリ抽出部１１０と、サブクエリ実行部１１１と、ＰＬデータ生成部１１２と、が設けられている。
　先ず、データ導入時処理の前提として、クエリ集合ＤＢ２００には、クエリの集合が格納されているものとする。
　クエリの集合とは、導入対象のゲーム内で使用され得るクエリ条件の集合である。
　具体的には、クエリ条件の集合は、次の式で定義される。
ｑＨ：＝｛ａ，ｂ，ｃ，ｄ，ｅ，・・・，ｈ｝　　　　・・・（１）
　ここで、ｑＨは、Ｈ番目の条件に対応するクエリ条件の集合を意味する。例えば、攻撃力の検索条件等の検索条件が対象とする属性に対応する。この集合の要素であるａ，ｂ，ｃ，ｄ，ｅ，・・・，ｈは、検索条件として使用される値である。例えば、最大値が１５である攻撃力の検索条件の場合であれば、｛１，２，３，４，５，６，７，８，９，１０，１１，１２，１３，１４，１５｝が集合の要素となる。
　サーバ２のＣＰＵ５１のサブクエリ抽出部１１０は、クエリ集合ＤＢ２００に格納されたクエリの集合体に基づいて、ゲーム内で実行され得るクエリの集合を分析し、その分析結果に基づいて複数種類のサブクエリを抽出する。
　ここで、データ導入時処理の前提として、検索対象データＤＢ３００には、導入対象のゲーム内の検索対象データが格納されるているものとする。
　なお、本実施形態で用いる検索対象データとは、ゲーム内で検索対象となるあらゆるデータであり、特定の形式に限定されるものではない。ＪＳＯＮ形式、ＣＳＶ形式、等、幅広いデータが対象となる。検索対象データの具体例については、図８を用いて後述する。
　サブクエリ実行部１１１は、検索対象データＤＢ３００に格納された検索対象データを対象として、サブクエリ抽出部１１０により抽出された複数種類のサブクエリの夫々を実行する。
　ＰＬデータ生成部１１２は、サブクエリ抽出部１１０により抽出された複数種類のサブクエリ毎に、サブクエリ実行部１１１による実行結果と、当該実行結果に対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付けデータ（ＰＬデータ（対応付データ）として生成する。なお、このような対応付けデータを、以下、「Ｐｒｅ－Ｌｉｎｋｅｄデータ」又は略記した「ＰＬデータ」と適宜呼ぶ。
　ＰＬデータ管理部１２０は、このようにして生成された複数種類のサブクエリ毎のＰＬデータをＰＬデータＤＢ４００に格納して管理する。
　即ち、ＰＬデータＤＢ４００は、複数種類のサブクエリ毎のＰＬデータを格納する。所定種類のサブクエリのＰＬデータは、当該所定種類のサブクエリを識別可能な情報と、当該所定種類のサブクエリの実行結果とを対応付けているデータである。
　所定種類のサブクエリを識別可能な情報は、その名のごとく所定種類のサブクエリを特定可能なものであれば足り、その形態等は特に限定されない。例えば本実施形態では、所定種類のサブクエリを識別するキーとなる条件（具体的には例えば、攻撃力で検索するサブクエリでは、ａｔｋ＝１０）が、当該所定種類のサブクエリの実行結果と対応付けられて、当該所定種類のサブクエリのＰＬデータが構成されている。
　次に、検索処理時の機能的構成について説明する。
　検索時処理においては、プレイヤー端末１では、ユーザインターフェイス制御部１００と、クエリ条件送信制御部１０１と、検索結果取得部１０２と、検索結果表示制御部１０４と、が機能する。サーバ２では、検索処理部１５２が機能する。
　検索処理部１５２には、ＰＬデータ管理部１２０と、クエリ条件取得部１２１と、分割部１２２と、実行結果抽出部１２３と、検索結果生成部１２４と、検索結果送信制御部１２５と、が設けられている。
　プレイヤー端末１のＣＰＵ２１のユーザインターフェイス制御部１００は、ゲームの実行中等において、所定のユーザインターフェイス用の画面（後述の図７参照）を表示部２７に表示させる制御を実行する。
　また、ユーザインターフェイス制御部１００は、上述の画面（タッチ操作入力部２６）に対してプレイヤーがしたタッチ操作の内容を受け付ける。例えば、ユーザインターフェイス制御部１００のうちクエリ条件受付部１３１は、プレイヤーがタッチ操作でタッチ操作入力部２６に対して入力した検索のための条件を、クエリ条件として受け付ける。
　クエリ条件送信制御部１０１は、クエリ条件受付部１３１により受け付けられたクエリ条件を、通信部３０を介してサーバ２へ送信する制御を実行する。
　サーバ２のクエリ条件取得部１２１は、このようにしてプレイヤー端末１から送信されてきたクエリ条件を、通信部５９を介して取得する。
　分割部１２２は、クエリ条件取得部１２により取得されたクエリ条件を、１種類以上のサブクエリの集合体に分割する。この集合体は、それに属する１種類以上のサブクエリの夫々が例えばＯＲ、ＡＮＤ、ＮＯＴ等で接続されて構成される論理演算式の形態を有している。
　実行結果抽出部１２３は、分割部１２２により分割された１種以上のサブクエリの実行結果の夫々を、ＰＬデータ管理部１２０から抽出する。
　検索結果生成部１２４は、実行結果抽出部１２３により抽出された１種以上のサブクエリの実行結果の集合体に基づいて、検索結果を生成する。ここで、この集合体は、それに属する１種類以上のサブクエリの実行結果の夫々が例えばＯＲ、ＡＮＤ、ＮＯＴ等で接続されて構成される論理演算式の形態を有している。そこで、検索結果生成部１２４は、当該論理演算式を解くこと（演算すること）によって、検索結果を生成する。
　ここで、検索結果生成部１２４内の一領域には演算順番決定部１４１が設けられる。
　演算順番決定部１４１は、検索結果生成部１２４が検索結果を生成するにあたり、夫々のサブクエリを統合（論理演算式の集合演算）をする際の集合演算コストを見積もることができる。
　演算順番決定部１４１は、見積もりの結果、最も絞り込み能力が高いサブクエリから順にソートすることにより、集合演算を適用するのに最も効率のいい順序を提案する。
　検索結果送信制御部１２５は、検索結果生成部１２４により生成された検索結果を通信部５９を介してプレイヤー端末１へ送信するための制御を実行する。
　プレイヤー端末１の検索結果取得部１０２は、このようにしてサーバ２から送信されてきた検索結果を通信部３０を介して取得する。
　検索結果表示制御部１０３は、検索結果取得部１０２により取得された検索結果（より正確には検索結果を示す画像等）を、表示部２７に表示させる制御を実行する。
　次に、図５を参照して、このような機能的構成を有するサーバ２が実行する、データ導入時処理の流れについて説明する。
　図５は、図４の機能的構成を有するサーバ２が実行する、データ導入時処理の流れの一例を説明するフローチャートである。
　ステップＳ１において、図４のサーバ２のサブクエリ抽出部１１０は、導入対象のゲーム内で使用され得るクエリ条件に基づいて、複数のサブクエリを抽出する。
　ステップＳ２において、サブクエリ実行部１１１は、ステップＳ１の処理で抽出された複数のサブクエリの夫々を実行する。
　ステップＳ３において、ＰＬデータ生成部１１２は、ステップＳ１において抽出された複数のサブクエリ毎に、ステップＳ２における所定種類のサブクエリの実行結果と、当該所定種類のサブクエリを識別可能な情報とを対応付けたデータを、ＰＬデータとして生成する。
　ステップＳ４において、ＰＬデータ管理部１２０は、ステップＳ３において生成されたＰＬデータを、ＰＬデータＤＢ４００に記憶される。
　これにより、データ導入時処理が終了し、これ以降、ＰＬデータＤＢ４００に複数のサブクエリ毎に記憶されたＰＬデータは、ＰＬデータ管理部１２０により管理される。
　続いて、図６を参照して、このような機能的構成を有するプレイヤー端末１及びサーバ２が実行する検索処理の流れについて説明する。
　図６は、図４の機能的構成を有するプレイヤー端末１及びサーバ２が実行する検索処理の流れの一例を説明するフローチャートである。
　ここで、図６の検索処理の実行に際して、プレイヤー端末１のユーザインターフェイス制御部１００の制御により、プレイヤーは、所定のユーザインターフェイス（具体例について図７を用いて後述する）を用いて、所望の検索のための条件（例えば、攻撃力が１５以上のカード等の条件）を入力するものとする。
　このような入力がなされると、処理はステップＳ２１に進む。
　ステップＳ２１において、プレイヤー端末１のクエリ条件受付部１３１は、プレイヤーが入力した検索のための条件を、クエリ条件として受け付ける。
　ステップＳ２２にいて、クエリ条件送信制御部１０１は、ステップＳ２１において受け付けられたクエリ条件を、通信部３０を介してサーバ２へ送信する。
　ステップＳ４１において、サーバ２のクエリ条件取得部１２１は、プレイヤー端末１から送信されてきたクエリ条件を通信部５９を介して取得する。
　ステップＳ４２において、分割部１２２は、ステップＳ４１において取得されたクエリ条件を、複数種類のサブクエリに分割する。
　ステップＳ４３において、実行結果抽出部１２３は、ステップＳ４２において分割されたサブクエリの実行結果を、ＰＬデータ管理部１２０を介してＰＬデータＤＢ４００から抽出する。
　ステップＳ４４において、検索結果生成部１２４は、ステップＳ４３において抽出された実行結果に基づいて、検索結果を生成する。
　なお、ステップＳ４４の処理において、検索結果生成部１２４内の演算順番決定部１４１は、サブクエリの検索コストの見積もりを行う。このような実行順序の制御による最適化により、ステップＳ４４の検索処理は、従来方式の処理に比較して遥かに効率的なものとなっている。演算順番決定部１４１の処理の詳細については、図１０の具体例を用いて後述する。
　ステップＳ４５において、検索結果送信制御部１２５は、ステップＳ４４において生成された検索結果を、通信部５９を介してプレイヤー端末１へ送信させる。
　ステップＳ２３において、プレイヤー端末１の検索結果取得部１０２は、ステップＳ４５においてサーバ２から送信されてきた検索結果を、通信部３０を介して取得する。
　ステップＳ２４において、検索結果表示制御部１０３は、ステップＳ２３において取得された検索結果を、表示部２７に表示させる。
　次に、図７以降の図面を参照して、データ導入時処理又は検索処理に関する具体例について説明する。
　図７は、ユーザインタフェースを構成する検索画面の一例を示す図である。
　本実施形態における検索処理を実現するためのゲーム内の検索機能は、予め決められた検索項目をプルダウンメニュー等で選択し、それらをＡＮＤ条件やＯＲ条件により組み合わせたものをクエリとして検索する機能である。
　例えば図７の例での検索項目については、上から「クラス」、「コスト」、「カードの種類」、「レアリティ」、「攻撃力」、「体力」、「タイプ」、「キーワード能力」、「トークンを含む」、及び「カードテキスト検索」が存在する。このように、本実施形態では検索項目の１つが、所定の１種類の属性を示している。
　１つの属性に対して、複数のサブクエリの種類が存在する。図７の例では、同一属性の各種のサブクエリは、横方向に配置されて表示される。
　「クラス」は、検索対象のカードのクラスである。図７の例では、「ロイヤル」、「ドラゴン」、「ビショップ」の３つがサブクエリとして選択されている。
　「コスト」は、検索対象のカードのコストであり、ゲーム内にカードとして存在するコストであれば、任意の数値をサブクエリとして入力することが可能である。
　「カードの種類」は、例えば「ユニット」、「スペル」、「フィールド」等の、検索対象のカードの種類を意味する。図７の例では、「ユニット」及び「スペル」の２つのサブクエリが選択されている。
　「レアリティ」は、例えば「ブロンズレア」、「シルバーレア」、「ゴールドレア」、「レジェンド」等の、検索対象のカードのレアリティである。図７の例では、「レジェンド」がサブクエリとして選択されている。
　「攻撃力」は、検索対象カードの攻撃力のパラメタである。図７の例では攻撃力「２」と「等しい」という条件が選択されているため、攻撃力２のカードのみがサブクエリとして選択されていることになる。
　「体力」は、検索対象の体力のパラメタである。図７の例では体力「１５」と「以下」という条件が選択されているため、体力１５以下の各数値（１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４、１５）がサブクエリとして選択されていることになる。
　即ち、静的データでは、予め全てのデータの値の範囲を検証することが出来るため、例えば「攻撃力３以下」というような範囲で検索条件が設定されてる場合、値の範囲のＯＲ条件として定義できる。即ち、「攻撃力３以下」であれば「３ｏｒ２ｏｒ１」として定義できる。つまり、サブクエリ「３」、「２」、及び「１」のｏｒ条件の集合体として、「攻撃力３以下」という検索条件を表すことができる。
「トークンの有無」は、検索対象として「トークン」のカードを含むか否かである。図７の例では、「ＯＮ」が選択されていないため、「トークン」は検索対象に含まれない。
　「カードテキスト検索」は、カードテキストに含まれる「キーワード」による検索であり、事前にいくつかの「キーワード」が設定され選択できるようになっている。図７の例では、「特殊能力を持つ」が選択されているため、「特殊能力を持つ」というキーワードがサブクエリとなり、当該サブクエリ（キーワード）を有するカードのみが検索対象となる。
　キーワイドについては、例えばｎ－ｇｒａｍ法を用いると、検索対象データと、検索条件の両方を、ｎ個の文字の組み合わせの集合としてモデル化することができる。より具体的に言えば、「サムライ」というキーワードをｎ－ｇｒａｍの一種である２－ｇｒａｍで表現した場合、「サム」、「ムラ」、「ライ」という３つの要素に分解でき、「サムライ」というキーワード検索を、「サム　ａｎｄ　ムラ　ａｎｄライ」という３つのクエリ条件の論理積として定義することができる。すなわち、キーワード検索のような、クエリ表現の自由度が一見高いように見える検索においても、検索条件を有限個のプリミティブなサブクエリの組み合わせとして表現することができる。
　本実施形態の情報処理システムの検索処理では、上述した様に、このようなプレイヤーにより入力された検索条件を、再利用性の高い最小単位のサブクエリへと分割し、夫々を、事前の検索結果（サブクエリの事前の実行結果）を用いることで、極めて高速な検索処理が実現される。
　つまり、本実施形態の検索処理のポイントは、上述した様に、その前に、本発明のデータ導入時処理が実行されていることである。そこで、以下、本発明のデータ導入時処理の詳細について説明する。
　本実施形態のデータ導入時処理における静的分析では、検索対象データの集合（図４の検索対象データＤＢ３００）と、クエリを構成する最小単位のサブクエリの集合（図４のクエリ集合ＤＢ２００）の２つを入力として受け取り、その結果として、全てのサブクエリの実行結果（検索結果）が、夫々固有の識別子により識別可能になっている必要がある。
　この識別により、検索処理の段階では、サブクエリを実行（検索）することなく、異なるサブクエリの実行結果を用いた統合の処理だけで、検索結果を生成することが可能になる。
　具体的には例えば、検索対象データＤｉは、次式（２）に示すように、一意の識別子と、検索対象属性群の組み合わせから構成することができる。
Ｄｉ：＝｛ＩＤｉ，ａｔｔｒ１，ａｔｔｒ２，ａｔｔｒ３，・・・，ａｔｔｒＩ｝
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・（２）
　ここで、ＩＤｉは、検索対象Ｄｉを一意に識別することができる識別子である。例えば、シリアル番号を用いて識別子を実装することもできるが、本実施形態では、特定の識別子の付与方法には依存しない。
　さらに、ａｔｔｒ１乃至ａｔｔｒＩは、検索対象Ｄｉに関連付けられたＩ個（Ｉは任意の整数値）の属性データである。
　例えば、図８は検索対象データの具体例を示す図である。
　図８の例では、夫々の行が、固有の識別子を持つ、固有のゲーム内データ（検索対象データ）に対応している。
　例えば、図８の１行目のデータは、クラス「ロイヤル」、レアリティ「レジェンド」、攻撃力「１０」の条件に該当するデータであり、ＩＤ「０００１」のデータである。
　また例えば、２行目のデータは、クラス「ウィッチ」、レアリティ「レジェンド」、攻撃力「７」の条件に該当するデータであり、ＩＤ「０００２」のデータである。
　ここで、図８の例では、「クラス」、「レアリティ」、「攻撃力」が検索対象の属性であり、これらの属性は、入れ替えることや追加することも、もちろん自在に可能である。
　これらのデータは、ゲーム内にｕ個（ｕは１以上の任意の整数）存在し、ゲーム内の検索対象データとして全て網羅することができる。
　本実施形態のデータ導入時処理では、このような図８の構造のゲーム内の検索対象データについて、クエリの集合から抽出された複数種類のサブクエリの夫々が実行（検索）される。そして、複数種類のサブクエリ毎に、サブクエリの実行結果と、当該サブクエリを識別可能な情報とを対応付けたＰＬデータが生成され、ＰＬデータＤＢ４００に格納される。
　図９は、このようなＰＬデータＤＢ４００の構造例を示す図である。
　図９の例では、ｙ軸がテーブルの属性の種類の軸、ｘ軸がサブクエリの種類の軸、ｚ軸は対応するサブクエリの検索結果（答えの１つ）の軸を示している。
　テーブルの属性の種類とは、任意の属性の種類を表す。例えば図７の例で言えば、縦方向の各検索項目に該当し、例えば図８の例で言えば、「クラス」、「レアリティ」、「攻撃力」等が該当する。図９の例で言えば、テーブルの属性の種類は、ｎ（ｎは１以上の任意の整数値）種類存在する。
　サブクエリの種類とは、例えば図７の例で言えば、横方向の項目等に該当し、任意のサブクエリの種類を表している。例えば、図８の例で言えば、「攻撃力」という属性に対して取り得る値、具体的には例えば１行目では「１０」が該当する。図９の例で言えば、サブクエリの種類は、ｍ（ｍは１以上の任意の整数）種類存在する。
　対応するサブクエリの検索結果とは、テーブルの属性の所定の種類（例えば「攻撃力」）のうち所定のサブクエリの種類（例えば「１０」）に対応するサブクエリの実行結果（検索結果）を示す。
　図９の例で言えば、対応するサブクエリの検索結果は、０から始まるｑ（ｑは１以上の任意の整数値）個の要素を持つ配列であり、夫々の配列のサイズはサブクエリ毎に異なる。
　例えば、テーブルの属性の種類「Ｋ」の中でサブクエリの種類「Ｐ」についての当該サブクエリの実行結果は、（Ｘ，Ｙ）＝（Ｐ，Ｋ）の座標においてＺ軸（対応するサブクエリの検索結果の軸方向）に配列される１以上の立方体により示されることになる。ここで、図９中で示された立方体ＣＰＫＲは、ある特定の属性の種類「Ｋ」に、ある特定のサブクエリの種類「Ｙ」で問い合わせた時の答えの１つ（検索結果の集合体の１つ）に対応するものである。
　このような図９の構造のＰＬデータＤＢ４００が用意できると、上述の検索処理が実行可能になる。
　上述した様に、本実施形態の検索処理では、検索クエリ条件から分割された１種類以上のサブクエリの夫々を結合した論理演算式を演算することにより、検索結果が生成される。
　本実施形態では、演算順番決定部１４１（図４）が、この論理演算式の演算の順番を最適にするように決定することで、高速な検索を可能にしている。そこで、以下、図１０を参照して、演算順番決定部１４１の具体的な処理内容について説明する。
　図１０は、サーバ２の検索結果生成部１２４内に設けられた演算順番決定部１４１において実行される、検索コストの見積もり処理及び実行順序の最適化処理の一例を示す図である。
　演算順番決定部１４１は、実行結果抽出部１２３が抽出したサブクエリの実行結果を統合する際（論理演算式による集合演算をする際）の集合演算コストを、サブクエリの実行結果の集合の要素数を参照することにより、見積もることができる。
　このように、演算コストを見積もることで、演算順番決定部１４１は、演算の順番を最適化して、クエリ条件が複雑な場合であっても、少ない回数の比較演算だけで集合演算を実行することができるようになる。
　図１０の例では、まず、初期状態のクエリとして、検索対象の属性（ａｔｔｒｉｂｕｔｅ）と、その値（サブクエリ）の列（ｃｏｎｄｉｔｉｏｎ）の組の配列としてクエリが作成されている。なお、夫々の値はＯＲ条件で接続されている。
　例えば、上図の一行目の場合であれば、検索対象の属性は「ｃｈａｒ＿ｔｙｐｅ」であり、その値（サブクエリ）の列は「１」である。
　ここで、このクエリ自体は、ユーザインターフェイス制御部１００により制御されたユーザインターフェイスから入力されたものをそのまま連結したものであるため、効率性等は考慮されていない。
　そこで、図１０に示すように、演算順番決定部１４１は、選択率が最も低いサブクエリ、言い換えると、最も制約が厳しく該当するデータ数が最小個数となる絞り込み条件から順に実行するように、サブクエリの列を並び替えるのである。
　より具体的に言えばは、演算順番決定部１４１は、ＰＬデータＤＢ４００においてサブクエリに対応する検索結果の集合の要素数（サブクエリの実行結果の数）を参照し、集合の要素数が少ない種類のサブクエリから順にソートすることにより、集合演算を適用するときに最も効率の良い順序を求める。
　なお、図１０の下図で追加されている属性「ｃｏｓｔ」は、その条件において返される結果の数（ＰＬデータＤＢ４００においてサブクエリに対応する検索結果の集合の要素数）を示しており、演算順番決定部は、この「ｃｏｓｔ」の値をもとに集合演算を適用するときに最も効率の良い順序を提案する。
　以上本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。
　例えば、図４の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図４の例に限定されない。また、機能ブロックの存在場所も、図４に特に限定されず、任意でよい。例えば、サーバ２の機能ブロックをプレイヤー端末１等に移譲させてもよい。逆にプレイヤー端末１の機能ブロックをサーバ２等に移譲させてもよい。
　また、一つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。
　各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
　コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。
　このようなプログラムを含む記録媒体は、プレイヤーにプログラムを提供するために装置本体とは別に配布される図示せぬリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でプレイヤーに提供される記録媒体等で構成される。
　なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
　また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。
　また例えば、検索対象データとしては、上述の実施形態では、主にオンラインゲーム等で用いられる静的なデータが採用されていたが、特にこれに限定されない。
　本発明が適用される静的分析技術は、オフライン型のカーナビゲーションシステムや、オフライン型の電子辞書のようなオフラインコンテンツ、Ｗｅｂ上の固定的な文章集合を対象とした全文検索エンジン等にも用いることもできる。
　さらには、本発明が適用される静的分析技術は、単純な文字列検索や数値探索のみに限定されない。具体的には、本発明は、文字列検索等の特定の検索手段には依存しないため、例えば画像検索等の極めて複雑な条件を導入しても、静的に解決することができる。
　これにより、極めて複雑な検索条件であっても、クエリの種類を静的に定めることができるものであれば、どのようのものでも対応することができる。
　より具体的に言えば、クエリを構成する夫々の条件間において、減少性、冪等性、クエリ条件の交換可能性がある、という３つの条件下においてクエリ条件を表現できるのであれば、検索対象データとして採用することができる。
　ここで、減少性とは、検索結果は、常に検索対象よりも小さくなるというものである。
　冪等性とは、同じサブクエリを、同じデータに何度も実行しても必ず同じ結果になる。つまり、キャッシュできるというものである。つまり、「現在時間で検索」のような条件がないというものである。
　交換可能性とは、条件Ａかつ条件Ｂの演算結果は、条件Ｂかつ条件Ａの検索結果と、必ず同じになるということであり、本発明においては、この交換可能性を根拠として、サブクエリの集合演算の比較順序を並び替え、最小の比較回数で、検索結果を求めることができる。
　換言すると、本発明が適用される情報処理システムは、上述の図１や図４の実施形態としての情報処理システムを含め、次のような構成を有する各種各様の実施形態を取ることができる。
　即ち、本発明が適用される複数の情報処理システムは、
　所定のユーザインターフェイスから入力可能であり、かつ、クエリを構成する夫々の条件間において、減少性、冪等性、交換可能性の３つを満たすクエリ条件を用いて、検索対象データに対して検索の処理を実行する情報処理システムであって、
　検索の処理前に処理を実行する前処理実行手段（例えば図４のデータ導入時処理部１５１）と、
　検索の処理を実行する検索処理手段（例えば図４の検索処理部１５２）と、
　を備え、
　前記前処理実行手段は、
　　前記検索対象データで使用され得るクエリ条件の集合から、複数種類のサブクエリを抽出するクエリ抽出手段（例えば図４のサブクエリ抽出部１１０）と、
　　前記クエリ抽出手段により抽出された前記複数種類のサブクエリの夫々を実行するクエリ実行手段（例えば図４のサブクエリ実行部１１１）と、
　　前記クエリ抽出手段により抽出された前記複数種類のサブクエリ毎に、前記クエリ実行手段による実行結果と、当該実行結果に対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付データとして生成する対応付け手段（例えば図４のＰＬデータ生成部１１２）と、
　　前記対応付け手段により生成された、前記複数種類のサブクエリ毎の対応付データを管理する管理手段（例えば図４のＰＬデータ管理部１２０）と、
　を含み、
　前記検索処理手段は、
　　前記ユーザインターフェイスから検索用に入力されたクエリ条件を、検索クエリ条件として受け付ける受付手段（例えば図４のユーザインターフェイス制御部１００）と、
　　前記受付手段により受け付けられた前記検索クエリ条件を、１種類以上のサブクエリの集合体に分割する分割手段（例えば図４の分割部１２２）と、
　　前記分割手段により分割された前記集合体に属する前記１種類以上のサブクエリの夫々を識別可能な情報に基づいて、当該１種類以上のサブクエリの夫々の実行結果を前記対応付データの中から抽出する実行結果抽出手段（例えば図４の実行結果抽出部１２３）と、
　　前記実行結果抽出手段の抽出結果に基づいて、前記受付手段により受け付けられた前記検索クエリ条件に対する検索結果を生成する検索結果生成手段（例えば図４の検索結果生成部１２４）と、
　を含む情報処理システムである。
　また、前記検索結果生成手段は、前記実行結果抽出手段により抽出された前記１種類以上のサブクエリの夫々の実行結果に対して決定された所定の順番に従って、当該１種類以上のサブクエリの夫々の実行結果の論理演算をすることにより、前記受付手段により受け付けられた前記検索クエリ条件に対する検索結果を生成し、
　前記実行結果抽出手段により抽出された前記１以上のサブクエリの夫々の実行結果について、前記検索対象データにおけるサブクエリの実行結果の量に応じた検索コストを演算し、当該検索コストに基づいて、前記検索結果生成手段における前記論理演算の前記所定の順番を決定する処理順番決定手段（例えば図４の演算順番決定部１４１）を、
さらに備えることができる。
　このような、サブクエリの検索コストの見積もりと実行順序の制御による最適化により、本発明は、従来方式よりもはるかに効率的に検索処理を実行することができる。
　また、前記所定のユーザインターフェイスは、複数種類の属性毎に、複数種類のサブクエリの中から所定の１種類を選択する操作機能を、
さらに備えることができる。
　これにより、プレイヤーが行う検索の幅を広げることができ、また、検索対象データを追加等する場合であっても、容易に対応することが可能となる。
　また、所定種類の属性の所定種類のサブクエリに対する前記クエリ実行手段による実行結果は、前記所定種類の属性、前記所定種類のサブクエリ、及び、前記検索対象データにおける、当該所定種類の属性の当該所定種類のサブクエリの実行結果の量を、
さらに含むことができる。
　これにより、任意に所定の種類のサブクエリ及び所定種類の属性を決定することが可能となり、静的データを、より効率的にかつ高速に扱うことができる。
　１、１－１乃至１－ｍ・・・プレイヤー端末、２・・・サーバ、２１，５１・・・ＣＰＵ、１００・・ユーザインターフェイス制御部、１０１・・・クエリ条件送信制御部、１０２・・・検索結果取得部、１０３・・・検索結果表示制御部、１１０・・・サブクエリ抽出部、１１１・・・サブクエリ実行部、１１２・・・ＰＬデータ生成部、１２０・・・ＰＬデータ管理部、１２１・・・クエリ条件取得部、１２２・・・分割部、１２３・・・実行結果抽出部、１２４・・・検索結果生成部、１２５・・・検索結果送信制御部、２００・・・クエリ集合ＤＢ、３００・・・検索対象データＤＢ、４００・・・ＰＬデータＤＢ

Claims (6)

  1. 　所定のユーザインターフェイスから入力可能であり、かつ、クエリを構成する夫々の条件間において、減少性、冪等性、交換可能性の３つを満たすクエリ条件を用いて、検索対象データに対して検索の処理を実行する情報処理システムにおいて、
    　検索の処理前に処理を実行する前処理実行手段と、
    　検索の処理を実行する検索処理手段と、
    　を備え、
    　前記前処理実行手段は、
    　　種類が静的に定められたクエリの集合を分析することで、クエリの最小単位であり、前記減少性、前記冪等性、前記交換可能性の３つを満たすサブクエリを、限定された種類数の複数種類だけ抽出するクエリ抽出手段と、
    　　前記クエリ抽出手段により抽出された前記複数種類のサブクエリの夫々を実行するクエリ実行手段と、
    　　前記クエリ抽出手段により抽出された前記複数種類のサブクエリ毎に、前記クエリ実行手段による実行結果と、当該実行結果に対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付データとして生成する対応付け手段と、
    　　前記対応付け手段により生成された、前記複数種類のサブクエリ毎の前記対応付データを管理する管理手段と、
    　を含み、
    　前記検索処理手段は、
    　　前記ユーザインターフェイスから検索用に入力されたクエリ条件を、検索クエリ条件として受け付ける受付手段と、
    　　前記受付手段により受け付けられた前記検索クエリ条件を、１種類以上のサブクエリの集合体に分割する分割手段と、
    　　前記分割手段により分割された前記集合体に属する前記１種類以上のサブクエリの夫々を識別可能な情報に基づいて、当該１種類以上のサブクエリの夫々の実行結果を前記対応付データの中から抽出する実行結果抽出手段と、
    　　前記実行結果抽出手段の抽出結果に基づいて、前記受付手段により受け付けられた前記検索クエリ条件に対する検索結果を生成する検索結果生成手段と、
    　を含む情報処理システム。
  2. 　前記検索結果生成手段は、前記実行結果抽出手段により抽出された前記１種類以上のサブクエリの夫々の実行結果に対して決定された所定の順番に従って、当該１種類以上のサブクエリの夫々の実行結果の論理演算をすることにより、前記受付手段により受け付けられた前記検索クエリ条件に対する検索結果を生成し、
    　前記実行結果抽出手段により抽出された前記１以上のサブクエリの夫々の実行結果について、前記検索対象データにおけるサブクエリの実行結果の量に応じた検索コストを演算し、当該検索コストに基づいて、前記検索結果生成手段における前記論理演算の前記所定の順番を決定する処理順番決定手段をさらに備える、
    　請求項１に記載の情報処理システム。
  3. 　前記ユーザインターフェイスは、複数種類の属性毎に、前記複数種類のサブクエリの中から所定の１種類を選択する操作機能を有する、
    　請求項１又は２に記載の情報処理システム。
  4. 　所定種類の属性の所定種類のサブクエリに対する前記クエリ実行手段による実行結果は、前記所定種類の属性、前記所定種類のサブクエリ、及び、前記検索対象データにおける、当該所定種類の属性の当該所定種類のサブクエリの実行結果の量を含む、
    　請求項３に記載の情報処理システム。
  5. 　所定のユーザインターフェイスから入力可能であり、かつ、クエリを構成する夫々の条件間において、減少性、冪等性、交換可能性の３つを満たすクエリ条件を用いて、検索対象データに対して検索の処理を実行する情報処理システムが実行する情報処理方法において、
    　　検索の処理前に処理を実行する前処理実行ステップと、
    　　検索の処理を実行する検索処理ステップと、
    　を含み、
    　前記前処理実行ステップは、
    　　種類が静的に定められたクエリの集合を分析することで、クエリの最小単位であり、前記減少性、前記冪等性、前記交換可能性の３つを満たすサブクエリを、限定された種類数の複数種類だけ抽出するクエリ抽出ステップと、
    　　前記クエリ抽出ステップにおいて抽出された前記複数種類のサブクエリの夫々を実行するクエリ実行ステップと、
    　　前記クエリ抽出ステップにおいて抽出された前記複数種類のサブクエリ毎に、前記クエリ実行ステップによる実行結果と、当該実行結果に対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付データとして生成する対応付けステップと、
    　　前記対応付けステップにおいて生成された、前記複数種類のサブクエリ毎の前記対応付データを管理する管理ステップと、
    　を含み、
    　前記検索処理ステップは、
    　　前記ユーザインターフェイスから検索用に入力されたクエリ条件を、検索クエリ条件として受け付ける受付ステップと、
    　　前記受付ステップにより受け付けられた前記検索クエリ条件を、１種類以上のサブクエリの集合体に分割する分割ステップと、
    　　前記分割ステップにおいて分割された前記集合体に属する前記１種類以上のサブクエリの夫々を識別可能な情報に基づいて、当該１種類以上のサブクエリの夫々の実行結果を前記対応付データの中から抽出する実行結果抽出ステップと、
    　　前記実行結果抽出ステップにおける抽出結果に基づいて、前記受付ステップにおいて受け付けられた前記検索クエリ条件に対する検索結果を生成する検索結果生成ステップと、
    　を含む情報処理方法。
  6. 　所定のユーザインターフェイスから入力可能であり、かつ、クエリを構成する夫々の条件間において、減少性、冪等性、交換可能性の３つを満たすクエリ条件を用いて、検索対象データに対して検索の処理を実行する情報処理システムに含まれるサーバとクライアントのうち、
    　前記サーバに、検索の処理前に処理を実行する前処理実行ステップを含む制御処理を実行させ、
    　前記サーバ又はクライアントに、検索の処理を実行する検索処理ステップを含む制御処理を実行させるプログラムであって、
    　前記前処理実行ステップは、
    　　種類が静的に定められたクエリの集合を分析することで、クエリの最小単位であり、前記減少性、前記冪等性、前記交換可能性の３つを満たすサブクエリを、限定された種類数の複数種類だけ抽出するクエリ抽出ステップと、
    　　前記クエリ抽出ステップにおいて抽出された前記複数種類のサブクエリの夫々を実行するクエリ実行ステップと、
    　　前記クエリ抽出ステップにおいて抽出された前記複数種類のサブクエリ毎に、前記クエリ実行ステップによる実行結果と、当該実行結果に対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付データとして生成する対応付けステップと、
    　　前記対応付けステップにおいて生成された、前記複数種類のサブクエリ毎の前記対応付データを管理する管理ステップと、
    　を含み、
    　前記検索処理ステップは、
    　　前記ユーザインターフェイスから検索用に入力されたクエリ条件を、検索クエリ条件として受け付ける受付ステップと、
    　　前記受付ステップにより受け付けられた前記検索クエリ条件を、１種類以上のサブクエリの集合体に分割する分割ステップと、
    　　前記分割ステップにおいて分割された前記集合体に属する前記１種類以上のサブクエリの夫々を識別可能な情報に基づいて、当該１種類以上のサブクエリの夫々の実行結果を前記対応付データの中から抽出する実行結果抽出ステップと、
    　　前記実行結果抽出ステップにおける抽出結果に基づいて、前記受付ステップにおいて受け付けられた前記検索クエリ条件に対する検索結果を生成する検索結果生成ステップと、
    　を含むプログラム。
PCT/JP2017/008806 2016-06-09 2017-03-06 情報処理システム及び方法、並びにプログラム WO2017212714A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
KR1020187037501A KR102156275B1 (ko) 2016-06-09 2017-03-06 정보 처리 시스템 및 방법, 및 프로그램
CN201780035755.7A CN109313641B (zh) 2016-06-09 2017-03-06 信息处理系统和方法以及程序
US16/215,163 US10990591B2 (en) 2016-06-09 2018-12-10 Sub-query processing system, method, and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-115415 2016-06-09
JP2016115415A JP6072334B1 (ja) 2016-06-09 2016-06-09 情報処理システム及び方法、並びにプログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/215,163 Continuation US10990591B2 (en) 2016-06-09 2018-12-10 Sub-query processing system, method, and program

Publications (1)

Publication Number Publication Date
WO2017212714A1 true WO2017212714A1 (ja) 2017-12-14

Family

ID=57937607

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/008806 WO2017212714A1 (ja) 2016-06-09 2017-03-06 情報処理システム及び方法、並びにプログラム

Country Status (6)

Country Link
US (1) US10990591B2 (ja)
JP (1) JP6072334B1 (ja)
KR (1) KR102156275B1 (ja)
CN (1) CN109313641B (ja)
TW (1) TWI615727B (ja)
WO (1) WO2017212714A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10853367B1 (en) * 2016-06-16 2020-12-01 Intuit Inc. Dynamic prioritization of attributes to determine search space size of each term, then index on those sizes as attributes
US20230222145A1 (en) * 2020-05-28 2023-07-13 Jfe Steel Corporation Information search system
JP7365469B1 (ja) 2022-08-05 2023-10-19 株式会社Cygames Ｒｄｂに関する処理を行うためのシステム、キャッシュサーバ、方法、及びプログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02130673A (ja) * 1988-11-10 1990-05-18 Chubu Nippon Denki Software Kk データ検索方式
JPH03230273A (ja) * 1990-02-05 1991-10-14 Nec Corp 検索条件式の保持方式
JP2003108561A (ja) * 2001-09-28 2003-04-11 Kawasaki Steel Systems R & D Corp データベース検索システム
JP2007534087A (ja) * 2004-04-22 2007-11-22 オラクル・インターナショナル・コーポレイション 部分的クエリーキャッシング

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0352068A (ja) * 1989-07-20 1991-03-06 Nec Corp 論理演算方式
US5367675A (en) * 1991-12-13 1994-11-22 International Business Machines Corporation Computer automated system and method for optimizing the processing of a query in a relational database system by merging subqueries with the query
JP3849279B2 (ja) 1998-01-23 2006-11-22 富士ゼロックス株式会社 インデクス作成方法および検索方法
US6973478B1 (en) * 1999-10-26 2005-12-06 Top Moxie, Inc. Autonomous local assistant for managing business processes
US7127473B2 (en) * 2002-05-17 2006-10-24 Sap Aktiengesellschaft Methods and systems for providing supplemental contextual content
US7694223B2 (en) * 2003-06-04 2010-04-06 Sony Computer Entertainment Inc. Methods and systems for recording user actions in computer programs
US7661099B2 (en) * 2004-06-29 2010-02-09 International Business Machines Corporation Using idempotent operations to improve transaction performance
US7539667B2 (en) * 2004-11-05 2009-05-26 International Business Machines Corporation Method, system and program for executing a query having a union operator
US20070078816A1 (en) * 2005-10-05 2007-04-05 Microsoft Corporation Common sub-expression elimination for inverse query evaluation
TW200745877A (en) * 2006-06-07 2007-12-16 Telepaq Technology Inc Distributed push-pull information service system
JP5235483B2 (ja) 2008-04-30 2013-07-10 インターナショナル・ビジネス・マシーンズ・コーポレーション データベースと仮想テーブルの整合性を維持する方法および装置。
KR101314201B1 (ko) * 2010-10-04 2013-10-02 엠파이어 테크놀로지 디벨롭먼트 엘엘씨 정보 처리 장치 및 프로그램
CN102779133A (zh) * 2011-05-12 2012-11-14 苏州同程旅游网络科技有限公司 基于多平台、多供应商的搜索比价方法
KR102031392B1 (ko) * 2011-11-15 2019-11-08 아브 이니티오 테크놀로지 엘엘시 후보 쿼리들에 기반한 데이터 클러스터링
CN103136210A (zh) * 2011-11-23 2013-06-05 北京百度网讯科技有限公司 一种挖掘具有相似需求的查询的方法及装置
JP5895813B2 (ja) * 2012-01-18 2016-03-30 富士ゼロックス株式会社 プログラム及び検索装置
CN103425662B (zh) * 2012-05-16 2017-08-25 腾讯科技（深圳）有限公司 一种网络社区中的信息搜索方法和装置
US10031948B1 (en) * 2013-12-02 2018-07-24 Amazon Technologies, Inc. Idempotence service
US9870390B2 (en) * 2014-02-18 2018-01-16 Oracle International Corporation Selecting from OR-expansion states of a query
JP6162664B2 (ja) * 2014-08-13 2017-07-12 ヤフー株式会社 抽出装置、検索サーバ、情報処理装置、抽出システム、抽出方法及び抽出プログラム
US10324931B2 (en) * 2016-02-05 2019-06-18 International Business Machines Corporation Dynamic combination of processes for sub-queries
US10656972B2 (en) * 2016-11-10 2020-05-19 International Business Machines Corporation Managing idempotent operations while interacting with a system of record

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02130673A (ja) * 1988-11-10 1990-05-18 Chubu Nippon Denki Software Kk データ検索方式
JPH03230273A (ja) * 1990-02-05 1991-10-14 Nec Corp 検索条件式の保持方式
JP2003108561A (ja) * 2001-09-28 2003-04-11 Kawasaki Steel Systems R & D Corp データベース検索システム
JP2007534087A (ja) * 2004-04-22 2007-11-22 オラクル・インターナショナル・コーポレイション 部分的クエリーキャッシング

Also Published As

Publication number Publication date
US20190171643A1 (en) 2019-06-06
US10990591B2 (en) 2021-04-27
TW201810086A (zh) 2018-03-16
JP6072334B1 (ja) 2017-02-01
KR20190013907A (ko) 2019-02-11
KR102156275B1 (ko) 2020-09-15
TWI615727B (zh) 2018-02-21
CN109313641A (zh) 2019-02-05
JP2017220102A (ja) 2017-12-14
CN109313641B (zh) 2022-02-18

Similar Documents

Publication Publication Date Title
US10311062B2 (en) Filtering structured data using inexact, culture-dependent terms
JP5316158B2 (ja) 情報処理装置、全文検索方法、全文検索プログラム、及び記録媒体
US8930342B2 (en) Enabling multidimensional search on non-PC devices
JP2010257488A (ja) 対話形サーチクエリー改良のためのシステム及び方法
JP2021174516A (ja) ナレッジグラフ構築方法、装置、電子機器、記憶媒体およびコンピュータプログラム
US10990591B2 (en) Sub-query processing system, method, and program
EP3245598A1 (en) Website access control
US20200065395A1 (en) Efficient leaf invalidation for query execution
CN111984774A (zh) 搜索方法、装置、设备以及存储介质
JP2006178599A (ja) 文書検索装置および方法
US20170124090A1 (en) Method of discovering and exploring feature knowledge
US20170193119A1 (en) Add-On Module Search System
JP2006134191A (ja) 文書検索方法およびそのシステム
Sailaja et al. An overview of pre-processing text clustering methods
EP4075424B1 (en) Speech recognition method and apparatus
JP2013242675A (ja) 分散情報制御装置、分散情報検索方法、データ分散配置方法、及びプログラム
JP2013222418A (ja) パッセージ分割方法、装置、及びプログラム
JP4728125B2 (ja) 索引ファイルを用いた文書検索の方法、索引ファイルを用いた文書検索サーバ、及び索引ファイルを用いた文書検索プログラム
JP5743938B2 (ja) 連想検索システム、連想検索サーバ及びプログラム
CN112148988B (zh) 用于生成信息的方法、装置、设备以及存储介质
WO2013069149A1 (ja) データ検索装置、データの検索方法及びプログラム
JP4942350B2 (ja) 検索クライアント
Ting et al. Finding m-similar users in social networks using the m-representative skyline query
WO2023249756A1 (en) Multi-model enrichment memory and catalog for better search recall with granular provenance and lineage
TW201430594A (zh) 用於非正規語彙網路文章之檢索方法

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20187037501

Country of ref document: KR

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 17809898

Country of ref document: EP

Kind code of ref document: A1