KR102815485B1 - Data providing method and apparatus for the same - Google Patents

Abstract

An electronic device and its operating method are provided, which receive a first data request from a front node, acquire first data from a main database based on the first data request, acquire second data from a temporary database based on the first data request, and transmit the first data and the second data to the front node.

Description

DATA PROVIDING METHOD AND APPARATUS FOR THE SAME

The present disclosure relates to a data providing method and a device thereof.

With the development of information and communication technology, the e-commerce market has developed rapidly and has become a part of shopping. Customers can purchase products online using electronic devices and have them delivered to their desired location. Accordingly, brokerage services that mediate sales between sellers and buyers and provide delivery services are becoming more active.

In such a sales brokerage service, there are cases where data needs to be changed due to changes in the items being sold or information to be provided to users. However, as the amount of data for the service provided increases, it takes a lot of time to modify or add some data, and if there is no integrity or consistency between the data, errors may occur in the service after the data is modified. Accordingly, in addition to the main database used for service operation, it has become necessary to operate a separate database related to modifying or adding data, and since the worker in charge of managing the data may not be familiar with modifying or adding to the database, a method is required that facilitates adding data to a temporary database without the help of a programmer and provides this to the front end in an appropriate form.

In relation to the present invention, reference may be made to prior literature such as KR 10-1589213 B1 and KR 0-2003-0057528 A.

The object of the present invention is to provide a method and device for managing a temporary database and a main database to provide data that can be provided to a front end according to a service operation direction, and combining information received from them to provide the combined information to the front end.

The technical problems to be solved by the present invention are not limited to the problems described above, and other technical problems can be inferred from the following examples.

According to one embodiment, a method for providing data of an electronic device may include: receiving a first data request from a front node; obtaining first data from a main database based on the first data request; obtaining second data from a temporary database based on the first data request; and transmitting the first data and the second data to the front node.

Additionally, the data providing method may include a step of transmitting a second data request including specific identification information to a temporary database; and a step of obtaining second data from the temporary database according to the second data request.

Additionally, certain identifying information can be identified based on the first data.

Additionally, the second data can be obtained from a table verified based on configuration information obtained from a dynamic configuration database according to specific identification information in a temporary database.

Additionally, the second data may include at least one key-value pair corresponding to the first data request.

Additionally, the key of a key-value pair may be information that identifies the entity that created the value corresponding to the key.

Additionally, the temporary database may be updated based on at least one data file, each of the at least one data file including at least one key-value pair and information identifying a subject that created each key-value pair.

Additionally, each of at least one data file can be verified based on the format of information contained in the data file and the size of the data file.

Additionally, the temporary database includes at least one table, and each of the at least one table can be distinguished from each other based on a type of specific identifying information.

Additionally, each of at least one table can be updated by replacing it with a table configured based on a working configuration file corresponding to each of at least one table.

Additionally, when at least one data file is uploaded, the type of specific identification information contained in each data file, the type of value, whether grouped, and the data expiration date information may be uploaded together.

Additionally, the first temporary data file may be configured to distinguish one or more pieces of information included in the first temporary data from one another using a delimiter, and the data providing method may include a step of parsing one or more temporary data files corresponding to the one or more temporary data using the delimiter to verify the one or more temporary data.

Additionally, the data providing method may include a step of transmitting the first data and the second data to the front node if the data expiration date for the second data has not expired.

Additionally, the data provision method may further include a step of providing a notification prior to a preset period from the data expiration date.

Additionally, the method of providing data includes a step of obtaining second data from a cache, wherein the cache can be updated based on a temporary database.

Additionally, when one or more specific identifying information is identified, data corresponding to the specific identifying information may be deleted from the cache.

Additionally, the temporary database can be updated at preset intervals.

Additionally, the data provision method can provide notifications for each of the following cases: when a request for an update operation of a temporary database is confirmed, when the start of an update operation is confirmed, and when the completion of an update operation is confirmed.

Additionally, the data providing method may include a step of displaying information on whether data included in a temporary database is activated.

In addition, the electronic device may include a memory having at least one program stored therein; and a processor that executes at least one program to receive a first data request from a front node, obtain first data from a main database based on the first data request, obtain second data from a temporary database based on the first data request, and transmit the first data and the second data to the front node.

Additionally, a non-transitory computer-readable recording medium can record a program for causing a computer to execute the above-described operating method.

Specific details of other embodiments are included in the detailed description and drawings.

According to the present invention, a user can provide temporary data to the front end together with main data without separate coding, so that the service user can receive the temporary data together with the main data. Therefore, there is an effect of saving programmer or developer resources.

Additionally, according to the present invention, a user can create, delete, and manage tables of a temporary database through a user interface.

In addition, according to the present invention, by utilizing a temporary database, data transmitted from a temporary database can be distinguished from data included in data provided from a backend, and based on this, a new service can be provided by utilizing data from a front end.

In addition, according to the present invention, 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 transferred from multiple tables based on specific identification information.

In addition, according to the present invention, there is an advantage in that temporary data can be obtained from a temporary database by utilizing a data request including specific identification information for the main database without separately modifying the main database storing the main data or modifying a data request form for the main database.

In addition, according to the present invention, when there is a change in the front service and a change in some data is required accordingly, a table related to the corresponding service can be added by utilizing the present invention, and when requesting data, data of the corresponding table can be obtained through an identifier and provided from the front node.

The effects of the invention are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood by a person skilled in the art from the description of the claims.

Figure 1 illustrates one embodiment of an electronic device according to the present disclosure.
FIG. 2 illustrates one embodiment of a data providing method according to the present disclosure.
FIG. 3a illustrates an embodiment of a data file according to the present disclosure.
FIG. 3b illustrates an example of information regarding a data file according to the present disclosure.
Figure 4 illustrates the types of information that may be included in information about a data file according to the present disclosure.
Figure 5 shows a table of data according to the present disclosure.
Figure 6 illustrates a request and response for temporary data regarding a data provision method according to the present disclosure.
FIG. 7 illustrates an embodiment of a data providing method according to the present disclosure.
FIG. 8 illustrates an embodiment of a data providing method according to the present disclosure.
FIG. 9 illustrates an embodiment of a data providing method according to the present disclosure.
FIG. 10 illustrates an embodiment of a data providing method according to the present disclosure.
FIG. 11 illustrates a user interface for a data providing method according to the present disclosure.
FIG. 12 illustrates a user interface for a data providing method according to the present disclosure.
FIG. 13 illustrates a user interface for a data providing method according to the present disclosure.
FIG. 14 illustrates an embodiment of a data providing method according to the present disclosure.
FIG. 15 illustrates an embodiment of a data providing method according to the present disclosure.
FIG. 16 illustrates an embodiment of a data providing method according to the present disclosure.
FIG. 17 illustrates an embodiment of a data providing method according to the present disclosure.
FIG. 18 illustrates an embodiment of a data providing method according to the present disclosure.
FIG. 19 illustrates an embodiment of a data providing method according to the present disclosure.

The embodiments described in this disclosure are intended to illustrate rather than limit the present disclosure, and those skilled in the art can design many alternative embodiments without departing from the scope of the present disclosure defined by the appended claims. The terms used in the embodiments have been selected from currently widely used general terms as much as possible while considering the functions in the present disclosure, but this may vary depending on the intention of a person skilled in the art, precedents, the emergence of new technologies, etc. In addition, in certain cases, there are terms arbitrarily selected by the applicant, and in this case, the meanings thereof will be described in detail in the corresponding description section. Therefore, the terms used in the present disclosure should be defined based on the meanings of the terms and the overall contents of the present disclosure, rather than the simple names of the terms.

As used herein, the singular expression includes both the singular and the plural, unless the context clearly indicates otherwise.

When it is said throughout this specification that a part "comprises" certain elements or steps, unless otherwise specifically stated, that does not mean that the part must include all of those elements or steps, nor does it exclude the inclusion of elements or steps other than those listed in the claims or throughout the specification, but only that the part may include more.

Also, terms including ordinal numbers such as first, second, etc. used in this specification may be used to describe various components, but the components should not be limited by the terms including ordinal numbers. The terms are used only for the purpose of distinguishing one component from another component in a portion of the specification in context. For example, a first component may be referred to as a second component in another portion of the specification, and conversely, a second component may also be referred to as a first component in another portion of the specification, without departing from the scope of the present invention.

In this specification, terms such as "mechanism", "element", "means", and "configuration" may be used broadly and are not limited to mechanical and physical configurations. The terms may include the meaning of a series of software processes (routines) in connection with a processor, etc.

The use of the term "above" and similar referential terms in this specification (especially in the claims) may refer to both the singular and the plural. In addition, when a range is described, it is intended to include individual values within the range (unless otherwise stated), and each individual value constituting the range is described in the detailed description. Finally, unless the order of the steps constituting the method is explicitly stated or stated to the contrary, the steps may be rearranged and performed in any appropriate order, and the order in which the steps are described is not necessarily limited. The use of all examples or exemplary terms (e.g., etc.) is intended merely to further illustrate the technical idea, and the scope is not limited by the examples or exemplary terms, unless otherwise stated by the claims. Those skilled in the art may add various modifications, combinations, and changes to the embodiments disclosed herein, depending on design conditions and factors, to form new embodiments falling within the scope of the claims or their equivalents.

Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.

FIG. 1 illustrates an exemplary and simplified block diagram of an electronic device (100) that may be used to implement at least one embodiment of the present disclosure. In various embodiments, the electronic device (100) may be used to implement any system or method described in the present disclosure. For example, the electronic device (100) may be configured to be used as any electronic device, including a data server, a web server, a portable computing device, a personal computer, a tablet computer, a workstation, a mobile phone, a smart phone, or any other device described below.

The electronic device (100) may include one or more processors (110) having a memory (120) and one or more cache memories and a memory controller configured to communicate with the memory (120). Additionally, the electronic device (100) may include other devices that may be connected to the electronic device (100) via one or more ports (e.g., a Universal Serial Bus (USB), a headphone jack, a Lightning connector, a Thunderbolt connector, etc.). The devices that may be connected to the electronic device (100) may include a plurality of ports configured to receive fiber optic connectors. The configuration of the illustrated electronic device (100) is intended only as a specific example for the purpose of illustrating preferred embodiments of the device. Only components relevant to the present embodiments are illustrated in the illustrated electronic device (100). Accordingly, it will be apparent to one of ordinary skill in the art that the electronic device (100) may further include other general purpose components in addition to the components illustrated.

The processor (110) may be utilized to enable the electronic device (100) to provide steps or functions of any of the embodiments described in the present disclosure. For example, the processor (110) controls the electronic device (100) as a whole 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), or the like provided within the electronic device (100), but is not limited thereto.

The memory (120) is a hardware that stores various types of data processed within the electronic device (100), and the memory (120) can store data processed and data to be processed through the processor (110) in the electronic device (100). In addition, the memory (120) can store basic programming and data structures that can provide functions of at least one embodiment of the present disclosure, as well as applications (programs, code modules, commands), drivers, etc. that can provide functions of the embodiments of the present disclosure. The memory (120) can include a random access memory (RAM) such as a dynamic random access memory (DRAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a CD-ROM, a Blu-ray or other optical disk storage, a hard disk drive (HDD), a solid state drive (SSD), or a flash memory.

The method and each step according to the present disclosure can be performed by an electronic device (100) or a processor (110). The electronic device (100) operates under the control of the processor (110). For simplicity of explanation, the following description assumes that the electronic device (100) is the subject of performing the method and each step according to the present disclosure.

FIG. 2 illustrates one embodiment of a payment service providing method according to the present disclosure. In one embodiment, an electronic device (100) may receive a first data request from a front node, obtain first data from a main database based on the first data request, obtain second data from a temporary database based on the first data request, and transmit the first data and the second data to a front node (not shown).

A "front node (not shown)" can receive data from a backend node and generate a page to be provided to a user. The front node can generate a page as a user's terminal and provide a service to a service user.

The serving layer (214) can provide data to the front node. The serving layer (214) can be included in the electronic device (100). The serving layer (214) includes a plurality of APIs, and can receive data from a backend node or server corresponding to a specific API according to a request of the front node and transmit the data to the front node. Specifically, the serving layer (214) can 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 a search result of data to the front node. The promotion API (217) can provide data regarding a promotion to the front node.

The front node can transmit a request including specific identification information of a specific object to the serving layer (214). The serving layer (214) can transmit a first data request to the object data providing API (213). The object data providing API (213) can be included in the electronic device (100). Specifically, the first data request can be a request for data regarding a specific object. In other words, the first data request can include specific identification information of a specific object corresponding to the request from the front node. The object data providing API (213) can obtain first data in response to the first data request of the serving layer (214) and provide the first data to the serving layer (214).

The object data provision API (213) can obtain first data from the main database based on the first data request. The main database can store data regarding a specific object. The first data request can include identification information regarding a specific object, and the object data provision API (213) can obtain first data regarding an object corresponding to the identification information from the main database using the identification information.

The main database can store a large amount of data, and accordingly, data requests and data provision tasks to the main database can also be performed frequently. Therefore, in order to minimize interference with the data provision tasks of the main database, data change, modification, deletion, and update tasks 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 provision API (213) can transmit the first data request to the shuttle (212). The shuttle (212) can be a part of the electronic device (100). The shuttle (212) can obtain second data from the temporary database (210) based on the first data request. The temporary database (210) can store data regarding a specific object. In addition, the temporary database (210) can be, or include, a distributed database such as Spark Cassandra, for example. The shuttle (212) can obtain second data regarding an object corresponding to the specific identification information from the temporary database (210) using specific identification information identified based on the first data request or the first data, and can transmit the second data to the object data provision API (213). The second data can include temporary data regarding a specific object. The object data provision API (213) or the processor can transmit 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.

In one embodiment, the shuttle (212) may transmit a second data request including specific identification information to the temporary database (210) and obtain second data from the temporary database (210) according to 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 the second data will be described in detail later with reference to FIG. 6.

In one embodiment, the shuttle (212) can obtain second data from the cache (211), and the cache (211) can be updated based on the temporary database (210). The cache (211) can include some of the data stored in the temporary database (210), such as the second data. This has the advantage of obtaining data more quickly than obtaining data directly from the temporary database (210).

In one embodiment, the second data may be obtained from a table identified based on configuration information obtained from the dynamic configuration database (209) according to specific identification information in the temporary database (210). Details of this table and the dynamic configuration database (209) will be described in detail later with reference to FIG. 5.

In one embodiment, a user (201) may upload (202) at least one data file via an ad hoc service (203) to add, modify, or update data in a temporary database (210). The ad hoc service (203) may include an ad hoc user interface (UI) (204), and the user (201) may upload (202) at least one data file using the ad hoc UI (204).

At least one data file can be a text file or a comma separated values (csv) file. An embodiment of the at least one data file is shown in FIG. 3a. The at least one data file can be stored in the file database (205), and the data extractor (208) can update the temporary database (210) from the at least one data file. That is, the temporary database (210) can be updated based on the at least one data file. The file database (205) can include cloud storage such as Amazon S3.

In one embodiment, each of the at least one data file may include at least one key-value pair. The key of the at least one key-value pair may be specific identification information, and the value may be a value corresponding to the specific identification information. Here, 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). In one embodiment, 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 delimiter. The delimiter may be a tab or a comma (,), etc. The delimiter may be set through the ad hoc UI (204) of FIG. 2. The user (201) may determine the delimiter to be used through the ad hoc UI (204).

