Computer-implemented systems and methods for ai-based database parameter optimization

Abstract

A system and method are provided for database parameter optimization based on artificial intelligence (AI). One method includes: receiving a query from a user device; preprocessing the query; predicting a plurality of optimal parameters for executing the query by: calculating a predicted change in database metrics based on the preprocessed query; sending the predicted change in database metrics to a tuner; calculating a database performance metric based on the predicted change in database metrics and a current database performance metric; calculating an optimal parameter vector based on the database performance metric; and executing the received query based on the predicted plurality of optimal parameters.

Description

[Technical Field]

[0001] This disclosure generally relates to computerized systems and methods for optimizing database parameters using artificial intelligence (AI). Specifically, embodiments of this disclosure relate to innovative and unconventional systems that can automatically modify user interface elements based on user and product identifiers associated with a query by generating a model for producing a list of suggested products. [Previous Technology]

[0002] Consumers frequently shop and purchase various items online using computers and smart devices. These online shoppers often submit millions of queries daily while researching, evaluating, and purchasing multiple products. In addition, sellers register millions of products online every day. Online shopping engines that are not configured to process input from consumers or sellers can severely degrade the user experience by increasing wait times and reducing workload balancing.

[0003] The databases used in online shopping engines often involve hundreds of parameters, requiring parameter tuning for data-intensive applications. Database parameters are typically optimized based on database workload rather than query patterns. Although query-level parameter optimization exists, these methods only tune global parameters based on all client conversations and queries. Databases also require optimal workload balancing strategies to reduce data server skew. However, typical network load balancers often incur additional operational and performance costs and are unaware of internal system metrics such as the number of server threads.

[0004] Therefore, there is a need for improved methods and systems to optimize database parameters, so that consumers can quickly find and purchase products while shopping online, and sellers can quickly register their products for sale. [Summary of the Invention]

[0005] One aspect of this disclosure relates to a system for AI-based database parameter optimization. The system may include: a memory storing instructions; and at least one processor configured to execute the instructions. The instructions may include: receiving a query from a user device; preprocessing the query; predicting multiple optimal parameters for executing the query by: calculating a database metric prediction change based on the preprocessed query; sending the database metric prediction change to a tuner; calculating a database performance metric based on the database metric prediction change and a current database performance metric; calculating an optimal parameter vector based on the database performance metric; and executing the received query based on the predicted multiple optimal parameters.

[0006] Another aspect of this disclosure relates to a method for AI-based database parameter optimization. The method may include: receiving a query from a user device; preprocessing the query; predicting multiple optimal parameters for executing the query by: calculating a database metric prediction change based on the preprocessed query; sending the database metric prediction change to a tuner; calculating a database performance metric based on the database metric prediction change and a current database performance metric; calculating an optimal parameter vector based on the database performance metric; and executing the received query based on the predicted multiple optimal parameters.

[0007] Another aspect of this disclosure relates to a system for AI-based database parameter optimization. The system may include: memory storing instructions; and at least one processor configured to execute the instructions. The instructions may include: receiving a query from a user device; preprocessing the query; using a model to predict multiple optimal parameters for executing the query by: calculating a database metric prediction change using the model based on the preprocessed query; sending the database metric prediction change to a tuner; using the tuner to calculate a database performance metric based on the database metric prediction change and a current database performance metric; and using the model to calculate an optimal parameter vector based on the database performance metric; and using the tuner to execute the received query based on the predicted multiple optimal parameters. The instructions may further include: using the tuner to calculate a performance score associated with the executed query; sending the performance score to the model; and updating the network weights of the model based on the performance score.

[0008] Other systems, methods and computer-readable media are also discussed in this document.

Implementation Method

[0010] The following detailed description refers to the accompanying drawings. The same reference numerals are used as far as possible in the drawings and the following description to refer to the same or similar parts. Although several exemplary embodiments are set forth herein, various modifications, adaptations, and other implementations are possible. For example, components and steps shown in the drawings may be replaced, added, or modified, and the exemplary methods set forth herein may be modified by replacing, reordering, removing, or adding steps of the disclosed methods. Therefore, the following detailed description is not limited to the disclosed embodiments and examples. Rather, the proper scope of the invention is defined by the claims of the appended patent application.

[0011] Embodiments disclosed herein relate to systems and methods configured for AI-based database parameter optimization. The disclosed embodiments are capable of initializing a user's client-side dialogue variables at connection time, and then customizing predicted optimal parameters based on the client-side dialogue context. The metric repository system can preprocess queries by characterizing the queries. In some embodiments, the model system can use a model to predict multiple optimal parameters for executing the query. Optimal parameters may include at least one of client-side dialogue database parameters, client-side dialogue connection pool parameters, client-side dialogue workload balancing parameters, or data partitioning parameters.

[0012] In some embodiments, the model system may predict optimal parameters by using a model to calculate database metric prediction changes based on a preprocessed query. For example, the model system may predict the difference in database metrics from before the query is executed to after the query is executed. In some embodiments, the model system may send the database metric prediction changes to a tuner system. The tuner system may calculate database performance metrics based on the database metric prediction changes and current database performance metrics. For example, the tuner system may calculate database performance metrics by retrieving current (e.g., real-time) database performance metrics from the system and adding the database metric prediction changes to the current database performance metrics.

[0013] In some embodiments, the model system may compute an optimal parameter vector based on the computed database performance metric. The tuner system may push the optimal parameters to the application and execute queries based on the predicted optimal parameters, thereby executing queries using client-specific optimal parameters and modifying client-specific parameters at runtime. In some embodiments, the tuner system may compute a performance score associated with the executed query. For example, the performance score may be computed by determining the change in database performance metric resulting from the executed query. In some embodiments, the tuner system may send the performance score to the model system, and the model system may update the network weights of the model based on the performance score.

[0014] Referring to FIG1A, FIG1A shows a schematic block diagram 100 illustrating an exemplary embodiment of a system including a computerized system for enabling communication in shipping, transportation, and logistics operations. As shown in FIG1A, system 100 may include various systems, each of which may be connected to each other via one or more networks. The systems may also be connected to each other via direct connection (e.g., using cables). The illustrated systems include a shipment authority technology (SAT) system 101, an external front-end system 103, an internal front-end system 105, a transportation system 107, mobile devices 107A, 107B, and 107C, a seller's entry point 109, a shipment and order tracking (SOT) system 111, a fulfillment optimization (FO) system 113, a fulfillment messaging gateway (FMG) 115, a supply chain management (SCM) system 117, a warehouse management system (WMS) 119, mobile devices 119A, 119B, and 119C (illustrated as being located within a fulfillment center (FC)) 200), third-party fulfillment (3PL) systems 121A, 121B, and 121C, a fulfillment center authorization system (FC Auth) 123, and a labor management system. system (LMS) 125.

[0015] In some embodiments, the SAT system 101 may be implemented as a computer system for monitoring order status and delivery status. For example, the SAT system 101 may determine whether an order has exceeded its Promised Delivery Date (PDD) and may take appropriate actions, including initiating a new order, reshipping items from an undelivered order, canceling an undelivered order, and initiating contact with the ordering customer. The SAT system 101 may also monitor other data, including outputs (e.g., the number of packages shipped during a specific time period) and inputs (e.g., the number of empty cartons received for shipment). The SAT system 101 may also act as a gateway between different devices in the system 100, enabling communication between devices such as the external front-end system 103 and the FO system 113 (e.g., using store-and-forward or other technologies).

