Database operation method and fully encrypted database

Abstract

A database operation method and a fully encrypted database are disclosed. The method is executed by a read node in a one-write-many-read database and includes: receiving a read operation request from a user; determining that a write operation needs to be performed on a data key table in response to the read operation request; establishing a connection with a write node and forwarding the write operation; obtaining a data password table updated by the write node based on the write operation; and generating a read operation response based on the updated data password table and sending it to the user. Therefore, the present invention proposes a one-write-many-read solution suitable for a fully encrypted database to solve the problem of key information writing of a read node in a distributed database scenario. When a user read request processed by a read node involves key information writing, remote SQL technology can be used to achieve connection with a write node, so that the write node completes the actual writing of the key information, and the synchronization function of the database is used to achieve synchronization of the password table, thereby avoiding security risks and trust issues caused by external password table access.

Description

Technical Field

[0001] The present disclosure relates to the field of databases, and in particular to a database operation method and a fully encrypted database. Background Art

[0002] The fully encrypted database encrypts data in the entire link (from the client to the database instance, including network, memory and storage), and aims to eliminate the risk of data leakage at any time during the operation of the database, eliminate the possibility of the platform and operation and maintenance personnel to access plaintext data, and ensure that users have full ownership of their data in the cloud.

[0003] Since the content stored in the fully encrypted database is encrypted using a data key pair, how to store and update the data key information in the distributed database architecture is an important issue involving the security and operational efficiency of the fully encrypted database.

[0004] Therefore, an improved data key information processing scheme is needed. Summary of the invention

[0005] A technical problem to be solved by the present disclosure is to provide a database operation solution, which provides a one-write-multiple-reader database architecture for a fully encrypted database, and ensures timely update and synchronization of the key table by unifying all key table write operations involved on the read node to the write node.

[0006] According to the first aspect of the present disclosure, a database operation method is provided, wherein the database is a one-write-many-read fully encrypted database including a write node and multiple read nodes, and is characterized in that the method comprises: receiving a read operation request from a user; determining that a write operation needs to be performed on a data key table in response to the read operation request, wherein the data key table stores multiple data keys for encrypting data stored by the user in the database; establishing a connection with the write node and forwarding the write operation; obtaining the data password table updated by the write node based on the write operation; and generating a read operation response based on the updated data password table and sending the read operation response to the user.

[0007] Optionally, receiving a read operation request from a user includes: receiving a read operation request from the user forwarded by a proxy server connected to the one write node and multiple read nodes in the database, wherein the read operation request does not involve a write operation on encrypted user data stored in the database.

[0008] Optionally, determining that a write operation needs to be performed on the data key table in response to the read operation request includes: determining that the read operation involves a change to the data structure of the encrypted user data stored in the database; and determining the write operation on the data key table involved in the change.

[0009] Optionally, establishing a connection with the write node and forwarding the write operation includes: obtaining connection address information of the write node and identity authentication information required to connect to the write node; and establishing a connection with the write node based on the obtained connection address information and identity authentication information.

[0010] Optionally, obtaining the connection address information of the write node includes: obtaining the connection address information of the write node from an internal table of the cluster, the connection address information including IP address information and port number information of the write node.

[0011] Optionally, obtaining identity authentication information required for connecting to the write node includes: obtaining user name and password information of a role built into the database as the identity authentication information required for connecting to the write node.

[0012] Optionally, obtaining the user name and password information of the role within the database as the authentication information required to connect to the write node includes: obtaining the user name and password information of the WalRcv user of the database from the global variable WalRcv loaded when starting as one of the read nodes; using the user name and password information of the WalRcv user as the authentication information required to connect to the write node.

[0013] According to a second aspect of the present disclosure, a fully encrypted database is provided, comprising: a proxy server for obtaining requests from users and distributing them; and a write node for receiving and responding to write requests from users distributed by the proxy server; and a plurality of read nodes for receiving and responding to read requests from users distributed by the proxy server, and performing the operation method as described in the first aspect.

[0014] Optionally, the write node is further used for: in response to updating the data password table based on the write operation, synchronizing the updated data password table to the multiple read nodes.

[0015] According to a third aspect of the present disclosure, a computing device is provided, comprising: a processor; and a memory on which executable codes are stored, and when the executable codes are executed by the processor, the processor executes the method described in the first aspect above.

[0016] According to a fourth aspect of the present disclosure, a non-transitory machine-readable storage medium is provided, on which executable code is stored. When the executable code is executed by a processor of an electronic device, the processor executes the method described in the first aspect above.

