Storage and calculation separated data read-write method and device, equipment and medium

Abstract

The invention discloses a storage and calculation separated data read-write method, device and equipment and a medium, and relates to the field of data storage, and the method comprises the steps that a business process in a calculation node sends a metadata read-write request for a business instance to a local service component through a local client; the metadata read-write request is sent to a key value storage service corresponding to the business instance through a service component, so that the key value storage service executes read-write operation on at least one hard disk in a distributed storage pool by responding to the metadata read-write request, and a metadata read-write result is returned to the client; different key value storage services in the service component are deployed based on different business instances in corresponding business processes; the distributed storage pool is located in a storage node that is independent of the compute node. By independently deploying the storage nodes and the computing nodes, the key value storage service in the computing nodes and the storage nodes are decoupled, so that the key value storage service can be independently deployed and flexibly deployed based on the business instances.

Description

Technical Field

[0001] This invention relates to the field of data storage, and in particular to a data reading and writing method, apparatus, device, and medium that separates storage and computation. Background Technology

[0002] Traditional distributed key-value stores (DKVS) employ a storage-compute coupled architecture, which couples storage nodes and compute nodes together. This means that key-value storage services on compute nodes can only be deployed in a fixed manner according to a pre-planned schedule. Because storage nodes and compute nodes are coupled, any change in one node affects the entire system. As a result, traditional distributed key-value stores cannot deploy key-value storage services independently, or the deployment cost is too high. Furthermore, fixed-deployment key-value storage services are difficult to adapt to complex and ever-changing business needs, leading to a decline in storage performance. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide a data read / write method, apparatus, device, and medium for storage-compute separation. By independently deploying storage nodes and compute nodes, the key-value storage service in the compute node is decoupled from the storage node, enabling the key-value storage service to be deployed independently and flexibly based on business instances. The specific solution is as follows:

[0004] Firstly, this application provides a data read / write method for storage-compute separation, applied to a target business process in a target computing node, including:

[0005] The local client sends metadata read / write requests for the target business instance to the local first service component.

[0006] The first service component sends the metadata read / write request to the target key-value storage service corresponding to the target business instance, so that the target key-value storage service can respond to the metadata read / write request, perform corresponding read / write operations on at least one hard disk, and return the metadata read / write result to the client.

[0007] Among them, the different key-value storage services in the service components are storage services deployed based on different business instances in the corresponding business processes; the at least one hard disk is located in the distributed storage pool of the storage node, and the storage node is independent of the computing node.

[0008] Optionally, the step of sending metadata read / write requests for the target business instance to the local first service component via a local client includes:

[0009] The local client calls a preset access interface to access the first local service component, so as to send the metadata read / write request for the target business instance to the first service component.

[0010] Optionally, sending the metadata read / write request to the target key-value storage service corresponding to the target business instance through the first service component includes:

[0011] The first service component determines the target key-value storage service corresponding to the target business instance based on the metadata read / write request;

[0012] If the target key-value storage service is located in the target business process, the metadata read / write request is sent to the target key-value storage service through the first service component based on local transmission.

[0013] If the target key-value storage service is located in another business process, the first service component sends the metadata read / write request to the second service component in the other business process via network transmission, so that the second service component sends the metadata read / write request to the target key-value storage service.

[0014] The other business processes include business processes in the target computing node other than the target business process, as well as business processes in other computing nodes.

[0015] Optionally, the target key-value storage service generates a hard disk read / write command in response to the metadata read / write request, and calls the local target key-value storage engine to send the hard disk read / write command to the target file system based on the target call interface, so that the target file system can directly access the at least one hard disk based on the first communication interface and perform read / write operations corresponding to the hard disk read / write command on the at least one hard disk, so as to return the metadata read / write result to the client;

[0016] The target file system is the file system corresponding to the target key-value storage service, and both the target file system and the first communication interface are located in the business process where the target key-value storage service is located.

[0017] Optionally, the metadata read / write request includes a metadata write request; correspondingly, the process of generating the hard disk read / write command includes:

[0018] The target key-value storage service writes the metadata to be written in the metadata write request to the target key-value storage engine in the form of key-value pairs, and generates the hard disk read / write command based on the metadata to be written by the target key-value storage engine;

[0019] Accordingly, the read / write operation includes writing the metadata to be written to a write-ahead log file on the at least one hard disk.

[0020] Optionally, the metadata read / write request includes a metadata read request; correspondingly, the process of generating the hard disk read / write command includes:

[0021] The target key-value storage service reads the corresponding metadata from the local cache based on the target key in the metadata read request through the target key-value storage engine. If the metadata is not found, a disk read / write command for reading the target file is generated. The target file is a file that stores ordered key-value pairs.

[0022] Accordingly, the read / write operation includes reading the target file from the at least one hard disk into the target key-value storage engine, so that the target key-value storage engine reads the corresponding metadata from the target file based on the target key.

[0023] Optionally, before directly accessing the at least one hard disk, the target file system verifies whether the first version number and the second version number carried by the hard disk read / write command are consistent. If they are inconsistent, the hard disk read / write command is rejected; if they are consistent, the at least one hard disk is accessed directly.

[0024] Wherein, the first version number is the version number recorded when the target file system last acquired the distributed lock; the second version number is the current version number of the distributed lock.

[0025] Optionally, the method further includes:

[0026] When the target key-value storage service is located in the other business process and a failure occurs, the target service identifier of the target key-value storage service is obtained through the first service component, and it is determined whether there is a created key-value storage service corresponding to the target service identifier locally;

[0027] If it exists, a preset lock acquisition operation is performed through the file system corresponding to the created key-value storage service, and a preset data reading operation is performed through the key-value storage engine in the created key-value storage service, so as to use the created key-value storage service to take over the work of the target key-value storage service.

[0028] If it does not exist, a preset service creation operation is performed through the first service component to replace the work of the target key-value storage service with the newly created key-value storage service; the preset service creation operation includes the preset lock acquisition operation and the preset data reading operation; the service identifier of the new key-value storage service is the same as the target service identifier.

[0029] Optionally, the execution of the preset service creation operation includes:

[0030] Create a new API call interface, and create a new file system through the new API call interface;

[0031] The new file system is mounted to the distributed storage pool via the second communication interface;

[0032] The new calling interface is mounted to the new file system, and the preset lock acquisition operation is performed through the new file system;

[0033] Create a new key-value storage engine and use the new API call as the interface for the new key-value storage engine to access the new file system;

