Database access management method and device, electronic equipment and storage medium
Through centralized configuration management tables and dynamic assembly technology, the problem of system bloat in heterogeneous database access is solved, system scalability and compatibility are achieved, and the flexibility and availability of database access are improved.
Patent Information
- Application Number
- CN202510804348.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-16
- Publication Date
- 2025-09-16
AI Technical Summary
In the existing technology, heterogeneous database access solutions lack a unified driver management and configuration management mechanism, resulting in bloated systems and difficulty in expansion.
It adopts centralized configuration management tables and driver information tables, realizes unified access interface management by dynamically assembling database access objects, and supports dynamic registration and configuration information update of multiple database types, including disaster recovery switching and performance optimization.
It improves system scalability, achieves compatibility with various mainstream databases, shortens database failover and version upgrade time, and improves system availability.
Smart Images

Figure CN120653687A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of database access technology, and in particular to a database access management method, device, electronic device and storage medium. Background Art
[0002] As enterprises deepen their digital transformation, modern business systems often need to integrate relational databases (MySQL / Oracle), NoSQL databases (HBase / MongoDB), and new analytical databases (Doris / StarRocks). These databases differ fundamentally in the following aspects: (1) Communication protocol differences: different interface specifications such as JDBC, Thrift, and REST; (2) Transaction model differences: different consistency guarantees such as ACID and BASE; (3) Functional feature differences: unique features such as indexing mechanisms and query syntax. This heterogeneity requires application systems to maintain independent access modules for each database, and to deal with data consistency issues when operating across databases, resulting in an exponential increase in system complexity.
[0003] Currently, there are two main solutions for accessing heterogeneous databases: (1) Customized adaptation: Developing a dedicated connection pool, driver loader, and fault handling module for each database. For example, a certain bank system maintains three access components: Oracle Pro*C, MySQL Connector / J, and HBase Client. (2) Standardized middleware: Using middleware such as ShardingSphere to provide SQL dialect conversion.
[0004] However, in these current database access solutions, the database access logic is independent of each other and lacks a unified driver management and configuration management mechanism, resulting in a bloated system and difficulty in expansion. Summary of the Invention
[0005] The present application provides a database access management method, device, electronic device and storage medium to solve the problem in the existing database access solution that each database access logic is independent of each other and lacks a unified driver management and configuration management mechanism, resulting in a bloated system and difficulty in expansion.
[0006] In a first aspect, the present application provides a database access management method, comprising:
[0007] Receive a database access request sent by a client, wherein the database access request includes an instance number of a target database;
[0008] Querying the corresponding database configuration information in a preset configuration management table according to the instance number;
[0009] Querying a corresponding target driver in a preset driver information table according to the database configuration information;
[0010] A database access object is dynamically assembled according to the target driver, and the database access object is returned to the client, so that the client can directly access the target database through the database access object.
[0011] In a possible implementation manner, after returning the database access object to the client, the method further includes:
[0012] Continuously monitoring the availability status of the target database;
[0013] In the case where it is monitored that the target database becomes unavailable, querying the disaster recovery database configuration information corresponding to the target database from the disaster recovery configuration information table, wherein the disaster recovery configuration information table is associated with the configuration management table through an instance number;
[0014] Reassembling a new database access object based on the disaster recovery database configuration information;
[0015] The reassembled database access object is returned to the client.
[0016] In a possible implementation manner, after returning the database access object to the client, the method further includes:
[0017] In response to a heartbeat detection request from the client, detecting whether the database configuration information has changed;
[0018] When a change in the database configuration information is detected, an information change message is pushed to the client through the heartbeat channel to notify the client to update the database access object cached locally.
[0019] In one possible implementation, the dynamically assembling database access objects according to the target driver includes:
[0020] When receiving a database access request sent by the client for the first time, performing a basic assembly operation to generate a database access object containing only basic functions;
[0021] When the client performs a database operation for the first time, the extended function module required for the current database operation is detected, and the extended function module is injected into the generated database access object.
[0022] In one possible implementation, the dynamically assembling database access objects according to the target driver includes:
[0023] Detecting the version requirement of the client operating environment;
[0024] Matching a driver implementation class that meets the version requirement from the target driver;
[0025] The driver implementation class is loaded to generate the database access object.
[0026] In a possible implementation manner, before loading the driver implementation class to generate the database access object, the process further includes:
[0027] Extracting the storage path and verification certificate of the target driver from the driver information table;
[0028] Downloading a driver package corresponding to the target driver according to the storage path, wherein the driver package includes the driver implementation class;
[0029] Verifying the integrity of the driver package using the verification certificate;
[0030] After the verification is passed, the step of loading the driver implementation class to generate the database access object is executed.
[0031] In a possible implementation manner, after returning the database access object to the client, the method further includes:
[0032] Collecting performance indicator data of the target database through the database access object;
[0033] When any of the performance indicator data exceeds the corresponding threshold in the configuration management table, the connection parameters are adjusted according to the preset rules;
[0034] Push the updated connection parameters to the client via the heartbeat channel.
[0035] In a second aspect, the present application provides a database access management device, comprising:
[0036] A receiving module, configured to receive a database access request sent by a client, wherein the database access request includes an instance number of a target database;
[0037] A first query module is used to query the corresponding database configuration information in a preset configuration management table according to the instance number;
[0038] A second query module is used to query the corresponding target driver in the preset driver information table according to the database configuration information;
[0039] The assembly module is used to dynamically assemble a database access object according to the target driver and return the database access object to the client, so that the client can directly access the target database through the database access object.
[0040] In a possible implementation, the device further includes a disaster recovery switching module, configured to:
[0041] Continuously monitoring the availability status of the target database;
[0042] In the case where it is monitored that the target database becomes unavailable, querying the disaster recovery database configuration information corresponding to the target database from the disaster recovery configuration information table, wherein the disaster recovery configuration information table is associated with the configuration management table through an instance number;
[0043] Reassembling a new database access object based on the disaster recovery database configuration information;
[0044] The reassembled database access object is returned to the client.
[0045] In one possible implementation, the device further includes a changing module, configured to:
[0046] In response to a heartbeat detection request from the client, detecting whether the database configuration information has changed;
[0047] When a change in the database configuration information is detected, an information change message is pushed to the client through the heartbeat channel to notify the client to update the database access object cached locally.
[0048] In one possible implementation, the assembly module is specifically configured to:
[0049] When receiving a database access request sent by the client for the first time, performing a basic assembly operation to generate a database access object containing only basic functions;
[0050] When the client performs a database operation for the first time, the extended function module required for the current database operation is detected, and the extended function module is injected into the generated database access object.
[0051] In one possible implementation, the assembly module is further configured to:
[0052] Detecting the version requirement of the client operating environment;
[0053] Matching a driver implementation class that meets the version requirement from the target driver;
[0054] The driver implementation class is loaded to generate the database access object.
[0055] In one possible implementation, the assembly module is further configured to:
[0056] Extracting the storage path and verification certificate of the target driver from the driver information table;
[0057] Downloading a driver package corresponding to the target driver according to the storage path, wherein the driver package includes the driver implementation class;
[0058] Verifying the integrity of the driver package using the verification certificate;
[0059] After the verification is passed, the step of loading the driver implementation class to generate the database access object is executed.
[0060] In one possible implementation, the device further includes an updating module, configured to:
[0061] Collecting performance indicator data of the target database through the database access object;
[0062] When any of the performance indicator data exceeds the corresponding threshold in the configuration management table, the connection parameters are adjusted according to the preset rules;
[0063] Push the updated connection parameters to the client via the heartbeat channel.
[0064] In a third aspect, the present application provides a device comprising: a processor and a memory, wherein the processor is configured to execute a database access management program stored in the memory to implement the database access management method according to any one of the first aspects.
[0065] In a fourth aspect, the present application provides a storage medium storing one or more programs, which can be executed by one or more processors to implement the database access management method described in any one of the first aspects.
[0066] The above-mentioned technical solution provided by the embodiment of the present application has the following advantages over the existing technology: the method provided by the embodiment of the present application, first, adopts a centralized configuration management table and a driver information table, which solves the system bloat problem caused by the independence of the access logic of each database, so that when adding a new database type, only the driver and configuration information need to be registered without modifying the application code, which greatly improves the scalability of the system; secondly, through the technology of dynamically assembling database access objects, while maintaining the native interface capabilities of each database, the access interface is standardized, and it can be fully compatible with the unique functions of various mainstream databases; finally, the configuration hot update capability based on this architecture makes it unnecessary to restart the application when the database fails or the version is upgraded, which significantly shortens the system recovery time and greatly improves the system availability. BRIEF DESCRIPTION OF THE DRAWINGS
[0067] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0068] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0069] One or more embodiments are exemplarily illustrated by pictures in the corresponding drawings. These exemplifications do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements. Unless otherwise stated, the figures in the drawings do not constitute proportional limitations.
[0070] Figure 1 A flowchart of an embodiment of a database access management method provided in an embodiment of the present application;
[0071] Figure 2 A schematic diagram of the structure of an access management framework provided in an embodiment of the present application;
[0072] Figure 3 A flowchart of another database access management method provided in an embodiment of the present application;
[0073] Figure 4 A flowchart of another embodiment of a database access management method provided in an embodiment of the present application;
[0074] Figure 5 A block diagram of an embodiment of a database access management device provided in an embodiment of the present application;
[0075] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0076] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0077] The disclosure below provides many different embodiments or examples for implementing different structures of the present application. In order to simplify the disclosure of the present application, the components and settings of specific examples are described below. Of course, these are merely examples and are not intended to limit the present application. In addition, the present application may repeat reference numbers and / or letters in different examples. Such repetition is for the purpose of simplicity and clarity and does not in itself indicate the relationship between the various embodiments and / or settings discussed.
[0078] In order to solve the technical problem in the database access solution in the prior art that the access logics of various databases are independent of each other and there is a lack of a unified driver management and configuration management mechanism, resulting in a bloated system and difficulty in expansion, the present application provides a database access management method. First, a centralized configuration management table and driver information table are adopted to solve the system bloating problem caused by the independence of the access logics of various databases. When adding a new database type, only the driver and configuration information need to be registered without modifying the application code, which greatly improves the scalability of the system; secondly, through the technology of dynamically assembling database access objects, the access interface is standardized while maintaining the native interface capabilities of each database, and is fully compatible with the unique functions of various mainstream databases; finally, the configuration hot update capability based on this architecture makes it unnecessary to restart the application when switching database faults or upgrading versions, which significantly shortens the system recovery time and greatly improves the system availability.
[0079] Figure 1 This is a flow chart of an embodiment of a database access management method provided in the embodiment of the present application. Figure 1 As shown, the method includes the following steps:
[0080] Step 101: Receive a database access request sent by a client, where the database access request includes an instance number of a target database.
[0081] In applications, the database access management method provided in the embodiments of the present application can be implemented through a universal access management framework for multiple heterogeneous databases based on Zookeeper. Figure 2 This is a schematic diagram of the structure of the general access management framework, such as Figure 2As shown, the management framework provides an initialization information tool for various database products. Through this tool, all the information of the database that needs to be connected can be initialized into the various management tables of the framework (configuration management table, driver information table, instance information table). Among them, the driver information table: mainly records the driver interface and version information of the controlled database. Configuration management table: mainly records the configuration information of the controlled database (such as service address, service port, permission information, database type, etc.). These configuration information correspond one-to-one with the instance information of the controlled database. Instance information table: records the instance number of the controlled database. In the management framework, each controlled database will be assigned a 16-bit unique instance number, which corresponds one-to-one with the instance configuration in the configuration management table.
[0082] The management framework integrates multiple versions of drivers and interface programs for mainstream database products and provides a unified external access interface. Furthermore, if a database has already implemented disaster recovery, the management framework will record the managed database's disaster recovery cluster information, enabling dynamic disaster recovery switching when necessary.
[0083] Database access request: refers to a database operation instruction initiated by a client application, which includes the operation type (such as query, update) and the target database identification information. In this application, the request uses a standardized format and includes the instance number of the target database as a key parameter.
[0084] Instance number: This is a 16-bit globally unique identifier assigned by the management framework when a database is connected. Each number corresponds to a registered database instance, and the mapping is stored in the instance information table of the ZK cluster. For example, "A1B2C3D4E5F6G7H8" corresponds to the MySQL master database in the production environment, while "Z9Y8X7W6V5U4T3S2" corresponds to the Oracle backup database in the disaster recovery environment.
[0085] In an embodiment of the present application, the management framework receives client requests by listening to a specific ZNode node (such as / db_requests) through the ZK (ZooKeeper) cluster. When the client creates a temporary node and writes a standardized JSON request containing a 16-bit instance number, the management framework performs a double verification: for valid requests (i.e., requests with the correct instance number format, existing in the instance information table, and the corresponding database status is "active"), the system will add them to the pending queue and enter the subsequent driver assembly process; for invalid requests (including requests with a non-existent number, an incorrect format, or the target database is offline), the framework will immediately return a preset error code (such as INVALID_INSTANCE_ID or SERVICE_UNAVAILABLE) and remove the invalid request node through ZK's automatic node cleanup mechanism.
[0086] In this way, by strictly distinguishing the processing paths of valid requests and invalid requests, we can ensure the efficient use of system resources, and guarantee access security through ZK's ACL permission control and temporary node characteristics, while maintaining millisecond-level request response capabilities.
[0087] Step 102: Query the corresponding database configuration information in the preset configuration management table according to the instance number.
[0088] Configuration management table: refers to the persistent node stored in the ZK cluster (such as / db_configs), which uses JSON format to record the detailed connection parameters of each database instance, such as the service address (IP / Domain), service port, authentication credentials (encrypted storage), database type (MySQL / Oracle, etc.), version number (such as MySQL 8.0), and weight value (for load balancing).
[0089] Database configuration information refers to structured data stored in configuration management tables that describes database instance connection and operational parameters. This information is crucial for dynamically assembling database access objects. Key features of this configuration information include: storing connection parameters in a key-value structure; including database type and version identifiers; encrypting sensitive information (such as passwords); supporting database-specific parameters (such as replica set names); and including performance tuning parameters (such as connection pool size). This configuration information is associated with a specific database instance via its instance ID and serves as the foundational metadata for unified access management.
[0090] In an embodiment of the present application, the management framework will query the corresponding database configuration information in the configuration management table based on the instance number provided by the client. This process introduces the important concept of "valid configuration", which refers to complete configuration data that has passed multiple verifications by the system and meets all technical requirements. To be a valid configuration, four core conditions must be met at the same time: first, the configuration data must be in a complete format and contain all necessary connection parameter fields; second, the configuration must be in an active and available state and not marked as disabled or expired; third, all encrypted fields must be able to be successfully decrypted by the system; and finally, the database version must fall within the range explicitly supported by the framework. Only configurations that have fully passed these verifications will be recognized by the system as valid configurations and then cached for use in subsequent driver assembly links. Any configuration that does not meet any of the conditions will be classified as an invalid configuration, triggering an error handling mechanism. This strict validity judgment mechanism ensures that the configuration data relied upon by the subsequent driver assembly links is absolutely reliable.
[0091] Step 103: Query the corresponding target driver in the preset driver information table according to the database configuration information.
[0092] Driver information table: The / db_drivers node in the ZK cluster stores metadata about all database drivers.
[0093] Target driver: refers to the driver package that exactly matches the database type and version (such as the JAR file and metadata of MySQL Connector / J8.0.28).
[0094] In an embodiment of the present application, according to the valid configuration information obtained in step 102, the matching target driver is queried in the driver information table. This step first locates the corresponding driver record through the database type and version number in the database configuration information, and obtains key information such as the driver storage path and main class name. Then, the management framework checks whether the driver package has been cached locally. If not, the driver file is downloaded from the specified storage location. After completing the driver acquisition, the management framework uses a custom class loader to load the driver main class to prepare for the subsequent dynamic assembly of database access objects. The entire process ensures that the driver version strictly matches the database configuration, while improving the driver loading efficiency through the local caching mechanism.
[0095] Step 104: Dynamically assemble a database access object according to the target driver, and return the database access object to the client, so that the client can directly access the target database through the database access object.
[0096] Dynamic assembly refers to the process of building database connection components on demand at runtime based on real-time driver information and configuration parameters. Unlike traditional static linking, dynamic assembly offers the following features: lazy loading, which initializes necessary components only on first access; adaptive environment adaptation, which automatically matches the client runtime environment (e.g., JDK version); and hot swapping, which supports driver updates without restarting the service.
[0097] Database access object: A standardized access interface instance generated by the management framework. Its essence is an adapter pattern implementation, including: native driver instance (such as MySQL Connector / J object); connection pool management module; monitoring probe (for performance data collection); fault switching processor.
[0098] In an embodiment of the present application, the management framework loads the native driver implementation class (such as MySQL's Connection interface implementation) contained therein based on the metadata of the target driver, and encapsulates it as a standardized access object through dynamic proxy technology. This object retains all the functions of the native driver, while adding a unified control layer of the management framework (such as connection pool, monitoring, etc.), and finally returns it to the client for use through an encrypted channel. This assembly process achieves efficient instant loading, supports dynamic driver updates and coexistence of multiple versions, enables the client to obtain out-of-the-box database access capabilities, and provides a scalable operating basis for advanced functions such as subsequent disaster recovery switching and configuration hot updates.
[0099] Specifically, in one embodiment, dynamically assembling a database access object according to the target driver may include the following steps: when a database access request sent by the client is received for the first time, performing a basic assembly operation to generate a database access object containing only basic functions; when the client performs a database operation for the first time, detecting the extended function module required for the current database operation, and injecting the extended function module into the generated database access object.
[0100] Basic assembly operation refers to initializing only the core components required for database access when processing a client request for the first time, including necessary modules such as a minimized connection pool, basic SQL parsing capabilities, and security authentication functions, and generating a lightweight access object with only necessary methods such as basic connection testing.
[0101] Extended function modules refer to enhanced components that are dynamically loaded based on the client's actual usage scenarios, including optional functional units such as transaction management, performance optimization, advanced monitoring, and various database special function adapters.
[0102] In this embodiment, the dynamic assembly process first performs basic assembly operations, that is, when the client request is first received, only the core components (such as the minimum connection pool, basic SQL parser and security authentication processor) are initialized, and a lightweight database access object containing only necessary functions such as basic connectivity testing is generated. This stage will control the time consumption to hundreds of milliseconds to meet the rapid response requirements. When the client performs a specific database operation for the first time, the system detects the required extended function modules (such as transaction management, performance optimization or geographic information processing and other special functions) through semantic analysis, dynamically queries and loads the corresponding modules from the driver information table, injects them into the running access object through the hot deployment mechanism, and establishes a service call chain between modules. This progressive loading strategy distributes the driver initialization overhead over the entire life cycle, which not only reduces the initial memory usage, but also supports on-demand function expansion through modular design, perfectly achieving the dual goals of "client out-of-the-box" and "flexible support for heterogeneous database features" in the briefing document.
[0103] In another embodiment, dynamically assembling a database access object according to the target driver may further include the following steps: detecting the version requirement of the client operating environment; matching a driver implementation class that meets the version requirement from the target driver; and loading the driver implementation class to generate the database access object.
[0104] The client runtime environment version requirements refer to the software environment characteristics of the client's host machine, including but not limited to JDK version (such as JDK11 or JDK17), operating system bit size (32 / 64 bit), dependent library version (such as Netty4.x), and other environmental constraints.
[0105] A driver implementation class refers to the differentiated implementations provided in the target driver package for different environments. For example, the MySQL driver includes support classes for both JDBC 4.2 and JDBC 5.0 specifications.
[0106] In this embodiment, the management framework first collects the client's runtime characteristics through an environment probe, then compares them with the compatibility matrix recorded in the driver information table, selects a fully matching driver implementation class, and finally uses the class loader to load the implementation class. This ensures that the generated database access object can fully utilize environmental characteristics (such as JDK11's HTTP / 2 support) while avoiding version conflicts.
[0107] In addition, in another embodiment, before loading the driver implementation class to generate the database access object, the following steps may also be included: extracting the storage path and verification certificate of the target driver from the driver information table; downloading the driver package corresponding to the target driver according to the storage path, the driver package containing the driver implementation class; using the verification certificate to verify the integrity of the driver package; after the verification is passed, executing the step of loading the driver implementation class to generate the database access object.
[0108] The storage path refers to the physical location of the driver package recorded in the driver information table in the distributed storage system, usually expressed as a URI address with access control.
[0109] The verification certificate is a digital certificate issued by the driver provider, which contains the hash fingerprint and signature information of the driver package and is used to verify the integrity and source credibility of the driver package.
[0110] In this embodiment, the management framework first extracts the storage path and verification certificate of the target driver from the driver information table, and then downloads the driver package (the compressed package contains the compiled driver implementation class and its dependent library) from the specified path through the secure HTTPS protocol. After the download is complete, the framework uses the public key in the verification certificate to decrypt the digital signature of the driver package, compares the hash value in the signature with the hash value calculated by the actual file, and ensures that the driver package has not been tampered with during transmission. After the verification is passed, the system will add the driver package to the trusted resource library and continue to execute the loading process of the driver implementation class. This solution prevents malicious driver injection through cryptographic means. For example, when the MySQL driver is upgraded, it can effectively identify forged driver packages implanted with backdoors. The entire verification process is completed in memory and will not affect normal service availability.
[0111] In another embodiment of the present application, after returning the database access object to the client, the following steps may also be included: responding to the client's heartbeat detection request, detecting whether the database configuration information has changed; when it is detected that the database configuration information has changed, pushing an information change message to the client through the heartbeat channel to notify the client to update the locally cached database access object.
[0112] A heartbeat detection request is a survival status report sent by the client to the management framework periodically (30 seconds by default). The request is implemented through a lightweight ZK temporary node.
[0113] Information change messages are standardized notification messages generated by the management framework, containing key metadata such as change type (such as active / standby switchover, parameter adjustment), timestamp, and version number.
[0114] In this embodiment, when the client initiates a heartbeat request, the management framework compares the current version number of the configuration management table in ZK with the version number of the client's local record. If any inconsistency is found, the change content (such as modification of the database address, port or authentication information) will be scanned immediately, and then the change message will be pushed through the pre-established TCP long connection channel (i.e., "heartbeat channel"). After the client receives the message, it will decide whether to immediately rebuild the access object (such as address change) or delay the update until the next access (such as parameter optimization) based on the type of change. For example, when the Doris database is upgraded from version 1.1 to version 1.2, all clients can complete the driver switch in seconds to ensure that the business is not perceived. Throughout the process, the heartbeat channel can use two-way authentication and message encryption to prevent the leakage of configuration information.
[0115] This solution first ensures that all clients can automatically keep in sync when the database configuration is updated, completely resolving the data access anomaly problem caused by configuration inconsistencies in traditional solutions; secondly, it uses a lightweight communication mechanism to achieve efficient configuration synchronization, significantly reducing system resource consumption; finally, it builds a reliable configuration distribution system through secure channels and strict version control to effectively prevent security risks and ensure configuration consistency, achieving imperceptible database operation and maintenance changes and rapid fault recovery capabilities, so that the business system remains continuously available during database maintenance.
[0116] In addition, in another embodiment of the present application, the method may further include the following steps: receiving driver information and configuration information of the extended database, the driver information including a driver interface program, and the configuration information including a service address, a service port, and permission information; writing the driver information into the driver information table, and assigning a new instance number to the extended database; writing the configuration information into the configuration management table, and establishing a corresponding relationship with the new instance number; wherein, when the client accesses the extended database through the new instance number, steps 101-104 are executed.
[0117] An extended database refers to a third-party or new database system that is not natively supported by the management framework. Its driver information and configuration information need to be standardized.
[0118] The driver interface program refers to the connector implementation that complies with the framework specifications and is provided by the extended database. It usually exists in the form of a JAR package or a dynamic link library and must contain the necessary interface classes and method definitions.
[0119] In this embodiment, the management framework receives the extended database component package submitted by the user through a secure upload channel, decompresses it, analyzes it, and verifies its integrity, then stores the driver binary file in the distributed file system and registers the driver metadata (including the entry class name, dependency library list, etc.) in the driver information table; the configuration information is encrypted and written into the dedicated partition of the configuration management table, and is assigned a globally unique instance number. The entire registration process uses a transaction mechanism to ensure data consistency. For example, when the configuration information fails to be written, the stored driver file will be automatically rolled back. In this way, new databases such as the time series database IoTDB and the graph database Neo4j can be quickly connected to the unified management framework. For example, a manufacturer's customized distributed database only needs to provide a driver package that complies with the specifications to obtain dynamic assembly, fault switching and other capabilities that are completely equivalent to the native support database, significantly improving the framework's expansion adaptability. The system will perform compatibility tests on newly registered extended databases to ensure that they meet minimum performance and security standards.
[0120] The technical solution provided by the embodiment of the present application, first, adopts a centralized configuration management table and driver information table to solve the system bloat problem caused by the independence of the access logic of each database, so that when adding a new database type, it is only necessary to register the driver and configuration information without modifying the application code, which greatly improves the scalability of the system; secondly, through the technology of dynamically assembling database access objects, while maintaining the native interface capabilities of each database, the access interface is standardized, and it can be fully compatible with the unique functions of various mainstream databases; finally, the configuration hot update capability based on this architecture makes it unnecessary to restart the application when the database fails or the version is upgraded, which significantly shortens the system recovery time and greatly improves the system availability.
[0121] Figure 3 A flowchart of another embodiment of database access management provided in an embodiment of the present application. Figure 3 The process shown in Figure 1 Based on the process shown, the following steps are included:
[0122] Step 301: Continuously monitor the availability status of the target database;
[0123] Step 302: When it is detected that the target database becomes unavailable, query the disaster recovery database configuration information corresponding to the target database from the disaster recovery configuration information table, where the disaster recovery configuration information table is associated with the configuration management table through an instance number;
[0124] Step 303: re-assemble a new database access object based on the disaster recovery database configuration information;
[0125] Step 304: Return the reassembled database access object to the client.
[0126] For ease of understanding, steps 301-304 are described below in a unified manner:
[0127] The disaster recovery configuration information table is a dedicated data structure maintained by the management framework in ZooKeeper. It is used to store the disaster recovery cluster information corresponding to each database instance. It establishes a strong association with the configuration management table through the instance number to ensure the consistency of the primary and backup configurations.
[0128] An unavailable state refers to an abnormal state of database service determined by the management system through heartbeat detection, connection testing, and performance indicator data analysis. This includes various types of failures such as network interruption, service crash, or performance degradation.
[0129] In an embodiment of the present application, the management framework implements three-dimensional health monitoring (network accessibility, service responsiveness, and transaction execution success rate) of the target database by deploying probe nodes in multiple availability zones, and triggers the disaster recovery switching process when multiple consecutive detection failures occur.
[0130] Specifically, first, the preset disaster recovery cluster configuration (such as the MySQL slave library address of the remote disaster recovery center) is queried from the disaster recovery configuration information table according to the instance number, and then the driver reassembly process is automatically executed: including disaster recovery driver loading (which may be different from the main library driver version), connection parameter adaptation and access policy adjustment (such as changing to read-only mode). The newly generated access object will be pushed to the client through a secure channel and marked as "disaster recovery mode". All subsequent operations of the client will be automatically routed to the disaster recovery database. For example, when the power outage occurs in the Beijing main library computer room, the Shanghai disaster recovery cluster can take over all requests within seconds, and the client application is unaware. The entire switching process ensures that the ACID characteristics are not damaged, and the eventual consistency of the data is guaranteed through the transaction log synchronization mechanism.
[0131] This solution first builds a full-dimensional health assessment system that can accurately identify abnormal conditions of various databases and ensure the accuracy of fault judgment; secondly, it relies on pre-registered disaster recovery configuration information to achieve business continuity protection in seconds, completely eliminating the manual intervention delays in traditional solutions; finally, through transparent access object hot replacement technology, the client automatically switches to the disaster recovery system without perception, ensuring high service availability while maintaining the integrity and consistency of transaction processing.
[0132] Figure 4 A flowchart of another embodiment of database access management provided in an embodiment of the present application. Figure 4 The process shown in Figure 1 Based on the process shown, the following steps are included:
[0133] Step 401: collecting performance indicator data of the target database through the database access object;
[0134] Step 402: If any of the performance indicator data exceeds the corresponding threshold in the configuration management table, adjust the connection parameters according to the preset rules;
[0135] Step 403: Push the updated connection parameters to the client via the heartbeat channel.
[0136] For ease of understanding, steps 401-403 are described below in a unified manner:
[0137] Performance indicator data refers to three types of core data collected when the database access object is running: the number of active connections reflects the current database load pressure, the average response time measures the query execution efficiency, and the query error rate monitors service stability.
[0138] Connection parameters specifically refer to adjustable variables that affect database connection behavior, including configurable items such as connection pool size, request timeout duration, and transaction retry count.
[0139] In this embodiment, the management framework continuously collects performance indicator data and performs sliding window analysis (such as the average response time trend within 5 minutes) by implanting monitoring probes in the database access object. When any indicator exceeds the threshold (such as the number of connections exceeds 80% of the maximum load), the system automatically triggers the parameter optimization engine: first, the best adjustment strategy is selected according to the rule base (such as expanding the connection pool capacity by 20%), and then the changes are safely implemented in the operating environment (using rolling updates to avoid connection interruptions), and finally the new parameters are encrypted and pushed to the client through the existing heartbeat channel. For example, when a sudden business peak causes the MySQL query delay to increase, the system can automatically optimize the connection parameters to improve the overall throughput, and at the same time ensure that all clients are updated synchronously through the heartbeat mechanism to avoid performance fluctuations caused by inconsistent configurations.
[0140] This solution ensures that all clients can adapt to database load changes in a timely manner and maintain optimal access performance without manual intervention.
[0141] Figure 5 This is a block diagram of an embodiment of a database access management device provided in an embodiment of the present application. Figure 5 As shown, the device includes:
[0142] The receiving module 51 is configured to receive a database access request sent by a client, wherein the database access request includes an instance number of a target database;
[0143] A first query module 52 is used to query the corresponding database configuration information in a preset configuration management table according to the instance number;
[0144] A second query module 53 is configured to query a corresponding target driver in a preset driver information table according to the database configuration information;
[0145] The assembly module 54 is configured to dynamically assemble a database access object according to the target driver and return the database access object to the client, so that the client can directly access the target database through the database access object.
[0146] In a possible implementation, the device further includes a disaster recovery switching module, configured to:
[0147] Continuously monitoring the availability status of the target database;
[0148] In the case where it is monitored that the target database becomes unavailable, querying the disaster recovery database configuration information corresponding to the target database from the disaster recovery configuration information table, wherein the disaster recovery configuration information table is associated with the configuration management table through an instance number;
[0149] Reassembling a new database access object based on the disaster recovery database configuration information;
[0150] The reassembled database access object is returned to the client.
[0151] In one possible implementation, the device further includes a changing module, configured to:
[0152] In response to a heartbeat detection request from the client, detecting whether the database configuration information has changed;
[0153] When a change in the database configuration information is detected, an information change message is pushed to the client through the heartbeat channel to notify the client to update the database access object cached locally.
[0154] In one possible implementation, the assembly module is specifically configured to:
[0155] When receiving a database access request sent by the client for the first time, performing a basic assembly operation to generate a database access object containing only basic functions;
[0156] When the client performs a database operation for the first time, the extended function module required for the current database operation is detected, and the extended function module is injected into the generated database access object.
[0157] In one possible implementation, the assembly module is further configured to:
[0158] Detecting the version requirement of the client operating environment;
[0159] Matching a driver implementation class that meets the version requirement from the target driver;
[0160] The driver implementation class is loaded to generate the database access object.
[0161] In one possible implementation, the assembly module is further configured to:
[0162] Extracting the storage path and verification certificate of the target driver from the driver information table;
[0163] Downloading a driver package corresponding to the target driver according to the storage path, wherein the driver package includes the driver implementation class;
[0164] Verifying the integrity of the driver package using the verification certificate;
[0165] After the verification is passed, the step of loading the driver implementation class to generate the database access object is executed.
[0166] In one possible implementation, the device further includes an updating module, configured to:
[0167] Collecting performance indicator data of the target database through the database access object;
[0168] When any of the performance indicator data exceeds the corresponding threshold in the configuration management table, the connection parameters are adjusted according to the preset rules;
[0169] Push the updated connection parameters to the client via the heartbeat channel.
[0170] like Figure 6 As shown, an embodiment of the present application provides a device, including a processor 111, a communication interface 112, a memory 113 and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114.
[0171] Memory 113, for storing computer programs;
[0172] In one embodiment of the present application, the processor 111 is configured to execute a program stored in the memory 113 to implement the database access management method provided by any of the aforementioned method embodiments, including:
[0173] Receive a database access request sent by a client, wherein the database access request includes an instance number of a target database;
[0174] Querying the corresponding database configuration information in a preset configuration management table according to the instance number;
[0175] Querying a corresponding target driver in a preset driver information table according to the database configuration information;
[0176] A database access object is dynamically assembled according to the target driver, and the database access object is returned to the client, so that the client can directly access the target database through the database access object.
[0177] An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the database access management method provided in any of the aforementioned method embodiments are implemented.
[0178] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.
[0179] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general hardware platform, or of course, by hardware. Based on this understanding, the above technical solution, in essence, or the part that contributes to the relevant technology, can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or certain parts of the embodiment.
[0180] It should be understood that the terms used herein are for the purpose of describing specific example embodiments only and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "comprise", "include", "contain" and "have" are inclusive and therefore specify the presence of stated features, steps, operations, elements and / or parts, but do not exclude the presence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring them to be performed in the specific order described or illustrated, unless the order of execution is clearly indicated. It should also be understood that additional or alternative steps may be used.
[0181] The foregoing is merely a list of specific embodiments of the present application, intended to enable those skilled in the art to understand or implement the present application. 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 the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the broadest scope consistent with the principles and novel features of the present application.
Claims
1. A database access management method, characterized in that: The method comprises: Receive a database access request sent by a client, wherein the database access request includes an instance number of a target database; Querying the corresponding database configuration information in a preset configuration management table according to the instance number; Querying a corresponding target driver in a preset driver information table according to the database configuration information; A database access object is dynamically assembled according to the target driver, and the database access object is returned to the client, so that the client can directly access the target database through the database access object.
2. The method according to claim 1, characterized in that After returning the database access object to the client, the method further includes: Continuously monitoring the availability status of the target database; In the case where it is monitored that the target database becomes unavailable, querying the disaster recovery database configuration information corresponding to the target database from the disaster recovery configuration information table, wherein the disaster recovery configuration information table is associated with the configuration management table through an instance number; Reassembling a new database access object based on the disaster recovery database configuration information; The reassembled database access object is returned to the client.
3. The method according to claim 1, characterized in that After returning the database access object to the client, the method further includes: In response to a heartbeat detection request from the client, detecting whether the database configuration information has changed; When a change in the database configuration information is detected, an information change message is pushed to the client through the heartbeat channel to notify the client to update the database access object cached locally.
4. The method according to claim 1, wherein The step of dynamically assembling a database access object according to the target driving comprises: When receiving a database access request sent by the client for the first time, performing a basic assembly operation to generate a database access object containing only basic functions; When the client performs a database operation for the first time, the extended function module required for the current database operation is detected, and the extended function module is injected into the generated database access object.
5. The method according to claim 1, wherein The step of dynamically assembling a database access object according to the target driving comprises: Detecting the version requirement of the client operating environment; Matching a driver implementation class that meets the version requirement from the target driver; The driver implementation class is loaded to generate the database access object.
6. The method according to claim 5, characterized in that Before loading the driver implementation class to generate the database access object, the method further includes: Extracting the storage path and verification certificate of the target driver from the driver information table; Downloading a driver package corresponding to the target driver according to the storage path, wherein the driver package includes the driver implementation class; Verifying the integrity of the driver package using the verification certificate; After the verification is passed, the step of loading the driver implementation class to generate the database access object is executed.
7. The method according to claim 1, characterized in that After returning the database access object to the client, the method further includes: Collecting performance indicator data of the target database through the database access object; When any of the performance indicator data exceeds the corresponding threshold in the configuration management table, the connection parameters are adjusted according to the preset rules; Push the updated connection parameters to the client via the heartbeat channel.
8. A database access management device, characterized in that: The device comprises: A receiving module, configured to receive a database access request sent by a client, wherein the database access request includes an instance number of a target database; A first query module is used to query the corresponding database configuration information in a preset configuration management table according to the instance number; A second query module is used to query the corresponding target driver in the preset driver information table according to the database configuration information; The assembly module is used to dynamically assemble a database access object according to the target driver and return the database access object to the client, so that the client can directly access the target database through the database access object.
9. A device, characterized in that include: A processor and a memory, wherein the processor is configured to execute a database access management program stored in the memory to implement the database access management method according to any one of claims 1 to 7.
10. A storage medium, characterized in that: The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the database access management method according to any one of claims 1 to 7.
Citation Information
Patent Citations
Database access control method, device and system
CN114896626A
Data access method and device, storage medium and program product
CN116955420A
Database access method and device and electronic equipment
CN119536844A
Retrieval message protocol conversion gateway system
JP1999154158A