CN114722115A - 数据库操作方法和全加密数据库 - Google Patents

Abstract

公开了一种数据库操作方法和全加密数据库。该方法由一写多读数据库中的读节点执行并且包括：接收来自用户的读操作请求；判定响应读操作请求需要针对数据密钥表进行写操作；与写节点建立连接并转发写操作；获取写节点基于写操作更新的数据密码表；以及基于更新的数据密码表，生成读操作响应并向所述用户发送。由此，本发明提出一种适用于全加密数据库的一写多读方案，解决在分布式数据库场景下，读节点的密钥信息写入问题。在读节点处理的用户读请求涉及密钥信息写入时，可以利用远程SQL技术实现与写节点的连接，使得写节点完成对密钥信息的实际写入，并利用数据库的同步功能实现密码表的同步，从而避免外部密码表访问带来的安全隐患与信任问题。

Description

数据库操作方法和全加密数据库

技术领域

本公开涉及一种数据库领域，尤其涉及一种数据库操作方法和全加密数据库。

背景技术

全加密数据库在全链路(从客户端至数据库实例，含网络、内存和存储)中对数据进行加密，并且旨在消除数据库在运行中任何时刻的数据泄露隐患，杜绝平台以及运维人员接触到明文数据的可能，保证用户对其云上数据的完全所有权。

由于全加密数据库中存储内容的采用数据密钥对进行加密，因此在分布式数据库的架构中，数据密钥信息如何存储和更新是涉及全加密数据库安全性和操作效率的一个重要问题。

因此，需要一种改进的数据密钥信息处理方案。

发明内容

本公开要解决的一个技术问题是提供一种数据库操作方案，该方案针对全加密数据库，提供一写多读数据库架构，并通过将读节点上涉及的密钥表写入操作都统一到写节点上进行来保证对密钥表的及时更新和同步。

根据本公开的第一个方面，提供了一种数据库操作方法，所述数据库是包括一个写节点和多个读节点的一写多读全加密数据库，其特征在于，所述方法包括：接收来自用户的读操作请求；定响应所述读操作请求需要针对数据密钥表进行写操作，其中，所述数据密钥表存储为所述用户在所述数据库中存储数据进行加密的多个数据密钥；与所述写节点建立连接并转发所述写操作；获取所述写节点基于所述写操作更新的所述数据密码表；以及基于更新的所述数据密码表，生成读操作响应并向所述用户发送所述读操作响应。

可选地，接收来自用户的读操作请求包括：接收所述数据库中与所述一个写节点和多个读节点相连的代理服务器转发的来自用户的读操作请求，所述读操作请求不涉及对数据库中存储的加密的用户数据的写操作。

可选地，判定响应所述读操作请求需要针对数据密钥表进行写操作包括：判定所述读操作涉及对所述数据库中存储的加密的用户数据的数据结构的改变；以及确定所述改变涉及的针对所述数据密钥表的写操作。

可选地，与所述写节点建立连接并转发所述写操作包括：获取所述写节点的连接地址信息以及连接所述写节点所需的身份验证信息；以及基于获取的所述连接地址信息和所述身份验证信息，与所述写节点建立连接。

可选地，获取所述写节点的连接地址信息包括：从所在集群内部表获取所述写节点的连接地址信息，所述连接地址信息包括上述写节点的IP地址信息和端口号信息。

可选地，获取连接所述写节点所需的身份验证信息包括：获取所述数据库内部自带角色的用户名和密码信息作为连接所述写节点所需的身份验证信息。

可选地，获取所述数据库内部自带角色的用户名和密码信作为连接所述写节点所需的身份验证信息包括：从作为读节点之一启动时加载的全局变量WalRcv中获取所述数据库的WalRcv用户的用户名和密码信息；使用所述WalRcv用户的用户名和密码信息作为连接所述写节点所需的身份验证信息。

根据本公开的第二个方面，提供了一种全加密数据库，包括：代理服务器，用于获取来自用户的请求，并进行分发；以及写节点，用于接收代理服务器分发的来自用户的写请求并进行响应；以及多个读节点，用于接收代理服务器分发的来自用户的读请求并进行响应，并且执行如第一方面所述的操作方法。