[0017] Therefore, the present invention proposes a one-write-multiple-read solution applicable to a fully encrypted database, which solves the key information writing problem of the read node in a distributed database scenario. The solution can use remote SQL technology to realize the connection between the read node and the write node, and when the user read request processed by the read node involves the writing of key information, through the above connection with the write node, the write node completes the actual writing of the key information, and uses the synchronization function of the database to realize the synchronization of the password table, thereby avoiding the additional security risks and trust issues caused by the external password table access. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The above and other objects, features and advantages of the present disclosure will become more apparent through a more detailed description of exemplary embodiments of the present disclosure in conjunction with the accompanying drawings, wherein like reference numerals generally represent like components in the exemplary embodiments of the present disclosure.

[0019] Figure 1 An implementation example of data encryption in a fully encrypted database is shown.

[0020] Figure 2 An example of a database architecture for implementing the database operation method of the present invention is shown.

[0021] Figure 3 A schematic flow chart of a database operation method according to an embodiment of the present invention is shown.

[0022] Figure 4 An example of interaction is shown when a read operation on a read node involves a key table update.

[0023] Figure 5 A schematic diagram of the structure of a computing device that can be used to implement the above database operation method according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0024] The preferred embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the preferred embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0025] As the name implies, a "fully encrypted database" encrypts data throughout the entire link (from the client to the database instance, including network, memory, and storage), and can ensure that the data exists in ciphertext throughout the entire process of transmission, use, and storage, while still having complete database query capabilities. Due to full-link encryption, only necessary operations are performed in TEE (Trusted Execution Environment, which usually provides a secure execution environment isolated from the outside world to protect the code and data within it from being leaked or maliciously tampered with). Therefore, it can prevent the platform operation and maintenance personnel and all other people who may have access to the data from stealing plaintext data, ensuring that users have full ownership of their cloud data.

[0026] Figure 1 An implementation example of data encryption in a fully encrypted database is shown. As shown in the figure, in the database instance, the user master key (Master Encryption Key, MEK for short) and the user data key (Data Encryption Key, DEK) can be used to encrypt the columns in the database to protect the data security of sensitive data.

[0027] The user master key is used to encrypt the user data key. Figure 1 As shown, a data key DEK can be provided for each encrypted column in the database, and these data keys can be stored together in a data key table. No one except the data owner can obtain the user master key.

[0028] The user data key encrypts the selected database column. If multiple columns need to be encrypted, multiple DEKs can be used to encrypt them separately. The data key can be accessed and used by a third party with the user's authorization.

[0029] Therefore, for the data owner, since he has the user master key and data key, he can use the key to encrypt the data on the client side, execute various queries and transactions on the database, and see the query results decrypted by the key.

[0030] For database operation and maintenance personnel and any other relevant personnel of the cloud platform, since they cannot obtain the user master key and cannot access the user data key without authorization, they can maintain the database or use other functions of the database, but cannot view the plaintext of the encrypted column.

[0031] Therefore, a fully encrypted database can ensure:

[0032] (1) Authorized users can read and write data in the cloud database normally through existing protocols;

[0033] (2) Unauthorized users cannot obtain the plaintext data of protected users;

[0034] (3) During the process of providing data services, the cloud database cannot obtain the user's plaintext data.

[0035] Some existing encrypted databases use external key management systems to manage keys. In a distributed database scenario, each node of these encrypted databases independently requests key information from the external key management system. This solution requires that each node can access the external key management system, and users need to trust the key management system.

[0036] However, in actual applications, cloud databases usually deploy database instance nodes in an isolated network or an independent VPC (virtual private cloud) network for security reasons to avoid malicious attacks from the outside. Therefore, for a fully encrypted database, the introduction of an external key management system will increase the potential security threats of the system to a certain extent. Therefore, in the implementation of the present invention, the data key (DEK) used to encrypt the encrypted columns of the database as described above can be centrally stored in a data key table, which can be stored in the instance node of the database. This avoids the introduction of an external key management system, and the security of the data key table is guaranteed by the secure deployment and disposal of the database instance node itself, thereby ensuring the security of the encrypted data.

