Database multi-version compatibility method, device, equipment and medium
By receiving remote procedure call requests from the HBase database and automatically matching the target version of the library to process the request using target fields or protobuf feature information, the problem of RPC interface incompatibility is solved, achieving efficient multi-version compatibility and improving the convenience and performance of the database.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-03-18
- Publication Date
- 2026-06-16
AI Technical Summary
Existing technologies suffer from RPC interface incompatibility issues in HBase database multi-version compatibility, leading to access request errors. At the same time, existing cross-language and cross-version interface services are complex and have poor performance.
By receiving remote procedure call requests from clients, the system automatically matches the target HBase version's libraries using target fields or protobuf feature information, and builds a retrieval library to quickly locate version differences, thus achieving multi-version compatibility.
This solution resolves access request errors caused by version incompatibility, improves the ease of use and service performance of the HBase database, and avoids the complexity and performance loss associated with additional interface services.
Smart Images

Figure CN122219963A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of database technology, and in particular to a method, apparatus, device and medium for database multi-version compatibility. Background Technology
[0002] Currently, HBase is a distributed, column-oriented, open-source non-relational database, typically consisting of two node roles: master nodes and region servers. The master node is usually used for HBase cluster management, while the region servers are used to provide services externally. Remote procedure call (RPC) is the core mechanism for communication between different nodes in a distributed system. HBase implements its own internal RPC call mechanism based on the Java language and the protocol buffers (protobuf) protocol. HBase clients can communicate with HBase region servers via RPC to perform all core HBase operations.
[0003] As HBase becomes more widely used, the number of versions has also increased, including enterprise-customized versions and various open-source versions. Incompatibility issues frequently arise between the RPC interfaces of these different versions, leading to access request errors. To address this problem, existing solutions involve providing interface services with better cross-language and cross-version capabilities, such as the Representational State Transfer Application Programming Interface (REST API) and Thrift application programming interface.
[0004] However, the above methods require more complex data parameter structures defined by the client due to the need for better cross-language and cross-version interface services, resulting in inconvenient interface usage. Furthermore, the performance of the interface service is inferior to that of RPC interfaces. Therefore, achieving multi-version compatibility while ensuring database usability and service performance has become a pressing technical problem to be solved. Summary of the Invention
[0005] To address the aforementioned technical problems, this disclosure provides a method, apparatus, device, and medium for database multi-version compatibility.
[0006] A first aspect of this disclosure provides a database multi-version compatibility method applied to a service node of an HBase cluster, the method comprising: Receive remote procedure call requests sent by the client, which carry a target field; Based on the mapping relationship between the target field and the HBase version, and when the target field matches the target HBase version corresponding to the client, the remote procedure call request is processed based on the class library corresponding to the target HBase version; or, Receive remote procedure call requests sent by the client, the remote procedure call requests carrying the first protobuf feature information; If the target HBase version corresponding to the client is matched based on the first protobuf feature information, the remote procedure call request is processed based on the class library corresponding to the target HBase version.
[0007] A second aspect of this disclosure provides a database multi-version compatibility apparatus applied to a service node of an HBase cluster, the apparatus comprising: The request receiving module is used to receive remote procedure call requests sent by the client. The remote procedure call request carries at least one of the following: a target field and first protobuf feature information. The first version determination module is used to process remote procedure call requests based on the class library corresponding to the target HBase version, when the target field matches the target HBase version corresponding to the client, based on the mapping relationship between the target field and the HBase version. The second version determination module is used to process remote procedure call requests based on the class library corresponding to the target HBase version when the target HBase version is matched with the first protobuf feature information.
[0008] A third aspect of this disclosure provides an electronic device, including: processor; Memory, used to store executable instructions; The processor is used to read executable instructions from memory and execute the executable instructions to implement the database multi-version compatibility method provided in the first aspect above.
[0009] A fourth aspect of this disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to implement the database multi-version compatibility method provided in the first aspect.
[0010] A fifth aspect of this disclosure provides a computer program product comprising a computer program or instructions that, when executed by a processor, implement the database multi-version compatibility method of the first aspect described above.
[0011] The technical solution provided in this disclosure has the following advantages compared with the prior art: The database multi-version compatibility method, apparatus, device, and medium provided in this disclosure can receive remote procedure call requests sent by clients, the remote procedure call requests carrying a target field; when the mapping relationship between the target field and HBase version, and when the target field matches the target HBase version corresponding to the client, the remote procedure call request is processed based on the class library corresponding to the target HBase version; or, receiving remote procedure call requests sent by clients, the remote procedure call requests carrying first protobuf feature information; when the first protobuf feature information matches the target HBase version corresponding to the client, the remote procedure call request is processed based on the class library corresponding to the target HBase version. Therefore, the target field or first protobuf feature information carried in the remote procedure call request enables automatic matching of HBase versions, thereby processing remote procedure call requests for multiple versions, solving access request errors caused by version compatibility issues. Simultaneously, it is compatible with the native RPC interface, eliminating the need for additional interface services to achieve multi-version compatible remote procedure call interaction, thus improving the ease of use and service performance of the HBase database. Attached Figure Description
[0012] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.
[0013] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0014] Figure 1 This is a flowchart of a database multi-version compatibility method provided in an embodiment of this disclosure; Figure 2 This is a flowchart of a method for determining a target HBase version provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram of the structure of a database multi-version compatibility device provided in an embodiment of this disclosure; Figure 4This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation
[0015] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.
[0016] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.
[0017] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.
[0018] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0019] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".
[0020] HBase is typically a distributed, column-oriented, open-source, non-relational database. It generally consists of two node roles: a master node and region servers. The master node is usually used for HBase cluster management, while the region servers are used to provide services externally. Remote procedure call (RPC) is the core mechanism for communication between different nodes in a distributed system. HBase implements its own internal RPC mechanism based on Java and the protocol buffers (protobuf). HBase clients can communicate with HBase region servers via RPC to perform all core HBase operations. With the widespread use of HBase, the number of versions has gradually increased, including enterprise-customized versions and various open-source versions. Incompatibility issues often exist between the RPC interfaces of different versions, leading to access request errors. To solve this problem, current solutions involve providing interface services with better cross-language and cross-version capabilities, such as the Representational State Transfer Application Programming Interface (REST API) and Thrift application programming interface services.
[0021] However, the above methods require more complex data parameter structures defined by the client due to the need for better cross-language and cross-version interface services, resulting in inconvenient interface usage. Furthermore, the performance of the interface service is significantly worse than that of the RPC interface, typically by an order of magnitude, and the interface is incomplete, unable to support all original RPC call interfaces. Therefore, achieving multi-version compatibility while ensuring database usability and service performance has become a pressing technical problem. To address this issue, this disclosure provides a database multi-version compatibility method, which is described below with reference to specific embodiments.
[0022] Figure 1 This is a flowchart of a database multi-version compatibility method provided in an embodiment of the present disclosure. The method can be executed by a database multi-version compatibility device, which can be implemented in software and / or hardware. The database multi-version compatibility device can be configured in an electronic device, such as a server or terminal, wherein the terminal specifically includes a mobile phone, computer or tablet computer, etc.
[0023] like Figure 1As shown, the database multi-version compatibility method provided in this embodiment is applied to the service node regionserver of the HBase cluster. The database multi-version compatibility method includes the following steps.
[0024] S110: Receive a remote procedure call request sent by the client.
[0025] In this embodiment of the disclosure, the remote procedure call request carries at least one of a target field and first protobuf feature information.
[0026] In this embodiment of the disclosure, the target field is a field used for HBase version tagging.
[0027] Specifically, the regionserver service node of the HBase cluster can receive remote procedure call requests sent by clients in real time. After receiving the remote procedure call request, it analyzes the request header corresponding to the remote procedure call request to determine whether a target field exists. If the target field exists, it means that the client corresponding to the remote procedure call request is a customized HBase client, and then step S120 is executed; if the target field does not exist, it means that the client corresponding to the remote procedure call request is a non-customized HBase client, that is, a public version of the HBase client, and then step S130 is executed.
[0028] S120. Based on the mapping relationship between the target field and the HBase version, and the fact that the target field carried in the remote procedure call request matches the target HBase version corresponding to the client, the remote procedure call request is processed based on the class library corresponding to the target HBase version.
[0029] In this embodiment of the disclosure, the mapping relationship between the target field and the HBase version can be understood as a pre-set correspondence between the field and the HBase version.
[0030] Specifically, the regionserver service node in the HBase cluster, upon determining that a remote procedure call request carries a target field, can identify the HBase version matching the target field based on the mapping relationship between the target field and the HBase version. This matched HBase version is then designated as the target HBase version for the client. The system directly retrieves the corresponding library from the multi-version compatibility configuration library, processes the remote procedure call request based on this library, and returns the processing result to the client.
[0031] S130. If the first protobuf feature information carried in the remote procedure call request matches the target HBase version corresponding to the client, the remote procedure call request is processed based on the class library corresponding to the target HBase version.
[0032] In this embodiment, the first protobuf feature information can be understood as the protobuf feature information corresponding to the HBase version requested by the remote procedure call request. Specifically, it may include key feature information such as method signature hash value and interface structure information.
[0033] Specifically, if the service node RegionServer of the HBase cluster determines that the remote procedure call request does not carry a target field, it can determine the target HBase version corresponding to the client based on the first protobuf feature information carried in the call request. If a target HBase version corresponding to the client is matched, it can directly retrieve the class library corresponding to the target HBase version from the multi-version compatible configuration library, process the remote procedure call request based on the class library, and return the processing result to the client.
[0034] It should be noted that the specific implementation of handling remote procedure call requests based on this class library is similar to the existing methods for handling remote procedure call requests, and will not be elaborated here.
[0035] Steps S120 and S130 are two processing logics used to determine different HBase versions. The appropriate processing logic can be adaptively selected based on the actual application scenario and the information carried in the remote procedure call request. For example, step S120 can be executed when the client is a customized HBase client; step S130 can be executed when the client is a generic HBase client.
[0036] In this embodiment, a remote procedure call (RPC) request carrying a target field can be received from a client. If the target field matches the target HBase version, and the target field matches the target HBase version corresponding to the client, the RPC request is processed based on the library corresponding to the target HBase version. Alternatively, a RPC request carrying a first protobuf feature can be received from a client. If the first protobuf feature matches the target HBase version corresponding to the client, the RPC request is processed based on the library corresponding to the target HBase version. Therefore, the target field or first protobuf feature carried in the RPC request enables automatic HBase version matching, thus handling multiple version RPC requests. This resolves access request errors caused by version compatibility issues. Furthermore, it is compatible with the native RPC interface, eliminating the need for additional interface services to achieve multi-version compatible RPC interaction, thereby improving the ease of use and service performance of the HBase database.
[0037] Based on the above embodiments disclosed herein, the service node RegionServer of the HBase cluster can construct a search library according to the interface information corresponding to each public version of HBase. If it is determined that the target field does not exist, the target HBase version matching the client is determined based on the search library and the first protobuf feature information.
[0038] In this embodiment of the disclosure, before determining the target HBase version matching the client based on the first protobuf feature information and the retrieval library, the database multi-version compatibility method may further include: constructing the retrieval library.
[0039] Building a search library can specifically include: obtaining the HBase interface information corresponding to each HBase version; and building a search library based on the preset protobuf analysis module and the HBase interface information.
[0040] The retrieval database includes the second protobuf feature information corresponding to each HBase version. Each HBase version refers to multiple public versions of HBase.
[0041] In this embodiment of the disclosure, HBase interface information can be understood as a collection of Application Programming Interfaces (APIs) provided by HBase for interacting with clients. For example, it may include HBase operation methods, data structure information, etc.
[0042] Specifically, before determining the target HBase version to match the client, the regionserver service node in the HBase cluster can collect HBase interface information from various public HBase versions and load a pre-defined protobuf analysis module. This module analyzes and summarizes the HBase interface information to create the corresponding search database. Since the various public HBase versions are open source, HBase interface information can be easily collected, and the interface differences between most versions are minimal; therefore, the search database is typically only in the kilobyte range in size.
[0043] In this embodiment, a search library can be constructed using a pre-defined protobuf analysis module, improving the intelligence and automation of search library construction. Since the search library records the second protobuf feature information corresponding to each HBase version, it can quickly locate protocol differences between different versions. Interface information for a specific version can be directly queried through the search library, reducing errors caused by version confusion and significantly improving multi-version compatibility management and development efficiency. Simultaneously, based on the remote procedure call request and the search library, a matching HBase version can be automatically selected, providing a foundation for subsequent HBase version matching and improving the efficiency and accuracy of HBase version determination.
[0044] In this embodiment of the disclosure, determining the target HBase version that matches the client based on the first protobuf feature information may specifically include: determining the target HBase version that matches the client based on the first protobuf feature information and the search library.
[0045] The following will combine Figure 2 This section provides a detailed explanation of the specific methods for determining the HBase version that matches the client.
[0046] Figure 2 This is a flowchart of a method for determining a target HBase version provided in an embodiment of this disclosure, such as... Figure 2 As shown, determining the target HBase version that matches the client based on the first protobuf feature information and the retrieval library can specifically include the following steps: S210. Compare the method signature hash values contained in the multiple second protobuf feature information with the first method signature hash value in the first protobuf feature information to obtain the comparison result.
[0047] Specifically, for each HBase version, the service nodes of the HBase cluster can retrieve the second protobuf feature information of that HBase version from the retrieval database, extract the method signature hash value from the second protobuf feature information, and compare the method signature hash value with the first method signature hash value in the first protobuf feature information to determine whether the method signature hash value in the second protobuf feature information matches the first method signature hash value, thus obtaining a comparison result. If the comparison result shows that there is a second method signature hash value that matches the first method signature hash value among the method signature hash values contained in the multiple second protobuf feature information entries, step S220 is executed; if the comparison result shows that there is no second method signature hash value that matches the first method signature hash value among the method signature hash values contained in the multiple second protobuf feature information entries, step S230 is executed.
[0048] S220. If, in the case that among the method signature hash values contained in the multiple second protobuf feature information, there is a second method signature hash value that matches the first method signature hash value, the first HBase version corresponding to the second method signature hash value is determined as the target HBase version.
[0049] In this embodiment of the disclosure, since the method signature hash value of each HBase version is unique, if the comparison result shows that there is a second method signature hash value that matches the first method signature hash value among the method signature hash values contained in the multiple second protobuf feature information, it indicates that the target HBase version matches the client, and then the first HBase version corresponding to the second method signature hash value is determined as the target HBase version.
[0050] S230. If the comparison result shows that there is no second method signature hash value that matches the first method signature hash value among the method signature hash values contained in the multiple second protobuf feature information, the target HBase version is determined based on the first interface structure information in the first protobuf feature information and the second interface structure information in the multiple second protobuf feature information.
[0051] In this embodiment, if the comparison result shows that none of the method signature hash values contained in the multiple second protobuf feature information matches the first method signature hash value, it indicates that a direct match cannot be made based on the method signature hash value. Therefore, the target HBase version is further determined based on the second interface structure information in the multiple second protobuf feature information and the first interface structure information corresponding to the remote procedure call request. Thus, considering the uniqueness of the HBase version's method signature hash value, the existence of a matching target HBase version is first determined through the method signature hash value, reducing the computational load for determining the target HBase hash value. When the target HBase version cannot be determined through the method signature hash value, it is determined by combining the HBase interface structure information, ensuring the flexibility and diversity of the HBase version determination method.
[0052] In this embodiment of the disclosure, the target HBase version is determined based on the first interface structure information in the first protobuf feature information and the second interface structure information in multiple second protobuf feature information. Specifically, this may include: determining the number of data structure fields in the second interface structure information corresponding to the multiple second protobuf feature information that match the first interface structure information corresponding to the first protobuf feature information; and determining the target HBase version based on the number of matched data structure fields.
[0053] In this embodiment, the interface structure information includes one or more of the following: field structure information, nested message structure information, exception handling structure information, and return value structure information. Field structure information clarifies parameter types and constraints, ensuring the accuracy of data interaction and avoiding runtime errors caused by type mismatches or missing fields. Nested message structures support modular encapsulation of complex logic. Determining the exception handling structure accelerates problem localization and fault-tolerant logic development, improving system robustness. The return value structure defines the semantics and format of response data, ensuring the client correctly parses the results, providing support for system development, maintenance, and cross-version compatibility.
[0054] In this embodiment of the disclosure, the number of matching data structure fields can be understood as the number of fields with the same field names in the data structure.
[0055] Specifically, the service nodes of the HBase cluster can extract the second interface structure information from each second protobuf feature information, determine the field information in the second interface structure information, match the field information with the field information corresponding to the first interface structure information in the first protobuf feature information, determine the data structure fields with the same field name, and then obtain the number of matched data structure fields. Further, based on the number of matched data structure fields, the similarity between the first interface structure information and the second interface structure information is determined, and the target HBase version is determined based on the similarity.
[0056] In this embodiment of the disclosure, determining the target HBase version based on the number of matched data structure fields may specifically include: determining the similarity between the first interface structure information and the second interface structure information based on the number of matched data structure fields and the total number of structure fields in the second interface structure information; and determining the second HBase version corresponding to the target interface structure information with the highest similarity to the first interface structure information among multiple second interface structure information as the target HBase version.
[0057] The formula for calculating similarity is: Similarity = (Number of matching data structure fields / Total number of structure fields in the second interface structure information) × 100%.
[0058] Specifically, after obtaining the similarity, the similarity is compared with a preset similarity threshold. The target interface structure information with the highest similarity is determined, and the second HBase version that matches the second protobuf feature information corresponding to the target interface structure information is determined as the target HBase version.
[0059] In this embodiment, the similarity between the first interface structure information and the second interface structure information is determined by the number of matching data structure fields between the interface structure information. Then, the target HBase version is determined by combining the similarity. By combining the differences in parameters, information structure, and return structure of the compatible versions of HBase interfaces, the version with the highest compatibility can be accurately selected by quantifying the similarity. This supports automated version adaptation, eliminates the need for version judgment logic, reduces development complexity, and improves the efficiency and accuracy of compatibility processing in multi-version environments.
[0060] In this embodiment of the disclosure, if it is determined that there is no target version of HBase database matching the remote procedure call request based on at least one of the target field and the first protobuf feature information carried in the remote procedure call request, an error message is returned to the client and an error log is recorded. This facilitates subsequent analysis by the user and improves the convenience of analysis and processing.
[0061] In this embodiment of the disclosure, the service nodes of the HBase cluster can also dynamically configure the multi-version compatibility function based on the client's operation or application scenario information. For example, in a special scenario where version compatibility issues do not need to be considered, the multi-version compatibility function can be dynamically disabled to avoid additional computing work, reduce resource consumption, and improve the flexibility of multi-version compatibility function settings.
[0062] Figure 3 This is a schematic diagram of the structure of a database multi-version compatibility device provided in an embodiment of this disclosure.
[0063] In this embodiment of the disclosure, the database multi-version compatibility device can be disposed within an electronic device and is understood as a part of the functional modules of the aforementioned electronic device. Specifically, the electronic device can be a server or a terminal, wherein the terminal specifically includes mobile phones, computers, or tablet computers, etc., without limitation.
[0064] like Figure 3 As shown, the database multi-version compatibility device 300 may include a request receiving module 310, a first version determination module 320, and a second version determination module 330.
[0065] The request receiving module 310 can be used to receive a remote procedure call request sent by a client, wherein the remote procedure call request carries at least one of a target field and first protobuf feature information; The first version determination module 320 can be used to process remote procedure call requests based on the class library corresponding to the target HBase version, in the case that the target field matches the target HBase version corresponding to the client, based on the mapping relationship between the target field and the HBase version. The second version determination module 330 can be used to process remote procedure call requests based on the class library corresponding to the target HBase version when the target HBase version is matched with the first protobuf feature information.
[0066] In this embodiment, a remote procedure call (RPC) request carrying a target field can be received from a client. If the target field matches the target HBase version, and the target field matches the target HBase version corresponding to the client, the RPC request is processed based on the library corresponding to the target HBase version. Alternatively, a RPC request carrying a first protobuf feature can be received from a client. If the first protobuf feature matches the target HBase version corresponding to the client, the RPC request is processed based on the library corresponding to the target HBase version. Therefore, the target field or first protobuf feature carried in the RPC request enables automatic HBase version matching, thus handling multiple version RPC requests. This resolves access request errors caused by version compatibility issues. Furthermore, it is compatible with the native RPC interface, eliminating the need for additional interface services to achieve multi-version compatible RPC interaction, thereby improving the ease of use and service performance of the HBase database.
[0067] In some embodiments of this disclosure, the second version determination module 330 may be specifically used to determine the target HBase version that matches the client based on the first protobuf feature information and the retrieval library, wherein the retrieval library includes the second protobuf feature information corresponding to each HBase version.
[0068] In some embodiments of this disclosure, the database multi-version compatible device 300 may further include a retrieval library construction module.
[0069] The retrieval library construction module can be used to obtain HBase interface information corresponding to each HBase version before determining the target HBase version matching the client based on the first protobuf feature information and the retrieval library; The retrieval database is constructed based on the preset protobuf analysis module and the HBase interface information.
[0070] In some embodiments of this disclosure, the second version determination module 330 may include an information comparison unit, a first processing unit, and a second processing unit.
[0071] The information comparison unit can be used to compare the method signature hash values contained in multiple second protobuf feature information with the first method signature hash value in the first protobuf feature information to obtain a comparison result; The first processing unit can be used to determine the first HBase version corresponding to the second method signature hash value as the target HBase version when the comparison result is that there is a second method signature hash value that matches the first method signature hash value among the method signature hash values contained in a plurality of second protobuf feature information; The second processing unit can be used to determine the target HBase version based on the first interface structure information in the first protobuf feature information and the second interface structure information in the multiple second protobuf feature information when the comparison result is that there is no second method signature hash value that matches the first method signature hash value among the method signature hash values contained in the multiple second protobuf feature information.
[0072] In some embodiments of this disclosure, the second processing unit may be specifically used to determine the number of data structure fields in the second interface structure information corresponding to the plurality of second protobuf feature information that match the first interface structure information corresponding to the first protobuf feature information. The target HBase version is determined based on the number of fields in the matched data structure.
[0073] In some embodiments of this disclosure, the second processing unit may also be specifically used to determine the similarity between the first interface structure information and the second interface structure information based on the number of matched data structure fields and the total number of structure fields in the second interface structure information; The second HBase version corresponding to the target interface structure information with the highest similarity to the first interface structure information among multiple second interface structure information is determined as the target HBase version.
[0074] In some embodiments of this disclosure, the interface structure information includes one or more of the following: field structure information, nested message structure information, exception handling structure information, and return value structure information.
[0075] It should be noted that, Figure 3 The database multi-version compatibility device 300 shown can execute the various steps in the above method embodiments and achieve the various processes and effects in the above method embodiments, which will not be elaborated here.
[0076] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure.
[0077] In this embodiment of the disclosure, Figure 4The electronic devices shown can be servers or terminals, and terminals specifically include mobile phones, computers, or tablets, etc., without limitation.
[0078] like Figure 4 As shown, the electronic device may include a processor 410 and a memory 420 storing computer program instructions.
[0079] Specifically, the processor 410 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this disclosure.
[0080] Memory 420 may include a large-capacity storage device for information or instructions. For example, and not limitingly, memory 420 may include a hard disk drive (HDD), a floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 420 may include removable or non-removable (or fixed) media. Where appropriate, memory 420 may be internal or external to the integrated gateway device. In a particular embodiment, memory 420 is a non-volatile solid-state memory. In a particular embodiment, memory 420 includes read-only memory (ROM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (Electrically Programmable ROM, EPROM), an electrically erasable programmable PROM (EEPROM), an electrically alterable ROM (EAROM), or flash memory, or a combination of two or more of these.
[0081] The processor 410 performs the steps of the database multi-version compatibility method provided in this disclosure by reading and executing computer program instructions stored in the memory 420.
[0082] In one example, the electronic device may also include a transceiver 430 and a bus 440. Wherein, as... Figure 4 As shown, the processor 410, memory 420 and transceiver 430 are connected via bus 440 and communicate with each other.
[0083] Bus 440 may include hardware, software, or both. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industrial Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a MicroChannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 440 may include one or more buses.
[0084] This disclosure also provides a computer-readable storage medium that can store a computer program that, when executed by a processor, causes the processor to implement the database multi-version compatibility method provided in this disclosure.
[0085] The aforementioned storage medium may, for example, include a memory 420 containing computer program instructions, which can be executed by a processor 410 of an electronic device to perform the database multi-version compatibility method provided in this embodiment. Optionally, the storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), compact disc ROM (CD-ROM), magnetic tape, floppy disk, and optical data storage device.
[0086] This disclosure also provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, they implement the database multi-version compatibility method provided in this disclosure and can achieve the various processes and effects in the above embodiments of this disclosure, which will not be elaborated here.
[0087] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A database multi-version compatibility method, characterized in that, The method, applied to service nodes in an HBase cluster, includes: Receive a remote procedure call request sent by a client, wherein the remote procedure call request carries a target field; Based on the mapping relationship between the target field and the HBase version, and if the target field matches the target HBase version corresponding to the client, the remote procedure call request is processed based on the class library corresponding to the target HBase version; or, Receive a remote procedure call request sent by a client, wherein the remote procedure call request carries first protobuf feature information; If a target HBase version corresponding to the client is matched based on the first protobuf feature information, the remote procedure call request is processed based on the class library corresponding to the target HBase version.
2. The method according to claim 1, characterized in that, Determining the target HBase version matching the client based on the first protobuf feature information includes: Based on the first protobuf feature information and the retrieval library, the target HBase version that matches the client is determined. The retrieval library includes the second protobuf feature information corresponding to each HBase version.
3. The method according to claim 2, characterized in that, Before determining the target HBase version matching the client based on the first protobuf feature information and the retrieval library, the method further includes: Retrieve the HBase interface information corresponding to each HBase version; The retrieval database is constructed based on the preset protobuf analysis module and the HBase interface information.
4. The method according to claim 2, characterized in that, The step of determining the target HBase version matching the client based on the first protobuf feature information and the retrieval library includes: The method signature hash values contained in the multiple second protobuf feature information are compared with the first method signature hash value in the first protobuf feature information to obtain the comparison result; If, in the case where the comparison result shows that there is a second method signature hash value that matches the first method signature hash value among the method signature hash values contained in the multiple second protobuf feature information, the first HBase version corresponding to the second method signature hash value is determined as the target HBase version; If, in the case that none of the method signature hash values contained in the multiple second protobuf feature information are a second method signature hash value that matches the first method signature hash value, the target HBase version is determined based on the first interface structure information in the first protobuf feature information and the second interface structure information in the multiple second protobuf feature information.
5. The method according to claim 4, characterized in that, The step of determining the target HBase version based on the first interface structure information in the first protobuf feature information and the second interface structure information in the plurality of second protobuf feature information includes: Determine the number of data structure fields in the second interface structure information corresponding to the plurality of second protobuf feature information that match the first interface structure information corresponding to the first protobuf feature information; The target HBase version is determined based on the number of fields in the matched data structure.
6. The method according to claim 5, characterized in that, Determining the target HBase version based on the number of matched data structure fields includes: Based on the number of matching data structure fields and the total number of structure fields in the second interface structure information, the similarity between the first interface structure information and the second interface structure information is determined. The second HBase version corresponding to the target interface structure information with the highest similarity to the first interface structure information among multiple second interface structure information is determined as the target HBase version.
7. The method according to claim 4, characterized in that, The interface structure information includes one or more of the following: field structure information, nested message structure information, exception handling structure information, and return value structure information.
8. A database multi-version compatibility device, characterized in that, The device is used for service nodes in an HBase cluster and includes: The request receiving module is used to receive a remote procedure call request sent by the client, wherein the remote procedure call request carries at least one of a target field and first protobuf feature information; The first version determination module is used to process the remote procedure call request based on the class library corresponding to the target HBase version, based on the mapping relationship between the target field and the HBase version, and when the target field matches the target HBase version corresponding to the client. The second version determination module is used to process the remote procedure call request based on the class library corresponding to the target HBase version when a target HBase version corresponding to the client is matched based on the first protobuf feature information.
9. An electronic device, characterized in that, include: processor; Memory, used to store executable instructions; The processor is configured to read the executable instructions from the memory and execute the executable instructions to implement the database multi-version compatibility method according to any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, causes the processor to implement the database multi-version compatibility method according to any one of claims 1-7.