Referring to FIG. 3a, the A1.txt file (301) may include 2 and 3 as values corresponding to keys 10001 and 10002, respectively. Each key and value is separated by a comma. The A2.txt file (302) may have 3000 as a value corresponding to key 10001. The A3.txt file (303) may have true as a value corresponding to key 19101053. The A4.txt file (304) may have retail/image01.png as a 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 at least one data file may correspond to information identifying a subject (or user) who created at least one key-value pair (i.e., a generating subject identifier). The generating subject identifier may be information identifying a usage of the second data. Through the generating subject identifier, the front node may determine a usage of the key-value pair or the second data included in at least one data file. That is, the generating subject identifier may be an identifier promised between the user and the front node, and may include identification information that allows not only the generating subject but also a front-end node that requests data required for a temporary database and receives the data to distinguish information obtained from the temporary database.

In one embodiment, each of at least one data file can be verified based on the format of information (key and value) included in the data file or the size of the data file. For example, it can be verified whether the key included in at least one data file is of integer type or the value is of string type, and it can be verified whether the data file is 1 megabyte or less. This has the effect of preventing a user (201) who is not familiar with programming from uploading data that may cause potential program errors.

In one embodiment, information regarding at least one data file may be stored in a file information database (206). The file information database (206) may include a relational database such as Amazon RDS. The information regarding at least one data file is described in more detail later with respect to FIG. 3b.

In one embodiment, a job configuration file may be uploaded to a job configuration file database (207) to update a temporary database (210) based on at least one data file stored in a file database (205). The job 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) to identify one or more data files stored in the file database (205), update the temporary database (210), and accordingly, update a table in the temporary database (210) and update a setting value in the dynamic setting database (209) to set a table or row corresponding to data to be transmitted to the front node. The data extractor (208) may include a data streaming tool such as Spark Streaming. The job configuration file may include information for batch processing one or more data files. This has the advantage of being able to adjust the load applied to the temporary database (210) by updating the temporary database (210) at an appropriate frequency.

In one embodiment, the data extractor (208) can update the temporary database (210) and then upload configuration information regarding the update of the temporary database (210) to the dynamic configuration database (209). The shuttle (212) can utilize this configuration information from the dynamic configuration database (209) to obtain second data from the temporary database (210). The configuration information of the dynamic configuration database (209) can include information regarding which data the shuttle (212) should refer to from the temporary database (210). For example, the shuttle (212) can determine which table and row/column information it should refer to based on the configuration information of the dynamic configuration database (209) and obtain the second data from the temporary database (210) based on this. By managing the configuration information in the dynamic configuration database (209) in this way, the data of the temporary database (210) can be adaptively updated, and even when the version of the data being used is changed, the data to be transmitted to the front node can be easily set by updating the dynamic configuration database (209).

The dynamic configuration database (209) may include updated table names of the temporary database (210) and updated column information of the corresponding tables.

FIG. 3b illustrates an example of information about at least one data file according to the present disclosure. At least one data file uploaded by a user may be stored in a file information database in the form of a table as shown in FIG. 3b. The information about at least one data file may include information such as an identifier (310) of each data file, a creator identifier (320), an identifier type (330), and a storage path (340).

The identifier (310) may correspond to a 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 the usage of the key-value pair included in at least one data file.

The identifier type (330) may mean the type of a key of a key-value pair included in at least one data file. Specifically, a key of a key-value pair included in at least one data file may correspond to specific identification information, and the specific identification information may be classified according to a certain standard. For example, the specific identification information may be identification information of a vendor item (VENDOR_ITEM) type, identification information of a category (CATEGORY) type, or identification information of a member (MEMBER) type.

The storage path (340) may represent a path where each of at least one data file is stored in the file database.

For example, a row with identifier (310) of 2 may correspond to file A2.txt (302) of FIG. 3A. That is, the storage path (340) cell of the row with identifier (310) of 2 may include a path where file A2.txt (302) of FIG. 3A is stored in the file database. Referring to the row with identifier (310) of 2, the creation subject identifier (320) may be CATEGORY_IMAGE, which may mean an operation of adding/changing/deleting an image corresponding to a specific category. In this case, the identifier type (330) may be set to CATEGORY. That is, a key included in file A2.txt (302), which is a data file related to this operation, may correspond to a specific category. For example, the A2.txt file (302) may include a key 10001 corresponding to the "T-shirt" category, and the value corresponding to the 10001 key to change the image corresponding to the "T-shirt" category may be the URL (Uniform Resource Locator) of the new image, for example, "retail/image01.png".

Also, for example, a row with an identifier (310) of 1 may correspond to the A1.txt file (301) of FIG. 3a, a row with an identifier (310) of 3 may correspond to the A3.txt file (303) of FIG. 3a, and a row with an identifier (310) of 4 may correspond to the A4.txt file (304) of FIG. 3a.