可选地，所述写节点还用于：响应于基于所述写操作更新所述数据密码表，将更新的所述数据密码表同步至所述多个读节点。

根据本公开的第三个方面，提供了一种计算设备，包括：处理器；以及存储器，其上存储有可执行代码，当可执行代码被处理器执行时，使处理器执行如上述第一方面所述的方法。

根据本公开的第四个方面，提供了一种非暂时性机器可读存储介质，其上存储有可执行代码，当可执行代码被电子设备的处理器执行时，使处理器执行如上述第一方面所述的方法。

由此，本发明提出一种适用于全加密数据库的一写多读方案，解决在分布式数据库场景下，读节点的密钥信息写入问题。该方案可以利用远程SQL技术实现读节点与写节点的连接，并在读节点处理的用户读请求涉及密钥信息写入时，通过与写节点的上述连接，使得写节点完成对密钥信息的实际写入，并利用数据库的同步功能实现密码表的同步，从而避免外部密码表访问带来的额外的安全隐患与信任问题。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1示出了全加密数据库中进行数据加密的一个实现例。

图2示出了用于实现本发明的数据库操作方法的数据库架构的一个例子。

图3示出了根据本发明一个实施例的数据库操作方法的示意性流程图。

图4示出了在读节点上的读操作涉及密钥表更新时的交互例。

图5示出了根据本发明一实施例可用于实现上述数据库操作方法的计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

“全加密数据库”顾名思义，是在全链路(从客户端至数据库实例，包含网络、内存和存储)中对数据进行加密，并且能够在保证数据在传输、使用和存储全程以密文形式存在的同时，仍然具备完整的数据库查询能力。由于全链路加密，仅在TEE(Trusted ExecutionEnvironment，可信执行环境，该执行环境通常通过提供与外界隔离的安全执行环境，保护其内代码和数据不会被泄露或恶意篡改)执行必要的操作，因此能够杜绝平台运维人员以及所有其他有可能接触到数据的人员盗取明文数据的可能，保证用户对其云上数据的完全所有权。

图1示出了全加密数据库中进行数据加密的一个实现例。如图所示，在数据库的实例中，可以使用用户主密钥(Master Encryption Key，简称MEK)和用户数据密钥(DataEncryption Key，DEK)来对数据库中的列进行加密，保护敏感数据的数据安全。

用户主密钥用于对用户数据密钥进行加密，如图1所示，可以为数据库中每个加密列配备一个数据密钥DEK，并且可以将这些数据密钥共同存储在一个数据密钥表中。除数据所有者外的任何人员无法获得用户主密钥。

用户数据密钥对选中的数据库列进行加密。如有多个列需要被加密保护，可以使用多个DEK分别对它们进行加密。数据密钥可以在用户授权的情况下被第三方访问使用。

由此，对于数据所有者而言，由于拥有用户主密钥和数据密钥，因此可以在客户端一侧使用密钥对数据进行加密，可对数据库执行各类查询和事务，可以看到经过密钥解密的查询结果。

对于数据库运维人员、云平台的任何其他相关人员而言，由于无法获得用户主密钥，未经授权无法访问用户数据密钥，因此可对数据库进行维护或使用数据库的其它功能，但无法查看加密列的明文。

由此，全加密数据库可以确保：

(1)授权用户可以通过现有协议正常读写云端数据库内的数据；

(2)未授权用户无法获得被保护用户的明文数据；

(3)云端数据库在提供数据服务的过程中，全程无法获得用户的明文数据。

现有的一些加密数据库会使用外部的密钥管理系统来管理密钥。在数据库的分布式场景下，这些加密数据库的每个节点都独立向外部的密钥管理系统请求密钥信息。这种方案需要每个节点都可以访问到外部密钥管理系统，并且用户需要额外信任该密钥管理系统。

然而在实际应用中，云数据库出于安全考虑，通常会将数据库实例节点部署在隔离网络或者独立的VPC(虚拟私有云)网络下，以避免来自外部的恶意攻击。因此，对于全加密数据库而言，引入外部的密钥管理系统，反而会在一定程度上增加系统的潜在安全威胁。因此，在本发明的实现中，如上所述用于为数据库的加密列加密的数据密钥(DEK)可以被集中保存在数据密钥表中，该数据密钥表则可被保存在数据库的实例节点中。由此避免引入外部的密钥管理系统，通过数据库实例节点自身的安全部署和处置，保证数据密钥表的安全，从而保证加密数据的安全。

