Data relationship and state separated storage method, response processing method and equipment

Abstract

The invention provides a data relation and state separated storage method, a response processing method and equipment, and belongs to the technical field of computer data storage and management. The method comprises the following steps: performing hash calculation on a target key, and determining a bucket number and an index position; and writing the key information of the target key into a corresponding index position in the key state page, writing the value data associated with the target key into a specified storage area in the value state page, recording a pointer pointing to the specified storage area at the corresponding index position in the key state page, and setting an effective mark as effective. By adopting a storage architecture in which a key metadata area is separated from a value data area, a key identifier, an effective mark and a storage position index pointing to the value data area are maintained in the key metadata area, and actual state data are independently stored in the value data area, so that physical storage of the state data and relation management of keys can be decoupled.

Description

TECHNICAL FIELD

[0001] The present disclosure belongs to the technical field of computer data storage and management, and relates to a data relationship and state separation storage method, a response processing method and equipment. BACKGROUND

[0002] In existing data storage systems, especially Key-Value storage engines and state management frameworks, a way of storing keys and their corresponding complete value data in close coupling is usually adopted. Typical implementations such as LevelDB, RocksDB, and other Log-Structured Merge (LSM) tree systems, or hash table structures in in-memory databases, all organize data in the form of "key + complete value record". In such designs, value data not only contains actual state content, but also implicitly contains key-related meta-information (such as version, validity period, reference relationship, etc.), or the index structure of the key is deeply bound to the value storage location.

[0003] Such a coupled storage architecture exposes significant defects when facing frequent update or deletion operations. First, the update operation must rewrite the entire value record, even if only a small change occurs in the state data, the original storage space cannot be reused, resulting in a serious write amplification problem. Second, in the deletion scenario, the system often needs to immediately erase or mark the entire record, making it difficult to implement an efficient delayed recycling mechanism, affecting the garbage collection efficiency. Third, since the validity, life cycle, and other relationship information of the key are mixed with the value data, the entire record needs to be locked during concurrent read and write, limiting the parallel processing capability of the system. In addition, in persistent storage, if the index structure of the key is strongly associated with the physical location of the value, value migration or compression operations will trigger massive index reconstruction, further increasing the system overhead.

[0004] Although some systems attempt to alleviate the above problems by introducing an append-only log or version number mechanism, the underlying still does not achieve the separation of the relationship information (such as validity, address mapping) of the key and the state data of the value at the logical and physical levels. For example, although Chinese patent CN109117352A abstracts features from user request logs in server performance prediction, the feature vectors and original logs are still stored in whole form, without decoupling metadata and state content. Similarly, traditional state tables also package identification, attributes, and association relationships into a single record when storing device states, service configurations, etc., lacking independent management of "relationships" and "states".

[0005] Therefore, there is an urgent need in the prior art for a mechanism that can separate the relationship metadata of the key and the state data of the value for storage, to support efficient data update, atomic visibility control, low-overhead garbage collection, and high-concurrency read-write access. SUMMARY

[0006] This disclosure provides a storage method, response processing method, and device that separate data relationships from state.

[0007] According to one aspect of this disclosure, a storage method for separating data relationships and states is provided, comprising the following steps: performing a hash calculation on an input target key to determine the bucket number and index position of the target key in a key state page; performing a write operation to write the key information of the target key to the corresponding index position in the key state page, writing the value data associated with the target key to a specified storage area in the value state page, recording a pointer to the specified storage area at the corresponding index position in the key state page, and setting a valid flag to valid.

[0008] According to at least one embodiment of the storage method of this disclosure, the method further includes a query operation, in response to a query request, accessing the corresponding index position in the key status page through hash calculation based on the target key in the query request, determining whether the valid flag at the index position is valid, and if valid, reading the corresponding value data from the value status page according to the pointer and returning it.

[0009] According to at least one embodiment of the storage method of this disclosure, the method further includes an update or deletion operation: in response to an update request, writing new value data into a new storage area of ​​the value status page, updating the pointer of the corresponding index position of the key status page to point to the new storage area, and keeping the validity flag valid; in response to a deletion request, only modifying the validity flag of the corresponding index position of the key status page to invalid.

[0010] According to at least one embodiment of the storage method of this disclosure, before writing the value data associated with the target key into a designated storage area in the value status page, the following steps are performed: performing business logic processing on the input data; generating status data including a device status identifier D, a service status S, and an object status set Os; using the status data as value data associated with the target key to write into the value status page; and sending a write completion event to trigger a data change notification process.

[0011] According to at least one embodiment of the storage method of this disclosure, the method further includes, after sending a write completion event to trigger a data change notification process, performing the following steps: receiving the write completion event; querying a subscription relationship table based on a status table identifier carried in the write completion event; determining one or more target service providers that have subscribed to the status table; and sending a notification message to each target service provider, the notification message including a status table identifier and a change key identifier.

[0012] According to at least one embodiment of the storage method disclosed herein, the method further includes, after sending a notification message to each target service provider, performing the following steps: receiving the notification message; parsing the notification message to obtain a status table identifier and a change key identifier; calling a unified read interface and passing in the status table identifier and the change key identifier; receiving the returned updated status data; and performing local business rule judgment and processing logic based on the status data.

[0013] According to at least one embodiment of the storage method of this disclosure, the method further includes, after the local business rule judgment and processing logic is executed based on the state data, performing the following steps: generating new state data based on the local processing result; writing the new state data into another business data state table; sending a new write completion event; and triggering the next level of data reading and processing flow in response to the new write completion event.

[0014] According to at least one embodiment of the storage method of this disclosure, the method further includes, before writing the value data associated with the target key into a designated storage area in the value status page, performing the following steps: loading a business data format file from a storage medium before writing; parsing the business data format file to obtain the field names, data types, field lengths, and index configurations of the target status table; organizing the status data to be written into structured records according to the field configurations; serializing the structured records into binary format; and using the binary format data as the content to be written into the value status page.

[0015] According to at least one embodiment of the storage method of this disclosure, the method further includes performing the following steps before performing hash calculation on the input target key to determine its bucket number and index position in the key state page: reading a business data format file at system startup; creating a corresponding memory state table structure for each business module; reading historical data records of each state table from persistent storage; loading the historical data records into the corresponding memory state table; and reconstructing a hash index for each state table based on the key identifier.

