WO2016208779A1 - 대용량 데이터를 처리하기 위한 2단계 쿼리 기반 온라인 분석 프로세싱 방법 - Google Patents

대용량 데이터를 처리하기 위한 2단계 쿼리 기반 온라인 분석 프로세싱 방법 Download PDF

Info

Publication number
WO2016208779A1
WO2016208779A1 PCT/KR2015/006300 KR2015006300W WO2016208779A1 WO 2016208779 A1 WO2016208779 A1 WO 2016208779A1 KR 2015006300 W KR2015006300 W KR 2015006300W WO 2016208779 A1 WO2016208779 A1 WO 2016208779A1
Authority
WO
WIPO (PCT)
Prior art keywords
query
result data
data
basic
request
Prior art date
Application number
PCT/KR2015/006300
Other languages
English (en)
French (fr)
Inventor
배영근
박민규
이영균
Original Assignee
(주) 비아이매트릭스
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by (주) 비아이매트릭스 filed Critical (주) 비아이매트릭스
Priority to PCT/KR2015/006300 priority Critical patent/WO2016208779A1/ko
Publication of WO2016208779A1 publication Critical patent/WO2016208779A1/ko

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

Definitions

  • SQL client when a client requests a query, SQL client separates the steps into a base query and an extended query, and the data obtained by the basic query is obtained from a database storing large data or big data.
  • a two-stage query-based on-line analysis processing method which stores in an in-memory-based server cache and executes an extended query from the data in the server cache to extract necessary data.
  • business intelligence analyzes a large amount of data of a company in a structured or informal manner such as statistical analysis or processes the analyzed information into an easy-to-understand and easy-to-view report to make business more rational. It is a set of tools to help you progress.
  • ETT data extraction and transformation
  • OLAP online analytical processing
  • reporting tools for report generation
  • data mining tools for finding hidden associations between data
  • BI business intelligence
  • big data is a data set with a level of data that is difficult to handle with ordinary software tools and computer systems for collecting, managing, storing, retrieving, sharing, analyzing, and visualizing data that falls within a certain amount of time. This applies mainly to (data sets).
  • the size of the big data may be in the terabyte, exabyte, or zettabyte range. Big data can exist in a variety of fields, including web logs, RFID, sensor networks, social networks, social data, Internet text and documents, Internet search indexing, point of sales data, sales records, and medical records. For example, photo recording, video recording, and electronic commerce.
  • On-line analytical processing (OLAP) systems are introduced and used to analyze using such big data, and one of the biggest problems that occur is a delay in data processing speed. In other words, because of the lengthy time required to process a large amount of data, the user waits for a very long time to feel happier online.
  • OLAP On-line analytical processing
  • the online analysis processing system is composed of a client installed in a user terminal, a BI server for processing data requirements of the client, and a database for storing big data.
  • the user creates a report form (or template) through a client in a web browser and requests the BI server for data to be included in the report form (step 1). That is, necessary information such as a database code (DB code) and a query (SQL query) extracted from the report generated by the client is transmitted to the BI server.
  • the BI server connects the database and requests the necessary data (step 2).
  • the database retrieves and extracts the requested data set (or query result, cube data set) and transmits the extracted result data to the BI server (step 3).
  • the BI server compresses the field information and data received from the database and transmits it to the client (step 4).
  • the conventional on-line analysis processing system as described above frequently takes more than 10 minutes to receive the query result from the moment when the source data exceeds 10 million. For example, a particular site could take over five minutes to retrieve 400 million results. It also takes between 15 and 30 seconds to format the data in the database.
  • Databases typically use data servers that are commercially available and handle standard DB (Database) functions. Such commercialized databases slow query processing to handle large amounts of data when the source table is huge, for example, when there are more than 100 million pieces of data.
  • a view is a logical representation of a subset of data from one or more tables. It does not have actual data, but rather a result in a single SQL. Views can be used to restrict access or easily create complex queries, but they execute SQL internally on demand. Therefore, when the source view is huge or complicated, the connected view also slows down. In addition, even when the query itself is complicated by using functions such as a join function in the query, the processing speed becomes very slow.
  • the commercialized database has a solution that processes queries faster by tuning its own queries to solve the above problems.
  • tuning is also prepared for the general situation, and tuning on its own system has some limitations, so the query speed itself cannot be dramatically improved.
  • An object of the present invention is to solve the problems described above, and the client separates the basic query and the extended query through SQL parsing when the query request, and the data by the basic query from a database storing large data or big data It is to provide a two-step query-based on-line analysis processing method to retrieve the data stored in the in-memory-based server cache, and execute the extended query from the data in the server cache to extract the required data.
  • the present invention relates to a two-step query-based on-line analysis processing method for processing a request query for a database requested by the client, (a) parsing the request query, and included in the request query Extracting column names; (b) a query that refers to the same table as the table referred to by the request query (hereinafter, referred to as a basic query) by using the extracted column name as a reference item, and result data requested by the request query by referring to the result data of the basic query.
  • a basic query a query that refers to the same table as the table referred to by the request query (hereinafter, referred to as a basic query) by using the extracted column name as a reference item, and result data requested by the request query by referring to the result data of the basic query.
  • Generating an extended query for importing (c) retrieving result data of the basic query from the cache; (d) if there is no result data of the basic query in the cache, requesting data from the database with the basic query, and storing the result data of the received basic query in the cache; And (e) obtaining the result data of the extension query by applying the extension query to the result data of the basic query and transmitting the obtained result data to the client.
  • the present invention relates to a two-step query-based online analysis processing method for processing a request query for a database requested by a client, (a) parsing the request query, extracting a column name included in the request query step; (b) a query that refers to the same table as the table referred to by the request query (hereinafter, referred to as a basic query) by using the extracted column name as a reference item, and result data requested by the request query by referring to the result data of the basic query.
  • a basic query a query that refers to the same table as the table referred to by the request query
  • Generating an extended query for importing (c) retrieving result data of the basic query from the cache; (d) if there is no result data of the basic query in the cache, requesting data from the database with the request query, and transmitting the result data of the received request query to the client; And (e) requesting data from the database with the basic query and storing the result data of the received basic query in the cache.
  • the present invention is a two-step query-based online analysis processing method, the result data of the extended query is stored in the cache as a cache file, the method, after (f) step (b), If the cache file is retrieved from the cache, characterized in that it further comprises the step of transmitting the retrieved cache file to the client.
  • the present invention is a two-step query-based online analysis processing method, in step (a), generates a unique key for identifying the column name, and in step (b), reference item of the basic query
  • step (a) generates a unique key for identifying the column name
  • step (b) reference item of the basic query
  • an alias is defined for the column name using the unique key
  • the extended query refers to the column using the alias.
  • the present invention is a two-step query-based online analysis processing method, characterized in that the unique key is obtained by hashing the name of the database, the name of the reference table, and the column name of the column name.
  • the present invention is a two-step query-based online analysis processing method, in step (b), the basic query is composed of a reference clause clause, a table reference clause, and a condition clause, the table reference clause and conditions of the basic query
  • the clause has the same structure as the table reference clause and the condition clause of the request query.
  • the present invention is a two-step query-based online analysis processing method, in step (b), the extended query refers to the result data of the basic query or the basic query in the table reference clause, and other than the table reference clause The clause of is generated to have the same structure as the clause of the request query.
  • the present invention is a two-step query-based online analysis processing method, in step (b), if an alias for a table is defined in the request query, the alias of the table is deleted and the alias of the table Replace with the name of the table to generate the extended query.
  • the present invention is a two-step query-based on-line analysis processing method, the cache is composed of in-memory storage and cache disk, characterized in that for storing the result data of the request-based query in the in-memory storage.
  • FIG. 1 is a block diagram of an on-line analysis processing system according to the prior art.
  • FIG. 2 is a block diagram of the configuration of an entire system for implementing a two-step query based online analysis processing method according to the present invention.
  • FIG. 3 is a flow chart illustrating a two-step query based online analysis processing method according to a first embodiment of the present invention.
  • 5 is an example of a basic query and an extended query according to the first embodiment of the present invention.
  • FIG. 6 is a flow chart illustrating a two-step query based online analysis processing method according to a second embodiment of the present invention.
  • FIG. 7 is a flowchart illustrating a two-step query based online analysis processing method according to a third embodiment of the present invention.
  • FIG. 8 is a configuration diagram of a server cache according to a fourth embodiment of the present invention.
  • FIG. 9 is a flowchart for explaining a first situation according to the present invention.
  • FIG. 11 is a flowchart for explaining a third situation according to the present invention.
  • the entire system for implementing the present invention is composed of a client 20, an analysis processing server 30, a BI server 50, and a database 60.
  • the analysis processing server 30 includes a server cache 40 for storing some data received from the database 60.
  • the client 20 is a client program system installed in the user terminal 10 and has a user interface through a web browser. That is, the user performs a data analysis process online through a web browser or an interface of a screen such as a web browser. At this time, the client 10 receives a user's command or the like, performs the corresponding command, and displays the processing result on the screen or a web browser.
  • the user terminal 10 is a computer terminal having a computing function, such as a personal computer (PC), PDA, smart phone.
  • the client 20 requests the analysis processing server 30 to perform an online processing such as data request, data analysis, etc., and retrieves the result from the server 30 and displays the result on the web browser.
  • an online processing such as data request, data analysis, etc.
  • the analysis processing server 30 is a server that processes online analysis processing (OLAP), receives a request for data analysis from the client 20, processes the corresponding analysis request, and returns the result to the client 20.
  • OLAP online analysis processing
  • the analysis processing server 30 retrieves the data stored in the database 50 by using a query for requesting data.
  • a query is a data manipulation language that describes a question or query that occurs when retrieving or updating data stored in a database.
  • a query serves as a kind of command.
  • SQL Structured Query Language
  • the analysis processing server 30 includes a server cache 40 to temporarily store all or part of the data taken from the database 60.
  • the server cache 40 may be implemented as a cache memory by being implemented on a memory (RAM, etc.) of the analysis processing server, or may be configured as a cache disk by being implemented as a hard disk or a solid state disk (SSD) disk or the like. Or you can save all the data to disk and put some data, that is, the data you need, into cache memory.
  • the BI server 50 serves as a database interface server for relaying the database 50. That is, the BI server 50 receives a query from the analysis processing server 30 and brings the data of the database 60 using the query. Or request the DBMS of the database 60 to get the data.
  • the BI server 50 is composed of a plurality of heterogeneous databases 60, the BI server 50 requests a query or receives data according to an interface method with the corresponding database. In addition, the BI server 50 performs additional operations for data transmission and reception such as encryption, data compression, or file compression.
  • the database 60 is a normal database (DB) for storing data, has a DBMS for managing data, and performs operations such as storing, deleting, and retrieving data through queries.
  • DB normal database
  • the database 60 is a commercially available database and performs a data query service by using a general query function for processing data.
  • the database 60 is a database that stores big data. Also preferably, the database 60 is composed of a relational database (RDB).
  • RDB relational database
  • the two-step query-based online analysis processing method includes (a) receiving and parsing a request query (S11); (b) generating a basic query and an extended query (S12); (c) retrieving a result of the basic query from the server cache (S13); (d) if not retrieved, the basic query is taken from the database and stored in a server cache (S14); (e) applying an extended query to the result of the basic query to obtain a result of the request query (S15); And (f) transmitting the result of the request query (S16).
  • the analysis processing server 30 receives a request query from the client 20 and parses the request query (S11).
  • the client 20 installed in the user terminal 10 requests the analysis processing server 30 as a query for necessary data.
  • the request query is written as an SQL query. 4 shows an example of a request query.
  • a request query created with an SQL query consists of a reference clause (SELECT clause), table clause and join clause (FROM clause), condition clause (WHERE clause), group clause (GROUP BY), or order clause (ORDER BY).
  • a select list is a clause that defines the fields / columns of a desired data table
  • a table reference is a clause that defines a table from which data is to be imported
  • a join clause defines joins between tables.
  • Where clause is a clause that defines a condition.
  • a group by or order by clause is a clause that defines the type of aggregation or presentation.
  • Data fields, reference tables, variables in conditional statements, etc., defined in the request query are all references to fields, tables, etc. of source data in the database 60.
  • Parsing the request SQL query parses the request SQL query to select a list list, table reference, join clause, where clause, and group by clause. , Order by clause, etc. are extracted in the form of a set.
  • the column name is extracted from the reference section of the SELECT clause (or reference section clause). Also, extract all column names referenced in join clause, condition clause, group clause, or sequence clause.
  • the SQL syntax for parsing is as follows:
  • query_block ((UNION ALL?)
  • an identifier or unique key that can be distinguished from other column names is generated for the extracted column name.
  • the unique key is an identifier (or unique key) for the absolute name of the column.
  • An absolute name is a name consisting of a reference database name, a reference table name, and a column name.
  • the absolute name of a column can be expressed as
  • the unique name of a column name is obtained through hashing using the absolute name of the column name.
  • the formula for generating a unique key is:
  • the unique key of the column name serves as an identifier for identifying the columns. That is, the column can be identified by a unique key.
  • the unique name of the column name is used to identify each column name through aliasing when generating the basic query or request query. All column names of the basic query are aliased using the unique name of the column so that all column names in the table of the result data by the basic query are generated as the unique key. That is, the reason for aliasing column names to identifiers (or unique keys) is to identify the columns in the auto-generated query.
  • query 1 and query 2 are as follows.
  • the query is generated as follows.
  • aliases of the table names are removed from the table clause, and all the syntax named aliases of the table names are changed to the original table names. For example, in the above example, if MATRIX_DEMO is aliased to T and renamed, it is changed to the original table name (MATRIX_DEMO).
  • the absolute name of the table for each table name in the table reference clause is obtained.
  • the absolute name of a table consists of the database name and the table name, expressed as ⁇ database name>. ⁇ Table name>.
  • table clauses and join clauses are included in the "FROM" clause in SQL statements.
  • the FROM clause refers to a table and consists of a table and a join. Therefore, hereinafter, a clause including a table clause and a join clause will be referred to as a "table reference clause”.
  • the analysis processing server 30 generates a basic query and an extended query by using the parsed request query (S12).
  • the basic query is a query that makes a request by referring to the data in the database 60
  • the extended query is a query that makes a request by referring to the data extracted by the basic query (or the result data of the basic query).
  • An example of a basic query and an extended query is shown in FIG.
  • the third reference item of the request query is a calculation formula of "SUM (T.H_VAL)".
  • alias the unique name of the column name to the reference items. That is, the unique key is defined as an alias.
  • the table clause (or table reference clause), join clause, and condition clause of the basic query are composed in the same way as the table clause, join clause, and condition clause of the request query.
  • the aliased alias is deleted. And change the table name with alias in the reference clause, join clause, and condition clause to the table name (or absolute name).
  • the request query is as follows.
  • the basic query generated from the request query 1 is as follows.
  • the extended query has the same structure as the request query except for the table clause, and references the result data table of the underlying query or the underlying query (the result table that the basic query retrieved from the source database) instead of the table referenced in the table clause.
  • ⁇ @ ORIGINAL_SQL @ ⁇ indicates to refer to the base query or the result table of the base query.
  • the extended query is a query requested by referring to the result data of the obtained basic query.
  • the result obtained by the extended query is the same as the result obtained by the original request query.
  • the set of result data obtained by the extended query is always smaller than the set of result data obtained by the basic query. That is, the data set of the extended query may be referred to as a subset of the data set of the basic query.
  • Data obtained from the database 60 by the basic query (or result data of the basic query) is stored and stored in the server cache 40.
  • the analysis processing server 30 searches the server cache 40 for the basic query obtained above. In other words, it is checked whether the basic query obtained before the stored basic query exists.
  • the SQL used in the applicant's matrix is SQL generated automatically using meta. If you have selected Meta Item 1 and Meta Item 2, you can automatically generate the table code, column code, and join condition for the meta item. You can see that SQL generated automatically from the same meta is equivalent by just comparing field aliases. In other words, it is possible to check whether or not to reuse the basic query only by performing condition comparison. However, if you only compare queries without meta, you also need to compare tables and their join relationships.
  • the data is requested to the database 60 with the basic query, and when the result data of the basic query is received, it is stored in the server cache 40 ( S14).
  • the basic query is a query that directly refers to data stored in the database 60
  • the basic query makes a query request to the database 60.
  • the query request is requested to the database 60 through the BI server 50, and the data extracted by the basic query in the database 60 is returned to the analysis processing server 30 through the BI server 50.
  • the analysis processing server 30 stores the result data of the basic query received in the server cache 50.
  • the result data of the basic query is stored in the same form or the same structure as the data structure of the database 60. That is, if the data of the database 60 is stored in the form of a table, the result data of the basic query is also stored in the form of a table.
  • the type and size of each field of the result data stored in the server cache 40 is configured to be the same as the type or size of the field configured in the database 60. This is so that the query can be executed even if the extended query refers to the result data of the basic query instead of the data stored in the database 60.
  • the column name of the result table is converted to the unique key of the column.
  • the analysis processing server 30 obtains the result of the request query by applying the extended query to the result of the basic query (S15).
  • the extended query is a query that references the underlying query instead of referring to the database 60 with the same structure as the request query. Therefore, it is generated by changing the names (hereinafter referred to as database reference names) referring to the database 60 in the extended query to names (hereinafter referred to as basic query reference names) referring to the result data of the basic query.
  • database reference names names
  • basic query reference names names
  • the names of tables referenced in the extended query are all changed to refer to the table (or result table) generated by the base query, and the names (or column names) of the data fields referenced in the extended query are all based. It is all changed to the name (or unique key of the column name) of the data field generated by the query.
  • step S13 the result data of the basic query may or may not be stored in the server cache 40. However, if not stored, in step S14, the query to the database 60 as a basic query to receive the data and store in the server cache 40. Therefore, in this step S15, the result data of the basic query is always stored in the server cache 40.
  • the extended query is also a query that references the data of the base query. Therefore, the extended query can be applied to the result data of the basic query. If you apply the extended query by referring to the result data of the underlying query, you can get the result data of the originally requested request query.
  • the result data obtained by applying the extended query is transmitted to the client 20 as a result of the request query (S16).
  • the two-step query-based online analysis processing method includes (a) receiving and parsing a request query (S21); (b) generating a basic query and an extended query (S22); (c) retrieving a result of the basic query from the server cache (S23); (d) if not retrieved, the request query is taken from the database and transmitted (S24); (h) taking the basic query from a database and storing it in a server cache (S28); (e) if found, executing the extended query (S25); (f) applying an extended query to the result of the basic query to obtain a result of the request query (S26); And (g) transmitting the result of the request query (S27).
  • the analysis processing server 30 receives and parses a request query from the client 20 (S21). The same as in the first embodiment. Next, the analysis processing server 30 generates a basic query and an extended query using the parsing result (S22).
  • the analysis processing server 30 searches for the basic query obtained above, in comparison with the basic queries stored in the result data in the server cache 40.
  • the data is requested to the database 60 by the request query, and when the result data of the request query is received, it is transmitted to the client 20 ( S24).
  • desired result data or result table
  • the analysis processing server 30 After transmitting the result data of the request query to the client 20, the analysis processing server 30 requests the data to the database 60 with the basic query, and receives the result data of the basic query, it is server cache 40 Stored in step S28). In particular, the analysis processing server 30 requests data for the basic query at a time when there is not much request from the database 60 by the scheduler and the traffic is free, and stores the result in the server cache 40.
  • the analysis processing server 30 obtains the result of the request query by applying the extended query to the result data of the basic query (S25). The obtained result data is transmitted to the client 20 (S26).
  • the two-step query-based online analysis processing method includes (a) receiving and parsing a request query (S31); (b) generating a basic query and an extended query (S31); (c) searching the cache file by combining the basic query and the extended query (S32); (d) if found, transmitting the cache file to the client (S33); (e) if not detected, performing 34 the first or second embodiment; And (f) storing the result data of the request query in a cache file (S35).
  • the third embodiment of the present invention is an embodiment complementing the first or second embodiment described above. That is, when the result data of the request query is stored in a binary form as a cache file and requested again by the same query, the cache file is directly transmitted to the client 20.
  • a cache file is a file that stores the result data of a request query in a file.
  • the analysis processing server 30 When the analysis processing server 30 generates the result data requested by the client 20 and finally transmits it, the analysis processing server 30 transmits the data in the form of a file.
  • the cache file is the same file as when transferred. Therefore, if a request is made with the same request query as the cache file query, the cache file can be transferred immediately.
  • the cache file is stored in the server cache 40 of the analysis processing server 40.
  • the analysis processing server 30 receives and parses a request query from the client 20 (S30). The same as in the first or second embodiment above.
  • the analysis processing server 30 combines the basic query and the extended query, compares the queries of the stored cache file, and searches whether there is the same query (S32).
  • the retrieved cache file is immediately transmitted to the client 20 (S33).
  • third search steps S13 and S23 of the first or second embodiment described above are performed (S34). That is, the server cache searches whether there is result data of the basic query. If the result data of the basic query exists in the server cache, the extended data is created for the basic query to obtain the result data. The obtained result data is transmitted to the client. If there is no result data of the base query in the server cache, the result data is taken from the database 60 in the base query or request query. If the imported result data is the basic query data, the result data of the request query is created through the extended query. Finally, the result data of the request query is transmitted to the client 20.
  • the result data (or result data transmitted to the client) of the combination of the generated basic query and the extended query is stored in the server cache 40 as a cache file (S36).
  • the fourth embodiment of the present invention has the same configuration as the first to third embodiments described above. However, the configuration of the server cache 40 is further subdivided.
  • the fourth embodiment of the present invention comprises a server cache 40 comprising a cache memory 41 and a cache disk 42.
  • the cache memory 41 is composed of random access memory (RAM) of the analysis processing server 30.
  • the cache memory 41 is composed of in-memory storage.
  • the cache disk 42 includes a hard disk or solid state disk (SSD) of the analysis processing server 30.
  • the result data of the basic query stored in the server cache 40 are all stored in the cache memory 41.
  • the result data of the basic query is larger than the storage capacity of the cache memory 41, the result data exceeding the capacity of the cache memory is stored in the cache disk 42.
  • the result data of the basic query transferred to the cache disk 42 is selected by a predetermined policy.
  • a predetermined policy based on the frequency of access to the result data, the latest access time, and the like, the result data with the least frequent access or the oldest access time is selected.
  • the cache file of the third embodiment is stored in the cache disk 42.
  • the present invention relates to a platform for processing big data based on business intelligence (BI).
  • BI business intelligence
  • the present invention uses cache files and cache memory tables for near real time processing. To do this, the request query is parsed and separated into basic and extended queries.
  • file loading / storing / filtering defines the structure of file loading / storing / filtering according to the limitation of memory. For example, if it takes about 5G to load 100 million memory tables, you can't have 1 billion memory in a 32G server environment. Therefore, there is a need for a structure that stores some data quickly in file form and loads it back into memory if necessary. Process only the data you want as conditions in the file itself (such as parsing filtering and queries to extract conditions from that column).
  • In-memory Database is a database management system that is installed and operated in main memory of data storage. The processing speed is faster than that installed on the disk.
  • the first situation is a case where both the basic query and the extended query are inconsistent. That is, the first situation corresponds to the case where the query is executed for the first time, and the overall processing speed is the same as that of the system according to the prior art.
  • DB code and SQL information extracted from a matrix report are divided into a basic query (BaseSQL) and an extended query (ExtendSQL) and requested to an analysis processing server (SOLAP server) (step 1). . Since there is no matching base query (BaseSQL) and extended query (ExtendSQL), the query is made to the BI server (Matrix Server) as the original request query (step 2). The BI server connects to the target DB and requests data (step 3). Send cube data from target DB (step 4). The field information and data are compressed and sent (step 5). Save the file you sent as a cache file (step 6). Send the cache file to the browser (or client) (step 7). Finally, the scheduler executes the base query (BaseSQL) in the source DB and stores it in the cache memory 40 (Background execution) (step 8).
  • the second situation is a case where the basic query matches and the extended query does not match. This is the case when the cache memory table corresponding to the basic query (BaseSQL) is generated, and the speed is about 10 seconds, which is 10 to 50 times higher than the first situation (or the prior art).
  • BaseSQL basic query
  • DB code and SQL information extracted from a matrix report are divided into basic query (BaseSQL) and extended query (ExtendSQL) and requested to the SOLAP server (step 1). If the base query (BaseSQL) matches and there is no extended query (ExtendSQL), the target table of the extended query (ExtendSQL) is changed to the table name stored in the server cache and executed (step 2).
  • the cube data is sent from the server cache (step 3). Save the sent file as a cache file (step 4). Finally, send the cache file to the browser (step 5).
  • the third situation is a case where both the basic query and the extended query match. This is the case when both the basic query (BaseSQL) and the extended query (ExtendSQL) match, and the speed is about 3 seconds, which is 100 times higher than the first situation or the prior art.
  • the DB code and SQL information extracted from the Matrix report are divided into a basic query (BaseSQL) and an extended query (ExtendSQL) and requested to the analysis processing server (step 1). If both the base query (BaseSQL) and extended query (ExtendSQL) match, there is a hash value (step 2). The cache file is then sent to the browser (step 3).
  • FIG. 12 A table comparing the processing speeds of the first to third situations and the like is shown in FIG. 12.
  • the state is automatically skipped. In other words, the process shifts from the first situation to the second situation and from the second situation to the third situation. Also, as the number of concurrent users increases, the frequency of cache file usage increases rapidly (expected to be over 90%). Most users will experience a reduction in query time from five minutes to three seconds.
  • the data for the underlying query can be run with the scheduler. In other words, the scheduler can import data at a leisurely time, so it does not affect the speed of feeling.

Landscapes

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

Abstract

본 발명은 클라이언트가 요청하는 데이터베이스에 대한 요청 쿼리를 처리하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 관한 것으로서, (a) 상기 요청 쿼리를 파싱하여, 상기 요청 쿼리에 포함된 컬럼명을 추출하는 단계; (b) 추출된 컬럼명을 참조항목으로 하여 상기 요청 쿼리가 참조하는 테이블과 동일한 테이블을 참조하는 쿼리(이하 기초 쿼리)와, 상기 기초 쿼리의 결과 데이터를 참조하여 상기 요청 쿼리가 요청하는 결과 데이터를 가져오는 확장 쿼리를 생성하는 단계; (c) 상기 기초 쿼리의 결과 데이터를 캐시에서 검색하는 단계; (d) 상기 캐시에 기초 쿼리의 결과 데이터가 없으면, 상기 기초 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 기초 쿼리의 결과 데이터를 상기 캐시에 저장하는 단계; 및, (e) 상기 확장 쿼리를 상기 기초 쿼리의 결과 데이터에 적용하여 상기 확장 쿼리의 결과 데이터를 획득하고, 획득된 결과 데이터를 상기 클라이언트로 전송하는 단계를 포함하는 구성을 마련한다. 상기와 같은 방법에 의하여, 요청된 쿼리 중 기본 쿼리의 데이터를 캐싱함으로써, 비즈니스 인텔리전스의 분석 환경에서 쿼리 실행 속도를 획기적으로 개선하여 사용자에게 분석처리 결과를 실시간으로 제공해줄 수 있다.

Description

대용량 데이터를 처리하기 위한 2단계 쿼리 기반 온라인 분석 프로세싱 방법
본 발명은 클라이언트가 질의요청시 SQL파싱을 통해 기초 쿼리(Base Query)와 확장 쿼리(Extend Query)로 단계를 분리하여, 대용량 데이터 또는 빅데이터를 저장하는 데이터베이스로부터 상기 기초 쿼리에 의한 데이터를 가져와서 인메모리기반 서버 캐시에 저장하고, 상기 서버 캐시의 데이터로부터 확장 쿼리를 실행하여 필요 데이터를 추출하는, 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 관한 것이다.
일반적으로 비즈니스 인텔리전스(BI, Business Intelligence)는 기업의 방대한 데이터를 통계분석과 같은 정형 또는 비정형적인 방법으로 다양하게 분석하여 주거나 분석된 정보를 이해하기 쉽고 보기 좋은 보고서 형태로 가공하여, 비즈니스를 보다 합리적으로 진행시킬 수 있도록 지원하는 일련의 도구들을 말한다.
기업이 비즈니스를 하면서 쌓이는 데이터는 수없이 많다. 이러한 데이터는 비즈니스 현장의 생생한 내용을 전달하는 것으로서, 제대로 분석된다면 그 안에서 비즈니스에 필요한 정보를 뽑아낼 수 있다. 그러나 현장에서 축적된 상당량의 데이터로부터 의미가 있는 분석결과를 도출한다는 것은 그리 쉬운 작업이 아니다.
이러한 분석을 위해 많은 도구들이 개별적으로 개발되어 왔다. 예를 들어, 데이터 추출 및 변형(ETT) 도구, 다차원 데이터 분석을 위한 온라인 분석처리(OLAP) 도구, 보고서 작성을 위한 리포팅 도구, 데이터간의 숨겨진 연관성을 찾아주는 데이터 마이닝 도구 등이 대표적이다. 이들 일련의 도구들을 하나의 소프트웨어 제품군으로 형성한 것이 일종의 비즈니스 인텔리전스(BI)이다.
그러나 종래의 비즈니스 인텔리전스(BI)는 다양한 분석도구들을 모아 놓았으나, 사용자들은 다양한 분석도구들을 다루기 위해서 숙련된 지식을 갖추어야 했기 때문에 특정 분석이외에는 보편적으로 이용되기 어려웠다. 이런 점들을 개선하여, 웹 환경에서 데이터베이스를 조회하여 분석하는 레포팅 기술들이 제시되고 있다[특허문헌 1]. 또한, 온라인상에서 엑셀 인터페이스를 기반으로 하는 분석 보고서 작성 시스템 등도 제시되고 있다[특허문헌 2].
그런데, 최근, SNS, 쇼셜 미디어 등의 데이터에 대한 분석의 중요성이 계속적으로 커지면서 기업체의 제품에 대한 고객관리나 제품 홍보 등을 위한 빅데이터(Big data)를 수집하여 분석을 필요로 하는 기업들이 많아지고 있다. 빅데이터라는 용어는, 어느 정도 경과한 시간 내에 속한 데이터를 수집, 관리, 저장, 검색, 공유, 분석, 및 시각화하기 위한 보통의 소프트웨어 툴 및 컴퓨터 시스템으로는 다루기 어려운 수준의 데이터양을 갖는 데이터 셋(data set)에 대하여 주로 적용된다. 빅데이터의 사이즈 테라바이트, 엑사바이트, 또는 제타바이트의 범위를 가질 수도 있다. 빅데이터는 다양한 분야에 존재할 수 있는데, 웹로그(web logs), RFID, 센서 네트워크, 소셜 네트워크, 소셜 데이터, 인터넷 텍스트와 문서, 인터넷 검색 인덱싱, POS(point of sales) 데이터, 판매 기록, 의료 기록, 사진 기록, 비디오 기록, 및 전자상거래 등이 그 예이다.
이러한 빅데이터를 이용하여 분석하기 위하여 온라인 분석 프로세싱(OLAP; on-line analytical processing) 시스템이 도입되고 사용되는데, 이때 발생되는 가장 큰 문제점 중 하나는 데이터 처리 속도의 지연이다. 즉, 수많은 데이터를 처리하기 위한 시간이 길어짐으로 인해, 온라인 상에서 사용자가 체감적으로 굉장히 긴 시간을 기다린다.
도 1에서 보는 바와 같이, 종래 기술에 의한 온라인 분석 프로세싱 시스템은 사용자 단말에 설치되는 클라이언트, 상기 클라이언트의 데이터 요구사항을 처리하는 BI 서버, 및, 빅데이터를 저장하는 데이터베이스로 구성된다.
사용자는 웹브라우저 상에서 클라이언트를 통해 보고서 형태(또는 템플릿)를 만들고 해당 보고서 형태에 들어갈 데이터를 BI 서버에 요청한다(① 단계). 즉, 상기 클라이언트에서 작성된 보고서에서 추출한 데이터베이스 코드(DB코드), 쿼리(SQL 쿼리) 등 필요한 정보를 BI 서버로 전송한다. 다음으로, BI 서버는 데이터베이스를 연결하여 필요한 데이터를 요청한다(② 단계). 데이터베이스는 요청된 데이터의 셋(또는 쿼리 결과, 큐브 데이터 셋) 등을 검색하고 추출하여, 추출된 결과 데이터를 BI 서버로 전송한다(③ 단계). BI 서버는 데이터베이스로부터 수신한 필드 정보와 데이터를 압축하여 클라이언트로 전송한다(④ 단계).
상기와 같은 종래 온라인 분석 프로세싱 시스템은 원천 데이터가 천만 건이 넘는 순간부터, 앞서 쿼리 결과를 수신하기 위하여 10분 이상이 소요되는 경우가 빈번히 발생한다. 예를 들어, 특정 사이트의 경우, 4억 건 결과 조회만으로 5분이 넘게 소요된다. 데이터베이스의 데이터를 포맷하는 데에도 15~30초 사이의 시간이 소요된다.
이와 같이 데이터 처리 속도가 느린 이유는 데이터베이스에 요청하는 처리 속도가 급격히 떨어지기 때문이다. 데이터베이스는 통상 상용화되어 표준적인 DB(Database) 기능을 처리하는 데이터 서버를 이용한다. 이러한 상용화된 데이터베이스는 원천 테이블이 거대한 경우, 예를 들어, 데이터가 1억 개 이상되는 경우, 많은 데이터를 처리하기 위해 쿼리 처리 속도가 급격히 떨어진다.
특히, 뷰(View)의 기능을 사용하는 경우에도, 쿼리 처리 속도가 매우 느려진다. 일반적으로 뷰(View)란 하나 이상의 테이블로부터 데이터를 부분집합을 논리적으로 표현하는 것으로 실제 데이터를 가지고 있는 것이 아니라 결과를 하나의 SQL로 가지고 있다. 뷰(View)는 액세스를 제한하기 위해 사용하거나 복잡한 질의를 쉽게 만들 수 있지만 요청할 때마다 내부적으로 SQL를 실행한다. 따라서 원천의 뷰(View)가 거대하거나 복잡한 경우, 연결된 뷰(View)도 느려지는 경우가 발생한다. 또한, 쿼리 내에 조인(Join) 함수 등의 기능을 사용하여 쿼리 자체가 복잡한 경우에도, 그 처리 속도가 매우 느려진다.
상용화된 데이터베이스는 상기와 같은 문제점을 해결하고자 자체적으로 쿼리를 튜닝하여 보다 빠르게 쿼리를 처리하는 솔루션을 가지고 있다. 그러나 이러한 튜닝도 일반적인 상황을 대비한 것이므로, 자체 시스템에 대한 튜닝만으로는 어느 정도 한계를 갖기 때문에, 쿼리 속도 자체를 획기적으로 개선할 수 없다.
예를 들어, 상용화된 데이터베이스는 일반적이고 표준화된 경우만을 대처하기 때문에, 동일하거나 비슷한 쿼리 요청에 대해서 동일한 작업을 반복적으로 수행한다.
상기와 같은 문제로 인해, 종래기술에 의한 온라인 분석 프로세싱(OLAP) 시스템은 온라인 상에서 매우 긴 대기 시간을 발생시키고, 사용자에게 사용상 큰 불편함을 야기한다.
본 발명의 목적은 상술한 바와 같은 문제점을 해결하기 위한 것으로, 클라이언트가 질의 요청시 SQL 파싱을 통해 기초 쿼리와 확장 쿼리로 분리하여, 대용량 데이터 또는 빅데이터를 저장하는 데이터베이스로부터 상기 기초 쿼리에 의한 데이터를 가져와서 인메모리 기반 서버 캐시에 저장하고, 상기 서버 캐시의 데이터로부터 확장 쿼리를 실행하여 의해 필요 데이터를 추출하는, 2단계 쿼리 기반 온라인 분석 프로세싱 방법을 제공하는 것이다.
상기 목적을 달성하기 위해, 본 발명은 클라이언트가 요청하는 데이터베이스에 대한 요청 쿼리를 처리하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 관한 것으로서, (a) 상기 요청 쿼리를 파싱하여, 상기 요청 쿼리에 포함된 컬럼명을 추출하는 단계; (b) 추출된 컬럼명을 참조항목으로 하여 상기 요청 쿼리가 참조하는 테이블과 동일한 테이블을 참조하는 쿼리(이하 기초 쿼리)와, 상기 기초 쿼리의 결과 데이터를 참조하여 상기 요청 쿼리가 요청하는 결과 데이터를 가져오는 확장 쿼리를 생성하는 단계; (c) 상기 기초 쿼리의 결과 데이터를 상기 캐시에서 검색하는 단계; (d) 상기 캐시에 기초 쿼리의 결과 데이터가 없으면, 상기 기초 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 기초 쿼리의 결과 데이터를 상기 캐시에 저장하는 단계; 및, (e) 상기 확장 쿼리를 상기 기초 쿼리의 결과 데이터에 적용하여 상기 확장 쿼리의 결과 데이터를 획득하고, 획득된 결과 데이터를 상기 클라이언트로 전송하는 단계를 포함하는 것을 특징으로 한다.
또한, 본 발명은 클라이언트가 요청하는 데이터베이스에 대한 요청 쿼리를 처리하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 관한 것으로서, (a) 상기 요청 쿼리를 파싱하여, 상기 요청 쿼리에 포함된 컬럼명을 추출하는 단계; (b) 추출된 컬럼명을 참조항목으로 하여 상기 요청 쿼리가 참조하는 테이블과 동일한 테이블을 참조하는 쿼리(이하 기초 쿼리)와, 상기 기초 쿼리의 결과 데이터를 참조하여 상기 요청 쿼리가 요청하는 결과 데이터를 가져오는 확장 쿼리를 생성하는 단계; (c) 상기 기초 쿼리의 결과 데이터를 상기 캐시에서 검색하는 단계; (d) 상기 캐시에 기초 쿼리의 결과 데이터가 없으면, 상기 요청 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 요청 쿼리의 결과 데이터를 상기 클라이언트로 전송하는 단계; 및, (e) 상기 기초 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 기초 쿼리의 결과 데이터를 상기 캐시에 저장하는 단계를 포함하는 것을 특징으로 한다.
또한, 본 발명은 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 있어서, 상기 확장 쿼리의 결과 데이터를 캐시파일로 상기 캐시에 저장하고, 상기 방법은, (f) 상기 (b)단계 이후, 상기 확장 쿼리의 캐시파일이 상기 캐시에서 검색되는 경우, 검색된 캐시 파일을 클라이언트로 전송하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 발명은 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 있어서, 상기 (a)단계에서, 상기 컬럼명을 식별할 수 있는 고유키를 생성하고, 상기 (b)단계에서, 상기 기초 쿼리의 참조항목 절에서 상기 컬럼명에 대하여 상기 고유키로 앨리어스(alias)를 정의하고, 상기 확장 쿼리는 상기 앨리어스를 이용하여 컬럼을 참조하는 것을 특징으로 한다.
또한, 본 발명은 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 있어서, 상기 고유키는 해당 컬럼명의 데이터베이스의 이름, 참조 테이블의 이름, 및 컬럼명을 해쉬하여 구하는 것을 특징으로 한다.
또한, 본 발명은 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 있어서, 상기 (b)단계에서, 상기 기초 쿼리는 참조항목 절, 테이블 참조 절, 및 조건 절로 구성되고, 상기 기초 쿼리의 테이블 참조 절과 조건 절은 상기 요청 쿼리의 테이블 참조 절과 조건 절과 동일한 구조를 갖는 것을 특징으로 한다.
또한, 본 발명은 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 있어서, 상기 (b)단계에서, 상기 확장 쿼리는 테이블 참조 절에서 상기 기초 쿼리 또는 상기 기초쿼리의 결과 데이터를 참조하고, 상기 테이블 참조 절 이외의 절이 상기 요청 쿼리의 절과 동일한 구조를 갖도록 생성되는 것을 특징으로 한다.
또한, 본 발명은 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 있어서, 상기 (b)단계에서, 상기 요청 쿼리에서 테이블에 대한 앨리어스(alias)가 정의된 경우, 상기 테이블의 앨리어스를 삭제하고 상기 테이블의 앨리어스를 상기 테이블의 이름으로 대체하여 상기 확장 쿼리를 생성하는 것을 특징으로 한다.
또한, 본 발명은 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 있어서, 상기 캐시는 인메모리 스토리지와 캐시 디스크로 구성되고,상기 요청 기초 쿼리의 결과 데이터를 상기 인메모리 스토리지에 저장하는 특징으로 한다.
상술한 바와 같이, 본 발명에 따른 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 의하면, 요청된 쿼리 중 기본 쿼리의 데이터를 캐싱함으로써, 비즈니스 인텔리전스의 분석 환경에서 쿼리 실행 속도를 획기적으로 개선하여 사용자에게 분석처리 결과를 실시간으로 제공해줄 수 있는 효과가 얻어진다.
도 1은 종래 기술에 따른 온라인 분석 프로세싱 시스템의 구성도.
도 2는 본 발명에 따른 2단계 쿼리 기반 온라인 분석 프로세싱 방법을 실시하기 위한 전체 시스템의 구성에 대한 블록도.
도 3은 본 발명의 제1 실시예에 따른 2단계 쿼리 기반 온라인 분석 프로세싱 방법을 설명하는 흐름도.
도 4는 본 발명의 제1 실시예에 따른 요청 쿼리의 일례.
도 5는 본 발명의 제1 실시예에 따른 기초 쿼리 및 확장 쿼리의 일례.
도 6은 본 발명의 제2 실시예에 따른 2단계 쿼리 기반 온라인 분석 프로세싱 방법을 설명하는 흐름도.
도 7은 본 발명의 제3 실시예에 따른 2단계 쿼리 기반 온라인 분석 프로세싱 방법을 설명하는 흐름도.
도 8은 본 발명의 제4 실시예에 따른 서버 캐시의 구성도.
도 9는 본 발명에 따른 제1 상황을 설명하기 위한 흐름도.
도 10은 본 발명에 따른 제2 상황을 설명하기 위한 흐름도.
도 11은 본 발명에 따른 제3 상황을 설명하기 위한 흐름도.
도 12는 본 발명의 상황에 따른 처리 결과에 대한 비교 표.
이하, 본 발명의 실시를 위한 구체적인 내용을 도면에 따라서 설명한다.
또한, 본 발명을 설명하는데 있어서 동일 부분은 동일 부호를 붙이고, 그 반복 설명은 생략한다.
먼저, 본 발명에 따른 기초 쿼리의 결과 캐싱 기반 온라인 분석 프로세싱 시스템 및 방법을 실시하기 위한 전체 시스템을 도 2를 참조하여 설명한다.
도 2에서 보는 바와 같이, 본 발명을 실시하기 위한 전체 시스템은 클라이언트(20), 분석처리 서버(30), BI 서버(50), 및 데이터베이스(60)로 구성된다. 특히, 분석처리 서버(30)는 데이터베이스(60)로부터 수신한 일부 데이터를 저장하기 위한 서버 캐시(40)를 구비한다.
클라이언트(20)는 사용자 단말(10)에 설치되는 클라이언트용 프로그램 시스템으로서, 웹브라우저를 통해 사용자 인터페이스를 갖는다. 즉, 사용자는 웹브라우저 또는 웹브라우저와 같은 화면의 인터페이스를 통해, 온라인상으로 데이터 분석 처리 작업을 수행한다. 이때, 클라이언트(10)는 사용자의 명령 등을 입력받아 해당 명령을 수행하고, 처리 결과를 화면 상 또는 웹브라우저 상에 표시한다. 한편, 사용자 단말(10)은 개인용 컴퓨터(PC), PDA, 스마트폰 등 컴퓨팅 기능을 가지는 컴퓨터 단말이다.
또한, 클라이언트(20)는 데이터 요청, 데이터 분석 등 온라인 상으로 분석 처리하는 작업을 분석처리 서버(30)에 요청하고, 그 결과를 서버(30)로부터 가져와서 웹브라우저 상에 표시한다.
다음으로, 분석처리 서버(30)는 온라인 분석 프로세싱(OLAP)을 처리하는 서버로서, 클라이언트(20)로부터 데이터 분석에 대한 요청을 수신하여, 해당 분석 요청을 처리하여 그 결과를 클라이언트(20)로 전송하는 서버이다.
특히, 분석처리 서버(30)는 데이터를 요청하는 쿼리를 이용하여, 데이터베이스(50)에 저장된 데이터를 가져온다. 쿼리는 데이터베이스에 저장된 데이터의 검색 또는 갱신 시 발생하는 질문 또는 문의를 기술하는 데이터 조작언어를 의미하며, 데이터베이스에서 쿼리는 일종의 명령어와 같은 역할을 수행한다. 관계 데이터베이스의 구조적 질의 언어(Structured Query Language : 이하 SQL)의 형식으로 표현되지만, 경우에 따라서는 SQL 이외의 형식으로 표현될 수도 있다.
또한, 분석처리 서버(30)는 서버 캐시(40)를 구비하여, 데이터베이스(60)로부터 가져온 데이터 전체 또는 일부를 임시로 저장한다. 서버 캐시(40)는 분석처리 서버의 메모리(RAM 등) 상에 구현되어 캐시 메모리로서 구성되거나, 하드 디스크 또는 SSD(solid state disk) 디스크 등으로 구현되어 캐시 디스크로 구성될 수 있다. 또는 모든 데이터를 디스크로 저장하고, 일부의 데이터, 즉, 필요한 데이터를 캐시 메모리로 올려놓고 사용할 수 있다.
다음으로, BI 서버(50)는 데이터베이스(50)를 중계하는 데이터베이스(DB) 인터페이스 서버 역할을 수행한다. 즉, BI 서버(50)는 분석처리 서버(30)로부터 쿼리를 수신하여, 해당 쿼리를 이용하여 데이터베이스(60)의 데이터를 가져온다. 또는 데이터베이스(60)의 DBMS에 요청하여 해당 데이터를 가져온다.
또한, BI 서버(50)는 이질적인 다수의 데이터베이스(60)로 구성되더라도 해당 데이터베이스와의 인터페이스 방식에 맞추어, 쿼리를 요청하거나 데이터를 수신한다. 또한, BI 서버(50)는 데이터를 송수신할 때 암호화하거나, 데이터 압축, 또는 파일 압축 등 데이터 송수신을 위한 부가적인 작업들도 수행한다.
다음으로, 데이터베이스(60)는 데이터를 저장하기 위한 통상의 데이터베이스(DB)로서, 데이터를 관리하기 위한 DBMS를 구비하고, 데이터의 저장, 삭제, 검색 등의 작업들을 쿼리를 통해 수행한다. 특히, 데이터베이스(60)는 상용화된 데이터베이스로서, 데이터를 처리하기 위한 일반적인 쿼리 기능을 이용하여, 데이터 쿼리 서비스를 수행한다.
특히, 데이터베이스(60)는 빅데이터를 저장하는 데이터베이스이다. 또한, 바람직하게는, 데이터베이스(60)는 관계형 데이터베이스(RDB)로 구성된다.
다음으로, 본 발명의 제1 실시예에 따른 2단계 쿼리 기반 온라인 분석 프로세싱 방법을 도 3을 참조하여 보다 구체적으로 설명한다.
도 3에서 보는 바와 같이, 본 발명의 제1 실시예에 따른 2단계 쿼리 기반 온라인 분석 프로세싱 방법은 (a) 요청 쿼리를 수신하여 파싱하는 단계(S11); (b) 기초 쿼리 및 확장 쿼리를 생성하는 단계(S12); (c) 기초 쿼리의 결과를 서버 캐시에서 검색하는 단계(S13); (d) 검색되지 않으면, 기초 쿼리를 데이터베이스에서 가져와서 서버 캐시에 저장하는 단계(S14); (e) 상기 기초 쿼리의 결과에 확장 쿼리를 적용하여 요청 쿼리의 결과를 획득하는 단계(S15); 및, (f) 요청 쿼리의 결과를 전송하는 단계(S16)로 구성된다.
먼저, 요청 쿼리를 수신하여 파싱하는 단계(S11)를 설명한다. 분석처리 서버(30)는 클라이언트(20)로부터 요청 쿼리를 수신하고, 상기 요청 쿼리를 파싱한다(S11).
사용자 단말(10)에 설치된 클라이언트(20)에서, 필요한 데이터를 쿼리로 분석처리 서버(30)에 요청한다. 바람직하게는 요청 쿼리는 SQL 쿼리로 작성된다. 도 4는 요청 쿼리의 일례를 나타내고 있다.
SQL 쿼리로 작성된 요청 쿼리는 참조항목 절(SELECT 절), 테이블 절 및 조인 절(FROM 절), 조건 절(WHERE 절), 그룹 절(GROUP BY), 순서 절(ORDER BY) 등으로 구성된다. 참조항목 절(select list)은 원하는 데이터 테이블의 필드/컬럼을 정의하는 절이고, 테이블 절(table reference)은 데이터를 가져올 테이블을 정의하는 절이고, 조인 절(join clause)은 테이블 간의 조인을 정의하는 절이고, 조건 절(where clause)는 조건을 정의하는 절이다. 그리고 그룹 절(group by) 이나 순서 절(order by clause)는 집계나 표시 형태를 정의하는 절이다. 요청 쿼리에서 정의된 데이터 필드, 참조 테이블, 조건문에서의 변수 등은 모두 데이터베이스(60)에 있는 원천 데이터의 필드, 테이블 등을 참조한 것이다.
요청 SQL 쿼리의 파싱은 요청 SQL 쿼리의 구문을 분석하여, 컬럼 리스트(select list), 테이블 참조(table reference), 조인 절(join clause), 조건 절(where clause), 그룹 절(group by clause), 순서 절(order by clause) 등을 집합 형태로 추출하는 것이다.
특히, SELECT 절(또는 참조항목 절)의 참조항목에서 컬럼명을 추출한다. 또한, 조인 절, 조건 절, 그룹 절, 순서 절 등에서 참조하는 컬럼명들을 모두 추출한다.
요청 쿼리가 SQL 쿼리인 경우, 파싱을 위한 SQL 구문은 다음과 같다.
query_block
: (subquery_factoring_clause)?
SELECT (((DISTINCT | UNIQUE)| ALL)?) select_list
FROM ( table_reference | join_clause) (COMMA (table_reference | join_clause))*
where_clause?
hierarchical_query_clause?
group_by_clause?
order_by_clause?
| query_block ((UNION ALL?) | (INTERSECT | S_MINUS)) query_block
| LPAREN query_block RPAREN
특히, 참조항목이 계산식인 경우에 계산식 내에 포함된 컬럼명을 추출한다. 또한, 조건 절 등 다른 절에서 참조하는 조건이나 수식 등에서 사용되는 컬럼명들도 추출한다.
또한, 추출된 컬럼명에 대하여 다른 컬럼명과 식별할 수 있는 식별자 또는 고유키를 생성한다. 이때의 고유키는 컬럼의 절대이름에 대한 식별자(또는 고유키)이다. 절대이름이란 참조 데이터베이스의 이름, 참조 테이블의 이름, 컬럼명으로 구성된 이름을 말한다. 따라서 컬럼의 절대이름은 다음과 같이 표현될 수 있다.
컬럼의 절대이름 = <데이터베이스의 이름>.<테이블의 이름>.<컬럼명>
또는 데이터베이스를 굳이 식별하지 않으면 다음과 같이 표현될 수도 있다.
컬럼의 절대이름 = <테이블의 이름>.<컬럼명>
절대이름과 대비하여, 컬럼명을 컬럼의 상대이름이라고도 부르기로 한다.
컬럼명의 고유키는 컬럼명의 절대이름을 이용하여 해싱을 통해 구한다. 고유키를 생성하는 수식은 다음과 같다.
[수학식 1]
고유키 = hash( (domain name) + database name + table name + column name + function name)
따라서 컬럼명의 고유키는 컬럼들을 식별할 수 있는 식별자의 기능을 수행한다. 즉, 고유키로 컬럼을 식별할 수 있다.
컬럼명의 고유키는 기초쿼리 또는 요청쿼리를 생성할 때 앨리어싱(aliasing, 별칭)을 통해 각 컬럼명을 식별하는데 이용된다. 컬럼명의 고유키를 이용하여 기초쿼리의 컬럼명을 모두 별칭(alias)으로 기재하여, 기초쿼리에 의한 결과 데이터의 테이블에서의 컬럼명을 모두 고유키로 생성되도록 한다. 즉, 컬럼명을 식별자(또는 고유키)로 앨리어스(alias)하는 이유는 자동 생성된 쿼리에서 컬럼을 식별하기 위한 것이다.
예를 들면, 1번 쿼리과 2번 쿼리가 다음과 같다고 가정한다.
[1번 쿼리]
select t1. customer
from matirx_demo t1
[2번 쿼리]
select m.customer
from matrix_demo m
이 경우, 1번과 2번 쿼리에서 customer는 동일한 테이블의 동일한 컬럼이다. 하지만 alias키가 없기 때문에 t1.customer와 m.customer를 다르다고 판단할 수 있다.
또한, 1번과 2번 쿼리가 다음과 같다고 가정한다.
[1번 쿼리]
select t.id
from matrix_demo1 t
[2번 쿼리]
select t.id
from matrix_demo2 t
이 경우에도, 앨리어스(alias, 별칭)의 고유키가 없기 때문에 같게 보이나 실제로는 다른 컬럼들이다.
이때, 고유키를 적용하여 앨리어싱하면 다음과 같이 쿼리가 생성된다.
[1번 쿼리]
select t1. customer C9A59FD7B
from matirx_demo t1
[2번 쿼리]
2번 쿼리
select m.customer C9A59FD7B
from matrix_demo m
따라서, 고유키 “C9A59FD7B“만 보면 동일 데이터베이스명, 동일 테이블명, 동일 컬럼명, 동일 함수명인 것을 확인할 수 있다.
또한, 바람직하게는, 테이블 절에서 테이블명의 앨리어스(alias)를 제거하고, 테이블명의 앨리어스(alias)로 명명된 구문을 모두 원래의 테이블명으로 변경한다. 예를 들어, 앞서의 예에서, MATRIX_DEMO가 T로 앨리어스(alias)되어 명명되어 있다면 원테이블명(MATRIX_DEMO)으로 변경한다.
또한, 바람직하게는, 다수의 데이터베이스를 이용하는 경우, 테이블 참조절에서의 각 테이블명에 대한 테이블의 절대이름을 구한다. 테이블의 절대이름은 데이터베이스 이름과 테이블 이름으로 구성되고, <데이터베이스 이름>.<테이블 이름>으로 표현된다.
한편, 테이블 절과 조인(join) 절은 SQL 구문에서 "FROM"절에 포함된다. 즉, FROM 절은 테이블을 참조하기 위한 절로서, 테이블과 조인으로 구성된다. 따라서 이하에서 테이블 절과 조인 절을 포함된 절을 "테이블 참조 절"이라 부르기로 한다.
다음으로, 분석처리 서버(30)는 파싱한 요청 쿼리를 이용하여, 기초 쿼리와 확장 쿼리를 생성한다(S12).
기초 쿼리는 데이터베이스(60)의 데이터를 참조하여 요청하는 쿼리이고, 확장 쿼리는 기초 쿼리에 의해 추출된 데이터(또는 기초 쿼리의 결과 데이터)를 참조하여 요청하는 쿼리이다. 기초 쿼리와 확장 쿼리의 일례가 도 5에 도시되고 있다.
도 5에서 보는 바와 같이, 기초 쿼리(BaseSQL)에서, SELECT문에 기재된 "CUSTOMER", "PRODUCT", "C", "C2" 등 데이터 필드의 명칭나, "MATRIX_DEMO" 등 참조 테이블의 명칭이나, "YYYY" 등의 조건문의 변수(또는 데이터 필드의 변수)는 모두 데이터베이스(60)의 원천 데이터를 직접 참조한다.
먼저, 기초쿼리는 다음과 같이 생성한다.
SQL 파싱에서 추출한 컬럼명(또는 컬럼 리스트)으로 참조항목을 만든다. 이때, 바람직하게는, 요청쿼리의 참조항목이 계산식인 경우, 요청쿼리의 계산식에 포함된 컬럼명으로 기초쿼리의 참조항목을 생성한다. 또한, 조건 절 등 다른 절에서 참조하는 컬럼명들도 기초쿼리의 참조항목으로 생성한다.
도 4의 예에서, 요청쿼리의 3번째 참조항목은 "SUM(T.H_VAL)"의 계산식이다. 또한, 조건 절(where clause)에서 "T.YYYY = '2013'"은 조건이나 그 조건 내에 "T.YYYY" 컬럼명이 포함되어 있다. 따라서 도 5의 기초쿼리에서의 참조항목에는 계산식 "SUM(T.H_VAL)" 내의 컬럼명 "T.H_VAL"과, 조건 "T.YYYY = '2013'" 내의 컬럼명 "T.YYYY"을 참조항목 절의 참조항목으로 생성한다.
또한, 참조항목들에 컬럼명의 고유키를 앨리어싱(aliasing)을 한다. 즉, 고유키를 별칭으로 정의한다.
그리고 기초쿼리의 테이블 절(또는 테이블 참조절), 조인 절, 조건 절은 요청쿼리의 테이블 절, 조인 절, 조건 절과 동일하게 구성한다.
다만, 바람직하게는, 요청쿼리의 테이블 절에서 테이블명이 앨리어스(alias)되어 있으면, 앨리어스된 별칭을 삭제한다. 그리고 참조항목 절, 조인절, 조건 절에서 별칭이 기재된 테이블명을 모두 테이블의 이름(또는 절대이름)으로 변경한다.
예를 들어, 요청쿼리가 다음과 같은 경우를 설명한다.
[요청쿼리 1]
select t.customer, sum(t.h_val)
from matrix_demo t
where t.yyyy = ‘2013’
group by t.cusomer
이때, 상기 요청쿼리 1로부터 생성한 기초쿼리는 다음과 같다.
[기초쿼리 1]
SELECT MATRIX_DEMO.CUSTOMER C9A59FD7B, MATRIX_DEMO.YYYY CEB41FFF7, MATRIX_DEMO.H_VAL CB165E5C5
FROM MATRIX.MATRIX_DEMO
WHERE MATRIX_DEMO.YYYY = '2013’
즉, 요청쿼리에서 테이블 matrix_demo의 별칭(alias)을 "t"로 선언하였는데, 기초쿼리에서는 모두 테이블의 이름인 matrix_demo로 변경되었다.
다음으로, 확장쿼리를 생성한다.
확장쿼리는 테이블 절을 제외하고 요청쿼리와 동일한 구조를 갖고, 테이블 절에서 참조하는 테이블 대신 기초쿼리 또는 기초쿼리의 결과 데이터 테이블(기초쿼리가 원천 데이터베이스에서 쿼리하여 가져온 결과 테이블)을 참조한다.
또한, 컬럼명들을 모두 컬럼들의 고유키로 변환한다. 즉, 확장쿼리가 참조하는 테이블이 기초쿼리의 결과 테이블이므로, 참조하는 테이블의 컬럼들은 모두 기초쿼리에서 선언한 고유키로 참조하여야 한다.
앞서 [요청쿼리 1]과 [기초쿼리 1]에 의한 확장쿼리는 다음과 같다.
[확장쿼리 1]
SELECT MHC.C9A59FD7B, SUM(MHC.CB165E5C5) AS "CB165E5C5"
FROM ( {@ORIGINAL_SQL@} ) MHC
WHERE MHC.CEB41FFF7 = '2013'
GROUP BY
MHC.C9A59FD7B
여기서, "{@ORIGINAL_SQL@}" 는 기초쿼리 또는, 기초쿼리의 결과 테이블을 참조하는 것을 표시한다.
따라서 기초 쿼리에 의해 추출된 데이터가 획득되면, 확장 쿼리는 획득된 기초 쿼리의 결과 데이터를 참조하여 요청되는 쿼리이다. 확장 쿼리에 의해 구해지는 결과는 원래 요청 쿼리에 의해 구해지는 결과와 동일하다. 또한, 확장 쿼리에 의해 구해지는 결과 데이터의 집합은 항상 기초 쿼리에 의해 구해지는 결과 데이터의 집합 보다 작다. 즉, 확장 쿼리의 데이터 집합은 기초 쿼리의 데이터 집합의 부분 집합이라 할 수 있다.
또한, 기초쿼리의 결과 데이터가 없는 경우, [확장쿼리 1]에서, {@ORIGINAL_SQL@}에 기초쿼리를 대치하고 원천 데이비베이스의 질의하면, 요청쿼리의 결과를 얻을 수 있다.
다음으로, 기초 쿼리의 결과 데이터가 서버 캐시(40)에 저장되어 있는지를 검색한다(S13).
기초 쿼리에 의해 데이터베이스(60)로부터 가져온 데이터(또는 기초 쿼리의 결과 데이터)는 서버 캐시(40)에 저장하여 보관된다. 분석처리 서버(30)는 앞서 구한 기초 쿼리를 서버 캐시(40)에서 검색한다. 즉, 저장해둔 기초쿼리에 앞서 구한 기초쿼리가 존재하는지를 검색한다.
검색을 위한 비교 과정을 설명하면, 참조항목 절, 테이블 절/조인 절, 및, 조건 절이 동일한지 여부로 판단한다. 다면, 참조하는 테이블들(또는 테이블간의 조인도 포함됨)이 동일한 경우에는, 참조항목 절(SELECT 절)과 조건 절(where clasue)만 동일한가를 비교한다. 특히, 참조항목 절에서는 컬럼명의 고유키들만 비교하면 된다. 즉, 앨리어스(alias)들이 동일한지만 비교한다.
예를 들어, 본 출원인의 매트릭스(matrix)에서 사용되는 SQL는 메타를 이용해서 자동 생성된 SQL이다. 메타 아이템1과 메타 아이템 2를 선택했다면, 이미 해당 메타 아이템의 테이블 코드, 컬럼 코드, 조인 조건을 자동으로 생성할 수 있다. 같은 메타에서 자동 생성된 SQL는 필드 alias 비교만으로도 같다는 것을 알 수 있다. 즉, 추가로 조건 비교만 수행하면 기초쿼리를 재사용 여부를 체크할 수 있다. 하지만, 메타 없이 쿼리만 비교한다면 테이블 및 그들간의 조인 관계도 비교해야 한다.
다음으로, 기초 쿼리의 결과 데이터가 서버 캐시에 저장되어 있지 않으면, 상기 기초 쿼리로 데이터베이스(60)에 데이터를 요청하고, 기초 쿼리의 결과 데이터를 수신하면, 이를 서버 캐시(40)에 저장한다(S14).
앞서 설명한 바와 같이, 기초 쿼리는 데이터베이스(60)에 저장된 데이터를 직접 참조하는 쿼리이므로, 해당 기초 쿼리로 데이터베이스(60)에 쿼리 요청을 한다. 쿼리 요청은 BI 서버(50)를 통해 데이터베이스(60)에 요청되고, 데이터베이스(60)에서 상기 기초 쿼리에 의해 추출된 데이터는 BI 서버(50)를 통해 분석처리 서버(30)로 리턴된다. 분석처리 서버(30)는 수신한 상기 기초 쿼리의 결과 데이터를 서버 캐시(50)에 저장한다.
한편, 기초 쿼리의 결과 데이터는 데이터베이스(60)의 데이터 구조와 동일한 형태 또는 동일한 구조로 저장된다. 즉, 데이터베이스(60)의 데이터들이 테이블 형태로 저장된다면, 기초 쿼리의 결과 데이터도 테이블 형식으로 저장된다. 또한, 서버 캐시(40)에서 저장되는 결과 데이터의 각 필드의 타입이나 크기 등이 데이터베이스(60)에서 구성된 필드의 타입이나 크기와 동일하게 구성된다. 이것은 확장 쿼리가 데이터베이스(60)에 저장된 데이터 대신, 기초 쿼리의 결과 데이터를 참조하여도 쿼리가 실행되게 하기 위함이다.
이때, 결과 테이블의 컬럼명은 컬럼의 고유키로 변환된다.
다음으로, 분석처리 서버(30)는 기초 쿼리의 결과에 확장 쿼리를 적용하여 요청 쿼리의 결과를 획득한다(S15).
확장 쿼리는 요청 쿼리와 동일한 구조를 가지고 데이터베이스(60)를 참조하는 대신 기초 쿼리를 참조하는 쿼리이다. 따라서 확장 쿼리에서 데이터베이스(60)를 참조하는 명칭(이하 데이터베이스 참조 명칭)들을 기초 쿼리의 결과 데이터를 참조하는 명칭(이하 기초 쿼리 참조 명칭)들로 변경하여 생성된다. 앞서 설명한 바와 같이, 확장 쿼리에서 참조하는 테이블의 명칭은 기초 쿼리에 의해 생성된 테이블(또는 결과 테이블)을 참조하도록 모두 변경되고, 확장 쿼리에서 참조하는 데이터 필드의 명칭(또는 컬럼명)은 모두 기초 쿼리에 의해 생성된 데이터 필드의 명칭(또는 컬럼명의 고유키)들로 모두 변경된다.
앞서 S13 단계에서, 기초 쿼리의 결과 데이터가 서버 캐시(40)에 저장되어 있을 수도 있고, 없을 수도 있다. 그러나 저장되어 있지 않은 경우, S14 단계에서, 기초 쿼리로 데이터베이스(60)에 쿼리 요청하여 데이터를 받아 서버 캐시(40)에 저장한다. 따라서 이번 단계(S15)에서는, 기초 쿼리의 결과 데이터는 서버 캐시(40)에 반드시 저장되어 있다.
또한, 확장 쿼리는 기초 쿼리의 데이터들을 참조하는 쿼리이다. 따라서 확장 쿼리를 기초 쿼리의 결과 데이터에 적용할 수 있다. 기초 쿼리의 결과 데이터를 참조하여 확장 쿼리를 적용하면, 원래 요청된 요청 쿼리의 결과 데이터를 구할 수 있다.
마지막으로, 앞서 확장 쿼리를 적용하여 구한 결과 데이터를 요청 쿼리의 결과로서, 클라이언트(20)에 전송한다(S16).
다음으로, 본 발명의 제2 실시예에 따른 2단계 쿼리 기반 온라인 분석 프로세싱 방법을 도 6을 참조하여 보다 구체적으로 설명한다.
도 6에서 보는 바와 같이, 본 발명의 제2 실시예에 따른 2단계 쿼리 기반 온라인 분석 프로세싱 방법은 (a) 요청 쿼리를 수신하여 파싱하는 단계(S21); (b) 기초 쿼리와 확장 쿼리를 생성하는 단계(S22); (c) 기초 쿼리의 결과를 서버 캐시에서 검색하는 단계(S23); (d) 검색되지 않으면, 요청 쿼리를 데이터베이스에서 가져와서 전송하는 단계(S24); (h) 기초 쿼리를 데이터베이스에서 가져와서 서버 캐시에 저장하는 단계(S28); (e) 검색되면, 확장 쿼리를 실행하는 단계(S25); (f) 상기 기초 쿼리의 결과에 확장 쿼리를 적용하여 요청 쿼리의 결과를 획득하는 단계(S26); 및, (g) 요청 쿼리의 결과를 전송하는 단계(S27)로 구성된다.
앞서 설명한 제1 실시예와 비교하면, 기초 쿼리를 서버 캐시에 검색하였을 때, 서버 캐시에서 기초 쿼리를 검색하지 못하면 요청 쿼리로 데이터베이스(60)에 요청하여 그 결과를 바로 클라이언트(20)에 전송하는 점(S24)에서 차이가 있다. 그리고 요청쿼리의 결과 데이터를 전송한 후, 기초 쿼리를 다시 데이터베이스(60)에 요청하여 기초 쿼리의 결과 데이터를 서버 캐시(40)에 저장한다(S28). 이하에서, 설명 중 생략된 부분은 앞서 설명한 제1 실시예의 설명을 참조한다.
먼저, 분석처리 서버(30)는 클라이언트(20)로부터 요청 쿼리를 수신하여 파싱한다(S21). 앞서 제1 실시예와 동일하다. 다음으로, 분석처리 서버(30)는 파싱 결과를 이용하여 기초 쿼리 및 확장 쿼리를 생성한다(S22).
그리고 기초 쿼리의 결과 데이터가 서버 캐시(40)에 저장되어 있는지를 검색한다(S23). 기초 쿼리에 의해 데이터베이스(60)로부터 가져온 데이터(또는 기초 쿼리의 결과 데이터)는 서버 캐시(40)에 저장하여 보관된다. 분석처리 서버(30)는 앞서 구한 기초 쿼리를, 서버 캐시(40)에 결과 데이터를 저장해둔 기초 쿼리들과 대비하여, 검색한다.
다음으로, 기초 쿼리의 결과 데이터가 서버 캐시에 저장되어 있지 않으면, 상기 요청 쿼리로 데이터베이스(60)에 데이터를 요청하고, 상기 요청 쿼리의 결과 데이터를 수신하면, 이를 클라이언트(20)에 전송한다(S24). 이때, 확장 쿼리 내에서 테이블 절을 기초쿼리로 대치한 후, 확장쿼리를 바로 데이터베이스(60)에 요청하여도, 원하는 결과 데이터(또는 결과 테이블)를 획득할 수 있다.
클라이언트(20)에 요청 쿼리의 결과 데이터를 전송한 후, 분석처리 서버(30)는 상기 기초 쿼리로 데이터베이스(60)에 데이터를 요청하고, 기초 쿼리의 결과 데이터를 수신하면, 이를 서버 캐시(40)에 저장한다(S28). 특히, 분석처리 서버(30)는 스케쥴러에 의해, 데이터베이스(60)의 요청이 많지 않고 트래픽에 여유가 있는 시간에 상기 기초 쿼리에 대한 데이터를 요청하여 그 결과를 서버 캐시(40)에 저장한다.
다음으로, 기초 쿼리의 결과 데이터가 서버 캐시에 저장된 경우를 설명한다. 분석처리 서버(30)는 기초 쿼리의 결과 데이터에 확장 쿼리를 적용하여 요청 쿼리의 결과를 획득한다(S25). 획득된 결과 데이터를 클라이언트(20)에 전송한다(S26).
다음으로, 본 발명의 제3 실시예에 따른 2단계 쿼리 기반 온라인 분석 프로세싱 방법을 도 7를 참조하여 보다 구체적으로 설명한다.
도 3에서 보는 바와 같이, 본 발명의 제3 실시예에 따른 2단계 쿼리 기반 온라인 분석 프로세싱 방법은 (a) 요청 쿼리를 수신하여 파싱하는 단계(S31); (b) 기초 쿼리와 확장 쿼리로 생성하는 단계(S31); (c) 상기 기초 쿼리와 확장 쿼리를 조합하여 캐시파일에서 검색하는 단계(S32); (d) 검색되면, 캐시파일을 클라이언트로 전송하는 단계(S33); (e) 검색되지 않으면, 제1 또는 제2 실시예를 수행하는 단계(34); 및 (f) 요청 쿼리의 결과 데이터를 캐시파일로 저장하는 단계(S35)로 구성된다.
본 발명의 제3 실시예는 앞서 설명한 제1 또는 제2 실시예를 보완하는 실시예이다. 즉, 요청 쿼리의 결과 데이터를 캐시파일로 바이너리 형태로 저장하였다가 동일한 쿼리로 다시 요청되면, 해당 캐시파일을 바로 클라이언트(20)에 전송한다.
캐시파일이란 요청 쿼리의 결과 데이터를 파일로 저장한 것을 말한다. 분석처리 서버(30)가 클라이언트(20)가 요청한 결과 데이터를 만들어 최종적으로 전송할 때, 파일 형태로 전송한다. 캐시파일은 전송할 때와 동일한 파일이다. 따라서 캐시파일의 쿼리와 동일한 요청 쿼리로 요청하면, 해당 캐시파일을 바로 전송해주면 된다.
바람직하게는, 캐시파일은 분석처리 서버(40)의 서버 캐시(40)에 저장된다.
구체적으로, 분석처리 서버(30)는 클라이언트(20)로부터 요청 쿼리를 수신하여 파싱한다(S30). 앞서 제1 또는 제2 실시예와 동일하다. 분석처리 서버(30)는 기초쿼리와 확장쿼리를 조합하여, 저장된 캐시파일의 쿼리를 비교하여, 동일한 쿼리가 있는지를 검색한다(S32).
만약 동일한 쿼리가 캐시파일에 있다면, 검색된 캐시파일을 바로 클라이언트(20)에 전송한다(S33).
만약 동일한 쿼리가 없다면, 앞서 설명한 제1 또는 제2 실시예의 3번째 검색 단계(S13,S23)를 수행한다(S34). 즉, 서버 캐시에 기초 쿼리의 결과 데이터가 있는지를 검색한다. 서버 캐시에 기초 쿼리의 결과 데이터가 있으면, 기초 쿼리를 대상으로 확장쿼리를 만들어 결과 데이터를 획득한다. 획득된 결과 데이터를 클라이언트에 전송한다. 서버 캐시에 기초 쿼리의 결과 데이터가 없으면, 기초 쿼리 또는 요청 쿼리로 데이터베이스(60)로부터 결과 데이터를 가져온다. 가져온 결과 데이터가 기초쿼리 데이터이면 확장 쿼리를 통해 요청 쿼리의 결과 데이터를 생성한다. 최종적으로 요청 쿼리의 결과 데이터를 클라이언트(20)에 전송한다.
제1 또는 제2 실시예를 완료하면, 생성된 기초쿼리 및 확장쿼리의 조합의 결과 데이터(또는 클라이언트에 전송한 결과 데이터)를 캐시파일로 서버 캐시(40)에 저장한다(S36).
다음으로, 본 발명의 제4 실시예에 따른 2단계 쿼리 기반 온라인 분석 프로세싱 방법을 도 8을 참조하여 구체적으로 설명한다.
본 발명의 제4 실시예는 앞서 설명한 제1 내지 제3 실시예와 동일한 구성을 가진다. 다만, 서버 캐시(40)의 구성이 보다 세분화된다.
도 8에서 보는 바와 같이, 본 발명의 제4 실시예는 서버 캐시(40)를 캐시 메모리(41)와 캐시 디스크(42)로 구성한다.
캐시 메모리(41)는 분석처리 서버(30)의 RAM(Random access memory)으로 구성된다. 특히, 캐시 메모리(41)는 인메모리 스토리지로 구성된다. 캐시 디스크(42)는 분석처리 서버(30)의 하드 디스크 또는 SSD(Solid State Disk) 등으로 구성된다.
앞서 본 발명의 제1 내지 제3 실시예에서, 서버 캐시(40)에 저장되는 기초 쿼리의 결과 데이터는 모두 캐시 메모리(41)에 저장된다. 다만, 캐시 메모리(41)의 저장 용량 보다 기초 쿼리의 결과 데이터가 더 많은 경우, 캐시 메모리의 용량을 초과하는 결과 데이터는 캐시 디스크(42)에 저장된다.
이때, 캐시 디스크(42)로 옮겨지는 기초 쿼리의 결과 데이터는 사전에 정해진 정책에 의해 선별된다. 선별 정책의 예로서, 결과 데이터에 대한 접근 빈도, 최근 접근 시각 등을 기초로 하여, 접근 빈도가 낮거나 최근 접근 시각이 가장 오래된 결과 데이들을 선별한다.
또한, 제3 실시예의 캐시파일은 캐시 디스크(42)에 저장된다.
본 발명의 효과를 도 9 내지 도 12를 참조하여 보다 구체적으로 설명한다.
본 발명은 비즈니스 인텔리전스(BI, Business Intelligence) 기반의 빅데이터를 처리를 위한 플랫폼에 관한 것이다. 특히, 빅데이터를 요청하였을 때 응답시간을 10초 이내의 빠른 시간 내에 처리함으로써, 실시간에 가까운 처리를 위한 것이다. 본 발명은 실시간에 가까운 처리를 위한 캐시 파일과 캐시 메모리 테이블을 사용한다. 이를 위해 요청 퀴리를 파싱하여, 기초 쿼리와 확장 쿼리로 분리한다.
또한, 메모리의 한계에 따른 파일 형태의 로딩/저장/필터링의 구조를 정의한다. 예를 들면 1억 건 정도 메모리 테이블에 로딩하는데 5G 정도 소요된다면, 32G 서버 환경이라면 10억 건 정도를 메모리에 가지고 있을 수 없다. 그러므로 일부 데이터를 파일 형태로 빠르게 저장하고 필요시 다시 메모리로 로딩하는 구조가 필요하다. 파일 자체에 조건(필터링과 쿼리를 파싱하여 해당 컬럼에서 조건 추출)으로 원하는 데이터만 처리한다.
또한, 요청 쿼리를 기초 쿼리(BaseSQL)와 확장 쿼리로 단계를 분리하는 이유는 상대적으로 속도가 떨어지는 관계형 데이터베이스(RDB)를 사용하는 것이 아니라, 분석처리 서버(30)에 구비된 서버 캐시(인메모리 데이터베이스)를 사용하기 위해서다. 이를 통해, 속도가 획기적으로 개선된다. 인메모리 데이터베이스(In-memory Database)는 데이터 스토리지의 메인 메모리에 설치되어 운영되는 방식의 데이터베이스 관리 시스템이다. 디스크에 설치되는 방식에 비해 처리 속도가 빠르다.
구체적으로, 본 발명의 제1 내지 제4 실시예를 적용하는 경우, 각 상황에서의 처리 속도를 설명한다.
먼저, 제1 상황은 기초 쿼리와 확장 쿼리가 모두 불일치하는 경우이다. 즉, 제1 상황은 최초로 쿼리가 실행되는 경우에 해당되며, 전체 처리속도는 종래 기술에 의한 시스템과 동일하게 소요된다.
도 9에서 보는 바와 같이, 먼저, 매트릭스(Matrix) 보고서에서 추출한 DB 코드, SQL 정보를 기초 쿼리(BaseSQL)와 확장 쿼리(ExtendSQL)로 분리하여 분석처리 서버(SOLAP 서버)에 요청한다(① 단계). 일치하는 기초 쿼리(BaseSQL)와 확장 쿼리(ExtendSQL)가 없기 때문에, 쿼리를 원래 요청 쿼리로 하여 BI 서버(Matrix Server)에 요청한다(② 단계). BI 서버에서 타겟 DB를 연결하여 데이터를 요청한다(③ 단계). 타겟 DB에서 큐브(cube) 데이터를 보내 준다(④ 단계). 그리고 필드 정보와 데이터를 압축해서 보내 준다(⑤ 단계). 보내준 파일을 캐시 파일로 저장한다(⑥ 단계). 캐시 파일을 브라우저(또는 클라이언트)에 보내 준다(⑦ 단계). 마지막으로, 스케줄러가 기초 쿼리(BaseSQL)를 원천 DB에서 실행하여 캐시 메모리(40)에 저장(Background 실행)한다(⑧ 단계).
다음으로, 제2 상황은 기초 쿼리는 일치하고, 확장 쿼리는 불일치하는 경우이다. 기초 쿼리(BaseSQL)에 해당하는 캐시 메모리 테이블을 생성된 경우에 해당되며 속도는 10초 내외 로서, 제1 상황(또는 종래 기술)에 비하여 10 ~ 50배 향상된다.
도 10에서 보는 바와 같이, 먼저, 매트릭스(Matrix) 보고서에서 추출한 DB 코드, SQL 정보를 기초 쿼리(BaseSQL)와 확장 쿼리(ExtendSQL)로 분리하여 SOLAP 서버에 요청한다(① 단계). 기초 쿼리(BaseSQL)가 일치하고 확장 쿼리(ExtendSQL)가 없는 경우 확장 쿼리(ExtendSQL)의 타겟 테이블은 서버 캐시에 저장된 테이블 명으로 변경하여 실행한다(② 단계). 그리고 서버 캐시에서 cube 데이터를 보내준다(③ 단계). 보내준 파일을 캐시 파일로 저장한다(④ 단계). 마지막으로,캐시 파일을 브라우저에 보내준다(⑤ 단계).
다음으로, 제3 상황은 기초 쿼리와 확장 쿼리가 모두 일치하는 경우이다. 기초 쿼리(BaseSQL)와 확장 쿼리(ExtendSQL) 모두 일치하는 경우에 해당되며 속도는 3초 내외로서, 제1 상황 또는 종래 기술에 비하여, 100배 이상 향상된다.
도 11에서 보는 바와 같이, Matrix 보고서에서 추출한 DB코드, SQL 정보를 기초 쿼리(BaseSQL)와 확장 쿼리(ExtendSQL)로 분리하여 분석처리 서버에 요청한다(① 단계). 기초 쿼리(BaseSQL)와 확장 쿼리(ExtendSQL)가 모두 일치하는 경우 해시키값이 존재한다(② 단계). 그리고 캐시 파일을 브라우저에 보내준다(③ 단계).
상기 제1 내지 제3 상황의 처리 속도 등을 비교한 표가 도 12에 도시되고 있다. 동일한 쿼리가 실행되면 상태가 자동으로 넘어간다. 즉, 제1 상황에서, 제2 상황으로, 제2 상황에서 제3 상황으로 넘어간다. 또한, 동시 사용자 수가 증가하면 캐시 파일 사용 빈도가 급격하게 증가한다(90% 이상으로 예상된다). 대다수의 사용자들은 5분에서 3초로 쿼리 시간 감소를 경험하게 된다. 또한, 최초의 실행에서, 기초 쿼리에 대한 데이터는 스케줄러로 실행할 수 있다. 즉, 스케줄러를 통해 여유있는 시간에 데이터를 가져올 수 있어, 체감 속도에 영향을 주지 않는다.
이상, 본 발명자에 의해서 이루어진 발명을 실시 예에 따라 구체적으로 설명하였지만, 본 발명은 실시 예에 한정되는 것은 아니고, 그 요지를 이탈하지 않는 범위에서 여러 가지로 변경 가능한 것은 물론이다.

Claims (9)

  1. 클라이언트가 요청하는 데이터베이스에 대한 요청 쿼리를 처리하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 있어서,
    (a) 상기 요청 쿼리를 파싱하여, 상기 요청 쿼리에 포함된 컬럼명을 추출하는 단계;
    (b) 추출된 컬럼명을 참조항목으로 하여 상기 요청 쿼리가 참조하는 테이블과 동일한 테이블을 참조하는 쿼리(이하 기초 쿼리)와, 상기 기초 쿼리의 결과 데이터를 참조하여 상기 요청 쿼리가 요청하는 결과 데이터를 가져오는 확장 쿼리를 생성하는 단계;
    (c) 상기 기초 쿼리의 결과 데이터를 캐시에서 검색하는 단계;
    (d) 상기 캐시에 기초 쿼리의 결과 데이터가 없으면, 상기 기초 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 기초 쿼리의 결과 데이터를 상기 캐시에 저장하는 단계; 및,
    (e) 상기 확장 쿼리를 상기 기초 쿼리의 결과 데이터에 적용하여 상기 확장 쿼리의 결과 데이터를 획득하고, 획득된 결과 데이터를 상기 클라이언트로 전송하는 단계를 포함하는 것을 특징으로 하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법.
  2. 클라이언트가 요청하는 데이터베이스에 대한 요청 쿼리를 처리하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법에 있어서,
    (a) 상기 요청 쿼리를 파싱하여, 상기 요청 쿼리에 포함된 컬럼명을 추출하는 단계;
    (b) 추출된 컬럼명을 참조항목으로 하여 상기 요청 쿼리가 참조하는 테이블과 동일한 테이블을 참조하는 쿼리(이하 기초 쿼리)와, 상기 기초 쿼리의 결과 데이터를 참조하여 상기 요청 쿼리가 요청하는 결과 데이터를 가져오는 확장 쿼리를 생성하는 단계;
    (c) 상기 기초 쿼리의 결과 데이터를 캐시에서 검색하는 단계;
    (d) 상기 캐시에 기초 쿼리의 결과 데이터가 없으면, 상기 요청 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 요청 쿼리의 결과 데이터를 상기 클라이언트로 전송하는 단계; 및,
    (e) 상기 기초 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 기초 쿼리의 결과 데이터를 상기 캐시에 저장하는 단계를 포함하는 것을 특징으로 하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법.
  3. 제1항 또는 제2항에 있어서,
    상기 확장 쿼리의 결과 데이터를 캐시파일로 상기 캐시에 저장하고,
    상기 방법은,
    (f) 상기 (b)단계 이후, 상기 확장 쿼리의 캐시파일이 상기 캐시에서 검색되는 경우, 검색된 캐시 파일을 클라이언트로 전송하는 단계를 더 포함하는 것을 특징으로 하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법.
  4. 제1항 또는 제2항에 있어서,
    상기 (a)단계에서, 상기 컬럼명을 식별할 수 있는 고유키를 생성하고,
    상기 (b)단계에서, 상기 기초 쿼리의 참조항목 절에서 상기 컬럼명에 대하여 상기 고유키로 앨리어스(alias)를 정의하고, 상기 확장 쿼리는 상기 앨리어스를 이용하여 컬럼을 참조하는 것을 특징으로 하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법.
  5. 제4항에 있어서,
    상기 고유키는 해당 컬럼명의 데이터베이스의 이름, 참조 테이블의 이름, 및 컬럼명을 해쉬하여 구하는 것을 특징으로 하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법.
  6. 제1항 또는 제2항에 있어서,
    상기 (b)단계에서, 상기 기초 쿼리는 참조항목 절, 테이블 참조 절, 및 조건 절로 구성되고, 상기 기초 쿼리의 테이블 참조 절과 조건 절은 상기 요청 쿼리의 테이블 참조 절과 조건 절과 동일한 구조를 갖는 것을 특징으로 하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법.
  7. 제6항에 있어서,
    상기 (b)단계에서, 상기 확장 쿼리는 테이블 참조 절에서 상기 기초 쿼리 또는 상기 기초쿼리의 결과 데이터를 참조하고, 상기 테이블 참조 절 이외의 절이 상기 요청 쿼리의 절과 동일한 구조를 갖도록 생성되는 것을 특징으로 하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법.
  8. 제7항에 있어서,
    상기 (b)단계에서, 상기 요청 쿼리에서 테이블에 대한 앨리어스(alias)가 정의된 경우, 상기 테이블의 앨리어스를 삭제하고 상기 테이블의 앨리어스를 상기 테이블의 이름으로 대체하여 상기 확장 쿼리를 생성하는 것을 특징으로 하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법.
  9. 제1항 또는 제2항에 있어서,
    상기 캐시는 인메모리 스토리지와 캐시 디스크로 구성되고,
    상기 기초 쿼리의 결과 데이터를 상기 인메모리 스토리지에 저장하는 것을 특징으로 하는 2단계 쿼리 기반 온라인 분석 프로세싱 방법.