[0034] The new key-value storage service is created based on the new key-value storage engine and the new calling interface, and the preset data reading operation is executed through the new key-value storage engine.

[0035] Optionally, the preset lock acquisition operation includes applying to acquire the distributed lock, and after the lease of the distributed lock in the target file system expires, acquiring the distributed lock and recording the incremented version number of the distributed lock; the incremented version number is the version number obtained by performing a preset increment operation on the current version number of the distributed lock;

[0036] The preset data read operation includes reading a copy of the target key-value storage service data from the at least one hard disk.

[0037] Optionally, the method further includes:

[0038] When the first service component receives a destruction instruction for the new key-value storage service, it sends the destruction instruction to the new key-value storage service through the first service component.

[0039] The new key-value storage service responds to the destruction command by calling the new call interface to unload the new file system after releasing the distributed lock, and closes the new call interface after unloading is complete;

[0040] After the new calling interface is successfully closed, the new key-value storage engine is destroyed through the new key-value storage service, and the destruction of the new key-value storage service is completed after the new key-value storage engine is successfully destroyed.

[0041] Optionally, the destruction instruction is an instruction generated when the failure duration of the new key-value storage service exceeds a first preset time, or an instruction generated when the new key-value storage service fails to acquire the distributed lock for a duration exceeding a second preset time after the failure is recovered.

[0042] Secondly, this application provides a storage-compute separation data read / write device, applied to a target business process in a target computing node, comprising:

[0043] The first sending module is used to send metadata read / write requests for the target business instance to the first local service component via a local client.

[0044] The second sending module is used to send the metadata read / write request to the target key-value storage service corresponding to the target business instance through the first service component, so that the target key-value storage service can perform corresponding read / write operations on at least one hard disk in response to the metadata read / write request and return the metadata read / write result to the client.

[0045] Among them, the different key-value storage services in the service components are storage services deployed based on different business instances in the corresponding business processes; the at least one hard disk is located in the distributed storage pool of the storage node, and the storage node is independent of the computing node.

[0046] Thirdly, this application provides an electronic device, comprising:

[0047] Memory, used to store computer programs;

[0048] A processor is used to execute the computer program to implement the aforementioned data read / write method that separates storage and computation.

[0049] Fourthly, this application provides a computer-readable storage medium for storing a computer program, which, when executed by a processor, implements the aforementioned data read / write method that separates storage and computation.

[0050] In this application, the target business process in the target computing node sends a metadata read / write request for the target business instance to a local first service component via a local client; the first service component then sends the metadata read / write request to a target key-value storage service corresponding to the target business instance, so that the target key-value storage service can respond to the metadata read / write request to perform corresponding read / write operations on at least one hard disk and return the metadata read / write result to the client; wherein, the different key-value storage services in the service component are storage services deployed based on different business instances in the corresponding business process; the at least one hard disk is located in a distributed storage pool of the storage node, and the storage node is independent of the computing node. Therefore, this application decouples the key-value storage service in the computing node from the storage node by independently deploying storage nodes and computing nodes. This allows the key-value storage service to be deployed independently in the computing node at a low deployment cost. Furthermore, since the key-value storage service in this application is deployed based on different business instances in the corresponding business process, different business instances in this application correspond to different key-value storage services. That is, this application supports flexible deployment of key-value storage services according to business instances, which can not only improve business concurrency capabilities but also adapt to complex and ever-changing business needs, thereby improving storage performance. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0052] Figure 1 A flowchart of a data read / write method with storage-compute separation provided in this application;

[0053] Figure 2 An overall architecture diagram of a key-value storage system with storage and computation separation provided for this application;

[0054] Figure 3 A flowchart for writing metadata is provided for this application;

[0055] Figure 4 A flowchart for reading metadata is provided for this application;

[0056] Figure 5 A flowchart for creating a key-value storage service provided in this application;

[0057] Figure 6 A flowchart for the destruction of a key-value storage service provided in this application;

[0058] Figure 7 A schematic diagram of a data read / write device with storage and computing separation provided in this application;

[0059] Figure 8 This application provides a structural diagram of an electronic device. Detailed Implementation

[0060] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0061] Traditional distributed key-value storage systems employ a storage-compute coupled architecture, meaning that key-value storage services on compute nodes can only be deployed in a fixed manner according to pre-planned strategies. Independent deployment of key-value storage services is either impossible or prohibitively expensive. Furthermore, fixed deployments of key-value storage services struggle to adapt to complex and ever-changing business needs, leading to performance degradation. To address this, this application provides a storage-compute separation data read / write method. By independently deploying storage and compute nodes, the key-value storage service on the compute nodes is decoupled from the storage nodes. This allows for independent deployment of key-value storage services based on flexible business instances, resulting in lower deployment costs and adaptability to complex and ever-changing business needs, thereby improving storage performance.

[0062] See Figure 1 As shown, this embodiment of the invention discloses a data read / write method with storage-compute separation, applied to a target business process in a target computing node, including:

[0063] Step S11: Send the metadata read / write request for the target business instance to the local first service component through the local client.

[0064] Step S12: The first service component sends the metadata read / write request to the target key-value storage service corresponding to the target business instance, so that the target key-value storage service can respond to the metadata read / write request to perform corresponding read / write operations on at least one hard disk and return the metadata read / write results to the client; wherein, the different key-value storage services in the service component are storage services deployed based on different business instances in the corresponding business process; the at least one hard disk is located in the distributed storage pool of the storage node, and the storage node is independent of the computing node.

[0065] Before describing the methods disclosed in the embodiments of the present invention, a brief description of the overall architecture of the Disaggregated Key-Value Store (DKVS) involved in the embodiments of the present invention will be given first, as follows: Figure 2 As shown, a compute-storage separation key-value storage system includes independently deployed compute nodes and storage nodes. There are at least two compute nodes and only one storage node. Different compute nodes interact remotely via network transmission, and each compute node directly accesses the storage node through a local communication interface. Furthermore, each compute node includes at least one business process (…). Figure 2 A dashed box in the diagram represents a business process. Different business processes interact via network transmission. Each business process includes three abstract layers: a business call layer, a key-value storage layer, and a file system layer. The business call layer contains several business instances. The key-value storage layer includes client and service components. The service component deploys key-value storage services corresponding to the business instances in the corresponding business process. The key-value storage service includes a key-value storage engine and a calling interface. The file system layer includes a file system component, a distributed lock component, and a communication component. The file system component deploys a file system (FS) corresponding to the key-value storage services in the corresponding business process. The distributed lock component includes several distributed locks. The communication component includes a communication interface for directly accessing storage nodes. The storage node includes a distributed storage pool, and the distributed storage pool is deployed with several hard disks, including but not limited to solid-state drives (SSDs), hard disk drives (HDDs), and virtual hard disks. Among them, the solid-state drives can adopt the NVMe (Non-Volatile Memory Host Controller Interface Specification) protocol; and the hard disks in the distributed storage pool can be multi-port disks, allowing multiple computing nodes to access them simultaneously.