[0016] In some embodiments, the external front-end system 103 may be implemented as a computer system that enables external users to interact with one or more systems in system 100. For example, in embodiments where system 100 can present the system to enable users to place orders for items, the external front-end system 103 may be implemented as a web server that receives search requests, presents item pages, and requests payment information. For example, the external front-end system 103 may be implemented as one or more computers running software such as Apache Hypertext Transfer Protocol (HTTP) servers, Microsoft Internet Information Services (IIS), NGINX, etc. In other embodiments, the external front-end system 103 may run custom web server software designed to receive and process requests from external devices (e.g., mobile device 102A or computer 102B), retrieve information from databases and other data storage based on these requests, and provide a response to the received requests based on the retrieved information.

[0017] In some embodiments, the external front-end system 103 may include one or more of a web caching system, a database, a search system, or a payment system. In one embodiment, the external front-end system 103 may include one or more of these systems, while in another embodiment, the external front-end system 103 may include an interface (e.g., server-to-server, database-to-database, or other network connection) connected to one or more of these systems.

[0018] A set of exemplary steps illustrated by Figures 1B, 1C, 1D, and 1E will help illustrate some operations of the external front-end system 103. The external front-end system 103 may receive information from systems or devices within system 100 for presentation and / or display. For example, the external front-end system 103 may host or provide one or more web pages, including a Search Results Page (SRP) (e.g., Figure 1B), a Single Details Page (SDP) (e.g., Figure 1C), a Shopping Cart Page (e.g., Figure 1D), or an Order Page (e.g., Figure 1E). A user device (e.g., using mobile device 102A or computer 102B) may navigate to the external front-end system 103 and request a search by entering information in a search box. The external front-end system 103 may request information from one or more systems within system 100. For example, the external front-end system 103 may request information from system 113 to satisfy a search request. External front-end system 103 may also request and receive the promised delivery date, or "PDD," for each product included in the search results (from FO system 113). In some embodiments, PDD may represent an estimate of when the package containing the product will arrive at the user's desired location, or the date on which the product is promised delivery to the user's desired location if ordered within a specific time period (e.g., before the end of the day (11:59 PM)). (PDD is further discussed below with reference to FO system 113.)

[0019] The external front-end system 103 may prepare an SRP based on the information (e.g., Figure 1B). The SRP may include information that satisfies the search request. For example, this may include images of products that satisfy the search request. The SRP may also include the corresponding price for each product, or information related to enhanced delivery options, PDD, weight, size, offers, discounts, etc., for each product. The external front-end system 103 may send the SRP to the user device that made the request (e.g., via a network).

[0020] The user device can then select a product from the SRP, for example, by clicking or tapping the user interface (or using another input device). The user device can make a request for information about the selected product and send it to the external front-end system 103. In response, the external front-end system 103 can request information related to the selected product. For example, the information may include additional information beyond what is presented for the product on the corresponding SRP. This additional information may include, for example, shelf life, country of origin, weight, size, number of items in the package, handling instructions, or other information about the product. The information may also include recommendations for similar products (e.g., based on massive data and / or machine learning analysis of customers who have purchased this product and at least one other product), answers to frequently asked questions, customer reviews, manufacturer information, images, etc.

[0021] The external front-end system 103 can prepare a Single Detail Page (SDP) (e.g., Figure 1C) based on the received product information. The SDP may also include other interactive elements such as a "Buy Now" button, an "Add to Cart" button, a quantity field, item images, etc. The SDP may further include a list of sellers offering the product. The list may be sorted based on the price offered by each seller, so that the seller offering the product at the lowest price can be listed at the top. The list may also be sorted based on seller ranking, so that the highest-ranked seller can be listed at the top. Seller ranking may be based on a variety of factors, including, for example, the seller's past track record of fulfilling the promised PDD. The external front-end system 103 can deliver the SDP to the requesting user device (e.g., via the internet).

[0022] The user device that makes the request can receive an SDP listing product information. After receiving the SDP, the user device can then interact with it. For example, the user of the user device that makes the request can click the "Add to Cart" button on the SDP or otherwise interact with the "Add to Cart" button on the SDP. This will add the product to the shopping cart associated with the user. The user device can send this request to the external front-end system 103 to add the product to the shopping cart.

[0023] The external front-end system 103 may generate a shopping cart page (e.g., FIG. 1D). In some embodiments, the shopping cart page lists products that have been added to a virtual "shopping cart" by the user. The user device may request the shopping cart page by clicking an icon on an SRP, SDP, or other page, or by otherwise interacting with an icon on an SRP, SDP, or other page. In some embodiments, the shopping cart page may list all products that have been added to the shopping cart by the user, as well as information about the products in the shopping cart, such as the quantity of each product, the unit price of each product, the price of each product based on the associated quantity, information about PDD, delivery method, shipping cost, user interface elements for modifying products in the shopping cart (e.g., deleting or modifying the quantity), options for ordering other products or setting up recurring delivery of products, options for setting up interest payments, user interface elements for continuing to purchase, etc. The user on the user device may click a user interface element (e.g., a button read as "Buy Now") or otherwise interact with a user interface element (e.g., a button read as "Buy Now") to initiate a purchase of products in the shopping cart. In doing so, the user device can send such a purchase request to the external front-end system 103.

[0024] The external front-end system 103 may generate an order page (e.g., FIG. 1E) in response to receiving a request to initiate a purchase. In some embodiments, the order page relists the items from the shopping cart and requests input of payment and shipping information. For example, the order page may include user interface elements that request information about the purchaser of the items in the shopping cart (e.g., name, address, email address, phone number), information about the recipient (e.g., name, address, phone number, delivery information), shipping information (e.g., delivery and / or collection speed / method), payment information (e.g., credit card, bank transfer, cheque, stored credit), and requests for a cash receipt (e.g., for tax purposes). The external front-end system 103 may send the order page to the user device.

[0025] The user device can enter information on the order page and click on the user interface element that sends the information to the external front-end system 103, or otherwise interact with the user interface element that sends the information to the external front-end system 103. The external front-end system 103 can send information from the user interface element to different systems in system 100, so that new orders can be created and processed with the products in the shopping cart.

[0026] In some embodiments, the external front-end system 103 may be further configured to enable the seller to transmit and receive information related to the order.

[0027] In some embodiments, the internal front-end system 105 may be implemented as a computer system that enables internal users (e.g., employees of an organization that owns, operates, or leases system 100) to interact with one or more systems within system 100. For example, in embodiments where system 101 can present the system to enable users to place orders for items, the internal front-end system 105 may be implemented as a web server that allows internal users to view diagnostic and statistical information about orders, modify item information, or check statistics related to orders. For example, the internal front-end system 105 may be implemented as one or more computers running software such as Apache HTTP Server, Microsoft Internet Information Services (IIS), NGINX, etc. In other embodiments, the internal front-end system 105 may run custom web server software, which is designed to receive and process requests from systems or devices (and other devices not shown) illustrated in system 100, retrieve information from databases and other data storage based on such requests, and provide responses to the received requests based on the retrieved information.

[0028] In some embodiments, the internal front-end system 105 may include one or more of a website caching system, a database, a search system, a payment system, an analytics system, an order monitoring system, etc. In one embodiment, the internal front-end system 105 may include one or more of these systems, while in another embodiment, the internal front-end system 105 may include an interface (e.g., server-to-server, database-to-database, or other network connection) connected to one or more of these systems.