进一步地，本发明提出一种适用于全加密数据库的一写多读方案来解决在分布式数据库场景下，读节点的密钥信息写入问题。图2示出了用于实现本发明的数据库操作方法的数据库架构的一个例子。如图所示，数据库200包括代理服务器210(也可称为“主节点”，或者“Proxy”)以及用于存储用户数据的多个节点。在图示的例子中，多个节点中包括一个写节点(RW，也可称为“读写节点”)220和多个读节点(RO，也可称为“只读节点”)230。在此，写节点指的是不仅能够针对用户数据进行读(Read)操作，也能进行写(Write)操作的节点。读节点仅对用户数据进行读操作(ReadOnly)。换句话说，本发明的数据库操作方案适用于分布式集群架构，一个集群版集群包含一个读写节点(RW)和多个只读节点(RO)(例如，图示的N个，通常多于1个，但小于例如15个)。读写节点处理读写请求，只读节点仅处理读请求。主节点和只读节点之间可以采用Active-Active的Failover方式，由此提供数据库的高可用服务。

换句话说，图2所示的架构是“一写多读共享同一份数据”。换句话说，不同于现有技术中一个主库写，将数据同步给多个从库，再使用这些从库完成读的访问的“一主多从”的技术，本发明的一写多读架构是共享同一个数据副本，无需额外建立多个从库，因此能够快速(例如，几分钟内)添加只读节点并启动服务。

在支持一写多读的数据库系统中，只有写节点(RW节点)能够进行读和写数据操作，而读节点(RO节点)只能读数据，写功能被完全禁止。因此在图2所示的分布式数据库系统中，主节点210接收来自用户的请求(即，来自用户的SQL语句)，并且根据SQL的具体类型，将需要写操作的SQL转发到RW节点220上，而读操作转发到任意一个节点上，可以是RO₁-RO_N中的任何一个节点或者是RW节点上。在全加密数据库系统设计中，使用位于数据库内的数据密钥表来用于管理和维护密钥相关信息。用户在建立一个SQL连接后，使用全加密功能前，需要将用户密钥相关信息安全的分发到目标节点的可信环境内，该可信环境，即TEE(Trusted Execution Environment，可信执行环境)，是通常通过提供与外界隔离的安全执行环境，保护其内代码和数据不会被泄露或恶意篡改，并且将内部生成或更新的密钥信息写入到对应节点的数据库密钥表中，并同步到其他节点上。当目标节点为读节点时，由于不具备写权限，不能对密钥表进行写入。

为此，本发明提出了一种基于一写多读数据库结构的数据库操作方法，通过该方法来解决在分布式数据库场景下，读节点的密钥信息写入问题。

图3示出了根据本发明一个实施例的数据库操作方法的示意性流程图。适用于该方法的数据库是包括一个写节点和多个读节点的一写多读全加密数据库，例如，如图2所示，包括一个写节点220和多个读节点230的一写多读全加密数据库。每个写节点和读节点上可以存储有相同的用户数据，例如，被多个数据密钥加密的多个数据列，并且每个节点上都包括用于存储密钥相关信息的数据密钥表。图3所示的方法可由读节点，例如图2所示的任一读节点230执行。

在步骤S310，读节点接收来自用户的读操作请求。在如上的分布式系统中，读节点能够接收到的用户请求，并非是直接来自用户的请求，而是接收所述数据库中与所述一个写节点和多个读节点相连的代理服务器转发的来自用户的读操作请求。所述代理服务器会识别用户读操作请求的SQL(结构化查询语言)，并且只有当该SQL语句中所包括的操作不涉及对数据库中存储的加密的用户数据的写操作时，才会将该操作认定为读操作并分配给一个读节点。

随后，在步骤S320，该读节点判定响应所述读操作请求需要针对数据密钥表进行写操作。在此，数据密钥表即存储为所述用户在所述数据库中存储数据进行加密的多个数据密钥。在有些情况下，虽然用户输入的SQL语句不涉及对用户数据的写操作，但上述读操作可能会涉及对所述数据库中存储的加密的用户数据的数据结构的改变，此时读节点可以确定所述改变涉及的针对所述数据密钥表的写操作。