[0066] It should be noted that different key-value storage systems with separate storage and computing require a switch for remote interaction.

[0067] The computing node is a device that includes a processor, accelerator, memory, etc., such as a server. The processor can be a single-core processor or a multi-core processor.

[0068] Network transmission methods include, but are not limited to, RPC (Remote Procedure Call) and RDMA (Remote Direct Memory Access).

[0069] When the hard drives in the distributed storage pool are solid-state drives (SSDs) using the NVMe protocol, the communication interface can be an interface using the NoF (NVMe Over Fabric, an extended protocol for NVMe). This allows NVMe devices (such as the compute nodes in this application) to communicate remotely via a network fabric (such as Ethernet, InfiniBand, FC (Fibre Channel), etc.), extending the high performance of NVMe from "local" to a "distributed environment" and enabling direct access to NVMe SSDs. The core of NoF passthrough to NVMe SSDs is "native NVMe semantic access to remote devices," meaning the host / VM (Virtual Machine) considers the remote NVMe SSD as a "local PCIe (Peripheral Component Interconnect Express, a high-speed serial computer extension bus standard) device," thus sending NVMe commands directly to the NVMe SSD without needing to adapt to other network protocols, i.e., without further network protocol conversion. Without NoF, NVMe commands would need to be converted through other network protocols before being sent to the NVMe SSD, adding an extra network overhead. Based on this, this application can reduce one network overhead by using NoF pass-through SSD and can alleviate the remote compaction problem caused by storage-compute separation.

[0070] Correspondingly, when the hard drives in the distributed storage pool are mechanical hard drives or other hard drives (not solid-state drives), the communication interface can adopt other protocols that allow direct access to the hard drives, thereby enabling direct access to the hard drives through the communication interface using direct access technology.

[0071] The business instances in the business call layer mainly fall into two categories: one is metadata business in the file storage and block storage process, such as MDS (Metadata Server) metadata business, where MDS metadata mainly includes inodes and dentry; the other is metadata business in the data IO (Input / Output) process, such as metadata business in the logcache / AppendOnly process.

[0072] The client in the key-value store layer acts as an interface abstraction layer, providing CRUD (Create, Read, Update, Delete) interfaces and transaction interfaces for specific business operations. Furthermore, all business instances in the business call layer need to initialize the client in the key-value store layer and access the service components in the key-value store layer through the CRUD interfaces and transaction interfaces provided by the client. The business call layer synchronously calls the interfaces provided by the client without the need for thread switching.

[0073] The service components in the key-value store layer are core business components. Clients in the key-value store layer can directly call APIs (Application Programming Interfaces) to access service components in the same business process.

[0074] The key-value storage service in the service component is equivalent to a compute instance, which can be initialized on demand based on the business instance in the business call layer. Furthermore, the key-value storage service provides an abstract interface to support integration with different single-machine database engines; that is, each key-value storage service can integrate with a key-value storage engine, such as RocksDB (an embedded, high-performance key-value storage engine). Secondly, the key-value storage service also includes a call interface to serve as the interface for the key-value storage engine to access the corresponding file system, providing file / directory I / O operations.

[0075] It should be noted that business instances in the business call layer can be deployed 1:1 with key-value storage services in the service component, or 1:N with key-value storage services in the service component. When deploying business instances with key-value storage services in a 1:N manner, an additional service abstraction layer needs to be designed in the service component for each business instance. This service abstraction layer contains N key-value storage services corresponding to the business instance. This service abstraction layer is then provided to the business instances for use. In this case, different business instances within the same business process correspond to different service abstraction layers. When a business instance performs data read / write operations through the corresponding service abstraction layer, for write operations, hash sharding and load balancing can be performed, but transactional consistency must be supported among the N key-value storage services. For read operations, a lookup can be performed in a specified key-value storage service based on a prefix, and the read results from the N key-value storage services can be aggregated. The aggregated result is then uniformly returned to the business instance. The prefix is ​​used to determine which key-value storage service in the service abstraction layer performs the read operation.

[0076] The file system layer belongs to the file system encapsulation interface class. The file system supports the invocation of interfaces used in key-value storage services and provides interfaces such as `mkfs` (initialization interface), `mount` (mounting interface), `umount` (unmounting interface), `create` (creating interface), `open` (file opening interface), `write` (writing interface), `read` (reading interface), and `close` (file closing interface). Furthermore, the file system can convert raw files with the suffixes `.sst` (Sorted String Table, used to store ordered key-value pairs) and `.log` (files used to store logs) into `plog` (Persistent Log) files and store them in a distributed storage pool. It should be noted that each `plog` file is configured with a corresponding file identifier. By establishing a mapping relationship between the filename of the raw file and the file identifier of the `plog` file, the target file identifier corresponding to the target filename can be found based on the mapping relationship, thereby retrieving the `plog` file corresponding to the target file identifier from the distributed storage pool.

[0077] It should also be noted that different file systems correspond to different key-value storage services, and different key-value storage services correspond to different business instances. Therefore, there is a certain correspondence between business instances, key-value storage services, and file systems. Furthermore, the system identifier of the file system is the same as the service identifier of the key-value storage service.

[0078] For the Distributed Lock component, the key-value storage service corresponding to the business instance needs to obtain the distributed lock from the distributed lock component through the file system before performing data I / O on the hard disk through the corresponding file system. Only after obtaining the distributed lock will the file system perform data I / O on the key-value storage service; otherwise, it will refuse the data I / O on the key-value storage service. Furthermore, for a faulty key-value storage service in a certain business process, this application will launch a new key-value storage service in another business process to take over the work of the faulty key-value storage service (e.g., adding 100 to data A). At this time, the faulty key-value storage service and the new key-value storage service correspond to the same distributed lock. Since the same distributed lock can only be acquired by one key-value storage service at a time, the faulty key-value storage service will lose the distributed lock, while the new key-value storage service will acquire the distributed lock. Even if the faulty key-value storage service recovers, it cannot acquire the distributed lock within the lease period of the new key-value storage service. This prevents the faulty key-value storage service from continuing to execute the operation of adding 100 to data A after recovery, so that both the new key-value storage service and the faulty key-value storage service add 100 to data A, and finally add 200 to data A, which is inconsistent with the initial requirement of adding 100 to data A. Therefore, this application can guarantee the eventual consistency of data reading and writing through distributed locks.