[0037] Furthermore, the present invention proposes a one-write-many-read solution applicable to a fully encrypted database to solve the problem of key information writing of a read node in a distributed database scenario. Figure 2 An example of a database architecture for implementing the database operation method of the present invention is shown. As shown, the database 200 includes a proxy server 210 (also referred to as a "master node", or "Proxy") and multiple nodes for storing user data. In the illustrated example, the multiple nodes include a write node (RW, also referred to as a "read-write node") 220 and multiple read nodes (RO, also referred to as "read-only nodes") 230. Here, the write node refers to a node that can not only perform a read (Read) operation on user data, but also a write (Write) operation. The read node only performs a read operation (ReadOnly) on user data. In other words, the database operation scheme of the present invention is applicable to a distributed cluster architecture, and a cluster version cluster includes a read-write node (RW) and multiple read-only nodes (RO) (for example, the N shown in the figure, usually more than 1, but less than, for example, 15). The read-write node processes read and write requests, and the read-only node only processes read requests. The Active-Active Failover method can be adopted between the master node and the read-only node, thereby providing a high-availability service for the database.

[0038] in other words, Figure 2 The architecture shown is "one write, multiple reads share the same copy of data". In other words, unlike the "one master, multiple slaves" technology in the prior art, where a master database writes, synchronizes data to multiple slave databases, and then uses these slave databases to complete read access, the one write, multiple read architecture of the present invention shares the same copy of data, without the need to establish multiple additional slave databases, so it is possible to quickly (for example, within a few minutes) add read-only nodes and start services.

[0039] In a database system that supports one write and multiple reads, only the write node (RW node) can perform read and write data operations, while the read node (RO node) can only read data, and the write function is completely prohibited. Figure 2 In the distributed database system shown, the master node 210 receives a request from a user (i.e., an SQL statement from the user), and forwards the SQL that requires a write operation to the RW node 220 according to the specific type of SQL, and forwards the read operation to any node, which can be RO1-RO N Any node in the database or on a RW node. In the design of a fully encrypted database system, a data key table located in the database is used to manage and maintain key-related information. After establishing a SQL connection, before using the full encryption function, the user needs to securely distribute the user key-related information to the trusted environment of the target node. The trusted environment, namely TEE (Trusted Execution Environment), is usually provided by a secure execution environment isolated from the outside world to protect the code and data therein from being leaked or maliciously tampered with, and write the internally generated or updated key information into the database key table of the corresponding node and synchronize it to other nodes. When the target node is a read node, the key table cannot be written because it does not have write permission.

[0040] To this end, the present invention proposes a database operation method based on a one-write-many-read database structure, through which the problem of key information writing of a read node in a distributed database scenario is solved.

[0041] Figure 3 The schematic flow chart of the database operation method according to one embodiment of the present invention is shown. The database applicable to the method is a one-write-many-reader fully encrypted database including a write node and multiple read nodes, for example, Figure 2 As shown, a one-write-multiple-reader fully encrypted database includes a write node 220 and multiple read nodes 230. Each write node and read node can store the same user data, for example, multiple data columns encrypted by multiple data keys, and each node includes a data key table for storing key-related information. Figure 3 The method shown can be used by a read node, such as Figure 2 Any of the read nodes 230 shown executes.

[0042] In step S310, the read node receives a read operation request from the user. In the above distributed system, the user request that the read node can receive is not a request directly from the user, but a read operation request from the user forwarded by a proxy server connected to the one write node and multiple read nodes in the database. The proxy server will recognize the SQL (Structured Query Language) of the user's read operation request, and only when the operation included in the SQL statement does not involve a write operation to the encrypted user data stored in the database, will the operation be identified as a read operation and assigned to a read node.

[0043] Subsequently, in step S320, the read node determines that a write operation needs to be performed on a data key table in response to the read operation request. Here, the data key table stores multiple data keys for encrypting data stored by the user in the database. In some cases, although the SQL statement input by the user does not involve a write operation on the user data, the above-mentioned read operation may involve a change in the data structure of the encrypted user data stored in the database, in which case the read node can determine the write operation on the data key table involved in the change.