In one embodiment, when at least one data file is uploaded, the type of specific identifying information contained in each data file, the type of value, whether grouped, and the data expiration date information may be uploaded together.

Types of specific identifying information may include, for example, types of specific identifying information such as PRODUCT, ITEM, VENDOR_ITEM, CATEGORY, VENDOR, MEMBER, UNKNOWN, etc.

The type of a value can include data description types such as TEXT, BOOLEAN, DOUBLE, LONG, UNKNOWN, etc.

The grouping may include whether the value can be a set of multiple values. For example, if the grouping is "SINGLE", this may mean that the value corresponding to a particular identifier is a single value. For another example, if the grouping is "MULTI", this may mean that the value corresponding to a particular identifier can be multiple, or other key-value pairs.

The data expiration date information may indicate a valid period for each of at least one data file. That is, if the data expiration date is set to May 16, 2022, the data file is valid only until May 16, 2022, and the information included in the data file may also be valid only until May 16, 2022. Accordingly, even if the information included in the data file is already stored in the temporary database, it may be provided to the front node only until May 16, 2022, which is the data expiration date. That is, the electronic device (100) may transmit the second data to the front node if the data expiration date for the second data has not passed. In addition, the electronic device (100) may provide a notification prior to a preset period from the data expiration date. This has the advantage of allowing the user to appropriately update the temporary data before the temporary data expires.

FIG. 4 illustrates types of information that may be included in information about a data file according to the present disclosure. Information about an ad hoc data transfer object (AdHocDto, 410) may include information about temporary data according to the present disclosure. That is, each row shown in the ad hoc data transfer object (410) may be information about a data file shown in FIG. 3b, that is, column information of a table. Accordingly, the information about the data file may include 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 subject (or file creation subject, createdBy) information, ad hoc modification date (or file modification date, modifiedAt) information, ad hoc modification subject (or file modification subject, modifiedBy) information, temporary database upload status (status) information of ad hoc data or data file, and storage path (s3Path) information of the data file.

A part of the ad hoc data transfer object (410) may be ad hoc data history information (AdHocDtoHistory, 430). The ad hoc data history information (430) may include identifier (id) information, ad hoc identifier (adHocID) information, description (Description) information, ad hoc creation date (or file creation date, createdAt) information, ad hoc creation subject (or file creation subject, createdBy) information, etc.

Identifier type (idType) information (420) may include identifier (id) information and type information of the identifier type.

Each piece of information (410, 420, 430) can be created, changed, or deleted by the administrator, and can be created, changed, or deleted by the user. For the management of each piece of information, the user's authority can be reduced compared to that of the administrator.

FIG. 5 illustrates a table of data that may be stored in a temporary database according to the present disclosure. In one embodiment, the temporary database includes at least one table, and each of the at least one table may be distinguished from each other according to a type of specific identification information. The type of specific identification information may correspond to the identifier type (330) shown in FIG. 3b. For example, 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.

For example, the type of specific identification information of a row in which the identifier (310) of FIG. 3b is 1, that is, the identifier type (310) is VENDOR_ITEM. The row in which the identifier (310) of FIG. 3b is 1 corresponds to the A1.txt file (301) of FIG. 3a. Since the generation 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) can be set to VI_BEST_SELLER_RANKING. And, since the A1.txt file (301) includes the value 2 corresponding to the specific identification information 10001 and the value 3 corresponding to the specific identification information 10002, the values 2 and 3 can be recorded in the cells corresponding to the rows with the specific identification information 10001 and 10002, respectively, in the second column of the vendor item table (510).

Next, the type of specific identification information of the row whose identifier (310) of FIG. 3b is 3 is also VENDOR_ITEM. The row whose identifier (310) of FIG. 3b is 3 corresponds to the A3.txt file (303) of FIG. 3a. Since the generation subject identifier (320) of the row whose identifier (310) of FIG. 3b is 3 is VI_FRESH_PROMOTION, the title of the third column of the vendor item table (510) can be set to VI_FRESH_PROMOTION. In addition, since the A3.txt file (303) includes the value 3000 corresponding to the specific identification information 10001, 3000 can be recorded in the cell corresponding to the row whose specific identification information is 10001 in the third column of the vendor item table (510).

Next, the type of specific identification information of the row in which the identifier (310) of FIG. 3b is 4 is MEMBER. The row in which the identifier (310) of FIG. 3b is 4 corresponds to the A4.txt file (304) of FIG. 3a. Since the generating 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) can be set to MEMBER_FREE_SHIPPING. In addition, since the A4.txt file (304) includes the value true corresponding to the specific identification information 19101053, true can be recorded in the cell corresponding to the row in which the specific identification information is 19101053 in the second column of the member table (520).

Finally, the type of specific identification information of the row whose identifier (310) of FIG. 3b is 2 is CATEGORY. The row whose identifier (310) of FIG. 3b is 2 corresponds to the A2.txt file (302) of FIG. 3a. Since the creator identifier (320) of the row whose identifier (310) of FIG. 3b is 2 is CATEGORY_IMAGE, the title of the second column of the category table (530) can be set to CATEGORY_IMAGE. In addition, since the A2.txt file (302) includes the value retail/image01.png corresponding to the specific identification information 10001, retail/image01.png can be recorded in the cell corresponding to the row whose specific identification information is 10001 in the second column of the category table (530).

Distinguishing at least one table of the temporary database according to the type of specific identification information as described above has the advantage of allowing the second data to be quickly obtained from the temporary database when a first data request or a second data request from the front node, the serving layer, the object data providing API, or the shuttle is about the type of specific identification information and the specific identification information.

FIG. 6 illustrates a second data request and a response corresponding to the second data request according to the present disclosure. In one embodiment, the second data request may include specific identification information. The second data request illustrated in FIG. 6 corresponds to "vi": 10001. vi means a VENDOR_ITEM type among types of specific identification information, and 10001 corresponds to a value of the specific identification information. That is, the second data request of 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. For example, the first data request itself may include requesting second data having a specific identification information of the VENDOR_ITEM type of 10001, and the second data request may be generated by the first data because the first data obtained according to the first data request includes information about an object having a specific identification information of the VENDOR_ITEM type of 10001.

The shuttle or object data providing API can transmit the second data request shown in FIG. 6 to the temporary database, and can generate the response shown in FIG. 6. According to FIG. 5, in the vendor item table (510) storing specific identification information of the VENDOR_ITEM type and data corresponding thereto, there is a row whose specific identification information is 10001. Accordingly, the shuttle or object data providing API can obtain the values 2 and 3 of the second row of the vendor item table (510) whose specific identification information is 10001, and the column names VI_BEST_SELLER_RANKING and VI_FRESH_PROMOTION, respectively. The shuttle or object data providing API can use this to generate a response including the second data as shown in FIG. 6.