[0029] In some embodiments, the transport system 107 may be implemented as a computer system enabling communication between systems or devices in system 100 and mobile devices 107A to 107C. In some embodiments, the transport system 107 may receive information from one or more mobile devices 107A to 107C (e.g., mobile phones, smartphones, personal digital assistants (PDAs), etc.). For example, in some embodiments, mobile devices 107A to 107C may include devices operated by a delivery worker. The delivery worker (who may be a permanent, temporary, or shift employee) may use mobile devices 107A to 107C to deliver packages containing products ordered by a user. For example, to deliver packages, the delivery worker may receive notifications on the mobile device instructing which package to deliver and where to deliver the package. Upon arrival at the delivery location, the delivery worker may use a mobile device to locate the package (e.g., in the back of a truck or in a crate), scan or otherwise capture information associated with identifiers on the package (e.g., barcodes, images, body text strings, radio frequency identification (RFID) tags, etc.), and deliver the package (e.g., by leaving the package at the front door, leaving it with a security guard, handing it over to the recipient, etc.). In some embodiments, the delivery worker may use a mobile device to capture a photograph of the package and / or obtain a signature. The mobile device may send information to the transportation system 107, including information about the delivery, such as time, date, Global Positioning System (GPS) location, photograph, identifiers associated with the delivery worker, identifiers associated with the mobile device, etc. The transportation system 107 may store this information in a database (not shown) for access by other systems in system 100. In some embodiments, the transportation system 107 may use this information to prepare tracking data and send the tracking data to other systems indicating the location of a specific package.

[0030] In some embodiments, some users may use one type of mobile device (e.g., permanent workers may use a dedicated PDA with custom hardware such as a barcode scanner, stylus, and other devices), while other users may use other types of mobile devices (e.g., temporary workers or shift workers may use readily available mobile phones and / or smartphones).

[0031] In some embodiments, the transportation system 107 may associate a user with each device. For example, the transportation system 107 may store associations between users (represented by, for example, user identifiers, employee identifiers, or telephone numbers) and mobile devices (represented by, for example, International Mobile Equipment Identity (IMEI), International Mobile Subscription Identifier (IMSI), telephone number, Universal Unique Identifier (UUID), or Globally Unique Identifier (GUID)). The transportation system 107 may use such associations, in conjunction with data received at the time of delivery, to analyze data stored in a database to determine, among other things, the worker's location, worker efficiency, or worker speed.

[0032] In some embodiments, seller entry 109 may be implemented as a computer system that enables a seller or other external entity to communicate electronically with one or more systems in system 100. For example, a seller may use a computer system (not shown) to upload or provide product information, order information, contact information, etc., for products that the seller wishes to sell through system 100 using seller entry 109.

[0033] In some embodiments, the shipping and order tracking system 111 may be implemented as a computer system that receives, stores, and transmits information about the location of packages containing products ordered by customers (e.g., users of devices 102A to 102B). In some embodiments, the shipping and order tracking system 111 may request or store information from a website server (not shown) operated by a shipping company that delivers packages containing products ordered by customers.

[0034] In some embodiments, the shipping and order tracking system 111 may request and store information from the systems depicted in system 100. For example, the shipping and order tracking system 111 may request information from transportation system 107. As discussed above, transportation system 107 may receive information from one or more mobile devices 107A to 107C (e.g., mobile phones, smartphones, PDAs, etc.) associated with one or more of the user (e.g., delivery workers) or vehicle (e.g., delivery trucks). In some embodiments, the shipping and order tracking system 111 may also request information from warehouse management system (WMS) 119 to determine the location of individual products within a fulfillment center (e.g., fulfillment center 200). The shipping and order tracking system 111 may request data from one or more of transportation system 107 or WMS 119, process it, and present it to devices (e.g., user devices 102A and 102B) upon request.

[0035] In some embodiments, the Fulfillment Optimization (FO) system 113 may be implemented as a computer system that stores information about customer orders from other systems (e.g., external front-end system 103 and / or shipping and order tracking system 111). The FO system 113 may also store information describing where specific items are accommodated or stored. For example, some items may be stored in only one fulfillment center, while others may be stored in multiple fulfillment centers. In still other embodiments, some fulfillment centers may be designed to store only a specific set of items (e.g., fresh produce or frozen product). The FO system 113 stores this information along with associated information (e.g., quantity, size, receipt date, expiration date, etc.).

[0036] The FO system 113 can also calculate a corresponding Promised Delivery Date (PDD) for each product. In some embodiments, the PDD may be based on one or more factors. For example, the FO system 113 may calculate the PDD for a product based on: past demand for the product (e.g., how many times the product has been ordered over a period of time), expected demand for the product (e.g., how many customers are expected to order the product in the upcoming period of time), total network past demand indicating how many products have been ordered over a period of time, total network expected demand indicating how many products are expected to be ordered in the upcoming period of time, one or more counts of products stored in each fulfillment center 200, which fulfillment center stores each product, expected orders or current orders for the product, etc.

[0037] In some embodiments, the FO system 113 may periodically (e.g., hourly) determine the PDD for each product and store it in a database for retrieval or transmission to other systems (e.g., external front-end system 103, SAT system 101, shipping and order tracking system 111). In other embodiments, the FO system 113 may receive electronic requests from one or more systems (e.g., external front-end system 103, SAT system 101, shipping and order tracking system 111) and calculate the PDD on demand.

[0038] In some embodiments, the fulfillment message gateway (FMG) 115 may be implemented as a computer system that receives requests or responses in one format or protocol from one or more systems in system 100 (e.g., FO system 113), converts them into another format or protocol, and forwards them in the converted format or protocol to other systems such as WMS 119 or third-party fulfillment systems 121A, 121B or 121C, and vice versa.

[0039] In some embodiments, the supply chain management (SCM) system 117 may be implemented as a computer system performing forecasting functions. For example, the SCM system 117 may forecast the demand level for a particular product based on, for example, past demand for the product, expected demand for the product, past demand across the entire network, expected demand across the entire network, product counts stored in each fulfillment center 200, expected orders for each product, or current orders. In response to such forecast levels and the quantity of each product in all fulfillment centers, the SCM system 117 may generate one or more purchase orders to procure and store sufficient quantities to meet the forecasted demand for a particular product.

[0040] In some embodiments, the warehouse management system (WMS) 119 may be implemented as a computer system for monitoring workflows. For example, the WMS 119 may receive event data from individual devices (e.g., devices 107A to 107C or 119A to 119C) that indicate discrete events. For example, the WMS 119 may receive event data indicating that one of these devices should be used to scan a package. As discussed below with reference to fulfillment center 200 and FIG2, during the fulfillment process, package identifiers (e.g., barcode or RFID tag data) may be scanned or read at specific stages by machines (e.g., automated barcode scanners or handheld barcode scanners, RFID readers, high-speed cameras, devices such as tablet 119A, mobile device / PDA 119B, computer 119C, etc., or similar devices). WMS 119 can store each event of scanning or reading the indication of the package identifier, along with the package identifier, time, date, location, user identifier, or other information, in a corresponding database (not shown), and can provide this information to other systems (e.g., shipping and order tracking system 111).

[0041] In some embodiments, WMS 119 may store information that associates one or more devices (e.g., devices 107A to 107C or 119A to 119C) with one or more users associated with system 100. For example, in some cases, the association between a user (e.g., a part-time or full-time employee) and a mobile device may be that the user owns the mobile device (e.g., the mobile device is a smartphone). In other cases, the association between a user and a mobile device may be that the user temporarily holds the mobile device (e.g., the user registers to lend out the mobile device at the beginning of the day, will use the mobile device during the day, and will return the mobile device at the end of the day).

