Query method of data table of tenant and related device

Abstract

The invention discloses a tenant data table query method and a related device, and relates to the technical field of cloud computing, the method comprises the following steps: receiving a data table query request containing an original table query statement, and analyzing to obtain an original table name of a to-be-queried data table and a tenant identifier of a to-be-queried tenant; searching a target created data table from a plurality of created data tables based on the original table name and the tenant identifier; obtaining the isolation level of the target created data table and determining the isolation level as the isolation level of the to-be-queried data table; if the isolation level is a row level, rewriting a field structure in the original table look-up statement based on the tenant identifier to obtain a first table look-up statement; if the isolation level is a table level, rewriting the original table name based on the tenant identifier to obtain a second table look-up statement; and executing the corresponding table look-up statement to obtain a query result. According to the method, the isolation level is dynamically determined and the query statement is correspondingly rewritten, so that the query accuracy and efficiency of the data table in the multi-tenant environment are improved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method and related apparatus for querying a tenant's data table. Background Technology

[0002] With the widespread adoption of cloud computing technology, multi-tenant architecture has become one of the core technologies for cloud service providers. In this architecture, multiple tenants share the same set of application and database resources, and it is essential to ensure that each tenant's data is isolated from and invisible to others. To achieve this, data from different tenants is typically stored using row-level or table-level isolation. Therefore, when executing data queries, the query statement must be adapted according to the isolation strategy of the corresponding data table.

[0003] Currently, when querying a tenant's data table, developers typically need to manually determine the isolation level of the tenant's data table based on hard-coded annotations and experience, and then manually add the isolation level information to the query statement.

[0004] However, manually determining the isolation level of a tenant's data table is prone to errors, and manually adding isolation level information to the query statement results in lower accuracy and efficiency for querying the tenant's data table. Summary of the Invention

[0005] In view of the above problems, this application provides a method and related apparatus for querying tenant data tables. To improve the accuracy and efficiency of querying tenant data tables, the specific solution is as follows:

[0006] The first aspect of this application provides a method for querying a tenant's data table, including:

[0007] Receive a data table query request containing an original table lookup statement, and parse the original table lookup statement to obtain the original table name of the data table to be queried and the tenant identifier of the tenant to be queried corresponding to the data table to be queried.

[0008] Based on the original table name of the data table to be queried and the tenant identifier of the tenant to be queried corresponding to the data table to be queried, the target created data table is found from multiple created data tables. The original table name of the target created data table is consistent with the original table name of the data table to be queried, and the tenant identifier of the created tenant corresponding to the target created data table is consistent with the tenant identifier of the tenant to be queried corresponding to the data table to be queried.

[0009] Obtain the isolation level of the target created data table, and determine the isolation level of the target created data table as the isolation level of the data table to be queried;

[0010] If the isolation level of the data table to be queried is row level, then the field structure in the original table lookup statement is rewritten based on the tenant identifier of the tenant to be queried corresponding to the data table to be queried, so as to obtain the first table lookup statement.

[0011] If the isolation level of the data table to be queried is table level, then the original table name in the original table lookup statement is rewritten based on the tenant identifier of the tenant to be queried corresponding to the data table to be queried, so as to obtain the second table lookup statement.

[0012] Execute the first table lookup statement and / or the second table lookup statement to obtain the data table query results of the tenant to be queried.

[0013] In one possible implementation, parsing the original table lookup statement to obtain the original table name of the data table to be queried and the tenant identifier of the tenant corresponding to the data table to be queried includes:

[0014] The original table lookup statement is parsed to obtain the original table name of the data table to be queried;

[0015] Obtain the business method corresponding to the original table lookup statement, and determine whether there is an annotation for the tenant to be queried corresponding to the data table to be queried in the business method corresponding to the original table lookup statement;

[0016] If the business method corresponding to the original table lookup statement contains an annotation for the tenant to be queried corresponding to the data table to be queried, then the annotation for the tenant to be queried corresponding to the data table to be queried is parsed to obtain the tenant identifier of the tenant to be queried corresponding to the data table to be queried.

[0017] If the business method corresponding to the original table lookup statement does not contain an annotation for the tenant to be queried corresponding to the data table to be queried, then the input parameters of the business method corresponding to the original table lookup statement are parsed to obtain the tenant identifier of the tenant to be queried corresponding to the data table to be queried.

[0018] In one possible implementation, after receiving a data table query request containing an original lookup statement and parsing the original lookup statement to obtain the original table name of the data table to be queried and the tenant identifier of the tenant corresponding to the data table to be queried, the method further includes:

[0019] Obtain the method identifier of the business method corresponding to the original table lookup statement and the input parameters of the business method, and perform hash calculation on the input parameters of the business method to obtain the hash value of the input parameters of the business method;

[0020] Based on the tenant identifier of the tenant to be queried corresponding to the data table to be queried, the method identifier of the business method, and the hash value of the input parameters of the business method, a lookup key corresponding to the data table to be queried is generated;

[0021] Determine whether there is a lookup cache key in the preset query cache library that matches the lookup key corresponding to the data table to be queried. If there is a lookup cache key in the preset query cache library that matches the lookup key corresponding to the data table to be queried, then obtain the lookup statement corresponding to the lookup cache key.

[0022] Execute the table lookup statement corresponding to the table lookup cache key to obtain the data table query result of the tenant to be queried.

[0023] In one possible implementation, before receiving the data table query request containing the original lookup statement, the method further includes:

[0024] Receive a data table creation request including the original table creation statement, and parse the original table creation statement to obtain the original table name of the data table to be created, the historical data increment sequence of the data table to be created, and the tenant identifier of the tenant to be created corresponding to the data table to be created.

[0025] The historical data increment sequence of the data table to be created is input into the time series model to obtain the current data increment of the data table to be created;

[0026] Based on the current data increment of the data table to be created, determine the isolation level of the data table to be created;

[0027] If the isolation level of the data table to be created is row-level, then the field structure in the original table creation statement is rewritten based on the tenant identifier of the tenant to be created corresponding to the data table to be created, to obtain the first table creation statement, and the first table creation statement is executed.

[0028] If the isolation level of the data table to be created is row-level, then the original table name of the original table creation statement is rewritten based on the tenant identifier of the tenant to be created corresponding to the data table to be created, to obtain a second table creation statement, and the second table creation statement is executed.

[0029] In one possible implementation, determining the isolation level of the data table to be created based on the current data increment includes:

[0030] Determine whether the data table type of the data table to be created is a preset data table type;

[0031] If the data table type of the data table to be created is the preset data table type, then the isolation level of the data table to be created is determined to be the row level;

