CN109756573B - File system based on block chain - Google Patents
File system based on block chain Download PDFInfo
- Publication number
- CN109756573B CN109756573B CN201910035139.2A CN201910035139A CN109756573B CN 109756573 B CN109756573 B CN 109756573B CN 201910035139 A CN201910035139 A CN 201910035139A CN 109756573 B CN109756573 B CN 109756573B
- Authority
- CN
- China
- Prior art keywords
- server
- file
- block
- blockchain
- block chain
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Abstract
The invention discloses a block chain-based file system, which comprises a main control server, a standby server, a plurality of block chain servers and a plurality of clients, wherein the main control server is connected with the standby server through a network; the main control server and the standby server respectively comprise a block generation module, a block chain server management module, a service scheduling module and a main and standby disaster recovery module; the block chain server comprises a data local storage module, a state maintenance module and a copy management module; the client comprises an interface module and a cache module. The invention mainly starts from a block chain technical architecture, combines the basic principle of a block chain system, realizes a file system based on the block chain, and ensures the authenticity, integrity and non-tamper property of the full life cycle of file storage. In addition, the main and standby servers are added, so that the availability of the system is improved; the scheme of fixing the block size is adopted, and the file access performance is improved.
Description
Technical Field
The invention relates to the technical field of internet, in particular to a file system based on a block chain.
Background
As modern society transits from the industrial age to the information age, data is becoming the most valuable resource in the world due to explosive growth of data caused by development of information technology and intelligentization of human life. According to the physical storage form, the data storage can be divided into centralized storage and distributed storage. Centralized storage is dominated by traditional storage arrays (traditional storage) and distributed storage (cloud storage) is dominated by software defined storage. The traditional storage is always well known for high reliability, good stability and rich functions, but at the same time, the traditional storage also exposes the defects of poor lateral expansibility, high price, difficult data communication and the like, and a data island is easily formed, so that the management and maintenance cost of a data center is high. Distributed storage: the data is stored on a plurality of independent devices on the network in a scattered manner, a standard x86 server is generally adopted to be interconnected with the network, and relevant storage software is operated on the server, so that the system provides storage service for the external as a whole. In a word, the distributed file storage not only improves the utilization rate of the storage space, but also realizes elastic expansion, reduces the operation cost, avoids resource waste and is more suitable for future data explosion times scenes.
In the data storage solution of the traditional distributed file system, the big problem is divided into small problems at the bottom. After a large number of files are uniformly distributed on a plurality of blockchain servers, the number of the files stored in each blockchain server is small, and in addition, the number of the files stored in a single blockchain server can be always reduced to the size which can be solved by a single blockchain server by using a mode of storing a plurality of small files by using a large file; for a very large file, the large file is divided into a plurality of relatively small segments and stored on a plurality of blockchain servers (at present, the support of a large number of local file systems to a very large file is not problematic, for example, when an EXT3 file system uses 4k blocks, the maximum file can reach 4T, and the EXT4 can support a larger file, which is only limited by the storage space of a disk).
Theoretically, a distributed file system can only consist of a client and a plurality of blockchain servers, the client determines which blockchain server to store a file to according to a file name, but once a blockchain server fails, the problem becomes complex, the client does not know the downtime message of the blockchain server and is still connected with the blockchain server for data access, so that the reliability of the whole system is greatly reduced, and the client is completely inflexible when determining data distribution, and cannot make different distribution strategies according to file characteristics. Therefore, urgent needs can be met to know the state management of the service state blockchain servers of each blockchain server, and a mainstream mode can be divided into a distributed mode and a centralized mode, wherein the former mode is that a plurality of blockchain servers are managed mutually, for example, each server sends heartbeat information to all other servers, but the mode has high overhead, is not easy to control and easily affects normal data service, and has complex engineering realization; the latter is to manage the blockchain server through an independent server (such as the main control server in the above figure), and each server reports the service status to the server to achieve the purpose of centralized management.
The simplest way to store files locally is to allocate each file data of a client to a single blockchain server as a local file, but this way does not take good advantage of the characteristics of the distributed file system.
In addition, for file update, the conventional blockchain server deletes the file before update, and cannot save the historical version.
Disclosure of Invention
In order to solve the technical problems, the invention aims to provide a block chain-based file system, which realizes block chain-based distributed file storage and ensures the authenticity, integrity and safety of the full life cycle of file storage; in addition, the main and standby servers are added, so that the availability of the system is improved; the scheme of fixing the block size is adopted, and the file access performance is improved.
In order to achieve the purpose, the invention provides the following technical scheme:
a block chain-based file system comprises a main control server, a standby server, a plurality of block chain servers and a plurality of clients;
the main control server and the standby server respectively comprise a block generation module, a block chain server management module, a service scheduling module and a main and standby disaster recovery module;
the block generation module is used for storing data of a plurality of files in one file block and establishing indexes for the files in the block; each file block has a unique ID, file IDs are generated for a plurality of files, and the generated file blocks are sent to a block chain server and exposed to a user for use;
the block chain server management module is used for centrally managing the block chain servers;
the service scheduling module is used for servicing requests from the client and the block chain server, the service model uses a thread pool, an independent thread receives the requests and adds the requests into a task queue, and the threads in the thread pool continuously take out tasks from the task queue for processing;
the main and standby disaster recovery modules provide a virtual IP service for the main and standby servers, realize data synchronization of the main and standby servers, and take over resources and services of the main control server when the standby server detects that the main control server is down;
the block chain server comprises a data local storage module, a state maintenance module and a copy management module;
the data local storage module is responsible for the local persistent storage of the file data; the file creation and deletion are supported, and the updating is not supported;
the state maintenance module is used for periodically reporting the state of the master control server to the master control server in a heartbeat packet mode, so that the master control server can know whether the master control server works normally or not; the heartbeat package comprises the current load condition of the block chain server, a CPU, a memory, a disk IO, a disk storage space, a network IO and a process resource;
the copy management module realizes that a plurality of copies of a file are stored in a block chain server, and particularly realizes that a main control server writes data to a new file block broadcasted through the whole network in a P2P network mode;
the client comprises an interface module and a cache module;
the interface module reads and writes files through an interface provided by a file system;
the client cache module is used for caching the meta information, and the data is cached in a local memory or a disk according to the service characteristics; the cache replacement algorithm may be LRU or random replacement.
Further, the file blocks are nodes constituting a block chain; the file blocks comprise magic numbers, block sizes, block headers, file numbers and file contents; the block header determines the entire block chain, including the version, Hash of the previous block, the Merkle root, and the timestamp.
Further, the centralized management of the blockchain server by the blockchain server management module is as follows: the method is realized by polling the blockchain servers or reporting heartbeats by the blockchain servers, and when a write request of a client is received, the main control server needs to select a group of blockchain servers to serve the blockchain servers according to the load information of each blockchain server; when the master control server finds that the blockchain server is down, a replication plan needs to be executed on files with insufficient replication numbers; when a new blockchain server joins the cluster or the load on a blockchain server is too high, the master control server can execute a copy migration plan according to the requirement.
Further, when the blockchain server management module allocates the blockchain server, the basic allocation method includes random selection, time slice rotation and low load priority.
Furthermore, the blockchain server management module may also use the deployment of the server as a reference when allocating the blockchain server, and may also order the allocated blockchain servers according to the distance from the client according to the information of the client, so that the client preferentially selects a blockchain server close to the client to perform data access.
Furthermore, the data of the main control server is synchronized to the standby server in an asynchronous mode, namely, the request information of the client is temporarily stored firstly and is added to the operation log, and the background thread replays the log to the standby server.
Furthermore, on the blockchain server, a plurality of physical blocks are arranged on the mount directory, the physical blocks are stored on a disk in a file form and are pre-distributed before deployment of the blockchain server, so as to guarantee subsequent access speed and reduce fragment generation, and the blockchain server adopts an EXT4 file system.
Further, the physical block is composed of a main block and an extended block, and the extended block is used for large file operation.
Furthermore, the file blocks correspond to a plurality of physical blocks, wherein the physical blocks comprise a main block, N expansion blocks and an index file corresponding to the file blocks; each small file in the file block is identified by a unique file ID within a block; the file name of the small file consists of a block ID and a file ID, the maximum length is 20 bytes, the maximum length is fixed by beginning B, the 2 nd to 3 rd bytes are the serial number of the cluster, the value range is 01-99, and the rest 17 bytes are obtained by encoding the block ID and the file ID.
Further, the interface provided by the file system is a POSIX interface, a client interface or a Restful interface.
Has the advantages that: the invention provides a block chain-based file system, which is mainly based on a block chain technical architecture and combined with the basic principle of the block chain system, realizes the block chain-based file system, and ensures the authenticity, integrity and non-tamper property of the full life cycle of file storage. In addition, the main and standby servers are added, so that the availability of the system is improved; the scheme of fixing the block size is adopted, and the file access performance is improved.
Drawings
FIG. 1 is an architecture diagram of a block chain based file system according to the present invention.
FIG. 2 is a block diagram of file block data according to the present invention.
Fig. 3 is a file name map.
Detailed Description
The present invention is further described below with reference to specific examples, which are only exemplary and do not limit the scope of the present invention in any way. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention, and that such changes and modifications may be made without departing from the spirit and scope of the invention.
A file system based on a block chain, as shown in fig. 1, includes a main control server (primary), a standby server (standby), a plurality of block chain servers, and a plurality of clients.
The client can be various application servers and can also be an end user.
The main control server comprises a block generation module, a block chain server management module, a service scheduling module and a main and standby disaster recovery module.
The master control server block generation module selects a plurality of files, stores data of the files in a file block, and establishes indexes for the files in the block; the unique ID is possessed for each file block, the file IDs are generated for a plurality of files, and the generated file blocks are sent to a block chain server and exposed to users for use.
The file block part is a node forming a block chain, and the file block data structure is shown in fig. 2. The block structure comprises magic numbers, block sizes, block headers, file numbers, file contents and the like. The block structure of one block is shown in table 1 below:
TABLE 1
Among the blocks, the block header is the block head that determines the entire block chain. The block header includes the version, Hash of the previous block, the Merkle root, the timestamp, etc. The block head is shown in table 2 below:
TABLE 2
The block chain server management module is used for managing the block chain servers in a centralized manner, and can be realized by polling the block chain servers or reporting heartbeats by the block chain servers; when the master control server finds that a blockchain server is down, a replication plan needs to be executed on files (blocks) with insufficient copy numbers; when a new blockchain server joins the cluster or the load on a blockchain server is too high, the master control server can also execute some copy migration plans according to the needs.
The metadata store of the master server may be persistent.
When the block chain server management module allocates the block chain server, the basic allocation method includes random selection, time slice rotation and low load priority.
The block chain server management module can also use the deployment of the server as a reference when the block chain server is distributed, and can also sort the distributed block chain servers according to the distance from the client according to the information of the client, so that the client preferentially selects the block chain server close to the client to perform data access.
The service scheduling module services requests from the client and the block chain server, the service model uses a thread pool, the requests are received by independent threads and added into a task queue, and the threads in the thread pool continuously take out tasks from the task queue for processing.
The main and standby disaster recovery modules provide a virtual IP service for the main and standby servers, realize data synchronization of the main and standby servers, and manage resources and services of the main control server when the standby server detects that the main server is down; the data of the main control server is synchronized to the standby server in an asynchronous mode, namely, the request information of the client is temporarily stored firstly and is added to the operation log, and the background thread replays the log to the standby main control server.
The block chain server comprises a data local storage module, a state maintenance module and a copy management module.
The data local storage module is responsible for the local persistent storage of the file data, and the block is actually stored in the blockchain server.
The information of all blocks is stored in the master server node, and one block is stored in a plurality of block chain servers to ensure the redundancy of data. For the data read-write request, the main control server selects a proper block chain server node to return to the client, and then performs data operation on the corresponding block chain server node. The master server needs to maintain a block information list and a mapping relationship between blocks and the blockchain server, and a metadata structure stored by the master server is shown in fig. 2.
On the blockchain server node, a plurality of physical blocks exist on the mount directory, and the physical blocks exist on a disk in a file form and are pre-distributed before deployment of the blockchain server, so that the subsequent access speed is ensured and the fragment generation is reduced. The blockchain server may employ the EXT4 file system.
The physical block is composed of a main block and an extended block, and the extended block is used for large file operation.
The file block may correspond to a plurality of physical blocks, including a main block, N extended blocks, and an index file corresponding to the file block.
Each small file in the file block is identified by a unique file ID within a block.
The file name of the small file is composed of a block ID and a file ID through a certain corresponding relation, the maximum length is 20 bytes, the maximum length is fixed by beginning B, the 2 nd to 3 rd bytes are the serial number (the value range is 01-99) of the cluster, and the rest 17 bytes are obtained by the block ID and the file ID through a certain coding mode.
The file name is encoded and decoded by the client program and it is mapped as shown in fig. 3.
The data local storage module supports the creation and deletion of files and does not support updating (completed by deletion and creation); adding the newly created file to the end of the large file and updating the index; when the file is deleted, the deletion mark of the file header is simply set, and the system can compress the large file when in idle and recycle the file storage space which is set with the deletion mark and exceeds a certain time limit.
The state maintenance module reports the state of the master control server to the master control server periodically in a heartbeat packet mode, so that the master control server knows whether the master control server works normally or not; the heartbeat includes the current load condition of the blockchain server, CPU, memory, disk IO, disk storage space, network IO and other process resources.
The copy management realizes that a file can store a plurality of copies to a block chain server, and concretely realizes that a main control server writes data to a new file block broadcasted through the whole network in a P2P network mode.
The client comprises an interface module and a cache module.
The client interface module reads and writes files through an interface provided by a file system, and the client converts file names into block ID and file ID information when reading the files and then can obtain the information of a block chain server where the block is located in a main control server; if the client has the cache of the block and the block chain server, the client directly fetches the block and the cache, and then performs reading operation with the block chain server.
The interface can be a POSIX interface, and an application (all languages are available, and finally the system call) can replace a local file storage with a distributed file storage without modification.
The interface may be a client interface in other languages such as the commonly used C/C + +, java, php, python clients. In a situation that the client-side mode is difficult to handle, when the client-side is upgraded, the application using the client-side interface needs to use a new function and needs to be upgraded, and when the number of applications is large, the upgrading process is very troublesome.
The interface can be a Restful interface, and a http protocol mode is used for the client to access the file resources. This avoids problems associated with upgrading functionality.
The client cache module caches the meta information, and the data can be cached in a local memory or a disk according to the service characteristics; the cache replacement algorithm may be LRU, random replacement, etc.
The invention mainly starts from a block chain technical architecture, combines the basic principle of a block chain system, realizes a file system based on the block chain, and ensures the authenticity, integrity and non-tamper property of the full life cycle of file storage.
The above description is only a preferred embodiment of the present invention, and is not intended to limit the scope of the present invention.
Claims (9)
1. A block chain-based file system is characterized by comprising a main control server, a standby server, a plurality of block chain servers and a plurality of clients;
the main control server and the standby server respectively comprise a block generation module, a block chain server management module, a service scheduling module and a main and standby disaster recovery module;
the block generation module is used for storing data of a plurality of files in one file block and establishing indexes for the files in the block; each file block has a unique ID, file IDs are generated for a plurality of files, and the generated file blocks are sent to a block chain server and exposed to a user for use;
the block chain server management module is used for managing the block chain servers in a centralized mode, and the block chain server management module manages the block chain servers in the centralized mode in the following mode: the method is realized by polling the blockchain servers or reporting heartbeats by the blockchain servers, and when a write request of a client is received, the main control server needs to select a group of blockchain servers to serve the blockchain servers according to the load information of each blockchain server; when the master control server finds that the blockchain server is down, a replication plan needs to be executed on files with insufficient replication numbers; when a new blockchain server is added into the cluster or the load on a certain blockchain server is too high, the main control server executes a copy migration plan according to the requirement;
the service scheduling module is used for servicing requests from the client and the block chain server, the service model uses a thread pool, an independent thread receives the requests and adds the requests into a task queue, and the threads in the thread pool continuously take out tasks from the task queue for processing;
the main and standby disaster recovery modules provide a virtual IP service for the main and standby servers, realize data synchronization of the main and standby servers, and take over resources and services of the main control server when the standby server detects that the main control server is down;
the block chain server comprises a data local storage module, a state maintenance module and a copy management module;
the data local storage module is responsible for the local persistent storage of the file data; the file creation and deletion are supported, and the updating is not supported;
the state maintenance module is used for periodically reporting the state of the master control server to the master control server in a heartbeat packet mode, so that the master control server can know whether the master control server works normally or not; the heartbeat package comprises the current load condition of the block chain server, a CPU, a memory, a disk IO, a disk storage space, a network IO and a process resource;
the copy management module realizes that a plurality of copies of a file are stored in a block chain server, and particularly realizes that a main control server writes data to a new file block broadcasted through the whole network in a P2P network mode;
the client comprises an interface module and a cache module;
the interface module reads and writes files through an interface provided by a file system;
the client cache module is used for caching the meta information, and the data is cached in a local memory or a disk according to the service characteristics; the cache replacement algorithm is LRU or random replacement.
2. The block chain based file system of claim 1, wherein the file blocks are nodes constituting a block chain; the file blocks comprise magic numbers, block sizes, block headers, file numbers and file contents; the block header determines the entire block chain, including the version, Hash of the previous block, the Merkle root, and the timestamp.
3. The blockchain-based file system of claim 1, wherein the blockchain server management module assigns blockchain servers according to a random selection method, a round robin method, and a low load priority method.
4. The blockchain-based file system according to claim 1, wherein the blockchain server management module further uses deployment of the server as a reference when allocating the blockchain server, and also sorts the allocated blockchain server according to a distance from the client according to information of the client, so that the client preferentially selects a blockchain server that is close to the client for data access.
5. The blockchain-based file system of claim 1, wherein the data synchronization of the main server to the standby server is asynchronous, that is, the request information of the client is temporarily stored first and added to the operation log, and the background thread replays the log to the standby server.
6. The blockchain-based file system of claim 1, wherein the blockchain server has a plurality of physical blocks on a mount directory, the physical blocks are stored on a disk in a file form and are pre-allocated before deployment of the blockchain server to ensure subsequent access speed and reduce fragment generation, and the blockchain server adopts an EXT4 file system.
7. The blockchain-based file system of claim 6, wherein the physical blocks are composed of main blocks and extended blocks, and the extended blocks are used for large file operations.
8. The blockchain-based file system of claim 6, wherein the file block corresponds to a plurality of physical blocks, including a main block, N extended blocks, and an index file corresponding to the file block; each small file in the file block is identified by a unique file ID within a block; the file name of the small file consists of a block ID and a file ID, the maximum length is 20 bytes, the maximum length is fixed by beginning B, the 2 nd to 3 rd bytes are the serial number of the cluster, the value range is 01-99, and the rest 17 bytes are obtained by the block ID and the file ID in an encoding mode.
9. The blockchain-based file system of claim 1, wherein the interface provided by the file system is a POSIX interface, a client interface, or a Restful interface.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910035139.2A CN109756573B (en) | 2019-01-15 | 2019-01-15 | File system based on block chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910035139.2A CN109756573B (en) | 2019-01-15 | 2019-01-15 | File system based on block chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109756573A CN109756573A (en) | 2019-05-14 |
| CN109756573B true CN109756573B (en) | 2022-02-08 |
Family
ID=66404957
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910035139.2A Active CN109756573B (en) | 2019-01-15 | 2019-01-15 | File system based on block chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109756573B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11036720B2 (en) | 2019-06-28 | 2021-06-15 | Advanced New Technologies Co., Ltd. | Blockchain-based hierarchical data storage |
| CN110347660B (en) * | 2019-06-28 | 2020-08-11 | 阿里巴巴集团控股有限公司 | Block chain based hierarchical storage method and device and electronic equipment |
| US10789222B2 (en) | 2019-06-28 | 2020-09-29 | Alibaba Group Holding Limited | Blockchain-based hierarchical data storage |
| CN111046107B (en) * | 2019-12-19 | 2023-05-26 | 北京中兵智航科技有限公司 | Distributed storage system based on airport center data of block chain technology |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101309167A (en) * | 2008-06-27 | 2008-11-19 | 华中科技大学 | Disaster allowable system and method based on cluster backup |
| CN103647797A (en) * | 2013-11-15 | 2014-03-19 | 北京邮电大学 | Distributed file system and data access method thereof |
| CN105005611A (en) * | 2015-07-10 | 2015-10-28 | 中国海洋大学 | File management system and file management method |
| CN106294585A (en) * | 2016-07-28 | 2017-01-04 | 四川新环佳科技发展有限公司 | A kind of storage method under cloud computing platform |
| CN107918612A (en) * | 2016-10-08 | 2018-04-17 | 腾讯科技（深圳）有限公司 | The implementation method and device of key assignments memory system data structure |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103581229B (en) * | 2012-07-26 | 2018-06-15 | 腾讯科技（深圳）有限公司 | Distributed file system, file access method and client |
-
2019
- 2019-01-15 CN CN201910035139.2A patent/CN109756573B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101309167A (en) * | 2008-06-27 | 2008-11-19 | 华中科技大学 | Disaster allowable system and method based on cluster backup |
| CN103647797A (en) * | 2013-11-15 | 2014-03-19 | 北京邮电大学 | Distributed file system and data access method thereof |
| CN105005611A (en) * | 2015-07-10 | 2015-10-28 | 中国海洋大学 | File management system and file management method |
| CN106294585A (en) * | 2016-07-28 | 2017-01-04 | 四川新环佳科技发展有限公司 | A kind of storage method under cloud computing platform |
| CN107918612A (en) * | 2016-10-08 | 2018-04-17 | 腾讯科技（深圳）有限公司 | The implementation method and device of key assignments memory system data structure |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109756573A (en) | 2019-05-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109756573B (en) | File system based on block chain | |
| US9460185B2 (en) | Storage device selection for database partition replicas | |
| JP6538780B2 (en) | System-wide checkpoint avoidance for distributed database systems | |
| JP6522812B2 (en) | Fast Crash Recovery for Distributed Database Systems | |
| US9489443B1 (en) | Scheduling of splits and moves of database partitions | |
| US10558565B2 (en) | Garbage collection implementing erasure coding | |
| US7076553B2 (en) | Method and apparatus for real-time parallel delivery of segments of a large payload file | |
| US8874811B2 (en) | System and method for providing a flexible buffer management interface in a distributed data grid | |
| US10659225B2 (en) | Encrypting existing live unencrypted data using age-based garbage collection | |
| US10534776B2 (en) | Proximity grids for an in-memory data grid | |
| US9569459B1 (en) | Conditional writes at distributed storage services | |
| US20150277802A1 (en) | File storage using variable stripe sizes | |
| US9860317B1 (en) | Throughput throttling for distributed file storage services with varying connection characteristics | |
| EP3039844B1 (en) | System and method for supporting partition level journaling for synchronizing data in a distributed data grid | |
| US10712964B2 (en) | Pre-forking replicas for efficient scaling of a distributed data storage system | |
| CN112653730A (en) | User mode network file storage method and system | |
| Li et al. | Distributed metadata management scheme in cloud computing | |
| CN113449065A (en) | Data deduplication-oriented decentralized storage method and storage device | |
| US10223184B1 (en) | Individual write quorums for a log-structured distributed storage system | |
| CN109871365A (en) | A kind of distributed file system | |
| US11347647B2 (en) | Adaptive cache commit delay for write aggregation | |
| CN113032356A (en) | Cabin distributed file storage system and implementation method | |
| US20230135583A1 (en) | Distributed storage systems and methods to provide change tracking integrated with scalable databases | |
| US20240104081A1 (en) | Integrating change tracking of storage objects of a distributed object storage database into a distributed storage system | |
| CN117749809A (en) | Data sharing method and system in cloud computing environment under multi-core heterogeneous cluster |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |