Database capacity expansion method, device and equipment and computer readable storage medium
By collecting multi-dimensional data and using a hybrid prediction model to generate expansion plans, the problem of insufficient prediction of database expansion in the cloud computing environment was solved, and the stability and resource optimization of high-concurrency services were achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-14
- Publication Date
- 2026-04-07
AI Technical Summary
Existing database expansion technologies struggle to anticipate demand, achieve multi-dimensional collaboration, and optimize costs in cloud computing environments, leading to service lag or resource waste during high-concurrency operations.
By collecting historical load data, real-time business data, and business calendar tagging data, a multi-dimensional correlation analysis is performed using a hybrid prediction model combining the Prophet algorithm and LSTM neural network to generate load prediction results. Based on these results, a capacity expansion plan is generated, including differentiated configuration evaluation index weights and cost decision trees, to optimize the capacity expansion scheme.
It achieves precise matching of database resource requirements, avoids service lag during peak periods and resource waste during off-peak periods, and improves system operating efficiency and cost optimization.
Smart Images
Figure CN121808103A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of database management, and in particular to a database expansion method, apparatus, device, and computer-readable storage medium. Background Technology
[0002] With the acceleration of digital transformation, enterprise businesses are gradually migrating to cloud computing environments. The core characteristics of cloud computing—on-demand allocation and dynamic scaling—have become key infrastructure supporting the large-scale development of industries such as e-commerce, finance, and social media. Among these, databases, as the core component for storing core business data, directly determine business continuity in terms of performance and stability. Current business scenarios place extreme demands on the resource adaptability of databases: ensuring low latency for read and write operations and high reliability for transactions during traffic surges, while avoiding cost waste due to resource idleness during off-peak periods. This has become the core challenge of database operation and maintenance in a cloud computing environment.
[0003] Current mainstream database scaling technologies include threshold-based reactive scaling and static scaling strategies. Threshold-based reactive scaling passively triggers scaling based on preset CPU and memory utilization thresholds (e.g., CPU > 80%). However, the delay from exceeding the threshold to scaling completion (typically 5-10 minutes) can directly lead to service lag and request failures in high-concurrency scenarios. Static scaling strategies execute operations based on fixed schedules or single metrics, which can easily lead to resource mismatches such as insufficient resources during peak periods and resource redundancy during off-peak periods, resulting in inappropriate scaling decisions. These problems all point to a core need: an intelligent automatic database scaling system that can predict demand in advance, coordinate across multiple dimensions, optimize costs, and adapt to heterogeneous environments, in order to solve the pain points of database operation and maintenance in high-concurrency cloud computing environments.
[0004] Therefore, how to achieve intelligent and automatic database scaling to solve the pain points of database operation and maintenance for high-concurrency businesses in cloud computing environments is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0005] The purpose of this invention is to provide at least one database expansion method, apparatus, device, and computer-readable storage medium, which can realize intelligent and automatic database expansion and solve the pain points of database operation and maintenance in high-concurrency business under cloud computing environment.
[0006] To address the aforementioned technical problems, at least one embodiment of this application provides a database expansion method, comprising: Collect historical load data, real-time business data, and business calendar marker data from the database; the business calendar marker data includes preset special business event information. The business calendar tag data is converted into quantitative parameters and used as business prediction parameters; The historical load data, the real-time business data, and the business prediction parameters are input into the prediction model. Based on the business prediction parameters and real-time monitoring indicators, the prediction model performs a multi-dimensional correlation analysis of the database resource demand within the target time period based on the historical load data and the real-time business data, and generates a load prediction result. Based on the load prediction results, a database expansion plan is generated.
[0007] In one embodiment, the prediction model is a hybrid prediction model combining the Prophet algorithm and an LSTM neural network. Based on the business prediction parameters and real-time monitoring indicators, the prediction model performs a multi-dimensional correlation analysis of the historical load data and the real-time business data to predict database resource requirements within a target time period, including: The Prophet algorithm extracts and fits the periodic features in the historical load data and the real-time business data based on the business prediction parameters and real-time monitoring indicators, and outputs the first prediction data. The LSTM neural network learns and predicts the nonlinear features and sudden fluctuation features in the historical load data and the real-time business data based on the business prediction parameters and real-time monitoring indicators, and outputs the second prediction data. The load prediction result is generated by combining the first prediction data and the second prediction data.
[0008] In one embodiment, before inputting the historical load data, the real-time service data, and the service prediction parameters into the prediction model, the method further includes: Construct a real-time evaluation matrix containing several specified evaluation indicators and their corresponding weights, and the weights corresponding to the specified evaluation indicators are configured differently according to the business scenario to which the database belongs; Collect the real-time values of the specified evaluation indicators in the database, and perform weighted calculation and accumulation of the real-time values according to the differentiated weights of each indicator in the real-time evaluation matrix to obtain the resource health score; When the resource health score is lower than a preset threshold, the step of inputting the historical load data, the real-time business data, and the business prediction parameters into the prediction model is executed.
[0009] In one embodiment, generating the database expansion plan based on the load prediction result includes: Determine whether the business scenario corresponding to the load prediction result belongs to the special business event; If it falls under the aforementioned special business event, an enhanced expansion plan with additional resource security margin will be generated. If it does not fall under the aforementioned special business events, a gradual expansion plan adapted to the growth rate of regular business will be generated.
[0010] In one embodiment, generating the database expansion plan based on the load prediction result includes: Construct a cost decision tree that includes several cloud database instance specifications; the cost decision tree is associated with the cloud vendor's billing rules corresponding to each instance specification. Based on the load prediction results, the cost decision tree is invoked to calculate the resource costs of at least two candidate expansion schemes that meet the database resource requirements; The candidate expansion scheme with the lowest resource cost is selected as the expansion plan.
[0011] In one embodiment, if the database is deployed in a cluster, after generating the database expansion plan based on the load prediction results, the method further includes: Obtain the scaling and adaptation attribute information of each node in the cluster of the database; Based on the aforementioned expansion and adaptation attribute information, the node with the best overall adaptation performance is selected as the expansion execution node; The expansion execution node synchronizes the expansion plan to all nodes in the cluster and drives each node to collaboratively execute the expansion plan.
[0012] In one embodiment, if the cluster contains at least two different types of heterogeneous databases, it further includes: Collect resource association data of various types of databases in the heterogeneous database; If the expansion plan includes node expansion operations for the first type of database in the heterogeneous database, determine whether other databases that have a dependency relationship with the first type of database need to be expanded based on the resource association data. If it is determined that associated expansion is required, an expansion sub-plan for the other databases is generated based on the performance parameters after the expansion operation and the resource association data. The expansion execution node synchronously drives the execution of the expansion plan and the expansion sub-plan.
[0013] At least one embodiment of this application also provides a database expansion device, comprising: The data acquisition module is used to collect historical load data, real-time business data, and business calendar marker data from the database; the business calendar marker data includes preset special business event information. The prediction parameter conversion module is used to convert the business calendar marker data into quantitative parameters as business prediction parameters; The load prediction module is used to input the historical load data, the real-time business data and the business prediction parameters into the prediction model. The prediction model, based on the business prediction parameters and real-time monitoring indicators, performs a multi-dimensional correlation analysis on the historical load data and the real-time business data to predict the database resource demand within the target time period and generates load prediction results. The contingency plan generation module is used to generate a database expansion contingency plan based on the load prediction results.
[0014] At least one embodiment of this application also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the database expansion method described above.
[0015] At least one embodiment of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the database expansion method described above.
[0016] The database expansion method provided in this application breaks through the limitations of traditional single data sources. It simultaneously collects historical load data, real-time business data, and business calendar marker data. Historical load data is used to capture periodic resource demand patterns, real-time business data is used to anchor the current operating baseline, and business calendar marker data is used to identify special business events such as Double 11. This three-in-one approach provides complete data support for subsequent predictions of past, present, and future business impacts, solving the problem that traditional solutions cannot predict business fluctuations due to insufficient data dimensions and avoiding sudden resource gaps caused by special events. Then, a predictive model is used to perform multi-dimensional correlation analysis on multiple types of data to proactively generate load prediction results for the target time period. Based on these results, an expansion plan is generated in advance, completely eliminating the passive mode of formulating a plan only after a threshold is triggered. This allows for advance preparation for expansion, fundamentally eliminating the risk of service lag during peak periods. The expansion plan generated based on the prediction results can accurately match the resource demand of the target time period, achieving automatic and intelligent expansion and ensuring the system's operating efficiency. Attached Figure Description
[0017] One or more embodiments are illustrated by way of example with reference to the accompanying drawings, and these illustrative descriptions do not constitute a limitation on the embodiments.
[0018] Figure 1 This is a flowchart of a database expansion method provided in one embodiment of this application; Figure 2 This is a schematic diagram of a database expansion device provided in one embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation
[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the various embodiments of this application to help readers better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is for the convenience of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.
[0020] This invention proposes a database expansion method. The implementation details of the database expansion method in this embodiment are described below. The following content is only for the convenience of understanding and is not necessary for implementing this solution.
[0021] Example 1: The specific process of the database expansion method in this embodiment can be described as follows: Figure 1 As shown, it includes: Step 101: Collect historical load data, real-time business data, and business calendar tag data from the database.
[0022] Historical load data refers to time-series resource consumption data generated during the past operation of the database, such as historical CPU utilization, memory usage, IOPS (Input / Output Operations Per Second), and transaction volume.
[0023] Real-time business data refers to the dynamic business and resource status data of the database during its current runtime, such as transaction throughput, cache hit rate, connection pool wait time, current number of connections, real-time read and write request volume, instantaneous transaction throughput, etc.
[0024] Business calendar tag data refers to information data that is manually pre-labeled in conjunction with business operation plans and includes special business events, such as e-commerce Double 11, promotional activities, and peak traffic during holidays.
[0025] Systematically collect these three types of core data related to database operation. Historical load data can be used by the model to capture the periodic patterns of database resource demand, such as daily and weekly traffic fluctuation patterns. Real-time business data can help the model anchor the current operating baseline and improve the timeliness of prediction. Business calendar marker data can make up for the shortcomings of pure algorithm prediction being out of touch with actual business, allowing the model to identify non-periodic and sudden resource demands brought about by special business events in advance.
[0026] Compared to the limitations of traditional expansion solutions that rely solely on a single real-time metric or static rules, this multi-dimensional data collection method provides a more complete data foundation for subsequent load forecasting. On the one hand, by introducing business calendar marker data, it enables proactive prediction of special business events, laying the data foundation for triggering expansion in advance and avoiding service congestion during peak periods. This addresses the technical pain points of traditional solutions, such as passive response, delayed expansion, and inability to adapt to business fluctuations, ensuring the stability of the database and the accuracy of resource allocation in high-concurrency scenarios. On the other hand, by combining historical and real-time data, the model's prediction accuracy for regular business fluctuations can be improved.
[0027] Step 102: Convert the business calendar tag data into quantitative parameters, which will be used as business forecasting parameters.
[0028] Business calendar data, which is mainly qualitatively descriptive (such as information on special business events like the Double 11 promotion and holiday peaks), is transformed into numerical forms that the prediction model can recognize and calculate (such as event start / end timestamps, weighting coefficients of the event's impact on resource demand, and baseline values of load increase during the event). The transformed quantitative values are then defined as business prediction parameters for subsequent model prediction and analysis of database resource demand.
[0029] Through quantitative transformation, a clear numerical correlation can be established between special business events and changes in database resource requirements. For example, Double 11 can be transformed into a time interval [11.1-11.11] with a load increase coefficient of 1.8, enabling the model to accurately capture the impact of special events on resource requirements. The specific parameter transformation method is not limited in this embodiment; relevant techniques in the prior art can be referenced, and will not be elaborated further here.
[0030] Step 103: Input historical load data, real-time business data, and business forecast parameters into the forecast model. Based on the business forecast parameters and real-time monitoring indicators, the forecast model performs a multi-dimensional correlation analysis of the database resource demand within the target time period based on the historical load data and real-time business data, and generates load forecast results.
[0031] Traditional solutions rely on resource thresholds to trigger expansion (e.g., expansion only occurs when CPU usage exceeds 80%), resulting in significant lag. To address this, this method inputs historical load data reflecting past database resource consumption patterns, real-time business data reflecting current operational status, and business prediction parameters quantifying the impact of business events into a pre-defined prediction model. The model uses business prediction parameters (quantitative characteristics associated with specific business events) and real-time monitoring metrics (e.g., real-time CPU utilization, instantaneous IOPS) as analytical anchors. It performs multi-dimensional correlation calculations between periodic patterns in historical load data (e.g., daily / weekly traffic fluctuations) and dynamic trends in real-time business data, ultimately outputting the specific resource requirements (CPU, memory, IOPS, etc.) for the database within a target time period (e.g., the next 15-30 minutes), i.e., the load prediction result.
[0032] This step, through multiple data inputs and model correlation analysis, provides comprehensive data support for prediction of past, present, and future business impacts, compared to traditional solutions that rely solely on a single real-time indicator. It combines historical load data (defining patterns), real-time business data (defining current status), and business prediction parameters (defining special events). This method can accurately predict resource demand and provide a basis for decision-making to trigger capacity expansion in advance. At the same time, combining business prediction parameters allows the model to identify non-periodic load fluctuations during special business events (such as Double 11), avoiding prediction biases caused by relying solely on historical data and ensuring that the prediction results closely match the actual business scenario.
[0033] In this embodiment, the specific model type and structure of the prediction model are not limited, and will be described in detail in subsequent embodiments.
[0034] Step 104: Generate a database expansion plan based on the load prediction results.
[0035] Based on the load forecast results, such as the specific requirements for CPU, memory, IOPS and other resources required by the database within the target time period, and combined with the characteristics of the business scenario and cost optimization goals, a database resource expansion plan that can be directly executed is generated and transformed into a specific and operable execution plan.
[0036] The expansion plan may include, but is not limited to, key aspects such as: determining the type of resources to be expanded (e.g., CPU expansion, memory expansion, or IOPS optimization), the scale of expansion (e.g., increasing the number of CPU cores, increasing the memory capacity), and the expansion method (e.g., expanding the master node, adding read-only replicas). This embodiment does not limit these aspects.
[0037] After generating the expansion plan, a resource rationality verification can be performed. This verification includes, but is not limited to, confirming whether the expansion plan meets the database's performance requirements within the target time period and whether it complies with cloud platform resource scheduling constraints. Once the verification passes, it is determined as the final expansion plan. Of course, this verification step can be omitted; this embodiment does not limit this, and appropriate configurations can be made according to the needs of the actual application scenario, which will not be elaborated upon here.
[0038] Based on the above introduction, the database expansion method provided in this embodiment breaks through the limitations of traditional single data sources. It simultaneously collects historical load data, real-time business data, and business calendar marker data. Historical load data is used to capture periodic resource demand patterns, real-time business data is used to anchor the current operating baseline, and business calendar marker data is used to identify special business events such as Double 11. This three-in-one approach provides complete data support for subsequent predictions of past, present, and future business impacts, solving the problem that traditional solutions cannot predict business fluctuations due to insufficient data dimensions and avoiding sudden resource gaps caused by special events. Then, a predictive model is used to perform multi-dimensional correlation analysis on multiple types of data to proactively generate load prediction results for the target time period. Based on these results, an expansion plan is generated in advance, completely eliminating the passive mode of formulating a plan only after the traditional threshold is triggered. This allows for early expansion preparation and fundamentally eliminates the risk of service lag during peak periods. The expansion plan generated based on the prediction results can accurately match the resource demand of the target time period, achieving automatic and intelligent expansion and ensuring the system's operating efficiency.
[0039] Example 2: The above embodiments do not limit the specific model type and structure of the prediction model; models such as ARIMA (Autoregressive Integral Moving Average) and GRU (Gated Recurrent Unit) can be used. To address the technical shortcomings of traditional single prediction models and the problem of predictions being detached from actual business needs, this embodiment proposes a hybrid prediction model consisting of the Prophet algorithm (Facebook Prophet) and an LSTM neural network (Long Short-Term Memory). This model uses two models to process different data features separately and then fuses them to generate the final prediction result. Specifically, if the prediction model is a hybrid model combining the Prophet algorithm and the LSTM neural network, then step 103, which involves the prediction model performing a multi-dimensional correlation analysis of historical load data and real-time business data to predict database resource requirements within the target time period based on business prediction parameters and real-time monitoring indicators, can be executed according to the following sub-steps: Step 31: Using the Prophet algorithm, based on business forecasting parameters and real-time monitoring indicators, extract and fit periodic features from historical load data and real-time business data, and output the first forecast data.
[0040] The Prophet algorithm excels at capturing explicit periodic data patterns. The model uses business forecast parameters (quantified business calendar-marked data) and real-time monitoring indicators as common inputs. The Prophet algorithm first focuses on the periodic characteristics (such as daily access peaks, weekend traffic fluctuations, monthly business patterns, etc.) in historical load data and real-time business data. Through data extraction and fitting, it outputs the first forecast data reflecting periodic resource demand.
[0041] Step 32: The LSTM neural network learns and predicts the nonlinear features and sudden fluctuation features in historical load data and real-time business data based on business prediction parameters and real-time monitoring indicators, and outputs the second prediction data.
[0042] LSTM neural networks excel at learning the nonlinear characteristics and burst patterns of sequential data. They focus on the nonlinear variation features (such as nonlinear trends in business growth and dynamic fluctuations in resource consumption) and burst fluctuation features (such as instantaneous traffic surges during flash sales and sudden load changes during temporary marketing campaigns). Through model learning and prediction output, they capture secondary predictive data on non-periodic resource demand. Step 33: Combine the first prediction data and the second prediction data to generate the load prediction result.
[0043] Finally, the first and second prediction data are merged. The specific fusion method used is not limited in this embodiment; for example, weighted fusion or feature complementation can be used. By weighted fusion or feature complementation of the two prediction data, a load prediction result that takes into account both periodicity and non-periodicity and fits the actual business needs is generated.
[0044] Compared to single prediction models and traditional threshold-triggered logic, the method provided in this embodiment has significant technical advantages in its model structure and prediction steps: First, it achieves comprehensive coverage of data features, retaining Prophet's accurate ability to capture periodic features while leveraging LSTM's efficient learning ability for nonlinear and burst features. This avoids the omission of features in complex load data by a single model, resulting in a prediction accuracy far exceeding that of a single model. It can effectively identify composite load scenarios of regular periodic fluctuations plus sudden traffic surges. Second, it strengthens the synergy between business and technology. By introducing business prediction parameters through dual models, the prediction results not only conform to the patterns of technical indicators such as CPU utilization and IOPS, but also accurately reflect business operation plans (such as special promotions and product launches). This solves the problem of the disconnect between pure technical models and actual business, and reduces resource misallocation caused by business prediction deviations.
[0045] Example 3: Regarding the issue of triggering database expansion, traditional solutions often rely on a single CPU or memory metric to determine whether expansion is needed. This is prone to misjudgment due to anomalies such as a surge in slow queries even when CPU usage is below the threshold. Furthermore, these solutions fail to consider the varying sensitivities of different business scenarios to metrics (e.g., the financial sector is more sensitive to connection pool wait times). Blindly triggering the prediction process also leads to wasted computing resources. Building upon the above embodiments, to further achieve on-demand prediction and resource optimization, before inputting historical load data, real-time business data, and business prediction parameters into the prediction model in step 103, the following steps can be further performed: Step 105: Construct a real-time evaluation matrix containing several specified evaluation indicators and their corresponding weights, and the weights corresponding to the specified evaluation indicators are configured differently according to the business scenario to which the database belongs.
[0046] First, key evaluation indicators (KPIs) are selected from the core dimensions of database operation, clarifying the monitoring scope and calculation standards for each indicator. Then, based on the core requirements of the business scenario to which the database belongs—for example, financial systems have high requirements for data interaction stability, requiring a focus on connection pool wait time and transaction throughput; e-commerce platforms are sensitive to read / write response speed, prioritizing IOPS and slow query rate—differentiated weights are assigned to different indicators. For instance, in a financial scenario, connection pool wait time is weighted at 20%, and transaction throughput at 18%; in an e-commerce scenario, IOPS is weighted at 22%, and slow query rate at 20%. Finally, the specified KPIs and their corresponding differentiated weights are structurally integrated in a matrix format to form a real-time evaluation matrix that can be invoked in real time and dynamically adapted to business scenarios, providing a standardized evaluation framework for subsequent computing resource health scoring. By configuring differentiated weights, the evaluation criteria are deeply aligned with the core requirements of business scenarios (e.g., in financial scenarios, the weight of connection pool waiting time is strengthened to ensure transaction stability, while in e-commerce scenarios, the weight of IOPS is increased to cope with read and write pressure during peak sales periods). This ensures that the evaluation criteria of the real-time evaluation matrix are deeply anchored to the core performance requirements of different scenarios. For example, in financial scenarios, transaction stability must be prioritized, so the weights of connection pool waiting time and transaction throughput are increased to ensure accurate capture of key risks affecting transaction continuity in this scenario. In e-commerce scenarios, high-concurrency read and write operations must be handled, so the weights of IOPS and slow query rate are strengthened to promptly identify storage performance bottlenecks during peak sales periods, thus solving the problem that traditional one-size-fits-all evaluation methods cannot match the needs of different industries.
[0047] One set of specified evaluation metrics includes: CPU utilization, memory usage, IOPS, transaction throughput, cache hit rate, connection pool wait time, and slow query rate. These seven metrics cover three dimensions: resource consumption (CPU, memory, IOPS), business performance (transaction throughput, slow query rate), and operational efficiency (cache hit rate, connection pool wait time). They comprehensively reflect the actual operating status of the database and avoid misjudgments during capacity expansion due to incomplete metrics. Of course, other types of metrics can be set for different evaluation needs. This embodiment does not limit this; it only uses the above-mentioned metric types as examples. Other configurations can refer to the description in this embodiment and will not be repeated here.
[0048] Step 106: Collect the real-time values of the specified evaluation indicators in the database, and perform weighted calculation and accumulation of the real-time values according to the differentiated weights of each indicator in the real-time evaluation matrix to obtain the resource health score.
[0049] First, regarding the database's operational status, the current actual values of several specified evaluation indicators (defined in the previously constructed real-time evaluation matrix) are collected in real time. Based on the indicator weights configured differently according to the database's business scenario (such as finance or e-commerce) in the real-time evaluation matrix, the real-time values of each collected indicator are calculated by multiplying the real-time value by the corresponding weight. Finally, all weighted results are summed to obtain a value that can quantify the overall status of the database's current resource consumption, business performance, and operational efficiency, namely the resource health score. This score can be directly used to determine whether the database is approaching or has reached a performance bottleneck.
[0050] Step 107: When the resource health score is lower than the preset threshold, the step of inputting historical load data, real-time business data and business prediction parameters into the prediction model is executed.
[0051] Resource health score is a core indicator that quantitatively reflects the current overall operating status of the database. When the score is lower than the preset threshold, it indicates that the database is approaching or has reached a performance bottleneck. This may result in risks such as CPU load approaching the limit, IOPS response delay, increased slow query rate, or connection pool waiting time affecting normal business interaction. In this case, the subsequent load prediction process needs to be initiated. If the resource health score is not lower than the preset threshold, this embodiment does not limit the handling method in this case. It can directly trigger the next round of expansion trigger judgment process, or it can be triggered after the preset time interval is reached. This will not be elaborated further here.
[0052] Based on the above introduction, the expansion triggering method provided in this embodiment, by configuring the weights of specified evaluation indicators such as CPU utilization, memory usage, IOPS, and connection pool wait time differently for the business scenario to which the database belongs, enables the evaluation criteria of the real-time evaluation matrix to be deeply anchored to the core performance requirements of different scenarios. This differentiated configuration makes the subsequent resource health score calculated based on weights no longer a general value that is added indiscriminately in the traditional solution, but a quantitative basis that can accurately reflect the real performance status of the database under specific business scenarios. This avoids the core risk omission caused by indiscriminate indicator weights, and ensures that the prediction process is only started when the database triggers the real performance risk under the scenario, effectively reducing unnecessary consumption of computing resources, and providing a triggering basis that fits the actual business needs for subsequent load prediction and expansion plan generation.
[0053] Example 4: After generating load forecast results, traditional scaling solutions cannot distinguish between the resource requirements of special business events and regular business growth, resulting in significant shortcomings in both scenarios: during special business events, the lack of reserved redundant resources can easily lead to service disruptions due to sudden traffic surges; during regular business growth, excessive scaling can result in long-term idle and wasted resources. To accurately adapt to the resource requirements of different business scenarios, step 104, which generates a database scaling plan based on the load forecast results, can be executed as follows: determine whether the business scenario corresponding to the load forecast results belongs to a special business event; if it belongs to a special business event, generate an enhanced scaling plan that includes additional resource safety margins; if it does not belong to a special business event, generate a gradual scaling plan that adapts to the growth rate of regular business.
[0054] After obtaining the load forecast results for the target time period, the first step is to determine the business scenario corresponding to the forecast result. For example, is the predicted traffic peak due to daily operations or a specific event? Is it a special business event that was manually marked in the business calendar? Special business events include promotional activities and holiday peaks, such as Double 11. If it is determined to be a special business event, it means that there is a non-periodic and sudden high load demand during the forecast period. An enhanced expansion plan with additional resource safety margin needs to be generated. An enhanced expansion plan with additional resource safety margin means that on the basis of the basic resource demand during the predicted target time period, an additional proportion or fixed amount of resource redundancy is configured. For example, 20%-30% of resources are reserved on the basis of the predicted resource demand to cope with instantaneous traffic fluctuations. If it is determined to be a normal business scenario, such as daily business growth or periodic traffic peaks, a gradual expansion plan that matches the normal growth rate in the load forecast result is generated. For example, resources are gradually increased according to the predicted demand to avoid excessive expansion at one time and to achieve a precise match between resource supply and business demand.
[0055] The capacity expansion plan generation method provided in this embodiment combines special event information marked in the previous business calendar (which has been converted into business prediction parameters for load prediction) to ensure that the capacity expansion plan generation is no longer divorced from actual business operations, but is deeply bound to business scenarios. For enhanced capacity expansion plans for special business events, additional resource safety margins can be used to cope with sudden traffic surges (such as the instantaneous request peak of a flash sale), avoiding the capacity expansion delays and service unavailability caused by the failure to predict special events in traditional solutions (the disclosure document points out that traditional solutions respond passively and cannot adapt to business fluctuations). For gradual capacity expansion plans for regular businesses, resources can be allocated gradually according to the actual growth rate, avoiding the resource idleness caused by the one-size-fits-all expansion of traditional solutions, reducing cloud resource costs, and upgrading from a generalized plan to a scenario-based precise plan, which can accurately adapt to the resource needs of different business scenarios.
[0056] Example 5: Example 4 introduces a contingency plan configuration method based on special business events. This example proposes an adaptive cost control contingency plan configuration method from a cost perspective. It should be noted that the contingency plan configuration method proposed in this example can be used simultaneously with the method provided in Example 4, and can also be applied simultaneously with contingency plan configuration methods in other directions.
[0057] Specifically, step 104, generating the database expansion plan based on the load prediction results, can be performed according to the following sub-steps: Step 41: Construct a cost decision tree containing several cloud database instance specifications; associate the cost decision tree with the cloud vendor's billing rules corresponding to each instance specification.
[0058] Traditional expansion solutions only focus on meeting performance requirements such as CPU and IOPS, completely ignoring the differentiated billing rules of cloud vendors (such as the cost difference between billing by the second and by the hour, and the cost difference between expanding read-only replicas and primary instances). This leads to problems such as blindly adding primary instances for expansion with hourly billing when high load lasts only 10 minutes, instead of using lower-cost read-only replicas, causing a surge in cloud resource costs. To address this, this embodiment proposes an expansion solution that binds instance specifications to billing rules.
[0059] First, several cloud database instance specifications covering database expansion needs are selected (including primary instances with different CPU core counts, memory capacity, and storage types, as well as read-only replicas adapted for read load balancing). These instance specifications serve as the core nodes of the decision tree, and a tree structure is constructed based on resource demand matching. For example, low load demand corresponds to small-specification instance branches, and high load demand corresponds to large-specification instances or multiple instance combinations branches. At the same time, each instance specification is deeply associated with the billing rules of mainstream cloud platforms. That is, each instance specification node is bound to corresponding billing information, such as AWS's per-second billing unit price, Azure's per-minute billing tiered pricing, cost differences between different payment models (pay-as-you-go / annual / monthly subscription), and additional fee rules for temporary upgrades and instance expansion. Finally, a structured cost decision tree with instance specification stratification and billing rule binding is formed, providing a standardized framework for subsequent computational expansion solution costs.
[0060] By associating billing rules with mainstream cloud platforms, the cost decision tree can adapt to the billing differences of different vendors. For example, AWS and Azure have different billing units and unit price tiers, making cost calculation more in line with the actual cloud environment. The decision tree integrates 200+ instance specifications and corresponding billing information, which can cover various expansion paths from single instance upgrades to multi-instance combinations (primary instance + read-only replicas). In subsequent calls, it can quickly calculate the cost of different paths, avoiding cost misjudgments caused by incomplete instance specification coverage and missing billing information in traditional solutions, and ensuring the comprehensiveness and accuracy of cost calculation.
[0061] Step 42: Based on the load forecast results, call the cost decision tree to calculate the resource costs of at least two candidate expansion schemes that meet the database resource requirements.
[0062] After obtaining the load forecast results for the target time period, the pre-built cost decision tree is invoked. Through the hierarchical matching logic of the decision tree, at least two candidate expansion schemes that can meet the above load forecast performance requirements are selected. For example, Scheme 1: Permanently upgrade the existing primary instance to a higher specification to carry the entire load; Scheme 2: Temporarily upgrade the existing primary instance and add 2 read-only replicas billed per second to share the read load; Scheme 3: Add only 3 read-only replicas billed per minute to cope with peak read load. Then, according to the billing rules of each instance specification bound in the decision tree, the full-process resource cost (including instance usage fees, additional costs for expansion operations, etc.) of each candidate scheme during the forecast load period is calculated to form clear cost comparison data.
[0063] In addition, the selected candidate expansion schemes can include, but are not limited to, at least one of the following expansion methods: temporary upgrade, read-only replica expansion, and horizontal node expansion. This can cover multiple expansion paths such as primary instance upgrade, temporary upgrade + read-only replica, and adding only read-only replicas. This avoids cost omissions caused by traditional solutions that only consider a single expansion method, such as ignoring the possibility that read-only replicas are cheaper than primary instance expansion, and lays the foundation for selecting the optimal cost scheme in the future.
[0064] Step 43: Select the candidate expansion scheme with the lowest resource cost as the expansion plan.
[0065] Based on the above introduction, the plan generation method provided in this embodiment constructs a cost decision tree that integrates multiple cloud database instances of various specifications and associates them with cloud vendor billing rules. It then uses the decision tree, combined with load prediction results, to calculate the costs of at least two candidate expansion schemes that meet database resource requirements. Finally, it selects the scheme with the lowest cost as the expansion plan. This method accurately adapts to the characteristics of the cloud environment, overcoming the cost waste caused by traditional expansion schemes ignoring differentiated billing rules of cloud vendors. Relying on the billing information bound to the decision tree, it can achieve optimization for complex scenarios. Furthermore, this method avoids the limitations of a single expansion approach. By comparing the costs of at least two candidate schemes, it avoids the rigid strategies of traditional schemes that rely solely on upgrading the primary instance, ensuring that the scheme has the potential for optimal cost while meeting performance requirements.
[0066] Example 6: The above embodiments do not limit the execution method of the expansion plan. However, traditional solutions often adopt single-point blind decision-making, selecting execution nodes without considering node role adaptability and resource status, which easily leads to low expansion efficiency. Furthermore, the lack of a cluster-level contingency plan synchronization and coordination mechanism can easily result in some nodes lagging or having configuration conflicts, causing data inconsistencies, split-brain problems, and other issues, failing to meet the overall performance balance requirements of the cluster. To achieve contingency plan synchronization and coordination, this embodiment proposes an execution method for the expansion plan. After generating the database expansion plan in step 104, the following steps can be further executed: Step 105: Obtain the scaling and adaptation attribute information of each node in the database cluster.
[0067] In a cluster deployment scenario, core attribute data directly related to scaling adaptability from all nodes is obtained, i.e., scaling adaptability attribute information. This information may include, but is not limited to: node role (master node / slave node / read-only replica, directly related to the division of scaling responsibilities, such as master nodes prioritizing write performance scaling, and slave nodes focusing on read load sharing scaling), current resource availability (number of idle CPU cores, remaining memory capacity, and IOPS idle allowance, reflecting the node's hardware capacity to handle scaling tasks), network topology location (stability and latency of network links between nodes, affecting the efficiency of scaling command synchronization and collaborative execution), and real-time load status (current CPU utilization, slow query rate, and connection pool occupancy, avoiding selecting high-load nodes for scaling to prevent service lag), etc. This provides a complete and quantitative evaluation basis for subsequently selecting the scaling execution node with the best overall adaptability performance.
[0068] In this embodiment, the method for obtaining the expansion adaptation attribute information of each node in the cluster is not limited. For example, it can be collected and summarized in real time through the lightweight monitoring agent deployed on each node of the cluster, i.e., the local node monitoring component. Of course, other methods can also be adopted, which will not be elaborated here.
[0069] Step 106: Select the node with the best overall adaptation performance based on the expansion and adaptation attribute information, and use it as the expansion execution node.
[0070] To avoid the pain points of blindly selecting execution nodes in traditional solutions, and to prevent problems such as low scaling efficiency and command synchronization failures due to insufficient node adaptability, this step selects nodes with the best overall adaptability performance, including role suitability, sufficient resources, and low real-time load. These nodes can quickly undertake scaling tasks, avoiding scaling process bottlenecks and service interruptions caused by node resource shortages or high loads. When the synchronization plan and driver are executed in coordination, decision conflicts caused by role mismatch can be reduced, ensuring that all nodes in the cluster execute scaling according to a unified plan.
[0071] Based on the business scenarios and expansion needs of the database cluster, different weights are configured for different attributes. For example, the master node has a higher role weight than the slave node because it needs to undertake the core write expansion responsibility; nodes with sufficient resource reserves and low real-time load have higher attribute weights than nodes with scarce resources and high load.
[0072] By weighting the attribute values and corresponding weights, a comprehensive adaptation performance score for each node is obtained. Finally, the node with the highest score, i.e., excellent role adaptability, sufficient resources, stable network, and low load, is selected as the expansion execution node and is responsible for the core responsibility of subsequent contingency plan synchronization and collaborative execution.
[0073] Step 107: The expansion execution node synchronizes the expansion plan to all nodes in the cluster and drives each node to execute the expansion plan collaboratively.
[0074] The expansion execution node with the best overall adaptation performance, selected earlier, distributes and synchronizes the generated expansion plan to all nodes in the cluster. The distribution and synchronization of the plan can rely on the improved Paxos protocol to ensure that the content of the plan received by each node is completely consistent. Of course, it can also rely on other protocols, but this embodiment does not limit it.
[0075] Subsequently, the scaling execution node drives all nodes to collaboratively execute the scaling operation based on the coordination rules in the plan. For example, for a heterogeneous MySQL+Redis cluster in an e-commerce scenario, the execution node first triggers the CPU and IOPS scaling of the MySQL master node. After the master node scaling is completed and confirmed to be stable, it then synchronously drives the Redis cache cluster to add new nodes to match the read and write capabilities of the master database. At the same time, it schedules slave nodes / read-only replicas to expand according to the plan to share the read load. During the execution process, the execution node can monitor the progress of each node in real time. If a node experiences execution delay (such as slow resource allocation of slave nodes), the scheduling priority is dynamically adjusted to ensure that the overall scaling rhythm of the cluster is consistent and to avoid the transfer of performance bottlenecks caused by the execution lag of a single node.
[0076] Existing technologies perform scaling on databases that trigger scaling requirements. However, if the cluster contains at least two different types of heterogeneous databases, such as MySQL relational database and Redis caching database, or MySQL and MongoDB non-relational database, and there are performance dependencies between the databases, the performance improvement of one database after scaling will cause a surge in requests to the dependent databases that have not been scaled, forming a new performance bottleneck. To avoid this problem and achieve distributed consistency coordination, this embodiment further proposes a method for collaborative scaling of clusters containing at least two different types of heterogeneous databases. Based on the above steps, the following steps can be further performed: Step 108: Collect resource association data of various types of databases in the heterogeneous database.
[0077] Resource-related data refers to performance dependency data between different types of databases, such as the mapping ratio of read / write requests between the MySQL master database and the Redis cache, and the correlation threshold between MySQL transaction throughput and MongoDB storage IOPS. Specifically, resource-related data includes: node configuration data, service load data, and interdependency data. Node configuration data at least includes node identifiers and hardware resource parameters; service load data at least includes the current number of connections and data read / write performance metrics; and interdependency data at least includes the service call relationships and data interaction paths between different types of databases.
[0078] Step 109: If the expansion plan includes node expansion operations for the first type of database in the heterogeneous database, determine whether other databases that have a dependency relationship with the first type of database need to be expanded based on the resource association data.
[0079] When the expansion plan involves expanding the nodes of a certain type of database (defined as the first type of database, such as the MySQL master database that handles order writing in e-commerce scenarios), based on the collected resource association data, it is determined whether other types of databases that have direct dependencies on the first type of database (such as the Redis cluster that caches order data) will experience potential bottlenecks due to the performance improvement after the expansion of the first type of database, such as the increased transaction throughput after the expansion of MySQL, which leads to a surge in Redis cache query requests, exceeding the current carrying capacity of the Redis node.
[0080] Step 110: If it is determined that associated expansion is required, then based on the performance parameters after the expansion operation and the resource association data, generate expansion sub-plans for other databases.
[0081] If the bottleneck risk is determined to exist, it is necessary to combine the performance parameters of the first type of database after expansion (such as the CPU idle rate and transaction processing peak after MySQL expansion) and resource-related data (such as the request volume ratio between MySQL and Redis) to generate expansion sub-plans for other databases, such as the number of new nodes added to the Redis cluster and the memory expansion specifications.
[0082] Step 111: The expansion execution node synchronously drives the execution of the expansion plan and expansion sub-plans.
[0083] The previously selected expansion execution nodes synchronously drive the execution of the main expansion plan for the first type of database and the expansion sub-plans for other databases, ensuring that the expansion operations of all related databases are consistent in timing and matched in configuration.
[0084] It should be noted that during the execution of the expansion plan and its sub-plans, in the event of anomalies such as network partitioning, the system can automatically downgrade to safe mode to strictly prevent resource conflicts or data inconsistencies caused by split-brain issues.
[0085] After each scaling up or down operation, data on actual performance improvements and cost changes can be collected to dynamically adjust metric weights and response thresholds. As the system accumulates runtime, the optimal resource allocation patterns for specific business scenarios can be gradually identified, forming a knowledge base of enterprise-specific elasticity strategies.
[0086] Based on the above introduction, this method can effectively eliminate the cluster performance imbalance problem caused by traditional single database expansion. By collecting resource association data between heterogeneous databases and judging the dependency relationship, it avoids the dependent database from becoming a new performance bottleneck due to only expanding the first type of database. It realizes the linkage expansion of the main plan and sub-plans, ensuring the balanced expansion of the overall system. In addition, by judging whether to expand the cluster in a related manner on demand instead of blindly expanding the entire cluster, it avoids unnecessary resource configuration waste, which can reduce the goal of cloud resource expenditure, while ensuring the precise matching of resource utilization and performance requirements.
[0087] Example 7: This embodiment relates to a database expansion device. A schematic diagram of the database expansion device in this embodiment is shown below. Figure 2 As shown, it includes: a data acquisition module 201, a prediction parameter conversion module 202, a load prediction module 203, and a contingency plan generation module 204.
[0088] The data acquisition module 201 is used to collect historical load data, real-time business data and business calendar marker data from the database; the business calendar marker data includes preset special business event information. The prediction parameter conversion module 202 is used to convert business calendar marker data into quantitative parameters as business prediction parameters. The load prediction module 203 is used to input historical load data, real-time business data and business prediction parameters into the prediction model. Based on the business prediction parameters and real-time monitoring indicators, the prediction model performs multi-dimensional correlation analysis on the database resource demand within the target time period of the historical load data and real-time business data, and generates load prediction results. The contingency plan generation module 204 is used to generate a database expansion contingency plan based on the load prediction results.
[0089] The database expansion device provided in this embodiment comprehensively collects historical load data, real-time business data, and business calendar marker data containing special business events through a data acquisition module. This breaks through the limitations of traditional solutions that rely solely on a single real-time indicator. By using a prediction parameter conversion module, the business calendar marker data is transformed into quantified business prediction parameters, achieving a deep integration of business operation intentions and prediction models. This allows for accurate identification of traffic patterns for special business events. The load prediction module performs correlation analysis on multi-dimensional data through a prediction model. It can capture both periodic load patterns and identify non-linear burst traffic, generating accurate load prediction results 15-30 minutes in advance, fundamentally eliminating the lag risk of traditional passive expansion. The contingency plan generation module generates adaptive contingency plans based on the prediction results, ensuring dynamic matching between resource supply and actual demand. This effectively avoids the shortcomings of traditional static strategies, such as insufficient or idle resources, ultimately achieving the dual goals of stable database operation under high-concurrency business and optimized cloud resource costs.
[0090] It should be noted that the contents of the database expansion device provided in this embodiment can be referred to in conjunction with the database expansion method provided in the above embodiments, and the repeated parts will not be described again in this embodiment.
[0091] Furthermore, it is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. In addition, to highlight the innovative aspects of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed in this application; however, this does not mean that other units are absent in this embodiment.
[0092] Example 8: Another embodiment of this application relates to an electronic device, such as... Figure 3 As shown, it includes: at least one processor 301; and a memory 302 communicatively connected to at least one processor 301; wherein the memory 302 stores instructions executable by at least one processor 301, the instructions being executed by at least one processor 301 to enable at least one processor 301 to perform the steps of the database expansion method in the above embodiments.
[0093] The memory and processor are connected via a bus, which can include any number of interconnecting buses and bridges, connecting various circuits of one or more processors and memories. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.
[0094] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.
[0095] Example 9: Another embodiment of this application relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the method embodiments described above.
[0096] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
[0097] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.
Claims
1. A database expansion method, characterized in that, include: Collect historical load data, real-time business data, and business calendar marker data from the database; The business calendar marker data includes preset special business event information; The business calendar tag data is converted into quantitative parameters and used as business prediction parameters; The historical load data, the real-time business data, and the business prediction parameters are input into the prediction model. Based on the business prediction parameters and real-time monitoring indicators, the prediction model performs a multi-dimensional correlation analysis of the database resource demand within the target time period based on the historical load data and the real-time business data, and generates a load prediction result. Based on the load prediction results, a database expansion plan is generated.
2. The database expansion method according to claim 1, characterized in that, The prediction model is a hybrid prediction model combining the Prophet algorithm and the LSTM neural network. Based on the business prediction parameters and real-time monitoring indicators, the prediction model performs a multi-dimensional correlation analysis of the historical load data and the real-time business data to predict database resource requirements within a target time period, including: The Prophet algorithm extracts and fits the periodic features in the historical load data and the real-time business data based on the business prediction parameters and real-time monitoring indicators, and outputs the first prediction data. The LSTM neural network learns and predicts the nonlinear features and sudden fluctuation features in the historical load data and the real-time business data based on the business prediction parameters and real-time monitoring indicators, and outputs the second prediction data. The load prediction result is generated by combining the first prediction data and the second prediction data.
3. The database expansion method according to claim 1, characterized in that, Before inputting the historical load data, the real-time business data, and the business prediction parameters into the prediction model, the method further includes: Construct a real-time evaluation matrix containing several specified evaluation indicators and their corresponding weights, and the weights corresponding to the specified evaluation indicators are configured differently according to the business scenario to which the database belongs; Collect the real-time values of the specified evaluation indicators in the database, and perform weighted calculation and accumulation of the real-time values according to the differentiated weights of each indicator in the real-time evaluation matrix to obtain the resource health score; When the resource health score is lower than a preset threshold, the step of inputting the historical load data, the real-time business data, and the business prediction parameters into the prediction model is executed.
4. The database expansion method according to claim 1, characterized in that, The process of generating the database expansion plan based on the load prediction results includes: Determine whether the business scenario corresponding to the load prediction result belongs to the special business event; If it falls under the aforementioned special business event, an enhanced expansion plan with additional resource security margin will be generated. If it does not fall under the aforementioned special business events, a gradual expansion plan adapted to the growth rate of regular business will be generated.
5. The database expansion method according to claim 1, characterized in that, The process of generating the database expansion plan based on the load prediction results includes: Construct a cost decision tree that includes several cloud database instance specifications; the cost decision tree is associated with the cloud vendor's billing rules corresponding to each instance specification. Based on the load prediction results, the cost decision tree is invoked to calculate the resource costs of at least two candidate expansion schemes that meet the database resource requirements; The candidate expansion scheme with the lowest resource cost is selected as the expansion plan.
6. The database expansion method according to claim 1, characterized in that, If the database is deployed in a cluster, after generating the database expansion plan based on the load prediction results, the following steps are also included: Obtain the scaling and adaptation attribute information of each node in the cluster of the database; Based on the aforementioned expansion and adaptation attribute information, the node with the best overall adaptation performance is selected as the expansion execution node; The expansion execution node synchronizes the expansion plan to all nodes in the cluster and drives each node to collaboratively execute the expansion plan.
7. The database expansion method according to claim 6, characterized in that, If the cluster contains at least two different types of heterogeneous databases, it also includes: Collect resource association data of various types of databases in the heterogeneous database; If the expansion plan includes node expansion operations for the first type of database in the heterogeneous database, determine whether other databases that have a dependency relationship with the first type of database need to be expanded based on the resource association data. If it is determined that associated expansion is required, an expansion sub-plan for the other databases is generated based on the performance parameters after the expansion operation and the resource association data. The expansion execution node synchronously drives the execution of the expansion plan and the expansion sub-plan.
8. A database expansion device, characterized in that, include: The data acquisition module is used to collect historical load data, real-time business data, and business calendar marker data from the database. The business calendar marker data includes preset special business event information; The prediction parameter conversion module is used to convert the business calendar marker data into quantitative parameters as business prediction parameters; The load prediction module is used to input the historical load data, the real-time business data and the business prediction parameters into the prediction model. The prediction model, based on the business prediction parameters and real-time monitoring indicators, performs a multi-dimensional correlation analysis on the historical load data and the real-time business data to predict the database resource demand within the target time period and generates load prediction results. The contingency plan generation module is used to generate a database expansion contingency plan based on the load prediction results.
9. An electronic device, characterized in that, include: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the database expansion method as described in any one of claims 1 to 7.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the database expansion method according to any one of claims 1 to 7.