[0032] If the data table type of the data table to be created is not the preset data table type, then determine whether the current data increment of the data table to be created is greater than the preset data increment;

[0033] If the current data increment of the data table to be created is greater than the preset data increment, then the isolation level of the data table to be created is determined to be the table level;

[0034] If the current data increment of the data table to be created is not greater than the preset data increment, then the isolation level of the data table to be created is determined to be the row level.

[0035] In one possible implementation, before inputting the historical data increment sequence of the data table to be created into the time series model to obtain the current data increment of the data table to be created, the method further includes:

[0036] Based on multiple historical data increments in the historical data increment sequence of the data table to be created, the mean and standard deviation of the historical data increment sequence are calculated.

[0037] The range of historical data increments is determined based on the mean and standard deviation of the historical data increment sequence.

[0038] Based on the historical data increment range, determine a first historical data increment that does not belong to the historical data increment range and a second historical data increment that belongs to the historical data increment range from multiple historical data increments in the historical data increment sequence of the data table to be created;

[0039] Based on the second historical data increment, the first historical data increment is corrected to obtain the corrected first historical data increment, and a new historical data increment sequence of the data table to be created is constructed using the second historical data increment and the corrected first historical data increment.

[0040] In one possible implementation, the step of correcting the first historical data increment based on the second historical data increment to obtain a corrected first historical data increment includes:

[0041] Obtain the second historical data increment corresponding to the target time period, wherein the target time period is determined based on the time corresponding to the first historical data increment;

[0042] The target linear equation is obtained by fitting the second historical data increment corresponding to the target time period, and the target historical data increment at the time corresponding to the first historical data increment is obtained by using the target linear equation.

[0043] The target historical data increment is determined as the corrected first historical data increment.

[0044] A second aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the tenant data table query method of the first aspect or any implementation thereof.

[0045] A third aspect of this application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0046] The memory is used to store computer programs;

[0047] The processor is used to execute the computer program so that the electronic device can implement the tenant data table query method of the first aspect or any implementation thereof.

[0048] A fourth aspect of this application provides a computer storage medium carrying one or more computer programs that, when executed by an electronic device, enable the electronic device to perform a query method for a tenant's data table according to the first aspect or any implementation thereof.

[0049] By means of the above technical solution, this application provides a method and related apparatus for querying a tenant's data table. The method includes: receiving a data table query request containing an original lookup statement, and parsing the original lookup statement to obtain the original table name of the data table to be queried and the tenant identifier of the tenant to be queried corresponding to the data table; based on the original table name of the data table to be queried and the tenant identifier of the tenant to be queried corresponding to the data table to be queried, searching for a target created data table from multiple created data tables, wherein the original table name of the target created data table is consistent with the original table name of the data table to be queried, and the tenant identifier of the created tenant corresponding to the target created data table is consistent with the original table name of the created tenant corresponding to the data table to be queried. The query process involves several steps: First, the tenant identifier of the target table is matched with the tenant identifier of the target table. Then, the isolation level of the target table is determined and used as the isolation level for the table to be queried. If the isolation level of the table to be queried is row-level, the field structure of the original query statement is rewritten based on the tenant identifier of the target table to obtain the first query statement. If the isolation level of the table to be queried is table-level, the original table name in the original query statement is rewritten based on the tenant identifier of the target table to obtain the second query statement. The first and / or second query statements are executed to obtain the query results for the target tenant's table. This application precisely matches the tenant identifier with the original table name to the corresponding created table, uses its isolation level as the isolation level of the table to be queried, and intelligently generates execution statements adapted to row-level or table-level isolation. This effectively avoids query errors in tenant tables caused by human error or omission, significantly improving the accuracy and efficiency of table queries in a multi-tenant environment. Attached Figure Description

[0050] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0051] Figure 1 A flowchart illustrating a method for querying a tenant's data table, provided in an embodiment of this application;

[0052] Figure 2 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0053] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0054] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0055] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0056] To improve the accuracy and efficiency of querying tenant data tables, this application provides a method for querying tenant data tables. The following description, in conjunction with the accompanying drawings and specific embodiments, provides a more detailed explanation of the method for querying tenant data tables provided in this application.

[0057] Please see the appendix Figure 1 , Figure 1 This is a flowchart illustrating a method for querying a tenant's data table, provided in an embodiment of this application. The method may include the following steps:

[0058] Step S101: Receive a data table query request containing the original table lookup statement, and parse the original table lookup statement to obtain the original table name of the data table to be queried and the tenant identifier of the tenant to be queried corresponding to the data table to be queried.

[0059] Before receiving a data table query request containing the original lookup statement, the method may further include the following steps: First, it may receive a data table creation request containing the original table creation statement, and parse the original table creation statement to obtain the original table name of the data table to be created, the historical data increment sequence of the data table to be created, and the tenant identifier of the tenant to be created corresponding to the data table to be created. Then, it may input the historical data increment sequence of the data table to be created into a time series model to obtain the current data increment of the data table to be created. Next, it may determine the isolation level of the data table to be created based on the current data increment of the data table to be created. If the isolation level of the data table to be created is row-level, the field structure in the original table creation statement is rewritten based on the tenant identifier of the tenant to be created corresponding to the data table to obtain the first table creation statement, and the first table creation statement is executed. If the isolation level of the data table to be created is row-level, the original table name of the original table creation statement is rewritten based on the tenant identifier of the tenant to be created corresponding to the data table to obtain the second table creation statement, and the second table creation statement is executed.

[0060] Specifically, a data table creation request containing a raw table creation statement can be received. This raw statement refers to a standard SQL table creation instruction submitted by the application or developer (e.g., `CREATE TABLE orders (id BIGINT, amount DECIMAL)`), which does not contain any multi-tenant isolation-related logic or fields, but only describes the table structure required by the business. Parsing this raw statement extracts three key pieces of information: the original table name of the data table to be created: i.e., the logical table name defined in the statement (e.g., `orders`). This name is a uniform table name from the tenant's perspective and does not reflect any tenant specificity; whether it will be rewritten later depends on the isolation strategy. The historical data increment sequence of the data table to be created: refers to the data growth records of this tenant in the same or similar business tables over a past period (e.g., a time series of weekly new records), used to predict future data scale. The tenant identifier of the tenant to be created: this is a globally unique and non-repeatable identity identifier assigned by the system to each tenant. Based on this, it is necessary to understand how the two isolation methods depend on the above information: Table-level isolation: creating a separate physical table. The specific approach involves concatenating the system name, the original table name, and the tenant's identifier to form a unique physical table name (e.g., abc_orders_tenant123). Different tenants have their own independent physical tables, achieving complete physical isolation and offering high security and performance advantages, suitable for scenarios with large data volumes. Row-level isolation: Multiple tenants share the same physical table. A field named `tenant_id`, with the same data type as the tenant identifier, can be automatically added to the field structure of the original table creation statement. All tenants' data is stored in the same table, but ownership is distinguished by the `tenant_id` field value, achieving logical isolation. This method saves storage resources and is suitable for lightweight or large-scale small-tenant scenarios.