[0042] In some embodiments, WMS 119 may maintain a work log for each user associated with system 100. For example, WMS 119 may store information associated with each employee, including any assigned processes (e.g., unloading trucks, picking items in self-pickup areas, rebin wall work, packing items), user identifier, location (e.g., floor or area in fulfillment center 200), number of units the employee moves through in the system (e.g., number of items picked, number of items packed), identifier associated with devices (e.g., devices 119A to 119C), etc. In some embodiments, WMS 119 may receive check-in and check-out information from a timing system, such as a timing system operating on devices 119A to 119C.

[0043] In some embodiments, third-party fulfillment (3PL) systems 121A to 121C represent computer systems associated with a third-party provider of logistics and products. For example, while some products are stored in fulfillment center 200 (as discussed below with reference to FIG2), others may be stored off-site, produced on demand, or otherwise not stored in fulfillment center 200. 3PL systems 121A to 121C may be configured to receive orders from FO system 113 (e.g., via FMG 115) and may provide products and / or services (e.g., delivery or installation) directly to customers. In some embodiments, one or more of 3PL systems 121A to 121C may be part of system 100, while in other embodiments, one or more of 3PL systems 121A to 121C may be outside of system 100 (e.g., owned or operated by a third-party provider).

[0044] In some embodiments, the Fulfillment Center Authorization System (FC Auth) 123 may be implemented as a computer system with various functionalities. For example, in some embodiments, FC Auth 123 may act as a single-sign-on (SSO) service for one or more other systems within System 100. For example, FC Auth 123 may enable a user to log in via an internal front-end system 105, determine that the user has similar privileges to access resources at the shipping and order tracking system 111, and enable the user to access those privileges without requiring a second login process. In other embodiments, FC Auth 123 may enable a user (e.g., an employee) to associate themselves with a specific task. For example, some employees may not have electronic devices (e.g., devices 119A to 119C) but may instead move between tasks and zones within Fulfillment Center 200 during the day. FC Auth 123 may be configured to allow these employees to indicate what tasks they are performing and which zones they are in at different times of the day.

[0045] In some embodiments, the Labor Relations Management System (LMS) 125 may be implemented as a computer system that stores attendance and overtime information of employees (including full-time and part-time employees). For example, the LMS 125 may receive information from FC Auth 123, WMS 119, devices 119A to 119C, transportation system 107 and / or devices 107A to 107C.

[0046] The specific configuration illustrated in Figure 1A is merely an example. For instance, although Figure 1A illustrates FC Auth system 123 connected to FO system 113, not all embodiments require this specific configuration. In fact, in some embodiments, the systems in system 100 may be connected to each other via one or more public or private networks, including: the Internet, an Intranet, a Wide-Area Network (WAN), a Metropolitan-Area Network (MAN), a wireless network conforming to the Institute of Electrical and Electronic Engineers (IEEE) 802.11a / b / g / n standards, leased lines, etc. In some embodiments, one or more of the systems in system 100 may be implemented as one or more virtual servers implemented in a data center, server farm, etc.

[0047] Figure 2 illustrates a fulfillment center 200. A fulfillment center 200 is an example of a physical location where items ordered and shipped to a customer are stored. A fulfillment center (FC) 200 may be divided into multiple zones, each of which is illustrated in Figure 2. In some embodiments, these "zones" may be considered as virtual divisions between different stages of the processes of receiving, storing, retrieving, and shipping items. Therefore, although "zones" are illustrated in Figure 2, other divisions of zones may exist, and in some embodiments, the zones in Figure 2 may be omitted, copied, or modified.

[0048] The receiving area 203 represents the area in which a seller of FC 200 who wishes to sell products from system 100 of Figure 1A receives items. For example, the seller may use truck 201 to deliver items 202A and 202B. Item 202A may represent a single item large enough to occupy its own shipping pallet, while item 202B may represent a group of items stacked together on the same pallet to save space.

[0049] Workers will receive items in the receiving area 203 and may optionally check for damage and correctness of the items using a computer system (not shown). For example, workers may use the computer system to compare the quantities of items 202A and 202B with the ordered quantities. If the quantities do not match, the worker may reject one or more of items 202A or 202B. If the quantities match, the worker may move these items (using, for example, a trolley, handcart, forklift, or manually) to a buffer zone 205. Buffer zone 205 may serve as a temporary storage area for items not currently needed in the picking area (e.g., due to a sufficient quantity of these items in the picking area to meet pre-ordered demand). In some embodiments, forklift 206 is operated to move items around in buffer zone 205 and between receiving area 203 and unloading area 207. If item 202A or 202B is needed in the picking area (e.g., due to forecasted demand), the forklift can move item 202A or 202B to the unloading area 207.

[0050] Unloading area 207 may be an area of ​​FC 200 where items are stored before being moved to picking area 209. A worker assigned a picking task ("picker") may approach items 202A and 202B in the picking area, scan the barcodes of the picking area using a mobile device (e.g., device 119B), and scan the barcodes associated with items 202A and 202B. The picker may then take the items to picking area 209 (e.g., by placing the items on a cart or by moving the items).

[0051] Picking area 209 may be an area of ​​FC 200 where items 208 are stored on storage unit 210. In some embodiments, storage unit 210 may include one or more of physical shelving, bookshelves, boxes, shipping containers, refrigerators, freezers, cold storage, etc. In some embodiments, picking area 209 may be organized into multiple floors. In some embodiments, workers or machines may move items to picking area 209 by various means, including forklifts, elevators, conveyors, trolleys, handcarts, automated robots or devices, or manual methods. For example, a picker may place items 202A and 202B on a handcart or trolley in unloading area 207 and walk to picking area 209.

[0052] The picker may receive an instruction to place (or "stow") an item in a specific location (e.g., a specific space on storage unit 210) within the picking area 209. For example, the picker may use a mobile device (e.g., device 119B) to scan item 202A. The device may, for example, use a system indicating aisles, shelves, and locations to instruct the picker where item 202A should be stored. Then, before storing item 202A in this location, the device may prompt the picker to scan the barcode at this location. The device may send (e.g., via a wireless network) data to a computer system (e.g., WMS 119 in FIG. 1A) to indicate that item 202A has been stored at the location by the user using device 119B.

[0053] Once a user places an order, the picker can receive instructions on device 119B to retrieve one or more items 208 from storage unit 210. The picker can retrieve item 208, scan the barcode on item 208, and place it on transport mechanism 214. Although transport mechanism 214 is represented as a slider, in some embodiments, transport mechanism may be implemented as one or more of conveyor belts, elevators, pallet trucks, forklifts, handcarts, trolleys, and other similar devices. Item 208 can then reach packaging area 211.

[0054] Packaging area 211 is an area for receiving items from the self-picking area 209 of FC 200 and packing the items into boxes or bags for final shipment to the customer. In packaging area 211, workers assigned to receive items ("rebin workers") will receive items 208 from self-picking area 209 and determine which order item 208 corresponds to. For example, the rebin worker can use a device such as computer 119C to scan the barcode on item 208. Computer 119C can visually indicate which order item 208 is associated with. For example, this may include spaces or "cells" on wall 216 corresponding to orders. Once an order is completed (e.g., since the cell contains all the items in the order), the rebin worker can indicate to the packer (or "packer") that the order is complete. The packer can retrieve the items from the cell and place them into boxes or bags for shipment. Next, the packer may send the boxes or bags to hub zone 213, for example by forklift, pallet truck, trolley, handcart, conveyor belt, manual or other means.