[0016] According to at least one embodiment of the storage method of this disclosure, the step of writing new value data to a new storage area of ​​the value status page and updating the pointer in the key status page to point to the new area in response to an update or delete request includes: calling a write interface and passing in a status table identifier, a key identifier, and status data; receiving a write request; allocating a new storage location in the value status page; writing the status data to the storage location; updating the validity flag of the corresponding key identifier in the key status page to be valid, and recording the pointer pointing to the storage location.

[0017] According to at least one embodiment of the storage method of this disclosure, the step of responding to a query request and accessing the corresponding index position in the key status page according to the target key includes: calling a read interface and passing in a status table identifier and a key identifier; receiving a read request; searching for the table entry corresponding to the key identifier in the key status page; determining whether the valid flag in the table entry is valid; if the valid flag is valid, reading the corresponding status data from the value status page according to the pointer in the table entry; and returning the status data.

[0018] According to at least one embodiment of the storage method of this disclosure, the method further includes, before writing the state data into the corresponding business data state table, performing the following steps: storing only device state identifier D, service state S, and object state set Os in the business data state table; not storing call dependency relationships L between storage services in the state table; not storing association relationships OL between objects in the state table; dynamically deriving the call dependency relationships L and association relationships OL based on the currently read state data; and performing subsequent business processing based on the derived relationships.

[0019] According to another aspect of this disclosure, a data response processing method is provided, comprising the following steps: receiving a notification message sent by the storage side, the notification message including a status table identifier and a change key identifier, the status table identifier corresponding to a business data status table using a key-data and value-status separation storage architecture; parsing the notification message and extracting the status table identifier and the change key identifier; calling the unified read interface of the storage side and passing in the status table identifier and the change key identifier; receiving updated status data returned by the unified read interface; and executing local business rule judgment and processing logic based on the updated status data.

[0020] According to at least one embodiment of the data response processing method of this disclosure, after the local business rule judgment and processing logic is executed based on the updated state data, the following steps are performed: generating new state data based on the local business processing result; writing the new state data into another business data state table that adopts a key-data and value-state separation storage architecture; sending a new write completion event; and triggering the next-level data reading and processing process in response to the new write completion event.

[0021] According to another aspect of this disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, causing the processor to perform a method according to any embodiment of this disclosure.

[0022] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements a method according to any embodiment of this disclosure.

[0023] In the scheme of this application embodiment, by adopting a storage architecture that separates the key data area and the value data area, the key data area maintains the key identifier, validity flag, and storage location index pointing to the value data area, while the actual state data is stored independently in the value data area, which can decouple the physical storage of the state data from the relationship management of the keys; by only writing new value data records and modifying the index in the key data area during updates, and only setting the invalid validity flag during deletions, in-place rewriting can be avoided, significantly reducing write amplification; by first reading the key data area to determine validity and obtain the index during queries, and then accessing the value data area as needed, high-concurrency lock-free reading can be supported while ensuring data consistency. Attached Figure Description

[0024] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0025] Figure 1 This is a schematic interactive flowchart of a storage method according to one embodiment of the present disclosure; Figure 2 This is a data-driven programming model diagram according to one embodiment of the present disclosure; Figure 3 This is a schematic diagram of a data reading and writing scheme according to one embodiment of the present disclosure; Figure 4 This is a schematic diagram of a deployment scheme according to one embodiment of the present disclosure; Figure 5 This is a schematic diagram of a key-value space according to one embodiment of the present disclosure; Figure 6 This is a schematic diagram of a key-value storage according to one embodiment of the present disclosure; Figure 7 This is a schematic diagram of a data insertion process according to one embodiment of the present disclosure; Figure 8 This is a schematic diagram of a data update process according to one embodiment of the present disclosure; Figure 9 This is a schematic diagram of a data deletion process according to one embodiment of the present disclosure; Figure 10 This is a schematic diagram illustrating the data association between HMS and SMS according to one embodiment of the present disclosure; Figure 11 This is a schematic diagram of key-value separation storage according to one embodiment of the present disclosure; Figure 12 This is a diagram illustrating a key-value separation storage example according to one embodiment of this disclosure; Figure 13This is a schematic diagram of a key-value pair shared data storage space according to one embodiment of the present disclosure; Figure 14 This is a schematic diagram of key-value pair data refresh according to one embodiment of the present disclosure; Figure 15 This is a schematic diagram illustrating key-value data updating and deletion according to one embodiment of the present disclosure; Figure 16 This is a schematic diagram of a key-value cache space according to one embodiment of the present disclosure; Figure 17 This is a schematic diagram of dynamic migration of key space pages according to one embodiment of the present disclosure; Figure 18 This is a schematic diagram of cache refresh after dynamic migration of key space pages according to one embodiment of this disclosure; Figure 19 This is a schematic diagram of dynamic migration of spatial pages according to one embodiment of the present disclosure. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0028] To achieve separate storage of data relationships and state, the following specific implementation problems need to be addressed: how to organize the underlying storage structure so that the metadata of keys (including validity and address mapping) is logically decoupled from state data; how to write new state data without blocking concurrent reads; how to support efficient updates and space reclamation of state records through lightweight mechanisms; and how to ensure that service components can still correctly deduce the required business relationships when only retrieving state data. These problems directly affect the feasibility and operational efficiency of the separate storage mechanism.

[0029] Therefore, this disclosure proposes the following technical solution, wherein a storage method for separating data relationships and states is provided, the method comprising the following steps: Perform a hash calculation on the input target key to determine the bucket number and index position of the target key in the key status page; The write operation writes the key information of the target key to the corresponding index position in the key status page, writes the value data associated with the target key to the specified storage area in the value status page, records a pointer to the specified storage area at the corresponding index position in the key status page, and sets the valid flag to valid. The query operation responds to the query request. Based on the target key in the query request, it accesses the corresponding index position in the key status page through hash calculation, determines whether the valid flag at the index position is valid, and if valid, reads the corresponding value data from the value status page according to the pointer and returns it. For update or delete operations, in response to an update request, the new value data is written to a new storage area of ​​the value status page, and the pointer of the corresponding index position of the key status page is updated to point to the new storage area, while keeping the validity flag valid; in response to a delete request, only the validity flag of the corresponding index position of the key status page is modified to invalid.