[0061] Before inputting the historical data increment sequence of the data table to be created into the time series model to obtain the current data increment of the data table, this method may further include the following steps: First, based on multiple historical data increments in the historical data increment sequence of the data table to be created, the mean and standard deviation of the historical data increment sequence can be calculated. Then, based on the mean and standard deviation of the historical data increment sequence, the range of historical data increments can be determined. Next, based on the range of historical data increments, a first historical data increment that does not belong to the range and a second historical data increment that belongs to the range can be determined from multiple historical data increments in the historical data increment sequence of the data table to be created. Finally, based on the second historical data increment, the first historical data increment can be corrected to obtain the corrected first historical data increment, and a new historical data increment sequence of the data table to be created can be constructed using the second historical data increment and the corrected first historical data increment.

[0062] Before inputting the historical data increment sequence of the data table to be created into a time series model (such as an ARIMA model) to predict the current data increment, this method also includes a data preprocessing and outlier correction step, designed to improve the accuracy of subsequent predictions. Specifically, based on multiple historical data increments (i.e., the amount of new data over several past time periods) in the historical data increment sequence of the data table to be created, the arithmetic mean (mean) and standard deviation of the sequence are calculated. The mean reflects the central trend of the historical data increments. The standard deviation measures the degree of fluctuation of the data around the mean. For ease of understanding, assume that the historical data increment sequence of the data table to be created is... .in, Indicates the first The total amount of new data (i.e., historical data increments) in the corresponding business table of this tenant within a time period (e.g., weekly). One observation. Mean Standard deviation .

[0063] Next, based on the mean and standard deviation mentioned above, a reasonable range for normal data fluctuation is defined, i.e., the range of historical data increments. The 95% confidence interval method, commonly used in statistics, is typically employed: the range of historical data increments is... This range covers approximately 95% of normal data points; values ​​outside this range are considered potential outliers. Then, each data point in the historical data increment sequence is evaluated: data points falling within this range are called the first historical data increment (i.e., normal values). Data points not falling within this range are called the second historical data increment (i.e., outliers or exceptions). For example, if a tenant experiences a surge in data due to a promotional activity during a certain period, with the increment significantly exceeding the normal level, then this increment is the second historical data increment. For ease of understanding, let's assume the historical data increment range is... Abnormal data points that do not fall within the above range, i.e., the first historical data increment. Normal data points falling within this range, i.e., the second historical data increment. .

[0064] To eliminate the interference of abnormal data points caused by temporary events (such as major sales events, web crawlers, and system failures) on the overall trend, the first historical data increment is further corrected. The specific steps are as follows: A second historical data increment corresponding to the target time period is obtained, where the target time period is determined based on the time corresponding to the first historical data increment. A target linear equation is obtained by fitting the second historical data increment corresponding to the target time period, and this target linear equation is used to obtain the target historical data increment for the time corresponding to the first historical data increment. This target historical data increment is then determined as the corrected first historical data increment.

[0065] Specifically, based on the time corresponding to the first historical data increment, i.e., the time point corresponding to the outlier, a target time period adjacent to it is determined. The selection of this time period needs to consider contextual continuity, for example, taking several cycles before and after it. All second historical data increments within this target time period are collected, i.e., all normal values ​​within this target time period, and linear regression analysis is performed on these data to fit a target linear equation. This equation describes the changing trend of normal values ​​within a specific time period. Using the target linear equation obtained above, the time point corresponding to the first historical data increment is substituted to calculate the reasonable data increment that should exist at that time point, denoted as the target historical data increment. This step is equivalent to filling the gaps in the outlier area by trend extrapolation. The original first historical data increment is replaced with the target historical data increment calculated above, thereby obtaining a corrected first historical data increment that better reflects the actual trend. For ease of understanding, it is assumed that for each outlier data point... (Corresponding time is) ),based on Select a nearby time window as the target time period ,in A preset timeframe (e.g., 2 weeks) is used to capture local trends. From Filtering out time periods All normal points within the range constitute the set. ,right Linear regression is performed on the normal points to obtain the local trend line. ,in , , and They are respectively The mean of the interval and the mean of the increment. The time of the outlier. Substituting into the fitting equation, we obtain a more reasonable estimate at that moment. .

[0066] Finally, all the corrected first historical data increments are merged with the original second historical data increments to form a new, smoother, and more accurate sequence of historical data increments. For ease of understanding, let's assume the original sequence... All abnormal data points Replace with its correction value Meanwhile, the normal data points remain unchanged, ultimately forming the corrected sequence. .

[0067] After outlier detection and correction of historical data increment sequences, an estimated value of the current data increment is output to predict the data growth of the table to be created over a future period using the ARIMA time series model. This prediction result will serve as a key basis for determining the isolation level (row-level or table-level) in intelligent decision-making. Periodic predictions are performed on a weekly basis.

[0068] The ARIMA model is a classic method widely used in time series forecasting, suitable for non-stationary data with trends, seasonality, or volatility. Its general form is ARIMA(p,d,q), where P is the autoregressive order, representing how many past periods the model depends on; d is the differencing order, indicating how many differencing operations are performed on the original series to make it stationary; and q is the moving average order, representing how many past periods the model depends on for error terms. The ARIMA model is used to predict the amount of new data in a tenant's data table, i.e., the future values ​​of the historical data increment series.

[0069] Before applying the ARIMA model, it must be ensured that the time series is stationary, meaning that the mean and variance do not change over time. If the original series is non-stationary, differencing is required. The ADF test aims to determine whether a unit root exists in the historical data increment series, i.e., whether it is non-stationary. The null hypothesis H0 is that a unit root exists, meaning the series is non-stationary. The alternative hypothesis H1 is that no unit root exists, meaning the series is stationary. The specific testing procedure is as follows: Perform first-order differencing on the original historical data increment series, i.e., calculate the difference between two adjacent increments. Perform an ADF test on the differencing series. If the p-value is ≥0.05, it indicates that the series is still non-stationary, and second-order differencing is performed. Repeat the above process until the p-value of the ADF test is <0.05, at which point the series is considered to have reached a stationary state, and the required differencing order d is recorded. This process ensures that subsequent modeling is based on stationary data, improving the reliability of predictions.

