Prediction driving-based storage and calculation separation key value storage delay optimization method

Abstract

The invention discloses a storage and calculation separation key value storage delay optimization method based on prediction driving, and aims to solve the problems of performance bottleneck and high tail delay caused by passive management and high network delay in a key value storage system in a storage and calculation separation scene. The method comprises the following steps: time load prediction: deploying a time sequence prediction model at a client, and predicting a future read-write request based on a historical access sequence; active cache prefetching: according to the predicted read request, actively preloading hotspot data from a server side to a client side for caching so as to improve the cache hit rate and hide network delay; active write-in optimization: according to the predicted write request, executing maintenance at a server side through predictive pre-insertion and active node splitting, and moving high index structure adjustment overhead out of a key request path to eliminate a write delay peak; and structure sensing batch synchronization: pre-fragmenting a local write buffer by using a server index top layer model of a client cache, and combining multiple independent remote insertion operations into one efficient batch update to reduce data synchronization overhead. Compared with an existing passive management system, the characteristics of model prediction and active cooperation are fully utilized, and the average delay and the tail delay of the system are reduced.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of computer storage, and particularly relates to a performance optimization method of a key-value storage system in a storage-computation separation scenario, and especially to a method based on workload prediction and active cooperation mechanism, aiming to reduce read-write delay, especially tail delay. BACKGROUND

[0002] Key-value storage is a basic component of modern high-performance data systems. To cope with the inherent scalability and cost-effectiveness challenges of traditional monolithic servers, the industry and academia are increasingly adopting storage-computation separation architecture. In this architecture, computing resources and memory resources are decoupled into independent resource pools and interconnected through high-speed networks such as remote direct memory access (RDMA). Although this architecture improves resource flexibility and utilization, it also introduces non-negligible network delay, posing new challenges to data access performance.

[0003] Under this emerging architecture, learning-based indexes show great potential to outperform traditional B+ trees and other structures due to their excellent space efficiency and query performance. Learning-based indexes treat index lookup as a regression problem, training a model to directly predict the location of a key, which ideally reduces multiple remote pointer chases to a single network round trip, thereby greatly reducing read operation delay. However, existing distributed storage systems based on learning-based indexes generally adopt a passive design, which has three major performance bottlenecks under dynamic load.

[0004] Read delay bottleneck caused by passive cache filling strategy. Existing systems usually only load data from remote memory nodes passively after a cache miss occurs. In a storage-computation separation environment with significant network delay, each cache miss will inevitably result in a high network round trip overhead. This strategy cannot effectively hide remote access delay, severely limiting read throughput in high-concurrency scenarios.

[0005] High tail delay caused by blocking structure maintenance. The low efficiency of the write path of learning-based indexes is rooted in its passive structure update mechanism. When the target data node capacity of an insertion operation is insufficient, the system will synchronously trigger a node split or reorganization on the foreground critical path. This process involves multiple RDMA operations, memory allocation, and data migration, which will exacerbate system delay.

[0006] Inefficient data synchronization mechanism. To distribute network overhead, client write operations are usually buffered locally before being synchronized in bulk to memory nodes. However, existing synchronization protocols ignore the structure of remote indexes and fail to utilize the orderliness of buffered data, placing a heavy processing burden on memory nodes with limited computing power.

[0007] The root cause of the above challenges lies in the passive design of the system, i.e., the system only reacts to the events that have occurred (such as cache miss, node write full), and fails to take advantage of the predictable patterns such as temporal locality and sequential dependency that exist in the workload. Therefore, how to change the system design from passive response to active prediction and collaborative optimization, by foreseeing the management of cache and maintaining the index structure, is the key to solving the latency problem of distributed key-value storage system. SUMMARY

[0008] In view of the deficiencies of the prior art, the purpose of the present application is to provide a prediction-driven storage-computation separation key-value storage latency optimization method.

[0009] To achieve the above technical purpose, the technical scheme adopted by the present application is:

[0010] A prediction-driven storage-computation separation key-value storage latency optimization method, comprising:

[0011] Temporal load prediction: deploy and run a time series prediction model at the client side, predict future read and write requests based on historical access request sequence, and provide decision basis for subsequent active cache and write optimization;

[0012] Active cache prefetching: according to the read request generated by the temporal load prediction, actively obtain data from the server side and load it to the client cache before the actual access occurs, to improve the cache hit rate and hide the network latency;

[0013] Active write optimization: according to the write request generated by the temporal load prediction, perform predictive pre-insertion and active node splitting and other maintenance operations on the server side, move the overhead of index structure adjustment out of the critical request path, and eliminate the delay spike caused by write operation;

[0014] Structure-aware batch synchronization: use the server-side index top-level model of the client cache to pre-shard the local write buffer data, combine multiple independent remote insertion operations into an efficient batch write, and reduce the network and computing overhead during data synchronization.

[0015] Preferably, the temporal load prediction comprises the following steps:

[0016] Step A1: map the discrete key ID sequence of historical access to a continuous vector sequence through an embedding layer (Embedding Layer), to realize the vectorization of input and capture the potential semantic relationship between keys;

[0017] Step A2: use a gated recurrent unit (GRU) encoder to process the vector sequence, compress it into a fixed-dimensional context vector to complete sequence encoding, and the context vector summarizes the temporal dependency and pattern of the historical access sequence;

[0018] Step A3: Sequence decoding by GRU decoder in an auto-regressive manner with the context vector as the initial state to generate the prediction of future key IDs one by one;

[0019] Step A4: Combine the segmental recursive prediction strategy with the Top-k sampling mechanism to generate a long prediction sequence that is diversified and consistent with the statistical characteristics of the real load, and finally divide the sequence into a predicted read request set and a predicted write request set to guide the subsequent active optimization.

[0020] Preferably, the active cache prefetching specifically includes the following steps:

[0021] Step B1: Obtain the predicted read request set generated by the time load prediction (Step A4);

[0022] Step B2: For each target key in the predicted read request set, the client initiates a data acquisition request to the server asynchronously before the actual application request occurs;

[0023] Step B3: The data returned by the server in response to the asynchronous request is preloaded into the local index or cache of the client;

[0024] Step B4: Thus, subsequent actual read requests can be satisfied by local cache hits, thereby avoiding network round-trip delays caused by remote access.

[0025] Preferably, the active write optimization includes the following components:

[0026] Component C1: The client obtains the predicted write request set generated by the time load prediction (Step A4), uses the cached server-side index top-level model to perform efficient local routing on the request set, groups the target keys to their corresponding target data nodes on the server side; then, obtains the current remaining capacity Cgap(n) of each target data node n through a lightweight remote request; finally, decides whether to start active structure maintenance on the node by calculating the predicted insertion amount 1pred(n) and judging whether the inequality Ipred(n) > θ*Cgap(n) holds according to the preset threshold θ;

[0027] Component C2: As an active maintenance strategy, for all predicted write requests, the server determines the theoretical insertion position of the key in the target data node, and reserves physical slots by moving subsequent key-value pairs; the key is to mark the reserved slots as logical available gaps in the index node's state bitmap, thereby converting the subsequent actual insertion operation into a no-structure-adjustment, low-overhead in-place write.

[0028] Component C3: When and only when the decision result of component C1 determines that the target data node will suffer from high write pressure, the server side performs a split operation on the high write pressure node asynchronously in the background before executing the logical space reservation; this operation aims to allocate new node resources in advance for the upcoming intensive writes, so as to completely remove the expensive and passive structural modification overhead from the foreground critical request path.

[0029] Preferably, the structure-aware bulk synchronization comprises the following steps:

[0030] Step D1: When the write buffer data in the local index of the client reaches a preset threshold, the synchronization process is triggered, and the batch of naturally ordered key-value pairs to be synchronized is extracted from the local index; to reduce network traffic, only the entries marked as newly inserted or updated can be selectively included;

[0031] Step D2: The client uses its cached server-side index top-level model to perform local pre-sharding processing on the batch of key-value pairs, divides the batch into multiple sub-batches, each of which contains all the key-value pairs to be written to the same server-side target data node, and attaches the global address of the target data node to each sub-batch;

[0032] Step D3: All pre-sharded sub-batches and their attached global addresses are bundled into a single structured bulk request and sent to the server side through a network transmission;

[0033] Step D4: After receiving the bulk request, the server side directly locates the target data node according to the global address attached to each sub-batch without performing index traversal lookup, and efficiently inserts the ordered sub-batch data into the existing gap of the target node through a low-computational-overshead merge-like operation;

[0034] Step D5: An optimistic consensus protocol is adopted to ensure data consistency, in which the server-side top-level model maintains a version number, and the client attaches the model version number used for pre-sharding when sending the bulk request; the server side checks whether the version numbers are consistent before performing the insertion; if not, the request is rejected and the latest model information is returned, and the client retries the synchronization process based on the new information.

[0035] According to the prediction-driven storage-computation separation key-value storage delay optimization method provided by the application, the following steps are included:

[0036] Time load prediction: a time series prediction model is deployed and run on the client side, and future read-write requests are predicted based on historical access request sequences.

[0037] Proactive cache prefetching: read requests generated by time load prediction are proactively fetched from server side and loaded into client cache before actual access happens to hide network latency.

[0038] Proactive write optimization: write requests generated by time load prediction are preemptively maintained on server side to remove structure adjustment overhead out of critical path to eliminate latency spikes.

[0039] Structure-aware bulk synchronization: client pre-sharding local write buffer with server index model to combine multiple independent inserts into one efficient bulk update.

[0040] Compared with the prior art, the present application has the following advantages and beneficial effects:

[0041] 1. Proactive design fundamentally optimizes performance: by introducing load prediction, the present application changes cache management and index maintenance from passive response to proactive preparation, which can foreseeably hide network latency and avoid blocking operations, fundamentally solving the read latency bottleneck and high tail latency problem caused by passive design.

[0042] 2. Collaborative synchronization mechanism improves write efficiency: the present application proposes a structure-aware synchronization protocol, which uses client's perception of remote index structure to pre-shard locally, converts a large number of discrete inserts into one efficient bulk update, and significantly reduces network overhead and remote node computing load during data synchronization.

[0043] 3. Significantly reduce write operation tail latency: through proactive write optimization, especially proactive structure modification mechanism, the present application asynchronously moves expensive index structure maintenance overhead from the foreground critical request path to the background, effectively eliminating the delay spikes caused by node write full, and ensuring the performance stability of the system under high write load.

[0044] 4. Improve the overall throughput under dynamic load: through the collaborative optimization of read path and write path, the present application can achieve higher cache hit rate and smoother write latency under dynamic mixed workloads, thereby obtaining higher throughput than existing systems. BRIEF DESCRIPTION OF DRAWINGS

[0045] Figure 1 is the overall framework diagram of the present application;

[0046] Figure 2 is the time load prediction process schematic diagram of the specific embodiment of the present application;

[0047] Figure 3 is the proactive cache prefetching schematic diagram of the present application;

[0048] Figure 4 A pre-insertion utilization state bitmap diagram for a specific embodiment of the present application;

[0049] Figure 5 A structure-aware batch synchronization process diagram for a specific embodiment of the present application. DETAILED DESCRIPTION

[0050] The present application will be further described with reference to the drawings and specific embodiments, it should be understood that these embodiments are only used to illustrate the present application and not used to limit the scope of the present application, after reading the present application, various equivalent modifications of the present application by those skilled in the art fall within the scope defined by the appended claims.

[0051] According to the present application, a prediction-driven storage-computation separation key-value storage delay optimization method is provided, as shown in Figure 1 The method comprises the following steps:

[0052] Time load prediction: deploying and running a time series prediction model at the client side, predicting future read and write requests based on historical access request sequences, providing decision basis for subsequent active caching and write optimization;

[0053] Active caching pre-fetching: according to the read request generated by the time load prediction, actively obtaining data from the server side and loading it to the client cache before the actual access occurs, to improve cache hit rate and hide network delay;

[0054] Active write optimization: according to the write request generated by the time load prediction, performing predictive pre-insertion and active node splitting and other maintenance operations at the server side, moving the index structure adjustment overhead out of the critical request path, to eliminate the delay spike caused by write operation;

[0055] Structure-aware batch synchronization: using the server-side index top-level model cached by the client, pre-sharding the local write buffer data, combining multiple independent remote insertion operations into an efficient batch write, to reduce network and computing overhead during data synchronization.

[0056] Specifically, the time load prediction process comprises the following steps as shown in Figure 2

[0057] Step A1: mapping the discrete key ID sequence of historical access through an embedding layer (Embedding Layer) to a continuous vector sequence, to realize input vectorization and capture the potential semantic relationship between keys;

[0058] Step A2: using a gated recurrent unit (GRU) encoder to process the vector sequence, compressing it into a fixed-dimensional context vector to complete sequence encoding, the context vector summarizes the time dependence and pattern of the historical access sequence;​

[0059] Step A3: Sequence decoding by GRU decoder in an auto-regressive manner to generate the prediction of future key IDs one by one, with the context vector as the initial state;

[0060] Step A4: Combining the segmented recursive prediction strategy with the Top-k sampling mechanism to generate a long prediction sequence that is diversified and consistent with the statistical characteristics of the real load, and finally dividing the sequence into a predicted read request set and a predicted write request set to guide the subsequent active optimization.

[0061] Specifically, for steps A1 to A3, the input of the model is a historical key ID sequence of length W. The sequence is first mapped to a low-dimensional dense vector sequence by an embedding layer, and then compressed into a fixed-dimensional context vector by a GRU encoder. The context vector is used as the initial state of the GRU decoder to generate the prediction of future keys one by one in an auto-regressive manner.

[0062] Specifically, for step A4, to generate a long prediction sequence that is consistent with the statistical characteristics of the real load, the process combines the segmented recursive prediction strategy with the Top-k sampling mechanism. The final generated prediction sequence is divided into a predicted read request set and a predicted write request set at the client side to serve as the input for active cache prefetching and active write optimization, respectively.

[0063] Specifically, as shown in Figure 3 the active cache prefetching specifically includes the following steps:

[0064] Step B1: Obtain the predicted read request set generated by the time load prediction (step A4);

[0065] Step B2: For each target key in the predicted read request set, the client initiates a data acquisition request to the server side asynchronously before the actual application request occurs;

[0066] Step B3: The data returned by the server side in response to the asynchronous request is preloaded into the local index or cache of the client side;

[0067] Step B4: Thus, the subsequent actual read request can be satisfied by the local cache hit, thereby avoiding the network round-trip delay caused by remote access.

[0068] Specifically, for steps B2 and B3, the prediction thread of the client is responsible for executing the procedure. When the thread predicts the sequence of hot data keys that are likely to be accessed in the future through the timing model, it packs the predicted keys into a batch request and sends it to the server asynchronously through an independent RDMA connection. After receiving the request, the server searches for the keys in its global index and writes all the hit key-value pairs into a dedicated, client-readable RDMA buffer. After completing the write, the server notifies the client that the data is ready through an RDMA SEND operation with immediate data. Upon receiving the notification, the client initiates an RDMA Read operation to read all the hot data in the buffer at once and batch-inserts them into the local lightweight learning index, thus completing the efficient cache prefetching.

[0069] Specifically, the active write optimization includes the following components:

[0070] Component C1: The client obtains the predicted write request set generated by the time load prediction (step A4), uses its cached server-side index top-level model to perform efficient local routing on the request set, grouping the target keys to their corresponding target data nodes on the server side; then, it obtains the current remaining capacity Cgap(n) of each target data node n through lightweight remote requests; finally, it calculates the predicted insertion amount Ipred(n) and determines whether the inequality Ipred(n) > θ * Cgap(n) holds according to the preset threshold θ, to decide whether to start active structure maintenance for the node;

[0071] Component C2: As an active maintenance strategy, for all predicted write requests, the server determines the theoretical insertion position of the key in its target data node and reserves physical slots by moving subsequent key-value pairs; the key is to mark the reserved slots as logically available gaps in the index node's state bitmap, thereby converting the subsequent actual insertion operation into a low-overhead in-place write without structure adjustment;

[0072] Component C3: When and only when the decision result of component C1 determines that the target data node will bear high write pressure, the server performs a split operation on the high-write-pressure node asynchronously and actively in the background before performing the logical space reservation; this operation aims to allocate new node resources in advance for the upcoming intensive writes, thereby completely removing the expensive, passive structure modification overhead from the foreground critical request path.

[0073] Specifically, for component C1, after obtaining the set of predicted write requests, the client's prediction thread locally performs preliminary routing of the predicted keys using its cached top-level RMI model of the server-side global index. Subsequently, it sends a lightweight metadata request containing the addresses of the grouped target nodes to the server side. After receiving the request, the server side returns the current remaining gap capacities (Cgap) of the target nodes. The client finally locally performs quantification calculation and decision-making of the write pressure.

[0074] Specifically, referring to Figure 4 For components C2 and C3, the client sends the active maintenance instruction containing the set of "potential insertion keys" and the decision result to the server side. After receiving the instruction, the server's main thread asynchronously executes the hierarchical maintenance strategy. If the decision result is yes, the server first performs standard node splitting. Subsequently, regardless of whether splitting is performed, the server performs pre-insertion operations on the target node (or the new node after splitting): determines the theoretical position of each potential insertion key using the state bitmap, moves existing data to reserve physical slots, but keeps the state of these slots in the bitmap as 0, i.e., logical gaps.

[0076] Specifically, as Figure 5 shown, the structure-aware bulk synchronization includes the following steps:

[0077] Step D1: When the write buffer data in the client's local index reaches a preset threshold, the synchronization process is triggered, and the naturally ordered key-value pair batches to be synchronized are extracted from the local index; to reduce network traffic, only entries marked as newly inserted or updated can be selectively included;

[0078] Step D2: The client uses its cached top-level model of the server-side index to locally pre-shard the key-value pair batches, dividing the batches into multiple sub-batches, each of which contains all key-value pairs to be written to the same target data node of the server side, and attaching the global address of the target data node to each sub-batch;

[0079] Step D3: All pre-sharded sub-batches and their attached global addresses are bundled into a single, structured bulk request, which is sent to the server side through a single network transmission;

[0080] Step D4: After receiving the bulk request, the server side does not need to perform index traversal lookup, but directly locates the target data node according to the global address attached to each sub-batch, and efficiently inserts the ordered sub-batch data into the existing gaps in the target node through a low-computational-cost merge-like operation;

[0081] Step D5: Data consistency is guaranteed by optimistic cooperative protocol, in which the server-side top-level model maintains a version number, and the client-side attaches the model version number used for pre-sharding when sending batch requests; the server-side checks the version number before executing the insertion, and if it is inconsistent, the request is rejected and the latest model information is returned, and the client-side retries the synchronization process based on the new information.