[0055] Central area 213 may be the area where the self-packaging area 211 of FC 200 receives all boxes or bags ("packages"). Workers and / or machines in central area 213 may pick up packages 218 and determine which part of the delivery area each package is intended to go to, and route the package to the appropriate camp area 215. For example, if the delivery area has two smaller sub-areas, the package will go to one of the two camp areas 215. In some embodiments, workers or machines may scan the package (e.g., using one of devices 119A to 119C) to determine its final destination. Routing the package to camp area 215 may include, for example, determining part of a geographic area that is the destination of the package (e.g., based on a postal code), and determining the camp area 215 associated with said part of said geographic area.

[0056] In some embodiments, camp area 215 may include one or more buildings, one or more physical spaces, or one or more areas, wherein packages are received from central area 213 for sorting into routes and / or subroutines. In some embodiments, camp area 215 is physically separate from FC 200, while in other embodiments, camp area 215 may form part of FC 200.

[0057] Workers and / or machines in camp area 215 may determine which route and / or sub-route a package 220 should be associated with, for example, based on a comparison of the destination with existing routes and / or sub-routes, a calculation of the workload for each route and / or sub-route, the time of day, the shipping method, the cost of shipping package 220, the PDD associated with the items in package 220, etc. In some embodiments, workers or machines may scan the package (e.g., using one of devices 119A to 119C) to determine its final destination. Once package 220 is assigned to a specific route and / or sub-route, workers and / or machines may move the package 220 to be shipped. In exemplary Figure 2, camp area 215 includes truck 222, vehicle 226, and delivery workers 224A and 224B. In some embodiments, truck 222 may be driven by delivery worker 224A, who is a full-time employee delivering packages for FC 200, and truck 222 is owned, leased, or operated by the same company that owns, leases, or operates FC 200. In some embodiments, vehicle 226 may be driven by delivery worker 224B, who is a "flexible" or occasional worker who makes deliveries on demand (e.g., seasonally). Vehicle 226 may be owned, leased, or operated by delivery worker 224B.

[0058] Referring to FIG3, FIG3 illustrates an exemplary network for an apparatus and system for AI-based database parameter optimization. As shown in FIG3, system 300 may include application 301, database 302, database 303, metric collector system 304, metric store system 305, model system 306, test database 307, and tuner system 308. Application 301 may communicate via a network with user device 320 associated with user 320A or other components of system 300. In some embodiments, application 301 may communicate with other components of system 300 via a direct connection (e.g., using a cable). In some other embodiments, system 300 may be part of system 100 shown in FIG1A and may communicate with other components of system 100 via a network or via a direct connection (e.g., using a cable). Application 301 may include a single computer or may be configured to each include a distributed computer system comprising multiple computers that interoperate to perform one or more of the processes and functions associated with the disclosed examples. In some embodiments, application 301 may include client components implemented using a specific language (e.g., Java) and protocol to communicate with external front-end system 103 and other components of system 100 or 300.

[0059] System 300 may include at least one processor, which may be one or more known processing devices, such as microprocessors from the Pentium™ series manufactured by Intel™ or the Turion™ series manufactured by Advanced Micro Devices™ (AMD™). The processor may be configured as a single-core or multi-core processor that executes parallel processes simultaneously. For example, the processor may use a logical processor to execute and control multiple processes simultaneously. The processor may implement virtual machine technology or other known technologies to provide the ability to execute, control, run, manipulate, store, etc., multiple software processes, applications, programs, etc. In another instance, the processor may include a multi-core processor arrangement configured to provide parallel processing capabilities, enabling system 300 to execute multiple processes simultaneously. Those skilled in the art will understand that other types of processor arrangements providing the capabilities disclosed herein can be implemented.

[0060] System 300 may include at least one memory, which may be stored in one or more operating systems that perform known operating system functions when executed by a processor. By way of example, the operating system may include Microsoft Windows, Unix, Linux, Android, Macintosh operating system (Mac OS), Apple operating system (iOS), or other types of operating systems. Therefore, embodiments of the disclosed invention can operate and function with computer systems running any type of operating system. The memory may be volatile or non-volatile, magnetic, semiconductor, magnetic tape, optical, removable, non-removable, or other types of storage devices or physical computer-readable media.

[0061] Databases 302, 303, or 307 may include, for example, Oracle™ databases, Sybase™ databases, or other relational or non-relational databases, such as Hadoop™ sequence archives, HBase™ databases, or Cassandra™ databases. In some embodiments, system 300 may include additional databases. Databases 302, 303, or 307 may include computing components (e.g., a database management system, a database server, etc.) configured to receive and process requests for data stored in the database's memory and to provide data from the database. Databases 302, 303, or 307 may include NoSQL databases, such as HBase™ databases, MongoDB™, or Cassandra™. Alternatively, databases 302, 303, or 307 may include relational databases, such as Oracle, MySQL, and Microsoft Structured Query Language (SQL) servers. In some embodiments, databases 302, 303, or 307 may take the form of a server, a general-purpose computer, a mainframe computer, or any combination of these components.

[0062] Databases 302, 303, or 307 may store data that can be used by a processor to implement methods and processes associated with the disclosed instances. As shown in FIG3, databases 302, 303, or 307 may be located in system 300, or alternatively, databases 302, 303, or 307 may be located in an external storage device outside of system 330 and query system 300. The data stored in databases 302 or 303 may include queries, query plans, query patterns (e.g., select_name_from_user_where_email = ?), query parameters, database workload parameters, optimal parameters, client session database parameters, client session connection pool parameters, client session workload balancing parameters, database metric changes, current database performance metrics, database performance metric changes, client session data, query profiling, system workload, execution plans, etc. The data stored in database 307 may include historical data, queries, query patterns, query parameters, database workload parameters, characteristic queries, optimal parameters, client-side database parameters, client-side connection pool parameters, client-side workload balancing parameters, database metric prediction changes, database metric changes, current database performance metrics, database performance metric changes, training data, training objectives, model inputs, model outputs, model network weights, error functions, performance scores, client-side data, query profiling, system workload, execution plans, etc. In some embodiments, the data stored in databases 302, 303, or 307 may include data from system 100, such as data from external front-end system 103, data from FO system 113, data from internal front-end system 105, etc.

[0063] The user device 320 may be a tablet computer, mobile device, computer, etc. The user device 320 may include a display. The display may include, for example, a liquid crystal display (LCD), a light-emitting diode screen (LED), an organic light-emitting diode screen (OLED), a touch screen, and other known display devices. The display may show various information to the user. For example, the display may display user interface elements (e.g., displayed on a webpage via an external front-end system 103 or an internal front-end system 105), which may include options for submitting queries, options for training the model, options for generating training data, options for tuning parameters, etc.

[0064] User device 320 may include one or more input / output (I / O) devices. The I / O devices may include one or more devices that enable user device 320 to send and receive information from user 320A or another device. I / O devices may include various input / output devices, cameras, microphones, keyboards, mouse-type devices, gesture sensors, motion sensors, physical buttons, oratory input, etc. I / O devices may also include one or more communication modules (not shown) for sending or receiving information within system 300 by establishing, for example, a wired or wireless connection between user device 320 and a network. In some embodiments, user device 320 may include devices of system 100, such as mobile device 102A or computer 102B.

[0065] The metric collector system 304 may collect data (e.g., historical data, queries, query patterns, query parameters, database workload parameters, characterized queries, optimal parameters, client dialogue database parameters, client dialogue connection pool parameters, client dialogue workload balancing parameters, database metric prediction changes, database metric changes, current database performance metrics, database performance metric changes, training data, training objectives, model inputs, model outputs, model network weights, error functions, performance scores, client dialogue data, query profiling, system workload, execution plans, etc.) from components of system 100 or 300 and send the data to the metric store system 305. In some embodiments, the metric store system 305 may characterize queries by analyzing query data, extracting query plans from query data, and generating vectors. In some embodiments, the metric store system 305 may characterize queries by query fingerprinting or query traffic capture. For example, query fingerprinting may include converting queries into query fingerprints. Query fingerprints are an abstraction of queries, which includes removing text values ​​and normalizing whitespace. For example, the query "user with id=6 selects name and password" can be transformed into the query fingerprint "password from user with id=?". Abstracting queries allows similar queries to be grouped together.

[0066] In some embodiments, user 320A may be an internal user (e.g., an employee of an organization that owns, operates, or leases system 100 or 300) or an external user (e.g., an online shopper).

[0067] In some embodiments, user 320A may submit a query to application 301 via user device 320 during a client conversation. For example, user 320A may use user device 320 to navigate to external front-end system 103 and request a search by entering information in a search box on a webpage delivered to external front-end system 103. External front-end system 103 may request information from one or more systems in system 100. For example, external front-end system 103 may request information from FO system 113 to satisfy the search request. In some embodiments, external front-end system 103 may prepare an SRP (e.g., FIG. 1B) based on the information. The SRP may include information to satisfy the search request. For example, this may include images of products that satisfy the search request. In some embodiments, a query may include multiple queries, or user 320A may submit multiple queries. Application 301 may generate a tuning request based on the received query and send the tuning request to tuner system 308. In some embodiments, application 301 may initialize client dialogue variables of user 320A at connection time and then customize the predicted optimal parameters based on the client dialogue context (e.g., based on query pattern, expected size of data to be returned, etc.).

[0068] The metric store system 305 may preprocess queries (e.g., transform, clean, etc.) by characterizing the queries. The metric store system 305 may characterize queries by analyzing queries, extracting query plans from queries, and generating vectors. In some embodiments, the query plan may include at least one of the following: query pattern, query parameters (e.g., tables involved in the query, cost of processing the query, query attributes, query type (e.g., insert, delete, select, update), query operation (e.g., select, join, group), etc.), or database workload parameters (e.g., the number of active connections distributed among database servers). In some embodiments, the metric store system 305 may generate a vector for each of a plurality of queries in the workload and merge the vectors to produce a single vector. In some embodiments, the metric store system 305 may generate a vector for each of a plurality of queries without merging the vectors. In some embodiments, the metric store system 305 may include a model (e.g., a deep learning model) that learns discrete values ​​of each parameter of a plurality of queries and classifies queries based on discrete configuration patterns of the queries. In some embodiments, the metric repository system 305 may characterize queries through query fingerprint analysis or query traffic capture. For example, query fingerprint analysis may include converting a query into a query fingerprint. A query fingerprint is an abstraction of a query, where abstraction includes removing literal values, normalizing whitespace, etc. For example, the query "user with id=6 selects name and password" may be converted into a query fingerprint of "password from user with id=?". Query abstraction allows similar queries to be grouped together.

[0069] In some embodiments, the model system 306 may use a model (e.g., a deep reinforcement learning model, a neural network, a bi-state deep deterministic policy gradient model, etc.) to predict multiple optimal parameters for executing a query. Optimal parameters may include at least one of the following: client-side dialogue database parameters (e.g., buffer size, cache size, working memory), client-side dialogue connection pool parameters (e.g., maximum active connections distributed across database servers), client-side dialogue workload balancing parameters (e.g., connection pool ratio per database server), or data partitioning parameters (e.g., clustering parameters). For example, optimizing client-side dialogue database parameters (e.g., buffer size) specific to a client-side dialogue can advantageously reduce latency (e.g., the buffer size is large enough that temporary files are not created on disk, but small enough that memory is not wasted). Similarly, client-side dialogue connection pool parameters, workload balancing parameters, or data partitioning parameters can be optimized to improve system performance. For example, the optimal maximum active connections for each database in system 300 can be large enough that if one database is serving a heavier workload, data can be served by another database to reduce latency and database server skew. In some embodiments, optimal data partitioning parameters may include a routing strategy that allows the optimal mechanism to be selected at runtime when data distribution changes (e.g., during migration, scaling, etc.).

[0070] In some embodiments, the model system 306 may predict optimal parameters by using a model to compute database metric prediction changes (e.g., latency, throughput, etc.) based on a preprocessed query. For example, the model system may predict the difference in database metrics from before the query is executed to after the query is executed. In some embodiments, the model system 306 may send the database metric prediction changes to the tuner system 308.

[0071] In some embodiments, the tuner system 308 may calculate the database performance metric based on the database metric prediction change and the current database performance metric. For example, the tuner system 308 may calculate the database performance metric by retrieving the current (e.g., real-time) database performance metric from the system 300 and adding the database metric prediction change to the current database performance metric.

[0072] In some embodiments, the tuner system 308 may send the calculated database performance metric to the model system 306, and the model may calculate an optimal parameter vector based on the calculated database performance metric. In some embodiments, the model system 306 may use multiple models. For example, the model system 306 may use a first model to calculate database metric prediction changes based on a preprocessed query, and use a second model to calculate the optimal parameter vector based on the calculated database performance metric. The model system 306 may input the calculated database performance metric into the model. The model system may calculate the optimal parameter vector based on the calculated database performance metric and send the optimal parameter vector to the tuner system 308. The tuner system 308 may push the optimal parameters to the application 301 and execute a query based on the predicted optimal parameters, thereby executing the query with client-specific optimal parameters and modifying client-specific parameters at runtime. In some embodiments, the tuner system 308 may calculate a performance score associated with the executed query. For example, a performance score can be calculated by determining the changes in database performance metrics resulting from the executed queries.

[0073] In some embodiments, the tuner system 308 may send a performance score to the model in the model system 306. The model system 306 may update the network weights of the model based on the performance score.

[0074] In some embodiments, the model system 306 may generate training data by retrieving data stored in databases 302, 303, or 307, the metric collector system 304, or data from the tuner system 308. In some embodiments, the model system 306 may generate training data by retrieving current client dialogue data (e.g., real-time data) from databases 302 or 303 or by retrieving historical data from database 307 and characterizing the retrieved data. For example, training data may include historical data from client conversations or real-time data from current client conversations (query patterns, query parameters, tables involved in the query, cost of processing the query, query attributes, query types (e.g., insert, delete, select, update), query operations (e.g., select, join, group), database workload parameters, number of active connections distributed across database servers, query vectors, query configuration patterns, optimal parameters, buffer size, cache size, working memory, client conversation connection pool parameters, maximum number of active connections distributed across database servers, client conversation workload balancing parameters, connection pool ratio for each database server, database metric prediction changes, preprocessed queries, calculated database performance metrics, actual database performance metrics, performance scores, etc.). Characterizing the extracted data may include analyzing the data, extracting query plans from the data, and generating vectors. In some embodiments, model system 306 may generate training data by inputting the characteristic extracted data into the model and determining performance metric changes from the model, wherein the determined performance metric changes may be the training data. In some embodiments, the metric repository system 305 may characterize queries through query fingerprint analysis or query traffic capture. For example, query fingerprint analysis may include converting a query into a query fingerprint. A query fingerprint is an abstraction of a query, where abstraction includes removing literal values, normalizing whitespace, etc. For example, the query "user with id=6 selects name and password" may be converted into a query fingerprint of "password from user with id=?". Query abstraction allows similar queries to be grouped together.