[0030] Terminology Definition To facilitate description and make the technical solutions of this disclosure easier to understand, the terminology of this disclosure will be explained before describing the technical solutions of this disclosure.

[0031] 1) HMS: Heap Memory Space. (Process isolation) 2) SMS: Shared Memory Space. Shared memory space (shared by processes); 3) PDS: Persistence Disk Space. 4) BKS: Business Key Space; 5) BVS: Business Value Space. (Business data value space) 6) BKI: Business Key Index; 7) KA: Key Area. (Keyword area) 8) VA: Value Area. The area containing data values. 9) KS: Key Space; 10) KSP: Key Space Page. 11) VS: Value Space. 12) VSHP: Value Space Hash Page. 13) VSP: Value Space Page.

[0032] Figure 1 A schematic diagram illustrating the overall flow of a storage method according to one embodiment of this disclosure is shown. Figure 1 The method shown includes steps S110 to S140. This method can be performed by an electronic device.

[0033] In step S110, a hash calculation is performed on the input target key to determine its bucket number and index position in the key status page. When a service component needs to write or query a certain status data, it first maps the key corresponding to the status data through a hash function to obtain a hash value; then, based on the hash value, it calculates the bucket number and index position within the bucket to which the data belongs in the business data status table, thereby locating the specific record slot.

[0034] In step S120, a write operation is performed, writing the key information of the target key to the corresponding index position in the key status page, writing the value data associated with the target key to a designated storage area in the value status page, recording a pointer to the designated storage area at the corresponding index position in the key status page, and setting the validity flag to valid. In step S130, a query operation is performed, responding to a query request, accessing the corresponding index position in the key status page through hash calculation based on the target key in the query request, determining whether the validity flag at the index position is valid, and if valid, reading the corresponding value data from the value status page according to the pointer and returning it. In step S140, an update or delete operation is performed, responding to an update request, writing the new value data to a new storage area in the value status page, updating the pointer at the corresponding index position in the key status page to point to the new storage area, and keeping the validity flag valid; responding to a delete request, only modifying the validity flag at the corresponding index position in the key status page to invalid.

[0035] By adopting a storage architecture that separates the key data area from the value data area, the key data area maintains key identifiers, validity flags, and indexes pointing to the storage location of the value data area, while the actual state data is stored independently in the value data area. This decouples the physical storage of state data from the relationship management of keys. By writing only new value data records and modifying the indexes in the key data area during updates, and only setting invalid or valid flags during deletions, in-place rewriting can be avoided, significantly reducing write amplification. By first reading the key data area to determine validity and obtain the index during queries, and then accessing the value data area as needed, high-concurrency lock-free reads can be supported while ensuring data consistency.

[0036] like Figure 2As shown, the data-driven programming model is a programming approach that triggers business logic execution through data changes. This model emphasizes the management and synchronization of data state, and through a data change notification mechanism, enables various service components to respond to data updates in real time, thereby achieving efficient system operation and automated processing.

[0037] 1. Service Components: 1) Each service component is responsible for specific business logic processing and writes the processing results to the corresponding business data status table; 2) When the data status changes, the service component will notify the data status management component through the data change notification mechanism.

[0038] 2. Business Data Status Table: 1) Each business data status table corresponds to a service component, storing the processing results and status information of that component; 2) The business data status table can be used to persistently store data for subsequent querying and analysis.

[0039] 3. Data Status Management Component (Core Component): 1) Business Data Status Table Registration and Format Parsing: Read and parse the definition structure (fields, types, lengths, indexes, etc.) of each status table from the "Business Data Format File" to ensure consistent understanding of the data structure across different business modules; 2) Business Data Status Table Read / Write: Provides a unified read and write interface for business components. It receives write data operations from service components, updates the corresponding business data status table, and notifies other service components subscribed to that business data. It also receives read data operations from service components and returns data from the business data status table. 3) Business data status table persistence: Persist the status pages in memory to the storage medium periodically or on demand; 4) Business data status table recovery and initialization: after system cold start, abnormal restart, or power outage recovery. 5) Receive data information from service components and update the corresponding business data status table according to the data change notification mechanism.

[0040] 4. Data change notification mechanism: 1) When the service component writes data, it triggers the data change notification mechanism to notify the data state management component to perform corresponding data processing and state updates; 2) This mechanism ensures timely synchronization and consistency of data status.

[0041] 5. Figure 2 The detailed process steps are shown, including: 1) Service component A writes data. After executing the logic, component A writes the result data into the "Business A - Data Status Table". The data status table records a certain standard format structure. 2) Data change notification: After writing, the data state management component notifies other interested parties through an event / subscription / callback mechanism. For example, if component B is notified that the data has changed, component B will initiate a data read operation. 3) Service component B writes data. Based on the data changes read from the "Business A - Data Status Table", component B executes its internal business logic and then writes the results to the "Business B - Data Status Table". 4) Trigger the data change notification again. Similarly, module B notifies module C that its state has changed. 5) Service component C processes the data and writes the results into the "Business C-Data Status Table". The entire chain forms a cascading execution model driven by data changes.

[0042] 6. Business data format file: 1) Generated by the data status management component, containing the latest status of all business data; 2) Business data format files are used for data exchange between systems to ensure that different systems can share the latest business data.

[0043] II. Data Read / Write Scheme like Figure 3 As shown, the system implements a write-multiple-read mechanism to ensure data consistency and timeliness. The business component (W) is responsible for data write operations, while the business component (R) performs data read operations through the logical read module (L(R)), enabling parallel read operations and improving the system's read performance.

[0044] 1. Data write operation process: 1) The business component (W) initiates a write operation: 1. The logic processing module (L(RW)) in the business component (W) updates the data based on the key and writes the data to the data state component (D,S). 2) Data status update: 2. After receiving a write operation request, the data state components (D,S) allocate an index for the key and store the data; 3. The data status component (D,S) notifies the logic read module (L(R)) of changes in the mapping relationship between key and index; 3) Notification logic read module: 4. After the data status component (D,S) completes the data writing, it notifies the logical read module (L(R)) of the mapping relationship between the key and the index; 4. The logical read module (L(R)) notifies the business component (R) that the data has changed.