In one embodiment, the second data may include at least one key-value pair corresponding to the first data request or the second data request. As shown in FIG. 6, the second data may be described in the form of key-value pairs. Specifically, the second data may be described in JSON format. The key of the key-value pair included in the second data may be information identifying 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.

For example, as shown in FIG. 6, the second data can be a first key-value pair with a value 2 corresponding to a key VI_BEST_SELLER_RANKING and a second key-value pair with a value 3 corresponding to a key VI_FRESH_PROMOTION. The first key-value pair and the second key-value pair can be included in a second data response as shown in FIG. 6, and the second data response can include a "vendorItem" key indicating that the second data corresponds to specific identifying information of the VENDOR_ITEM type. Additionally, the second data response can include an "adhocProperties" key indicating that the second data is temporary data.

FIG. 7 illustrates an embodiment of a data providing method according to the present disclosure. Specifically, FIG. 7 illustrates a process of updating at least one table of a temporary database based on information of a data file uploaded by a user. An ad hoc backend (710) may be a module included in an 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 an electronic device (100).

In one embodiment, according to step S701, the ad hoc backend (710) can retrieve the airflow job base configuration file from the adhoc_base.yaml file in Amazon S3 (730). The adhoc_base.yaml file or the airflow job base configuration file can include common settings, commands, or sequences for updating at least one table in the temporary database.

In one embodiment, according to step S702, the ad hoc backend (710) can create a cache of the base configuration for triggering each airflow task. That is, the ad hoc backend (710) can cache the base configuration information based on the task base configuration file.

In one embodiment, according to step S703, the user may click on the publish button for Adhoc.id. That is, the user may instruct to update the temporary database by publishing at least one data file already uploaded to the file database.

In one embodiment, according to step S704, the ad hoc backend (710) may set the ad hoc status to 'activated' in response to the user's click on the publish button. The ad hoc status may mean whether information included in a data file newly updated in the temporary database is activated when updating the temporary database. If the ad hoc status is activated, information of the corresponding temporary database may be transferred to the front node by the shuttle. The ad hoc status information may be recorded in Amazon RDS (720).

In one embodiment, according to step S705, the ad hoc backend (710) may query all ad hoc lists in an activated state from Amazon RDS (720). The ad hoc list may mean information of a file information database, i.e., information of a data file stored in Amazon RDS (720). That is, the ad hoc list may correspond to the table of FIG. 3b.

In one embodiment, according to step S706, the ad hoc backend (710) can create a configuration for an Airflow job. This configuration can be based on the basic configuration cached in step S702. In addition, the ad hoc backend (710) can create an input session of a yaml file as an ad hoc list. This allows the ad hoc backend (710) to configure a job configuration file for an update task of a temporary database.

In one embodiment, according to step S707, the ad hoc backend (710) can upload an adhoc_{ID_TYPE}.yaml file to Amazon S3 (730). The adhoc_{ID_TYPE}.yaml file can be a job configuration file that includes settings for a job to update a table in a temporary database whose type of specific identification information is ID_TYPE based on information corresponding to key-value pairs whose type of specific identification information is ID_TYPE in at least one data file. For example, the vendor item table (510) of FIG. 5 can be updated by referencing the adhoc_vendorItem.yaml file.

In one embodiment, according to step S708, Apache Airflow (740) can retrieve a yaml file from Amazon S3 (730) for the task. Apache Airflow (740) can retrieve each csv, text file to be parsed according to step S709 from Amazon S3 (730) by referencing the yaml file. The csv, text file can correspond to at least one data file.

In one embodiment, according to step S710, Apache Airflow (740) can create a new table of Cassandra. Cassandra may correspond to a temporary database. In this process, an existing table of Cassandra can be dropped. That is, Apache Airflow (740) can create a new table corresponding to a table stored in Cassandra or a temporary database, and replace or substitute the table stored in the temporary database with the newly created table. This method has an advantage of updating the temporary database faster than overwriting all information of at least one file in a table of Cassandra or a temporary database. That is, in one embodiment, each of at least one table can be updated by being replaced with a table configured based on a task configuration file corresponding to each of at least one table.

FIG. 8 illustrates an embodiment of a method according to the present disclosure. Specifically, FIG. 8 illustrates a method for transmitting new data to a front node. Apache Airflow (810) may include a Join-Writer (811). In one embodiment, the Join-Writer (811) may be a module that performs a task of joining tables with each other. 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). The CDS (812) may correspond to a main database. The Shuttle (813) may obtain new data from the CDS (812), and the Object Data Providing API (814) may bring in data based on each id. Here, the id may be specific identification information. The object data provision API (814) can deliver new data to the serving layer (815) so that the new data can be delivered to the front node.

In another embodiment, 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). The CDS (823) may correspond to the main database. The shuttle (824) may obtain new data from the CDS (823), and the object data provision API (827) may retrieve data based on each id. Here, the id may be specific identification information. The object data provision API (827) may forward the new data to the serving layer (828), so that the new data may be forwarded to the front node.

Alternatively, the join-writer (823) and the ad-hoc writer (822) can write the join data and the ad-hoc data including the new data to the same table, and then update the CDS (825). The CDS (825) may correspond to the main database or the temporary database. The shuttle (826) can obtain the new data from the CDS (825), and the object data providing API (827) can retrieve the data based on each id, where the id can be a specific identification information. The object data providing API (827) can pass the new data to the serving layer (828), so that the new data can be passed to the front node.

FIG. 9 illustrates an embodiment of a method according to the present disclosure. Each component shown in FIG. 9 may correspond to a component of the same name described in FIGS. 1 to 8, respectively. A user (901) may upload at least one data file through an ad hoc UI of an ad hoc service (903). The at least one data file may be uploaded to a file database or S3 (905). Information about the at least one uploaded data file may be uploaded to a file information database or RDS (904).

The user (901) can trigger the active test list to trigger the operation of the data extractor (906). The active test list may mean a list of files in which an ad hoc state is activated in the file information database or S3 (905). The data extractor (906) can upload the names of the tables and columns provided to the dynamic configuration database (907). The tables and columns provided may mean tables that have been (or will be) updated and columns that have been (or will be) updated in the temporary database or CDS (909). The dynamic configuration database (907) can inform the shuttle (908) of the names of the updated tables and columns.

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 a 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 second data request based on the first data request or the first data. The object data providing API (911) may transmit the second data request to the shuttle (908). The shuttle (908) may provide 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 transmit the first data and the second data to the serving layer (912) so that the first data and the second data may be transmitted to the front node.

Fig. 10 illustrates one embodiment of a method according to the present disclosure. Each component shown in Fig. 10 may correspond to a component of the same name described in Figs. 1 to 9.

