A time series prediction model incremental training method and system based on a PostgreSQL database

Abstract

A method and system for incremental training of a time series forecasting model based on a PostgreSQL database is disclosed. The method includes: dividing the original time series data into time series data blocks and storing these blocks in a PostgreSQL table; sampling the PostgreSQL table using a two-layer time series sampling mechanism built into the PostgreSQL database to obtain a sampled dataset; inputting the sampled dataset into the built-in time series forecasting model of the PostgreSQL database for training, and outputting updated time series forecasting model parameters after training; using a row-column hybrid storage strategy to store the updated time series forecasting model parameters to complete the incremental training of the time series forecasting model; by inputting the sampled dataset obtained through the two-layer time series sampling mechanism into the built-in time series forecasting model of the PostgreSQL database for training, and by using a row-column hybrid storage strategy to save the updated model training parameters, the method achieves high efficiency, reliability, and lightweight incremental training of the time series forecasting model.

Description

Technical Field

[0001] This invention relates to the field of database and artificial intelligence interdisciplinary technology, specifically to an incremental training method and system for a time series prediction model based on a PostgreSQL database. Background Technology

[0002] In the field of time series prediction, traditional model training methods have the following significant limitations: training data must be exported from the database to an external computing framework, resulting in long data transfer paths, high I / O overhead, low training efficiency, and a high risk of data privacy leaks. Simultaneously, the storage and updating of model parameters largely rely on file systems, lacking unified version management and fault recovery mechanisms, making it difficult to ensure the continuity and traceability of training. Furthermore, insufficient data sampling, feature extraction, and adaptation to native database capabilities during training further constrain the overall performance of model training.

[0003] DB4AI (Database for AI) aims to reduce the deployment complexity of AI models through database technology, but research on training time series prediction models within the database remains insufficient. Existing DB4AI research largely focuses on improving the inference performance of built-in prediction models, without deeply adapting to the model training process, making it difficult to solve the efficiency problems of training data sampling and parameter updates. Furthermore, existing solutions lack specific mechanisms designed for the data sampling characteristics of incremental training of time series prediction models, and model storage does not deeply integrate with database row-column storage and log mechanisms, resulting in significant storage space overhead.

[0004] Moritz Sichert (Sichert M, Neumann T. User-defined operators: Efficiently integrating custom algorithms into modern databases[J / OL]. Proceedings of the VLDB Endowment, 2022, 15(5): 1119-1131 [2026-03-13]. https: / / doi.org / 10.14778 / 3510397.3510408.) et al. proposed a technical solution based on user-defined operators. By integrating custom algorithms into modern database query engines in the form of algebraic operators, they designed two core components: the UDO user compiler and the query compiler. This avoids the inefficiency of data export and import, maintains the ACID properties of the database, solves the data migration overhead problem, and achieves data processing efficiency comparable to native query operations. However, this solution does not specifically address the sampling characteristics of time series data and the compression optimization of time series prediction model storage. It does not include a dedicated implementation or process for training time series prediction models, resulting in poor adaptability to the training of time series prediction models and an excessively large storage volume of the trained time series prediction model parameters. Summary of the Invention

[0005] To overcome the aforementioned technical deficiencies, this invention proposes an incremental training method and system for time series prediction models based on a PostgreSQL database. This method employs a two-layer time series sampling mechanism to input the sampled dataset into the built-in time series prediction model of the PostgreSQL database for training. A row-column hybrid storage strategy is used to save the updated model training parameters, accelerating the time series data sampling speed, improving data access efficiency during training, avoiding redundant full table scans, and reducing disk I / O overhead. Simultaneously, model storage compression is implemented, reducing storage space usage, and model version management is supported, shortening model recovery time.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: An incremental training method for a time series forecasting model based on a PostgreSQL database includes the following steps: Step 1: Divide the raw time series data into time series data blocks and store the time series data blocks in a PostgreSQL data table; Step 2: Use the two-level time-series sampling mechanism encapsulated within the PostgreSQL database to sample the PostgreSQL data table and obtain the sampled dataset; Step 3: Input the sampled dataset into the built-in time series prediction model of the PostgreSQL database for training. After training is complete, output the updated time series prediction model parameters. Step 4: Use a row-column hybrid storage strategy to store the updated time series prediction model parameters to complete the incremental training of the time series prediction model.

[0007] Furthermore, step 2 specifically includes: Step 2.1: Encapsulate the two-level time-series sampling mechanism using PostgreSQL user-defined operators, and then read the time-series data blocks from the PostgreSQL data table; the two-level time-series sampling mechanism includes block-level sampling and tuple-level sampling; Step 2.2: Perform block-level sampling on the time-series data blocks in the PostgreSQL data table to obtain a list of data blocks; Step 2.3: Use a double-buffered alternation mechanism to perform tuple-level sampling on the data block list to obtain the sampled dataset.

[0008] Furthermore, step 2.2 specifically includes: Step 2.2.1: Configure the timing data window for the timing data block : in, The latest occurrence time of the time series data. The length of the window; Step 2.2.2: Targeting the time series data window Within the time-series data blocks, the correlation coefficient of the time-series data blocks is calculated using the B+ tree partition index of the PostgreSQL database; Step 2.2.3: Determine the data blocks to be collected based on the correlation coefficient of the time-series data blocks; if the correlation coefficient of the time-series data block is greater than the first preset threshold, then collect the time-series data block; if the correlation coefficient of the time-series data block is less than the first preset threshold, then ignore the time-series data block. Step 2.2.4: Window the time series data Based on the time period length of the time-series data block S Slide along the time axis to the next time series data window Then, sample the next time-series data window according to steps 2.2.2-2.2.3. The time-series data blocks in the PostgreSQL data table are sampled until all the time-series data blocks in the PostgreSQL data table are sampled.

[0009] Furthermore, step 2.3 specifically includes: Step 2.3.1: After the two data buffer pools in the PostgreSQL database are initialized, they enter the data pre-read state of the data block list respectively; Step 2.3.2: When performing tuple-level sampling on the data block list, when the data in either data block list in the two data buffer pools is consumed, the consumed data buffer pool enters the data pre-read state, and the other data buffer pool switches to the data consumption state. Step 2.3.3: Read the data from the list of consumed data blocks and configure the timing data window for the data in the list of consumed data blocks. : in, This represents the number of tuples contained in the corresponding training batch. This refers to the earliest occurrence time of the time series data; Step 2.3.4: Targeting the time series data window The data in the list of data blocks is randomly sampled or stratified, the relevant derived features of the data in the list of data blocks after random sampling or stratified sampling are calculated, and the data in the list of data blocks and their relevant derived features are saved into the sampled dataset. Step 2.3.5: Window the time series data Based on the time period length of the time-series data block S Slide along the time axis to the next time series data window Then, sample the next time-series data window according to steps 2.3.2-2.3.4. The data in the data block list is sampled until all the data in the data block list in the data buffer pool has been sampled.

