WO2024005252A1 - 데이터 제공 방법 및 그 장치 - Google Patents

데이터 제공 방법 및 그 장치 Download PDF

Info

Publication number
WO2024005252A1
WO2024005252A1 PCT/KR2022/010024 KR2022010024W WO2024005252A1 WO 2024005252 A1 WO2024005252 A1 WO 2024005252A1 KR 2022010024 W KR2022010024 W KR 2022010024W WO 2024005252 A1 WO2024005252 A1 WO 2024005252A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
file
database
information
request
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/KR2022/010024
Other languages
English (en)
French (fr)
Inventor
카델프라카쉬
박정준
강구
박종훈
이진운
황수현
권장혁
김두형
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Coupang Corp
Original Assignee
Coupang Corp
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 Coupang Corp filed Critical Coupang Corp
Publication of WO2024005252A1 publication Critical patent/WO2024005252A1/ko
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/22—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2358—Change logging, detection, and notification
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/25—Integrating or interfacing systems involving database management systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Definitions

  • This disclosure relates to a data provision method and device.
  • the object of the present invention is to manage a temporary database and a main database to provide data that can be provided to the front end according to the service operation direction, and to provide a method and method for combining the information received from them and providing it to the front end.
  • the purpose is to provide a device.
  • a method of providing data by an electronic device includes receiving a first data request from a front node; Obtaining first data from the main database based on the first data request; Obtaining second data from a temporary database based on the first data request; And it may include transmitting the first data and the second data to the front node.
  • the data provision method includes transmitting a second data request including specific identification information to a temporary database; and obtaining second data from a temporary database according to the second data request.
  • specific identification information may be confirmed based on the first data.
  • the second data may be obtained from a table confirmed based on setting information obtained from a dynamic setting database according to specific identification information in the temporary database.
  • the second data may include at least one key-value pair corresponding to the first data request.
  • the key of the key-value pair may be information that identifies the subject who created the value corresponding to the key.
  • the temporary database is updated based on at least one data file, and each of the at least one data file may include at least one key-value pair and information identifying the subject who created each key-value pair. .
  • each of the at least one data file may be verified based on the format of information included in the data file and the size of the data file.
  • the temporary database includes at least one table, and each of the at least one tables can be distinguished from each other according to the type of specific identification information.
  • each of the at least one table may be updated by being replaced with a table configured based on a job configuration file corresponding to each of the at least one table.
  • the type of specific identification information, type of value, grouping status, and data expiration date information included in each data file may be uploaded together.
  • the first temporary data file may be configured to distinguish one or more pieces of information included in the first temporary data from each other using a separator
  • the data provision method may include one or more pieces of information corresponding to one or more temporary data using a separator. It may include parsing one or more temporary data files to check one or more temporary data.
  • the data provision method may include transmitting the first data and the second data to the front node when the data expiration date for the second data has not passed.
  • the data provision method may further include providing a notification before a preset period of time from the data expiration date.
  • the data providing method includes obtaining second data from a cache, and the cache may be updated based on the temporary database.
  • data corresponding to the specific identification information may be deleted from the cache.
  • the temporary database may be updated at a preset interval.
  • the data provision method may provide notifications when a request for an update task of a temporary database is confirmed, when the start of an update task is confirmed, and when completion of an update task is confirmed.
  • the data provision method may include displaying information on whether data included in the temporary database is activated.
  • the electronic device may include a memory storing at least one program; and executing at least one program to receive a first data request from the front node, obtain first data from the main database based on the first data request, and obtain second data from a temporary database based on the first data request. It may include a processor that acquires and transmits the first data and the second data to the front node.
  • a computer-readable non-transitory recording medium can record a program for executing the above-described operation method on a computer.
  • the user can provide temporary data together with the main data to the front end without any additional coding, so that the service user can receive the temporary data together with the main data. Therefore, programmer or developer resources are saved.
  • a user can create, delete, and manage tables in a temporary database through a user interface.
  • data delivered from the temporary database can be distinguished among data included in the data provided by the backend, and based on this, new services can be provided by utilizing the data at the front end.
  • temporary data is stored in the form of a table in a temporary database, so that it is possible to distinguish which temporary data should be transmitted from a plurality of tables based on specific identification information.
  • temporary data can be retrieved from a temporary database by utilizing a data request containing specific identifying information for the main database without separately modifying the main database storing the main data or modifying the data request form for the main database.
  • the present invention when there is a change in the front service and some data needs to be changed accordingly, the present invention is used to add a table related to the service, and when requesting data, obtain the data of the table through an identifier. It can be provided by the front node.
  • FIG 1 shows an embodiment of an electronic device according to the present disclosure.
  • Figure 2 shows an embodiment of a data provision method according to the present disclosure.
  • 3A shows one embodiment of a data file according to the present disclosure.
  • 3B shows an example of information about a data file according to the present disclosure.
  • Figure 4 shows the types of information that can be included in information about a data file according to the present disclosure.
  • FIG. 5 shows a table of data according to the present disclosure.
  • Figure 6 shows a request and response for temporary data regarding the data provision method according to the present disclosure.
  • Figure 7 shows an example of a data provision method according to the present disclosure.
  • Figure 8 shows an embodiment of a data provision method according to the present disclosure.
  • Figure 9 shows an example of a data provision method according to the present disclosure.
  • Figure 10 shows an example of a data provision method according to the present disclosure.
  • FIG. 11 shows a user interface related to a data provision method according to the present disclosure.
  • Figure 12 shows a user interface related to the data provision method according to the present disclosure.
  • Figure 13 shows a user interface related to the data provision method according to the present disclosure.
  • Figure 14 shows an example of a data provision method according to the present disclosure.
  • Figure 15 shows an example of a data provision method according to the present disclosure.
  • Figure 16 shows an example of a data provision method according to the present disclosure.
  • Figure 17 shows an example of a data provision method according to the present disclosure.
  • Figure 18 shows an example of a data provision method according to the present disclosure.
  • Figure 19 shows an example of a data provision method according to the present disclosure.
  • first, second, etc. used in this specification may be used to describe various components, but the components should not be limited by terms containing the ordinal numbers.
  • the above terms are used in context only to distinguish one element from another element in one part of the specification.
  • a first component may be referred to as a second component in other parts of the specification, and conversely, the second component may also be referred to as a first component in other parts of the specification. It can be.
  • FIG. 1 illustrates an example, simplified block diagram of an electronic device 100 that may be used to practice at least one embodiment of the present disclosure.
  • electronic device 100 may be used to implement any system or method described in this disclosure.
  • electronic device 100 may include any data server, web server, portable computing device, personal computer, tablet computer, workstation, mobile phone, smart phone, or any other device described below. It can be configured to be used as an electronic device.
  • Electronic device 100 may include memory 120 and one or more processors 110 having one or more cache memories and a memory controller that may be configured to communicate with memory 120 . Additionally, the electronic device 100 may be connected to the electronic device 100 through one or more ports (e.g., Universal Serial Bus (USB), headphone jack, Lightning connector, Thunderbolt connector, etc.). May include devices. A device that can be connected to electronic device 100 can include a plurality of ports configured to receive fiber optic connectors.
  • the configuration of electronic device 100 shown is intended as a specific example only for the purpose of illustrating preferred embodiments of the device. In the illustrated electronic device 100, only components related to the present embodiments are shown. Accordingly, it is obvious to those skilled in the art that the electronic device 100 may further include other general-purpose components in addition to the components shown.
  • Processor 110 may be used to cause electronic device 100 to provide the steps or functions of any embodiment described in this disclosure.
  • the processor 110 generally controls the electronic device 100 by executing programs stored in the memory 120 within the electronic device 100.
  • the processor 110 may be implemented as a central processing unit (CPU), a graphics processing unit (GPU), an application processor (AP), etc. provided in the electronic device 100, but is not limited thereto.
  • the memory 120 is hardware that stores various data processed within the electronic device 100.
  • the memory 120 can store data processed through the processor 110 and data to be processed in the electronic device 100. there is.
  • the memory 120 stores basic programming and data structures that can provide the functions of at least one embodiment of the present disclosure, as well as applications (programs, code modules) that can provide the functions of the embodiments of the present disclosure. , commands), drivers, etc. can be saved.
  • the memory 120 includes random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), CD- It may include ROM, Blu-ray or other optical disk storage, a hard disk drive (HDD), a solid state drive (SSD), or flash memory.
  • RAM random access memory
  • DRAM dynamic random access memory
  • SRAM static random access memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • CD- It may include ROM, Blu-ray or other optical disk storage, a hard disk drive (HDD), a solid state drive (SSD), or flash memory.
  • the method and each step according to the present disclosure can be performed by the electronic device 100 or the processor 110.
  • the electronic device 100 operates under the control of the processor 110.
  • the following description will be made on the assumption that the electronic device 100 is the entity that performs the method and each step according to the present disclosure.
  • Figure 2 shows an embodiment of a payment service providing method according to the present disclosure.
  • the electronic device 100 receives the first data request from the front node, obtains the first data from the main database based on the first data request, and obtains the first data from the temporary database based on the first data request. 2 data may be acquired and the first data and second data may be transmitted to the front node (not shown).
  • the “front node (not shown)” may receive data from the backend node and create a page to be provided to the user.
  • the front node can provide services to service users by creating a page on the user's terminal.
  • the serving layer 214 may provide data to the front node.
  • the serving layer 214 may be included in the electronic device 100.
  • the serving layer 214 includes a plurality of APIs, and may receive data from a backend node or server corresponding to a specific API according to a request from the front node and transmit it to the front node.
  • the serving layer 214 may include at least one of a listing API 215, a search API 216, and a promotion API 217.
  • the listing API 215 can provide a list of data to the front node.
  • the search API 216 can provide search results of data to the front node.
  • the promotion API 217 can provide data about promotions to the front node.
  • the front node may transmit a request containing specific identification information of a specific object to the serving layer 214.
  • the serving layer 214 may transmit a first data request to the object data providing API 213.
  • the object data providing API 213 may be included in the electronic device 100.
  • the first data request may be a request for data regarding a specific object.
  • the first data request may include specific identification information of a specific object corresponding to the request from the front node.
  • the object data providing API 213 may obtain first data in response to a first data request from the serving layer 214 and provide the first data to the serving layer 214 .
  • the object data providing API 213 may obtain first data from the main database based on the first data request.
  • the main database can store data about specific objects.
  • the first data request may include identification information about a specific object, and the object data providing API 213 may use the identification information to obtain first data about the object corresponding to the identification information from the main database.
  • the main database can store a huge amount of data, and accordingly, data requests and data provision tasks to the main database can occur frequently. Therefore, in order to minimize interference with data provision work in the main database, data change, modification, deletion, and update operations for the main database also need to be minimized. Therefore, instead of reflecting temporary data in the main database, a separate temporary database can be used and temporary data can be loaded from the temporary database and provided.
  • the object data providing API 213 may transmit the first data request to the shuttle 212.
  • Shuttle 212 may be part of electronic device 100 .
  • Shuttle 212 may obtain second data from temporary database 210 based on the first data request.
  • the temporary database 210 may store data about a specific object.
  • the temporary database 210 may be or include a distributed database such as Spark Cassandra.
  • the shuttle 212 may obtain second data about an object corresponding to specific identification information from the temporary database 210 using the first data request or specific identification information confirmed based on the first data, and second Data can be passed to the object data providing API (213).
  • the second data may include temporary data about a specific object.
  • the object data providing API 213 or processor transmits the first data and the second data to the serving layer 214, so that the first data and the second data can be transmitted to the front node.
  • shuttle 212 may transmit a second data request containing specific identifying information to temporary database 210 and obtain second data from temporary database 210 in accordance with the second data request.
  • the second data request may be generated based on the first data or the first data request. The second data request and second data will be described in detail later with reference to FIG. 6.
  • shuttle 212 may obtain second data from cache 211 and cache 211 may be updated based on temporary database 210 .
  • the cache 211 may include some of the data stored in the temporary database 210, such as the second data. This has the advantage of being able to acquire data more quickly than acquiring data directly from the temporary database 210.
  • the second data may be obtained from a table confirmed based on setting information obtained from the dynamic setting database 209 according to specific identification information in the temporary database 210. Details of these tables and the dynamic setting database 209 will be described in detail later with reference to FIG. 5.
  • the user 201 may upload 202 at least one data file through the ad hoc service 203.
  • the ad hoc service 203 may include an ad hoc UI (User Interface) 204, and the user 201 may upload at least one data file (202) using the ad hoc UI 204.
  • ad hoc UI User Interface
  • At least one data file may be a text file or a comma separated values (csv) file.
  • An example of at least one data file is shown in Figure 3A.
  • At least one data file may be stored in file database 205, and data extractor 208 may update temporary database 210 from the at least one data file. That is, the temporary database 210 can be updated based on at least one data file.
  • the file database 205 may include cloud storage such as Amazon S3.
  • each of the at least one data file may include at least one key-value pair.
  • the key of at least one key-value pair may be specific identification information, and the value may be a value corresponding to the specific identification information.
  • the value corresponding to each key may be a single value, but may also include one or more values expressed in a data format such as json (JavaScript Object Notation) format.
  • each of the at least one data file may be configured to distinguish one or more pieces of information included in each of the at least one data file from each other using a separator.
  • the separator may be a tab or a comma (,).
  • the separator can be set through the ad hoc UI 204 of FIG. 2.
  • the user 201 can determine the separator to be used through the ad hoc UI 204.
  • the A1.txt file 301 may include 2 and 3 as values corresponding to keys 10001 and 10002, respectively. Each key and value are separated by commas.
  • the A2.txt file 302 may have 3000 as the value corresponding to key 10001.
  • the A3.txt file 303 may have true as the value corresponding to key 19101053.
  • the A4.txt file 304 may have retail/image01.png as the value corresponding to key 10001.
  • the B1.txt file 305 may have ⁇ "bsr_rank”: “1", “bsr_limit”: false ⁇ as values corresponding to key 10001. This may correspond to the json format.
  • Each of the at least one data file may correspond to information identifying the subject (or user) who created at least one key-value pair (in other words, a creation subject identifier).
  • the creation subject identifier may be information that identifies the use of the second data.
  • the front node can determine the use of key-value pairs or second data included in at least one data file.
  • the creating subject identifier may be an identifier promised between the user and the front node, which can request the necessary data from the temporary database as well as the creating subject, and distinguish the information obtained from the temporary database from the front-end node that received it. It may include identifying information that allows it to be used.
  • each of the at least one data file may be verified based on the size of the data file or the format of information (keys and values) included in the data file. For example, it can be verified whether a key included in at least one data file is of an integer type or a value of a string type, and whether the data file is less than 1 megabyte can be verified. This has the effect of preventing the problem of a user 201 who is not familiar with programming uploading data that may cause a potential program error.
  • information regarding at least one data file may be maintained in file information database 206.
  • the file information database 206 may include a relational database such as Amazon RDS. Information regarding the at least one data file will be described in detail later with reference to FIG. 3B.
  • a job configuration file may be uploaded to the job configuration file database 207 to update the temporary database 210 based on at least one data file stored in the file database 205.
  • the task configuration file database may include a database such as Amazon S3.
  • the data extractor 208 may refer to the job configuration file stored in the job configuration file database 207, check one or more data files stored in the file database 205, and update the temporary database 210, thereby The table of the database 210 is updated, and the setting value in the dynamic setting database 209 can be updated to set a table or row corresponding to data to be delivered to the front node.
  • Data extractor 208 may include a data streaming tool such as Spark Streaming.
  • a job configuration file may contain information for batch processing one or more data files. This has the advantage of controlling the load on the temporary database 210 by updating the temporary database 210 at an appropriate frequency.
  • data extractor 208 may update temporary database 210 and then upload configuration information regarding the update of temporary database 210 to dynamic configuration database 209.
  • the shuttle 212 may utilize this setting information from the dynamic setting database 209 to obtain second data from the temporary database 210.
  • the configuration information of the dynamic configuration database 209 may include information regarding what data the shuttle 212 should refer to from the temporary database 210 .
  • the shuttle 212 determines which table and row/column information should be referenced based on the setting information of the dynamic setting database 209, and obtains second data from the temporary database 210 based on this. You can.
  • the data in the temporary database 210 can be adaptively updated, and even when the version of the data used changes, the dynamic setting database 209 is updated to You can easily set the data to be delivered to the node.
  • the dynamic setting database 209 may include the updated table name of the temporary database 210 and updated column information of the table.
  • FIG. 3B shows an example of information about at least one data file according to the present disclosure.
  • At least one data file uploaded by the user may be stored in the file information database in the form of a table shown in FIG. 3B.
  • Information about at least one data file may include information such as an identifier 310, a creation subject identifier 320, an identifier type 330, and a storage path 340 of each data file.
  • the identifier 310 may correspond to the sequence number of at least one data file.
  • the creation subject identifier 320 may be information that identifies the subject that created at least one data file, and, as described above, may be information that determines where the key-value pair included in at least one data file is used. .
  • the identifier type 330 may refer to the type of key of a key-value pair included in at least one data file.
  • the key of the key-value pair included in at least one data file may correspond to specific identification information, and the specific identification information may be classified based on a certain standard.
  • the specific identification information may be a vendor item (VENDOR_ITEM) type of identification information, a category (CATEGORY) type of identification information, or a member (MEMBER) type of identification information.
  • the storage path 340 may represent a path where each of at least one data file is stored in a file database.
  • the row with the identifier 310 being 2 may correspond to the A2.txt file 302 in FIG. 3A. That is, the storage path 340 cell in the row where the identifier 310 is 2 may include the path where the Figure A2.txt file 302 is stored in the file database.
  • the creation subject identifier 320 is CATEGORY_IMAGE, which may mean the operation of adding / changing / deleting an image corresponding to a specific category.
  • the identifier type 330 may be set to CATEGORY. That is, the key included in the A2.txt file 302, which is a data file related to this task, may correspond to a specific category.
  • the A2.txt file 302 may include 10001, a key corresponding to the "T-shirt” category, and in order to change the image corresponding to the "T-shirt” category, the value corresponding to the 10001 key is the URL of the new image ( Uniform Resource Locator), for example, “retail/image01.png”.
  • Uniform Resource Locator Uniform Resource Locator
  • a row with the identifier 310 as 1 may correspond to the A1.txt file 301 in Figure 3A
  • a row with the identifier 310 as 3 may correspond to the A3.txt file 303 in Figure 3A.
  • the row with the identifier 310 being 4 may correspond to the A4.txt file 304 in FIG. 3A.
  • the type of specific identification information, type of value, grouping status, and data expiration date information included in each data file may be uploaded together.
  • types of specific identification information may include PRODUCT, ITEM, VENDOR_ITEM, CATEGORY, VENDOR, MEMBER, and UNKNOWN.
  • the value type may include, for example, data description types such as TEXT, BOOLEAN, DOUBLE, LONG, and UNKNOWN.
  • Grouping may include whether the value can be a set of multiple values. For example, if the grouping status is “SINGLE”, this may mean that the value corresponding to specific identification information is a single value. For another example, when the grouping status is “MULTI,” this may mean that there may be multiple values corresponding to specific identification information or other key-value pairs.
  • Data expiration date information may mean a valid period for each of at least one data file.
  • the data expiration date is specified as May 16, 2022
  • the data file is valid only until May 16, 2022
  • the information included in the data file can also be valid only until May 16, 2022. Therefore, even if the information included in the data file is already stored in the temporary database, it can be provided to the front node only until May 16, 2022, the data expiration date. That is, the electronic device 100 may transmit the second data to the front node when the data expiration date for the second data has not passed. Additionally, the electronic device 100 may provide a notification before a preset period of time from the data expiration date. This has the advantage of allowing users to properly update temporary data before it expires.
  • Ad hoc data transfer object (AdHocDto, 410) information may include information about temporary data according to the present disclosure. That is, each row appearing in the ad hoc data transfer object 410 may be information about the data file shown in FIG. 3B, that is, table column information.
  • information about the data file includes identifier (id) information, title information, description information, content information, identifier type (idType) information, ad hoc creation date (or file creation date, createdAt) Information, ad hoc creation entity (or file creation entity, createdBy) information, ad hoc modification date (or file modification date, modifiedAt) information, ad hoc modification entity (or file modification entity, modifiedBy) information, temporary database upload status of ad hoc data or data file ( status) information and data file storage path (s3Path) information, etc. may be included.
  • Ad hoc data history information 430 includes identifier (id) information, ad hoc identifier (adHocID) information, description information, ad hoc creation date (or file creation date, createdAt) information, ad hoc creation subject (or file creation subject, createdBy ) information, etc. may be included.
  • Identifier type (idType) information 420 may include identifier (id) information and type information of the identifier type.
  • Each piece of information 410, 420, and 430 can be created, changed, or deleted by an administrator, and can be created, changed, or deleted by a user.
  • the user's authority may be reduced compared to the administrator.
  • the temporary database includes at least one table, and each of the at least one tables may be distinguished from each other according to the type of specific identification information.
  • the type of specific identification information may correspond to the identifier type 330 shown in FIG. 3B.
  • the vendor item table 510 may include specific identification information of the VENDOR_ITEM type shown in FIG. 3B and values corresponding to the specific identification information in the form of a table.
  • the row with the identifier 310 of 1 in FIG. 3B corresponds to the A1.txt file 301 in FIG. 3A. Since the creation subject identifier 320 of the row in which the identifier 310 of FIG. 3B is 1 is VI_BEST_SELLER_RANKING, the title of the second column of the vendor item table 510 may be set to VI_BEST_SELLER_RANKING.
  • the A1.txt file 301 includes value 2 corresponding to specific identification information 10001 and value 3 corresponding to specific identification information 10002, the specific identification information 10001 in the second column of the vendor item table 510 You can write the values 2 and 3 in the cells corresponding to row 10002 and row 10002, respectively.
  • the type of specific identification information in the row where the identifier 310 in FIG. 3B is 3 is also VENDOR_ITEM.
  • the row with identifier 310 in FIG. 3B corresponds to the A3.txt file 303 in FIG. 3A. Since the generating subject identifier 320 of the row in which the identifier 310 of FIG. 3B is 3 is VI_FRESH_PROMOTION, the title of the third column of the vendor item table 510 may be set to VI_FRESH_PROMOTION. And, since the A3.txt file 303 contains the value 3000 corresponding to specific identification information 10001, 3000 is recorded in the cell corresponding to the row with specific identification information 10001 in the third column of the vendor item table 510. can do.
  • the type of specific identification information in the row where the identifier 310 of FIG. 3B is 4 is MEMBER.
  • the row with identifier 310 of 4 in FIG. 3B corresponds to the A4.txt file 304 in FIG. 3A. Since the creation subject identifier 320 of the row in which the identifier 310 of FIG. 3B is 4 is MEMBER_FREE_SHIPPING, the title of the second column of the member table 520 may be set to MEMBER_FREE_SHIPPING. And, since the A4.txt file 304 contains the value true corresponding to the specific identification information 19101053, true can be recorded in the cell corresponding to the row with the specific identification information 19101053 in the second column of the member table 520. You can.
  • the type of specific identification information in the row where the identifier 310 in FIG. 3B is 2 is CATEGORY.
  • the row with identifier 310 of 2 in FIG. 3B corresponds to the A2.txt file 302 in FIG. 3A. Since the creation subject identifier 320 of the row in which the identifier 310 of FIG. 3B is 2 is CATEGORY_IMAGE, the title of the second column of the category table 530 may be set to CATEGORY_IMAGE. And, since the A2.txt file 302 contains the value retail/image01.png corresponding to the specific identification information 10001, retail is entered in the cell corresponding to the row with the specific identification information 10001 in the second column of the category table 530. You can record /image01.png.
  • distinguishing at least one table of the temporary database according to the type of specific identification information means that the first data request or the second data request from the front node, serving layer, object data providing API, or shuttle includes the specific identification information.
  • the first data request or the second data request from the front node, serving layer, object data providing API, or shuttle includes the specific identification information.
  • the second data request may include specific identifying information.
  • the second data request shown in Figure 6 corresponds to "vi": 10001.
  • vi means the VENDOR_ITEM type among the types of specific identification information
  • 10001 corresponds to the value of the specific identification information. That is, the second data request in FIG. 6 means requesting second data whose specific identification information of the VENDOR_ITEM type is 10001.
  • the second data request may be generated based on the first data request or the first data.
  • the first data request itself may include requesting second data where specific identification information of type VENDOR_ITEM is 10001
  • the first data obtained according to the first data request may include requesting second data where specific identification information of type VENDOR_ITEM is 10001. Because it includes information about the object number 10001, the second data request may be generated by the first data.
  • the shuttle or object data serving API may send the second data request shown in Figure 6 to the temporary database and generate the response shown in Figure 6.
  • the shuttle or object data providing API can obtain the values 2 and 3 of the second row where the specific identification information of the vendor item table 510 is 10001, and the respective column names VI_BEST_SELLER_RANKING and VI_FRESH_PROMOTION.
  • the shuttle or object data providing API can use this to generate a response including second data as shown in FIG. 6.
  • the second data may include at least one key-value pair corresponding to the first data request or the second data request.
  • the second data may be described in the form of key-value pairs.
  • the second data may be described in JSON format.
  • the key of the key-value pair included in the second data may be information that identifies the subject who created the value corresponding to the key. That is, the key of the key-value pair included in the second data may be a generating subject identifier.
  • the second data may be a first key-value pair with a value of 2 corresponding to the key VI_BEST_SELLER_RANKING and a second key-value pair with a value of 3 corresponding to the key VI_FRESH_PROMOTION.
  • the first key-value pair and the second key-value pair may be included in the second data response as shown in FIG. 6, and the second data response includes "vendorItem", meaning that the second data corresponds to specific identification information of the VENDOR_ITEM type. " Keys may be included.
  • the second data response may include an “adhocProperties” key, meaning that the second data is temporary data.
  • FIG. 7 shows an example of a data provision method according to the present disclosure. Specifically, FIG. 7 shows a process of updating at least one table of a temporary database based on information in a data file uploaded by a user.
  • the ad hoc backend 710 may be a module included in the electronic device 100.
  • Amazon RDS 720 may correspond to a file information database.
  • Amazon S3 730 may correspond to a job configuration file database.
  • Apache Airflow 740 may be a module included in the electronic device 100.
  • the ad hoc backend 710 may retrieve the airflow job base configuration file from the adhoc_base.yaml file in Amazon S3 730.
  • the adhoc_base.yaml file, or airflow job base configuration file may contain common settings, commands, or sequences for updating at least one table in the temporary database.
  • ad hoc backend 710 may create a cache of basic configuration for triggering each airflow operation. That is, the ad hoc backend 710 may cache basic configuration information based on a working basic configuration file.
  • the user may click a publish button for Adhoc.id. That is, the user may command the temporary database to be updated by issuing at least one data file that has already been uploaded to the file database.
  • the ad hoc backend 710 may set the ad hoc state to 'activated' in response to the user's click on the publish button.
  • the ad hoc state may mean whether information contained in a data file newly updated in the temporary database is activated when the temporary database is updated. If the ad hoc state is activated, information in the corresponding temporary database may be delivered to the front node by the shuttle. Ad-hoc state information may be recorded in Amazon RDS 720.
  • ad hoc backend 710 may query Amazon RDS 720 for a list of all ad hocs in an activated state.
  • the ad hoc list may refer to information about data files stored in a file information database, that is, Amazon RDS (720). That is, the ad hoc list may correspond to the table in FIG. 3B.
  • the ad hoc backend 710 may create settings for an Airflow operation. This setting may be based on the basic configuration cached in step S702. Additionally, the ad hoc backend 710 can create an input session for a yaml file using an ad hoc list. Through this, the ad hoc backend 710 can configure a task configuration file for the update task of the temporary database.
  • the ad hoc backend 710 may upload the adhoc_ ⁇ ID_TYPE ⁇ .yaml file to Amazon S3 730.
  • the adhoc_ ⁇ ID_TYPE ⁇ .yaml file is a task for updating a table whose specific identification information type is ID_TYPE in a temporary database based on information corresponding to a key-value pair whose specific identification information type is ID_TYPE in at least one data file. It may be a job configuration file containing settings for .
  • the vendor item table 510 of FIG. 5 can be updated by referring to the adhoc_vendorItem.yaml file.
  • Apache Airflow 740 may retrieve a yaml file from Amazon S3 730 for work.
  • Apache Airflow (740) can refer to the yaml file and import each csv and text file to be parsed according to step S709 from Amazon S3 (730).
  • csv and text files may correspond to at least one data file.
  • Apache Airflow 740 may create a new table in Cassandra.
  • Cassandra may be the counterpart to a temporary database.
  • Cassandra's existing tables can be dropped.
  • Apache Airflow (740) can create a new table corresponding to a table stored in Cassandra or a temporary database, and replace or replace the table stored in the temporary database with a newly created table.
  • This method has the advantage of updating the temporary database faster than overwriting all information in at least one file in Cassandra or the temporary database table. That is, in one embodiment, each of the at least one table may be updated by being replaced with a table configured based on a job configuration file corresponding to each of the at least one table.
  • Figure 8 shows one embodiment of a method according to the present disclosure. Specifically, Figure 8 shows a method for transmitting new data to the front node.
  • Apache Airflow (810) may include a Join-Writer (811).
  • the join-writer 811 may be a module that joins tables together.
  • the join-writer 811 may create a join table, write new data to the join table, and then update the CDS (Cassandra Data Server, 812).
  • CDS 812 may correspond to the main database.
  • the shuttle 813 can obtain new data from the CDS 812, and the object data providing API 814 can retrieve data based on each ID.
  • id may be specific identification information.
  • the object data providing API 814 can deliver new data to the serving layer 815, allowing the new data to be delivered to the front node.
  • Apache Airflow 820 may include a join-writer 821 and an ad-hoc writer 822.
  • the ad hoc writer 822 may be a module that stores new data in a temporary database.
  • the join-writer 823 may create a join table, write new data to the join table, and then update the CDS 823.
  • CDS 823 may correspond to the main database.
  • the shuttle 824 can obtain new data from the CDS 823, and the object data providing API 827 can retrieve data based on each ID.
  • id may be specific identification information.
  • the object data providing API 827 can deliver new data to the serving layer 828, allowing the new data to be delivered to the front node.
  • the join-writer 823 and the ad-hoc writer 822 may write join data and ad-hoc data including new data to the same table and then update the CDS 825.
  • CDS 825 may correspond to a main database or a temporary database.
  • the shuttle 826 can obtain new data from the CDS 825, and the object data providing API 827 can retrieve data based on each ID.
  • id may be specific identification information.
  • the object data providing API 827 can deliver new data to the serving layer 828, allowing the new data to be delivered to the front node.
  • Figure 9 shows one embodiment of a method according to the present disclosure.
  • Each component shown in FIG. 9 may correspond to a component with the same name described in FIGS. 1 to 8.
  • the user 901 may upload at least one data file through the ad hoc UI of the ad hoc service 903.
  • At least one data file may be uploaded to a file database or S3 905.
  • Information about at least one uploaded data file may be uploaded to the file information database or RDS 904.
  • the active test list may refer to a file information database or a list of files for which the ad hoc state is activated in S3 (905).
  • the data extractor 906 can upload the names of the tables and columns it provides to the dynamic setting database 907.
  • the provided tables and columns may mean updated (to be updated) tables and updated (to be updated) columns in the temporary database or CDS (909).
  • Dynamic configuration database 907 may inform shuttle 908 of updated table and column names.
  • the serving layer 912 may include a listing API 913, a search API 914, and a promotion API 915.
  • the serving layer 913 may transmit the first data request to the object data providing API 911.
  • the object data providing API 911 may obtain first data from the main database based on the first data request.
  • the object data providing API 911 may generate a first data request or a second data request based on the first data.
  • the object data providing API 911 may transmit a second data request to the shuttle 908.
  • the shuttle 908 may provide the second data from the temporary database 919 or the cache 910 to the object data providing API 911 in response to the second data request, and the object data providing API 911 may provide the first data.
  • the data and second data can be delivered to the serving layer 912 so that the first data and second data are delivered to the front node.
  • FIG. 10 shows one embodiment of a method according to the present disclosure.
  • Each component shown in FIG. 10 may correspond to a component with the same name described in FIGS. 1 to 9 .
  • the user can create a new data file or update an existing data file through the ad hoc UI 1010.
  • the ad hoc UI 1010 may call /api/file/upload of the ad hoc server 1020.
  • /api/file/upload may refer to a command that performs upload of a data file.
  • the ad hoc server 1020 may be a module included in the electronic device 100.
  • the file database or S3 (1030) may first store the type and title of specific identification information in the file information database (1040).
  • the title may correspond to the identifier of the subject who created the file, that is, the creator identifier 320 of FIG. 3B.
  • the file information database 1040 may return a storage result and an identifier.
  • the identifier may correspond to the identifier 310 in FIG. 3B.
  • the ad hoc server 1020 may upload at least one file to the file database or S3 (1030).
  • the file database or S3 (1030) may return the upload result to the ad hoc server (1020) in step S1006.
  • the ad hoc server 1020 may store the s3 path along with the previous ID in the file information database 1040 in step S1007.
  • the previous ID may correspond to the identifier 310 in FIG. 3B and may mean the identifier 310 before the file was uploaded or updated.
  • step S1008 the file information database 1040 notifies the ad hoc server 1020 of successful upload, and the ad hoc server 1020 can display the upload success UI (S1010) on the ad hoc UI 1010 according to step S1009. there is.
  • FIG. 11 shows an example of an ad hoc UI 1110 according to the present disclosure.
  • the ad hoc UI 1110 may display a list 1114 of ad hoc services (temporary services) based on the file information database.
  • the ad hoc service or temporary service may correspond to each of at least one data file uploaded to the file information database.
  • the ad hoc UI 1110 includes a search window 1111 and a search button 1112, so that the user can search for information based on the column names of the list 1114.
  • the ad hoc UI 1110 may include a new button 1113, and the user may click the new button 1113 to upload at least one file to the database 1120.
  • the ad hoc UI 1110 may include an update button 1115, and the user may click the update button 1115 to update at least one file uploaded to the database 1120.
  • the ad hoc UI 1110 may include a download button 1116, and the user may click the download button 1116 to download at least one file uploaded to the database 1120.
  • the ad hoc UI 1110 may include a delete button 1117, and the user may click the delete button 1117 to delete at least one file uploaded to the database 1120. At this time, the ad hoc UI 1110 includes a confirmation window 1130 so that the user can once again confirm whether or not to delete.
  • FIG. 12 shows an example of an ad hoc UI 1200 according to the present disclosure.
  • the ad hoc UI 1200 represents an interface for creating or editing an ad hoc service, that is, a temporary service.
  • the ad hoc UI 1200 may include a business ID input field.
  • the business ID may correspond to the creation subject identifier 320 in FIG. 3B. That is, the use of temporary data or secondary data can be determined based on the set business ID.
  • the business ID or creation subject identifier may be a value promised to the front node.
  • the ad hoc UI 1200 may include a button that can set the type of specific identification information.
  • the ad hoc UI 1200 may include a field for inserting a related link and may include a field for recording a description of the ad hoc service.
  • the ad hoc UI 1200 may include a field for entering at least one data file. This allows at least one data file to be uploaded to the file database.
  • Figure 13 shows an example of an ad hoc UI 1300 according to the present disclosure.
  • the ad hoc UI 1300 represents an ad hoc service, that is, an interface for editing temporary data.
  • Ad hoc UI 1300 may include a stateful UI.
  • the status active UI may indicate whether temporary data is active.
  • the ad hoc UI 1300 may include a button that can set the type of specific identification information.
  • the ad hoc UI 1300 may include a field for inserting a related link and may include a field for recording a description of the ad hoc service.
  • the ad hoc UI 1300 may include a field for entering at least one data file. This allows at least one data file to be uploaded to the file database.
  • FIG. 14 shows one embodiment of the method according to the present disclosure. Each component shown in FIG. 14 may correspond to a component with the same name described in FIGS. 1 to 13.
  • Spark airflow 1410 may trigger data extractor 1420.
  • the data extractor 1420 may include a join writer 1421.
  • the data extractor 1420 may update the table of the temporary database or CDS 1430 in response to the trigger of Spark airflow.
  • CDS 1430 may cache updated information of the table in a cache 1440.
  • Shuttle 1450 may obtain second data from cache 1440.
  • the second data may include updated information of the table.
  • the electronic device 100 may obtain the second data from the cache, and the cache may be updated based on the temporary database.
  • the second data may be transmitted to the mate-api (1460).
  • Mate-api 1460 may correspond to an object data providing API.
  • FIG. 15 shows one embodiment of a method according to the present disclosure.
  • Each component shown in FIG. 15 may correspond to a component with the same name described in FIGS. 1 to 14.
  • the user 1500 may create, update, delete (CUD) a data file through the mock creation UI 1503 of the mock creation interface 1502.
  • the mock creation interface 1502 may correspond to the ad hoc service 203 of FIG. 2, and the mock creation UI 1503 may correspond to the ad hoc UI 204 of FIG. 2.
  • a mock may correspond to an ad hoc service or at least one data file.
  • the neck creation UI 1503 can create (1505) and update (1506) a neck through bulk Kafka (1507).
  • the result of creating or updating a tree may be delivered to the tree creation UI 1503 through individual Kafka 1508.
  • Bulk Kafka (1507) and individual Kafka (1508) may refer to data or message streaming solutions such as Apache Kafka.
  • the mock creation UI 1503 may trigger the shuttle 1511 to update the CDS 1512.
  • the updater 1510 may update the tables 1533 and 1534 of the CDS 1512 and the tables 1531 and 1532 of the RDS 1504 based on the created or updated list.
  • the table of RDS (1504) can be updated through transaction Kafka (1509).
  • Transaction Kafka (1509) can also refer to a data or message streaming solution such as Apache Kafka.
  • SIGNAL may correspond to the generating subject identifier 320 of FIG. 3B
  • LEVEL may correspond to the specific identification information of FIG. 3B. It may correspond to the type, that is, the identifier type 330.
  • ID and String may refer to the key and value shown in FIG. 3A. For example, 10001, the key of B1.txt (305) in FIG. 3A, may correspond to ID, and the value ⁇ "bsr_rank": "1", "bsr_limit”: false ⁇ may correspond to String.
  • String may refer to a string in JSON format.
  • the shuttle 1511 may obtain the second data from the cache 1513 or the CDS 1512 according to a request 1535 of the object data providing API 1514 and transmit it to the object data providing API 1514.
  • the object data providing API 1514 may include the second data in the response 1536 and transmit it to the serving layer 1516.
  • the second data may be included in the response 1536 along with the first data.
  • the mocking handler 1515 can intervene and replace the response if the signal is of the MOCK type.
  • a signal of type MOCK may be a type of specific identifying information used to test the operation of the method according to the present disclosure.
  • Each mocking handler 1520 may process a response to a MOCK type signal by intervening in the listing API 1517, search API 1518, and promotion API 1519 of the serving layer 1516.
  • FIG. 16 shows one embodiment of a method according to the present disclosure. Each component shown in FIG. 16 may correspond to a component with the same name described in FIGS. 1 to 15.
  • the user 1600 may create, update, delete (CUD) a data file through the mock creation UI 1603 of the mock creation interface 1602.
  • the mock creation interface 1602 may correspond to the ad hoc service 203 of FIG. 2, and the mock creation UI 1603 may correspond to the ad hoc UI 204 of FIG. 2.
  • a mock may correspond to an ad hoc service or at least one data file.
  • the mock creation UI 1603 may publish a mock 1605 to the mock Kafka 1606.
  • the cleanup scheduler 1604 may trigger the topic creation UI 1603 at a certain cycle (e.g., daily) to issue a topic 1605. That is, the temporary database or CDS 1612 may be updated at a preset period.
  • the shuttle 1611 can update the table 1631 of the CDS 1612 by subscribing 1607 to the mock through the mock Kafka 1606.
  • the mock creation interface 1602 may update the table 1630 of the RDS 1610 by subscribing 1609 to the state through the state Kafka 1610.
  • BUSINESS_SIGNAL in the tables 1630 and 1631 may correspond to the generating subject identifier 320 shown in FIG. 3B, and ID_TYPE may correspond to the type of specific identification information in FIG. 3B, that is, the identifier type 330.
  • ID and BUSINESS_CONTENTS may refer to the keys and values shown in FIG. 3A. For example, 10001, the key of B1.txt (305) in FIG. 3A, may correspond to ID, and the value ⁇ "bsr_rank": "1", "bsr_limit”: false ⁇ may correspond to BUSINESS_CONTENTS.
  • BUSINESS_CONTENTS can contain a string in JSON format.
  • STATUS may indicate the status in which the temporary database or CDS 1612 is updated based on the list or at least one data file. For example, if STATUS is CONFIRMED, the temporary database or CDS (1612) has already been updated. If STATUS is WAITING, the temporary database or CDS (1612) is waiting to be updated. If STATUS is FAILED, the temporary database or CDS (1612) is waiting to be updated. ) update may have failed. The status related to this update can be reflected in the table 1630 of the RDS 1610 through the status subscription 1609, and this can be made known to the user 1600.
  • the electronic device 100 sends a notification (for example, a cleanup notification) when confirming a request for an update task of a temporary database, when confirming the start of an update task, and when confirming completion of an update task.
  • a notification for example, a cleanup notification
  • the shuttle 1611 may obtain second data from the cache 1613 or the CDS 1612 according to a request 1632 of the object data providing API 1614 and transmit it to the object data providing API 1614.
  • the object data providing API 1614 may include the second data in the response 1633 and transmit it to the serving layer 1616.
  • the second data may be included in the response 1632 along with the first data.
  • the mocking handler 1615 can intervene and replace the response if the signal is of the MOCK type.
  • a signal of type MOCK may be a type of specific identifying information used to test the operation of the method according to the present disclosure.
  • Each mocking handler 1620 may process a response to a MOCK type signal by intervening in the listing API 1617, search API 1618, and promotion API 1619 of the serving layer 1616.
  • FIG. 17 shows one embodiment of a method according to the present disclosure. Each component shown in FIG. 17 may correspond to a component with the same name described in FIGS. 1 to 16.
  • the user 1700 may upload at least one data file to a file database or S3 1706 through the ad hoc UI 1703 of the ad hoc service 1702.
  • the file information 1730 stored in the file information database 1705 may be updated through the ad hoc UI 1703.
  • the ad hoc UI 1703 may trigger the data extractor 1707 by calling an API.
  • Data extractor 1707 may update table 1731 of temporary database or CDS 1710 by referencing at least one data file from file database or S3 1706.
  • the cleanup scheduler 1704 may trigger the ad hoc UI 1703 at regular intervals (eg, daily) to call the data extractor 1707. That is, the temporary database or CDS 1710 may be updated at a preset period.
  • the temporary database or CDS 1710 may be updated when files in the file database or S3 1706 are added, deleted, or updated.
  • the ad hoc UI 1703 may trigger the data extractor 1707 by calling an API when a file in the file database or S3 1706 is added, deleted, or updated.
  • the data extractor 1707 checks at least one data file that has been added, deleted, or updated from the file database or S3 (1706) and extracts the temporary database or CDS (1710) corresponding to the at least one data file that has been added, deleted, or updated.
  • the table 1731 can be updated (add, delete, or update rows or columns of the table 1731).
  • the cleanup scheduler 1704, the ad hoc service 1702, or the ad hoc UI 1703 operates at a certain cycle (preferably, Every morning (at dawn time), it is possible to check whether updates to the table 1731 of the temporary database or CDS 1710 are missed, and to call the data extractor 1707 to ensure that the table 1731 of the temporary database or CDS 1710 is updated. there is.
  • the temporary database or CDS 1710 may be updated when files in the file database or S3 1706 are added, deleted, or updated.
  • the ad hoc UI 1703 checks whether files in the file database or S3 1706 have been added, deleted, or updated at a preset cycle (e.g., once every few minutes to tens of minutes, preferably once every 10 minutes).
  • the data extractor 1707 can be triggered by calling the API.
  • the data extractor 1707 checks at least one data file that has been added, deleted, or updated from the file database or S3 (1706) and extracts the temporary database or CDS (1710) corresponding to the at least one data file that has been added, deleted, or updated.
  • the table 1731 can be updated (add, delete, or update rows or columns of the table 1731).
  • the cleanup scheduler 1704, the ad hoc service 1702, or the ad hoc UI 1703 operates at a certain cycle (preferably, Every morning (at dawn time), it is possible to check whether updates to the table 1731 of the temporary database or CDS 1710 are missed, and to call the data extractor 1707 to ensure that the table 1731 of the temporary database or CDS 1710 is updated. there is.
  • the data extractor 170 may also update the cache 1711 through the cache updater 1708.
  • the cache 1711 may be updated by the user 1700.
  • the user 1700 may input specific identification information through the ad hoc UI 1703, and the data extractor 1707 may input data (e.g., data corresponding to the specific identification information through the cache updater 1708) in response to the user's input.
  • the key-value of at least one data file may be stored in the cache 1711.
  • second data corresponding to specific identification information may be provided from the cache 1711 to the object data providing API 1712.
  • data corresponding to specific identification information may be deleted from the cache.
  • data corresponding to the specific identification information may be deleted from the cache. This has the advantage that temporary data corresponding to specific identification information can be quickly delivered to the front node as needed without triggering the cleanup scheduler 1704.
  • File information 1730 may correspond to the table shown in FIG. 3B.
  • Table 1731 may correspond to any one of tables 510, 520, and 530 shown in FIG. 5.
  • the title of the file information 1730 and BUSINESS_SIGNAL of the table 1731 may correspond to the creation subject identifier 320 shown in FIG. 3B, and ID_TYPE may correspond to the type of specific identification information in FIG. 3B, that is, the identifier type 330. .
  • ID and BUSINESS_CONTENTS may refer to the keys and values shown in FIG. 3A. For example, 10001, the key of B1.txt (305) in FIG. 3A, may correspond to ID, and the value ⁇ "bsr_rank": "1", "bsr_limit”: false ⁇ may correspond to BUSINESS_CONTENTS.
  • BUSINESS_CONTENTS can contain a string in JSON format.
  • the shuttle 1709 may obtain second data from the cache 1711 or the CDS 1710 according to a request 1732 of the object data providing API 1712 and transmit it to the object data providing API 1712.
  • the object data providing API 1712 may include the second data in the response 1733 and transmit it to the serving layer 1714.
  • the second data may be included in the response 1733 together with the first data.
  • the mocking handler 1713 can intervene and replace the response if the signal is of the MOCK type.
  • a signal of type MOCK may be a type of specific identifying information used to test the operation of the method according to the present disclosure.
  • Each mocking handler 1718 may process a response to a MOCK type signal by intervening in the listing API 1715, search API 1716, and promotion API 1717 of the serving layer 1714.
  • FIG. 18 shows a method of operating the electronic device 100 according to an embodiment. Description of each step of the operation method of FIG. 18 that overlaps with the operation of the processor 110 described in FIGS. 1 to 17 will be omitted.
  • the electronic device 100 may receive a first data request from the front node.
  • the first data request may include a request for data regarding a specific object.
  • the serving layer may receive the first data request and pass it to the item data providing API.
  • the electronic device 100 may obtain first data from the main database based on the first data request.
  • the item data providing API may obtain first data from the main database based on the first data request.
  • the electronic device 100 may obtain second data from the temporary database based on the first data request.
  • the item data providing API may transmit a second data request to the shuttle based on the first data obtained from the main database.
  • the second data request may include specific identifying information regarding a specific object.
  • Shuttle obtains the row value and column information (creation subject identifier) corresponding to the specific identification information from the table according to the type of specific identification information in the temporary database, and based on this, 2 Data can be obtained.
  • the second data may be data in json format.
  • the electronic device 100 may transmit first data and second data to the front node.
  • the front node may parse the first data and the second data, distinguish the first data and the second data, and then create a page to be provided to the service user based on the first data and the second data.
  • a user of an invention according to the present disclosure may need to display additional information about items corresponding to a particular category, for example a fashion category.
  • the user can use the ad hoc UI of the electronic device 100 according to the present disclosure.
  • Users can upload additional information in the form of a file to be provided to the front node through the ad hoc UI.
  • the file may be a text file. That is, the user can upload the identifier of the fashion category (corresponding to specific identification information in this disclosure) and the corresponding information in the form of a file.
  • the electronic device 100 may add or modify tables and rows corresponding to the fashion category in the temporary database based on the uploaded file. Thereafter, the electronic device 100 receives a first data request from the front node, and if the identifier of the fashion category is confirmed from the first data, the electronic device 100 combines the first data with second data including additional information corresponding to the fashion category from the temporary database. It can be forwarded to the front node together.
  • secondary data can be displayed on the page. That is, additional information about the fashion category can be added or modified to the page where the fashion category is displayed. This modified page can be provided to service users.
  • FIG. 19 shows a method of operating the electronic device 100 according to an embodiment. Description of each step of the operation method of FIG. 19 that overlaps with the operation of the processor 110 described in FIGS. 1 to 17 will be omitted.
  • step S1910 the electronic device 100 may receive a first data request from the front node.
  • step S1920 the electronic device 100 may obtain first data from the main database based on the first data request.
  • step S1931 the electronic device 100 may transmit a second data request including specific identification information confirmed based on the first data to the temporary database.
  • step S1932 the electronic device 100 may obtain second data from the temporary database according to the second data request.
  • step S1940 the electronic device 100 may transmit first data and second data to the front node.
  • Embodiments according to the present disclosure described above may be implemented in the form of program instructions that can be executed through various computer components and recorded on a computer-readable recording medium or non-transitory recording medium.
  • the computer-readable recording medium or non-transitory recording medium may include program instructions, data files, data structures, etc., singly or in combination.
  • Program instructions recorded on the computer-readable recording medium or non-transitory recording medium may be specially designed and constructed for the present invention or may be known and usable by those skilled in the computer software field.
  • Examples of computer-readable recording media or non-transitory recording media include magnetic media such as hard disks, floppy disks and magnetic tapes, optical recording media such as CD-ROMs and DVDs, and magneto-optical media such as floptical disks.
  • magneto-optical media and hardware devices specifically configured to store and perform program instructions, such as ROM, RAM, flash memory, etc.
  • program instructions include not only machine language code such as that created by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.
  • the hardware device or electronic device may be configured to operate as one or more software modules to perform processing according to the present disclosure, and vice versa.
  • This embodiment can be represented by functional block configurations and various processing steps. These functional blocks may be implemented as various numbers of hardware, software, or combinations thereof that execute specific functions. For example, embodiments include integrated circuit configurations such as memory, processing, logic, look-up tables, etc. that can execute various functions under the control of one or more microprocessors or other control devices. can be hired. Similar to how the components can be implemented as software programming or software elements, the present embodiments include various algorithms implemented as combinations of data structures, processes, routines or other programming constructs, such as C, C++, Java ( It can be implemented in a programming or scripting language such as Java), assembler, etc. Functional aspects may be implemented as algorithms running on one or more processors. Additionally, this embodiment may employ conventional technologies for electronic environment setting, signal processing, data processing, or a combination thereof.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

프론트 노드에서 제1 데이터 요청을 수신하고, 제1 데이터 요청을 기반으로 메인 데이터베이스 에서 제1 데이터를 획득하고, 제1 데이터 요청을 기반으로 임시 데이터베이스 에서 제2 데이터를 획득하고, 제1 데이터 및 제2 데이터를 프론트 노드로 전송하는 전자 장치 및 그의 동작 방법을 제공한다.

Description

데이터 제공 방법 및 그 장치
본 개시는 데이터 제공 방법 및 그 장치에 관한 것이다.
정보통신기술의 발전에 따라 전자상거래 시장은 빠르게 발전하여 쇼핑의 한 분야로 자리잡았다. 고객은 전자 기기 등을 사용하여 온라인 상에서 물품을 구매하고, 원하는 장소로 물품을 배달시킬 수 있다. 이에 따라 판매자와 구매자 간의 매매를 중개하고 배송 서비스를 배송하는 매매 중개 서비스가 활성화되고 있다.
이와 같은 매매 중개 서비스에서는 판매하는 물품의 변화나 사용자에게 제공해야 하는 정보가 변경됨에 따라 데이터의 변경이 필요한 경우가 발생한다. 그러나 제공되는 서비스의 데이터 양이 증가함에 따라 일부 데이터를 수정하거나 추가하는데에 많은 시간이 소요되고, 데이터 사이에 무결성이나 일관성을 가지지 못하는 경우 데이터 수정 이후 서비스에 오류가 나타날 수 있게 되었다. 이에 따라, 서비스 운영을 위해 사용되는 메인 데이터베이스 이외에 데이터 수정이나 추가와 관련된 별도의 데이터 베이스를 운영할 필요성이 생겼으며, 데이터 관리를 하는 작업자는 데이터 베이스의 수정이나 추가에 익숙하지 않을 수 있으므로, 프로그래머의 도움 없이 임시 데이터 베이스에 데이터 추가를 용이하게 하고, 이를 적절한 형테로 프론트엔드에 제공할 수 있는 방안이 요구된다.
본 발명과 관련하여, KR 10-1589213 B1 건, KR 10-2003-0057528 A 등의 선행문헌들을 참조할 수 있다.
본 발명의 과제는 서비스 운영 방향에 따라 프론트 엔드에 제공될 수 있는 데이터를 제공하기 위해 임시 데이터베이스와 메인 데이터 베이스를 관리하고, 이들로부터 수신한 정보를 조합하여 프론트 엔드에 제공할 수 있는 방법 및 그 장치를 제공하는데 있다.
본 발명이 이루고자 하는 기술적 과제는 상기된 바와 같은 과제로 한정되지 않으며, 이하의 실시예들로부터 또 다른 기술적 과제들이 유추될 수 있다.
일 실시예에 따라, 전자 장치의 데이터 제공 방법은, 프론트 노드에서 제1 데이터 요청을 수신하는 단계; 제1 데이터 요청을 기반으로 메인 데이터베이스 에서 제1 데이터를 획득하는 단계; 제1 데이터 요청을 기반으로 임시 데이터베이스 에서 제2 데이터를 획득하는 단계; 및 제1 데이터 및 제2 데이터를 프론트 노드로 전송하는 단계를 포함할 수 있다.
또한, 데이터 제공 방법은, 특정 식별 정보를 포함하는 제2 데이터 요청을 임시 데이터 베이스에 전송하는 단계; 및 제2 데이터 요청에 따라 임시 데이터베이스로부터 제2 데이터를 획득하는 단계를 포함할 수 있다.
또한, 특정 식별 정보는 제1 데이터를 기반으로 확인될 수 있다.
또한, 제2 데이터는 임시 데이터베이스에서 특정 식별 정보에 따라 동적 설정 데이터 베이스 로부터 획득된 설정 정보를 기반으로 확인된 테이블로부터 획득될 수 있다.
또한, 제2 데이터는 제1 데이터 요청에 대응하는 적어도 하나의 키-값 쌍을 포함할 수 있다.
또한, 키-값 쌍의 키는 키에 대응하는 값을 생성한 주체를 식별하는 정보일 수 있다.
또한, 임시 데이터베이스는 적어도 하나의 데이터 파일을 기초로 갱신되고, 적어도 하나의 데이터 파일 각각은 적어도 하나의 키-값 쌍 및 각각의 키-값 쌍을 생성한 주체를 식별하는 정보를 포함할 수 있다.
또한, 적어도 하나의 데이터 파일 각각은 데이터 파일에 포함되는 정보의 형식 및 데이터 파일의 크기를 기초로 검증될 수 있다.
또한, 임시 데이터베이스는 적어도 하나의 테이블을 포함하고, 적어도 하나의 테이블 각각은 특정 식별 정보의 타입 에 따라 서로 구별될 수 있다.
또한, 적어도 하나의 테이블 각각은, 적어도 하나의 테이블 각각에 대응하는 작업 구성 파일 을 기초로 구성되는 테이블로 교체됨으로써 갱신될 수 있다.
또한, 적어도 하나의 데이터 파일이 업로드될 때, 각 데이터 파일에 포함되는 특정 식별 정보의 타입, 값의 타입, 그룹핑 여부 및 데이터 만료일 정보가 함께 업로드될 수 있다.
또한, 제1 임시 데이터 파일은, 구분자를 이용하여 제1 임시 데이터에 포함된 하나 이상의 정보를 서로 구분할 수 있도록 구성될 수 있고, 데이터 제공 방법은, 구분자를 이용하여 하나 이상의 임시 데이터에 대응하는 하나 이상의 임시 데이터 파일을 파싱(parsing)하여 하나 이상의 임시 데이터를 확인하는 단계를 포함할 수 있다.
또한, 데이터 제공 방법은, 제2 데이터에 대한 데이터 만료일이 경과하지 않은 경우, 제1 데이터 및 제2 데이터를 프론트 노드로 전송하는 단계를 포함할 수 있다.
또한, 데이터 제공 방법은, 데이터 만료일로부터 기 설정된 기간 이전에 알림을 제공하는 단계를 더 포함할 수있다.
또한, 데이터 제공 방법은, 캐시(cache)로부터 제2 데이터를 획득하는 단계를 포함하고, 캐시는 임시 데이터베이스를 기초로 갱신될 수 있다.
또한, 하나 이상의 특정 식별 정보가 확인되면 특정 식별 정보에 대응하는 데이터가 캐시에서 삭제될 수 있다.
또한, 임시 데이터베이스는 기 설정된 주기로 갱신될 수 있다.
또한, 데이터 제공 방법은, 임시 데이터베이스의 갱신 작업의 요청을 확인한 경우, 갱신 작업의 시작을 확인한 경우 및 갱신 작업의 완료를 확인한 경우 각각에 대해 알림을 제공할 수 있다.
또한, 데이터 제공 방법은, 임시 데이터베이스에 포함된 데이터의 활성화 여부 정보를 표시하는 단계를 포함할 수 있다.
또한, 전자 장치는, 적어도 하나의 프로그램이 저장된 메모리; 및 적어도 하나의 프로그램을 실행함으로써, 프론트 노드에서 제1 데이터 요청을 수신하고, 제1 데이터 요청을 기반으로 메인 데이터베이스에서 제1 데이터를 획득하고, 제1 데이터 요청을 기반으로 임시 데이터베이스에서 제2 데이터를 획득하고, 제1 데이터 및 제2 데이터를 프론트 노드로 전송하는 프로세서를 포함할 수 있다.
또한, 컴퓨터로 읽을 수 있는 비일시적 기록매체는, 상술한 동작 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록할 수 있다.
기타 실시예들의 구체적인 사항은 상세한 설명 및 도면들에 포함된다.
본 발명에 따르면, 사용자는 별도의 코딩 없이도 임시 데이터를 메인 데이터와 함께 프론트엔드에 제공하여, 서비스 이용자가 임시 데이터를 메인 데이터와 함께 제공받을 수 있다. 따라서 프로그래머 또는 개발자 자원이 절약되는 효과가 있다.
또한 본 발명에 따르면, 사용자는 유저 인터페이스를 통해 임시 데이터베이스의 테이블을 생성, 삭제, 관리할 수 있다.
또한 본 발명에 따르면, 임시 데이터베이스를 활용하여 백엔드에서 제공한 데이터에 포함된 데이터 중에 임시 데이터베이스에서 전달한 데이터를 구별하고, 이를 기반으로 프론트 엔드에서 데이터를 활용하여 새로운 서비스를 제공할 수 있다
또한 본 발명에 따르면, 임시 데이터는 임시 데이터베이스의 테이블 형태에 저장되어, 특정 식별 정보를 기반으로 복수개의 테이블에서 어떤 임시 데이터를 전달해야 하는지 구별할 수 있다
또한 본 발명에 따르면, 메인 데이터를 보관하는 메인 데이터베이스를 별도로 수정하거나 메인 테이터베이스에 대한 데이터 요청 양식을 수정하지 않아도 메인 데이터베이스에 대한 특정 식별 정보를 포함하는 데이터 요청을 활용하여 임시 데이터베이스에서 임시 데이터를 획득할 수 있는 이점이 있다.
또한 본 발명에 따르면, 프론트 서비스의 변경이 있고, 그에 따른 일부 데이터의 변경이 필요한 경우, 본 발명을 활용하여 해당 서비스에 관련된 테이블을 추가하고, 데이터 요청 시 식별자를 통해 해당 table의 데이터를 획득하고 프론트 노드에서 제공할 수 있다.
발명의 효과는 이상에서 언급한 효과만으로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 청구범위 기재로부터 당해 기술 분야의 통상의 기술자에게 명확하게 이해될 수 있다.
도 1은 본 개시에 따른 전자 장치의 일 실시예를 나타낸다.
도 2는 본 개시에 따른 데이터 제공 방법의 일 실시예를 나타낸다.
도 3a 는 본 개시에 따른 데이터 파일의 일 실시예를 나타낸다.
도 3b 는 본 개시에 따른 데이터 파일에 관한 정보의 일 실시예를 나타낸다.
도 4는 본 개시에 따른 데이터 파일에 관한 정보에 포함될 수 있는 정보의 종류를 나타낸다.
도 5는 본 개시에 따른 데이터의 테이블을 나타낸다.
도 6 은 본 개시에 따른 데이터 제공 방법에 관한 임시 데이터의 요청 및 응답을 나타낸다.
도 7 은 본 개시에 따른 데이터 제공 방법의 일 실시예를 나타낸다.
도 8 은 본 개시에 따른 데이터 제공 방법의 일 실시예를 나타낸다.
도 9 는 본 개시에 따른 데이터 제공 방법의 일 실시예를 나타낸다.
도 10 은 본 개시에 따른 데이터 제공 방법의 일 실시예를 나타낸다.
도 11 은 본 개시에 따른 데이터 제공 방법에 관한 사용자 인터페이스를 나타낸다.
도 12 는 본 개시에 따른 데이터 제공 방법에 관한 사용자 인터페이스를 나타낸다.
도 13 은 본 개시에 따른 데이터 제공 방법에 관한 사용자 인터페이스를 나타낸다.
도 14 는 본 개시에 따른 데이터 제공 방법의 일 실시예를 나타낸다.
도 15 는 본 개시에 따른 데이터 제공 방법의 일 실시예를 나타낸다.
도 16 은 본 개시에 따른 데이터 제공 방법의 일 실시예를 나타낸다.
도 17 은 본 개시에 따른 데이터 제공 방법의 일 실시예를 나타낸다.
도 18 은 본 개시에 따른 데이터 제공 방법의 일 실시예를 나타낸다.
도 19 는 본 개시에 따른 데이터 제공 방법의 일 실시예를 나타낸다.
본 개시에 기술된 실시예는 본 개시를 제한하는 것이 아니라 예시하는 것이고, 통상의 기술자는 첨부된 청구범위에 의해 정의된 본 개시의 범주를 벗어나지 않으면서, 다수의 대안적인 실시예를 설계할 수 있다. 실시 예들에서 사용되는 용어는 본 개시에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어들을 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 개시에서 사용되는 용어는 단순한 용어의 명칭이 아닌, 그 용어가 가지는 의미와 본 개시의 전반에 걸친 내용을 토대로 정의되어야 한다.
본 명세서에서 사용되는 단수의 표현은 문맥상 명백하게 반대되는 기재가 존재하지 않는 한, 단수는 물론 복수를 모두 포함한다.
본 명세서 전체에서 어떤 부분이 어떤 구성요소들 또는 어떤 단계들을 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한, 어떤 부분이 구성요소들 또는 단계들을 반드시 모두 포함해야 하는 것은 아니고, 청구범위 또는 명세서 전체에 열거된 것 이외의 구성요소 또는 단계가 포함되는 것을 배제하는 것도 아니며, 단지 이들을 더 포함할 수 있음을 의미한다.
또한, 본 명세서에서 사용되는 제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 서수를 포함하는 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 문맥상 명세서의 일 부분에서 일 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리범위를 벗어나지 않으면서 제1 구성요소는 명세서의 다른 부분에서 제2 구성요소로 명명될 수 있고, 반대로 제2 구성요소도 명세서의 다른 부분에서 제1 구성요소로 명명될 수 있다.
본 명세서에서 "매커니즘", "요소", "수단", "구성"과 같은 용어는 넓게 사용될 수 있으며, 기계적이고 물리적인 구성들로서 한정되는 것은 아니다. 상기 용어는 프로세서 등과 연계하여 소프트웨어의 일련의 처리들(routines)의 의미를 포함할 수 있다.
본 명세서(특히 청구범위에서)에서 "상기"의 용어 및 이와 유사한 지시 용어의 사용은 단수 및 복수 모두에 해당하는 것일 수 있다. 또한, 범위(range)를 기재한 경우 상기 범위에 속하는 개별적인 값을 포함하는 것으로서(이에 반하는 기재가 없다면), 상세한 설명에 상기 범위를 구성하는 각 개별적인 값을 기재한 것과 같다. 마지막으로, 방법을 구성하는 단계들에 대하여 명백하게 순서를 기재하거나 반하는 기재가 없다면, 상기 단계들은 적당한 순서로 재배열되어 행해질 수 있고, 반드시 상기 단계들의 기재 순서에 한정되는 것은 아니다. 모든 예들 또는 예시적인 용어(예들 들어, 등등)의 사용은 단순히 기술적 사상을 상세히 설명하기 위한 것으로서 청구범위에 의해 한정되지 않는 이상 상기 예들 또는 예시적인 용어로 인해 범위가 한정되는 것은 아니다. 통상의 기술자는 본 명세서에 개시된 실시예에 설계 조건 및 팩터에 따라 다양한 수정, 조합 및 변경을 부가하여 특허청구범위 또는 그 균등물의 범주에 속하는 새로운 실시예를 구성할 수 있다.
이하에서는 도면을 참조하여 본 개시의 실시예를 설명한다.
도 1 은 본 개시의 적어도 하나의 실시예를 실행하는데 사용될 수 있는 전자 장치(100)의 예시적이고 단순화된 블록도를 나타낸다. 다양한 실시예에서, 전자 장치(100)는 본 개시에서 서술된 임의의 시스템 또는 방법을 구현하는데 사용될 수 있다. 예를 들어, 전자 장치(100)는 데이터 서버, 웹 서버, 휴대용 컴퓨팅 디바이스, 개인용 컴퓨터, 태블릿 컴퓨터, 워크스테이션, 휴대폰, 스마트 폰(smart phone) 또는 아래에서 서술되는 임의의 다른 디바이스를 포함하는 임의의 전자 장치로서 사용되도록 구성될 수 있다.
전자 장치(100)는 메모리(120) 및 메모리(120)와 통신하도록 구성될 수 있는 하나 이상의 캐시 메모리 및 메모리 제어기를 갖는 하나 이상의 프로세서(110)를 포함할 수 있다. 추가적으로, 전자 장치(100)는 하나 이상의 포트(예컨대, USB(Universal Serial Bus), 헤드폰 잭, 라이트닝(Lightning) 커넥터, 썬더볼트(Thunderbolt) 커넥터 등)를 통해 전자 장치(100)에 연결될 수 있는 다른 디바이스를 포함할 수 있다. 전자 장치(100)에 연결될 수 있는 디바이스는 광섬유 커넥터를 수용하도록 구성되는 복수의 포트를 포함할 수 있다. 도시된 전자 장치(100)의 구성은 디바이스의 바람직한 실시예를 예시할 목적으로 특정 예시로서만 의도된다. 도시된 전자 장치(100)에는 본 실시예들과 관련된 구성요소들만이 도시되어 있다. 따라서, 전자 장치(100)에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 더 포함될 수 있음은 당해 기술분야의 통상의 기술자에게 자명하다.
프로세서(110)는 전자 장치(100)가 본 개시에서 서술된 임의의 실시예의 단계 또는 기능을 제공하도록 하기 위해 이용될 수 있다. 예를 들어, 프로세서(110)는 전자 장치(100) 내의 메모리(120)에 저장된 프로그램들을 실행함으로써, 전자 장치(100)를 전반적으로 제어한다. 프로세서(110)는 전자 장치(100) 내에 구비된 CPU(central processing unit), GPU(graphics processing unit), AP(application processor) 등으로 구현될 수 있으나, 이에 제한되지 않는다.
메모리(120)는 전자 장치(100) 내에서 처리되는 각종 데이터들을 저장하는 하드웨어로서, 메모리(120)는 전자 장치(100)에서 프로세서(110)를 통해 처리된 데이터들 및 처리될 데이터들을 저장할 수 있다. 또한, 메모리(120)는 본 개시의 적어도 하나의 실시예의 기능을 제공할 수 있는 기본 프로그래밍 및 데이터 구조를 저장하는 것은 물론, 본 개시의 실시예의 기능을 제공할 수 있는 애플리케이션들(프로그램, 코드 모듈, 명령어), 드라이버들 등을 저장할 수 있다. 메모리(120)는 DRAM(dynamic random access memory), SRAM(static random access memory) 등과 같은 RAM(random access memory), ROM(read-only memory), EEPROM(electrically erasable programmable read-only memory), CD-ROM, 블루레이 또는 다른 광학 디스크 스토리지, HDD(hard disk drive), SSD(solid state drive), 또는 플래시 메모리를 포함할 수 있다.
본 개시에 따른 방법 및 각 단계는 전자 장치(100) 또는 프로세서(110)가 수행할 수 있다. 전자 장치(100)는 프로세서(110)의 제어에 의해 동작한다. 설명을 간단히 하기 위하여 아래부터는 전자 장치(100)가 본 개시에 따른 방법 및 각 단계의 수행 주체임을 전제하여 설명한다.
도 2 는 본 개시에 따른 결제 서비스 제공 방법의 일 실시예를 나타낸다. 일 실시예에서, 전자 장치(100)는 프론트 노드에서 제1 데이터 요청을 수신하고, 제1 데이터 요청을 기반으로 메인 데이터베이스 에서 제1 데이터를 획득하고, 제1 데이터 요청을 기반으로 임시 데이터베이스 에서 제2 데이터를 획득하고 제1 데이터 및 제2 데이터를 프론트 노드(미도시)로 전송할 수 있다.
"프론트 노드(미도시)"는 백엔드 노드로부터 데이터를 수신하고, 사용자에게 제공할 페이지를 생성할 수 있다. 프론트 노드는 사용자의 단말로 페이지를 생성하여 서비스 이용자에게 서비스를 제공할 수 있다.
서빙 레이어(214)는 프론트 노드로 데이터를 제공할 수 있다. 서빙 레이어(214)는 전자 장치(100)에 포함될 수 있다. 서빙 레이어(214)는 복수의 API들을 포함하고, 프론트 노드의 요청에 따라 특정 API에 대응하는 백엔드 노드 또는 서버로부터 데이터를 수신하여 프론트 노드에 전달할 수 있다. 구체적으로, 서빙 레이어(214)는 리스팅 API(215), 검색 API(216) 및 프로모션 API(217) 중 적어도 하나를 포함할 수 있다. 리스팅 API(215)는 프론트 노드로 데이터의 리스트를 제공할 수 있다. 검색 API(216)은 프론트 노드로 데이터의 검색 결과를 제공할 수 있다. 프로모션 API(217)는 프론트 노드로 프로모션에 관한 데이터를 제공할 수 있다.
프론트 노드는 서빙 레이어(214)로 특정한 객체의 특정 식별 정보를 포함하는 요청을 송신할 수 있다. 서빙 레이어(214)는 객체 데이터 제공 API(213)로 제1 데이터 요청을 송신할 수 있다. 객체 데이터 제공 API(213)는 전자 장치(100)에 포함될 수 있다. 구체적으로, 제1 데이터 요청은 특정한 객체에 관한 데이터의 요청일 수 있다. 다시 말해, 제1 데이터 요청은 프론트 노드로부터의 요청에 대응하는 특정한 객체의 특정 식별 정보를 포함할 수 있다. 객체 데이터 제공 API(213)는 서빙 레이어(214)의 제1 데이터 요청에 대응하여 제1 데이터를 획득하고, 제 1 데이터를 서빙 레이어(214)로 제공할 수 있다.
객체 데이터 제공 API(213)는 제1 데이터 요청을 기반으로 메인 데이터베이스에서 제1 데이터를 획득 할 수 있다. 메인 데이터베이스는 특정한 객체에 관한 데이터를 저장할 수 있다. 제1 데이터 요청은 특정한 객체에 관한 식별 정보를 포함할 수 있고, 객체 데이터 제공 API(213)는 식별 정보를 이용하여 메인 데이터베이스로부터 식별 정보에 대응하는 객체에 관한 제1 데이터를 획득할 수 있다.
메인 데이터베이스는 방대한 양의 데이터를 저장할 수 있으며, 그에 따라 메인 데이터베이스로의 데이터 요청 및 데이터 제공 작업도 빈번하게 이루어질 수 있다. 따라서 메인 데이터베이스의 데이터 제공 작업에 대한 방해가 최소화되도록, 메인 데이터베이스에 대한 데이터 변경, 수정, 삭제, 갱신 작업 역시 최소화될 필요가 있다. 따라서 임시 데이터를 메인 데이터베이스에 반영하는 대신, 별도의 임시 데이터베이스를 사용하고, 임시 데이터베이스로부터 임시 데이터를 로드하여 제공할 수 있다.
객체 데이터 제공 API(213)는 제1 데이터 요청을 셔틀(212)에 전달할 수 있다. 셔틀(212)는 전자 장치(100)의 일부일 수 있다. 셔틀(212)은 제1 데이터 요청을 기반으로 임시 데이터베이스(210)에서 제2 데이터를 획득할 수 있다. 임시 데이터베이스(210)는 특정한 객체에 관한 데이터를 저장할 수 있다. 또한, 임시 데이터베이스(210)는 예를 들어, Spark Cassandra 등의 분산형 데이터베이스이거나, 그를 포함할 수 있다. 셔틀(212)은 제1 데이터 요청 또는 제1 데이터를 기반으로 확인되는 특정 식별 정보를 이용하여 임시 데이터베이스(210)로부터 특정 식별 정보에 대응하는 객체에 관한 제2 데이터를 획득할 수 있고, 제2 데이터를 객체 데이터 제공 API(213)에 전달할 수 있다. 제2 데이터는 특정한 객체에 관한 임시 데이터를 포함할 수 있다. 객체 데이터 제공 API(213) 또는 프로세서는 제1 데이터 및 제2 데이터를 서빙 레이어(214)로 전달하여, 제1 데이터 및 제2 데이터가 프론트 노드로 전송될 수 있다.
일 실시예에서, 셔틀(212)은 특정 식별 정보를 포함하는 제2 데이터 요청을 임시 데이터베이스(210)에 전송하고, 제2 데이터 요청에 따라 임시 데이터베이스(210)로부터 제2 데이터를 획득할 수 있다. 제2 데이터 요청은 제1 데이터 또는 제1 데이터 요청을 기반으로 생성될 수 있다. 제2 데이터 요청 및 제2 데이터에 관하여는 이후 도 6을 참조하여 자세히 설명한다.
일 실시예에서, 셔틀(212)은 캐시(211)로부터 제2 데이터를 획득할 수 있고, 캐시(211)는 임시 데이터베이스(210)를 기초로 갱신될 수 있다. 캐시(211)는 제2 데이터와 같이 임시 데이터베이스(210)에 저장된 데이터 중 일부를 포함할 수 있다. 이는 임시 데이터베이스(210)로부터 직접 데이터를 획득하는 것보다 더 신속하게 데이터를 획득할 수 있는 이점이 있다.
일 실시예에서, 제2 데이터는 임시 데이터베이스(210)에서 특정 식별 정보에 따라 동적 설정 데이터베이스(209)로부터 획득된 설정 정보를 기반으로 확인된 테이블로부터 획득될 수 있다. 이러한 테이블 및 동적 설정 데이터베이스(209)의 자세한 내용에 관하여는 이후 도 5 를 참조하여 자세히 설명한다.
일 실시예에서, 임시 데이터베이스(210)에 데이터를 추가, 수정 또는 갱신하기 위하여 사용자(201)는 애드혹 서비스(203)를 통해 적어도 하나의 데이터 파일을 업로드(202)할 수 있다. 애드혹 서비스(203)은 애드혹 UI(User Interface)(204)를 포함할 수 있고, 사용자(201)는 애드혹 UI(204)를 이용하여 적더오 하나의 데이터 파일을 업로드(202)할 수 있다.
적어도 하나의 데이터 파일은 텍스트 파일 또는 csv(comma separated values) 파일일 수 있다. 적어도 하나의 데이터 파일의 실시예는 도 3a 에 나타나 있다. 적어도 하나의 데이터 파일은 파일 데이터베이스(205)에 저장될 수 있고, 데이터 추출기(208)는 적어도 하나의 데이터 파일로부터 임시 데이터베이스(210)를 갱신할 수 있다. 즉, 임시 데이터베이스(210)는 적어도 하나의 데이터 파일을 기초로 갱신될 수 있다. 파일 데이터베이스(205)는 Amazon S3 등의 클라우드 스토리지를 포함할 수 있다.
일 실시예에서, 적어도 하나의 데이터 파일 각각은 적어도 하나의 키-값 쌍을 포함할 수 있다. 적어도 하나의 키-값 쌍의 키는 특정 식별 정보일 수 있고, 값은 특정 식별 정보에 대응되는 값일 수 있다. 여기서 각각의 키에 대응하는 값은 단일 값일 수도 있지만, json(JavaScript Object Notation) 형태 등의 데이터 포맷으로 표현된 하나 이상의 값을 포함할 수도 있다. 일 실시예에서, 적어도 하나의 데이터 파일 각각은 구분자를 이용하여 적어도 하나의 데이터 파일 각각에 포함된 하나 이상의 정보를 서로 구분할 수 있도록 구성될 수 있다. 구분자는 탭(tab) 또는 콤마(,)등일 수 있다. 구분자는 도 2 의 애드혹 UI(204)를 통해 설정될 수 있다. 사용자(201)는 애드혹 UI(204)를 통해 사용할 구분자를 결정할 수 있다.
도 3a 를 참조하여 설명하면, A1.txt 파일(301)은 키 10001, 키 10002에 각각 대응하는 값으로 2 및 3을 각각 포함할 수 있다. 각각의 키 및 값은 콤마로 구분된다. A2.txt 파일(302)은 키 10001에 대응하는 값으로 3000을 가질 수 있다. A3.txt 파일(303)은 키 19101053에 대응하는 값으로 true를 가질 수 있다. A4.txt 파일(304)은 키 10001에 대응하는 값으로 retail/image01.png를 가질 수 있다.
B1.txt 파일(305)은 키 10001에 대응하는 값으로 {"bsr_rank": "1", "bsr_limit": false}를 가질 수 있다. 이는 json 포맷에 대응될 수 있다.
적어도 하나의 데이터 파일 각각은 적어도 하나의 키-값 쌍을 생성한 주체(또는 사용자)를 식별하는 정보(다시 말해, 생성 주체 식별자)에 대응될 수 있다. 생성 주체 식별자는 제2 데이터의 사용처를 식별하는 정보일 수 있다. 생성 주체 식별자를 통해, 프론트 노드에서는 적어도 하나의 데이터 파일에 포함되는 키-값 쌍 또는 제2 데이터의 사용처를 결정할 수 있다. 즉, 생성 주체 식별자는 사용자와 프론트 노드 사이에서 약속된 식별자일 수 있으며, 이는 생성 주체뿐만 아니라 임시 데이터베이스에 필요한 데이터를 요청하고, 이를 수신한 프론트 엔드 노드에서 임시 데이터베이스에서 획득한 정보를 구별할 수 있도록 하는 식별 정보를 포함할 수 있다.
일 실시예에서, 적어도 하나의 데이터 파일 각각은 데이터 파일에 포함되는 정보(키 및 값)의 형식 또는 데이터 파일의 크기를 기초로 검증될 수 있다. 예를 들어, 적어도 하나의 데이터 파일에 포함되는 키가 integer 타입인지 혹은 값이 string 타입인지 검증될 수 있고, 데이터 파일인 1메가바이트 이하인지 등이 검증될 수 있다. 이는 프로그래밍에 익숙하지 않은 사용자(201)가 잠재적 프로그램 오류를 야기할 수 있는 데이터를 업로드하는 문제를 방지할 수 있는 효과가 있다.
일 실시예에서, 적어도 하나의 데이터 파일에 관한 정보는 파일 정보 데이터베이스(206)에 보관될 수 있다. 파일 정보 데이터베이스(206)는 Amazon RDS 등의 관계형 데이터베이스를 포함할 수 있다. 적어도 하나의 데이터 파일에 관한 정보는 이후 도 3b 와 관련하여 자세히 설명한다.
일 실시예에서, 파일 데이터베이스(205)에 저장된 적어도 하나의 데이터 파일을 기초로 임시 데이터베이스(210)를 갱신하기 위하여, 작업 구성 파일이 작업 구성 파일 데이터베이스(207)에 업로드될 수 있다. 작업 구성 파일 데이터베이스는 Amazon S3 등의 데이터베이스를 포함할 수 있다. 데이터 추출기(208)는 작업 구성 파일 데이터베이스(207)에 저장된 작업 구성 파일을 참조하여 파일 데이터베이스(205)에 저장된 하나 이상의 데이터 파일을 확인하고, 임시 데이터베이스(210)를 갱신할 수 있으며, 이에 따라 임시 데이터베이스(210)의 테이블이 갱신되고, 프론트 노드로 전달할 데이터에 대응하는 테이블이나 로우(row)를 설정하기 위해 동적 설정 데이터베이스(209)에 설정 값을 업데이트 할 수 있다. 데이터 추출기(208)는 Spark Streaming 등의 데이터 스트리밍 도구를 포함할 수 있다. 작업 구성 파일은 하나 이상의 데이터 파일을 일괄 작업하기 위한 정보를 포함할 수 있다. 이는 임시 데이터베이스(210)를 적절한 빈도로 갱신하여, 임시 데이터베이스(210)에 가해지는 부하를 조절할 수 있는 이점이 있다.
일 실시예에서, 데이터 추출기(208)는 임시 데이터베이스(210)를 갱신한 다음, 임시 데이터베이스(210)의 갱신에 관한 설정 정보를 동적 설정 데이터베이스(209)에 업로드할 수 있다. 셔틀(212)은 동적 설정 데이터베이스(209)로부터 이러한 설정 정보를 임시 데이터베이스(210)로부터 제2 데이터를 획득하는데 활용할 수 있다. 동적 설정 데이터베이스(209)의 설정 정보는 셔틀(212)이 임시 데이터베이스(210)로부터 어떤 데이터를 참조해야 하는지에 관한 정보를 포함할 수 있다. 예를 들어, 셔틀(212)은 동적 설정 데이터베이스(209)의 설정 정보를 기초로 어떤 테이블 및 행/열 정보를 참조해야 하는지 확인하고, 이를 기초로 임시 데이터베이스(210)로부터 제2 데이터를 획득할 수 있다. 이와 같이 동적 설정 데이터베이스(209)에서 설정 정보를 관리함으로써 임시 데이터베이스(210)의 데이터를 적응적으로 업데이트 할 수 있으며, 사용되는 데이터의 버전이 변경되는 경우에도 동적 설정 데이터베이스(209)를 업데이트함으로써 프론트 노드로 전달될 데이터를 용이하게 설정할 수 있다.
동적 설정 데이터베이스(209)에는 임시 데이터베이스(210)의 갱신된 테이블 이름 및 해당 테이블의 갱신된 열 정보가 포함될 수 있다.
도 3b 는 본 개시에 따른 적어도 하나의 데이터 파일에 관한 정보의 일 실시예를 나타낸다. 사용자가 업로드한 적어도 하나의 데이터 파일은 도 3b 에 도시된 테이블 형태로 파일 정보 데이터베이스에 저장될 수 있다. 적어도 하나의 데이터 파일에 관한 정보는 각 데이터 파일의 식별자(310), 생성 주체 식별자(320), 식별자 타입(330) 및 저장 경로(340) 등의 정보를 포함할 수 있다.
식별자(310)는 적어도 하나의 데이터 파일의 순번에 대응될 수 있다.
생성 주체 식별자(320)는 적어도 하나의 데이터 파일을 생성한 주체를 식별하는 정보일 수 있으며, 상술한 바와 같이, 적어도 하나의 데이터 파일에 포함되는 키-값 쌍이 사용되는 사용처를 정하는 정보일 수 있다.
식별자 타입(330)은 적어도 하나의 데이터 파일에 포함되는 키-값 쌍의 키의 타입을 의미할 수 있다. 구체적으로, 적어도 하나의 데이터 파일에 포함되는 키-값 쌍의 키는 특정 식별 정보에 대응할 수 있고, 특정 식별 정보는 일정한 기준으로 분류될 수 있다. 예를 들어, 특정 식별 정보는 벤더 아이템(VENDOR_ITEM) 타입의 식별 정보일 수 있고, 카테고리(CATEGORY) 타입의 식별 정보일 수 있고, 멤버(MEMBER) 타입의 식별 정보일 수 있다.
저장 경로(340)는 적어도 하나의 데이터 파일 각각이 파일 데이터베이스에 저장된 경로를 나타낼 수 있다.
예를 들어, 식별자(310)가 2인 행은 도 3a의 A2.txt파일(302)에 대응될 수 있다. 즉, 식별자(310)가 2인 행의 저장 경로(340) 셀은 도A2.txt 파일(302)가 파일 데이터베이스 내에 저장된 경로를 포함할 수 있다. 식별자(310)가 2인 행을 참조하면, 생성 주체 식별자(320)는 CATEGORY_IMAGE로, 특정한 카테고리에 대응하는 이미지를 추가 / 변경 / 삭제 하는 작업을 의미할 수 있다. 이 경우, 식별자 타입(330)은 CATEGORY로 설정될 수 있다. 즉, 이 작업과 관련된 데이터 파일인 A2.txt파일(302)에 포함되는 키는 특정한 카테고리에 대응될 수 있다. 예를 들어, A2.txt파일(302) 에는 "티셔츠" 카테고리에 대응되는 키인 10001이 포함될 수 있고, "티셔츠" 카테고리에 대응하는 이미지를 변경하기 위하여 10001 키에 대응되는 값은 새로운 이미지의 URL(Uniform Resource Locator), 예를 들어 "retail/image01.png" 등일 수 있다.
또한 예를 들어, 식별자(310)가 1인 행은 도 3a의 A1.txt 파일(301)에 대응될 수 있고, 식별자(310)가 3인 행은 도 3a의 A3.txt 파일(303)에 대응될 수 있고, 식별자(310)가 4인 행은 도 3a의 A4.txt 파일(304)에 대응될 수 있다.
일 실시예에서, 적어도 하나의 데이터 파일이 업로드될 때, 각 데이터 파일에 포함되는 특정 식별 정보의 타입, 값의 타입, 그룹핑 여부 및 데이터 만료일 정보가 함께 업로드될 수 있다.
특정 식별 정보의 타입에는 예를 들어 PRODUCT, ITEM, VENDOR_ITEM, CATEGORY, VENDOR, MEMBER, UNKNOWN 등의 특정 식별 정보의 타입이 있을 수 있다.
값의 타입에는 예를 들어 TEXT, BOOLEAN, DOUBLE, LONG, UNKNOWN 등의 데이터 기술 타입이 포함될 수 있다.
그룹핑 여부에는 값이 복수의 값의 세트일 수 있는지 여부가 포함될 수 있다. 예를 들어 그룹핑 여부가 "SINGLE"인 경우, 특정 식별 정보에 대응하는 값은 단일 값임을 의미할 수 있다. 다른 예를 들어, 그룹핑 여부가 "MULTI"인 경우, 특정 식별 정보에 대응하는 값은 복수 개이거나, 다른 키-값 쌍이 될 수 있음을 의미할 수 있다.
데이터 만료일 정보는 적어도 하나의 데이터 파일 각각이 유효한 기간을 의미할 수 있다. 즉, 데이터 만료일이 2022년 5월 16일로 지정된 경우, 데이터 파일은 2022년 5월 16일까지만 유효하며, 데이터 파일에 포함되는 정보 역시 2022년 5월 16일까지만 유효할 수 있다. 따라서, 데이터 파일에 포함되는 정보가 임시 데이터베이스에 이미 저장되어 있다고 해도, 이는 데이터 만료일인 2022년 5월 16일까지만 프론트 노드에 제공될 수 있다. 즉, 전자 장치(100)는 제2 데이터에 대한 데이터 만료일이 경과하지 않은 경우, 제2 데이터를 프론트 노드로 전송할 수 있다. 또한, 전자 장치(100)는 데이터 만료일로부터 기 설정된 기간 이전에 알림을 제공할 수 있다. 이는 사용자가 임시 데이터가 만료되기 전에 임시 데이터를 적절히 갱신할 수 있도록 하는 이점이 있다.
도 4 는 본 개시에 따른 데이터 파일에 관한 정보에 포함될 수 있는 정보의 종류를 나타낸다. 애드혹 데이터 전달 오브젝트(AdHocDto, 410) 정보는 본 개시에 따른 임시 데이터에 관한 정보를 포함할 수 있다. 즉, 애드혹 데이터 전달 오브젝트(410)에 나타난 각 행은 도 3b 에 나타난 데이터 파일에 관한 정보, 즉 테이블의 열 정보일 수 있다. 따라서, 데이터 파일에 관한 정보에는 식별자(id) 정보, 제목(title) 정보, 설명(Description) 정보, 내용(Content) 정보, 식별자 타입(idType) 정보, 애드혹 생성일(또는 파일 생성일, createdAt) 정보, 애드혹 생성 주체(또는 파일 생성 주체, createdBy) 정보, 애드혹 수정일(또는 파일 수정일, modifiedAt) 정보, 애드혹 수정 주체(또는 파일 수정 주체, modifiedBy) 정보, 애드혹 데이터 또는 데이터 파일의 임시 데이터베이스 업로드 상태(status) 정보 및 데이터 파일의 저장 경로(s3Path) 정보 등이 포함될 수 있다.
애드혹 데이터 전달 오브젝트(410)의 일부는 애드혹 데이터 히스토리 정보(AdHocDtoHistory, 430)일 수 있다. 애드혹 데이터 히스토리 정보(430)에는 식별자(id) 정보, 애드혹 식별자(adHocID)정보, 설명(Description) 정보, 애드혹 생성일(또는 파일 생성일, createdAt) 정보, 애드혹 생성 주체(또는 파일 생성 주체, createdBy) 정보 등이 포함될 수 있다.
식별자 타입(idType) 정보(420)에는 식별자 타입의 식별자(id) 정보 및 타입 정보가 포함될 수 있다.
각 정보(410, 420, 430)는 관리자에 의해 생성, 변경, 삭제될 수 있으며, 사용자에 의해 생성, 변경, 삭제될 수 있다. 각 정보의 관리를 위하여, 사용자의 권한은 관리자에 비해 축소될 수 있다.
도 5 는 본 개시에 따라 임시 데이터베이스에 저장될 수 있는 데이터의 테이블을 나타낸다. 일 실시예에서, 임시 데이터베이스는 적어도 하나의 테이블을 포함하고, 적어도 하나의 테이블 각각은 특정 식별 정보의 타입에 따라 서로 구별될 수 있다. 특정 식별 정보의 타입은 도 3b 에 나타난 식별자 타입(330)에 해당하는 것일 수 있다. 예를 들어, 벤더 아이템 테이블(510)은 도 3b 에 나타난 VENDOR_ITEM 타입의 특정 식별 정보 및 해당 특정 식별 정보에 대응하는 값들을 테이블 형태로 포함할 수 있다.
예를 들어, 도 3b의 식별자(310)가 1인 행의 특정 식별 정보의 타입, 즉, 식별자 타입(310)은 VENDOR_ITEM이다. 도 3b의 식별자(310)가 1인 행은 도 3a의 A1.txt 파일(301)에 대응된다. 도 3b의 식별자(310)가 1인 행은 생성 주체 식별자(320)가 VI_BEST_SELLER_RANKING 이므로, 벤더 아이템 테이블(510)의 두 번째 열의 제목은 VI_BEST_SELLER_RANKING으로 설정될 수 있다. 그리고, A1.txt 파일(301)은 특정 식별 정보 10001에 대응하는 값 2 및 특정 식별 정보 10002에 대응하는 값 3을 포함하므로, 벤더 아이템 테이블(510)의 두 번째 열에서 특정 식별 정보가 10001인 행 및 10002인 행에 대응하는 셀에 값 2 및 3을 각각 기록할 수 있다.
다음으로, 도 3b의 식별자(310)가 3인 행의 특정 식별 정보의 타입 역시 VENDOR_ITEM이다. 도 3b의 식별자(310)가 3인 행은 도 3a의 A3.txt 파일(303)에 대응된다. 도 3b의 식별자(310)가 3인 행은 생성 주체 식별자(320)가 VI_FRESH_PROMOTION 이므로, 벤더 아이템 테이블(510)의 세 번째 열의 제목은 VI_FRESH_PROMOTION 으로 설정될 수 있다. 그리고, A3.txt 파일(303)은 특정 식별 정보 10001에 대응하는 값 3000을 포함하므로, 이를 벤더 아이템 테이블(510)의 세 번째 열에서 특정 식별 정보가 10001인 행에 대응하는 셀에 3000을 기록할 수 있다.
다음으로, 도 3b의 식별자(310)가 4인 행의 특정 식별 정보의 타입은 MEMBER 이다. 도 3b의 식별자(310)가 4인 행은 도 3a의 A4.txt 파일(304)에 대응된다. 도 3b의 식별자(310)가 4인 행은 생성 주체 식별자(320)가 MEMBER_FREE_SHIPPING 이므로, 멤버 테이블(520)의 두 번째 열의 제목은 MEMBER_FREE_SHIPPING 으로 설정될 수 있다. 그리고, A4.txt 파일(304)은 특정 식별 정보 19101053에 대응하는 값 true를 포함하므로, 이를 멤버 테이블(520)의 두 번째 열에서 특정 식별 정보가 19101053인 행에 대응하는 셀에 true를 기록할 수 있다.
마지막으로, 도 3b의 식별자(310)가 2인 행의 특정 식별 정보의 타입은 CATEGORY이다. 도 3b의 식별자(310)가 2인 행은 도 3a의 A2.txt 파일(302)에 대응된다. 도 3b의 식별자(310)가 2인 행은 생성 주체 식별자(320)가 CATEGORY_IMAGE 이므로, 카테고리 테이블(530)의 두 번째 열의 제목은 CATEGORY_IMAGE 으로 설정될 수 있다. 그리고, A2.txt 파일(302)은 특정 식별 정보 10001에 대응하는 값 retail/image01.png를 포함하므로, 카테고리 테이블(530)의 두 번째 열에서 특정 식별 정보가 10001인 행에 대응하는 셀에 retail/image01.png를 기록할 수 있다.
상술한 것과 같이 임시 데이터베이스의 적어도 하나의 테이블을 특정 식별 정보의 타입에 따라 구별하는 것은, 프론트 노드, 서빙 레이어, 객체 데이터 제공 API또는 셔틀로부터의 제1 데이터 요청 또는 제2 데이터 요청이 특정 식별 정보의 타입 및 특정 식별 정보에 관한 것인 경우 임시 데이터베이스로부터 신속하게 제2 데이터를 획득할 수 있는 이점을 가진다.
도 6 은 본 개시에 따른 제2 데이터 요청 및 제2 데이터 요청에 대응하는 응답을 나타낸다. 일 실시예에서, 제2 데이터 요청은 특정 식별 정보를 포함할 수 있다. 도 6 에 나타난 제2 데이터 요청은 "vi": 10001 에 해당한다. vi는 특정 식별 정보의 타입 중 VENDOR_ITEM타입을 의미하고, 10001은 특정 식별 정보의 값에 해당한다. 즉, 도 6 의 제2 데이터 요청은 VENDOR_ITEM 타입의 특정 식별 정보가 10001인 제2 데이터를 요청하는 것을 의미한다.
제2 데이터 요청은 제1 데이터 요청 또는 제1 데이터를 기초로 생성된 것일 수 있다. 예를 들어, 제1 데이터 요청 자체가 VENDOR_ITEM 타입의 특정 식별 정보가 10001인 제2 데이터를 요청하는 것을 포함할 수도 있고, 제1 데이터 요청에 따라 획득된 제1 데이터가 VENDOR_ITEM 타입의 특정 식별 정보가 10001인 객체에 대한 정보를 포함하기 때문에, 제2 데이터 요청이 제1 데이터에 의해 생성된 것일 수 있다.
셔틀 또는 객체 데이터 제공 API는 도 6 에 나타난 제2 데이터 요청을 임시 데이터베이스에 전송할 수 있고, 도 6 에 나타난 응답을 생성할 수 있다. 도 5 에 따르면, VENDOR_ITEM 타입의 특정 식별 정보 및 그에 대응하는 데이터를 저장하는 벤더 아이템 테이블(510)에는 특정 식별 정보가 10001인 행이 존재한다. 따라서, 셔틀 도는 객체 데이터 제공 API는 벤더 아이템 테이블(510)의 특정 식별 정보가 10001인 두 번째 행의 값들인 2 및 3, 그리고 각각의 열 이름인 VI_BEST_SELLER_RANKING 및 VI_FRESH_PROMOTION을 획득할 수 있다. 셔틀 또는 객체 데이터 제공 API는 이를 이용하여 제2 데이터를 포함하는 응답을 도 6 과 같이 생성할 수 있다.
일 실시예에서, 제2 데이터는 제1 데이터 요청 또는 제2 데이터 요청에 대응하는 적어도 하나의 키-값 쌍을 포함할 수 있다. 도 6 에 나타난 것과 같이, 제2 데이터는 키-값 쌍의 형태로 기술될 수 있다. 구체적으로, 제2 데이터는 JSON 포맷으로 기술될 수 있다. 제2 데이터에 포함되는 키-값 쌍의 키는 키에 대응하는 값을 생성한 주체를 식별하는 정보일 수 있다. 즉, 제2 데이터에 포함되는 키-값 쌍의 키는 생성 주체 식별자일 수 있다.
예를 들어, 도 6 에 나타난 것과 같이 제2 데이터는 키 VI_BEST_SELLER_RANKING에 대응하는 값 2의 제1 키-값 쌍 및 키 VI_FRESH_PROMOTION에 대응하는 값 3의 제2 키-값 쌍이 될 수 있다. 제1 키-값 쌍 및 제2 키-값 쌍은 도 6과 같이 제2 데이터 응답에 포함될 수 있고, 제2 데이터 응답에는 제2 데이터가 VENDOR_ITEM 타입의 특정 식별 정보에 대응하는 것임을 의미하는 "vendorItem" 키가 포함될 수 있다. 또한, 제2 데이터 응답에는 제2 데이터가 임시 데이터임을 의미하는 "adhocProperties" 키가 포함될 수 있다.
도 7 은 본 개시에 따른 데이터 제공 방법의 일 실시예를 나타낸다. 구체적으로, 도 7 은 사용자가 업로드한 데이터 파일의 정보를 기초로 임시 데이터베이스의 적어도 하나의 테이블을 갱신하는 과정을 나타낸다. 애드혹 백엔드(710)는 전자 장치(100)에 포함되는 모듈일 수 있다. Amazon RDS(720)는 파일 정보 데이터베이스에 대응될 수 있다. Amazon S3(730)는 작업 구성 파일 데이터베이스에 대응될 수 있다. Apache Airflow(740)는 전자 장치(100)에 포함되는 모듈일 수 있다.
일 실시예에서, 단계 S701에 따라, 애드혹 백엔드(710)는 Amazon S3(730)에서 adhoc_base.yaml 파일로부터 airflow 작업 기초 구성 파일을 가져올 수 있다. adhoc_base.yaml 파일 또는 airflow 작업 기초 구성 파일은 임시 데이터베이스의 적어도 하나의 테이블을 갱신하기 위한 공통적인 설정, 명령 또는 시퀀스를 포함할 수 있다.
일 실시예에서, 단계 S702에 따라, 애드혹 백엔드(710)는 각 airflow 작업을 트리거하는 것에 대한 기초 구성의 캐시를 만들 수 있다. 즉, 애드혹 백엔드(710)는 작업 기초 구성 파일을 기초로 기초 구성 정보를 캐싱할 수 있다.
일 실시예에서, 단계 S703에 따라, 사용자는 Adhoc.id에 대한 발행 버튼을 클릭할 수 있다. 즉, 사용자는 파일 데이터베이스에 이미 업로드된 적어도 하나의 데이터 파일을 발행하여 임시 데이터베이스를 갱신하도록 명령할 수 있다.
일 실시예에서, 단계 S704에 따라, 애드혹 백엔드(710)는 사용자의 발행 버튼 클릭에 대응하여 애드혹 상태를 '활성화됨'으로 설정할 수 있다. 애드혹 상태는 임시 데이터베이스를 갱신할 때 임시 데이터베이스에 새롭게 업데이트되는 데이터 파일에 포함된 정보의 활성화 여부를 의미할 수 있다. 애드혹 상태가 활성화된 경우, 대응되는 임시 데이터베이스의 정보가 셔틀에 의해 프론트 노드로 전달될 수 있다. 애드혹 상태 정보는 Amazon RDS(720)에 기록될 수 있다.
일 실시예에서, 단계 S705에 따라, 애드혹 백엔드(710)는 활성화된 상태의 모든 애드혹 리스트를 Amazon RDS(720)로부터 쿼리할 수 있다. 애드혹 리스트는 파일 정보 데이터베이스, 즉, Amazon RDS(720)에 저장된 데이터 파일의 정보를 의미할 수 있다. 즉, 애드혹 리스트는 도 3b의 테이블에 대응되는 것일 수 있다.
일 실시예에서, 단계 S706에 따라, 애드혹 백엔드(710)는 Airflow 작업을 위한 설정을 만들 수 있다. 이 설정은 단계 S702에서 캐시된 기초 구성에 기초할 수 있다. 또한, 애드혹 백엔드(710)는 애드혹 리스트로 yaml 파일의 입력 세션을 만들 수 있다. 이를 통해 애드혹 백엔드(710)는 임시 데이터베이스의 갱신 작업에 대한 작업 구성 파일을 구성할 수 있다.
일 실시예에서, 단계 S707에 따라, 애드혹 백엔드(710)는 adhoc_{ID_TYPE}.yaml 파일을 Amazon S3(730)에 업로드할 수 있다. adhoc_{ID_TYPE}.yaml 파일은 적어도 하나의 데이터 파일에서 특정 식별 정보의 타입이 ID_TYPE인 키-값 쌍에 해당하는 정보를 기초로 임시 데이터베이스에서 특정 식별 정보의 타입이 ID_TYPE인 테이블을 갱신하기 위한 작업의 설정을 포함하는 작업 구성 파일일 수 있다. 예를 들어, 도 5의 벤더 아이템 테이블(510)은 adhoc_vendorItem.yaml 파일을 참조하여 갱신될 수 있다.
일 실시예에서, 단계 S708에 따라, Apache Airflow(740)는 작업을 위해 yaml 파일을 Amazon S3(730)로부터 가져올 수 있다. Apache Airflow(740)는 yaml 파일을 참조하여 단계 S709에 따라 파싱할 각 csv, text 파일을 Amazon S3(730)로부터 가져올 수 있다. csv, text 파일은 적어도 하나의 데이터 파일에 대응될 수 있다.
일 실시예에서, 단계 S710에 따라, Apache Airflow(740)는 카산드라의 신규 테이블을 생성할 수 있다. 카산드라는 임시 데이터베이스에 대응되는 것일 수 있다. 이 과정에서, 카산드라의 기존 테이블은 드랍할 수 있다. 즉, Apache Airflow(740)는 카산드라 또는 임시 데이터베이스에 저장된 테이블에 대응되는 테이블을 새로 생성하고, 임시 데이터베이스에 저장된 테이블을 새로 생성된 테이블로 교체 또는 치환할 수 있다. 이러한 방법은 카산드라 또는 임시 데이터베이스의 테이블에 적어도 하나의 파일의 정보를 모두 덮어쓰기하는 것보다 더 빠르게 임시 데이터베이스를 갱신할 수 있는 이점이 있다. 즉, 일 실시예에서 적어도 하나의 테이블 각각은 적어도 하나의 테이블 각각에 대응하는 작업 구성 파일을 기초로 구성되는 테이블로 교체됨으로써 갱신될 수 있다.
도 8 은 본 개시에 따른 방법의 일 실시예를 나타낸다. 구체적으로, 도 8 은 새로운 데이터를 프론트 노드로 전달하기 위한 방법을 나타낸다. Apache Airflow(810)는 조인-라이터(Join-Writer, 811)를 포함할 수 있다. 일 실시예에서, 조인-라이터(811)는 테이블을 서로 조인(join)하는 작업을 하는 모듈일 수 있다. 조인-라이터(811)는 조인 테이블을 생성하고, 새로운 데이터를 조인 테이블에 쓴 다음, CDS(Cassandra Data Server, 812)를 갱신할 수 있다. CDS(812)는 메인 데이터베이스에 대응하는 것일 수 있다. 셔틀(813)은 CDS(812)로부터 새로운 데이터를 획득할 수 있고, 객체 데이터 제공 api(814)는 각 id를 기초로 데이터를 가져올 수 있다. 여기서 id는 특정 식별 정보일 수 있다. 객체 데이터 제공 api(814)는 새로운 데이터를 서빙 레이어(815)로 전달하여, 새로운 데이터가 프론트 노드로 전달되도록 할 수 있다.
다른 실시예에서, Apache Airflow(820)는 조인-라이터(821) 및 애드혹 라이터(822)를 포함할 수 있다. 애드혹 라이터(822)는 새로운 데이터를 임시 데이터베이스에 저장하는 작업을 하는 모듈일 수 있다. 조인-라이터(823)는 조인 테이블을 생성하고, 새로운 데이터를 조인 테이블에 쓴 다음, CDS(823)를 갱신할 수 있다. CDS(823)는 메인 데이터베이스에 대응하는 것일 수 있다. 셔틀(824)은 CDS(823)로부터 새로운 데이터를 획득할 수 있고, 객체 데이터 제공 api(827)는 각 id를 기초로 데이터를 가져올 수 있다. 여기서 id는 특정 식별 정보일 수 있다. 객체 데이터 제공 api(827)는 새로운 데이터를 서빙 레이어(828)로 전달하여, 새로운 데이터가 프론트 노드로 전달되도록 할 수 있다.
또는, 조인-라이터(823) 및 애드혹 라이터(822)는 새로운 데이터를 포함하는 조인 데이터 및 애드혹 데이터를 같은 테이블에 쓴 다음, CDS(825)를 갱신할 수 있다. CDS(825)는 메인 데이터베이스 또는 임시 데이터베이스에 대응하는 것일 수 있다. 셔틀(826)은 CDS(825)로부터 새로운 데이터를 획득할 수 있고, 객체 데이터 제공 api(827)는 각 id를 기초로 데이터를 가져올 수 있다. 여기서 id는 특정 식별 정보일 수 있다. 객체 데이터 제공 api(827)는 새로운 데이터를 서빙 레이어(828)로 전달하여, 새로운 데이터가 프론트 노드로 전달되도록 할 수 있다.
도 9 는 본 개시에 따른 방법의 일 실시예를 나타낸다. 도 9 에 나타난 각 구성요소는 도 1 내지 도 8에서 설명된 동일한 명칭의 구성요소에 각각 대응되는 것일 수 있다. 사용자(901)는 적어도 하나의 데이터 파일을 애드혹 서비스(903)의 애드혹 UI를 통해 업로드할 수 있다. 적어도 하나의 데이터 파일은 파일 데이터베이스 또는 S3(905)에 업로드될 수 있다. 업로드된 적어도 하나의 데이터 파일에 대한 정보는 파일 정보 데이터베이스 또는 RDS(904)에 업로드될 수 있다.
사용자(901)는 활성 테스트 리스트를 트리거하여, 데이터 추출기(906)의 작업을 트리거할 수 있다. 활성 테스트 리스트는 파일 정보 데이터베이스 또는 S3(905)에서 애드혹 상태가 활성화된 파일의 리스트를 의미하는 것일 수 있다. 데이터 추출기(906)는 제공하는 테이블 및 열(column)의 이름을 동적 설정 데이터베이스(907)에 업로드할 수 있다. 제공하는 테이블 및 열은 임시 데이터베이스 또는 CDS(909)에서 갱신된(갱신될) 테이블 및 갱신된(갱신될) 열을 의미할 수 있다. 동적 설정 데이터베이스(907)은 갱신된 테이블 및 열의 이름을 셔틀(908)에 알릴 수 있다.
서빙 레이어(912)는 리스팅 API(913), 검색 API(914), 프로모션 API(915)를 포함할 수 있다. 서빙 레이어(913)는 제1 데이터 요청을 객체 데이터 제공 API(911)로 전송할 수 있다. 객체 데이터 제공 API(911)는 제1 데이터 요청을 기초로 메인 데이터베이스에서 제1 데이터를 획득할 수 있다. 객체 데이터 제공 API(911)는 제1 데이터 요청 또는 제1 데이터를 기초로 제2 데이터 요청을 생성할 수 있다. 객체 데이터 제공 API(911)는 제2 데이터 요청을 셔틀(908)에 전송할 수 있다. 셔틀(908)은 제2 데이터 요청에 대응하여 임시 데이터베이스(919) 또는 캐시(910)로부터 제2 데이터를 객체 데이터 제공 API(911)로 제공할 수 있고, 객체 데이터 제공 API(911)는 제1 데이터 및 제2 데이터를 서빙 레이어(912)로 전달하여 제1 데이터 및 제2 데이터가 프론트 노드로 전달되도록 할 수 있다.
도 10 은 본 개시에 따른 방법의 일 실시예를 나타낸다. 도 10 에 나타난 각 구성요소는 도 1 내지 도 9에서 설명된 동일한 명칭의 구성요소에 각각 대응되는 것일 수 있다.
일 실시예에서, 단계 S1001에 따라, 사용자는 애드혹 UI(1010)를 통해 새로운 데이터 파일을 생성하거나, 기존의 데이터 파일을 갱신할 수 있다. 단계 S1002에 따라, 애드혹 UI(1010)는 애드혹 서버(1020)의 /api/file/upload를 호출할 수 있다. /api/file/upload 는 데이터 파일의 업로드를 수행하는 명령어를 의미할 수 있다. 애드혹 서버(1020)는 전자 장치(100)에 포함되는 모듈일 수 있다.
단계 S1003에 따라, 파일 데이터베이스 또는 S3(1030)는 특정 식별 정보의 타입 및 제목을 먼저 파일 정보 데이터베이스(1040)에 저장할 수 있다. 여기서 제목은 파일을 생성한 주체의 식별자, 즉, 도 3b의 생성 주체 식별자(320)에 대응하는 것일 수 있다.
단계 S1004에 따라, 파일 정보 데이터베이스(1040)는 저장 결과 및 식별자를 리턴할 수 있다. 여기서 식별자는 도 3b의 식별자(310)에 대응하는 것일 수 있다.
단계 S1005에 따라, 애드혹 서버(1020)는 파일 데이터베이스 또는 S3(1030)에 적어도 하나의 파일을 업로드할 수 있다. 파일 데이터베이스 또는 S3(1030)는 단계 S1006에 따라, 업로드 결과를 애드혹 서버(1020)로 리턴할 수 있다.
애드혹 서버(1020)는 단계 S1007에 따라 이전 id와 함께 s3 경로를 파일 정보 데이터베이스(1040)에 저장할 수 있다. 이전 id는 도 3b의 식별자(310)에 대응하는 것일 수 있고, 파일이 업로드되거나 갱신되기 이전의 식별자(310)를 의미할 수 있다.
단계 S1008에 따라, 파일 정보 데이터베이스(1040)는 업로드 성공을 애드혹 서버(1020)로 알리고, 애드혹 서버(1020)는 단계 S1009에 따라 애드혹 UI(1010)에 업로드 성공 UI(S1010)를 표시하도록 할 수 있다.
도 11 은 본 개시에 따른 애드혹 UI(1110)의 일 실시예를 나타낸다. 애드혹 UI(1110)는 파일 정보 데이터베이스에 기초하여 애드혹 서비스(임시 서비스)의 리스트(1114)를 표시할 수 있다. 애드혹 서비스 또는 임시 서비스는 파일 정보 데이터베이스에 업로드된 적어도 하나의 데이터 파일 각각에 대응되는 것일 수 있다.
애드혹 UI(1110)는 검색 창(1111) 및 검색 버튼(1112)을 포함하여, 사용자는 리스트(1114)의 열 이름을 기초로 정보를 검색할 수 있다.
애드혹 UI(1110)는 신규 버튼(1113)을 포함할 수 있고, 사용자는 신규 버튼(1113)을 클릭하여, 데이터베이스(1120)에 적어도 하나의 파일을 업로드할 수 있다.
애드혹 UI(1110)는 갱신 버튼(1115)을 포함할 수 있고, 사용자는 갱신 버튼(1115)을 클릭하여 데이터베이스(1120)에 업로드된 적어도 하나의 파일을 갱신할 수 있다.
애드혹 UI(1110)는 다운로드 버튼(1116)을 포함할 수 있고, 사용자는 다운로드 버튼(1116)을 클릭하여 데이터베이스(1120)에 업로드된 적어도 하나의 파일을 다운로드할 수 있다.
애드혹 UI(1110)는 삭제 버튼(1117)을 포함할 수 있고, 사용자는 삭제 버튼(1117)을 클릭하여 데이터베이스(1120)에 업로드된 적어도 하나의 파일을 삭제할 수 있다. 이 때, 애드혹 UI(1110)는 확인 창(1130)을 포함하여, 삭제 여부를 사용자에게 다시 한번 확인할 수 있다.
도 12 는 본 개시에 따른 애드혹 UI(1200)의 일 실시예를 나타낸다. 구체적으로, 애드혹 UI(1200)는 애드혹 서비스, 즉 임시 서비스를 신규 생성 또는 편집하기 위한 인터페이스를 나타낸다. 애드혹 UI(1200)는 비즈니스 ID 입력 필드를 포함할 수 있다. 비즈니스 ID는 도 3b의 생성 주체 식별자(320)에 대응되는 것일 수 있다. 즉, 설정된 비즈니스 ID를 기초로 임시 데이터 또는 제2 데이터의 사용처가 결정될 수 있다. 제2 데이터가 적절하게 제공되기 위하여, 비즈니스 ID 또는 생성 주체 식별자는 프론트 노드와 약속된 값일 수 있다.
애드혹 UI(1200)는 특정 식별 정보의 타입을 설정할 수 있는 버튼을 포함할 수 있다.
애드혹 UI(1200)는 관련 링크를 삽입할 수 있는 필드를 포함할 수 있고, 애드혹 서비스의 설명을 기록할 수 있는 필드를 포함할 수 있다.
애드혹 UI(1200)는 적어도 하나의 데이터 파일을 입력할 수 있는 필드를 포함할 수 있다. 이를 통해 적어도 하나의 데이터 파일이 파일 데이터베이스에 업로드될 수 있다.
도 13 은 본 개시에 따른 애드혹 UI(1300)의 일 실시예를 나타낸다. 구체적으로, 애드혹 UI(1300)는 애드혹 서비스, 즉 임시 데이터를 편집하기 위한 인터페이스를 나타낸다.
애드혹 UI(1300)는 상태 활성 UI를 포함할 수 있다. 상태 활성 UI는 임시 데이터가 활성화 상태인지 여부를 표시할 수 있다.
애드혹 UI(1300)는 특정 식별 정보의 타입을 설정할 수 있는 버튼을 포함할 수 있다.
애드혹 UI(1300)는 관련 링크를 삽입할 수 있는 필드를 포함할 수 있고, 애드혹 서비스의 설명을 기록할 수 있는 필드를 포함할 수 있다.
애드혹 UI(1300)는 적어도 하나의 데이터 파일을 입력할 수 있는 필드를 포함할 수 있다. 이를 통해 적어도 하나의 데이터 파일이 파일 데이터베이스에 업로드될 수 있다.
도 14 는 본 개시에 따른 방법의 일 실시예를 나타낸다. 도 14 에 나타난 각 구성요소는 도 1 내지 도 13에서 설명된 동일한 명칭의 구성요소에 각각 대응되는 것일 수 있다.
일 실시예에서, Spark airflow(1410)는 데이터 추출기(1420)를 트리거할 수 있다. 데이터 추출기(1420)는 조인 라이터(1421)를 포함할 수 있다. 데이터 추출기(1420)는 Spark airflow의 트리거에 대응하여, 임시 데이터베이스 또는 CDS(1430)의 테이블을 갱신할 수 있다.
CDS(1430)는 테이블의 갱신된 정보를 캐시(cache, 1440)에 캐싱(caching)할 수 있다. 셔틀(1450)은 캐시(1440)로부터 제2 데이터를 획득할 수 있다. 제2 데이터는 테이블의 갱신된 정보를 포함할 수 있다.
즉, 일 실시예에서 전자 장치(100)는, 캐시(cache)로부터 제2 데이터를 획득할 수 있고, 캐시는 임시 데이터베이스를 기초로 갱신될 수 있다.
제2 데이터는 메이트-api(1460)에 전달될 수 있다. 메이트-api(1460)는 객체 데이터 제공 API에 대응되는 것일 수 있다.
도 15 는 본 개시에 따른 방법의 일 실시예를 나타낸다. 도 15 에 나타난 각 구성요소는 도 1 내지 도 14에서 설명된 동일한 명칭의 구성요소에 각각 대응되는 것일 수 있다.
일 실시예에서, 사용자(1500)는 목(mock) 생성 인터페이스(1502)의 목 생성 UI(1503)를 통해 데이터 파일을 CUD(Create, Update, Delete)할 수 있다. 목 생성 인터페이스(1502)는 도 2 의 애드혹 서비스(203)에 대응되고, 목 생성 UI(1503)는 도 2 의 애드혹 UI(204)에 대응되는 것일 수 있다. 또한 목(mock)은 애드혹 서비스 또는 적어도 하나의 데이터 파일에 대응되는 것일 수 있다.
목 생성 UI(1503)는 벌크 카프카(kafka)(1507)를 통해 목을 생성(1505) 및 업데이트(1506)할 수 있다. 목의 생성 또는 업데이트 결과는 개별 카프카(1508)를 통해 목 생성 UI(1503)로 전달될 수 있다. 벌크 카프카(1507) 및 개별 카프카(1508)는 Apache kafka 등의 데이터 또는 메시지 스트리밍 솔루션을 의미할 수 있다.
목 생성 UI(1503)는 셔틀(1511)을 트리거하여 CDS(1512)를 갱신할 수 있다. 이 때, 업데이터(1510)가 생성 또는 업데이트된 목을 기초로 CDS(1512)의 테이블(1533, 1534) 및 RDS(1504)의 테이블(1531, 1532)을 갱신할 수 있다. RDS(1504)의 테이블을 트랜잭션 카프카(1509)를 통해 갱신될 수 있다. 트랜잭션 카프카(1509) 역시 Apache kafka 등의 데이터 또는 메시지 스트리밍 솔루션을 의미할 수 있다.
CDS(1512)의 테이블(1533, 1534) 및 RDS(1504)의 테이블(1531, 1532)에서 SIGNAL은 도 3b의 생성 주체 식별자(320)에 대응될 수 있고, LEVEL은 도 3b의 특정 식별 정보의 타입, 즉, 식별자 타입(330)에 대응될 수 있다. ID 및 String은 도 3a 에 나타난 키 및 값을 의미할 수 있다. 예를 들어, 도 3a의 B1.txt(305)의 키인 10001이 ID에, 값인 {"bsr_rank": "1", "bsr_limit": false}가 String에 대응될 수 있다. String은 JSON 포맷의 문자열을 의미할 수 있다.
셔틀(1511)은 객체 데이터 제공 API(1514)의 요청(1535)에 따라, 캐시(1513) 또는 CDS(1512)로부터 제2 데이터를 획득하고, 객체 데이터 제공 API(1514)로 전달할 수 있다. 객체 데이터 제공 API(1514)는 제2 데이터를 응답(1536)에 포함시켜서 서빙 레이어(1516)로 전달할 수 있다. 제2 데이터는 제1 데이터와 함께 응답(1536)에 포함될 수 있다. 이 때, 모킹 핸들러(1515)가 개입하여 신호가 MOCK 타입인 경우 응답을 대체할 수 있다. MOCK 타입의 신호는 본 개시에 따른 방법의 작동을 시험(test)하는데 사용되는 특정 식별 정보의 타입일 수 있다. 각각의 모킹 핸들러(1520)는 서빙 레이어(1516)의 리스팅 API(1517), 검색 API(1518) 및 프로모선 API(1519)에 개입하여 MOCK 타입의 신호에 대한 응답을 처리할 수 있다.
도 16 은 본 개시에 따른 방법의 일 실시예를 나타낸다. 도 16 에 나타난 각 구성요소는 도 1 내지 도 15에서 설명된 동일한 명칭의 구성요소에 각각 대응되는 것일 수 있다.
일 실시예에서, 사용자(1600)는 목(mock) 생성 인터페이스(1602)의 목 생성 UI(1603)를 통해 데이터 파일을 CUD(Create, Update, Delete)할 수 있다. 목 생성 인터페이스(1602)는 도 2 의 애드혹 서비스(203)에 대응되고, 목 생성 UI(1603)는 도 2 의 애드혹 UI(204)에 대응되는 것일 수 있다. 또한 목(mock)은 애드혹 서비스 또는 적어도 하나의 데이터 파일에 대응되는 것일 수 있다.
목 생성 UI(1603)는 목 카프카(1606)에 목을 발행(1605)할 수 있다. 이 때, 클린업 스케줄러(1604)는 일정한 주기(예를 들어, 매일)로 목 생성 UI(1603)을 트리거하여 목을 발행(1605)하도록 할 수 있다. 즉, 임시 데이터베이스 또는 CDS(1612)는 기 설정된 주기로 갱신될 수 있다.
셔틀(1611)은 목 카프카(1606)를 통해 목을 구독(1607)하여 CDS(1612)의 테이블(1631)을 갱신할 수 있다. 목 생성 인터페이스(1602)는 상태 카프카(1610)를 통해 상태를 구독(1609)하여 RDS(1610)의 테이블(1630)을 갱신할 수 있다.
테이블(1630, 1631)의 BUSINESS_SIGNAL은 도 3b에 나타난 생성 주체 식별자(320)에, ID_TYPE은 도 3b의 특정 식별 정보의 타입, 즉, 식별자 타입(330)에 대응될 수 있다. ID 및 BUSINESS_CONTENTS는 도 3a 에 나타난 키 및 값을 의미할 수 있다. 예를 들어, 도 3a의 B1.txt(305)의 키인 10001이 ID에, 값인 {"bsr_rank": "1", "bsr_limit": false}가 BUSINESS_CONTENTS에 대응될 수 있다. BUSINESS_CONTENTS은 JSON 포맷의 문자열을 포함할 수 있다.
STATUS는 목 또는 적어도 하나의 데이터 파일을 기초로 임시 데이터베이스 또는 CDS(1612)가 갱신되는 상태를 나타낼 수 있다. 예를 들어, STATUS가 CONFIRMED 라면 임시 데이터베이스 또는 CDS(1612)가 이미 갱신 완료된 상태를, STATUS가 WAITING이라면 임시 데이터베이스 또는 CDS(1612)가 갱신 대기 중인 상태를, STATUS가 FAILED라면 임시 데이터베이스 또는 CDS(1612)의 갱신이 실패한 상태일 수 있다. 이러한 갱신과 관련된 상태는 같이 상태 구독(1609)을 통해 RDS(1610)의 테이블(1630)에 반영될 수 있고, 이는 사용자(1600)에게 알려질 수 있다. 즉, 일 실시예에서, 전자 장치(100)는 임시 데이터베이스의 갱신 작업의 요청을 확인한 경우, 갱신 작업의 시작을 확인한 경우 및 갱신 작업의 완료를 확인한 경우 각각에 대해 알림(예를 들어 클린업 알림)을 제공할 수 있다.
셔틀(1611)은 객체 데이터 제공 API(1614)의 요청(1632)에 따라, 캐시(1613) 또는 CDS(1612)로부터 제2 데이터를 획득하고, 객체 데이터 제공 API(1614)로 전달할 수 있다. 객체 데이터 제공 API(1614)는 제2 데이터를 응답(1633)에 포함시켜서 서빙 레이어(1616)로 전달할 수 있다. 제2 데이터는 제1 데이터와 함께 응답(1632)에 포함될 수 있다. 이 때, 모킹 핸들러(1615)가 개입하여 신호가 MOCK 타입인 경우 응답을 대체할 수 있다. MOCK 타입의 신호는 본 개시에 따른 방법의 작동을 시험(test)하는데 사용되는 특정 식별 정보의 타입일 수 있다. 각각의 모킹 핸들러(1620)는 서빙 레이어(1616)의 리스팅 API(1617), 검색 API(1618) 및 프로모선 API(1619)에 개입하여 MOCK 타입의 신호에 대한 응답을 처리할 수 있다.
도 17 은 본 개시에 따른 방법의 일 실시예를 나타낸다. 도 17 에 나타난 각 구성요소는 도 1 내지 도 16에서 설명된 동일한 명칭의 구성요소에 각각 대응되는 것일 수 있다.
일 실시예에서, 사용자(1700)는 애드혹 서비스(1702)의 애드혹 UI(1703)을 통해 적어도 하나의 데이터 파일을 파일 데이터베이스 또는 S3(1706)에 업로드할 수 있다. 이 때, 애드혹 UI(1703)을 통해 파일 정보 데이터베이스(1705)에 저장된 파일 정보(1730)가 갱신될 수 있다.
애드혹 UI(1703)은 API를 호출하여 데이터 추출기(1707)를 트리거할 수 있다. 데이터 추출기(1707)는 파일 데이터베이스 또는 S3(1706)로부터 적어도 하나의 데이터 파일을 참조하여 임시 데이터베이스 또는 CDS(1710)의 테이블(1731)을 갱신할 수 있다. 클린업 스케줄러(1704)는 일정한 주기(예를 들어, 매일)로 애드혹 UI(1703)을 트리거하여 데이터 추출기(1707)를 호출하도록 할 수 있다. 즉, 임시 데이터베이스 또는 CDS(1710)는 기 설정된 주기로 갱신될 수 있다.
일 실시예에서, 파일 데이터베이스 또는 S3(1706)의 파일이 추가, 삭제 또는 갱신된 경우 임시 데이터베이스 또는 CDS(1710)가 업데이트될 수 있다. 애드혹 UI(1703)는 파일 데이터베이스 또는 S3(1706)의 파일이 추가, 삭제 또는 갱신되었을 때, API를 호출하여 데이터 추출기(1707)를 트리거할 수 있다. 데이터 추출기(1707)는 파일 데이터베이스 또는 S3(1706)로부터 추가, 삭제 또는 갱신된 적어도 하나의 데이터 파일을 확인하고 추가, 삭제 또는 갱신된 적어도 하나의 데이터 파일에 대응되는 임시 데이터베이스 또는 CDS(1710)의 테이블(1731)을 갱신(테이블(1731)의 행 또는 열을 추가, 삭제 또는 갱신)할 수 있다. 이 때, 임시 데이터베이스 또는 CDS(1710)의 테이블(1731)의 갱신이 누락되는 것을 방지하기 위해, 클린업 스케줄러(1704), 애드혹 서비스(1702) 또는 애드혹 UI(1703)는 일정한 주기(바람직하게는, 매일 새벽 시간)로 임시 데이터베이스 또는 CDS(1710)의 테이블(1731)의 갱신이 누락되었는지 확인하고, 데이터 추출기(1707)를 호출하여 임시 데이터베이스 또는 CDS(1710)의 테이블(1731)이 갱신되도록 할 수 있다.
일 실시예에서, 파일 데이터베이스 또는 S3(1706)의 파일이 추가, 삭제 또는 갱신된 경우 임시 데이터베이스 또는 CDS(1710)가 업데이트될 수 있다. 애드혹 UI(1703)는 기 설정된 주기(예를 들어, 수 분 내지 수십 분에 한 번, 바람직하게는 10분에 한 번)로 파일 데이터베이스 또는 S3(1706)의 파일이 추가, 삭제 또는 갱신되었는지 확인하고, API를 호출하여 데이터 추출기(1707)를 트리거할 수 있다. 데이터 추출기(1707)는 파일 데이터베이스 또는 S3(1706)로부터 추가, 삭제 또는 갱신된 적어도 하나의 데이터 파일을 확인하고 추가, 삭제 또는 갱신된 적어도 하나의 데이터 파일에 대응되는 임시 데이터베이스 또는 CDS(1710)의 테이블(1731)을 갱신(테이블(1731)의 행 또는 열을 추가, 삭제 또는 갱신)할 수 있다. 이 때, 임시 데이터베이스 또는 CDS(1710)의 테이블(1731)의 갱신이 누락되는 것을 방지하기 위해, 클린업 스케줄러(1704), 애드혹 서비스(1702) 또는 애드혹 UI(1703)는 일정한 주기(바람직하게는, 매일 새벽 시간)로 임시 데이터베이스 또는 CDS(1710)의 테이블(1731)의 갱신이 누락되었는지 확인하고, 데이터 추출기(1707)를 호출하여 임시 데이터베이스 또는 CDS(1710)의 테이블(1731)이 갱신되도록 할 수 있다.
데이터 추출기(170)는 캐시 업데이터(1708)를 통해 캐시(1711)를 함께 갱신할 수 있다. 캐시(1711)의 업데이트는 사용자(1700)에 의해 이루어질 수 있다. 사용자(1700)는 애드혹 UI(1703)를 통해 특정 식별 정보를 입력할 수 있고, 데이터 추출기(1707)는 사용자의 입력에 대응하여 캐시 업데이터(1708)를 통해 특정 식별 정보에 대응하는 데이터 (예를 들어, 적어도 하나의 데이터 파일의 키-값)을 캐시(1711)에 저장할 수 있다. 이후 특정 식별 정보에 대응하는 제2 데이터가 캐시(1711)로부터 객체 데이터 제공 API(1712)로 제공될 수 있다. 데이터가 캐시(1711)로부터 객체 데이터 제공 API(1712) 로 제공된 다음, 특정 식별 정보에 대응하는 데이터는 캐시에서 삭제될 수 있다. 즉, 일 실시예에서, 하나 이상의 특정 식별 정보가 확인되면 특정 식별 정보에 대응하는 데이터가 캐시에서 삭제될 수 있다. 이는 클린업 스케줄러(1704)의 트리거 없이도 필요에 따라 특정 식별 정보에 대응하는 임시 데이터가 프론트 노드로 빨리 전달될 수 있는 이점을 가진다.
파일 정보(1730)는 도 3b에 나타난 표에 대응될 수 있다. 테이블(1731)은 도 5에 나타난 테이블(510, 520, 530) 중 어느 하나에 대응될 수 있다.
파일 정보(1730)의 title 및 테이블(1731)의 BUSINESS_SIGNAL은 도 3b에 나타난 생성 주체 식별자(320)에, ID_TYPE은 도 3b의 특정 식별 정보의 타입, 즉, 식별자 타입(330)에 대응될 수 있다. ID 및 BUSINESS_CONTENTS는 도 3a 에 나타난 키 및 값을 의미할 수 있다. 예를 들어, 도 3a의 B1.txt(305)의 키인 10001이 ID에, 값인 {"bsr_rank": "1", "bsr_limit": false}가 BUSINESS_CONTENTS에 대응될 수 있다. BUSINESS_CONTENTS은 JSON 포맷의 문자열을 포함할 수 있다.
셔틀(1709)은 객체 데이터 제공 API(1712)의 요청(1732)에 따라, 캐시(1711) 또는 CDS(1710)로부터 제2 데이터를 획득하고, 객체 데이터 제공 API(1712)로 전달할 수 있다. 객체 데이터 제공 API(1712)는 제2 데이터를 응답(1733)에 포함시켜서 서빙 레이어(1714)로 전달할 수 있다. 제2 데이터는 제1 데이터와 함께 응답(1733)에 포함될 수 있다. 이 때, 모킹 핸들러(1713)가 개입하여 신호가 MOCK 타입인 경우 응답을 대체할 수 있다. MOCK 타입의 신호는 본 개시에 따른 방법의 작동을 시험(test)하는데 사용되는 특정 식별 정보의 타입일 수 있다. 각각의 모킹 핸들러(1718)는 서빙 레이어(1714)의 리스팅 API(1715), 검색 API(1716) 및 프로모선 API(1717)에 개입하여 MOCK 타입의 신호에 대한 응답을 처리할 수 있다.
도 18 은 일 실시예에 따른 전자 장치(100)의 동작 방법을 나타낸다. 도 18 의 동작 방법의 각 단계에 대해 도 1 내지 도 17 에서 설명한 프로세서(110)의 동작과 중복되는 내용에 대해서는 설명을 생략한다.
단계 S1810에서, 전자 장치(100)는, 프론트 노드에서 제1 데이터 요청을 수신할 수 있다. 제1 데이터 요청은 특정한 객체에 관한 데이터의 요청을 포함할 수 있다. 서빙 레이어는 제1 데이터 요청을 수신하여, 아이템 데이터 제공 API로 넘겨줄 수 있다.
단계 S1820에서, 전자 장치(100)는, 제1 데이터 요청을 기반으로 메인 데이터베이스에서 제1 데이터를 획득할 수 있다. 구체적으로, 아이템 데이터 제공 API는 제1 데이터 요청을 기초로 메인 데이터베이스에서 제1 데이터를 획득할 수 있다.
단계 S1830에서, 전자 장치(100)는, 제1 데이터 요청을 기반으로 임시 데이터베이스에서 제2 데이터를 획득할 수 있다. 구체적으로, 아이템 데이터 제공 API는 메인 데이터베이스에서 획득한 제1 데이터를 기초로 셔틀로 제2 데이터 요청을 송신할 수 있다. 제2 데이터 요청은 특정한 객체에 관한 특정 식별 정보를 포함할 수 있다. 셔틀은 제2 데이터 요청의 특정 식별 정보를 기초로 임시 데이터베이스에서 특정 식별 정보의 타입에 따른 테이블로부터 특정 식별 정보에 해당하는 행의 값 및 열 정보(생성 주체 식별자)를 획득하고, 이를 기초로 제2 데이터를 획득할 수 있다. 제2 데이터는 json 포맷의 데이터일 수 있다.
단계 S1840에서, 전자 장치(100)는, 제1 데이터 및 제2 데이터를 프론트 노드로 전송할 수 있다. 프론트 노드는 제1 데이터 및 제2 데이터를 파싱하여 제1 데이터 및 제2 데이터를 구분한 다음, 제1 데이터 및 제2 데이터를 기초로 서비스 이용자에게 제공할 페이지를 생성할 수 있다.
예를 들어, 본 개시에 따른 발명의 사용자는 특정 카테고리, 예를 들어 패션 카테고리에 대응하는 아이템에 대해 추가 정보를 표시해야 할 수 있다. 이 때, 메인 데이터베이스의 수정이 어려울 수 있으므로, 사용자는 본 개시에 따른 전자 장치(100)의 애드혹 UI를 이용할 수 있다. 사용자는 애드혹 UI를 통해 프론트 노드로 제공할 추가 정보를 파일 형태로 업로드할 수 있다. 이 때, 파일은 텍스트 파일일 수 있다. 즉, 사용자는 패션 카테고리의 식별자(본 개시에서 특정 식별 정보에 대응됨)와 이에 대응되는 정보를 파일 형태로 업로드할 수 있다.
전자 장치(100)는 업로드된 파일을 기초로 임시 데이터베이스에서 패션 카테고리에 대응되는 테이블 및 행을 추가 또는 수정할 수 있다. 이후 전자 장치(100)는 프론트 노드로부터 제1 데이터 요청을 수신하고, 제1 데이터로부터 패션 카테고리의 식별자를 확인하였다면 임시 데이터베이스로부터 패션 카테고리에 대응되는 추가 정보를 포함하는 제2 데이터를 제1 데이터와 함께 프론트 노드로 전달할 수 있다.
프론트 노드 측에서는 제2 데이터를 페이지에 표시할 수 있다. 즉, 패션 카테고리에 관한 추가 정보를 패션 카테고리가 표시된 페이지에 추가 또는 수정할 수 있다. 이렇게 수정된 페이지는 서비스 이용자에게 제공될 수 있다.
도 19 는 일 실시예에 따른 전자 장치(100)의 동작 방법을 나타낸다. 도 19 의 동작 방법의 각 단계에 대해 도 1 내지 도 17 에서 설명한 프로세서(110)의 동작과 중복되는 내용에 대해서는 설명을 생략한다.
단계 S1910에서, 전자 장치(100)는, 프론트 노드에서 제1 데이터 요청을 수신할 수 있다.
단계 S1920에서, 전자 장치(100)는, 제1 데이터 요청을 기반으로 메인 데이터베이스에서 제1 데이터를 획득할 수 있다.
단계 S1931에서, 전자 장치(100)는, 제1 데이터를 기반으로 확인되는 특정 식별 정보를 포함하는 제2 데이터 요청을 임시 데이터베이스에 전송할 수 있다.
단계 S1932에서, 전자 장치(100)는, 제2 데이터 요청에 따라 임시 데이터베이스로부터 제2 데이터를 획득할 수 있다.
단계 S1940에서, 전자 장치(100)는, 제1 데이터 및 제2 데이터를 프론트 노드로 전송할 수 있다.
이상 설명된 본 개시에 따른 실시예들은 다양한 컴퓨터 구성요소를 통하여 수행될 수 있는 프로그램 명령어의 형태로 구현되어 컴퓨터 판독 가능한 기록 매체 또는 비일시적 기록 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능한 기록 매체 또는 비일시적 기록 매체는 프로그램 명령어, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 컴퓨터 판독 가능한 기록 매체 또는 비일시적 기록 매체에 기록되는 프로그램 명령어는 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 분야의 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능한 기록 매체 또는 비일시적 기록 매체의 예에는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM, DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 ROM, RAM, 플래시 메모리 등과 같은 프로그램 명령어를 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령어의 예에는, 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함된다. 상기 하드웨어 장치 또는 전자 장치는 본 개시에 따른 처리를 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
본 실시 예는 기능적인 블록 구성들 및 다양한 처리 단계들로 나타내어질 수 있다. 이러한 기능 블록들은 특정 기능들을 실행하는 다양한 개수의 하드웨어, 소프트웨어, 또는 이들의 조합들로 구현될 수 있다. 예를 들어, 실시 예는 하나 이상의 마이크로프로세서들의 제어 또는 다른 제어 장치들에 의해서 다양한 기능들을 실행할 수 있는, 메모리, 프로세싱, 로직(logic), 룩 업 테이블(look-up table) 등과 같은 직접 회로 구성들을 채용할 수 있다. 구성 요소들이 소프트웨어 프로그래밍 또는 소프트웨어 요소들로 실행될 수 있는 것과 유사하게, 본 실시 예는 데이터 구조, 프로세스들, 루틴들 또는 다른 프로그래밍 구성들의 조합으로 구현되는 다양한 알고리즘을 포함하여, C, C++, 자바(Java), 어셈블러(assembler) 등과 같은 프로그래밍 또는 스크립팅 언어로 구현될 수 있다. 기능적인 측면들은 하나 이상의 프로세서들에서 실행되는 알고리즘으로 구현될 수 있다. 또한, 본 실시 예는 전자적인 환경 설정, 신호 처리, 데이터 처리 또는 이들의 조합 등을 위하여 종래 기술을 채용할 수 있다.

Claims (21)

  1. 전자 장치의 데이터 제공 방법에 있어서,
    프론트 노드에서 제1 데이터 요청을 수신하는 단계;
    상기 제1 데이터 요청을 기반으로 메인 데이터베이스에서 제1 데이터를 획득하는 단계;
    상기 제1 데이터 요청을 기반으로 임시 데이터베이스에서 제2 데이터를 획득하는 단계; 및
    상기 제1 데이터 및 상기 제2 데이터를 상기 프론트 노드로 전송하는 단계를 포함하는, 데이터 제공 방법.
  2. 제1항에 있어서,
    상기 제2 데이터를 획득하는 단계는
    특정 식별 정보를 포함하는 제2 데이터 요청을 상기 임시 데이터 베이스에 전송하는 단계; 및
    상기 제2 데이터 요청에 따라 상기 임시 데이터베이스로부터 상기 제2 데이터를 획득하는 단계를 포함하는, 데이터 제공 방법.
  3. 제2항에 있어서,
    상기 특정 식별 정보는 상기 제1 데이터를 기반으로 확인되는, 데이터 제공 방법.
  4. 제2항에 있어서,
    상기 제2 데이터는 상기 임시 데이터베이스에서 상기 특정 식별 정보에 따라 동적 설정 데이터베이스로부터 획득된 설정 정보를 기반으로 확인된 테이블로부터 획득되는, 데이터 제공 방법.
  5. 제1항에 있어서,
    상기 제2 데이터는 상기 제1 데이터 요청에 대응하는 적어도 하나의 키-값 쌍을 포함하는, 데이터 제공 방법.
  6. 제5항에 있어서,
    상기 키-값 쌍의 키는 상기 키에 대응하는 값을 생성한 주체를 식별하는 정보인, 데이터 제공 방법.
  7. 제6항에 있어서,
    상기 임시 데이터베이스는 적어도 하나의 데이터 파일을 기초로 갱신되고,
    상기 적어도 하나의 데이터 파일 각각은 상기 주체를 식별하는 정보에 대응되는, 데이터 제공 방법.
  8. 제7항에 있어서,
    상기 적어도 하나의 데이터 파일 각각은 상기 데이터 파일에 포함되는 정보의 형식 및 상기 데이터 파일의 크기를 기초로 검증되는, 데이터 제공 방법.
  9. 제7항에 있어서,
    상기 임시 데이터베이스는 적어도 하나의 테이블을 포함하고,
    상기 적어도 하나의 테이블 각각은 특정 식별 정보의 타입에 따라 서로 구별되는, 데이터 제공 방법.
  10. 제9항에 있어서,
    상기 적어도 하나의 테이블 각각은,
    상기 적어도 하나의 테이블 각각에 대응하는 작업 구성 파일을 기초로 구성되는 테이블로 교체됨으로써 갱신되는, 데이터 제공 방법.
  11. 제7항에 있어서,
    상기 적어도 하나의 데이터 파일이 업로드될 때, 각 데이터 파일에 포함되는 특정 식별 정보의 타입, 값의 타입, 그룹핑 여부 및 데이터 만료일 정보가 함께 업로드되는, 데이터 제공 방법.
  12. 제7항에 있어서,
    상기 적어도 하나의 데이터 파일 각각은,
    구분자를 이용하여 상기 적어도 하나의 데이터 파일 각각에 포함된 하나 이상의 정보를 서로 구분할 수 있도록 구성되는,
    데이터 제공 방법.
  13. 제1항에 있어서,
    상기 프론트 노드로 전송하는 단계는,
    상기 제2 데이터에 대한 데이터 만료일이 경과하지 않은 경우, 상기 제2 데이터를 상기 프론트 노드로 전송하는 단계를 포함하는, 데이터 제공 방법.
  14. 제13항에 있어서,
    상기 데이터 만료일로부터 기 설정된 기간 이전에 알림을 제공하는 단계를 더 포함하는, 데이터 제공 방법.
  15. 제1항에 있어서,
    상기 임시 데이터베이스에서 제2 데이터를 획득하는 단계는,
    캐시(cache)로부터 상기 제2 데이터를 획득하는 단계를 포함하고,
    상기 캐시는 임시 데이터베이스를 기초로 갱신되는, 데이터 제공 방법.
  16. 제15항에 있어서,
    하나 이상의 특정 식별 정보가 확인되면 상기 특정 식별 정보에 대응하는 데이터가 상기 캐시에서 삭제되는, 데이터 제공 방법.
  17. 제1항에 있어서,
    상기 임시 데이터베이스는 기 설정된 주기로 갱신되는, 데이터 제공 방법.
  18. 제1항에 있어서,
    상기 임시 데이터베이스의 갱신 작업의 요청을 확인한 경우, 상기 갱신 작업의 시작을 확인한 경우 및 상기 갱신 작업의 완료를 확인한 경우 각각에 대해 알림을 제공하는 단계를 더 포함하는, 데이터 제공 방법.
  19. 제1항에 있어서,
    상기 임시 데이터베이스에 포함된 데이터의 활성화 여부 정보를 표시하는 단계를 포함하는, 데이터 제공 방법.
  20. 전자 장치로서,
    적어도 하나의 프로그램이 저장된 메모리; 및
    상기 적어도 하나의 프로그램을 실행함으로써,
    프론트 노드에서 제1 데이터 요청을 수신하고,
    상기 제1 데이터 요청을 기반으로 메인 데이터베이스에서 제1 데이터를 획득하고,
    상기 제1 데이터 요청을 기반으로 임시 데이터베이스에서 제2 데이터를 획득하고,
    상기 제1 데이터 및 상기 제2 데이터를 상기 프론트 노드로 전송하는 프로세서를 포함하는, 전자 장치.
  21. 전자 장치의 임시(ad-hoc) 서비스 제공 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 비일시적 기록매체로서,
    상기 데이터 제공 방법은,
    프론트 노드에서 제1 데이터 요청을 수신하는 단계;
    상기 제1 데이터 요청을 기반으로 메인 데이터베이스에서 제1 데이터를 획득하는 단계;
    상기 제1 데이터 요청을 기반으로 임시 데이터베이스에서 제2 데이터를 획득하는 단계; 및
    상기 제1 데이터 및 상기 제2 데이터를 상기 프론트 노드로 전송하는 단계를 포함하는, 비일시적 기록 매체.
PCT/KR2022/010024 2022-06-30 2022-07-11 데이터 제공 방법 및 그 장치 Ceased WO2024005252A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020220080614A KR102815485B1 (ko) 2022-06-30 2022-06-30 데이터 제공 방법 및 그 장치
KR10-2022-0080614 2022-06-30

Publications (1)

Publication Number Publication Date
WO2024005252A1 true WO2024005252A1 (ko) 2024-01-04

Family

ID=89382565

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/010024 Ceased WO2024005252A1 (ko) 2022-06-30 2022-07-11 데이터 제공 방법 및 그 장치

Country Status (3)

Country Link
KR (2) KR102815485B1 (ko)
TW (2) TWI864827B (ko)
WO (1) WO2024005252A1 (ko)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030060941A (ko) * 2000-11-21 2003-07-16 싱잉피쉬 닷 컴, 인코포레이티드 네트워크를 서치하기 위한 시스템 및 방법
US20140310287A1 (en) * 2012-12-17 2014-10-16 Unisys Corporation Method and system for storing data in commodity computing
JP2018010424A (ja) * 2016-07-12 2018-01-18 株式会社東芝 データベースシステム、データ結合方法、統合サーバ、データ結合プログラム、データベースシステム連携方法、および、データベースシステム連携プログラム
KR20190010079A (ko) * 2017-07-20 2019-01-30 네이버 주식회사 콘텐츠 공유 방법 및 콘텐츠 공유 서버
US20190034550A1 (en) * 2016-04-01 2019-01-31 Alibaba Group Holding Limited Data caching method and apparatus
US20210357405A1 (en) * 2020-05-12 2021-11-18 Coupang Corp. Systems and methods for reducing database query latency

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7996754B2 (en) * 2006-02-13 2011-08-09 International Business Machines Corporation Consolidated content management
US10963438B1 (en) * 2020-11-17 2021-03-30 Coupang Corp. Systems and methods for database query efficiency improvement

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030060941A (ko) * 2000-11-21 2003-07-16 싱잉피쉬 닷 컴, 인코포레이티드 네트워크를 서치하기 위한 시스템 및 방법
US20140310287A1 (en) * 2012-12-17 2014-10-16 Unisys Corporation Method and system for storing data in commodity computing
US20190034550A1 (en) * 2016-04-01 2019-01-31 Alibaba Group Holding Limited Data caching method and apparatus
JP2018010424A (ja) * 2016-07-12 2018-01-18 株式会社東芝 データベースシステム、データ結合方法、統合サーバ、データ結合プログラム、データベースシステム連携方法、および、データベースシステム連携プログラム
KR20190010079A (ko) * 2017-07-20 2019-01-30 네이버 주식회사 콘텐츠 공유 방법 및 콘텐츠 공유 서버
US20210357405A1 (en) * 2020-05-12 2021-11-18 Coupang Corp. Systems and methods for reducing database query latency

Also Published As

Publication number Publication date
KR102815485B1 (ko) 2025-06-02
KR20250079114A (ko) 2025-06-04
TW202507529A (zh) 2025-02-16
TWI864827B (zh) 2024-12-01
TW202416151A (zh) 2024-04-16
TWI894029B (zh) 2025-08-11
KR20240003313A (ko) 2024-01-08

Similar Documents

Publication Publication Date Title
US20150073898A1 (en) Method and system of publishing campaign data
WO2020101343A1 (ko) 데이터베이스 관리 시스템에서의 변경 데이터 캡쳐 구현 기법
WO2015111950A1 (ko) 메세지 중개 방법, 메세지 처리 방법, 서비스 관리 방법 및 상기 방법을 수행하는 장치
WO2023106485A1 (ko) 할인 쿠폰 정보 제공 방법 및 이를 이용한 전자 장치
WO2016171401A1 (ko) 공동 편집 문서를 공유하는 방법 및 장치
CN111796851B (zh) 客户端基础库更新方法、装置、电子设备和存储介质
WO2018201774A1 (zh) 数据审批方法、装置、设备和计算机可读存储介质
WO2020027408A1 (ko) 암호화폐 교환을 위한 트랜잭션을 매칭하는 전자 장치 및 방법
WO2018097407A1 (ko) 사용자 정의 erp 펑션 공유 방법 및 시스템
WO2019245247A1 (en) Method for object management using trace identifier, apparatus for the same, computer program for the same, and recording medium storing computer program thereof
CN115640280B (zh) 数据迁移方法及装置
JP2021157259A (ja) オブジェクト最適配置装置及び方法
WO2023210852A1 (ko) 결제 서비스 제공 방법 및 그 장치
WO2016117818A1 (ko) 효율적인 리타겟팅을 제공하는 방법 및 장치
WO2016171373A1 (ko) 광고플랫폼장치 및 그 동작 방법
WO2024005234A1 (ko) 정보를 제공하는 방법 및 장치
WO2023224423A1 (ko) 웹사이트 자동 생성 플랫폼 운영 방법 및 시스템
KR102815485B1 (ko) 데이터 제공 방법 및 그 장치
WO2024080425A1 (ko) 공급망 관리에 관한 작업 흐름을 제어하는 플랫폼을 제공하는 전자 장치, 그 방법, 및 프로그램이 기록된 비일시적 컴퓨터 판독 가능 기록 매체
WO2022114898A1 (ko) 다중파일 트랜잭션의 파일 관리 기법 및 장치
CN114741158A (zh) 页面切换方法、装置、设备以及存储介质
WO2022244905A1 (ko) 아이템 피드 정보 관리 방법 및 그 장치
WO2016178495A1 (ko) 다중 가입자 정보 처리 스마트 카드, 이를 사용하는 전자 장치, 및 전자 장치에서의 다중 가입자 관리 방법
WO2022211483A1 (en) Method and apparatus for avoiding exception
WO2023136575A1 (en) Method and device of providing adaptive user interface based on user functional elements

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

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

Country of ref document: EP

Kind code of ref document: A1