In one embodiment, according to step S1001, a user can create a new data file or update an existing data file through an ad hoc UI (1010). According to step S1002, the ad hoc UI (1010) can call /api/file/upload of an ad hoc server (1020). /api/file/upload may mean a command for performing upload of a data file. The ad hoc server (1020) may be a module included in the electronic device (100).

According to step S1003, the file database or S3 (1030) may first store the type and title of specific identification information in the file information database (1040). Here, the title may correspond to the identifier of the entity that created the file, i.e., the creation entity identifier (320) of FIG. 3b.

According to step S1004, the file information database (1040) may return a storage result and an identifier. Here, the identifier may correspond to the identifier (310) of FIG. 3b.

According to step S1005, the ad hoc server (1020) can upload at least one file to the file database or S3 (1030). The file database or S3 (1030) can return the upload result to the ad hoc server (1020) according to step S1006.

The ad hoc server (1020) may store the s3 path together with the previous id in the file information database (1040) according to step S1007. The previous id may correspond to the identifier (310) of FIG. 3B and may mean the identifier (310) before the file is uploaded or updated.

According to step S1008, the file information database (1040) notifies the ad hoc server (1020) of the upload success, and the ad hoc server (1020) can display the upload success UI (S1010) on the ad hoc UI (1010) according to step S1009.

FIG. 11 illustrates an embodiment of an ad hoc UI (1110) according to the present disclosure. The ad hoc UI (1110) can display a list (1114) of ad hoc services (temporary services) based on a file information database. The ad hoc services or temporary services can 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 a user can search for information based on column names in a list (1114).

The ad hoc UI (1110) may include a new button (1113), and a user may click the new button (1113) to upload at least one file to the database (1120).

The ad hoc UI (1110) may include a refresh button (1115), and a user may click the refresh button (1115) to refresh at least one file uploaded to the database (1120).

The ad hoc UI (1110) may include a download button (1116), and a 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) may include a confirmation window (1130) to confirm with the user whether to delete or not.

FIG. 12 illustrates an embodiment of an ad hoc UI (1200) according to the present disclosure. Specifically, the ad hoc UI (1200) illustrates an interface for newly creating or editing an ad hoc service, i.e., 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) of FIG. 3b. That is, the use of temporary data or second data may be determined based on the set business ID. In order for the second data to be provided appropriately, the business ID or the 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 into which a related link can be inserted and a field into which a description of the ad hoc service can be recorded.

The ad hoc UI (1200) may include a field into which at least one data file may be entered. This allows at least one data file to be uploaded to a file database.

FIG. 13 illustrates an embodiment of an ad hoc UI (1300) according to the present disclosure. Specifically, the ad hoc UI (1300) illustrates an interface for editing an ad hoc service, i.e., temporary data.

The ad hoc UI (1300) may include a state active UI. The state active UI may indicate whether the ad hoc 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 into which a related link can be inserted and a field into which a description of the ad hoc service can be recorded.

The ad hoc UI (1300) may include a field into which at least one data file may be entered. This allows at least one data file to be uploaded to a file database.

Fig. 14 illustrates one embodiment of a method according to the present disclosure. Each component shown in Fig. 14 may correspond to a component having the same name described in Figs. 1 to 13.

In one embodiment, Spark airflow (1410) can trigger a data extractor (1420). The data extractor (1420) can include a join writer (1421). The data extractor (1420) can update a table in a temporary database or CDS (1430) in response to the trigger of Spark airflow.

CDS (1430) can cache updated information of the table in cache (cache, 1440). Shuttle (1450) can obtain second data from cache (1440). The second data can include updated information of the table.

That is, in one embodiment, the electronic device (100) can obtain second data from a cache, and the cache can be updated based on a temporary database.

The second data can be passed to mate-api (1460). Mate-api (1460) may correspond to an object data provision API.

Fig. 15 illustrates one embodiment of a method according to the present disclosure. Each component shown in Fig. 15 may correspond to a component of the same name described in Figs. 1 to 14.

In one embodiment, a user (1500) can CUD (Create, Update, Delete) a data file through a mock creation UI (1503) of a 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. In addition, the mock may correspond to an ad hoc service or at least one data file.

The mock creation UI (1503) can create (1505) and update (1506) mocks via bulk Kafka (1507). The result of creating or updating mocks can be delivered to the mock creation UI (1503) via individual Kafka (1508). Bulk Kafka (1507) and individual Kafka (1508) can refer to data or message streaming solutions such as Apache Kafka.

The mock creation UI (1503) can trigger the shuttle (1511) to update the CDS (1512). At this time, the updater (1510) can update the tables (1533, 1534) of the CDS (1512) and the tables (1531, 1532) of the RDS (1504) based on the created or updated mock. The tables of the RDS (1504) can be updated through transaction Kafka (1509). Transaction Kafka (1509) can also mean a data or message streaming solution such as Apache Kafka.

In tables (1533, 1534) of CDS (1512) and tables (1531, 1532) of RDS (1504), SIGNAL may correspond to the creation subject identifier (320) of FIG. 3b, and LEVEL may correspond to the type of specific identification information of FIG. 3b, that is, the identifier type (330). ID and String may mean the key and value shown in FIG. 3a. For example, the key 10001 of B1.txt (305) of FIG. 3a may correspond to ID, and the value {"bsr_rank": "1", "bsr_limit": false} may correspond to String. String may mean a character string in JSON format.

The shuttle (1511) may obtain second data from the cache (1513) or the CDS (1512) according to the 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 a response (1536) and transmit it to the serving layer (1516). The second data may be included in the response (1536) together with the first data. At this time, the mocking handler (1515) may intervene and replace the response if the signal is of the MOCK type. The MOCK type signal may be a type of specific identification information used to test the operation of the method according to the present disclosure. Each mocking handler (1520) can intervene in the listing API (1517), search API (1518), and promotion API (1519) of the serving layer (1516) to process a response to a signal of the MOCK type.

Fig. 16 illustrates one embodiment of a method according to the present disclosure. Each component shown in Fig. 16 may correspond to a component of the same name described in Figs. 1 to 15.

In one embodiment, a user (1600) can CUD (Create, Update, Delete) a data file through a mock creation UI (1603) of a 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. In addition, the mock may correspond to an ad hoc service or at least one data file.

The mock creation UI (1603) can publish (1605) a mock to the mock Kafka (1606). At this time, the cleanup scheduler (1604) can trigger the mock creation UI (1603) to publish (1605) a mock at a regular interval (e.g., daily). That is, the temporary database or CDS (1612) can be updated at a preset interval.

The shuttle (1611) can update the table (1631) of the CDS (1612) by subscribing to the state (1607) through the state Kafka (1606). The mock creation interface (1602) can update the table (1630) of the RDS (1610) by subscribing to the state (1609) through the state Kafka (1610).

