Authority management method and device for distributed database, equipment, medium and product

Abstract

The invention discloses an authority management method and device for a distributed database, equipment, a medium and a product. The method comprises the following steps: pulling latest permission data from a matched target management node during starting, and caching the latest permission data to the local; and in response to a permission change request of the user, broadcasting the changed permission data to all other data nodes in the cluster through the target management node, so that all other data nodes update the permission data cached locally. According to the technical scheme provided by the invention, the permission data are cached locally in advance, and are synchronized to all other data nodes through the management node by utilizing a broadcast mechanism when the permission is changed, so as to trigger the updating of the local cache, so that simple, efficient and flexible permission management is realized, the permission verification performance in a high-concurrency scene is improved, and the permission verification efficiency is improved. And dynamic permission adjustment is supported, the consistency of permission data can be ensured, and meanwhile, the influence of a single-point fault on a permission verification function is also reduced.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of database technology, and in particular to a method, device, equipment, medium and product for managing permissions of a distributed database. Background Art

[0002] Permission management in traditional database systems usually relies on a global permission table, which controls user access rights through centralized permission management. This centralized permission management works well in a single-node database, but in a distributed database, due to the distributed nature of data nodes and high concurrent access requirements, the global permission table may become a performance bottleneck, especially in frequent permission verification requests. Moreover, permissions are centrally stored in the global permission table. Once the node where the global permission table is located fails, the system permission verification may not be able to proceed normally. In addition, the maintenance of the global permission table requires complex synchronization and consistency assurance mechanisms, which is a major difficulty in distributed scenarios. Summary of the invention

[0003] The embodiments of the present invention provide a method, apparatus, device, medium and product for rights management of a distributed database, so as to solve the problems of single point failure, performance bottleneck and insufficient flexibility in the existing rights management of a distributed database.

[0004] In a first aspect, an embodiment of the present invention provides a method for managing rights in a distributed database, the method comprising:

[0005] At startup, pull the latest permission data from the matching target management node and cache it locally;

[0006] In response to the user's permission change request, the changed permission data is broadcasted to all other data nodes in the cluster through the target management node, so that all other data nodes update the permission data cached locally.

[0007] Optionally, broadcasting the changed permission data to all other data nodes in the cluster through the target management node so that all other data nodes update their locally cached permission data includes:

[0008] Sending a table ban request to the target management node;

[0009] Broadcasting the table ban request to all other data nodes through the target management node, and returning the table ban result after waiting for all other data nodes to respond;

[0010] Pushing the changed permission data to the target management node;

[0011] Broadcasting the changed permission data to all other data nodes through the target management node, and returning the change result after waiting for all other data nodes to respond;

[0012] Sending a request to remove the ban table to the target management node;

[0013] The target management node broadcasts the ban-release request to all other data nodes, and waits for all other data nodes to respond before returning a ban-release result.

[0014] Optionally, the method further includes:

[0015] In response to a user's operation request for a target resource, verify whether the user has the corresponding operation authority based on the locally cached authority data;

[0016] Determine whether to allow the operation request to be executed according to the verification result.

[0017] Optionally, the permission data is stored in metadata, including library-level permissions, table-level permissions, and column-level permissions.

[0018] Optionally, the verifying whether the user has corresponding operation authority according to the locally cached authority data includes:

[0019] Verify layer by layer in the order of library level, table level and column level;

[0020] If the current layer verification fails, the operation request is directly rejected, otherwise the next layer verification is continued until the verification is completed.

[0021] Optionally, the method further includes:

[0022] Initiate a metadata comparison request to the target management node according to a preset period;

[0023] If the local metadata version lags behind the latest version, the latest metadata pushed by the target management node is received.

[0024] In a second aspect, an embodiment of the present invention further provides a rights management device for a distributed database, the device comprising:

[0025] The permission data cache module is used to pull the latest permission data from the matching target management node and cache it locally when starting;

[0026] The permission data change module is used to respond to the user's permission change request and broadcast the changed permission data to all other data nodes in the cluster through the target management node, so that all other data nodes update their locally cached permission data.

[0027] In a third aspect, an embodiment of the present invention further provides a computer device, the computer device comprising:

[0028] one or more processors;

[0029] A memory for storing one or more programs;

[0030] When the one or more programs are executed by the one or more processors, the one or more processors implement the distributed database rights management method provided by any embodiment of the present invention.