PCT/KR2015/006300 2015-06-22 2015-06-22 대용량 데이터를 처리하기 위한 2단계 쿼리 기반 온라인 분석 프로세싱 방법 WO2016208779A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/KR2015/006300 WO2016208779A1 (ko) 2015-06-22 2015-06-22 대용량 데이터를 처리하기 위한 2단계 쿼리 기반 온라인 분석 프로세싱 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/KR2015/006300 WO2016208779A1 (ko) 2015-06-22 2015-06-22 대용량 데이터를 처리하기 위한 2단계 쿼리 기반 온라인 분석 프로세싱 방법

Publications (1)

Publication Number Publication Date
WO2016208779A1 true WO2016208779A1 (ko) 2016-12-29

Family

ID=57586533

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2015/006300 WO2016208779A1 (ko) 2015-06-22 2015-06-22 대용량 데이터를 처리하기 위한 2단계 쿼리 기반 온라인 분석 프로세싱 방법

Country Status (1)

Country Link
WO (1) WO2016208779A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110515987A (zh) * 2019-08-30 2019-11-29 恩亿科(北京)数据科技有限公司 一种数据分析结果的查询方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011253299A (ja) * 2010-06-01 2011-12-15 Nippon Telegr & Teleph Corp <Ntt> 検索装置、検索方法及び検索プログラム
US20120084315A1 (en) * 2010-10-04 2012-04-05 Sybase, Inc. Query Plan Optimization for Prepared SQL Statements
US8380703B2 (en) * 2010-07-26 2013-02-19 International Business Machines Corporation Feedback loop between a query optimizer and a cache manager
US20140108331A1 (en) * 2010-11-22 2014-04-17 Sap Ag OLAP Execution Model Using Relational Operations
KR20140046257A (ko) * 2012-10-10 2014-04-18 (주)티베로 쿼리의 최적화를 위한 방법
KR101544560B1 (ko) * 2014-04-02 2015-08-17 (주)비아이매트릭스 대용량 데이터를 처리하기 위하여 ｓｑｌ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011253299A (ja) * 2010-06-01 2011-12-15 Nippon Telegr & Teleph Corp <Ntt> 検索装置、検索方法及び検索プログラム
US8380703B2 (en) * 2010-07-26 2013-02-19 International Business Machines Corporation Feedback loop between a query optimizer and a cache manager
US20120084315A1 (en) * 2010-10-04 2012-04-05 Sybase, Inc. Query Plan Optimization for Prepared SQL Statements
US20140108331A1 (en) * 2010-11-22 2014-04-17 Sap Ag OLAP Execution Model Using Relational Operations
KR20140046257A (ko) * 2012-10-10 2014-04-18 (주)티베로 쿼리의 최적화를 위한 방법
KR101544560B1 (ko) * 2014-04-02 2015-08-17 (주)비아이매트릭스 대용량 데이터를 처리하기 위하여 ｓｑｌ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110515987A (zh) * 2019-08-30 2019-11-29 恩亿科(北京)数据科技有限公司 一种数据分析结果的查询方法及装置