[0070] Once the series is stationary, the next step is to determine the values ​​of p and q. This is achieved by analyzing two key statistics. The autocorrelation function (ACF) measures the correlation between a time series and its lagged versions. Observing the decay pattern of the ACF plot helps determine the moving average order q. If the ACF drops sharply to zero after a certain order, then that order is the appropriate value for q. Simultaneously, a 95% confidence interval is used to determine which lagged terms are significantly correlated. Refer to the formula for details. ,in, Lagging The autocorrelation coefficient of the period, The mean of the sequence. Let V be the variance of the sequence. Let be the observation value at period t. The partial autocorrelation function PACF is a measure of the effect of intermediate lags after excluding the influence of intermediate lags. and The direct correlation. Used to observe the truncation characteristics of the PACF plot, it can determine the autoregressive order p. If the PACF abruptly truncates after a certain order, then that order is the appropriate p value. Refer to the formula for details. ,in, Lagging The partial autocorrelation coefficient of the period, Lagging The autocorrelation coefficient of the period, The partial autocorrelation coefficients are known. The molecular response of PACF before knockout... Net correlation after the -1 period effect, with the denominator being a standardized factor, ensures .

[0071] Based on the p, d, and q determined in the above steps, construct the ARIMA model. Its mathematical expression is: ,in, The sequence after d-order differencing. The constant term represents the baseline level of the sequence. The trend term is represented by t, which is a time variable, indicating a linear trend. This is the autoregressive term (the effect of lag by 1 period). This is the difference term (autoregressive part) with a lag of p periods. This is a random error term that follows a normal distribution. This model integrates trend, autoregressive, and moving average components, effectively capturing complex time series patterns.

[0072] Historical data increment sequences can be used to estimate the parameters of the ARIMA model (e.g., least squares method). Residual diagnostics (e.g., Ljung-Box test) are used to verify whether the model residuals are white noise; if not, p or q needs adjustment. Cross-validation or rolling forecasting methods are used to evaluate model performance. After model training, the latest historical data increment sequence is input. The model is used to make point predictions of the data increment for the next period (i.e., the following week), and the output is the current data increment. This is performed weekly to ensure the model can respond promptly to changes in tenant data growth. After each prediction, new observations are added to the historical sequence, and the model is retrained to achieve online learning and continuous optimization.

[0073] The system determines whether the table type of the data table to be created is a preset table type. If the table type is a preset table type, the isolation level for the data table is set to row-level. If the table type is not a preset table type, the system checks whether the current data increment of the data table is greater than the preset data increment. If the current data increment is greater than the preset data increment, the isolation level for the data table is set to table-level. If the current data increment is not greater than the preset data increment, the isolation level for the data table is set to row-level.

[0074] It's important to note that preset data table types refer to special data tables whose isolation strategies are clearly defined during the system design phase and do not require data growth prediction to determine the isolation method. Typical examples include: configuration tables and dictionary tables, which store static or rarely changing system parameters, enumeration values, etc., with very small data volumes. Association tables (intermediate tables) are used to represent many-to-many relationships between multiple main tables (such as user-role association tables). Their isolation strategies usually follow the main tables and are not independently determined. These tables, due to their stable structure, small data volume, or strong dependencies, uniformly use row-level isolation by default. Current data increment refers to the amount of new data the table to be created is predicted to add in a future period (e.g., one week) using a time series model (such as ARIMA), serving as a key indicator of its future scale. Preset data increment (fixed threshold) is an empirical value set by experienced developers or operations personnel to determine whether table-level isolation should be used. Its value comprehensively considers factors such as database type (e.g., MySQL vs. distributed database), server performance (CPU, memory, I / O capabilities), and business query performance requirements. For example, it could be set to add 100,000 records per week. Business experience values ​​refer to manually specified isolation strategies for specific table and tenant combinations, either pre-configured or historically accumulated. When such experience rules exist, they take precedence over model predictions and are used to handle special business scenarios that the model cannot cover (such as compliance, security, and performance fallback). Tenant table structure metadata refers to the internal data structure used by the system to record the physical implementation information of each logical table under each tenant. Core fields include: tenant identifier (uniquely identifying the tenant), original table name (the table name from the tenant's perspective), and isolation level (row-level or table-level). This metadata serves as the basis for subsequent automatic table creation and query rewriting.

[0075] After cleaning the historical incremental data sequence and performing ARIMA model predictions, the final decision-making stage for the isolation level begins. First, it's determined whether the table to be created belongs to the preset table type. If the table is a known small-volume or strongly dependent table, such as a configuration table, dictionary table, or related table, its isolation level is directly set to row-level, without any data growth prediction. This is because such tables have stable data and small data volumes; row-level isolation satisfies data isolation requirements while maximizing storage resource savings and simplifying management.

[0076] For ordinary business tables that do not belong to the preset type, the decision is made based on the comparison between the current data increment (i.e., the future growth value predicted by the ARIMA model) and the preset data increment (fixed threshold). If the predicted current data increment is greater than the threshold, it indicates that the table will carry a large amount of data in the future. In this case, table-level isolation is more appropriate. By creating an independent physical table for the tenant (with the tenant identifier embedded in the table name), the query performance degradation and lock contention issues caused by sharing a large table under row-level isolation can be avoided. Conversely, if the predicted increment does not exceed the threshold, row-level isolation is selected, that is, a tenant_id field is added to the shared table to achieve logical isolation in a more economical way.

[0077] To further enhance the robustness of decision-making, a business experience value mechanism can be introduced. Even if the model prediction suggests row-level isolation, if there are business experience rules for that table that explicitly require table-level isolation (e.g., physical isolation is required due to financial auditing or high-concurrency scenarios), then the business experience value will prevail. This design, which prioritizes expert experience over model prediction, ensures that the system can still make correct decisions when faced with special business needs or model limitations.

[0078] Ultimately, regardless of whether the isolation level is determined through rules, models, or experience, the results (including tenant identifier, original table name, and isolation level) will be persistently written to the tenant table structure metadata. This metadata will become the core basis for subsequent automatic table creation (dynamically rewriting table creation statements) and transparent queries (dynamically rewriting SQL), thereby achieving automation, intelligence, and consistency of multi-tenant data isolation throughout the entire lifecycle.

[0079] If the isolation level is row-level, a tenant identifier field must be explicitly added to the table structure. Specifically, add a field named `tenant_id` at the end of the field list (or at a specified position). The data type of this field should match the data type of the tenant identifier in the system (e.g., VARCHAR(32) or BIGINT). An index is usually created for it to speed up tenant data filtering. The resulting statement is called the first table creation statement. If the isolation level is table-level, a separate physical table must be created for this tenant, therefore the table name must be modified. Specifically, replace the original table name in the original table creation statement with a combination of "original table name + tenant identifier" (e.g., `orders→orders_tenant123`). The table structure itself remains unchanged (without the `tenant_id` field). The resulting statement is called the second table creation statement. The key premise here is that the table structure used must be up-to-date, not the original statement initially submitted by the user that may be outdated.