[0031] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the distributed database rights management method provided by any embodiment of the present invention.

[0032] In a fifth aspect, an embodiment of the present invention further provides a computer program product, which includes a computer program, and when the program is executed by a processor, it implements the distributed database rights management method provided by any embodiment of the present invention.

[0033] The embodiment of the present invention provides a method for managing permissions of a distributed database. First, at startup, the latest permission data is pulled from the matching target management node and cached locally. Then, during use, when a permission change request from a user is received, the changed permission data is broadcasted to all other data nodes in the cluster through the target management node, so that all other data nodes update their locally cached permission data. The method for managing permissions of a distributed database provided by the embodiment of the present invention caches permission data locally in advance, and synchronizes to all other data nodes through the management node using a broadcast mechanism when permissions are changed to trigger the update of their local caches, thereby achieving simple, efficient and flexible permission management, improving the performance of permission verification in high-concurrency scenarios, supporting dynamic permission adjustment, and ensuring the consistency of permission data, while also reducing the impact of single point failures on the permission verification function. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 A flowchart of a method for managing rights in a distributed database provided in Embodiment 1 of the present invention;

[0035] Figure 2 A schematic diagram of the permission change process provided in the first embodiment of the present invention;

[0036] Figure 3 A schematic diagram of the structure of a rights management device for a distributed database provided in Embodiment 2 of the present invention;

[0037] Figure 4This is a schematic diagram of the structure of a computer device provided in Embodiment 3 of the present invention. DETAILED DESCRIPTION

[0038] The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present invention, rather than to limit the present invention. It should also be noted that, for ease of description, only parts related to the present invention, rather than all structures, are shown in the accompanying drawings.

[0039] It should be mentioned before discussing the exemplary embodiments in more detail that some exemplary embodiments are described as processes or methods depicted as flow charts. Although the flow charts describe the steps as sequential processes, many of the steps therein can be implemented in parallel, concurrently or simultaneously. In addition, the order of the steps can be rearranged. The process can be terminated when its operation is completed, but can also have additional steps not included in the accompanying drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0040] Embodiment 1

[0041] Figure 1 This is a flowchart of the method for managing the rights of a distributed database provided in the first embodiment of the present invention. This embodiment can be applied to the management of rights of a distributed database, and is particularly applicable to situations that require high-concurrency rights verification and dynamic rights adjustment. The method can be executed by the distributed database rights management device provided in the embodiment of the present invention, which can be implemented in hardware and / or software, and can generally be integrated into a computer device, and specifically can be any data node in a distributed database cluster. Figure 1 As shown, the specific steps include:

[0042] S11. When starting, pull the latest permission data from the matching target management node and cache it locally.

[0043] S12. In response to the user's permission change request, the target management node broadcasts the changed permission data to all other data nodes in the cluster, so that all other data nodes update their locally cached permission data.

[0044] Specifically, the cluster may include a storage node etcd for persistent storage of permission data, etc., and may also include one or more management nodes meshm, and each management node meshm may match one or more data nodes meshd. Each data node may pull the latest permission data from the matching target management node and cache it locally when it starts up, and the corresponding target management node may obtain the latest permission data from the storage node to provide it to the data node, thereby ensuring that each data node has complete permission data when it starts up, and when permission verification is required, the local cache may be used directly to complete the verification, avoiding frequent data acquisition from the storage node, reducing dependence on the management node and storage node, reducing network overhead and improving verification performance.

[0045] During the use of this data node, if a user's permission change request is received, specifically, the administrator uses the grant and revoke statements to change permissions through the root user on this data node, then the matching target management node can be used to coordinate and broadcast the changed permission data to all other data nodes in the cluster, so as to trigger all other data nodes to update their locally cached permission data, thereby ensuring the consistency of permission data on each data node. Correspondingly, when this data node receives the broadcasted changed permission data, it also synchronously updates the locally cached permission data to ensure real-time update of permission data. This supports dynamic adjustment of permission configuration to meet actual business needs.

[0046] Among them, optionally, the broadcasting of the changed permission data to all other data nodes in the cluster through the target management node so that all other data nodes update the permission data cached locally, including: sending a ban request to the target management node; broadcasting the ban request to all other data nodes through the target management node, and waiting for all other data nodes to respond before returning the ban result; pushing the changed permission data to the target management node; broadcasting the changed permission data to all other data nodes through the target management node, and waiting for all other data nodes to respond before returning the change result; sending a ban release request to the target management node; broadcasting the ban release request to all other data nodes through the target management node, and waiting for all other data nodes to respond before returning the ban release result.