[0045] 2. Data read operation process: 1) Business component (R) initiates read operation: The business component (R) initiates a read request through the logical read module (L(R)); 2) The logical read module handles read requests: The logical read module (L(R)) receives read requests and reads data from the data status components (D,S) according to the key; 3) Data reading and result return: The data status component (D,S) returns the read operation result to the logical read module (L(R)); The logical read module (L(R)) returns the read operation results to the business component (R); 4) Notification to the business component (R): After receiving the read operation result, the business component (R) processes the business logic and updates the business state. III. Deployment Method Figure 4 This describes a system deployment method in a multi-threaded and multi-process environment, involving two main processes, each containing multiple threads, and using shared memory (HMS) for intra-thread communication. The detailed process is described below.

[0046] 1. Multithreaded communication (within a process) 1) Each process contains multiple threads, which communicate with each other via shared memory (HMS); 2) HMS provides a shared data storage area for all threads within a process; 3) Each thread can read or write data through HMS to achieve efficient communication between threads; thread 1.1 can write the processing result to shared memory through HMS, and thread 1.2 can read the data written by thread 1.1 from HMS for subsequent processing.

[0047] 2. Multi-process communication (inter-process) 1) Process 1 and Process 2 share data through a shared memory system (SMS); 2) SMS provides a globally shared memory area that allows different processes to access and modify shared data; 3) SMS ensures data consistency and efficient access between different processes; process 1 can write data to shared memory via SMS. Process 2 can read the data written by process 1 from SMS, realizing inter-process data communication.

[0048] 3. Data persistence 1) Data status and business data are ultimately stored in persistent data storage (PDS); 2) PDS is used to store long-term data, ensuring that system data can be recovered after a restart or crash; 3) After the data is processed in SMS, it will be saved to PDS periodically or in real time; 4) Data in SMS can be periodically synchronized to PDS to ensure data persistence; 5) After the system restarts, data can be recovered from PDS to ensure that no data is lost.

[0049] IV. Key Space Figure 5 It demonstrates a key-value space storage structure, which includes a key space and a value space.

[0050] The key space employs a two-tiered hierarchical design, logically similar to the "page-based management" of an operating system. It divides the entire key space into multiple equal-length key pages (KSPs), each of which can be independently loaded, flushed, replaced, or migrated, providing excellent space management and local update capabilities. The key space is the global key index space, logically responsible for managing all keys and their references to the value space. A key page (KS-Page) is a specific data page within the key space, with each page storing several key entries. The value space has a three-tiered structure: Value Space -> ValueSpace Hash Page (VSHP) -> Value Space Page (VSP). The value space is the logical whole storing all value ontology data (Value Area, VA), and is completely independent of the key space in a key-value separation scenario. To improve the organizational efficiency and concurrency of the value space, it is divided into multiple logical subspaces called value hash spaces (VSHPs), each VSHP responsible for storing a portion of the value data pages. A value page is the smallest physical storage unit in a value space, and each page is used to store multiple value data.

[0051] 1. Key Space 1) KS-Page-I (Meta) and KS-Page-II (Meta): These two pages represent the metadata pages of the key space, storing information about the key space structure and management. They function similarly to a page directory and belong to the first-level control structure of the key space. They maintain the key page distribution, record the number of KS Pages in the Key Space, track the status of each KS Page (validity, version, dirty page flag, etc.), and manage the address mapping relationship of each KSP on disk.

[0052] 2) KS-Page-0, KS-Page-1, ..., KS-Page-N: These are the actual data pages in the key space, storing the specific key data. Each page is of fixed size (e.g., 2KB, 4KB), supporting page loading and flushing to disk, reducing write operations. Key entries are fixed-length or variable-length structures, supporting compact storage of variable-length keys.

[0053] KS Meta: Records information about the number of KS Pages in the Key Space; KSP Meta: Records internal information about each KS Page. 2. Value Space 1) VSH-Page-I (Meta) and VSH-Page-II (Meta): These two pages represent the metadata pages of the hash page set of the value space. They store information about the structure and management of the value space, record how many VSH-PAGEs there are, and manage the address mapping relationship of each VSH-PAGE on the disk.

[0054] 2) VSH-Page-0, VSH-Page-1, ..., VSH-Page-N: These are hash pages of the value space, used for fast lookup and storage of hash values ​​for value data. They are one of the actual control pages of the value space, typically the value space page table, which records the status information of all value pages (VSPs).

[0055] 3. Value Space Hash Page 1) Value Space Hash Page(0): a) VS-Page-I (Meta) and VS-Page-II (VSP Meta): These pages represent the metadata and management information of the hash page. They record the number of VS-Pages, the total number of Value entries in the current value space hash page, the valid and invalid data in each VS-Page, and the percentage of free space.

[0056] b) VS-Page-0, VS-Page-1, ..., VS-Page-N: These are the actual data pages of the hash page, storing the specific value data. They are the areas where the value body truly resides in the key-value separation architecture, and they correspond precisely to the key index in the key space through (VSHP Num, VSP Num, Offset).

[0057] 2) Value Space Hash Page(1) and Value Space Hash Page(2): The structure is the same as Value Space Hash Page(0), each containing a metadata page and multiple actual data pages.

[0058] 4. Data Flow Description 1) Data mapping from key space to hash pages in value space: From the actual data pages (KS-Page-0, KS-Page-1, ..., KS-Page-N) in the key space to the hash pages (VSH-Page-0, VSH-Page-1, ..., VSH-Page-N) in the value space. This path represents the specific location of the key in the key space mapped to the hash page in the value space; the key stored in the data page of the key space can be found in the corresponding value in the hash page of the value space.

[0059] 2) Relationship between value space hash pages and value pages: The path from the hash page (VSH-Page-0, VSH-Page-1, ..., VSH-Page-N) in the value space to the specific value data page (e.g., VS-Page-0, VS-Page-1, ..., VS-Page-N in Value Space Hash Page(0)) represents the mapping between the hash value in the value space hash page and the specific value data page. The specific value data page can be quickly located through the hash value in the hash page, thereby improving search efficiency.

[0060] V. Key-value unified storage Figure 6 This demonstrates the structure of a Key Space Page (KSP). In this design, each key-value pair is stored within a page in a fixed-length format. This structure simplifies storage management and lookup operations, improving access efficiency. The following is a detailed description of each field: 1.KSP (Key Space Page) Header: The page header contains metadata such as page number, page size, and usage information. The page header is used to manage and index key-value pairs within the page.