[0010] Furthermore, step 3 specifically includes: Step 3.1: Before training, the sampled dataset is divided into training data and validation data according to a preset ratio, and indexes are added to the field columns of the training data and the field columns of the validation data respectively; the indexes include B+ tree partition index, function index, and null bitmap index; Step 3.2: During training, load the training data using the indexes corresponding to the field columns of the training data, and use a transaction mechanism to train the time series prediction model; Step 3.3: After training is complete, load the validation data using the indexes corresponding to the field columns of the validation data, and evaluate the time series prediction model with updated parameters. If the validation loss of the time series prediction model meets the preset index, output the updated time series prediction model parameters. If the validation loss of the time series prediction model does not meet the preset index, return to step 3.2 and continue training the time series prediction model until the validation loss of the time series prediction model meets the preset index.

[0011] Furthermore, in step 3.2, training the time series prediction model using a transaction mechanism specifically includes: If the training process is uninterrupted, the B+ tree partition index is first used to locate the range of the target data block. If the range of the target data block is not located, the missing target data block is skipped using the null bitmap index. If the range of the target data block is located, the target data block is read, the statistical features of the target data block are obtained using the function index, and the target data block and its statistical features are used to train the time series prediction model. If the training process is interrupted, the process is restored to the initial state of training through the transaction rollback mechanism. After the training loop ends normally, the transaction is committed to save the parameters of the time series prediction model.

[0012] Furthermore, step 4 specifically includes: Step 4.1: Divide the updated time series forecasting model parameters into basic parameters and incremental parameters; Step 4.2: Store the basic parameters in the basic parameter table of the time series forecasting model in the form of a row-based table; Step 4.3: Divide the incremental parameters into different incremental parameter blocks according to the different levels of the time series forecasting model. Each incremental parameter block is an incremental parameter of the same level of time series forecasting model and corresponds to a parameter value field column in the column storage table. Step 4.4: Store the incremental parameter blocks in the incremental parameter table of the time series prediction model in the form of a columnar storage table to complete the incremental training of the time series prediction model.

[0013] Furthermore, step 4.4 specifically includes: Step 4.4.1: Each incremental parameter block corresponds to a parameter value field in the incremental parameter table of the time series prediction model; Step 4.4.2: Incrementally assign a version identifier field to each incremental parameter block; Step 4.4.3: Calculate the checksum of each incremental parameter block using a hash algorithm and fill the checksum field of the incremental parameter block with the checksum of each incremental parameter block. Simultaneously, compare the incremental parameter block with the previous version's incremental parameter block to detect the change status of each incremental parameter block. If the incremental parameter block is marked as "changed", perform differential encoding and compression on the changed incremental parameter block to obtain the encoded parameter value field and encoding type field. If the incremental parameter block is marked as "unchanged", only retain the reference to the incremental parameter block of the previous version's time series prediction model in the incremental parameter table. The differential encoding and compression of the changed incremental parameter blocks specifically includes: Maintain a lightweight statistical summary for each parameter value field in the incremental parameter table; the lightweight statistical summary includes sparsity, update magnitude, and access popularity; The incremental parameter blocks are differentially encoded and compressed based on a lightweight statistical summary of each parameter value field. The specific rules for the differential coding compression are as follows: When the sparsity of the parameter value field is higher than the second preset threshold, run length encoding compression is selected; Incremental encoding compression is selected when the sparsity of the parameter value field is lower than the second preset threshold and the update magnitude is lower than the third preset threshold. When the parameter value field is a high-dimensional vector, vector quantization or product quantization is used for compression. When the parameter value field is unstructured metadata, serialization encoding is used first, followed by encoding and compression using a general lossless compression algorithm; If other conditions occur, block-level quantization encoding compression should be selected for the parameter value field; Step 4.4.4: Write the encoded parameter value field, version identifier field, checksum field, and encoding type field into the corresponding columns of the incremental parameter table of the time series prediction model to complete the incremental training of the time series prediction model.

[0014] Furthermore, it also includes step 5: After storing the updated time series prediction model parameters, a version management system for the incrementally trained time series prediction model is established using the PostgreSQL multi-version concurrency control mechanism and extended PostgreSQL transaction logs, so as to achieve traceability of the time series prediction model after incremental training.

[0015] An incremental training system for time series prediction models based on a PostgreSQL database includes: Time-series data storage module: Divides the raw time-series data into time-series data blocks and stores the time-series data blocks in PostgreSQL data tables; Time-series data sampling module: It uses the two-level time-series sampling mechanism encapsulated within the PostgreSQL database to sample PostgreSQL data tables and obtain the sampled dataset; Model training module: Input the sampled dataset into the built-in time series prediction model of the PostgreSQL database for training, and output the updated time series prediction model parameters after training is completed; Model parameter storage module: A hybrid row and column storage strategy is used to store the updated time series prediction model parameters to complete the incremental training of the time series prediction model.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. In step 2 of this invention, when sampling the PostgreSQL data table using the dual-layer time-series sampling mechanism encapsulated within the PostgreSQL database, the double-buffering alternation mechanism in step 2.3 solves the problem of low sampling efficiency caused by the serial execution of data pre-reading and tuple-level sampling. It realizes the parallel execution of data pre-reading and tuple-level sampling, and the tuple-level sampling process does not need to wait for data loading, which has the advantages of improving tuple-level sampling efficiency and shortening tuple-level sampling time.

[0017] 2. In step 3 of this invention, when the sampled dataset is input into the time series prediction model built into the PostgreSQL database for training, indexes are added to the field columns of the training data and the field columns of the validation data in step 3.1, and the training data and validation data are loaded using the indexes in steps 3.2-3.3. This solves the problem of low data reading efficiency and slowing down the training speed, and has the advantages of avoiding full table scans and reducing disk I / O.

[0018] 3. Step 3.3 of this invention uses a transaction mechanism to train the time series prediction model, encapsulating the training within the transaction execution, which solves the problems of lack of atomicity guarantee and difficulty in recovery after failure interruption in the training process. It ensures data consistency in the training process and can restore the training to the starting state through the transaction rollback mechanism if the training is interrupted. It has the advantages of ensuring training reliability and model parameter integrity.

[0019] 4. Step 4 of this invention uses a row-column hybrid storage strategy to store the updated time series prediction model parameters, which solves the problem that a single storage method cannot simultaneously meet the read and write efficiency requirements between basic parameters and incremental parameters. It achieves higher storage and read / write efficiency for time series prediction model parameters and has the advantages of balancing read and write efficiency and optimizing storage space utilization.

[0020] 5. The present invention solves the problem of excessive model parameter storage space by performing differentiated encoding and compression on the changed incremental parameter block in step 4.4.3. The corresponding encoding method is selected according to the parameter statistical characteristics, which effectively reduces storage costs.

[0021] 6. Step 5 of this invention utilizes a multi-version concurrency control mechanism and extended PostgreSQL transaction logs to establish version management for incremental training prediction models. This solves the problems of lack of model version traceability and difficulty in fault recovery during the training process, and obtains version management capabilities for time series prediction models in PostgreSQL databases. This effectively supports multiple incremental trainings of time series prediction models in PostgreSQL databases, and has the advantages of model version traceability and shortened model recovery time.

[0022] In summary, the incremental training method for time series prediction models based on PostgreSQL database of this invention achieves pipelined parallelism of data pre-reading and sampling through PostgreSQL's built-in two-layer time series sampling combined with a double-buffering alternation mechanism, reducing time series data sampling time; it implements training of the built-in time series prediction model in PostgreSQL database through user-defined operators, and combines the PostgreSQL database index mechanism to read training and validation data, reducing data reading time overhead and the number of data reading I / O operations; it ensures training reliability and atomicity through a transaction mechanism, avoiding damage to model parameters due to training failure; it achieves storage of time series prediction model parameters after training through a row-column hybrid storage strategy and differentiated dynamic compression encoding, balancing the read and write efficiency between basic model parameters and incremental model parameters, and reducing the storage space overhead of model parameters; and it achieves version management of the time series prediction model after incremental training through a multi-version concurrency control mechanism and extended PostgreSQL transaction logs, supporting multiple incremental training of the time series prediction model and shortening model recovery time. Attached Figure Description

[0023] Figure 1 This is a flowchart of the incremental training method for the time series prediction model based on the PostgreSQL database according to the present invention.

[0024] Figure 2 This is an architecture diagram of the incremental training method for time series prediction models based on the PostgreSQL database according to the present invention.

[0025] Figure 3 This is a flowchart illustrating the dual-layer timing sampling mechanism of the present invention.

[0026] Figure 4 This is a schematic diagram illustrating the process of establishing corresponding indexes for fields in training and validation data according to the present invention.

[0027] Figure 5 This is a schematic diagram illustrating the process of storing updated time series prediction model parameters using a row-column hybrid storage strategy according to the present invention.

[0028] Figure 6 This is a schematic diagram illustrating the process of compressing the changed incremental parameter block using differentiated encoding compression in this invention.

[0029] Figure 7 This is a diagram illustrating version management with multi-version concurrency control mechanisms and log collaboration.

[0030] Figure 8This diagram illustrates a comparison of the training speeds of different time series prediction models based on the incremental training method of this invention and existing training methods on the Weather dataset.

[0031] Figure 9 This diagram illustrates a comparison of the training speeds of different time series prediction models based on the incremental training method of this invention and the original PyTorch training method across multiple dataset types; wherein, Figure 9 (a) is a schematic diagram comparing the training speed of Autoformer on multiple types of datasets using the incremental training method based on the present invention and the original PyTorch training method. Figure 9 (b) is a schematic diagram comparing the training speed of DLinear based on the incremental training method of the present invention and the original PyTorch training method on multiple types of datasets. Figure 9 (c) is a schematic diagram comparing the training speed of FEDformer based on the incremental training method of the present invention and the original PyTorch training method under multiple types of datasets; Figure 9 (d) in the figure is a comparison diagram of the training speed of FreTS based on the incremental training method of the present invention and the original PyTorch training method under multiple types of datasets; Figure 9 (e) in the figure is a schematic diagram comparing the training speed of Informer on multiple types of datasets with the incremental training method based on the present invention and the original PyTorch training method. Figure 9 (f) in the figure is a comparison diagram of the training speed of Koopa based on the incremental training method of the present invention and the original PyTorch training method under multiple types of datasets; Figure 9 (g) in the figure is a comparison diagram of the training speed of LightTS based on the incremental training method of the present invention and the original PyTorch training method under multiple types of datasets; Figure 9 (h) in the figure is a schematic diagram comparing the training speed of PatchTST based on the incremental training method of the present invention and the original PyTorch training method under multiple types of datasets; Figure 9 (i) is a schematic diagram comparing the training speed of TSMixer with the original PyTorch training method based on the present invention in multiple types of datasets; Figure 9 (j) is a schematic diagram comparing the training speed of TimeMixer for multiple types of datasets using the incremental training method based on the present invention and the original PyTorch training method. Figure 9 (k) in the figure is a comparison diagram of the training speed of TimeXer for multiple types of datasets, based on the incremental training method of the present invention and the original PyTorch training method. Figure 9(l) is a schematic diagram comparing the training speed of the incremental training method based on the present invention and the original PyTorch training method on TimesNet under multiple types of datasets; Figure 9 The (m) in the figure is a comparison diagram of the training speed of Transformer in multiple types of datasets between the incremental training method based on the present invention and the original PyTorch training method. Figure 9 In the diagram, (n) is a comparison of the training speed of iTransformer under multiple types of datasets using the incremental training method based on the present invention and the original PyTorch training method.

[0032] Figure 10 This is a schematic diagram comparing the storage overhead of the parameter storage method based on the present invention with that of traditional parameter storage methods across multiple dataset types; wherein, Figure 10 (a) in the figure is a comparison of the storage volume of the parameter storage method of the present invention and the traditional parameter storage method; Figure 10 (b) is a comparison diagram of the storage configuration details of the parameter storage method of the present invention and the traditional parameter storage method.

[0033] Figure 11 This diagram illustrates a comparison of fault recovery time between the parameter storage method based on the present invention and traditional parameter storage methods across multiple dataset types.

[0034] Figure 12 This is a heatmap comparing the MSE accuracy of different time series prediction models based on the incremental training method of this invention and the original PyTorch training method on multiple dataset types; wherein, Figure 12 (a) is a heatmap showing the MSE accuracy comparison between the incremental training method based on the present invention and the original PyTorch training method without adding an index; Figure 12 (b) is a heatmap showing the MSE accuracy comparison between the incremental training method based on the present invention and the original PyTorch training method when adding an index.

[0035] Figure 13 This is a heatmap illustrating the comparison of MAE accuracy between the incremental training method based on this invention and the original PyTorch training method for different time series prediction models across multiple dataset types; wherein, Figure 13 (a) is a heatmap showing the MAE accuracy comparison between the incremental training method based on this invention and the original PyTorch training method without adding an index; where, Figure 13 (b) is a heatmap showing the MAE accuracy comparison between the incremental training method based on the present invention and the original PyTorch training method when adding an index. Detailed Implementation

[0036] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments: See Figure 1 and Figure 2 An incremental training method for a time series prediction model based on a PostgreSQL database includes the following steps: Step 1: Divide the raw time series data into time series data blocks and store the time series data blocks in a PostgreSQL data table; the raw time series data in this embodiment comes from the open-source data warehouse of thumb / Time-Series-Library on the Hugging Face platform (https: / / huggingface.co / datasets / thuml / Time-Series-Library), which covers time series forecasting benchmark data in multiple fields such as power, transportation, and weather; When dividing the raw time-series data into time-series data blocks, the data blocks are divided according to the size of the PostgreSQL storage page (default 8KB), and the time-series data blocks are stored in the PostgreSQL data table according to the order of the time-series data in the time-series data blocks.