[0082] Specifically, for steps D1 to D3, when the capacity of the lightweight learning index locally on the client reaches a threshold, the main thread of the client triggers synchronization. It first extracts all new insertions and updated entries in the local index into an ordered array. Then, the thread uses the cached server-side global index top-level RMI model to perform efficient pre-sharding of the ordered array locally. All the shards with the target node global address, along with the top-level model version number used by the client, are written into a dedicated RDMA buffer and transmitted to the server-side through an RDMA Write operation in one go, and finally a notification message is sent.

[0083] Specifically, for steps D4 and D5, after receiving the notification, the server-side main thread first checks whether the model version number carried in the request is consistent with the version number of the current top-level model. If it is consistent, it directly locates the target data node according to the address of each sub-batch in the request and performs efficient merge-like insertion; if it is not consistent, it rejects the write and returns the latest top-level model information to the client, which refreshes the cache and retries.

[0084] According to the method provided by the application, a prediction-driven storage-computation separation key-value storage delay optimization method is provided, which comprises:

[0085] Time load prediction: a time series prediction model is deployed and run on the client side, and future read and write requests are predicted based on historical access request sequences.

[0086] Active cache prefetching: read requests generated according to time load prediction are actively obtained from the server side and loaded into the client cache before actual access occurs to hide network delay.

[0087] Active write optimization: write requests generated according to time load prediction are executed preemptively on the server side to remove structure adjustment overhead from the critical path to eliminate delay spikes.

[0088] Structure-aware batch synchronization: the client uses the server index model to pre-shard the local write buffer, combining multiple independent insertions into an efficient batch update.

[0089] In the description of the present application, it should be understood that the terms "upper", "lower", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the purpose of facilitating the description of the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the present application.

[0090] The specific embodiments of the present application are described above. It should be understood that the present application is not limited to the specific embodiments described above, and various changes or modifications can be made by those skilled in the art within the scope of the claims, which do not affect the essential content of the present application. The embodiments of the present application and the features in the embodiments can be arbitrarily combined with each other in the case of no conflict.

Claims

1. A prediction-driven, in-memory / computation-separated key-value storage latency optimization method, characterized in that, include: Time-based load prediction: Deploy and run a time-based prediction model on the client side to predict future read and write requests based on historical access request sequences, providing a basis for decision-making for subsequent proactive caching and write optimization; Proactive cache prefetching: Based on read requests generated by time load prediction, data is proactively retrieved from the server and loaded into the client cache before the actual access occurs, in order to improve cache hit rate and hide network latency; Proactive write optimization: Based on the write requests generated by time load prediction, perform maintenance operations such as predictive pre-insertion and proactive node splitting on the server side to move the overhead of index structure adjustment out of the critical request path, thereby eliminating latency spikes caused by write operations. Structure-aware batch synchronization: Utilizing the top-level model of the server-side index cached by the client, the local write buffer data is pre-sharded, merging multiple independent remote insert operations into a single efficient batch write to reduce network and computational overhead during data synchronization.

2. The prediction-driven, in-memory-compute separation key-value storage latency optimization method according to claim 1, characterized in that, The time load prediction specifically includes the following steps: Step A1: Map the discrete key ID sequence of historical accesses into a continuous vector sequence through an embedding layer to vectorize the input and capture the potential semantic relationships between keys; Step A2: The vector sequence is processed using a gated cyclic unit (GRU) encoder to compress it into a fixed-dimensional context vector to complete the sequence encoding. The context vector summarizes the temporal dependencies and patterns of the historical access sequence. Step A3: Using the context vector as the initial state, perform sequence decoding in an auto-regressive manner through the GRU decoder to generate predictions for future key IDs one by one; Step A4: Combine the segmented recursive prediction strategy with the Top-k sampling mechanism to generate a diverse long prediction sequence that conforms to the statistical characteristics of the real load. Finally, divide the sequence into a predicted read request set and a predicted write request set to guide subsequent proactive optimization.