[0080] In this application, the original table lookup statement is first parsed to obtain the original table name of the data table to be queried. Then, the business method corresponding to the original table lookup statement is obtained, and it is determined whether the business method contains an annotation for the tenant corresponding to the data table to be queried. If the business method contains an annotation for the tenant corresponding to the data table to be queried, the annotation is parsed to obtain the tenant identifier of the tenant corresponding to the data table to be queried. If the business method does not contain an annotation for the tenant corresponding to the data table to be queried, the input parameters of the business method are parsed to obtain the tenant identifier of the tenant corresponding to the data table to be queried.

[0081] Specifically, it first receives statements containing the original table lookup statement (such as standard...). The system processes and parses the data table query request to extract the original table name (e.g., `orders`). This table name is the logical table name from the tenant's perspective and does not contain any tenant-specific information; it is only used for subsequent metadata matching. In a typical cloud application architecture, SQL queries are usually triggered by a business method (i.e., a program function or interface method) in the upper-layer business code. The system associates the current SQL execution context with the corresponding business method through the call stack or AOP (Aspect-Oriented Programming) mechanism. This business method is the context carrier for extracting the tenant identifier. First, it checks whether the business method contains a predefined tenant annotation (e.g., `@Tenant(tenantId="tenant123")`). This is a programming method that explicitly declares the tenant identity and is commonly used in the following scenarios: scheduled tasks need to be executed with a specific tenant identity; administrator operations need to switch to the target tenant context; and special business processes such as cross-tenant data synchronization.

[0082] If the annotation exists, parse the `value` field (or other specified attribute) in the annotation and use its value directly as the tenant identifier of the tenant being queried. This method has the highest priority, indicating that the developer has explicitly specified the tenant identity for this query, and the system should strictly adhere to it. For example, if a business method is annotated with `@Tenant("abc_tenant_001")`, then regardless of other contexts, this query is considered a request for tenant `abc_tenant_001`. If the above tenant annotation does not exist in the business method, instead, analyze the method's input parameters, i.e., the method parameter list, and extract the tenant identifier from it. This is a more common scenario and applies to most ordinary user requests, where the tenant identity is usually passed as a request parameter (such as `X-Tenant-ID` in the HTTP header or the `tenantId` field in the method input parameters). The specific implementation includes: traversing all parameters of the method; identifying whether the parameters contain fields named `tenantId`, `tenant_id`, or fields marked by custom annotations; if found, using their values ​​as the tenant identifier of the tenant being queried. If not explicitly provided in the parameters, the system can also attempt to obtain the tenant identifier from the current thread context (such as a ThreadLocal variable). Typically, the tenant identifier is pre-injected at the request entry point (such as an API gateway or interceptor) based on authentication information (such as a JWT token). For example, in the REST API method getOrders(String tenantId, String status), the tenantId parameter value is used as the tenant identifier.

[0083] Furthermore, after receiving a data table query request containing the original lookup statement and parsing the original lookup statement to obtain the original table name of the data table to be queried and the tenant identifier of the tenant to be queried corresponding to the data table, the method may further include the following steps: First, the method identifier of the business method corresponding to the original lookup statement and the input parameters of the business method can be obtained, and a hash calculation can be performed on the input parameters of the business method to obtain the hash value of the input parameters of the business method. Then, based on the tenant identifier of the tenant to be queried corresponding to the data table, the method identifier of the business method, and the hash value of the input parameters of the business method, a lookup key corresponding to the data table to be queried can be generated. Next, it can be determined whether a lookup cache key consistent with the lookup key corresponding to the data table to be queried exists in the preset query cache library. If a lookup cache key consistent with the lookup key corresponding to the data table to be queried exists in the preset query cache library, the lookup statement corresponding to the lookup cache key is obtained. Finally, the lookup statement corresponding to the lookup cache key can be executed to obtain the data table query result of the tenant to be queried.

[0084] Specifically, the method identifier (i.e., fully qualified name) of the business method that triggered the current query is obtained through the call context (such as AOP aspects or interceptors), as well as all the actual parameters passed when the method was called (e.g., userId=123, status="paid"). To ensure that parameters with the same semantics generate the same hash value, the following parameter standardization rules are executed: Basic type processing: Numbers (int / long / float, etc.) retain their original values. Strings are preserved as is. Boolean values ​​are uniformly converted to lowercase strings "true" or "false" to avoid inconsistent hashes due to language differences (e.g., Java uses boolean, databases use 0 / 1). Complex type processing (objects, Maps, Lists, etc.): Objects: Extract their fields, sort them lexicographically by field names, and serialize them into JSON strings. Maps: Sort by key name and then serialize. Lists / Arrays: Maintain the element order, but if the element is an object, recursively standardize. This avoids different hashes due to different field orders (e.g., {a:1,b:2} vs {b:2,a:1}), even though the actual semantics are exactly the same. The standardized parameters are then concatenated into a single string, and its hash value is calculated using the CRC32 algorithm, resulting in a fixed-length (typically an 8-digit hexadecimal string). CRC32 is chosen because it is fast, has an acceptable collision rate, and a short output length, making it suitable as part of the cache key. This result is the hash value of the input parameters for the business method.

[0085] Concatenate the following three elements in a fixed format to form a unique lookup key: Tenant ID + "_" + Method ID of the business method + "_" + Hash value of the input parameters. This key uniquely identifies a query initiated by a tenant with a specific set of parameters under a specific method, ensuring cache hits, e.g., tenant_abc123_com.example.service.OrderService.getOrders_c3a8f2d1. You can check in the preset query cache (in-memory key-value storage) to see if a lookup cache key that exactly matches the above lookup key exists. If it does, directly retrieve the lookup statement corresponding to that cache key (i.e., the previously rewritten SQL, such as...). Skip subsequent steps such as parsing, metadata querying, isolation checks, and SQL rewriting. Execute the table lookup statement directly and return the query result. If the result does not exist, continue with the complete query process. Store the final generated table lookup statement in the cache with the current lookup key as the key for reuse in subsequent identical requests.

[0086] All cached data is stored in memory (such as the JVM heap memory), avoiding disk I / O and greatly improving access speed. A standard key-value mapping can be used, where the key is the lookup key mentioned above, and the value is the rewritten SQL string. When the number of cached entries exceeds a preset capacity threshold, an LRU (Least Recently Used) eviction policy is used to automatically remove the least recently used cached item, preventing memory overflow. The cache library must support high-concurrency read and write operations to ensure the correctness of cache operations in a multi-tenant environment.