例如，当前的数据密钥表例如记载了用于数据列C₀到数据列C_M-1的M个数据密钥，即DEK₀～DEK_M-1。在用户在本地生成了新的数据(例如，将在数据库中存储为加密数据列C_M的第M+1列的数据)并需要上传数据库时，用户需要新的数据密钥来为数据列C_M进行加密。此时，用户向数据库发出的请求可以是读取对应于加密数据列C_M的数据密钥DEK_M。由于该请求中包括的操作是读取对应于加密数据列C_M的数据密钥DEK_M，因此代理服务器将该请求识别为读请求并将其分发给一个读节点。而当该读节点接收到该请求时，会尝试查找该节点上的数据密钥表，并且发现当前的数据密钥表上并没有记载数据密钥DEK_M(而仅仅记载了M个现有数据密钥，即DEK₀～DEK_M-1)，此时，由于读节点不具备写权限，不能对密钥表进行写入，因此需要写节点参与对尚未记载的数据密钥DEK_M的创建。

在判定当前读操作需要对密钥表进行写入的情况下，在步骤S330，读节点与写节点建立连接并转发所述写操作。上述连接的建立是在后台进行的，并且读节点可以直接将判定出的对密钥表进行写入的操作信息发送给写节点。

写节点于是可以基于所述写操作来更新数据密码表。例如，写节点可以根据如上所述的用户请求创建新的数据密钥DEK_M。于是，读节点可以在步骤S340获取写节点基于所述写操作更新的所述数据密码表。例如，写节点可以将更新的数据密码表(即，包括新创建的数据密钥DEK_M的数据密码表)同步给所有的读节点。换句话说，更新的数据密码表不仅会被发送给与写节点建立连接并转发所述写操作的读节点，还会发送给其他的读节点。

在步骤S350，获取到如上涉及密码表写操作的读请求的读节点就可以基于更新的所述数据密码表，生成读操作响应并向所述用户发送所述读操作响应。例如，在如上的例子中，将新创建的数据密钥DEK_M发送给进行请求的用户。

由此，通过读节点转发密钥表更新请求，写节点更新密钥表并同步，利用数据库自带功能实现可靠同步更新和存储服务。

由此，当前一写多读架构中所有密钥管理操作中的写操作，都在WR节点上执行，RO节点上的写操作，转发到WR节点执行，再经由内核同步到所有RO节点上。图4示出了在读节点上的读操作涉及密钥表更新时的交互例。如图所示，数据库400同样包括代理服务器410、一个写节点420和多个读节点430。代理服务器410将一个读请求分配给一个读节点(RO_i)，该RO_i节点判定当前读取器涉及密钥表更新操作(包括密钥的更新和插入)。

具体地，主节点(即图中代理服务器410)将SQL转发到RO节点430，RO节点430进行数据处理，当需要写入密钥表时，执行以下步骤：

1.获取RW节点的连接信息；

2.建立一个从RO节点到RW节点的后台连接；

3.将对密钥表的写操作(Insert/Update)通过后台连接转发(重定向)到RW节点；

4.由RW节点执行对密钥表的写操作；

5.写入后，将由分布式系统自带的同步功能，将更新信息同步到所有的节点上。

一写多读作为扩展能力，依赖于底层数据库集群已具备一写多读能力。同时考虑到多版本形态产品的维护成本，在设计上可以尽量避免引入与单机版数据库的不一致，或者能够自动识别单机/一写多读，从而避免维护多个不同的数据库版本。

在数据库服务端建立后台连接，主流的功能组件中(例如，DBLINK和FDW)都允许执行Remote SQL(远程结构化查询)，并且都是数据库的标准组件，因此从加密数据库角度，使用DBLINK和FDW具备很好的兼容性。

然而，由于FDW依赖于建立单向的远程服务器和映射表，一旦发生主备切换会导致已有配置失效；并且在映射表上的插入操作无法被读节点执行反向同步到源表，因此FDW不适用本发明中的一写多读场景。为此，可以使用DBLINK作为底层的Remote SQL通信方案。

使用Remote SQL通信方案，核心需要解决的问题是获取建立到RW节点的后台连接的连接信息。换句话说，在如上步骤S330中，与写节点的连接通常是无法直接建立的，需要获取写节点的连接信息，也需要向写节点验证身份。

为此，与所述写节点建立连接并转发所述写操作的步骤S330可以包括：获取所述写节点的连接地址信息以及连接所述写节点所需的身份验证信息；以及基于获取的所述连接地址信息和所述身份验证信息，与所述写节点建立连接。

进一步地，获取所述写节点的连接地址信息可以包括：从所在集群内部表获取所述写节点的连接地址信息，所述连接地址信息包括上述写节点的IP地址信息和端口号信息。而获取连接所述写节点所需的身份验证信息则可包括：获取所述数据库内部自带角色的用户名和密码信息作为连接所述写节点所需的身份验证信息。

换句话说，使用Remote SQL通信方案时，与RW节点建立后台连接所需要的信息至少包括：

·host：WR节点IP

·port：WR节点端口号

·user：连接目标用户名

·password：连接目标口令

·dbname：WR上目标库，在本方案中即为当前库

作为一个服务系统，设计中的写操作转发功能不应该要求用户交互式的提供以上所需的连接信息，而应该是用户无感的完成以上过程。

由于分布式集群会在建立集群每个RO节点时配置好RW节点的信息，RO节点可以通过内部表/视图插叙获得(如果RO节点已连入集群)WR节点的host和port信息，由此实现如上写节点的连接地址信息的获取。在加密数据库一写多读场景下，dbname即为当前库名。

而对于用户名和密钥，出于对用户密码保护的考虑，数据库系统内部维护的密码信息会经过1)加盐Hash(即，加入随机数的哈希变化)，以及2)脱敏这两层保护，因此在服务端后台无法直接拿到数据库用户的明文密码。即，无法拿到在客户端进行读请求的用户自身的明文密码。为此，可以获取所述数据库内部自带角色的用户名和密码信作为连接所述写节点所需的身份验证信息。具体地，可以从作为读节点之一启动时加载的全局变量WalRcv中获取所述数据库的WalRcv用户的用户名和密码信息；以及使用所述WalRcv用户的用户名和密码信息作为连接所述写节点所需的身份验证信息。

换句话说，为了解决读节点在向写节点验证自身身份时无法获知用户明文密码这个问题，本发明巧妙复用了数据库系统中的自带的Replication(复制)角色。在数据库系统中，Replication角色能够正常访问目标库并执行密钥管理函数，且该角色的密码由数据库管理员静态的在配置文件中进行配置。例如在一写多读的集群中，存在一个特殊的用户(记为WalRcv用户)，用于拉取同步日志，且具备Replication角色权限。可以将WalRcv用户的用户名和密码信息，以配置参数的方式，在postgresql.conf或者recovery.conf文件中明文给出，并且节点启动时加载到全局共享内存的全局变量WalRcv中，因此可以在服务进程内存中，读节点可以通过本地访问全局变量WalRcv的方式获得WalRcv用户的完整连接信息。

由此，在插件源码中可以通过如下操作实现与写节点的连接：

1.从全局变量WalRcv中拿到连接所需的身份验证信息

2.准备好DBLINK需要的连接地址信息

3.通过SPI函数发起dblink函数调用，并由此实现与写节点的连接。

由此，本发明通过将密钥相关信息存储在数据库内部的密钥表中，不依赖于任何外部的密钥管理系统，即避免访问到外部密钥管理系统，并且用户也无需额外信任该密钥管理系统，在设计上天生的避免了现有技术中的缺点。此外，采用数据库内部密钥表的方式，将密钥信息作为普通数据一般，能够利用数据库的备份管理等自带已有功能，提供稳定可靠的存储备份服务。

本发明还可以实现为一种全加密数据库。该全加密数据库如图2和图4所示，包括代理服务器、写节点和多个读节点。

代理服务器用于获取来自用户的请求，并进行分发。写节点用于接收代理服务器分发的来自用户的写请求并进行响应。多个读节点，用于接收代理服务器分发的来自用户的读请求并进行响应，并且执行如上基于图3所述的操作方法。