3. The prediction-driven, in-memory-compute separation key-value storage latency optimization method according to claim 1, characterized in that, The active cache prefetching specifically includes the following steps: Step B1: Obtain the predicted read request set generated by the time load forecast (step A4); Step B2: For each target key in the predicted read request set, the client asynchronously initiates a data retrieval request to the server before the actual application request occurs; Step B3: Preload the data returned by the server in response to the asynchronous request into the client's local index or cache; Step B4: This ensures that subsequent actual read requests can be hit and satisfied by the local cache, thereby avoiding network round-trip delays caused by remote access.

4. The prediction-driven, in-memory-compute separation key-value storage latency optimization method according to claim 1, characterized in that, The proactive write optimization comprises three components: write pressure quantization and decision-making, predictive insertion, and proactive structural modification. Component C1: The client obtains the predicted write request set generated by the time load prediction (step A4), and uses its cached server-side index top-level model to perform efficient local routing on the request set, grouping the target keys to their corresponding target data nodes on the server side; then, it obtains the current remaining capacity Cgap(n) of each target data node n through a lightweight remote request; finally, it calculates the predicted insertion amount Ipred(n) and judges whether the inequality Ipred(n)>θ*Cgap(n) holds based on the preset threshold θ, to decide whether to start active structure maintenance for the node; Component C2: As a proactive maintenance strategy, for all predicted write requests, the server determines the theoretical insertion position of the key within its target data node and reserves a physical slot by shifting subsequent key-value pairs. The key is that in the inode's state bitmap, this reserved slot is marked as a logically available gap, thereby transforming the subsequent actual insertion operation into a low-overhead, in-place write without structural adjustments. Component C3: If and only if the decision result of component C1 determines that the target data node will be subjected to high write pressure, the server performs a split operation on the high write pressure node asynchronously and proactively in the background before performing the logical space reservation; this operation aims to allocate new node resources in advance for the upcoming intensive write, thereby completely removing the expensive, passive structural modification overhead from the foreground critical request path.

5. The prediction-driven, in-memory-compute separation key-value storage latency optimization method according to claim 1, characterized in that, The structure-aware batch synchronization includes the following steps: Step D1: When the write buffer data in the client's local index reaches a preset threshold, the synchronization process is triggered, and the batch of naturally ordered key-value pairs to be synchronized is extracted from the local index; to reduce network traffic, only entries marked as newly inserted or updated may be selectively included. Step D2: The client uses its cached server-side index top-level model to perform local pre-sharding on the key-value pair batch, dividing the batch into multiple sub-batches, where each sub-batch contains all key-value pairs that will be written to the same server-side target data node, and appends the global address of the target data node to each sub-batch. Step D3: Bundle all pre-fragmented sub-batches and their associated global addresses into a single, structured batch request and send it to the server in a single network transmission. Step D4: After receiving the batch request, the server does not need to perform an index traversal search. Instead, it directly locates the target data node based on the global address attached to each sub-batch and efficiently inserts the ordered sub-batch data into the existing gaps in the target node through a low-computation merge-like operation. Step D5: An optimistic collaborative protocol is used to ensure data consistency. The top-level model on the server side maintains a version number. When the client sends a batch request, it attaches the model version number used for pre-sharding. Before performing the insertion, the server checks whether the version numbers are consistent. If they are inconsistent, the request is rejected and the latest model information is returned. The client then retryes the synchronization process based on the new information. A prediction-driven, in-memory / computation-separated key-value storage latency optimization method, characterized in that, include: Time-based load forecasting: Deploy and run a time-based forecasting model on the client side to predict future read and write requests based on historical access request sequences. Proactive cache prefetching: Based on read requests generated by time load prediction, data is proactively retrieved from the server and loaded into the client cache before the actual access occurs, in order to hide network latency. Proactive write optimization: Based on write requests generated by time load prediction, preemptive maintenance is performed on the server side to move structural adjustment overhead off the critical path to eliminate latency spikes. Structure-aware batch synchronization: The client uses the server index model to pre-shard the local write buffer, merging multiple independent insertions into a single efficient batch update.

Images