[0087] Step S102: Based on the original table name of the data table to be queried and the tenant identifier of the tenant to be queried corresponding to the data table to be queried, find the target created data table from multiple created data tables. The original table name of the target created data table is consistent with the original table name of the data table to be queried, and the tenant identifier of the created tenant corresponding to the target created data table is consistent with the tenant identifier of the tenant to be queried corresponding to the data table to be queried.

[0088] In this application, the input for this step includes two key elements: the original table name of the data table to be queried: that is, the logical table name used from the tenant's perspective (e.g., orders), which does not contain any tenant-specific information; and the tenant identifier of the tenant to be queried: uniquely identifying the tenant currently initiating the query (e.g., tenant_abc123). These two pieces of information together constitute the unique query context of "tenant + logical table".

[0089] The system maintains a tenant table structure metadata repository (usually a metadata table in the database or a configuration center), which records information about all physical data tables created for each tenant. Each metadata record contains at least the following fields: Logical table name: The logical table name corresponding to this physical table. Tenant identifier: The tenant to which this physical table belongs. Physical table name: The actual table name created in the database (e.g., orders_tenant_abc123 or orders). Isolation level: Row-level or table-level.

[0090] Perform an exact match query in the metadata repository, with the following filtering criteria: The original table name in the metadata record equals the original table name of the table being queried. The tenant identifier in the metadata record equals the tenant identifier of the tenant being queried. Only metadata records that satisfy both of these conditions are considered to point to a physical table that has been created as the target table. Example: Query request: Tenant_abc123 queries the logical table `orders`. The system searches the metadata: If the record found is: {Original table name: "orders", Tenant identifier: "tenant_abc123", Physical table name: "orders_tenant_abc123", Isolation level: "table level"}, then a match is successful. Records ignored: {Original table name: "orders", Tenant identifier: "tenant_xyz789",...} (tenant mismatch). Records ignored: {Original table name: "users", Tenant identifier: "tenant_abc123",...} (table name mismatch).

[0091] The system may contain both row-level isolated tables (sharing a single physical table) and table-level isolated tables (each tenant has its own independent table). The physical location cannot be determined solely by the original table name; it must be combined with the tenant identifier for accurate location. Failure to strictly match the tenant identifier may result in incorrectly returning data from other tenants (e.g., routing a request from tenant_abc123 to a table belonging to tenant_xyz789), leading to serious privilege escalation. This step employs double verification to prevent such risks.

[0092] If no matching target table is found in the metadata, it means that the tenant has not yet created a physical instance of the logical table. In this case, the system may trigger one of the following actions: automatically invoke the aforementioned table creation process (predicting the isolation level based on historical data and creating the table); throw a table not found exception, which will be handled by the upper-level business logic; or return an empty result set (suitable for some read-only scenarios). Specific strategies can be flexibly configured according to the system design.

[0093] Step S103: Obtain the isolation level of the target created data table, and determine the isolation level of the target created data table as the isolation level of the data table to be queried.

[0094] In this application, once the target data table matching the current tenant and logical table name has been accurately located and created, its isolation level (row-level or table-level) is read from the corresponding metadata and directly determined as the isolation level to be used in this query. This approach ensures that the query rewriting logic is completely consistent with the underlying physical implementation, fundamentally avoiding data privilege escalation or query failures caused by policy mismatch.

[0095] To further improve performance, when a tenant initiates its first query, the system does not only retrieve the isolation level of the current table, but also loads the isolation level information of all created tables under that tenant's name at once, and caches the entire "table name → isolation level" mapping relationship in memory with the tenant's identifier as the key. For example, information such as the tenant_abc123's orders table being table-level isolated and users table being row-level isolated will be loaded into the local cache.

[0096] After this, any subsequent queries to that tenant (whether querying orders, users, or other tables) can quickly retrieve the corresponding isolation level directly from memory, without needing to access the database or remote metadata service again. This not only reduces the metadata retrieval latency for a single query to the microsecond level but also significantly reduces the pressure on the backend storage. Simultaneously, by listening for table creation or policy change events, the cached entries for the relevant tenants are promptly cleared or updated, ensuring that the policy always remains consistent with the latest configuration.

[0097] Step S104: If the isolation level of the data table to be queried is row-level, then the field structure in the original table lookup statement is rewritten based on the tenant identifier of the tenant to be queried corresponding to the data table to obtain the first table lookup statement.

[0098] In this application, row-level isolation refers to multiple tenants sharing the same physical data table, using a field named `tenant_id` to distinguish data rows from different tenants. Therefore, any operation on this table must explicitly include the current tenant's tenant identifier; otherwise, it will result in unauthorized data access or write errors. To address this, the system employs different rewrite strategies based on the type of SQL statement operation.

[0099] Insert operation (INSERT): Because the shared table structure contains a tenant_id field, this field value must be provided when inserting a new record. The system will automatically add tenant_id to the field list and fill in the tenant identifier of the tenant being queried in the value list. For example, the original statement is INSERT INTO abc_order(id,order_no) VALUES (1,'ab123456'), which is rewritten as INSERT INTO abc_order(id,order_no,tenant_id) VALUES (1,'ab123456','0001'), where '0001' is the tenant identifier of the current tenant.

[0100] Query, update, and delete operations (SELECT / UPDATE / DELETE): These operations all require appending the filter condition `tenant_id='current tenant identifier'` to the WHERE clause to ensure that the operation only applies to the current tenant's data. Specifically: The original statement for a query operation (SELECT) is as follows: , was rewritten as If the original statement already has a WHERE clause, it is connected using AND, such as WHERE id=1 AND tenant_id='0001'. The original UPDATE statement, UPDATE abc_order SET order_no='ab123456' WHERE id=1, is rewritten as UPDATE abc_order SET order_no='ab123456' WHERE id=1 AND tenant_id='0001'. The original DELETE statement, DELETE FROM abc_order WHERE id=1, is rewritten as DELETE FROM abc_order WHERE id=1 AND tenant_id='0001'. All rewrites are based on parsing and reconstructing the SQL syntax tree (AST), rather than simple string concatenation, ensuring syntactic correctness and security (such as preventing SQL injection).

[0101] Step S105: If the isolation level of the data table to be queried is table level, then the original table name in the original table lookup statement is rewritten based on the tenant identifier of the tenant to be queried corresponding to the data table to be queried, so as to obtain the second table lookup statement.