[0061] 2. Key-value pair storage structure: 1) Index: The index position of the key-value pair, used to quickly locate the key-value pair. The index is a relative position within the page, used to indicate the storage location of the specific key-value pair on the page.

[0062] 2) Valid: Valid flag, indicating whether the record is valid. If the record is deleted or not used, this flag will be set to invalid.

[0063] 3) KA (Key Area): This area stores the specific key portion. The key length is fixed, facilitating quick comparison and searching.

[0064] 4) VA (Value Area): This is the data value area, storing the actual value. The length of the value is also fixed, which simplifies storage and retrieval operations. 3. Fixed-length key-value pairs: Both keys and values ​​have fixed lengths. This design helps improve access efficiency because the position of each key-value pair can be calculated directly through the index, without having to deal with the complexity of variable lengths.

[0065] VI. Data Operation Process Figure 5 , Figure 8 , Figure 9 This demonstrates three data operations: data insertion, data update, and data deletion, using hash buckets and indexes to uniquely identify a key-value pair. A hash(key) can be mapped to a specific hash bucket, and then to a specific key space page (KSP). The technical process of each operation will be described in detail below.

[0066] 1. Data Insertion 1) Hash Map Keys key1, key2, and key3 are mapped to Bucket-0 using a hash function. The corresponding indices are 0, 1, and 2, respectively.

[0067] 2) Keyspace Page The mapping result inserts key1, key2, and key3 into page KSP-0, with corresponding index rows 0, 1, and 2 respectively. Each row includes an index, a validity flag, a key area, and a value area.

[0068] 3) Insertion complete At this point, page KSP-0 stores the key-value pairs key1, key2, and key3.

[0069] 2. Data Update 1) Hash Map The key 1 is mapped to index 0 of Bucket-0 through a hash function.

[0070] 2) Key space page update In page KSP-0, the data for key1 at index 0 is updated. The Valid flag is set to 0 to indicate that the old data is invalid. At the same time, a new key1 and its corresponding new value value11 are inserted at the new index 3, and the Valid flag is set to 1.

[0071] 3) Update complete At this point, the old data for key1 at index 0 in page KSP-0 becomes invalid, and the new data is stored at index 3.

[0072] 3. Data Deletion 1) Hash Map The key key11 is mapped to index 0 of Bucket-1 through a hash function.

[0073] 2) Deleting key space pages On page KSP-1, setting the Valid flag of the key11 data to 0 indicates that the data is invalid.

[0074] 3) Deletion complete At this point, the key11 data at index 0 in page KSP-1 is marked as invalid.

[0075] VII. Data Association between HMS and SMS Figure 10 This demonstrates the data association between HMS and SMS. The technical process of each operation will be described in detail below.

[0076] 1. Data mapping relationship Before the key-value data is stored in the Storage Management System (SMS), the BucketNum and Index of an item are empty. Whenever new data is inserted, the BucketNum and Index are calculated using a hash function and stored in the corresponding key-value store (KSP). Afterward, the BucketNum and Index in the item object are updated so that subsequent update and deletion operations on that item can be quickly retrieved without needing to perform a hash lookup using the key again.

[0077] For example, "key1" and "key2" are stored in Bucket 0, with index positions 0 and 1 respectively. The corresponding item will update its Bucket Num and Index after insertion.

[0078] 2. See Figure 7 The data insertion process is as follows: 1) Data generation The application layer generates the key-value data to be inserted, for example (key1, value1).

[0079] 2) Hash calculation Perform a hash calculation on the key (key1) to obtain the corresponding Bucket Num and Index. For example, suppose the result of hash(key1) maps to Bucket 0 and Index 0.

[0080] 3) Insert KSP Find an empty slot in KSP-0 where the valid bit is 0, insert key1 and value1 into it, and set the valid bit to 1. The corresponding updated KSP-0 is as follows.

[0081] 4) Update Item After successful insertion, update the Bucket Num and Index information to Item-1.

[0082] 3. Data update process 1) Find Item To update the key (key1) as needed, first find the corresponding position based on the Bucket Num and Index stored in the Item. Assuming the hash result of key1 still maps to Bucket 0 and Index 0, directly find Item-1.

[0083] 2) Update KSP Find a new empty slot in KSP-0, insert key1 and the new value into it, and set the valid bits to 1. At the same time, set the valid bits of the old index to 0.

[0084] 3) Update Item After a successful update, the new Bucket Num and Index information will be updated in Item-1.

[0085] 4. Data deletion process 1) Find Item For the key (key11) that needs to be deleted, find the corresponding position based on the Bucket Num and Index stored in the Item. Assuming that the hash result of key11 maps to Bucket 1 and Index 0, directly find Item-3.

[0086] 2) Update KSP Find the corresponding index position (Index 0) in KSP-1 and set the valid bits of key11 to 0.

[0087] 3) Update Item After deletion, set the Bucket Num and Index in Item-3 to empty. The information for Item-3 is as follows.

[0088] 8. Key-value separation storage Figure 11 This diagram illustrates key-value storage, a model that combines key-value storage with hash pages to achieve efficient data management and retrieval. The Key-Value Provider (KSP) records the key data, and the Value Provider (VSP) records the value data. Hash pages quickly locate the value data, improving storage and retrieval efficiency. The technical process of each operation will be described in detail below.

[0089] 1. KSP Key Entry Description 1) Index: The index position of the key-value pair in KSP.

[0090] 2) Valid: Validity flag, indicating whether the key-value pair is valid.

[0091] 3) KA (Key Address): Key address information.

[0092] 4) VSHP Num (Value Space Hash Page Number): Records the VSHP number of the value corresponding to this key.

[0093] 5) VSP Num (Value Space Page Number): Records the VSP number of the value corresponding to this key.

[0094] 6) Offset: Records the offset of the value corresponding to this key in the Value Space Page.

[0095] 2. VSP Value Item Description 1) Reference: Records reference information for value data.

[0096] 2) Length: The length of the recorded value data.

[0097] 3) VA (Value Address): Stores the value corresponding to each key as a cell. Each cell occupies 1 byte.

[0098] Figure 12 This is an example diagram of key-value separation storage, explained in detail below: 1. Example of KSP-1 key entry 1) Index 0: Valid: 1, indicating that the value is valid; Key: "key1"; VSHP Num: 1, locating to the VSHP-1 page; VSP Num: 2, locating to the VSP-2 page within the VSHP-1 page; Offset: 0, retrieving the value data "orchid" starting from offset 0 of VSP-2.