[0044] For example, the current data key table records the key information for data columns C0 to C1. M-1 M data keys, namely DEK0~DEK M-1 When a user generates new data locally (for example, storing it in the database as encrypted data column C M When the data in the M+1th column of the data column needs to be uploaded to the database, the user needs a new data key to M At this time, the user's request to the database may be to read the encrypted data column C M Data key DEK M Since the operation included in the request is to read the encrypted data column C M Data key DEK M Therefore, the proxy server identifies the request as a read request and distributes it to a read node. When the read node receives the request, it tries to find the data key table on the node and finds that the data key DEK is not recorded in the current data key table. M (Only M existing data keys are recorded, namely DEK0~DEK M-1 ), at this time, since the read node does not have write permission, it cannot write to the key table, so the write node needs to participate in the data key DEK that has not yet been recorded. M Creation.

[0045] If it is determined that the current read operation needs to write to the key table, in step S330, the read node establishes a connection with the write node and forwards the write operation. The establishment of the above connection is performed in the background, and the read node can directly send the determined operation information of writing to the key table to the write node.

[0046] The write node can then update the data password table based on the write operation. For example, the write node can create a new data key DEK according to the user request as described above. M Then, the read node can obtain the data password table updated by the write node based on the write operation in step S340. For example, the write node can update the data password table (that is, including the newly created data key DEK M In other words, the updated data password table will not only be sent to the read node that establishes a connection with the write node and forwards the write operation, but also to other read nodes.

[0047] In step S350, the read node that obtains the read request involving the write operation of the password table can generate a read operation response based on the updated data password table and send the read operation response to the user. M Sent to the user making the request.

[0048] Therefore, the key table update request is forwarded by the read node, the write node updates the key table and synchronizes it, and the database's own functions are used to achieve reliable synchronization update and storage services.

[0049] Therefore, the write operations in all key management operations in the current one-write-many-read architecture are executed on the WR node, and the write operations on the RO node are forwarded to the WR node for execution, and then synchronized to all RO nodes through the kernel. Figure 4 The example of interaction when the read operation on the read node involves the key table update is shown. As shown in the figure, the database 400 also includes a proxy server 410, a write node 420 and multiple read nodes 430. The proxy server 410 assigns a read request to a read node (RO i ), the RO i The node determines that the current reader is involved in a key table update operation (including key update and insertion).

[0050] Specifically, the master node (i.e., the proxy server 410 in the figure) forwards the SQL to the RO node 430, and the RO node 430 processes the data. When the key table needs to be written, the following steps are performed:

[0051] 1. Get the connection information of the RW node;

[0052] 2. Establish a background connection from the RO node to the RW node;

[0053] 3. Forward (redirect) the write operation (Insert / Update) of the key table to the RW node through the background connection;

[0054] 4. The RW node performs a write operation on the key table;

[0055] 5. After writing, the distributed system’s built-in synchronization function will synchronize the updated information to all nodes.

[0056] As an expansion capability, single write and multiple reads rely on the underlying database cluster to have single write and multiple reads capabilities. At the same time, considering the maintenance cost of multi-version products, the design can try to avoid introducing inconsistencies with the stand-alone database, or can automatically identify stand-alone / single write and multiple reads, thereby avoiding the need to maintain multiple different database versions.

[0057] Establish a background connection on the database server. The mainstream functional components (for example, DBLINK and FDW) allow the execution of Remote SQL (remote structured query) and are standard components of the database. Therefore, from the perspective of encrypted database, using DBLINK and FDW has good compatibility.

[0058] However, since FDW relies on establishing a one-way remote server and mapping table, once the master-slave switch occurs, the existing configuration will become invalid; and the insert operation on the mapping table cannot be reversely synchronized to the source table by the read node, so FDW is not suitable for the one-write-multiple-read scenario in the present invention. For this reason, DBLINK can be used as the underlying Remote SQL communication solution.

[0059] When using the Remote SQL communication solution, the core problem to be solved is to obtain the connection information for establishing a background connection to the RW node. In other words, in step S330 above, the connection with the write node cannot be established directly, and the connection information of the write node needs to be obtained, and the identity needs to be verified with the write node.

[0060] To this end, step S330 of establishing a connection with the write node and forwarding the write operation may include: obtaining connection address information of the write node and identity authentication information required to connect to the write node; and establishing a connection with the write node based on the obtained connection address information and identity authentication information.

[0061] Further, obtaining the connection address information of the write node may include: obtaining the connection address information of the write node from an internal table of the cluster, the connection address information including the IP address information and port number information of the write node. And obtaining the identity authentication information required to connect to the write node may include: obtaining the user name and password information of the role in the database as the identity authentication information required to connect to the write node.

[0062] In other words, when using the Remote SQL communication solution, the information required to establish a background connection with the RW node includes at least:

[0063] host: WR node IP

[0064] port: WR node port number

[0065] User: the target user name to connect to

[0066] ·password: connection target password

[0067] dbname: the target database on WR, which is the current database in this solution

[0068] As a service system, the write operation forwarding function in the design should not require users to interactively provide the required connection information, but should complete the above process without users noticing.

[0069] Since the distributed cluster will configure the RW node information when establishing each RO node in the cluster, the RO node can obtain the host and port information of the WR node through the internal table / view (if the RO node has been connected to the cluster), thereby achieving the acquisition of the connection address information of the write node as above. In the encrypted database write-one-read-many scenario, dbname is the current database name.

[0070] As for the username and key, out of consideration for user password protection, the password information maintained within the database system will go through two layers of protection: 1) salted hashing (i.e., adding random numbers to the hash changes), and 2) desensitization. Therefore, the plaintext password of the database user cannot be directly obtained in the server backend. In other words, the plaintext password of the user who makes a read request on the client cannot be obtained. To this end, the username and password information of the role that comes with the database can be obtained as the authentication information required to connect to the write node. Specifically, the username and password information of the WalRcv user of the database can be obtained from the global variable WalRcv loaded when one of the read nodes is started; and the username and password information of the WalRcv user can be used as the authentication information required to connect to the write node.

[0071] In other words, in order to solve the problem that the read node cannot obtain the user's plain text password when verifying its identity with the write node, the present invention cleverly reuses the built-in Replication role in the database system. In the database system, the Replication role can normally access the target library and execute the key management function, and the password of the role is statically configured in the configuration file by the database administrator. For example, in a cluster with one write and multiple reads, there is a special user (recorded as the WalRcv user) for pulling synchronization logs and having the Replication role permissions. The user name and password information of the WalRcv user can be given in the form of configuration parameters in the postgresql.conf or recovery.conf file, and loaded into the global variable WalRcv in the global shared memory when the node starts, so that the read node can obtain the complete connection information of the WalRcv user by locally accessing the global variable WalRcv in the service process memory.

[0072] Therefore, in the plugin source code, the connection with the write node can be achieved by the following operations:

[0073] 1. Get the authentication information required for the connection from the global variable WalRcv

[0074] 2. Prepare the connection address information required by DBLINK

[0075] 3. Initiate a dblink function call through the SPI function, and thereby connect to the write node.

[0076] Therefore, the present invention stores key-related information in a key table inside the database, does not rely on any external key management system, that is, avoids access to an external key management system, and the user does not need to trust the key management system, and the design inherently avoids the shortcomings of the prior art. In addition, by adopting the method of a key table inside the database, the key information is treated as ordinary data, and the existing functions such as backup management of the database can be utilized to provide a stable and reliable storage backup service.

[0077] The present invention can also be implemented as a fully encrypted database. Figure 2 and Figure 4 As shown, it includes a proxy server, a write node and multiple read nodes.

[0078] The proxy server is used to obtain requests from users and distribute them. The write node is used to receive write requests from users distributed by the proxy server and respond. Multiple read nodes are used to receive read requests from users distributed by the proxy server and respond, and execute the above based on Figure 3 The described method of operation.

[0079] When the write node updates the data password table based on the write operation, it can also be used to: in response to updating the data password table based on the write operation, synchronize the updated data password table to the multiple read nodes.

[0080] Figure 5 A schematic diagram of the structure of a computing device that can be used to implement the above database operation method according to an embodiment of the present invention is shown.

[0081] See also Figure 5 , the computing device 500 includes a memory 510 and a processor 520 .

[0082] The processor 520 may be a multi-core processor or may include multiple processors. In some embodiments, the processor 520 may include a general-purpose main processor and one or more special coprocessors, such as a graphics processing unit (GPU), a digital signal processor (DSP), etc. In some embodiments, the processor 520 may be implemented using a customized circuit, such as an application-specific integrated circuit (ASIC) or a field programmable gate array (FPGA).

[0083] The memory 510 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. Among them, ROM can store static data or instructions required by the processor 520 or other modules of the computer. The permanent storage device may be a readable and writable storage device. The permanent storage device may be a non-volatile storage device that does not lose the stored instructions and data even after the computer is powered off. In some embodiments, the permanent storage device uses a large-capacity storage device (such as a magnetic or optical disk, flash memory) as a permanent storage device. In some other embodiments, the permanent storage device may be a removable storage device (such as a floppy disk, optical drive). The system memory may be a readable and writable storage device or a volatile readable and writable storage device, such as a dynamic random access memory. The system memory may store some or all instructions and data required by the processor at runtime. In addition, the memory 510 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, the memory 510 may include a readable and / or writable removable storage device, such as a laser disc (CD), a read-only digital versatile disc (e.g., DVD-ROM, double-layer DVD-ROM), a read-only Blu-ray disc, an ultra-density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. The computer-readable storage medium does not include carrier waves and transient electronic signals transmitted wirelessly or wired.