[0075] In some embodiments, the model system 306 may train the model by: acquiring training data, defining a training objective, running the model using the training data, and iteratively updating the network weights of the model until the model outputs the training objective. In some embodiments, the training objective may include minimizing an error function. In some embodiments, the model may be trained by randomly selecting training data.

[0076] In some embodiments, the model may be a multilayer perceptron model consisting of four fully connected layers. In some embodiments, the model system 306 may generate the model based on the scale of the input or output vectors (e.g., determining the number of neurons in each layer of the model). The input layer of the model may accept feature vectors and output mapped tensors (e.g., higher dimensions) to hidden layers. The hidden layers may include a series of nonlinear data transformations. The outputs may constrain the tensors to the scale of the database and produce vectors representing predicted changes in database metrics. The network may represent a chain of functions that transform the inputs into an output space (e.g., a pattern). In some embodiments, the model may include activation functions (e.g., rectified linear units, ReLU) in the hidden layers to capture more patterns. In some embodiments, the weights in the network may be initialized with a standard normal distribution.

[0077] In some embodiments, the model system 306 may map a query to a discrete configuration pattern. For example, the model's input layer may receive feature vectors as input and map the feature vectors to a target parameter space to scale the output. The second layer may be a dense layer with an activation function (e.g., ReLU) that captures correlations between input features (e.g., the difference in feature values ​​when other features change) or a mapping between the input and output vectors. Subsequent layers may normalize the input vectors to obtain a discretized result and use a sigmoid activation function to receive real values ​​as input and output values ​​from "0" to "1". In some embodiments, the model's output layer may be used as a probability distribution function, where for each feature in the output vector, if the feature is less than 0.5, the resulting bit is "-1", if the feature is equal to 0.5, the resulting bit is "0", and otherwise the resulting bit is "1". In some embodiments, the model may propagate features through a network, output a query pattern, and update the model's network weights by minimizing the difference between the output query pattern and the actual query pattern.

[0078] In some embodiments, the model system 306 may train the model using a stochastic optimization algorithm (e.g., Adaptive Moment Estimation), which iteratively updates the network weights using the first and second moments of the gradient, which can be calculated using a stochastic objective function. Training may terminate if the model converges or has run a given number of steps. For example, the model may be transformed when the performance metric changes to a training objective (e.g., when the performance metric changes to less than a threshold, greater than a threshold, etc.).

[0079] In some embodiments, the model system 306 may classify queries into different clusters based on the similarity of query patterns. For example, the configuration may be clustered using a clustering algorithm (e.g., density-based spatial clustering for applications with noise) and clustered based on the configuration pattern, wherein the model system 306 may group patterns that are close to each other together based on distance measurements and the minimum number of points that can be clustered together.

[0080] In some embodiments, the model system 306 may periodically retrieve data (e.g., real-time data, historical data, etc.), run the model, and push the predicted optimal parameters to the application 301. The application 301 may receive the predicted optimal parameters and update the database configuration using the optimal parameters at runtime.

[0081] Referring to FIG4, FIG4 illustrates a process 400 for AI-based database parameter optimization. Although some of the steps set forth herein may be performed in system 330 in some embodiments, other embodiments may also exist. For example, any of the systems and components described and illustrated herein (e.g., system 100) may perform the steps set forth in this disclosure.

[0082] In step 401, user 320A may submit a query to application 301 via user device 320 during a client conversation. In some embodiments, the query may include multiple queries, or user 320A may submit multiple queries. Application 301 may generate a tuning request based on the received query and send the tuning request to tuner system 308. In some embodiments, application 301 may initialize user 320A's client conversation variables at connection time, and then customize the predicted optimal parameters according to the client conversation context (e.g., based on the query pattern, the expected size of the data to be returned, etc.).

[0083] The metric store system 305 may preprocess queries (e.g., transform, clean, etc.) by characterizing the queries. The metric store system 305 may characterize queries by analyzing queries, extracting query plans from queries, and generating vectors. In some embodiments, a query plan may include at least one of the following: query pattern, query parameters (e.g., tables involved in the query, cost of processing the query, query attributes, query type (e.g., insert, delete, select, update), query operation (e.g., select, join, group), etc.), or database workload parameters (e.g., the number of active connections distributed across database servers). In some embodiments, the metric store system 305 may characterize queries by query fingerprint analysis or query traffic capture. For example, query fingerprint analysis may include converting a query into a query fingerprint. A query fingerprint is an abstraction of a query, where abstracting the query includes removing text values, normalizing whitespace, etc. For example, the query "user with id=6 selects name and password" may be converted into a query fingerprint of "password from user with id=?". Abstracted queries allow similar queries to be grouped together.

[0084] In step 403, the model system 306 may predict optimal parameters by using a model to calculate database metric prediction changes (e.g., latency, throughput, etc.) based on a preprocessed query. For example, the model system may predict the difference in database metrics from before the query is executed to after the query is executed. In some embodiments, the model system 306 may send the database metric prediction changes to the tuner system 308.

[0085] In some embodiments, the model system 306 may use a model (e.g., a deep reinforcement learning model, a neural network, a bi-state deep deterministic policy gradient model, etc.) to predict multiple optimal parameters for executing the query. Optimal parameters may include at least one of the following: client-side dialogue database parameters (e.g., buffer size, cache size, working memory), client-side dialogue connection pool parameters (e.g., maximum active connections distributed across database servers), client-side dialogue workload balancing parameters (e.g., connection pool ratio per database server), or data partitioning parameters (e.g., clustering parameters).

[0086] For example, optimizing client-side database parameters (e.g., buffer size) specific to the client-side session can advantageously reduce latency (e.g., the buffer size can be large enough that temporary files are not created on the disk, but small enough that memory is not wasted). Similarly, client-side connection pool parameters, workload balancing parameters, or data partitioning parameters can be optimized to improve system performance. For example, the optimal maximum active connections for each database in system 300 can be large enough that if one database is serving a heavier workload, data can be served by another database to reduce latency and database server skew. In some embodiments, optimal data partitioning parameters may include a routing strategy that allows the optimal mechanism to be selected at runtime when data distribution changes (e.g., during migration, scaling, etc.).

[0087] In step 405, the tuner system 308 may calculate the database performance metric based on the database metric prediction change and the current database performance metric. For example, the tuner system 308 may calculate the database performance metric by retrieving the current (e.g., real-time) database performance metric from the system 300 and adding the database metric prediction change to the current database performance metric. In some embodiments, the tuner system 308 may send the calculated database performance metric to the model system 306.

[0088] In step 407, the model system may calculate an optimal parameter vector based on the calculated database performance metric. In some embodiments, the model system 306 may use multiple models to perform the steps of process 400. For example, the model system 306 may use a first model to calculate database performance metric prediction changes based on a preprocessed query, and use a second model to calculate an optimal parameter vector based on the calculated database performance metric. The model system 306 may input the calculated database performance metric into the model. The model system may calculate the optimal parameter vector based on the calculated database performance metric and send the optimal parameter vector to the tuner system 308.