[0079] Distributed locks can be implemented in various ways, including but not limited to database-based distributed locks, cache-based distributed locks (such as Redis), and Zookeeper (a reliable coordination service for distributed systems).

[0080] In addition, when the file system does not support direct access to the hard drive through the communication interface, it can also send access commands to the access service in the distributed storage pool through the communication component via network transmission, so as to access the hard drive through the access service in the distributed storage pool.

[0081] Furthermore, the distributed storage pool in this embodiment of the invention is implemented based on the CRUSH (Controlled Replication Under Scalable Hashing, a consistency protocol) protocol for persistent storage of data and metadata, and supports byte-level read and write operations. Compared to key-value storage systems that are coupled with computing, this application offloads the consistency protocol and disk management functions on the computing node side to the storage node, reducing the resource consumption of the computing node. The file system adopts a flat directory structure to store its own metadata in the distributed storage pool, thereby relying on the metadata read and write provided by the distributed storage pool for continuous updates, startup, and recovery of the file system metadata. The distributed storage pool includes two replica pools: a data replica pool and a metadata replica pool. Each replica pool includes several disks. Although this application mainly focuses on metadata read and write operations, data read and write operations can also be referenced from this application and will not be elaborated here.

[0082] It should be noted that key-value storage services, by performing read and write operations on at least one hard drive in the distributed storage pool, can achieve simultaneous read and write operations across multiple replica pools by accessing at least one hard drive simultaneously. This means a single key-value storage service can perform read and write operations on multiple replicas concurrently, thus enabling a deployment architecture where one key-value storage service corresponds to multiple replica pools. These replica pools can reside on different hard drives or on different partitions of the hard drives; this is not a limitation. Compared to storage-compute coupled key-value storage systems, where one key-value storage service can only deploy one replica pool, requiring multiple key-value storage services to be deployed when multiple replica pools are needed, this application, through a deployment architecture where one key-value storage service corresponds to multiple replica pools, reduces the number of key-value storage services from multiple to one when multiple replica pools are required. This not only reduces deployment costs but also reduces the overhead of key-value storage service compression and merging, ensuring storage performance.

[0083] In such Figure 2Based on the overall architecture of the storage-compute separation key-value storage system shown, this application takes any business process (denoted as the target business process) in any computing node (denoted as the target computing node) in the storage-compute separation key-value storage system as an example to explain in detail how to perform read and write operations on the hard disk based on the key-value storage service in the business process, and how to create and destroy key-value storage services in the business process.

[0084] For hard drive data read / write, the target business process in the target compute node accesses the local first service component through a preset access interface called by the local client to send the metadata read / write request for the target business instance to the first service component. Then, the first service component determines the target key-value storage service corresponding to the target business instance based on the metadata read / write request. If the target key-value storage service is located in the target business process, the first service component sends the metadata read / write request to the target key-value storage service via local transmission. If the target key-value storage service is located in another business process, the first service component sends the metadata read / write request to a second service component in that other business process via network transmission, so that the second service component forwards the metadata read / write request to the target key-value storage service. Other business processes include business processes in the target compute node other than the target business process, and business processes in other compute nodes. Correspondingly, after receiving the metadata read / write request, the target key-value storage service responds to the request by performing corresponding read / write operations on at least one hard drive in the distributed storage pool and returns the metadata read / write results to the client. The metadata read / write request for the target business instance can also be understood as a metadata read / write request originating from the target business instance.

[0085] According to one example, determining the target key-value storage service corresponding to the target business instance can specifically include: determining the target key-value storage service corresponding to the target business instance based on the object identifier (OID) in the metadata read / write request.

[0086] For example, by performing a hash calculation on the object identifier in the metadata read / write request, the corresponding target service identifier can be obtained, and the target key-value storage service corresponding to the target business instance can be determined based on the target service identifier.

[0087] In one example, for the business process hosting the target key-value storage service, the compute node and business process corresponding to the target key-value storage service can be determined based on the mapping table recorded in the monitor module. The mapping table records the compute nodes and business processes corresponding to each key-value storage service.

[0088] It should be noted that this application deploys a business instance and a key-value storage service as a computing instance in the same business process on the same computing node. Therefore, when processing metadata read / write requests for a target business instance, if the target key-value storage service and the target business instance are located in the same business process, the metadata read / write request is sent to the target key-value storage service based on local transmission. Compared with the problem of request cross-network transmission caused by the business instance and the key-value storage service being deployed in different processes or different nodes when storage and computing are coupled, this application allows local transmission of requests, that is, no cross-network transmission is required, reducing one network overhead.

[0089] Furthermore, after receiving a metadata read / write request, the target key-value storage service generates a disk read / write command in response to the request. It then calls the local target key-value storage engine to send the disk read / write command to the target file system corresponding to the target key-value storage service based on the target call interface. This allows the target file system to directly access at least one hard drive in the distributed storage pool based on the first communication interface and perform read / write operations corresponding to the disk read / write command on at least one hard drive, so as to return the metadata read / write result to the client in the target business process.

[0090] The target key-value storage engine and the target call interface are both located in the target key-value storage service; the target file system and the first communication interface are both located in the business process where the target key-value storage service is located.

[0091] According to one example, when a metadata read / write request includes a metadata write request, the process of generating disk read / write commands specifically includes: the target key-value storage service writes the metadata to be written in the metadata write request to the target key-value storage engine in the form of key-value pairs, and the target key-value storage engine generates disk read / write commands based on the metadata to be written. Correspondingly, the read / write operations corresponding to the disk read / write commands include: writing the metadata to be written to a write-ahead logging (WAL) file on at least one hard disk.

[0092] Specifically, the metadata writing process of the target business process in the target computing node is as follows: Figure 3 As shown, it includes the following steps:

[0093] 1. The business call layer sends a metadata write request for the target business instance to the client (DKV Client). Here, DKV refers to key-value storage with storage and compute separation.