[0102] Table-level isolation refers to creating a separate physical table for each tenant, with data from different tenants stored entirely in different tables, achieving complete physical isolation. These tables typically follow a unified naming convention: original table name + tenant identifier (e.g., if the logical table name is abc_order and the tenant identifier is 0001, then its physical table name is abc_order_0001). Therefore, before performing any database operations, the logical table name in the original SQL must be replaced with the physical table name corresponding to that tenant.

[0103] Specifically, the system performs syntax parsing on the original table lookup statements (including all DML operations such as SELECT, INSERT, UPDATE, and DELETE), identifies the original table names involved, and replaces them with the format "original table name_tenant identifier". The entire process does not modify the field structure or add extra conditions; it only changes the table name itself. For example, the original statement for the query operation (SELECT) is... , was rewritten as (Tenant ID is '0001'). The original INSERT statement was INSERT INTO abc_order(id, order_no) VALUES (1,'ab123456'), which was rewritten as INSERT INTO abc_order_0001(id, order_no) VALUES (1, 'ab123456'). The original UPDATE statement was UPDATE abc_order SET order_no = 'xyz789' WHERE id = 1, which was rewritten as UPDATE abc_order_0001 SET order_no = 'xyz789' WHERE id = 1. The original DELETE statement was DELETE FROM abc_order WHERE id = 1, which was rewritten as DELETE FROM abc_order_0001 WHERE id = 1. Under table-level isolation, there is no need to explicitly include the tenant_id field in the statement, because each physical table naturally belongs to only one tenant, and the data ownership is uniquely determined by the table name.

[0104] This rewriting process is based on deep parsing of the SQL syntax tree (AST), ensuring that even in complex query scenarios (such as multi-table JOIN, subqueries, alias usage, etc.), the target table name can be accurately identified and replaced, avoiding accidental or missed modifications.

[0105] If the original statement is If both abc_order and abc_user are table-level isolated, the system will replace the two table names with abc_order_0001 and abc_user_0001 respectively, ensuring that the join query is still executed in the same tenant context.

[0106] Step S106: Execute the first table lookup statement and / or the second table lookup statement to obtain the data table query results of the tenant to be queried.

[0107] In this application, SQL statements adapted to the isolation strategy are executed, and the correct data results belonging to the current tenant being queried are returned. The statement executed in this step may be a first table lookup statement, a second table lookup statement, or a single rewritten statement combining the logic of the two, depending on the tables involved in the query and their isolation levels. The first table lookup statement refers to the rewritten statement generated for row-level isolated tables, characterized by injecting tenant_id-related logic into the original SQL (such as adding fields during insertion, and appending the WHERE tenant_id='tenant identifier' condition during query / update / deletion); the second table lookup statement refers to the rewritten statement generated for table-level isolated tables, characterized by replacing the original table name with the physical table name of "original table name_tenant identifier", without modifying fields or conditions.

[0108] In scenarios involving single-table queries or all related tables using the same isolation level, only one type of rewrite result needs to be executed: either the first lookup statement or the second lookup statement. For example, if only a row-isolated user table is queried, the first lookup statement is executed; if only a table-isolated order table is queried, the second lookup statement is executed. However, in more complex mixed isolation level JOIN queries (such as when the order table is table-isolated and the dictionary table is row-isolated), the system applies both rewrite rules simultaneously, generating a merged complete SQL statement: replacing the table name of the table-isolated table (e.g., abc_order) with abc_order_0001; and adding the condition tenant_id = '0001' to the WHERE clause of the row-isolated table (e.g., abc_dict). In this case, although technically only one SQL statement is generated and executed, its content simultaneously reflects the rewrite logic of both the first and second lookup statements. For example: the original statement is...

[0109] ,

[0110] It can be rewritten as

[0111] .

[0112] After the rewrite is complete, the system submits the generated complete SQL statement to the database for execution and returns the query results to the caller. The entire process is completely transparent to the business layer; developers do not need to care whether the underlying table is a shared table or an independent table, nor do they need to manually construct tenant conditions or modify table names.

[0113] To further improve performance, this application can also store the final rewritten complete SQL statement (including complex statements in mixed isolation scenarios) together with the previously generated lookup key (composed of tenant identifier, fully qualified method name, and parameter hash value) in a preset query cache. When the same tenant, the same method, and the same parameters appear again, the system can directly retrieve the rewritten SQL from the memory cache and execute it, skipping all parsing, metadata query, isolation judgment, and syntax rewriting steps, significantly reducing CPU overhead and response latency.

[0114] In summary, this application provides a method for querying a tenant's data table. The method includes: receiving a data table query request containing an original lookup statement; parsing the original lookup statement to obtain the original table name of the data table to be queried and the tenant identifier of the tenant corresponding to the data table to be queried; based on the original table name of the data table to be queried and the tenant identifier of the tenant corresponding to the data table to be queried, searching through multiple created data tables to obtain a target created data table, wherein the original table name of the target created data table is consistent with the original table name of the data table to be queried, and the tenant identifier of the created tenant corresponding to the target created data table is consistent with the original table identifier of the tenant corresponding to the data table to be queried. The tenant identifier is consistent; the isolation level of the target created data table is obtained and determined as the isolation level of the data table to be queried; if the isolation level of the data table to be queried is row-level, the field structure in the original table lookup statement is rewritten based on the tenant identifier of the tenant corresponding to the data table to be queried, resulting in the first table lookup statement; if the isolation level of the data table to be queried is table-level, the original table name in the original table lookup statement is rewritten based on the tenant identifier of the tenant corresponding to the data table to be queried, resulting in the second table lookup statement; the first table lookup statement and / or the second table lookup statement are executed to obtain the data table query results of the tenant to be queried. This application accurately matches the tenant identifier with the original table name to the corresponding created data table, uses its isolation level as the isolation level of the data table to be queried, and intelligently generates execution statements adapted to row-level or table-level isolation, effectively avoiding query errors of tenant data tables caused by human misjudgment or omission, and significantly improving the accuracy and efficiency of data table queries in a multi-tenant environment.

[0115] This application also provides an electronic device in its embodiments. (See reference...) Figure 2 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 2 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0116] like Figure 2 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 201, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 202 or a program loaded from a storage device 208 into a random access memory (RAM) 203. When the electronic device is powered on, the RAM 203 also stores various programs and data required for the operation of the electronic device. The processing unit 201, ROM 202, and RAM 203 are interconnected via a bus 204. An input / output (I / O) interface 205 is also connected to the bus 204.

[0117] Typically, the following devices can be connected to I / O interface 205: input devices 206 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 207 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 208 including, for example, memory cards, hard drives, etc.; and communication devices 209. Communication device 209 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 2 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0118] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the methods provided in this application for recommending mobile banking products to bank users.