[0047] Specifically, when executing a permission change statement, this data node can first send a table ban request to the matching target management node to ensure data consistency and integrity. After receiving the table ban request, the target management node can first persist it to the storage node, and then publish it to all management nodes in the cluster through the storage node, and then broadcast the table ban request to all data nodes in the cluster. Then the data node that received the table ban request can respond to the request and return. After waiting for all other data nodes to respond, the target management node can return the table ban result to this data node. Subsequently, this data node pushes the changed permission data to the target management node. The target management node can also first persist the changed permission data to the storage node, and then publish it to all management nodes in the cluster through the storage node, and then broadcast the changed permission data to all data nodes in the cluster. Similarly, after waiting for all other data nodes to respond, the target management node can return the change result to this data node. Finally, this data node sends a request to lift the ban on the table to the target management node. After receiving the request, the target management node can also persist it to the storage node first, and then publish it to all management nodes in the cluster through the storage node, and then broadcast the request to lift the ban on the table to all data nodes in the cluster. After waiting for all other data nodes to respond, the target management node can return the lifting of the ban result to this data node, thus ending this permission change process. The above permission change process can be referred to Figure 2 shown.

[0048] Based on the above technical solution, optionally, the method also includes: in response to a user's operation request for a target resource, verifying whether the user has corresponding operation authority based on locally cached permission data; and determining whether to allow the operation request to be executed based on the verification result.

[0049] Specifically, during the use of this data node, if a user's operation request for a target resource is received, which may be a user inputting a SQL statement using this data node, the locally cached permission data may be queried first to verify whether the user has the operation permission for the target resource. If the verification result is successful, the operation request is allowed to execute; otherwise, the operation request is rejected.

[0050] Further optionally, the permission data is stored in the metadata, including library-level permissions, table-level permissions, and column-level permissions. By embedding metadata fields and storing them in a library, table, and column structure, multi-level permission management can be implemented, thereby achieving more refined permission control. Among them, each permission data may include a mapping of user information and information such as the type of permission owned (such as SELECT, INSERT). Accordingly, when pulling permission data from the target management node, the current full metadata can be directly pulled, that is, including the permission data.

[0051] Further optionally, the verification of whether the user has the corresponding operation permission based on the locally cached permission data includes: verifying layer by layer in the order of library level, table level and column level; if the current layer verification fails, directly rejecting the operation request, otherwise continuing to the next layer verification until the verification is completed. Specifically, first verify the user's library-level permission. If the library-level permission verification fails, directly reject the operation request, otherwise continue to verify the user's table-level permission. If the table-level permission verification fails, directly reject the operation request, otherwise continue to verify the user's column-level permission. If the column-level permission verification fails, reject the operation request, otherwise allow the operation request.

[0052] On the basis of the above technical solution, optionally, the method further includes: initiating a metadata comparison request to the target management node according to a preset period; if the local metadata version lags behind the latest version, receiving the latest metadata pushed by the target management node. Preferably, the preset period is thirty seconds. Then each working data node can initiate a metadata comparison request to the corresponding matching target management node every thirty seconds. If the target management node finds that the metadata version of a data node lags behind the latest version, it can push the latest metadata to the data node. After receiving the latest metadata, the corresponding data node can update the locally cached permission data. This further ensures the consistency of the permission data.

[0053] The technical solution provided by the embodiment of the present invention first pulls the latest permission data from the matching target management node and caches it locally at startup, and then during use, when a user's permission change request is received, the changed permission data is broadcast to all other data nodes in the cluster through the target management node, so that all other data nodes can update their locally cached permission data. By caching the permission data locally in advance and synchronizing it to all other data nodes through the management node using a broadcast mechanism when the permission changes to trigger the update of their local cache, simple, efficient and flexible permission management is achieved, the performance of permission verification in high-concurrency scenarios is improved, and dynamic permission adjustment is supported. It can ensure the consistency of permission data, and also reduce the impact of single point failures on the permission verification function.

[0054] Embodiment 2

[0055] Figure 3 This is a schematic diagram of the structure of the distributed database rights management device provided in the second embodiment of the present invention. The device can be implemented by hardware and / or software, and can generally be integrated into a computer device to execute the distributed database rights management method provided in any embodiment of the present invention. Figure 3 As shown, the device comprises:

[0056] The permission data cache module 31 is used to pull the latest permission data from the matching target management node and cache it locally when starting;

[0057] The permission data changing module 32 is used to respond to the user's permission change request and broadcast the changed permission data to all other data nodes in the cluster through the target management node, so that all other data nodes update their locally cached permission data.

[0058] The technical solution provided by the embodiment of the present invention first pulls the latest permission data from the matching target management node and caches it locally at startup, and then during use, when a user's permission change request is received, the changed permission data is broadcast to all other data nodes in the cluster through the target management node, so that all other data nodes can update their locally cached permission data. By caching the permission data locally in advance and synchronizing it to all other data nodes through the management node using a broadcast mechanism when the permission changes to trigger the update of their local cache, simple, efficient and flexible permission management is achieved, the performance of permission verification in high-concurrency scenarios is improved, and dynamic permission adjustment is supported. It can ensure the consistency of permission data, and also reduce the impact of single point failures on the permission verification function.

[0059] On the basis of the above technical solution, optionally, the authority data changing module 32 is specifically used for:

[0060] Sending a table ban request to the target management node;

[0061] Broadcasting the table ban request to all other data nodes through the target management node, and returning the table ban result after waiting for all other data nodes to respond;

[0062] Pushing the changed permission data to the target management node;

[0063] Broadcasting the changed permission data to all other data nodes through the target management node, and returning the change result after waiting for all other data nodes to respond;

[0064] Sending a request to remove the ban table to the target management node;

[0065] The target management node broadcasts the ban-release request to all other data nodes, and waits for all other data nodes to respond before returning a ban-release result.

[0066] On the basis of the above technical solution, optionally, the device further includes:

[0067] The permission verification module is used to respond to the user's operation request for the target resource and verify whether the user has the corresponding operation permission according to the permission data cached locally;

[0068] The execution determination module is used to determine whether to allow the operation request to be executed according to the verification result.

[0069] Based on the above technical solution, optionally, the permission data is stored in metadata, including library-level permissions, table-level permissions, and column-level permissions.

[0070] Based on the above technical solution, optionally, the permission verification module is specifically used to:

[0071] Verify layer by layer in the order of library level, table level and column level;

[0072] If the current layer verification fails, the operation request is directly rejected, otherwise the next layer verification is continued until the verification is completed.

[0073] On the basis of the above technical solution, optionally, the device further includes:

[0074] A metadata comparison module, used to initiate a metadata comparison request to the target management node according to a preset period;

[0075] The metadata update module is used to receive the latest metadata pushed by the target management node if the local metadata version lags behind the latest version.

[0076] The rights management device for a distributed database provided in an embodiment of the present invention can execute the rights management method for a distributed database provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0077] It is worth noting that in the above-mentioned embodiment of the permission management device of the distributed database, the various units and modules included are only divided according to functional logic, but are not limited to the above-mentioned division, as long as the corresponding functions can be achieved; in addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of the present invention.

[0078] Embodiment 3

[0079] Figure 4 The schematic diagram of the structure of the computer device provided for the third embodiment of the present invention shows a block diagram of an exemplary computer device suitable for implementing the implementation mode of the present invention. Figure 4 The computer device shown is only an example and should not limit the functions and scope of use of the embodiments of the present invention. Figure 4As shown, the computer device includes a processor 41, a memory 42, an input device 43 and an output device 44; the number of processors 41 in the computer device can be one or more. Figure 4 Taking a processor 41 as an example, the processor 41, memory 42, input device 43 and output device 44 in the computer device can be connected through a bus or other means. Figure 4 The example of connecting through bus is taken in the following.

[0080] The memory 42 is a computer-readable storage medium that can be used to store software programs, computer executable programs and modules, such as program instructions / modules corresponding to the distributed database rights management method in the embodiment of the present invention (for example, the rights data cache module 31 and the rights data change module 32 in the distributed database rights management device). The processor 41 executes various functional applications and data processing of the computer device by running the software programs, instructions and modules stored in the memory 42, that is, realizing the above-mentioned distributed database rights management method.

[0081] The memory 42 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and at least one application required for a function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 42 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 42 may further include a memory remotely arranged relative to the processor 41, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0082] The input device 43 may be used to pull permission data, and generate key signal inputs related to user settings and function control of the computer device, etc. The output device 44 may be used to send requests to the management node, etc.