[0037] Step 2: Use the two-level time-series sampling mechanism encapsulated within the PostgreSQL database to sample the PostgreSQL data table and obtain the sampled dataset; See Figure 3 Step 2 specifically includes: Step 2.1: Encapsulate the two-level time-series sampling mechanism using PostgreSQL user-defined operators, and then read the time-series data blocks from the PostgreSQL data table; the two-level time-series sampling mechanism includes block-level sampling and tuple-level sampling; the specific operation flow of encapsulating the two-level time-series sampling mechanism using PostgreSQL user-defined operators in Step 2.1 is as follows: a) The two-level timing sampling mechanism is encapsulated into a specific C function using the C language. The declaration and definition of the C function should be implemented using the function definition format specified by the PostgreSQL user-defined operator. The function definition format in this embodiment is as follows: G_FUNCTION_INFO_V1(ts_block_level_sampling); Daily ts_block_level_sampling(PG_FUNCTION_ARGS){... Specific logic}; b) Register user functions implemented on the C side in the SQL side, such as ts_sampling_operator; c) Use Makefile to build the compilation project and compile user-defined operators as extensions into the kernel of the PostgreSQL database; d) Install an extension in the PostgreSQL database to complete the encapsulation of the two-layer time-series sampling mechanism.

[0038] Step 2.2: Perform block-level sampling on the time-series data blocks in the PostgreSQL data table to obtain a list of data blocks; Step 2.2 specifically includes: Step 2.2.1: Read the timing data block and configure the timing data window for the timing data block. : in, The latest occurrence time of the time series data. The length of the window; Step 2.2.2: Targeting the time series data window Within the time-series data blocks, the correlation coefficient of the time-series data blocks is calculated using the B+ tree partition index of the PostgreSQL database; Step 2.2.3: Determine the data block to be collected based on the correlation coefficient of the time-series data block; if the correlation coefficient of the time-series data block is greater than the first preset threshold, then collect the time-series data block; if the correlation coefficient of the time-series data block is less than the first preset threshold, then ignore the time-series data block; the first preset threshold in this embodiment is 0.7; Step 2.2.4: Window the time series data Based on the time period length of the time-series data block S Slide along the time axis to the next time series data window Then, sample the next time-series data window according to steps 2.2.2-2.2.3. The time-series data blocks in the PostgreSQL data table are sampled until all the time-series data blocks in the PostgreSQL data table are sampled.

[0039] Step 2.3: Use a double-buffered alternation mechanism to perform tuple-level sampling on the data block list to obtain the sampled dataset. The double-buffered alternation mechanism enables parallel execution of data pre-reading and tuple-level sampling. The tuple-level sampling process does not need to wait for data loading, which can reduce the time overhead of tuple-level sampling.

[0040] Furthermore, step 2.3 specifically includes: Step 2.3.1: After the two data buffer pools in the PostgreSQL database are initialized, they enter the data pre-read state of the data block list respectively; Step 2.3.2: When performing tuple-level sampling on the data block list, when the data in either data block list in the two data buffer pools is consumed, the consumed data buffer pool enters the data pre-read state, and the other data buffer pool switches to the data consumption state. Step 2.3.3: Read the data from the list of consumed data blocks and configure the timing data window for the data in the list of consumed data blocks. : in, This represents the number of tuples contained in the corresponding training batch. This refers to the earliest occurrence time of the time series data; Step 2.3.4: Targeting the time series data window The data in the data block list is randomly sampled or stratified, and the relevant derived features of the data block list data after random sampling or stratified sampling are calculated. The data of the data block list and its relevant derived features are then saved to the sampling result table. The relevant derived features of the data block list data are all calculated by window functions in the PostgreSQL database. The relevant derived features of the data block list data include mean, standard deviation, range, difference feature, and moving average feature. This embodiment takes the difference feature as an example, and the specific calculation process is as follows: During the sampling process, the PostgreSQL window function LAG() is used to maintain the data position information of the preceding data block list so that the differential features can be calculated later. The `LAG(value, 1)` function retrieves the list of data from the previous sampled data block. Then, using PostgreSQL window functions and numerical operators, the first-order difference feature (the difference between the current data block list and the previous data block list) is calculated according to the first-order difference feature calculation formula. Here, `LAG` is a PostgreSQL window function used to retrieve a value preceding the current value, and `value` is the data passed to the current data block list. The first-order difference feature calculation formula is as follows: in, These are first-order difference eigenvalues. The list of data blocks at the current time t This is a list of data blocks from the previous sample. The LAG(value, 1) function is used to retrieve the list of data from the previous sampled data block. Then, using PostgreSQL window functions and numerical operators, the second-order difference feature is calculated according to the second-order difference feature calculation formula. This second-order difference feature is the difference between the first-order difference feature value of the current data block list and the previous first-order difference feature value. The second-order difference feature calculation formula is as follows: in, Second-order difference eigenvalues; Step 2.3.5: Window the time series data Based on the time period length of the time-series data block S Slide along the time axis to the next time series data window Then, sample the next time-series data window according to steps 2.3.2-2.3.4. The data in the data block list is sampled until all the data in the data block list in the data buffer pool has been sampled.

[0041] Step 3: Input the sampled dataset into the built-in time series prediction model of the PostgreSQL database for training. After training is complete, output the updated time series prediction model parameters. The time series prediction models in this embodiment include, but are not limited to, Transformer, Informer, Autoformer, FEDformer, DLinear, TimesNet, LightTS, TSMixer, PatchTST, Koopa, TimeMixer, iTransformer, TimeXer, and FreTS deep learning network structures. The training logic of the time series prediction model is encapsulated within a PostgreSQL database using PostgreSQL user-defined operators. The encapsulation process is the same as that of the aforementioned two-layer time series sampling mechanism. The time series prediction model is natively built into the PostgreSQL database; the training logic of the time series prediction model in this embodiment is based on existing technology and comes from https: / / github.com / thuml / Time-Series-Library. See Figure 4 Step 3 specifically includes: Step 3.1: Before training, the sampled dataset is divided into training data and validation data according to a preset ratio, and indexes are added to the field columns of both the training data and validation data. The indexing mechanism speeds up the loading efficiency of training data, avoids full table scans, and reduces disk I / O. The indexes include B+ tree partition indexes, function indexes, and null bitmap indexes. The B+ tree partition index is used for fast location of target data blocks; the function index is used for pre-calculating statistical features, including but not limited to moving average fields, difference feature fields, and rolling statistics fields; the null bitmap index is used to skip missing target data blocks during training. In this embodiment, the sampled dataset is divided into training data and validation data in an 8:2 ratio, that is, training data accounts for 80% and validation data accounts for 20%.