[0099] 2) Index 1: Valid: 1, indicating that the value is valid; Key: "key2"; VSHP Num: 1, locating to the VSHP-1 page; VSP Num: 2, locating to the VSP-2 page within the VSHP-1 page; Offset: 10, retrieving the value data "bluebell" starting from offset 10 in VSP-2.

[0100] 3) Index 2: Valid: 1, indicating that the value is valid; Key: "key3"; VSHP Num: 1, locating to the VSHP-1 page; VSP Num: 2, locating to the VSP-2 page within the VSHP-1 page; Offset: 22, retrieving the value data "chrysanthemum" starting from offset 22 in VSP-2.

[0101] 4) Index 3: Valid: 1, indicating that the value is valid; Key: "key4"; VSHP Num: 1, locating to the VSHP-1 page; VSP Num: 2, locating to the VSP-2 page within the VSHP-1 page; Offset: 39, retrieving the value data "primrose" starting from offset 39 of VSP-2.

[0102] 2. Example Explanation of VSP-2 Value Table Entries 1) "orchid": Starting from offset 0, it is "orchid", with a reference count of 1 and a length of 6.

[0103] 2) "bluebell": Starting from offset 10, it is "bluebell", with a reference count of 1 and a length of 8.

[0104] 3) "chrysanthemum": Starting from offset 22, it is "chrysanthemum", with a reference count of 1 and a length of 13.

[0105] 4) "primrose": Starting from offset 30, it is "primrose", with a reference count of 1 and a length of 8.

[0106] 3. Examples of key-value pair data changes Figure 13 This is a key-value shared data storage space. New shared value data storage spaces for Key5 and key3 have been added. Details are as follows: 1) Hash calculation and bucket mapping: key5 is hashed and mapped to the appropriate bucket. Assume that the item in the hash bucket is updated, containing the Bucket Num and Index information.

[0107] 2) Store key information in KSP: Hash bucket is mapped to KSP-1. Find an available index position in KSP-1. In this example, select Index = 4 according to the monotonically increasing index method, insert key5, and set VSHP Num, VSPNum and Offset to be the same as key3, i.e. 22.

[0108] 3) Shared storage value to VSP: Since key5 shares the value data of key3, no new storage is needed; only the reference count needs to be incremented by 1.

[0109] Figure 14 This is a key-value pair data refresh process, where the value of key1 is refreshed from "orchid" to "daisy". Details are as follows: 1) Find existing records: Use KSP-1 to find the current record of key1, find the record with Index 0, and mark it as invalid.

[0110] 2) Add new value data in VSP-1: Add "daisy" in VSP-2, assign Reference 4, Length 5, and Offset 51.

[0111] 3) Update KSP-1: Add a new record to KSP-1 with Index = 4, Valid = 1, KA = "key1", VSHP Num = 1, VSP Num = 2, Offset = 51. Set the Valid value of the existing key1 record at Index = 0 to 0.

[0112] 4) VSP-2 Update Reference Count: Decrease the reference count of the old value "orchid" to 0. Increase the reference count of the new value "daisy" to 1.

[0113] Figure 15 This describes the process of updating and deleting key-value data. Specifically, the value of key3 is updated from "chrysanthemum" to "carnation", and the data for key4 is deleted. The data deletion process is explained in detail below: 1) Find existing records: Use KSP-1 to find the current record of key4, find the Index is 3, VSHPNum is 1, VSP Num is 2, and Offset is 39.

[0114] 2) Update KSP-1: The record for key4 is located at index 3, and the valid flag is 0.

[0115] 3) VSP-2 Update Reference Count: Reduce the reference count of "primrose" to 0.

[0116] IX. Data Read Operation Procedure 1. Normal data read operation The following describes the specific operation process for reading key-value pair data. Figure 14 For example, to read the value data of key3: 1) Determine the key space page table: key3 determines the key space page table KSP-1 through hash calculation.

[0117] 2) Keyspace page table lookup key: Search for all records of key3 in KSP-1. The records of key3 are as follows: Index: 2, Valid: 0, KA: "key3", VSHP Num: 1, VSP Num: 2, Offset: 22 Index: 6, Valid: 1, KA: "key3", VSHP Num: 1, VSP Num: 2, Offset: 60 3) Verify the validity of the key: Checking the Valid field of the first found record (index 2), we find that its value is 0, indicating that the key is invalid.

[0118] Check the Valid field of the second found record (index 6) and confirm that its value is 1, indicating that the key is valid. 4) Obtain VSP information: The VSHP Num and VSP Num of the valid record determine which VSP the value data is stored in. According to the information in the table above, the valid value data for key3 is stored in VSP-2, with an offset of 60.

[0119] 5) Read value data from VSP: In VSP-2, value data is read starting from offset 60. According to the table above, the value data corresponding to offset 60 is "carnation".

[0120] 6) Return value data: Returns "carnation".

[0121] 2. Fast data read operation Improve data retrieval performance through caching mechanisms, such as... Figure 16 : 1) Utilize caching technology to cache frequently accessed key-value pairs in memory, reducing the number of disk accesses; 2) Use the LRU (Least Recently Used) algorithm to manage the cache, ensuring that the most frequently used data is retained in the cache; 3) When reading a key-value pair, adjacent key-value pairs can be prefetched into the cache to improve the speed of subsequent accesses.

[0122] In the system, we maintain a key area cache, where each record contains a key (KA), a key space page number (KSP Num), an index, and a value.

[0123] First, check if the target key exists in the key area cache. For example, when searching for key3, if a record exists in the cache, return "carnation". If the cache is not found, refer to the normal data read operation procedure.

[0124] 10. Key space page optimization When key space pages (KSPs) change continuously, resulting in a large number of key values ​​being in an invalid state, it will affect the overall storage efficiency and performance. To address this, a dynamic migration strategy is adopted. When the invalid data on a page reaches a certain proportion, the remaining valid data is automatically migrated to other pages, and the current page is released.

[0125] 1. Dynamic migration like Figure 17 The diagram illustrates the dynamic migration process of key space pages (KSPs) from KS-Page-5 to KS-Page-8. The primary goal of this process is to improve the utilization of key space pages by migrating valid data and releasing invalid data. The specific process is as follows: 1) Initial state: KS-Page-5 contains some invalid and valid key-value pairs. KS-Page-8 is a new page used to receive valid data from the migration.

[0126] 2) Original key space page scan: Traverse all entries in KS-Page-5 and find valid entries (Valid = 1): Index = 54, 55, 56, 59.

[0127] 3) New keyspace page migration: KS-Page-5

[54] migrates to KS-Page-8

[80] ; KS-Page-5

[55] migrates to KS-Page-8

[81] ; KS-Page-5

[56] migrates to KS-Page-8

[82] ; KS-Page-5

[59] migrates to KS-Page-8

[83] . Update the entries in KS-Page-8 to reflect the new data.

[0128] 4) Release the original key space page: Delete invalid data in KS-Page-5, clear KS-Page-5, and release the page.

[0129] 2. Data source item refresh For example, data with Index = 54 in KS-Page-5 is migrated to Index = 80 in KS-Page-8. 1) Original state of the data source item: In KS-Page-5, the item may look like this: Item key1 = { "key3", 5, 54}; / / key1 points to index 54 of KS-Page-5 2) New status of data source item: After migration, the item needs to be updated to: Item key1 = { "key3", 8, 80}; / / Update key1 to point to index 80 of KS-Page-8 3. Key Area Cache Refresh like Figure 18 The diagram illustrates the Key Area Cache state refresh process after the dynamic migration of the Key Space Page (KSP) from KS-Page-5 to KS-Page-8.

[0130] 1) Update cache: During the migration process, when valid data is copied to the new key space page, the KSP Num and index values ​​in the Key Area Cache need to be updated simultaneously to point to the new location; 2) Delete old cache: Delete or mark old cache items as invalid to avoid using old cache data; XI. Value Space Page Optimization Similar to the key space, when the value space page (VSP-2) experiences frequent data writes, leading to fragmentation or reduced space utilization, the system performs a value space migration operation to move active data to a new value space page (VSP-3) in order to improve read / write efficiency and compress the data storage structure.

[0131] 1. Dynamic migration like Figure 19 The diagram illustrates the dynamic migration process from value space pages VSP-2 to VSP-3. The primary goal of this process is to improve the utilization of value space pages by migrating valid data and releasing invalid data. The specific process is as follows: 1) Identify the data that needs to be migrated: The system scans all records in VSP-2 and determines which records are still referenced based on strategies such as reference counting and validity flags (e.g., "bluebell", "chrysanthemum", "daisy", "carnation").

[0132] 2) Copy data to a new page (VSP-3): Copy the still valid data one by one to the new value space page VSP-3. Place them sequentially and maintain the new offsets, for example: "bluebell" is copied to offset = 0, "chrysanthemum" to offset = 12, "daisy" to offset = 29, and "carnation" to offset = 38. 3) Update value references in KSP: Update the record in KSP-1 that originally pointed to VSP-2 to point to the new VSP-3 page.

[0133] 2. Precautions Figure 19 This description only addresses the mapping from a single key space to a value space. In reality, multiple key spaces may map to a single value space. Value space migration may involve refreshing references across multiple key spaces (KSPs) because the same value space page (VSP) may be shared by multiple keys distributed across different key space pages. To ensure consistency and correctness of references after migration, the system needs to scan all data items referencing the value and uniformly update their VSP page numbers and offsets within their respective KSPs, thus achieving global synchronization. This process is a crucial step in ensuring data correctness in a key-value separation architecture.

[0134] The following is an example of a real-world business scenario (linked processing of various services in response to Ethernet interface status changes). 1. Background Introduction In a router device, when the state of an Ethernet interface (such as eth0) changes (e.g., from UP to DOWN), the system needs to automatically trigger a series of service module responses, including interface state table updates, routing table cancellations, recalculation of dynamic routing protocols such as OSPF, and SNMP alarm reporting.

[0135] 2. Component Function and Status Table The following is a summary of the functions of each component and the business status data table information for writing and subscribing, based on this business scenario.

[0136]

[0137] 3. Business Logic Flow 1) Interface Management Component: Interface status changes are written to the interface status table.

[0138] The interface monitoring module detected a disconnection on eth0 and wrote the following status data (JSON format as value space data): { "ifName": "eth0", "adminState": "up", "linkState": "down", "timestamp": "2025-06-20 10:00:01" } 2) Data status management component: Status change notification triggers dependent components to read.

[0139] When the state management component detects a change in the interface state table, it triggers various business components that have subscribed to that state table: a) Routing Management Component: Reads the interface status table and finds that the "linkState" field has changed to "down". Locates all route entries bound to eth0 and writes them to the "Route Status Table", marking the routes as invalid.

[0140] b) Routing protocol component: Reads the interface state table and finds that the "linkState" field has changed to "down". It finds all associated neighbors bound to eth0 and writes them to the "Neighbor State Table", marking the neighbor relationship as "down". It triggers route recalculation, and the calculation result is written to the "OSPF Protocol Routing State Table". An example of the neighbor state table update is shown below: { "protocol": "OSPF", "neighbor": "192.168.1.1", "interface": "eth0", "adjacencyState": "down" } The route associated with eth0 is marked as invalid; a new valid route is written.

[0141] c) Alarm Module Component: Reads the interface status table and detects that the "linkState" field has changed to "down". The alarm module generates an "Interface down" event and writes it to the "Alarm Event Table". Example data is shown below: { "alarmType": "InterfaceDown", "interface": "eth0", "severity": "critical", "timestamp": "2025-06-20 10:00:01" } The OSPF neighbor status table is read, and the neighbor status adjacency relationship changes from FULL to DOWN. The alarm module generates a "neighbor down" event and writes it to the "alarm event table." Example data is shown below: { "protocol": "OSPF", "localIfName": "eth0", "neighborAddr": "192.168.1.2", "neighborId": "1.1.1.1", "oldState": "Full", "newState": "Down", "eventReason": "LinkDown", "timestamp": "2025-06-20 10:00:01" } d) SNMP component: Reads the contents of the alarm event table, detects interface down events and neighbor disconnection events, generates standard Trap messages and reports them to the network management system.