[0083] Embodiment 4

[0084] Embodiment 4 of the present invention further provides a storage medium containing computer executable instructions, wherein the computer executable instructions are used to execute a distributed database rights management method when executed by a computer processor, the method comprising:

[0085] At startup, pull the latest permission data from the matching target management node and cache it locally;

[0086] In response to the user's permission change request, the changed permission data is broadcasted to all other data nodes in the cluster through the target management node, so that all other data nodes update the permission data cached locally.

[0087] The storage medium may be any of various types of memory devices or storage devices. The term "storage medium" is intended to include: installation media, such as CD-ROM, floppy disk or tape device; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory, magnetic media (such as hard disk or optical storage); registers or other similar types of memory elements, etc. The storage medium may also include other types of memory or combinations thereof. In addition, the storage medium may be located in the computer system in which the program is executed, or may be located in a different second computer system, which is connected to the computer system via a network (such as the Internet). The second computer system may provide program instructions to the computer for execution. The term "storage medium" may include two or more storage media that may reside in different locations (e.g., in different computer systems connected via a network). The storage medium may store program instructions (e.g., embodied as a computer program) that may be executed by one or more processors.

[0088] Of course, the computer executable instructions of a storage medium including computer executable instructions provided in an embodiment of the present invention are not limited to the operations of the method described above, but can also execute related operations in the distributed database rights management method provided in any embodiment of the present invention.

[0089] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0090] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0091] Through the above description of the implementation methods, the technicians in the relevant field can clearly understand that the present invention can be implemented by means of software and necessary general hardware, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory (FLASH), hard disk or optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0092] Embodiment 5

[0093] Embodiment 5 of the present invention further provides a computer program product, which includes a computer program (also referred to as code, instruction), which can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it is used to execute the distributed database permission management method provided in any of the above embodiments, and has the corresponding beneficial effects of the execution method.

[0094] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A method for managing rights in a distributed database, characterized in that: include: At startup, pull the latest permission data from the matching target management node and cache it locally; In response to the user's permission change request, the changed permission data is broadcasted to all other data nodes in the cluster through the target management node, so that all other data nodes update the permission data cached locally.

2. The method for managing rights of a distributed database according to claim 1, characterized in that: The method of broadcasting the changed permission data to all other data nodes in the cluster through the target management node, so that all other data nodes update their locally cached permission data, includes: Sending a table ban request to the target management node; Broadcasting the table ban request to all other data nodes through the target management node, and returning the table ban result after waiting for all other data nodes to respond; Pushing the changed permission data to the target management node; Broadcasting the changed permission data to all other data nodes through the target management node, and returning the change result after waiting for all other data nodes to respond; Sending a request to remove the ban table to the target management node; The target management node broadcasts the ban-release request to all other data nodes, and waits for all other data nodes to respond before returning a ban-release result.

3. The method for managing rights of a distributed database according to claim 1, characterized in that: The method further comprises: In response to a user's operation request for a target resource, verify whether the user has the corresponding operation authority based on the locally cached authority data; Determine whether to allow the operation request to be executed according to the verification result.

4. The method for managing rights of a distributed database according to claim 3, characterized in that: The permission data is stored in metadata, including library-level permissions, table-level permissions, and column-level permissions.

5. The method for managing rights of a distributed database according to claim 4, characterized in that: The verifying whether the user has the corresponding operation authority according to the locally cached authority data includes: Verify layer by layer in the order of library level, table level and column level; If the current layer verification fails, the operation request is directly rejected, otherwise the next layer verification is continued until the verification is completed.

6. The method for managing rights of a distributed database according to claim 4, characterized in that: The method further comprises: Initiate a metadata comparison request to the target management node according to a preset period; If the local metadata version lags behind the latest version, the latest metadata pushed by the target management node is received.

7. A rights management device for a distributed database, characterized in that: include: The permission data cache module is used to pull the latest permission data from the matching target management node and cache it locally when starting; The permission data change module is used to respond to the user's permission change request and broadcast the changed permission data to all other data nodes in the cluster through the target management node, so that all other data nodes update their locally cached permission data.

8. A computer device, characterized in that: include: one or more processors; A memory for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the distributed database rights management method as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the distributed database rights management method as described in any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the computer program implements the distributed database rights management method as described in any one of claims 1 to 6.

Images