[0094] 2. The client calls the preset access interface to access the first service component (DKV Server0) to send the metadata write request to the first service component. The first service component determines whether a target key-value storage service (KVDB) corresponding to the target business instance exists based on the metadata write request. If it does not exist, it directly returns a prompt message indicating that the target key-value storage service does not exist to the client, and then returns it to the business call layer through the client; if it exists, it further determines whether the target key-value storage service is located in the target business process. If it is located, it goes to the Local mode and proceeds to step 3; if it is not located, it goes to the Remote mode and proceeds to step 4.

[0095] 3. In Local mode: The first service component obtains the handle of the target key-value storage service and sends the metadata write request to the target key-value storage service based on local transmission, and then proceeds to step 5;

[0096] 4. In Remote mode: The first service component sends the metadata write request to the second service component (DKV Server1) in other business processes via network transmission, so that the second service component can obtain the handle of the target key-value storage service and send the metadata write request to the target key-value storage service, and then proceed to step 5; in this case, the request sent by the first service component needs to be resent if it times out.

[0097] 5. The target key-value storage service responds to metadata write requests by calling the local processing interface to process them, supporting custom business transaction logic; after the transaction logic is processed, the metadata to be written in the metadata write request is serialized using iobuf (Input / Output Buffer) and written to batch_data in the form of key-value pairs;

[0098] 6. The target key-value storage service obtains the handle of the target key-value storage engine (RocksDB) and calls the write interface of the target key-value storage engine to persist the batch_data data to the target key-value storage engine;

[0099] 7. The target key-value storage engine generates disk read / write commands based on the batch_data data and calls the target call interface (EnvPlogFS) to send the disk read / write commands to the target file system (PlogFS) corresponding to the target key-value storage service. This allows the target file system to directly access at least one disk in the distributed storage pool via the first communication interface (NoF Client) and perform read / write operations corresponding to the disk read / write commands on at least one disk. The read / write operations include: querying the disk for the existence of a WAL file via the stat_plog query interface; if it does not exist, creating a new WAL file and opening it via the open_plog open interface; if it exists, opening the WAL file via the open_plog open interface; and after opening the WAL file, writing the batch_data data to the WAL file via the write_plog write interface for persistence to the distributed storage pool.

[0100] 8. In Local mode: The target key-value storage service returns the metadata read / write results to the client through the first service component, and then returns them to the business call layer through the client;

[0101] 9. In Remote mode: The target key-value storage service returns the metadata read and write results to the first service component through the second service component, then to the client through the first service component, and finally to the business call layer through the client.

[0102] According to another example, when the metadata read / write request includes a metadata read request, the process of generating disk read / write commands specifically includes: the target key-value storage service reads the corresponding metadata from its local cache through the target key-value storage engine based on the target key in the metadata read request; if the metadata is not found, a disk read / write command for reading the target file is generated; wherein, the target file is a file storing ordered key-value pairs. Correspondingly, the read / write operation corresponding to the disk read / write command includes: reading the target file from at least one disk to the target key-value storage engine, so that the target key-value storage engine reads the corresponding metadata from the target file based on the target key.

[0103] Specifically, the metadata reading process of the target business process in the target computing node is as follows: Figure 4 As shown, it includes the following steps:

[0104] 1. The business call layer sends a metadata read request for the target business instance to the client (DKV Client).

[0105] 2. The client calls the preset access interface to access the first service component (DKV Server0) to send the metadata read request to the first service component. The first service component determines whether a target key-value storage service (KVDB) corresponding to the target business instance exists based on the metadata read request. If it does not exist, it directly returns a prompt message indicating that the target key-value storage service does not exist to the client, and then returns it to the business call layer through the client; if it exists, it further determines whether the target key-value storage service is located in the target business process. If it is located, it goes to the Local mode and proceeds to step 3; if it is not located, it goes to the Remote mode and proceeds to step 4.

[0106] 3. In Local mode: The first service component obtains the handle of the target key-value storage service and sends the metadata read request to the target key-value storage service based on local transmission, and then proceeds to step 5;

[0107] 4. In Remote mode: The first service component sends the metadata read request to the second service component (DKV Server1) in other business processes via network transmission, so that the second service component can obtain the handle of the target key-value storage service and send the metadata read request to the target key-value storage service, and then proceed to step 5; in this case, the request sent by the first service component needs to be resent if it times out.

[0108] 5. The target key-value storage service responds to metadata read requests by calling local processing interfaces, supporting custom business transaction logic;

[0109] 6. The target key-value storage service obtains the handle of the target key-value storage engine (RocksDB), and reads the corresponding metadata (value) from the local cache (Memtable (readable and writable memory table) and Immute Memtable (readable but not writable memory table)) based on the target key in the metadata read request. If the value is found, the corresponding metadata is put into batch_data.

[0110] 7. If the target key-value storage engine does not read the corresponding metadata from its local cache, it generates a disk read / write command to read the target file (such as an .sst file) and calls the target call interface (EnvPlogFS) to send the disk read / write command to the target file system (PlogFS) corresponding to the target key-value storage service. This allows the target file system to directly access at least one disk in the distributed storage pool based on the first communication interface (NoF Client) and perform read / write operations corresponding to the disk read / write command on at least one disk. The read / write operations include: first, calling the stat_plog query interface to query the Manifest file (a transactional log that records all changes in the database state, such as the creation, deletion, or merging of .sst files) from the disk to obtain the .sst file name; then calling the open_plog open interface to open the .sst file corresponding to the file name; and calling the read_plog read interface to read the .sst file into the target key-value storage engine. After that, the target key-value storage engine searches for the corresponding metadata in the .sst files at levels L0-L6 based on the target key (accelerated by a Bloom filter at each level), and reads the corresponding metadata into batch_data after finding it.

[0111] 8. In Local mode: The target key-value storage service returns the metadata read / write results in batch_data to the client through the first service component, and then returns them to the business call layer through the client;

[0112] 9. In Remote mode: The target key-value storage service returns the metadata read and write results to the first service component through the second service component, then to the client through the first service component, and finally to the business call layer through the client.

[0113] It should be noted that after receiving a disk read / write command from the target key-value storage service, and before directly accessing at least one disk, the target file system needs to verify whether the first version number and the second version number carried in the disk read / write command are consistent. If they are inconsistent, the disk read / write command is rejected; if they are consistent, at least one disk is accessed directly. The first version number is the version number recorded when the target file system last acquired the distributed lock; the second version number is the current version number of the distributed lock.