在写节点基于所述写操作更新所述数据密码表时，还可用于：响应于基于所述写操作更新所述数据密码表，将更新的所述数据密码表同步至所述多个读节点。

图5示出了根据本发明一实施例可用于实现上述数据库操作方法的计算设备的结构示意图。

参见图5，计算设备500包括存储器510和处理器520。

处理器520可以是一个多核的处理器，也可以包含多个处理器。在一些实施例中，处理器520可以包含一个通用的主处理器以及一个或多个特殊的协处理器，例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中，处理器520可以使用定制的电路实现，例如特定用途集成电路(ASIC，Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA，Field Programmable Gate Arrays)。

存储器510可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器520或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器510可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器510可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器510上存储有可执行代码，当可执行代码被处理器520处理时，可以使处理器520执行上文述及的数据库操作方法。

上文中已经参考附图详细描述了根据本发明的数据库操作方法。本发明提出一种适用于全加密数据库的一写多读方案，解决在分布式数据库场景下，读节点的密钥信息写入问题。本发明提出了的方法能够用户无感的建立后台连接，并且适用于基于不同TEEenclave(安全区)的全加密数据库。

此外，根据本发明的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。

或者，本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时，使所述处理器执行根据本发明的上述方法的各个步骤。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (11)

1.一种数据库操作方法，所述数据库是包括一个写节点和多个读节点的一写多读全加密数据库，其特征在于，所述方法包括：

接收来自用户的读操作请求；

判定响应所述读操作请求需要针对数据密钥表进行写操作，其中，所述数据密钥表存储为所述用户在所述数据库中存储数据进行加密的多个数据密钥；

与所述写节点建立连接并转发所述写操作；

获取所述写节点基于所述写操作更新的所述数据密码表；以及

基于更新的所述数据密码表，生成读操作响应并向所述用户发送所述读操作响应。

2.如权利要求1所述的方法，其中，接收来自用户的读操作请求包括：

接收所述数据库中与所述一个写节点和多个读节点相连的代理服务器转发的来自用户的读操作请求，所述读操作请求不涉及对数据库中存储的加密的用户数据的写操作。

3.如权利要求2所述的方法，其中，判定响应所述读操作请求需要针对数据密钥表进行写操作包括：

判定所述读操作涉及对所述数据库中存储的加密的用户数据的数据结构的改变；以及

确定所述改变涉及的针对所述数据密钥表的写操作。

4.如权利要求1所述的方法，其中，与所述写节点建立连接并转发所述写操作包括：

获取所述写节点的连接地址信息以及连接所述写节点所需的身份验证信息；以及

基于获取的所述连接地址信息和所述身份验证信息，与所述写节点建立连接。

5.如权利要求4所述的方法，其中，获取所述写节点的连接地址信息包括：

从所在集群内部表获取所述写节点的连接地址信息，所述连接地址信息包括上述写节点的IP地址信息和端口号信息。

6.如权利要求4所述的方法，其中，获取连接所述写节点所需的身份验证信息包括：

获取所述数据库内部自带角色的用户名和密码信息作为连接所述写节点所需的身份验证信息。

7.如权利要求6所述的方法，其中，获取所述数据库内部自带角色的用户名和密码信作为连接所述写节点所需的身份验证信息包括：

从作为读节点之一启动时加载的全局变量WalRcv中获取所述数据库的WalRcv用户的用户名和密码信息；

使用所述WalRcv用户的用户名和密码信息作为连接所述写节点所需的身份验证信息。

8.一种全加密数据库，包括：

代理服务器，用于获取来自用户的请求，并进行分发；以及

写节点，用于接收代理服务器分发的来自用户的写请求并进行响应；以及

多个读节点，用于接收代理服务器分发的来自用户的读请求并进行响应，并且执行如权利要求1-7中任一项所述的操作方法。

9.如权利要求8所述的数据库，其中，所述写节点还用于：

响应于基于所述写操作更新所述数据密码表，将更新的所述数据密码表同步至所述多个读节点。

10.一种计算设备，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1-7中任一项所述的方法。

11.一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1-7中任一项所述的方法。

Images