[0142] Interface down event trap format: Trap Type: linkDown (1.3.6.1.6.3.1.1.5.3) ifIndex: 3 ifDescr: eth0 ifOperStatus: down (2) Timestamp: 2025-06-20 10:00:01 Neighbor disconnection event trap format: Trap Type: ospfNbrStateChange (1.3.6.1.2.1.14.16.2) ospfNbrIpAddr: 192.168.1.2 ospfNbrRtrId: 1.1.1.1 oldState: Full newState: Down localIf: eth0 Timestamp: 2025-06-20 10:00:01 This disclosure also provides an electronic device, including: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, causing the processor to perform any of the methods described above.

[0143] The hardware architecture of electronic devices / devices can be implemented using a bus architecture. A bus architecture can include any number of interconnect buses and bridges, depending on the specific application and overall design constraints of the hardware. A bus connects various circuits, including one or more processors, memories, and / or hardware modules. A bus can also connect various other circuits such as peripherals, voltage regulators, power management circuits, external antennas, etc. Buses can be Industry Standard Architecture (ISA) buses, Peripheral Component Interconnect (PCI) buses, or Extended Industry Standard Component (EISA) buses, etc. Buses can be categorized as address buses, data buses, control buses, etc.

[0144] For ease of explanation, certain steps of the above method are described in relation to modules. It should be understood that the corresponding module performing one or more steps of the above method may be one or more hardware modules specifically configured to perform the corresponding step, or implemented by a processor configured to perform the corresponding step, or stored in a computer-readable medium for implementation by a processor, or implemented by some combination thereof.

[0145] The specific implementation of each module in the above-mentioned device can be referred to the implementation process of the corresponding steps in the above-mentioned method implementation method of this disclosure, and will not be repeated here.

[0146] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0147] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.

[0148] Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A storage method that separates data relationships from state, characterized in that, The method includes the following steps: Perform a hash calculation on the input target key to determine the bucket number and index position of the target key in the key status page; Write the key information of the target key into the corresponding index position in the key status page, and write the value data associated with the target key into the specified storage area in the value status page; In the key status page, a pointer to the specified storage area is recorded at the corresponding index position, and a valid flag is set to valid.

2. The storage method according to claim 1, characterized in that, The method further includes: When a query request is received, the corresponding index position in the key status page is accessed through hash calculation based on the target key in the query request. Determine whether the valid flag at the index position is valid. If valid, read the corresponding value data from the value status page according to the pointer and return it.

3. The storage method according to claim 1, characterized in that, The method further includes: When an update request is received, the new value data is written to the new storage area of ​​the value status page, and the pointer of the corresponding index position of the key status page is updated to point to the new storage area, while keeping the valid flag as valid; When a deletion request is received, only the valid flag at the index position corresponding to the key status page is modified to invalid.

4. The storage method according to claim 1, characterized in that, The method further includes performing the following steps before writing the value data associated with the target key into a designated storage area in the value status page: Perform business logic processing on the input data; Generate status data that includes a set of device status identifiers, service statuses, and object statuses; The status data is used as value data associated with the target key and written to the value status page; Send a write complete event to trigger the data change notification process.

5. The method according to claim 4, characterized in that, The method further includes, after sending the write completion event to trigger the data change notification process, performing the following steps: Receive the write complete event; Based on the status table identifier carried in the write completion event, query the subscription relationship table; Identify one or more target service providers that have subscribed to this status table; A notification message is sent to each target service provider. The notification message includes a status table identifier and a change key identifier.

6. The method according to claim 1, characterized in that, The method further includes performing the following steps before writing the value data associated with the target key into a designated storage area in the value status page: Load the business data format file from the storage medium before writing; Parse the business data format file to obtain the field names, data types, field lengths, and index configurations of the target status table; Based on the field configuration, the status data to be written is organized into structured records; The structured record is serialized into binary format; The binary format data is written as the content of the value status page.

7. The method according to claim 1, characterized in that, The method further includes performing the following steps before hashing the input target key to determine its bucket number and index position in the key state page: Read the business data format file when the system starts up; Create a corresponding memory status table structure for each business module; Read historical data records from each state table from persistent storage; Load the historical data records into the corresponding memory status table; Rebuild the hash index for each state table based on the key identifier.

8. The method according to claim 3, characterized in that, The step of writing the new value data to a new storage area of ​​the value status page and updating the pointer of the corresponding index position of the key status page to point to the new storage area when an update request is received includes: Call the write interface and pass in the status table identifier, key identifier, and status data; Receive write requests; Allocate a new storage location in the value status page; Write the status data to the storage location; Update the valid flag of the corresponding key identifier to valid in the key status page, and record the pointer to the storage location.

9. The method according to claim 2, characterized in that, When a query request is received, accessing the corresponding index position in the key status page through hash calculation based on the target key in the query request includes: Call the read interface and pass in the status table identifier and key identifier; Receive read request; Locate the entry corresponding to the key identifier in the key status page; Determine whether the valid flag in the table entry is valid; If the validity flag is valid, the corresponding status data is read from the value status page according to the pointer in the table entry; Return the status data.

10. The method according to claim 4, characterized in that, The method further includes performing the following steps before writing the state data as value data associated with the target key into the value state page: The business data status table only stores device status identifiers, service status, and object status sets; The call dependencies between storage services are not present in the status table; The relationships between objects are not stored in the status table; The call dependencies and associations are dynamically derived based on the currently read state data; Subsequent business processing is performed based on the derived relationships.

11. A data response processing method, characterized in that, Includes the following steps: Receive a notification message sent by the storage side. The notification message includes a status table identifier and a change key identifier. The status table identifier corresponds to a business data status table that adopts a storage architecture that separates key data and value status. Parse the notification message and extract the status table identifier and change key identifier; Call the unified read interface on the storage side and pass in the status table identifier and change key identifier; Receive the updated status data returned by the unified read interface; Based on the updated status data, execute local business rule judgment and processing logic.

12. The data response processing method according to claim 11, characterized in that, After the local business rule judgment and processing logic is executed based on the updated status data, the following steps are performed: New status data is generated based on the results of local business processing. The new status data is written into another business data status table that uses a storage architecture that separates key metadata from value status. Send a new write complete event; In response to the new write completion event, the next level of data reading and processing is triggered.

13. An electronic device, characterized in that, include: The memory stores execution instructions; as well as A processor that executes execution instructions stored in the memory, causing the processor to perform the method of any one of claims 1 to 12.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 12.

Images