[0114] For distributed locks, each time a key-value storage service acquires the lock, its version number is incremented by a pre-defined operation, such as incrementing by 1, to update the version number. Since only one key-value storage service can acquire a distributed lock at a time, different key-value storage services cannot have the same version number. Therefore, by comparing the consistency of the version numbers, it can be determined whether the target key-value storage service is the one that has acquired the distributed lock. This prevents key-value storage services that have not acquired the distributed lock from performing data read and write operations on the hard drive, ensuring eventual consistency of data read and write operations.

[0115] Furthermore, this application also includes a failover mechanism, which can promptly launch a new key-value storage service in other business processes when a key-value storage service fails in a certain business process, thereby taking over the work of the failed key-value storage service and ensuring business continuity. It should be noted that key-value storage service failures include, but are not limited to, network failures of the key-value storage service and failures of the business instance corresponding to the key-value storage service, such as heartbeat timeouts and network failures.

[0116] Specifically, when the target key-value storage service is located in another business process and fails, the first service component obtains the target service identifier of the target key-value storage service and determines whether a locally existing key-value storage service corresponding to the target service identifier exists. If it exists, a preset lock acquisition operation is performed through the file system corresponding to the existing key-value storage service, and a preset data read operation is performed through the key-value storage engine in the existing key-value storage service, so that the existing key-value storage service can take over the work of the target key-value storage service. If it does not exist, the first service component performs a preset service creation operation, so that the newly created key-value storage service can take over the work of the target key-value storage service. The preset service creation operation includes a preset lock acquisition operation and a preset data read operation. Furthermore, since the new key-value storage service is used to take over the work of the target key-value storage service, the service identifier of the new key-value storage service is the same as the target service identifier, so that subsequent metadata read / write requests for the target business instance can be sent to the new key-value storage service.

[0117] For example, performing a preset service creation operation includes: creating a new call interface and creating a new file system through the new call interface; mounting the new file system to a distributed storage pool through a second communication interface; mounting the new call interface to the new file system and performing a preset lock acquisition operation through the new file system; creating a new key-value storage engine and using the new call interface as the interface for the new key-value storage engine to access the new file system; creating a new key-value storage service based on the new key-value storage engine and the new call interface, and performing a preset data reading operation through the new key-value storage engine.

[0118] For example, the preset lock acquisition operation includes: requesting to acquire a distributed lock, and after the lease of the distributed lock on the target file system expires, acquiring the distributed lock and recording the incremented version number of the distributed lock; the incremented version number is the version number obtained by performing a preset increment operation on the current version number of the distributed lock.

[0119] In other words, if key-value storage service 1 fails during its lease period for the distributed lock, key-value storage service 2 needs to acquire the distributed lock in order to take over its work. Only the key-value storage service that acquires the distributed lock can perform data read and write operations on the hard drive. However, when key-value storage service 2 applies for the distributed lock, key-value storage service 1's lease for the distributed lock may not have expired. In this case, a lock acquisition failure message will be returned to key-value storage service 2, and key-value storage service 2 will continue to retry until key-value storage service 1's lease for the distributed lock expires. At this time, key-value storage service 2 will perform a preset increment operation, such as +1, to update the version number of the distributed lock. After that, key-value storage service 2 can use the incremented version number to perform data read and write operations on the hard drive, ensuring that the same distributed lock can only be acquired by one key-value storage service at a time. Thus, through the distributed lock, eventual consistency of data read and write operations can be guaranteed.

[0120] For example, a preset data read operation includes: reading a copy of the target key-value storage service data from at least one hard drive in the distributed storage pool. In this way, by employing a storage-compute separation architecture, the present invention allows multiple computing nodes to share the same storage node. Therefore, in the failover mechanism, the replacement key-value storage service only needs to read the copy of the failed key-value storage service data from the distributed storage pool to achieve failover. Compared to the storage-compute coupling approach, which requires executing snapshot generation -> snapshot transfer -> snapshot installation operations to achieve failover, the present invention can significantly reduce the overhead of failover and improve its efficiency.

[0121] It should be noted that, in addition to creation under the failover mechanism mentioned above, key-value storage services can also be created when a new business instance is added in the business process, or according to user needs. This application does not limit the triggering conditions for key-value storage service creation. The creation process of key-value storage services is as follows: Figure 5 As shown, the specific steps include:

[0122] 1. The service component (DKV Server) obtains the storage service creation instructions;

[0123] 2. The service component creates a call interface (EnvPlogFS) as the Env (Environment, which is the operating system abstraction layer in RocksDB and the unified interface between RocksDB and the underlying operating system) for the subsequently created key-value storage engine (RocksDB), and persists WAL, current (a special file that does not contain actual data but stores a filename pointer to the latest Manifest file), Manifest, and SST files, etc.

[0124] 3. The service component creates a file system (PlogFS) and generates a system identifier (fsid) by calling the interface; the file system is mounted to the distributed storage pool through the communication interface (NoF Client);

[0125] 4. The service component initializes the file system by calling the interface based on the system identifier (fsid);

[0126] 5. The service component will mount the API call to the file system;

[0127] 6. The service component performs a preset lock acquisition operation through the file system to obtain a distributed lock (PLock). After acquiring the distributed lock, the file system persists the system identifier (fsid) to the distributed lock.

[0128] 7. The service component creates RocksDB:Env by calling the interface and binds it to the file system;

[0129] 8. The service component creates a key-value storage engine (RocksDB) to create a key-value storage service (KVDB) based on the key-value storage engine and the calling interface. The service identifier of the key-value storage service is the same as the system identifier (fsid).

[0130] 9. Key-value storage service control: The key-value storage engine uses the call interface as RocksDB:Env for persistent data, thus making the call interface the interface for the key-value storage engine to access the file system;

[0131] 10. The key-value storage engine queries the existence of LockFile (a file lock used to encrypt files or folders of any type) by calling the interface. If it exists, the interface returns OK; otherwise, a new LockFile is created.

[0132] 11. The key-value store engine queries the existence of current and identity files (used to store unique identifiers for database instances) by calling the interface; the interface queries the distributed storage pool through the state_plog query interface in the file system to determine whether current and identity files exist. If they do not exist, the current and identity files are created.

[0133] 12. The key-value storage engine loads the Manifest and WAL files by calling the interface. Specifically, the interface queries the Manifest and WAL files from the distributed storage pool through the stat_plog query interface in the file system, opens the Manifest and WAL files through the open_plog open interface in the file system, and reads the Manifest and WAL files through the read_plog read interface in the file system and inserts them into the Memtable of the key-value storage engine.