Similar Documents

Publication Publication Date Title
US10152513B2 (en) Managing record location lookup caching in a relational database
US8886617B2 (en) Query-based searching using a virtual table
US6567816B1 (en) Method, system, and program for extracting data from database records using dynamic code
WO2010123168A1 (ko) 데이터베이스 관리 방법 및 시스템
KR101544560B1 (ko) 대용량 데이터를 처리하기 위하여 ｓｑｌ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법
CN112506964B (zh) 数据查询方法、系统及计算机可读存储介质
EP2391955A1 (en) Document analysis system
WO2017146338A1 (ko) 인덱스정보를 생성하는 데이터베이스의 아카이빙 방법 및 장치, 인덱스정보를 포함하는 아카이빙된 데이터베이스의 검색 방법 및 장치
KR102368775B1 (ko) 인덱스 관리 방법, 장치, 기기 및 저장 매체
KR20110037889A (ko) 구조화된 데이터 소스들과 비구조화된 데이터 소스들간의 상호 검색 및 경보
US9524305B2 (en) Boolean term conversion for null-tolerant disjunctive predicates
WO2018097407A1 (ko) 사용자 정의 erp 펑션 공유 방법 및 시스템
WO2018182060A1 (ko) 관계형 데이터베이스 기반의 텍스트 로그데이터 저장 및 검색 방법
WO2016208779A1 (ko) 대용량 데이터를 처리하기 위한 2단계 쿼리 기반 온라인 분석 프로세싱 방법
US11301441B2 (en) Information processing system and information processing method
WO2021141292A1 (ko) 하이브리드 클라우드 기반의 실시간 데이터 아카이빙 방법 및 시스템
WO2017191877A1 (ko) 프로버넌스 관리를 위한 압축 장치 및 방법
WO2022030670A1 (ko) 쿼리를 이용한 프레임워크 딥러닝 학습 시스템 및 방법
WO2011025162A2 (ko) 특정 클래스에 속하는 엔터티의 리스트 검색 방법
KR101820108B1 (ko) 캐시 테이블 통합 기반 2단계 쿼리 처리 시스템
WO2015178554A1 (ko) 압축 방식을 이용한 데이터 소스 관리 장치 및 방법
WO2024071504A1 (ko) 서로 다른 프로세서 자원을 할당하여 정형 데이터와 비정형 데이터를 처리하는 방법 및 이러한 방법을 제공하는 데이터 처리 시스템
WO2024019225A1 (ko) 복수의 서로 다른 데이터베이스 상의 정형 데이터와 비정형 데이터를 처리하는 방법 및 이러한 방법을 제공하는 데이터 처리 플랫폼
WO2024019224A1 (ko) 데이터베이스 상에서 정형 데이터와 비정형 데이터를 처리하는 방법 및 이러한 방법을 제공하는 데이터 처리 플랫폼
US9754030B2 (en) Free text search engine system and method

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15896413

Country of ref document: EP

Kind code of ref document: A1