[0119] This application also provides a computer-readable storage medium carrying one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the methods provided in this application for recommending mobile banking products to bank users.

[0120] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0121] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0122] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0123] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for querying a tenant's data table, characterized in that, include: Receive a data table query request containing an original table lookup statement, and parse the original table lookup statement to obtain the original table name of the data table to be queried and the tenant identifier of the tenant to be queried corresponding to the data table to be queried. Based on the original table name of the data table to be queried and the tenant identifier of the tenant to be queried corresponding to the data table to be queried, the target created data table is found from multiple created data tables. The original table name of the target created data table is consistent with the original table name of the data table to be queried, and the tenant identifier of the created tenant corresponding to the target created data table is consistent with the tenant identifier of the tenant to be queried corresponding to the data table to be queried. Obtain the isolation level of the target created data table, and determine the isolation level of the target created data table as the isolation level of the data table to be queried; If the isolation level of the data table to be queried is row level, then the field structure in the original table lookup statement is rewritten based on the tenant identifier of the tenant to be queried corresponding to the data table to be queried, so as to obtain the first table lookup statement. If the isolation level of the data table to be queried is table level, then the original table name in the original table lookup statement is rewritten based on the tenant identifier of the tenant to be queried corresponding to the data table to be queried, so as to obtain the second table lookup statement. Execute the first table lookup statement and / or the second table lookup statement to obtain the data table query results of the tenant to be queried.

2. The method for querying a tenant's data table according to claim 1, characterized in that, The step of parsing the original table lookup statement to obtain the original table name of the data table to be queried and the tenant identifier of the tenant to be queried corresponding to the data table includes: The original table lookup statement is parsed to obtain the original table name of the data table to be queried; Obtain the business method corresponding to the original table lookup statement, and determine whether there is an annotation for the tenant to be queried corresponding to the data table to be queried in the business method corresponding to the original table lookup statement; If the business method corresponding to the original table lookup statement contains an annotation for the tenant to be queried corresponding to the data table to be queried, then the annotation for the tenant to be queried corresponding to the data table to be queried is parsed to obtain the tenant identifier of the tenant to be queried corresponding to the data table to be queried. If the business method corresponding to the original table lookup statement does not contain an annotation for the tenant to be queried corresponding to the data table to be queried, then the input parameters of the business method corresponding to the original table lookup statement are parsed to obtain the tenant identifier of the tenant to be queried corresponding to the data table to be queried.

3. The method for querying a tenant's data table according to claim 1, characterized in that, After receiving a data table query request containing an original lookup statement and parsing the original lookup statement to obtain the original table name of the data table to be queried and the tenant identifier of the tenant corresponding to the data table to be queried, the method further includes: Obtain the method identifier of the business method corresponding to the original table lookup statement and the input parameters of the business method, and perform hash calculation on the input parameters of the business method to obtain the hash value of the input parameters of the business method; Based on the tenant identifier of the tenant to be queried corresponding to the data table to be queried, the method identifier of the business method, and the hash value of the input parameters of the business method, a lookup key corresponding to the data table to be queried is generated; Determine whether there is a lookup cache key in the preset query cache library that matches the lookup key corresponding to the data table to be queried. If there is a lookup cache key in the preset query cache library that matches the lookup key corresponding to the data table to be queried, then obtain the lookup statement corresponding to the lookup cache key. Execute the table lookup statement corresponding to the table lookup cache key to obtain the data table query result of the tenant to be queried.

4. The method for querying a tenant's data table according to claim 1, characterized in that, Before receiving the data table query request containing the original lookup statement, the method further includes: Receive a data table creation request including the original table creation statement, and parse the original table creation statement to obtain the original table name of the data table to be created, the historical data increment sequence of the data table to be created, and the tenant identifier of the tenant to be created corresponding to the data table to be created. The historical data increment sequence of the data table to be created is input into the time series model to obtain the current data increment of the data table to be created; Based on the current data increment of the data table to be created, determine the isolation level of the data table to be created; If the isolation level of the data table to be created is row-level, then the field structure in the original table creation statement is rewritten based on the tenant identifier of the tenant to be created corresponding to the data table to be created, to obtain the first table creation statement, and the first table creation statement is executed. If the isolation level of the data table to be created is row-level, then the original table name of the original table creation statement is rewritten based on the tenant identifier of the tenant to be created corresponding to the data table to be created, to obtain a second table creation statement, and the second table creation statement is executed.

5. The method for querying a tenant's data table according to claim 4, characterized in that, The step of determining the isolation level of the data table to be created based on the current data increment includes: Determine whether the data table type of the data table to be created is a preset data table type; If the data table type of the data table to be created is the preset data table type, then the isolation level of the data table to be created is determined to be the row level; If the data table type of the data table to be created is not the preset data table type, then determine whether the current data increment of the data table to be created is greater than the preset data increment; If the current data increment of the data table to be created is greater than the preset data increment, then the isolation level of the data table to be created is determined to be the table level; If the current data increment of the data table to be created is not greater than the preset data increment, then the isolation level of the data table to be created is determined to be the row level.

6. The method for querying a tenant's data table according to claim 4, characterized in that, Before inputting the historical data increment sequence of the data table to be created into the time series model to obtain the current data increment of the data table to be created, the method further includes: Based on multiple historical data increments in the historical data increment sequence of the data table to be created, the mean and standard deviation of the historical data increment sequence are calculated. The range of historical data increments is determined based on the mean and standard deviation of the historical data increment sequence. Based on the historical data increment range, determine a first historical data increment that does not belong to the historical data increment range and a second historical data increment that belongs to the historical data increment range from multiple historical data increments in the historical data increment sequence of the data table to be created; Based on the second historical data increment, the first historical data increment is corrected to obtain the corrected first historical data increment, and a new historical data increment sequence of the data table to be created is constructed using the second historical data increment and the corrected first historical data increment.

7. The method for querying a tenant's data table according to claim 6, characterized in that, The step of correcting the first historical data increment based on the second historical data increment to obtain the corrected first historical data increment includes: Obtain the second historical data increment corresponding to the target time period, wherein the target time period is determined based on the time corresponding to the first historical data increment; The target linear equation is obtained by fitting the second historical data increment corresponding to the target time period, and the target historical data increment at the time corresponding to the first historical data increment is obtained by using the target linear equation. The target historical data increment is determined as the corrected first historical data increment.

8. A computer program product, characterized in that, Includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the method for querying a tenant's data table as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is configured to execute the computer program to enable the electronic device to implement the tenant data table query method as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the tenant's data table query method as described in any one of claims 1 to 7.

Images