[0084] The memory 510 stores executable codes, and when the executable codes are processed by the processor 520 , the processor 520 can execute the database operation method mentioned above.

[0085] The database operation method according to the present invention has been described in detail above with reference to the accompanying drawings. The present invention proposes a one-write-many-read solution suitable for a fully encrypted database to solve the problem of writing key information of a read node in a distributed database scenario. The method proposed in the present invention can establish a background connection without the user noticing, and is suitable for fully encrypted databases based on different TEE enclaves (security zones).

[0086] In addition, the method according to the present invention may also be implemented as a computer program or a computer program product, which includes computer program code instructions for executing the above steps defined in the above method of the present invention.

[0087] Alternatively, the present invention may also be implemented as a non-temporary machine-readable storage medium (or computer-readable storage medium, or machine-readable storage medium) on which executable code (or computer program, or computer instruction code) is stored. When the executable code (or computer program, or computer instruction code) is executed by a processor of an electronic device (or computing device, server, etc.), the processor executes the various steps of the above-mentioned method according to the present invention.

[0088] Those skilled in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or a combination of both.

[0089] The flow chart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system and method according to multiple embodiments of the present invention. In this regard, each square box in the flow chart or block diagram can represent a part of a module, program segment or code, and the part of the module, program segment or code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous square boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0090] The embodiments of the present invention have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A database operation method, wherein the database is a one-write-many-reader fully encrypted database including a write node and multiple read nodes, characterized in that: The method comprises: Receive a read operation request from a user; Determining that a write operation needs to be performed on a data key table in response to the read operation request, wherein the data key table stores a plurality of data keys for encrypting data stored by the user in the database; Establishing a connection with the write node and forwarding the write operation; Acquire the data key table updated by the write node based on the write operation, and synchronize the updated data key table by the write node to all read nodes; and Based on the updated data key table, a read operation response is generated and sent to the user.

2. The method of claim 1, wherein: Receiving a read operation request from a user includes: A read operation request from a user forwarded by a proxy server connected to the one write node and the multiple read nodes in the database is received, wherein the read operation request does not involve a write operation on encrypted user data stored in the database.

3. The method of claim 2, wherein: Determining that a write operation needs to be performed on the data key table in response to the read operation request includes: determining that the read operation involves a change to a data structure of encrypted user data stored in the database; and A write operation to the data key table involved in the change is determined.

4. The method of claim 1, wherein: Establishing a connection with the write node and forwarding the write operation includes: Acquire the connection address information of the write node and the identity authentication information required to connect to the write node; and Based on the acquired connection address information and the identity authentication information, a connection is established with the write node.

5. The method of claim 4, wherein: Obtaining the connection address information of the write node includes: The connection address information of the write node is obtained from an internal table of the cluster, where the connection address information includes the IP address information and port number information of the write node.

6. The method of claim 4, wherein: Obtaining the authentication information required to connect to the write node includes: The user name and password information of the role in the database are obtained as the identity authentication information required to connect to the write node.

7. The method of claim 6, wherein: Obtaining the user name and password of the role in the database as the authentication information required to connect to the write node includes: Obtain the user name and password information of the WalRcv user of the database from the global variable WalRcv loaded when starting as one of the reading nodes; The user name and password information of the WalRcv user is used as the authentication information required to connect to the write node.

8. A fully encrypted database system, comprising: Proxy server, used to obtain requests from users and distribute them; as well as The write node is used to receive and respond to write requests from users distributed by the proxy server; as well as A plurality of read nodes are used to receive and respond to read requests from users distributed by a proxy server, and to execute an operation method as described in any one of claims 1 to 7.

9. The database system according to claim 8, wherein: The write node is also used to: In response to updating the data key table based on the write operation, the updated data key table is synchronized to the plurality of read nodes.

10. A computing device comprising: processor; as well as A memory having executable codes stored thereon, which, when executed by the processor, causes the processor to execute the method according to any one of claims 1 to 7.

11. A non-transitory machine-readable storage medium having executable codes stored thereon, which, when executed by a processor of an electronic device, causes the processor to execute the method according to any one of claims 1 to 7.

Images