BUSINESS_SIGNAL of tables (1630, 1631) may correspond to the creation subject identifier (320) shown in Fig. 3b, and ID_TYPE may correspond to the type of specific identification information of Fig. 3b, i.e., the identifier type (330). ID and BUSINESS_CONTENTS may mean the key and value shown in Fig. 3a. For example, the key 10001 of B1.txt (305) of Fig. 3a may correspond to ID, and the value {"bsr_rank": "1", "bsr_limit": false} may correspond to BUSINESS_CONTENTS. BUSINESS_CONTENTS may include a string in JSON format.

STATUS can indicate the status of the temporary database or CDS (1612) being updated based on a node or at least one data file. For example, if STATUS is CONFIRMED, it can indicate that the temporary database or CDS (1612) has already been updated, if STATUS is WAITING, it can indicate that the temporary database or CDS (1612) is waiting for an update, and if STATUS is FAILED, it can indicate that the update of the temporary database or CDS (1612) has 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 notified to the user (1600). That is, in one embodiment, the electronic device (100) can provide a notification (e.g., a cleanup notification) for each of the cases where it confirms a request for an update operation of a temporary database, confirms the start of an update operation, and confirms the completion of an update operation.

The shuttle (1611) may obtain second data from the cache (1613) or the CDS (1612) according to the 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 a response (1633) and transmit it to the serving layer (1616). The second data may be included in the response (1632) together with the first data. At this time, the mocking handler (1615) may intervene and replace the response if the signal is of the MOCK type. The MOCK type signal may be a type of specific identification information used to test the operation of the method according to the present disclosure. Each mocking handler (1620) can intervene in the listing API (1617), search API (1618), and promotion API (1619) of the serving layer (1616) to process a response to a signal of the MOCK type.

Fig. 17 illustrates one embodiment of a method according to the present disclosure. Each component shown in Fig. 17 may correspond to a component of the same name described in Figs. 1 to 16.

In one embodiment, a user (1700) can upload at least one data file to a file database or S3 (1706) through an ad hoc UI (1703) of an ad hoc service (1702). At this time, file information (1730) stored in a file information database (1705) can be updated through the ad hoc UI (1703).

The ad hoc UI (1703) can trigger the data extractor (1707) by calling an API. The data extractor (1707) can reference at least one data file from the file database or S3 (1706) to update a table (1731) of the temporary database or CDS (1710). The cleanup scheduler (1704) can trigger the ad hoc UI (1703) to call the data extractor (1707) at a regular interval (e.g., daily). That is, the temporary database or CDS (1710) can be updated at a preset interval.

In one embodiment, the temporary database or CDS (1710) may be updated when a file in the file database or S3 (1706) is 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) may identify at least one data file that has been added, deleted, or updated from the file database or S3 (1706) and update a table (1731) in the temporary database or CDS (1710) corresponding to the at least one data file that has been added, deleted, or updated (add, delete, or update a row or column in the table (1731)). At this time, in order to prevent the update of the table (1731) of the temporary database or CDS (1710) from being missed, the cleanup scheduler (1704), the ad hoc service (1702), or the ad hoc UI (1703) can check at regular intervals (preferably, every morning) whether the update of the table (1731) of the temporary database or CDS (1710) is missed, and call the data extractor (1707) to update the table (1731) of the temporary database or CDS (1710).