[0042] Step 3.2: During training, the training data is loaded using the indexes corresponding to the field columns of the training data, and the time series prediction model is trained using a transaction mechanism. The transaction mechanism can provide atomicity guarantee for the training of the time series prediction model and activate the necessary isolation function to prevent other execution tasks from interfering with the training of the current time series prediction model. Furthermore, in step 3.2, training the time series prediction model using a transaction mechanism specifically includes: If the training process is uninterrupted, the B+ tree partition index is first used to locate the range of the target data block. If the range of the target data block is not located, the missing target data block is skipped using the null bitmap index. If the range of the target data block is located, the target data block is read, the statistical features of the target data block are obtained using the function index, and the target data block and its statistical features are used to train the time series prediction model. If the training process is interrupted, it can be restored to the training start state through the transaction rollback mechanism. After the training loop ends normally, the transaction is committed to save the parameters of the time series prediction model.

[0043] Step 3.3: After training is complete, load the validation data using the indexes corresponding to the field columns of the validation data, and evaluate the updated time series prediction model. If the validation loss of the time series prediction model meets the preset metric, output the updated time series prediction model parameters. If the validation loss of the time series prediction model does not meet the preset metric, return to Step 3.2 and continue training the time series prediction model until the validation loss meets the preset metric. The preset metric is that the MAE (Mean Absolute Error) value is lower than 0.5 or the MAE value does not decrease for five consecutive training epochs.

[0044] Step 4: Use a row-column hybrid storage strategy to store the updated time series prediction model parameters to complete the incremental training of the time series prediction model.

[0045] See Figure 5 Step 4 specifically includes: Step 4.1: Divide the updated time series forecasting model parameters into basic parameters and incremental parameters; The basic parameters in this embodiment include relatively stable configuration information such as model architecture definition, optimizer state, and hyperparameter configuration; the incremental parameters include frequently changing data such as gradients, update amounts, and incremental blocks; in addition, during the incremental training process of the time series prediction model, the read and write modes involved in the basic parameters and incremental parameters are different. The basic parameters are often read and written in full, while the incremental parameters are more often read and written frequently for some parameters. If a single storage method is used, it is often impossible to meet the read and write requirements of both basic parameters and incremental parameters at the same time.

[0046] Step 4.2: Store the basic parameters in the basic parameter table of the time series forecasting model in the form of a row-based table; Step 4.3: Divide the incremental parameters into different incremental parameter blocks according to the different levels of the time series forecasting model. Each incremental parameter block is an incremental parameter of the same level of time series forecasting model and corresponds to a parameter value field column in the column storage table. Step 4.4: Store the incremental parameter blocks in the incremental parameter table of the time series prediction model in the form of a columnar storage table to complete the incremental training of the time series prediction model. The incremental parameter table includes columns consisting of parameter value fields, version identifier fields, checksum fields, and encoding type fields. The parameter value field columns generally use binary type. Multiple versions of the same incremental parameter block are organized through columnar storage and stored contiguously in physical storage. This supports compressed storage and vectorized querying of batch incremental parameter blocks. By storing the basic parameters and incremental parameters in a mixed row and column format, read and write requests can be better balanced, achieving higher read and write efficiency for the time series prediction model parameters.

[0047] Furthermore, step 4.4 specifically includes: Step 4.4.1: Each incremental parameter block corresponds to a parameter value field in the incremental parameter table of the time series prediction model; Step 4.4.2: Incrementally assign a version identifier field to each incremental parameter block; Step 4.4.3: Calculate the checksum of each incremental parameter block using a hash algorithm and fill the checksum field of each incremental parameter block with the checksum field. Simultaneously, compare the incremental parameter block with the previous version's incremental parameter block to detect changes in each incremental parameter block. If the incremental parameter block is marked as "changed," perform differential encoding and compression on the changed incremental parameter block to obtain the encoded parameter value field and encoding type field. If the incremental parameter block is marked as "unchanged," only retain references to the previous version's time series prediction model incremental parameter block in the incremental parameter table. By performing differential encoding and compression on the changed incremental parameter blocks, the storage cost of incremental parameters can be effectively reduced.

[0048] See Figure 6 The differential encoding and compression of the changed incremental parameter blocks specifically includes: Maintain a lightweight statistical summary for each parameter value field in the incremental parameter table; the lightweight statistical summary includes sparsity, update magnitude, and access popularity; The incremental parameter blocks are differentially encoded and compressed based on a lightweight statistical summary of each parameter value field. The specific rules for the differential coding compression are as follows: When the sparsity of the parameter value field is higher than the second preset threshold, the run length encoding compression is selected to obtain the run length encoded parameter value field and the run length encoded type field; When the sparsity of the parameter value field is lower than the second preset threshold and the update magnitude is lower than the third preset threshold, incremental encoding compression is selected to obtain the incremental encoded parameter value field and the incremental encoding type field. When the parameter value field is a high-dimensional vector, vector quantization or product quantization is used for compression to obtain the quantized encoded parameter value field and the quantized encoded type field. When the parameter value field is unstructured metadata, serialization encoding is first used, followed by encoding compression using a general lossless compression algorithm to obtain the serialized parameter value field and the serialized type field. If other conditions are met, block-level quantization encoding compression is selected for the parameter value field, resulting in a block-level quantization encoding parameter value field and a block-level quantization encoding type field. Step 4.4.4: Write the encoded parameter value field, version identifier field, checksum field, and encoding type field into the corresponding columns of the incremental parameter table of the time series prediction model to complete the incremental training of the time series prediction model.

[0049] Furthermore, it also includes step 5: After storing the updated time series prediction model parameters, a version management system for the incrementally trained time series prediction model is established using the PostgreSQL multi-version concurrency control mechanism and extended PostgreSQL transaction logs, so as to achieve traceability of the time series prediction model after incremental training.

[0050] See Figure 7 Step 5 specifically includes: Step 5.1: Establish a version management table to store version metadata for different training versions; the version management table includes version identifier, version creation timestamp, training round, and base model version reference; Step 5.2: After associating the current version metadata, store it in the version management table; the version metadata includes the version identifier field corresponding to the incremental parameter block, the creation time of the corresponding version, the training round of the time series prediction model, and the basic training version of the time series prediction model; Step 5.3: Utilize the PostgreSQL multi-version concurrency control mechanism to create an independent transaction snapshot for each version metadata stored in the version management table, and add a B+ tree partition index to the version identifier field; the transaction snapshot includes the version identifier, version creation timestamp, training round, status type, and parameter value fields; Step 5.4: Expand the PostgreSQL transaction log by writing the transaction snapshots of the time series prediction model corresponding to the training version into the PostgreSQL transaction log; the PostgreSQL transaction log includes log ID, version identifier, training round, status type, parameter value field, timestamp, and checksum field; Step 5.5: Each PostgreSQL transaction log is committed to disk using an asynchronous commit strategy, before the parameters of the corresponding trained version of the time series prediction model are committed to disk; Step 5.6: Based on the extended PostgreSQL transaction log and version management table, a hybrid mechanism of snapshot and incremental log is adopted to achieve traceability of the time series prediction model; Step 5.6 specifically includes: Step 5.6.1: Periodically save the updated time series prediction model parameters of the current training version to the version snapshot table; the version snapshot table has three columns, each corresponding to the model identifier, version identifier, and model parameter snapshot.

[0051] Step 5.6.2: During the retrospective analysis of the time series forecasting model, first, based on the latest version identifier recorded in the PostgreSQL transaction log, query the most recent complete snapshot from the version snapshot table; Step 5.6.3: Based on the parameters of the most recently trained version of the time series prediction model, backtrack through the PostgreSQL transaction log and apply subsequent incremental data in timestamp order to finally obtain the backtracked time series prediction model. During the backtracking process, the integrity of the data is verified by checking the PostgreSQL transaction log. If the verification fails, the abnormal log is skipped and an alarm is issued. The backtracking process supports two modes: full replay mode, which replays all PostgreSQL transaction logs starting from the earliest snapshot, suitable for accurate recovery after long-term backtracking; and incremental compensation mode, which only replays the PostgreSQL transaction logs after the most recent snapshot, suitable for fast recovery after short-term backtracking.

[0052] Based on the aforementioned incrementally trained time series prediction model, this invention proposes a long-term weather information prediction method, specifically including: Step S1: Collect weather information using sensors and store the weather information in the weather information data table of the PostgreSQL database in the form of a row-store table: the weather information includes, but is not limited to, temperature, humidity, wind speed, wind direction, rainfall, and duration of rainfall; Step S2: Restore the target time series prediction model after the specified incremental training version using the PostgreSQL multi-version concurrency control mechanism; Step S2 specifically includes: Step S2-1: Load the version identifier of the time series prediction model. Based on the version identifier, query the complete snapshot information corresponding to the most recent time series prediction model version from the version snapshot table to obtain the basic parameters of the time series prediction model after the most recent incremental training within the complete snapshot information. If the complete snapshot information corresponding to the most recent time series prediction model version is not found in the version snapshot table, load the basic parameters of the time series prediction model after the most recent incremental training from the basic parameter table in the PostgreSQL database. Step S2-2: Based on the basic parameters of the time series prediction model after the most recent incremental training, backtrack through the PostgreSQL transaction log and apply the incremental data after the timestamp of the target recovery version in timestamp order to obtain the target time series prediction model after the specified incremental training version. Step S2-2 specifically includes: 1) Locate and read the incremental log record corresponding to the specified incremental training version in the PostgreSQL transaction log by using the version identifier of the basic parameters of the time series prediction model after the most recent incremental training; the PostgreSQL transaction log includes log ID, training round, status type, parameter value field, timestamp, and checksum field; 2) Iterate through each incremental log record in the PostgreSQL transaction log in timestamp order and extract the parameter value field from each incremental log record; 3) The extracted parameter values ​​are sequentially superimposed onto the most recent basic parameters according to the hierarchical structure of the time series prediction model to obtain the superimposed time series prediction model parameters. 4) During the overlay process, the checksum field of the PostgreSQL transaction log is used to verify the data integrity of each incremental log record; if the verification fails, the exception log is skipped and an alarm is issued. 5) Repeat steps 3) to 4) until all incremental log records of the specified incremental training version in the PostgreSQL transaction log have been applied, and the target time series prediction model after the specified incremental training version is obtained. Step S3: Continuously read weather information data tables according to the input time series window of the target time series prediction model after the specified incremental training version, and output multiple first time points. t 1. Historical weather information data; Step S4: Combine multiple first moments t Historical weather information data is input into the target time series prediction model after a specified incremental training version, and multiple second time points are output. t 2. Historical weather information data; Step S5: Repeat the input / output process of steps S3 and S4 until weather information data for a preset time period is obtained; in this embodiment, the preset time period includes multiple moments, namely { t 1, t 2, t 3…… , t n-1 , t n By using historical weather information data predicted at the previous moment as input for the next moment's prediction, multi-step continuous prediction is achieved, thereby completing long-term prediction of weather information.

[0053] The incrementally trained time series prediction model of this invention shows no significant difference in prediction accuracy compared to the original PyTorch-trained time series prediction model. However, this invention significantly improves the time and storage overhead of restoring a specified version of the time series prediction model. Specifically, the average recovery time of the incremental training method of this invention is reduced from 30ms to 23ms compared to the original PyTorch training, resulting in a speedup of 1.3x. The storage overhead of the parameters of the incrementally trained time series prediction model based on this invention is only 24% of that of the traditional full parameter storage method. Considering the additional overhead of PostgreSQL logs, the incremental training method of this invention can achieve a storage saving rate of 54.17% compared to the traditional full parameter storage method.

[0054] An incremental training system for time series prediction models based on a PostgreSQL database includes: Time-series data storage module: Divides the raw time-series data into time-series data blocks and stores the time-series data blocks in PostgreSQL data tables; Time-series data sampling module: It uses the two-level time-series sampling mechanism encapsulated within the PostgreSQL database to sample PostgreSQL data tables and obtain the sampled dataset; Model training module: Input the sampled dataset into the built-in time series prediction model of the PostgreSQL database for training, and output the updated time series prediction model parameters after training is completed; Model parameter storage module: A hybrid row and column storage strategy is used to store the updated time series prediction model parameters to complete the incremental training of the time series prediction model.

[0055] The application effects of this invention will be explained in detail below with reference to simulation experiments.

[0056] I. Regarding the verification of training efficiency: This invention utilizes incremental training of a time series prediction model built into the PostgreSQL database, combined with an indexing mechanism, to eliminate data I / O redundancy in traditional methods and shorten the data computation path. To quantify its efficiency advantage, the experiment uses the training time speedup ratio as the evaluation metric (speedup ratio = original PyTorch training time / incremental training time of this invention), and compares it with the original PyTorch training method. The experimental results are as follows: Figure 8 and Figure 9 As shown.

[0057] Figure 8 Focusing on the Weather dataset, this study demonstrates the training speedup of 14 time series prediction models (Transformer, Informer, Autoformer, FEDformer, DLinear, TimesNet, LightTS, TSMixer, PatchTST, Koopa, TimeMixer, iTransformer, TimeXer, and FreTS deep learning network architectures) across three test sets (original PyTorch training, incremental training method based on this invention without indexing, and incremental training method based on this invention with indexing). Experimental results show that the incremental training method based on this invention achieves a speedup of at least 1.0 for all 14 time series prediction models, both with and without indexing, indicating improved training efficiency. Specifically, the incremental training method based on this invention generally achieves a higher speedup when indexing is added compared to when indexing is not added. Introduction: The index optimization speedup ratios of the lightweight Autoformer and DLinear models reach 1.3 and 1.4 respectively, meaning that the training time is only 71% and 77% of that of the original PyTorch training. Even for the Transformer and Informer models with larger parameter scales, the index optimization speedup ratio remains stable above 1.2. The core support for this improvement lies in the hierarchical index design of this invention (B+ tree partition index + function index + null bitmap index), which achieves accurate positioning of training data, avoids cross-partition data scanning and random I / O overhead in traditional schemes, and forms a synergistic optimization with the double-buffered alternating mechanism of double-layer temporal sampling.

[0058] Figure 9The (an) method further expands the dataset to multiple types, including ECL, ETTm1 industrial dataset, ECL power dataset, Weather dataset, and traffic dataset, to verify the generalization of the incremental training method based on this invention. Experimental results show that on the ETTm1 and ETTm2 time-series datasets, the incremental training method based on this invention generally improves the speedup to 1.4 and 1.5 when adding indexes, respectively, which is about 15% higher than the average speedup of the Weather dataset. This improvement is due to the fact that the batch reading requirements of industrial datasets are highly compatible with the batch access characteristics of the "row-column hybrid storage strategy" of this invention, and the combination of index optimization further amplifies this advantage. Taking the Transformer model as an example, when adding an index, the training time on the ETTm1 dataset is reduced by 40% compared to the original method and by 18% compared to when no index is added, fully verifying the value of adding an index in improving training efficiency. In addition, regardless of the model complexity, the present invention maintains a stable acceleration effect on multiple types of datasets, both with and without an index, proving that the incremental training method of the present invention has universality for different types of time series prediction models.

[0059] II. Regarding storage overhead verification: This invention employs a hybrid row-column storage and differential encoding compression strategy to effectively reduce the storage overhead of model parameters. To quantitatively evaluate storage efficiency, the incremental training method of this invention is compared with the traditional parameter storage method (i.e., using full parameter storage baseline). The experimental results are as follows: Figure 10 As shown.

[0060] Figure 10 (a) shows a comparison of the storage volume of each part of the incremental training method based on the present invention compared with the traditional parameter storage method; the parameter storage volume of the incremental training method based on the present invention is reduced by 88% compared with the traditional parameter storage method. This advantage stems from the hybrid row and column storage and differential encoding compression strategy of the present invention, which performs columnar storage for parameters and combines quantization encoding, run-length encoding and incremental encoding to achieve efficient compression.

[0061] Figure 10 (b) Further details the storage configuration comparison of the incremental training method based on the present invention are presented; considering the actual overhead of the WAL log (approximately 200KB), the incremental training method of the present invention achieves a storage saving rate of 54.17% compared to the traditional parameter storage method. Experimental data further show that by combining the row-column hybrid storage and differential encoding compression strategy of the present invention, a storage space saving of over 50% can be achieved.

[0062] III. Regarding fault recovery verification: This invention leverages PostgreSQL's multi-version concurrency control mechanism and extended PostgreSQL transaction logs to achieve historical tracing of time series prediction model versions and rapid fault recovery. To quantitatively evaluate recovery performance, experiments were conducted with training interruption points at the 20th, 50th, and 80th epochs. The recovery time of the incremental training method based on this invention was compared with that of training from scratch (Baseline). The experimental results are as follows: Figure 11 As shown.

[0063] Figure 11 The comparison of recovery time under different epochs is shown. Experimental results show that the average recovery time of the incremental training method of the present invention is 23.0ms, which is about 30% faster than the traditional training from scratch (Baseline) of 30.0ms, with a speedup of 1.30x. This verifies that the PostgreSQL multi-version concurrency control mechanism and extended PostgreSQL transaction log of the present invention can significantly accelerate model recovery without training from scratch.

[0064] IV. Regarding the verification of prediction accuracy: While verifying the improvement in training efficiency, this invention also focuses on maintaining the accuracy of the time series prediction model; specifically, it uses two metrics, MSE (mean squared error) and MAE (mean absolute error), for quantitative evaluation. Experimental results are as follows: Figure 12 , Figure 13 As shown, the smaller the values ​​of MSE (mean squared error) and MAE (mean absolute error), the higher the accuracy.

[0065] Figure 12 This is a heatmap comparing the MSE accuracy of time series prediction models based on the incremental training method of this invention and the original PyTorch training method on multiple dataset types; Figure 12 As shown in (a) and (b), across multiple dataset types, the incremental training method based on this invention exhibits minimal differences in MSE accuracy between models with and without indexes, as well as the original PyTorch training method. In most scenarios, the difference is less than 0.01, effectively ensuring the stability of training accuracy. Figure 13 This is a heatmap comparing the MAE accuracy of time series prediction models based on the incremental training method of this invention and the original PyTorch training method on multiple dataset types; Figure 13 As shown in (a) and (b), for the 14 models on multiple datasets, the difference in MAE between the incremental training method based on this invention with index added, without index added, and the original PyTorch training method is less than 0.02, and there is no obvious regular deviation.

[0066] From the overall data distribution perspective, Figure 12 MSE accuracy and Figure 13 The fact that no single aspect of MAE accuracy is significantly superior or inferior fully demonstrates that the incremental training method based on this invention achieves a significant improvement in training efficiency without sacrificing accuracy, breaking the dilemma of "difficulty in balancing efficiency and accuracy" in traditional solutions.

[0067] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications, equivalent substitutions or improvements made by those skilled in the art within the spirit and principles of the present invention should be covered within the scope of protection of the present invention.

Claims

1. An incremental training method for a time series prediction model based on a PostgreSQL database, characterized in that: Specifically, the following steps are included: Step 1: Divide the raw time series data into time series data blocks and store the time series data blocks in a PostgreSQL data table; Step 2: Use the two-level time-series sampling mechanism encapsulated within the PostgreSQL database to sample the PostgreSQL data table and obtain the sampled dataset; Step 3: Input the sampled dataset into the built-in time series prediction model of the PostgreSQL database for training. After training is complete, output the updated time series prediction model parameters. Step 4: Use a row-column hybrid storage strategy to store the updated time series prediction model parameters to complete the incremental training of the time series prediction model.

2. The incremental training method for a time series prediction model based on a PostgreSQL database according to claim 1, characterized in that: Step 2 specifically includes: Step 2.1: Encapsulate the two-level time-series sampling mechanism using PostgreSQL user-defined operators, and then read the time-series data blocks from the PostgreSQL data table; the two-level time-series sampling mechanism includes block-level sampling and tuple-level sampling; Step 2.2: Perform block-level sampling on the time-series data blocks in the PostgreSQL data table to obtain a list of data blocks; Step 2.3: Use a double-buffered alternation mechanism to perform tuple-level sampling on the data block list to obtain the sampled dataset.

3. The incremental training method for a time series prediction model based on a PostgreSQL database according to claim 2, characterized in that: Step 2.2 specifically includes: Step 2.2.1: Configure the timing data window for the timing data block : in, The latest occurrence time of the time series data. The length of the window; Step 2.2.2: Targeting the time series data window Within the time-series data blocks, the correlation coefficient of the time-series data blocks is calculated using the B+ tree partition index of the PostgreSQL database; Step 2.2.3: Determine the data blocks to be collected based on the correlation coefficient of the time-series data blocks; if the correlation coefficient of the time-series data block is greater than the first preset threshold, then collect the time-series data block; if the correlation coefficient of the time-series data block is less than the first preset threshold, then ignore the time-series data block. Step 2.2.4: Window the time series data Based on the time period length of the time-series data block S Slide along the time axis to the next time series data window Then, sample the next time series data window according to steps 2.2.2-2.2.

3. The time-series data blocks in the PostgreSQL data table are sampled until all the time-series data blocks in the PostgreSQL data table are sampled.

4. The incremental training method for a time series prediction model based on a PostgreSQL database according to claim 2, characterized in that: Step 2.3 specifically includes: Step 2.3.1: After the two data buffer pools in the PostgreSQL database are initialized, they enter the data pre-read state of the data block list respectively; Step 2.3.2: When performing tuple-level sampling on the data block list, when the data in either data block list in the two data buffer pools is consumed, the consumed data buffer pool enters the data pre-read state, and the other data buffer pool switches to the data consumption state. Step 2.3.3: Read the data from the list of consumed data blocks and configure the timing data window for the data in the list of consumed data blocks. : in, This represents the number of tuples contained in the corresponding training batch. This refers to the earliest occurrence time of the time series data; Step 2.3.4: Targeting the time series data window The data in the list of data blocks is randomly sampled or stratified, the relevant derived features of the data in the list of data blocks after random sampling or stratified sampling are calculated, and the data in the list of data blocks and their relevant derived features are saved into the sampled dataset. Step 2.3.5: Window the time series data Based on the time period length of the time-series data block S Slide along the time axis to the next time series data window Then, sample the next time series data window according to steps 2.3.2-2.3.

4. The data in the data block list is sampled until all the data in the data block list in the data buffer pool has been sampled.

5. The incremental training method for a time series prediction model based on a PostgreSQL database according to claim 1, characterized in that: Step 3 specifically includes: Step 3.1: Before training, the sampled dataset is divided into training data and validation data according to a preset ratio, and indexes are added to the field columns of the training data and the field columns of the validation data respectively; the indexes include B+ tree partition index, function index, and null bitmap index; Step 3.2: During training, load the training data using the indexes corresponding to the field columns of the training data, and use a transaction mechanism to train the time series prediction model; Step 3.3: After training is complete, load the validation data using the indexes corresponding to the field columns of the validation data, and evaluate the time series prediction model with updated parameters. If the validation loss of the time series prediction model meets the preset index, output the updated time series prediction model parameters. If the validation loss of the time series prediction model does not meet the preset index, return to step 3.2 and continue training the time series prediction model until the validation loss of the time series prediction model meets the preset index.

6. The incremental training method for a time series prediction model based on a PostgreSQL database according to claim 5, characterized in that: Step 3.2, training the time series prediction model using a transaction mechanism, specifically includes: If the training process is uninterrupted, the B+ tree partition index is first used to locate the range of the target data block. If the range of the target data block is not located, the missing target data block is skipped using the null bitmap index. If the range of the target data block is located, the target data block is read, the statistical features of the target data block are obtained using the function index, and the target data block and its statistical features are used to train the time series prediction model. If the training process is interrupted, the process is restored to the initial state of training through the transaction rollback mechanism. After the training loop ends normally, the transaction is committed to save the parameters of the time series prediction model.

7. The incremental training method for a time series prediction model based on a PostgreSQL database according to claim 1, characterized in that: Step 4 specifically includes: Step 4.1: Divide the updated time series forecasting model parameters into basic parameters and incremental parameters; Step 4.2: Store the basic parameters in the basic parameter table of the time series forecasting model in the form of a row-based table; Step 4.3: Divide the incremental parameters into different incremental parameter blocks according to the different levels of the time series forecasting model. Each incremental parameter block is an incremental parameter of the same level of time series forecasting model and corresponds to a parameter value field column in the column storage table. Step 4.4: Store the incremental parameter blocks in the incremental parameter table of the time series prediction model in the form of a columnar storage table to complete the incremental training of the time series prediction model.

8. The incremental training method for a time series prediction model based on a PostgreSQL database according to claim 7, characterized in that: Step 4.4 specifically includes: Step 4.4.1: Each incremental parameter block corresponds to a parameter value field in the incremental parameter table of the time series prediction model; Step 4.4.2: Incrementally assign a version identifier field to each incremental parameter block; Step 4.4.3: Calculate the checksum of each incremental parameter block using a hash algorithm and fill the checksum field of the incremental parameter block with the checksum of each incremental parameter block. Simultaneously, compare the incremental parameter block with the previous version's incremental parameter block to detect the change status of each incremental parameter block. If the incremental parameter block is marked as "changed", perform differential encoding and compression on the changed incremental parameter block to obtain the encoded parameter value field and encoding type field. If the incremental parameter block is marked as "unchanged", only retain the reference to the incremental parameter block of the previous version's time series prediction model in the incremental parameter table. The differential encoding and compression of the changed incremental parameter blocks specifically includes: Maintain a lightweight statistical summary for each parameter value field in the incremental parameter table; the lightweight statistical summary includes sparsity, update magnitude, and access popularity; The incremental parameter blocks are differentially encoded and compressed based on a lightweight statistical summary of each parameter value field. The specific rules for the differential coding compression are as follows: When the sparsity of the parameter value field is higher than the second preset threshold, run length encoding compression is selected; Incremental encoding compression is selected when the sparsity of the parameter value field is lower than the second preset threshold and the update magnitude is lower than the third preset threshold. When the parameter value field is a high-dimensional vector, vector quantization or product quantization is used for compression. When the parameter value field is unstructured metadata, serialization encoding is used first, followed by encoding and compression using a general lossless compression algorithm; If other conditions occur, block-level quantization encoding compression should be selected for the parameter value field; Step 4.4.4: Write the encoded parameter value field, version identifier field, checksum field, and encoding type field into the corresponding columns of the incremental parameter table of the time series prediction model to complete the incremental training of the time series prediction model.

9. The incremental training method for a time series prediction model based on a PostgreSQL database according to claim 1, characterized in that: It also includes step 5: After storing the updated time series prediction model parameters, a version management system for the incrementally trained time series prediction model is established using the PostgreSQL multi-version concurrency control mechanism and extended PostgreSQL transaction logs, so as to achieve traceability of the time series prediction model after incremental training.

10. An incremental training system for a time series prediction model based on a PostgreSQL database, characterized in that: include: Time-series data storage module: Divides the raw time-series data into time-series data blocks and stores the time-series data blocks in PostgreSQL data tables; Time-series data sampling module: It uses the two-level time-series sampling mechanism encapsulated within the PostgreSQL database to sample PostgreSQL data tables and obtain the sampled dataset; Model training module: Input the sampled dataset into the built-in time series prediction model of the PostgreSQL database for training, and output the updated time series prediction model parameters after training is completed; Model parameter storage module: A hybrid row and column storage strategy is used to store the updated time series prediction model parameters to complete the incremental training of the time series prediction model.

Images