[0089] In step 409, the tuner system 308 may push optimal parameters to the application 301 and execute a query based on the predicted optimal parameters, thereby executing the query using client-specific optimal parameters and modifying the client-specific parameters at runtime. In some embodiments, the tuner system 308 may calculate a performance score associated with the executed query. For example, the performance score may be calculated by determining the database performance metric change resulting from the executed query. In some embodiments, the tuner system 308 may send the performance score to the model in the model system 306. The model system 306 may update the network weights of the model based on the performance score.

[0090] Although this disclosure has been shown and described with reference to specific embodiments thereof, it should be understood that this disclosure can be practiced in other environments without modification. The foregoing description is presented for illustrative purposes. The foregoing description is not exhaustive and is not limited to the precise forms or embodiments disclosed. Various modifications and adaptations will become apparent to those skilled in the art from the description and practice of the disclosed embodiments. In addition, although the forms of the disclosed embodiments are described as being stored in memory, those skilled in the art should understand that such forms can also be stored on other types of computer-readable media, such as auxiliary storage devices (e.g., compact disk read-only memory, CD ROM) or other forms of random access memory (RAM) or read-only memory (ROM), universal serial bus (USB) media, digital versatile disc (DVD), Blu-ray, or other optically driven media.

[0091] Computer programs based on the written description and the disclosed methods are within the skill level of experienced developers. Various programs or program modules can be created using any techniques known to those skilled in the art, or can be designed in conjunction with existing software. For example, program sections or program modules can be designed using or with the aid of the .NET Framework, .NET Compact Framework (and related languages ​​such as Visual Basic, C, etc.), Java, C++, Objective-C, Hypertext Markup Language (HTML), HTML / AJAX combination, Extensible Markup Language (XML), or HTML including Java applets.

[0092] Furthermore, although exemplary embodiments have been described herein, those skilled in the art will contemplate any and all embodiments with equivalent elements, modifications, omissions, combinations (e.g., combinations of forms between various embodiments), adaptations, and / or alterations based on this disclosure. The limitations in the claims should be interpreted broadly based on the language used in the claims, and not limited to the examples set forth in this specification or during the application process. These examples should be considered non-exclusive. Moreover, the steps of the disclosed methods can be modified in any way, including by reordering the steps and / or inserting or deleting steps. Therefore, this specification and examples are intended to be illustrative only, and the true scope and spirit are indicated by the full scope of the following claims and their equivalents. [Simplified Explanation of the Diagram]

[0009] Figure 1A is a schematic block diagram illustrating an exemplary embodiment of a network conforming to the disclosed embodiments, the network including a computerized system for shipping, transportation, and logistics operations capable of communication. Figure 1B illustrates a sample Search Result Page (SRP) conforming to the disclosed embodiments, which includes one or more search results satisfying a search request and interactive user interface elements. Figure 1C illustrates a sample Single Detail Page (SDP) conforming to the disclosed embodiments, which includes product and information about the product and interactive user interface elements. Figure 1D illustrates a sample Cart page conforming to the disclosed embodiments, which includes items in a virtual shopping cart and interactive user interface elements. Figure 1E illustrates a sample Order page conforming to the disclosed embodiments, which includes items from a virtual shopping cart and information about purchasing and shipping, and interactive user interface elements. Figure 2 is an illustration of an exemplary fulfillment center configured to utilize the disclosed computerized system conforming to the disclosed embodiments. Figure 3 illustrates an exemplary network of an apparatus and system for AI-based database parameter optimization conforming to the disclosed embodiments. Figure 4 illustrates an exemplary process for AI-based database parameter optimization conforming to the disclosed embodiments.

Claims

1. A computer-implemented system for AI-based database parameter optimization, the system comprising: Memory stores instructions; and at least one processor, configured to execute the instructions to: initialize client-side dialog variables associated with the user device; The query is received from the user device; the query is preprocessed; Multiple optimal parameters for executing the query are predicted by: calculating database metric prediction changes based on the preprocessed query; and calculating database performance metrics based on the database metric prediction changes and the current database performance metrics. And calculate the optimal parameter vector based on the database performance metric; and execute the received query based on the predicted multiple optimal parameters customized according to the client dialogue context.

2. The system as described in claim 1, wherein preprocessing the query includes characterizing the query.

3. The system as described in claim 2, wherein characterizing the query includes: Analyze the query; extract the query plan from the query; And generate vectors.

4. The system as described in claim 3, wherein the query plan includes at least one of a query pattern, query parameters, and database workload parameters.

5. The system as described in claim 1, wherein the plurality of optimal parameters includes at least one of client dialogue database parameters, client dialogue connection pool parameters, or client dialogue workload balancing parameters.

6. The system as described in claim 1, further comprising training the model, wherein training the model includes: Extract training data; Define the training objective; Run the model using the training data; And iteratively update the network weights of the model until the model outputs the training objective.

7. The system as described in claim 6, wherein the training objective includes minimizing an error function.

8. The system as claimed in claim 6, wherein training the model further includes generating the training data.

9. The system as described in claim 8, wherein generating the training data includes: Retrieve historical data from the database; And to characterize the historical data.

10. The system as described in claim 9, wherein characterizing the historical data includes: Analyze the historical data; extract a query plan from the historical data; And generate vectors.

11. A computer-implemented method for database parameter optimization based on artificial intelligence, comprising: Initialize client-side dialog variables associated with the user device; The query is received from the user's device; The query is preprocessed; Multiple optimal parameters for executing the query are predicted by: calculating database metric prediction changes based on the preprocessed query; and calculating database performance metrics based on the database metric prediction changes and the current database performance metrics. And calculate the optimal parameter vector based on the database performance metric; and execute the received query based on the predicted multiple optimal parameters customized according to the client dialogue context.

12. The method as described in request item 11, wherein preprocessing the query includes characterizing the query.

13. The method as described in request item 12, wherein characterizing the query includes: Analyze the query; extract the query plan from the query; And generate vectors.

14. The method as described in request item 11, wherein the plurality of optimal parameters includes at least one of client dialogue database parameters, client dialogue connection pool parameters, or client dialogue workload balancing parameters.

15. The method of claim 11, further comprising training the model, wherein training the model includes: Extract training data; Define the training objective; Run the model using the training data; And iteratively update the network weights of the model until the model outputs the training objective.

16. The method as described in request item 15, wherein the training objective includes minimizing an error function.

17. The method of claim 15, wherein training the model further includes generating the training data.

18. The method of claim 17, wherein generating the training data comprises: Retrieve historical data from the database; And to characterize the historical data.

19. The method of claim 18, wherein characterizing the historical data comprises: Analyze the historical data; extract a query plan from the historical data; And generate vectors.

20. A computer-implemented system for AI-based database parameter optimization, the system comprising: Memory stores instructions; and at least one processor, configured to execute the instructions to: initialize client-side dialog variables associated with the user device; The user device receives a query; the query is preprocessed; a model is used to predict multiple optimal parameters for executing the query, wherein the multiple optimal parameters are customized according to the client dialogue context associated with the client dialogue variables; the model is used to calculate a database metric prediction change based on the preprocessed query; the database metric prediction change is sent to a tuner; the tuner is used to calculate a database performance metric based on the database metric prediction change and the current database performance metric. The process includes: calculating an optimal parameter vector using the model based on the database performance metric; executing the received query using the tuner based on the predicted optimal parameters customized according to the client dialogue context; calculating a performance score associated with the executed query using the tuner; sending the performance score to the model; and updating the network weights of the model based on the performance score.

Images