In one embodiment, the temporary database or CDS (1710) may be updated when a file in the file database or S3 (1706) is added, deleted, or updated. The ad hoc UI (1703) may check whether a file in the file database or S3 (1706) is added, deleted, or updated at a preset interval (e.g., once every several minutes to tens of minutes, preferably once every 10 minutes) and call an API to trigger the data extractor (1707). The data extractor (1707) may check at least one data file added, deleted, or updated from the file database or S3 (1706) and update a table (1731) of the temporary database or CDS (1710) corresponding to the at least one data file added, deleted, or updated (add, delete, or update a row or column of the table (1731). At this time, in order to prevent the update of the table (1731) of the temporary database or CDS (1710) from being missed, the cleanup scheduler (1704), the ad hoc service (1702), or the ad hoc UI (1703) can check at regular intervals (preferably, every morning) whether the update of the table (1731) of the temporary database or CDS (1710) is missed, and call the data extractor (1707) to update the table (1731) of the temporary database or CDS (1710).

The data extractor (170) can update the cache (1711) together with the cache updater (1708). The update of the cache (1711) can be performed by the user (1700). The user (1700) can input specific identification information through the ad hoc UI (1703), and the data extractor (1707) can store data (e.g., key-value of at least one data file) corresponding to the specific identification information in the cache (1711) in response to the user's input through the cache updater (1708). Thereafter, second data corresponding to the specific identification information can be provided from the cache (1711) to the object data provision API (1712). After the data is provided from the cache (1711) to the object data provision API (1712), the data corresponding to the specific identification information can be deleted from the cache. That is, in one embodiment, when one or more pieces of specific identification information are confirmed, the data corresponding to the specific identification information can 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 the tables (510, 520, 530) shown in Fig. 5.

The title of the file information (1730) and the BUSINESS_SIGNAL of the table (1731) may correspond to the creator identifier (320) shown in Fig. 3b, and ID_TYPE may correspond to the type of specific identification information of Fig. 3b, i.e., the identifier type (330). ID and BUSINESS_CONTENTS may mean the key and value shown in Fig. 3a. For example, the key 10001 of B1.txt (305) of Fig. 3a may correspond to ID, and the value {"bsr_rank": "1", "bsr_limit": false} may correspond to BUSINESS_CONTENTS. BUSINESS_CONTENTS may include a string in JSON format.

The shuttle (1709) may obtain second data from the cache (1711) or the CDS (1710) according to the 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 a 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. At this time, the mocking handler (1713) may intervene and replace the response if the signal is of the MOCK type. The MOCK type signal may be a type of specific identification information used to test the operation of the method according to the present disclosure. Each mocking handler (1718) can intervene in the listing API (1715), search API (1716), and promotion API (1717) of the serving layer (1714) to process responses to signals of the MOCK type.

Fig. 18 illustrates an operating method of an electronic device (100) according to one embodiment. For each step of the operating method of Fig. 18, descriptions of the same content as the operation of the processor (110) described in Figs. 1 to 17 will be omitted.

In step S1810, 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 on to the item data provision API.

In step S1820, the electronic device (100) can obtain first data from the main database based on the first data request. Specifically, the item data provision API can obtain first data from the main database based on the first data request.

In step S1830, the electronic device (100) may obtain second data from a temporary database based on the first data request. Specifically, the item data provision 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 identification information regarding a specific object. The shuttle may obtain a row value and column information (creation subject identifier) corresponding to the specific identification information from a table according to the type of the specific identification information in the temporary database based on the specific identification information of the second data request, and obtain the second data based on the same. The second data may be data in a json format.

In step S1840, the electronic device (100) can transmit the first data and the second data to the front node. The front node can parse the first data and the second data to distinguish the first data and the second data, and then generate a page to be provided to the service user based on the first data and the second data.

For example, a user of the invention according to the present disclosure may need to display additional information for an item corresponding to a specific category, for example, a fashion category. At this time, since it may be difficult to modify the main database, the user may utilize an ad hoc UI of the electronic device (100) according to the present disclosure. The user may upload additional information to be provided to the front node in the form of a file through the ad hoc UI. At this time, the file may be a text file. That is, the user may upload an identifier of a fashion category (corresponding to specific identification information in the present disclosure) and information corresponding thereto in the form of a file.

The electronic device (100) can 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 it has confirmed the identifier of the fashion category from the first data, it can transmit second data including additional information corresponding to the fashion category from the temporary database to the front node together with the first data.

On the front node side, 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. The modified page can be provided to the service users.

FIG. 19 illustrates an operating method of an electronic device (100) according to one embodiment. For each step of the operating method of FIG. 19, descriptions of the same content as the operation of the processor (110) described in FIGS. 1 to 17 will be omitted.

In step S1910, the electronic device (100) can receive a first data request from the front node.

In step S1920, the electronic device (100) can obtain first data from the main database based on the first data request.

In step S1931, the electronic device (100) may transmit a second data request including specific identification information verified based on the first data to a temporary database.

In step S1932, the electronic device (100) can obtain second data from a temporary database according to a second data request.

In step S1940, the electronic device (100) can transmit first data and second data to the front node.

The 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 a non-transitory recording medium. The computer-readable recording medium or the non-transitory recording medium may include program instructions, data files, data structures, etc., alone or in combination. The program instructions recorded on the computer-readable recording medium or the non-transitory recording medium may be those specially designed and configured for the present invention or may be those known to and available to those skilled in the art of computer software. Examples of the computer-readable recording medium or the non-transitory recording medium include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical recording media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and hardware devices specially configured to store and execute program instructions such as ROMs, RAMs, flash memories, etc. Examples of the program instructions include not only machine language codes generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter, etc. The above 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.

The present embodiment may be represented by functional block configurations and various processing steps. These functional blocks may be implemented by various numbers of hardware, software, or combinations thereof to perform specific functions. For example, the embodiment may employ direct circuit configurations such as memory, processing, logic, look-up tables, etc., which may perform various functions under the control of one or more microprocessors or other control devices. Similarly to the fact that the components may be implemented as software programming or software elements, the present embodiment may be implemented in a programming or scripting language such as C, C++, Java, assembler, etc., including various algorithms implemented as a combination of data structures, processes, routines, or other programming elements. The functional aspects may be implemented as algorithms that are executed on one or more processors. In addition, the present embodiment may employ conventional techniques for electronic environment setting, signal processing, data processing, or combinations thereof.

Claims (21)

In a method for providing data in an electronic device,
A step of receiving a first data request from a front node;
A step of obtaining first data from a main database based on the first data request;
A step of obtaining second data from a temporary database based on the first data request; and
comprising a step of transmitting the first data and the second data to the front node;
The step of obtaining the above second data is
transmitting a second data request containing specific identification information to the temporary database; and
A method for providing data, comprising the step of obtaining the second data from the temporary database according to the second data request.
delete In the first paragraph,
A method of providing data, wherein the specific identification information is verified based on the first data.
In the first paragraph,
A method for providing data, wherein the second data is obtained from a table verified based on setting information obtained from a dynamic setting database according to the specific identification information in the temporary database.
In the first paragraph,
A method for providing data, wherein the second data includes at least one key-value pair corresponding to the first data request.
In a method for providing data in an electronic device,
A step of receiving a first data request from a front node;
A step of obtaining first data from a main database based on the first data request;
A step of obtaining second data from a temporary database based on the first data request; and
comprising a step of transmitting the first data and the second data to the front node;
The second data includes at least one key-value pair corresponding to the first data request,
A method for providing data, wherein the key of the above key-value pair is information that identifies the subject that created the value corresponding to the key.
In Article 6,
The above temporary database is updated based on at least one data file,
A method of providing data, wherein each of said at least one data file corresponds to information identifying said subject.
In Article 7,
A method for providing data, wherein each of said at least one data file is verified based on the format of information contained in said data file and the size of said data file.
In Article 7,
The above temporary database contains at least one table,
A method of providing data, wherein each of the at least one table is distinguished from the others based on a type of specific identifying information.
In Article 9,
Each of the above at least one table,
A method of providing data, wherein the data is updated by replacing the table with a table configured based on a work configuration file corresponding to each of the at least one table above.
In Article 7,
A method of providing data, wherein when at least one data file is uploaded, the type of specific identification information included in each data file, the type of value, whether grouped, and the data expiration date information are uploaded together.
In Article 7,
Each of the above at least one data file,
configured to be able to distinguish one or more pieces of information contained in each of said at least one data file from each other using a delimiter,
How to provide data.
In the first paragraph,
The step of transmitting to the above front node is:
A data providing method, comprising the step of transmitting the second data to the front node if the data expiration date for the second data has not expired.
In Article 13,
A method of providing data, further comprising the step of providing a notification prior to a preset period from the data expiration date.
In the first paragraph,
The step of obtaining the second data from the above temporary database is:
Comprising a step of obtaining the second data from a cache,
A method of providing data in which the above cache is updated based on a temporary database.
In Article 15,
A method of providing data, wherein when one or more specific identification pieces of information are identified, data corresponding to said specific identification pieces of information are deleted from the cache.
In the first paragraph,
A method of providing data, wherein the above temporary database is updated at a preset cycle.
In the first paragraph,
A method for providing data, further comprising the steps of providing a notification when a request for an update operation of the temporary database is confirmed, when the start of the update operation is confirmed, and when the completion of the update operation is confirmed.
In the first paragraph,
A method for providing data, comprising the step of displaying information on whether data included in the temporary database is activated.
As an electronic device,
memory in which at least one program is stored; and
By executing at least one of the above programs,
Receive the first data request from the front node,
Obtaining first data from the main database based on the first data request above,
Obtain second data from a temporary database based on the first data request above,
Including a processor that transmits the first data and the second data to the front node,
To obtain the second data, the processor,
Transmitting a second data request containing specific identifying information to said temporary database;
An electronic device that obtains the second data from the temporary database in response to the second data request.
A non-transitory computer-readable storage medium having recorded thereon a program for executing a method of providing data to an electronic device on a computer,
The above data provision method is:
A step of receiving a first data request from a front node;
A step of obtaining first data from a main database based on the first data request;
A step of obtaining second data from a temporary database based on the first data request; and
comprising a step of transmitting the first data and the second data to the front node;
The step of obtaining the above second data is
transmitting a second data request containing specific identification information to the temporary database; and
A non-transitory recording medium, comprising a step of obtaining the second data from the temporary database according to the second data request.

Images