[0134] 13. The key-value storage engine persists data in the Memtable to the corresponding sst file in the distributed storage pool by calling the interface. Specifically, the interface opens the sst file through the open_plog interface in the file system and writes the data in the Memtable to the sst file through the write_plog interface in the file system. After successful writing, the result is returned to complete the creation of the key-value storage service.

[0135] Furthermore, this application also includes a destruction mechanism for the key-value storage service. Taking a new key-value storage service created by the first service component as an example, when the first service component obtains a destruction instruction for the new key-value storage service, it sends the destruction instruction to the new key-value storage service. The new key-value storage service responds to the destruction instruction by calling a new call interface to unload the new file system after releasing the distributed lock, and closes the new call interface after unloading is completed. After the new call interface is successfully closed, the new key-value storage engine is destroyed through the new key-value storage service, and the destruction of the new key-value storage service is completed after the new key-value storage engine is successfully destroyed.

[0136] The destruction instruction is generated when the failure duration of the new key-value storage service exceeds the first preset time, or when the failure duration of the new key-value storage service after recovery exceeds the second preset time. Of course, there may be other ways to generate the destruction instruction, which will not be illustrated here.

[0137] Specifically, the destruction process of key-value storage services is as follows: Figure 6 As shown, the following steps may be included:

[0138] 1. The service component (DKV Server) obtains the destruction command for the key-value storage service (KVDB);

[0139] 2. The service component sends the destruction command to the key-value storage service;

[0140] 3. The key-value storage service responds to the destruction command to unload the file system after releasing the distributed lock by calling the interface (EnvPlogFS), and closes the calling interface after the unloading is completed; wherein, the calling interface unloads the file system (PlogFS) corresponding to the key-value storage service, and the file system has released the distributed lock;

[0141] 4. The key-value storage service destroys the key-value storage engine (RocksDB);

[0142] 5. After the key-value storage engine is successfully destroyed, a message indicating successful destruction is returned to the service component.

[0143] Furthermore, considering that failover mechanisms can easily burden other business processes, leading to load imbalances among them, and prolonged load imbalances can cause system crashes, this embodiment of the invention also adds a failover mechanism. Taking the scenario where the target key-value storage service is located in another business process and fails as an example, assuming the target business process has already created a new key-value storage service to replace the target key-value storage service in the first service component based on the failover mechanism, in order to balance the load among the business processes, after detecting that the target key-value storage service has recovered from the failure or that other normally operating business processes have destroyed the failed target key-value storage service, the target business process can send a failover instruction to other business processes and destroy the local new key-value storage service. Correspondingly, upon receiving the fault rollback instruction, other business processes respond to it by determining whether a locally existing key-value storage service (i.e., the target key-value storage service after fault recovery) exists, corresponding to the service identifier of the new key-value storage service. If it exists, a preset lock acquisition operation is performed through the file system corresponding to the existing key-value storage service, and a preset data read operation is performed through the key-value storage engine in the existing key-value storage service, so that the existing key-value storage service can take over the work of the new key-value storage service. If it does not exist, a preset service creation operation is performed through the second service component, so that the newly created key-value storage service can take over the work of the new key-value storage service. The preset service creation operation includes a preset lock acquisition operation and a preset data read operation; the newly created key-value storage service has the same service identifier as the new key-value storage service. In this way, by introducing a fault rollback mechanism, this application can ensure load balancing among various business processes as much as possible, thereby improving system stability.

[0144] Therefore, this application decouples the key-value storage service in the computing node from the storage node by independently deploying storage nodes and computing nodes. This allows the key-value storage service to be deployed independently in the computing node at a low deployment cost. Furthermore, since the key-value storage service in this application is deployed based on different business instances in the corresponding business process, different business instances in this application correspond to different key-value storage services. That is, this application supports flexible deployment of key-value storage services according to business instances, which can not only improve business concurrency capabilities but also adapt to complex and ever-changing business needs, thereby improving storage performance.

[0145] See Figure 7 As shown, this embodiment of the invention discloses a storage-compute separation data read / write device, applied to a target business process in a target computing node, comprising:

[0146] The first sending module 11 is used to send metadata read / write requests for the target business instance to the local first service component through a local client;

[0147] The second sending module 12 is used to send the metadata read / write request to the target key-value storage service corresponding to the target business instance through the first service component, so that the target key-value storage service can perform corresponding read / write operations on at least one hard disk in response to the metadata read / write request and return the metadata read / write result to the client.

[0148] Among them, the different key-value storage services in the service components are storage services deployed based on different business instances in the corresponding business processes; the at least one hard disk is located in the distributed storage pool of the storage node, and the storage node is independent of the computing node.

[0149] It should be noted that the feature descriptions in the embodiments corresponding to the storage-computation separation data read-write device correspond to the embodiments in the storage-computation separation data read-write method section. Therefore, the specific feature descriptions of the device section embodiments can be referred to the embodiments in the method section, and will not be elaborated further here.

[0150] Therefore, this application decouples the key-value storage service in the computing node from the storage node by independently deploying storage nodes and computing nodes. This allows the key-value storage service to be deployed independently in the computing node at a low deployment cost. Furthermore, since the key-value storage service in this application is deployed based on different business instances in the corresponding business process, different business instances in this application correspond to different key-value storage services. That is, this application supports flexible deployment of key-value storage services according to business instances, which can not only improve business concurrency capabilities but also adapt to complex and ever-changing business needs, thereby improving storage performance.

[0151] Furthermore, embodiments of this application also disclose an electronic device, Figure 8 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0152] Figure 8 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the storage-computation separation data read / write method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0153] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0154] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0155] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the storage-computation separation data read / write method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0156] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned data read / write method with storage-computation separation. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0157] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0158] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0159] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0160] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0161] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data read / write method with storage-compute separation, characterized in that, The target business processes applied to the target computing node include: The local client sends metadata read / write requests for the target business instance to the local first service component. The first service component sends the metadata read / write request to the target key-value storage service corresponding to the target business instance, so that the target key-value storage service can respond to the metadata read / write request, perform corresponding read / write operations on at least one hard disk, and return the metadata read / write result to the client. Among them, the different key-value storage services in the service components are storage services deployed based on different business instances in the corresponding business processes; the at least one hard disk is located in the distributed storage pool of the storage node, and the storage node is independent of the computing node.

2. The data read / write method with storage-computation separation according to claim 1, characterized in that, The step of sending metadata read / write requests for the target business instance to the local first service component via a local client includes: The local client calls a preset access interface to access the first local service component, so as to send the metadata read / write request for the target business instance to the first service component.

3. The data read / write method with storage-computation separation according to claim 1, characterized in that, The step of sending the metadata read / write request to the target key-value storage service corresponding to the target business instance through the first service component includes: The first service component determines the target key-value storage service corresponding to the target business instance based on the metadata read / write request; If the target key-value storage service is located in the target business process, the metadata read / write request is sent to the target key-value storage service through the first service component based on local transmission. If the target key-value storage service is located in another business process, the first service component sends the metadata read / write request to the second service component in the other business process via network transmission, so that the second service component sends the metadata read / write request to the target key-value storage service. The other business processes include business processes in the target computing node other than the target business process, as well as business processes in other computing nodes.

4. The data read / write method with storage-computation separation according to claim 3, characterized in that, The target key-value storage service generates a hard disk read / write command in response to the metadata read / write request, and calls the local target key-value storage engine to send the hard disk read / write command to the target file system based on the target call interface, so that the target file system can directly access the at least one hard disk based on the first communication interface and perform read / write operations corresponding to the hard disk read / write command on the at least one hard disk, so as to return the metadata read / write result to the client; The target file system is the file system corresponding to the target key-value storage service, and both the target file system and the first communication interface are located in the business process where the target key-value storage service is located.

5. The data read / write method with storage-computation separation according to claim 4, characterized in that, The metadata read / write request includes a metadata write request; correspondingly, the process of generating the hard disk read / write command includes: The target key-value storage service writes the metadata to be written in the metadata write request to the target key-value storage engine in the form of key-value pairs, and generates the hard disk read / write command based on the metadata to be written by the target key-value storage engine; Accordingly, the read / write operation includes writing the metadata to be written to a write-ahead log file on the at least one hard disk.

6. The data read / write method with storage-computation separation according to claim 4, characterized in that, The metadata read / write request includes a metadata read request; correspondingly, the process of generating the hard disk read / write command includes: The target key-value storage service reads the corresponding metadata from the local cache based on the target key in the metadata read request through the target key-value storage engine. If the metadata is not found, a disk read / write command for reading the target file is generated. The target file is a file that stores ordered key-value pairs. Accordingly, the read / write operation includes reading the target file from the at least one hard disk into the target key-value storage engine, so that the target key-value storage engine reads the corresponding metadata from the target file based on the target key.

7. The data read / write method with storage-computation separation according to claim 4, characterized in that, Before directly accessing the at least one hard disk, the target file system verifies whether the first version number and the second version number carried by the hard disk read / write command are consistent. If they are inconsistent, the hard disk read / write command is rejected; if they are consistent, the at least one hard disk is accessed directly. Wherein, the first version number is the version number recorded when the target file system last acquired the distributed lock; the second version number is the current version number of the distributed lock.

8. The data read / write method with storage-computation separation according to claim 7, characterized in that, Also includes: When the target key-value storage service is located in the other business process and a failure occurs, the target service identifier of the target key-value storage service is obtained through the first service component, and it is determined whether there is a created key-value storage service corresponding to the target service identifier locally; If it exists, a preset lock acquisition operation is performed through the file system corresponding to the created key-value storage service, and a preset data reading operation is performed through the key-value storage engine in the created key-value storage service, so as to use the created key-value storage service to take over the work of the target key-value storage service. If it does not exist, a preset service creation operation is performed through the first service component to use the newly created key-value storage service to take over the work of the target key-value storage service. The preset service creation operation includes the preset lock acquisition operation and the preset data reading operation; The service identifier of the new key-value storage service is the same as the target service identifier.

9. The data read / write method with storage-computation separation according to claim 8, characterized in that, The execution of the preset service creation operation includes: Create a new API call interface, and create a new file system through the new API call interface; The new file system is mounted to the distributed storage pool via the second communication interface; The new calling interface is mounted to the new file system, and the preset lock acquisition operation is performed through the new file system; Create a new key-value storage engine and use the new API call as the interface for the new key-value storage engine to access the new file system; The new key-value storage service is created based on the new key-value storage engine and the new calling interface, and the preset data reading operation is executed through the new key-value storage engine.

10. The data read / write method with storage-computation separation according to claim 9, characterized in that, The preset lock acquisition operation includes applying to acquire the distributed lock, and after the lease of the distributed lock in the target file system expires, acquiring the distributed lock and recording the incremented version number of the distributed lock; the incremented version number is the version number obtained by performing a preset increment operation on the current version number of the distributed lock; The preset data read operation includes reading a copy of the target key-value storage service data from the at least one hard disk.

11. The data read / write method with storage-computation separation according to claim 9, characterized in that, Also includes: When the first service component receives a destruction instruction for the new key-value storage service, it sends the destruction instruction to the new key-value storage service through the first service component. The new key-value storage service responds to the destruction command by calling the new call interface to unload the new file system after releasing the distributed lock, and closes the new call interface after unloading is complete; After the new calling interface is successfully closed, the new key-value storage engine is destroyed through the new key-value storage service, and the destruction of the new key-value storage service is completed after the new key-value storage engine is successfully destroyed.

12. The data read / write method with storage-computing separation according to claim 11, characterized in that, The destruction instruction is generated when the failure duration of the new key-value storage service exceeds a first preset time, or when the new key-value storage service fails to acquire the distributed lock for a duration exceeding a second preset time after the failure is recovered.

13. A data read / write device with separate storage and computation functions, characterized in that, The target business processes applied to the target computing node include: The first sending module is used to send metadata read / write requests for the target business instance to the first local service component via a local client. The second sending module is used to send the metadata read / write request to the target key-value storage service corresponding to the target business instance through the first service component, so that the target key-value storage service can perform corresponding read / write operations on at least one hard disk in response to the metadata read / write request and return the metadata read / write result to the client. Among them, the different key-value storage services in the service components are storage services deployed based on different business instances in the corresponding business processes; the at least one hard disk is located in the distributed storage pool of the storage node, and the storage node is independent of the computing node.

14. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the storage-computation separation data read / write method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, Used to store computer programs, which, when executed by a processor, implement the storage-computation separation data read / write method as described in any one of claims 1 to 12.

Images