Database migration method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of databases, can be applied to the field of science and technology finance / digital medical treatment, and discloses a database migration method and device, electronic equipment and a storage medium. The method comprises the steps that database structured query language identifiers are defined, strategy classes corresponding to all databases are packaged, and a strategy context management container is created; receiving a target database type, dynamically loading a strategy type instance according to the type, and generating an executable query strategy chain according to the strategy type instance; when a database query request is received, matching a corresponding strategy type instance, and processing an original database query statement to generate a target database executable instruction; controlling a query strategy chain to execute a single-path or double-write-path mode through a common switch, and transmitting the instruction to a strategy type instance for execution; and analyzing a return result of the target database, performing conversion adaptation through the strategy type instance, and returning a conversion adaptation result. The method realizes automatic migration, reduces cost and risk, and improves system performance.

Description

Technical Field

[0001] The present application relates to the field of database technology and can be applied to the fields of technology finance / digital medicine, and in particular to a database migration method, device, electronic device and storage medium. Background Art

[0002] Database "de-O" generally refers to the process of migrating Oracle-based systems to alternative technology stacks such as MySQL and PostgreSQL. This requires addressing core issues such as migrating SQL query logic and adapting to heterogeneous data sources. The traditional "interface replacement" approach achieves this by developing corresponding APIs for each SQL statement. However, in sectors such as finance and healthcare, which place high demands on stability and compliance, this approach presents several challenges. Each SQL statement requires a separate interface, leading to an exponential increase in the number of interfaces. For example, during the core system migration of a provincial bank, over 200 customer account query SQL statements required the development of an equivalent number of interfaces, extending the development cycle from four to ten months. Later, regulatory requirements for field adjustments necessitated simultaneous code modifications across over 200 interface lines across five business systems, increasing labor costs by 200%. Interface failures directly impact business continuity. For example, due to a missing exception handling interface in the testing system of a regional medical platform, intermittently returned erroneous data, impacting the diagnoses of over 1,200 patients within a week. Data delays led to misdiagnoses in three cases. The core bottleneck of existing technologies lies in the lack of abstraction and unified management mechanisms for SQL logic. Instead, they adopt a "point-to-point" migration model that deeply binds database operations with business logic, leading to a rigid system architecture. In scenarios such as finance and healthcare, their inefficient development, complex maintenance, and delayed expansion not only directly impact business efficiency but are also likely to trigger compliance risks and technical security incidents. Summary of the Invention

[0003] The main technical problems solved by the implementation methods of this application are the large amount of development and maintenance, poor stability, logical duplication and insufficient scalability in traditional database de-O migration.

[0004] To solve the above technical problems, the first technical solution adopted by the embodiment of the present application is: providing a database migration method, including: defining structured query language identifiers of different databases to be migrated, wherein the database structured query language identifiers are used to represent different database query functions; encapsulating the query statement conversion, execution and result mapping logic of each database into a corresponding policy class, creating a mapping relationship between the database structured query language identifier and the policy class, and a policy context management container; receiving a target database type input by a target business system, dynamically loading a policy class instance of the corresponding policy class according to the target database type, and generating an executable query policy chain according to the policy class instance through the policy context management container; When a database query request initiated by the target business system is received, the policy context management container matches the policy class instance according to the database structured query language identifier, and processes the original database query statement through the matched policy class instance to generate an executable instruction for the target database; the query strategy chain is controlled to execute a single path or a dual write path mode through a pre-configured common switch, and the target database executable instruction is passed to the corresponding policy class instance for execution, and the execution path is automatically switched according to the real-time monitored performance indicators; the return result of the target database is parsed, and the corresponding policy class instance is called through the policy context management container for conversion and adaptation, and the conversion and adaptation result is returned to the target business system.

[0005] Optionally, the step of controlling the query strategy chain to execute a single path or dual write path mode through a pre-configured common switch, and transferring the target database executable instruction to the corresponding strategy class instance for execution, and automatically switching the execution path according to the real-time monitored performance indicators, includes: when the common switch is configured as a single path mode, sending the target database executable instruction to the strategy class instance corresponding to the target database for execution through the query strategy chain; when the common switch is configured as a dual write path mode, sending the target database executable instruction to the old database and the strategy class instance corresponding to the target database in parallel through the query strategy chain for execution, and The result mapping logic verifies the consistency of the results returned by the database; collects the corresponding response time, error rate and throughput indicator data in the single path mode and the dual write path mode according to a preset sampling period; when the query response time for a preset first number of consecutive times in the single path mode exceeds a preset first time threshold, and / or the error rate exceeds a preset first ratio threshold, switches the common switch to the dual write path mode; when the consistency of the return results of the old database and the target database in the dual write path mode reaches a preset second ratio threshold for a consecutive preset second number of times, and the response time of the target database is lower than a preset third ratio threshold of the response time of the old database, switches the common switch to the single path mode.

[0006] Optionally, the step of calling the corresponding policy class instance through the policy context management container for conversion and adaptation, and returning the conversion adaptation result to the target business system, includes: when the target database is a relational database, converting the returned table structure data into an object list that conforms to the data model of the target business system through the policy class instance, wherein the first rule of conversion includes field mapping, data type conversion and null value processing; when the target database is a non-relational database, converting the returned unstructured data into an object list that conforms to the data model of the target business system through the policy class instance, wherein the second rule of conversion includes tree structure linearization, collection data processing and association relationship analysis; if the common switch is the dual-write path mode, then after conversion and adaptation, the returned conversion adaptation result is secondary verified through the result comparison logic in the policy class instance, wherein the verification rules include business field comparison, collection element comparison and business rule verification.

[0007] Optionally, the step of receiving the target database type input by the target business system, dynamically loading the corresponding policy class instance of the policy class according to the target database type, and generating an executable query policy chain according to the policy class instance through the policy context management container includes: based on the target database type, searching for the corresponding policy class from the pre-configured policy class and database type mapping relationship; creating the policy class instance through the system's built-in class loading mechanism, and setting database connection information, configuration parameters and common dependency components for the policy class instance; determining the different stages of query execution according to the target database type, and assigning a corresponding policy class instance to each query stage; combining the policy class instances into an orderly processing flow in the order of execution, and passing the processing results of the previous stage to the next stage for further processing in the processing flow; performing data caching processing on the created policy class instance, wherein the cache identifier is composed of the target database type and the information of the policy class; when a new database query request is received, obtaining the matching policy class instance from the cache, and recreating it if it does not exist in the cache, and setting the cache validity time and maximum capacity.

[0008] Optionally, after the step of calling the corresponding policy class instance through the policy context management container for conversion and adaptation, and returning the conversion and adaptation result to the target business system, it includes: monitoring the execution load of the policy class instance in real time through a preset runtime optimization module; when it is detected that the load of the policy class instance exceeds a preset threshold, creating a new policy class instance corresponding to the policy class; allocating new database query requests to the new policy class instance, and dynamically adjusting the proportion of each policy class instance allocated through weighted polling or minimum connection number algorithm.

[0009] Optionally, after the step of assigning new database query requests to the new strategy class instance and dynamically adjusting the proportion of each strategy class instance assigned through weighted polling or a minimum connection number algorithm, the method further includes: obtaining request feature information data, execution path data, and performance data of historical database query requests; constructing a query execution path optimization model based on the request feature information data, the execution path data, and the performance data, wherein the query execution path optimization model establishes a mapping relationship between query features and optimal execution paths through statistical analysis or a machine learning algorithm; when a new database query request is received, predicting the optimal execution path corresponding to the new database query request through the query execution path optimization model, and switching the common switch according to the obtained optimal execution path; regularly using the newly added request feature information data, the execution path data, and the performance data to update and train the query execution path optimization model, and using the updated training results to update the currently running query execution path optimization model.

[0010] Optionally, after the step of calling the corresponding policy class instance through the policy context management container for conversion and adaptation, and returning the conversion and adaptation result to the target business system, it also includes: when receiving a database query request with multiple table associations, analyzing the foreign key relationship, data dependency path and business semantic association between tables through the pre-deployed knowledge graph system; based on the analysis results, screening out the optimal policy class combination from the policy context management container, and generating a corresponding customized migration strategy chain according to the optimal strategy class combination, and using the customized migration strategy to replace the generated query strategy chain; when generating the target database executable instructions, automatically completing the missing association conditions and constraints based on the semantic information stored in the knowledge graph system; performing a semantic consistency check on the generated target database executable instructions to verify whether they comply with the business rules predefined in the knowledge graph.

[0011] In order to solve the above technical problems, the second technical solution adopted by the embodiment of the present application is: to provide a database migration device, including: a query language identification module, used to define the structured query language identifiers of different databases to be migrated, wherein the database structured query language identifiers are used to represent different database query functions; a context management container module, used to encapsulate the query statement conversion, execution and result mapping logic of each database into a corresponding policy class, create a mapping relationship between the database structured query language identifier and the policy class, and a policy context management container; a query policy chain module, used to receive the target database type input by the target business system, dynamically load the corresponding policy class instance of the policy class according to the target database type, and generate an executable query policy chain according to the policy class instance through the policy context management container; An executable command module is used to, when receiving a database query request initiated by the target business system, match the policy class instance according to the database structured query language identifier through the policy context management container, and process the original database query statement through the matched policy class instance to generate a target database executable instruction; a public gateway management module is used to control the query strategy chain to execute a single path or dual write path mode through a pre-configured public switch, and pass the target database executable instruction to the corresponding policy class instance for execution, and automatically switch the execution path according to the real-time monitored performance indicators; a conversion and adaptation result module is used to parse the return result of the target database, call the corresponding policy class instance through the policy context management container for conversion and adaptation, and return the conversion and adaptation result to the target business system.

[0012] To solve the above technical problems, the third technical solution adopted in the embodiment of the present application is: to provide an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the database migration method as described above.

[0013] In order to solve the above technical problems, the fourth technical solution adopted in the embodiment of the present application is: providing a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions. When the computer-executable instructions are executed by an electronic device, the electronic device executes the database migration method as described above.

[0014] Unlike related technologies, this application uses standardized SQL identifiers to mask differences in heterogeneous databases and achieve cross-database compatibility. Policy class encapsulation and dynamic mapping improve code maintainability, while dynamic policy chaining and cache management optimize resource utilization. Dual-path execution and real-time monitoring ensure business continuity, while differentiated conversion and validation ensure data quality. Multi-layered technology collaboration enables automated migration, reduces cost risks, and improves system performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] One or more embodiments are exemplarily illustrated by corresponding drawings, which do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0016] Figure 1 This is a schematic diagram of the operating environment of the database migration method provided in the embodiment of the present application.

[0017] Figure 2 This is a schematic diagram of the execution flow of the database migration method provided in an embodiment of the present application.

[0018] Figure 3 This is a schematic diagram of the execution flow of generating an executable query strategy chain in the database migration method provided in an embodiment of the present application.

[0019] Figure 4 This is a schematic diagram of the execution flow of a policy class instance in the database migration method provided in an embodiment of the present application.

[0020] Figure 5 Schematic diagram of the system structure of the database migration device provided in the embodiment of the present application.

[0021] Figure 6 Schematic diagram of the hardware structure of an electronic device for executing the database migration method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0023] It should be noted that, if there is no conflict, the various features in the embodiments of the present application can be combined with each other and are all within the scope of protection of the present application. In addition, although the functional modules are divided in the device schematics and the logical order is shown in the flow charts, in some cases, the steps shown or described can be performed in a different order than the module division in the device schematics or the order in the flow charts.

[0024] Unless otherwise defined, all technical and scientific terms used in this specification have the same meanings as those commonly understood by those skilled in the art to which this application belongs. The terms used in this specification are intended only to describe specific embodiments and are not intended to limit this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the relevant listed items.

[0025] To facilitate understanding of this embodiment, a database migration method disclosed in the embodiment of this application is first introduced in detail. Figure 1 , Figure 1 This is a schematic diagram of the operating environment of the database migration method provided in the embodiment of the present application. Figure 1 As shown, the execution subject of the database migration method provided in the embodiment of the present application is generally an electronic device with certain computing capabilities, such as a computer device. In some possible implementations, the database migration method can be implemented by a processor calling computer-readable instructions stored in a memory. Figure 1 The computer device in the above can be a server. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. It can be understood that Figure 1 The number of computer devices in the figure is only for reference and can be expanded to any number according to actual needs.

[0026] Please continue reading Figure 2 , Figure 2 This is a schematic diagram of the execution flow of the database migration method provided in the embodiment of the present application. Figure 2 As shown, the following steps are included:

[0027] S1. Define different database structured query language identifiers to be migrated, where the database structured query language identifiers are used to represent different database query functions.

[0028] Among them, the technical purpose of step S1 is to establish a standardized SQL function label system for uniformly describing the query functions of different databases (for example, MySQL, Oracle, PostgreSQL, etc.) and shielding the differences in the underlying database syntax. Specifically, first analyze the syntax characteristics of the source database and the target database, and extract common query functions (for example, data query, insert, update, multi-table association, transaction control, etc.). Then, assign a unique identifier to each function (for example, "SQL-SELECT-JOIN" represents a multi-table join query) to form a mappable function dictionary.

[0029] As an example, in the scenario where a bank's core system is migrated from Oracle to GoldenDB, it is necessary to define the "SQL-TRAN-FINANCIAL-UPDATE" identifier to specifically represent account balance update operations involving transaction control (for example, the deduction and addition of funds in transfer transactions must ensure atomicity). At the same time, the "SQL-QUERY-FINANCIAL-REPORT" identifier is defined to describe financial report queries that involve multiple tables (for example, linking the customer table, account table, and transaction flow table to generate an asset and liability report). The core query functions in financial services are abstracted through standardized identifiers.

[0030] As another example, when a hospital migrates its imaging system from SQL Server to PostgreSQL, it needs to define the "SQL-INSERT-MEDICAL-RECORD" identifier to represent the insertion operation of patient medical records containing binary imaging data (for example, CT / MRI files), and define the "SQL-QUERY-MEDICAL-TIMESERIES" identifier for time series queries of patient vital signs data (for example, aggregating temperature and blood pressure data by date). The identifiers unify special query requirements in medical scenarios.

[0031] S2. Encapsulate the query statement conversion, execution, and result mapping logic of each database into the corresponding strategy class, create a mapping relationship between the database structured query language identifier and the strategy class, and a strategy context management container.

[0032] Among them, the technical purpose of step S2 is to encapsulate the core logic of database migration (syntax conversion, execution control, result adaptation, etc.) into a reusable strategy class, realize the dynamic binding of SQL identifiers and strategies through mapping relationships, and manage the strategy life cycle through containers. For example, the conversion of source database syntax to target database syntax is realized (for example, converting Oracle's PL / SQL functions to PostgreSQL functions), adapting the data types of the source and target databases (for example, converting Oracle's DATE to MySQL's DATETIME), and the result set format (such as column name case conversion). Establish a mapping of "SQL identifier → strategy class combination" (for example, "SQL-SELECT-JOIN" corresponds to "conversion strategy class A + execution strategy class B"). The strategy context management container is used to store strategy class instances, dynamically load / unload strategies, and manage dependencies between strategies (for example, run the conversion strategy first, then run the execution strategy).

[0033] As an example, when migrating a securities trading system to the OceanBase distributed database, it is necessary to encapsulate a "stored procedure conversion strategy class" to convert the Oracle stored procedure used to calculate trading commissions into an OceanBase distributed function to handle the sharding logic. This class also encapsulates a "high-concurrency execution strategy class" to implement read-write separation and connection pool optimization. The "SQL-TRAN-FINANCIAL-UPDATE" flag is mapped to this strategy class to ensure transaction consistency and query performance in high-concurrency scenarios.

[0034] As another example, when migrating a medical insurance settlement system from a traditional database to AWS Aurora, it is necessary to encapsulate a "CLR function conversion strategy class" to convert the CLR integration functions used in SQL Server for medical insurance rule calculations into PostgreSQL UDFs. A "medical code mapping strategy class" is also encapsulated to handle the mapping of source database enumeration values ​​(for example, "1 = normal") to target database status codes (for example, "N"). The "SQL-QUERY-MEDICAL-TIMESERIES" identifier is bound to the aforementioned strategy class to achieve cross-database adaptation of medical insurance calculation logic and consistency verification of data standards.

[0035] S3. Receive the target database type input by the target business system, dynamically load the policy class instance of the corresponding policy class according to the target database type, and generate an executable query policy chain according to the policy class instance through the policy context management container.

[0036] Among them, step S3 aims to achieve dynamic policy adaptation during the database migration process. First, the target database type specified by the target business system (for example, MySQL, SQL Server, etc.) is received, and then the type is used as an index to dynamically locate and load the matching policy class instance in the policy class library. The aforementioned instance contains the query statement conversion, execution and result mapping logic for a specific database. Finally, the loaded policy class instance is orchestrated through the policy context management container, and is connected in series into an executable query policy chain according to the business process of data migration (for example, data extraction, conversion, verification, and writing), ensuring that operations between different databases can be executed automatically and in a standardized manner, thereby shielding the underlying database differences and improving migration efficiency and compatibility.

[0037] As an optional implementation, see Figure 3 , Figure 3 This is a schematic diagram of the execution flow of generating an executable query strategy chain in the database migration method provided in the embodiment of the present application, such as Figure 3 As shown, the following steps S31 to S36 may be included.

[0038] S31. Based on the target database type, a corresponding policy class is searched from a pre-configured mapping relationship between policy classes and database types.

[0039] Among them, step S31 is the initial link of dynamic policy loading. First, the target database type input by the target business system (for example, when migrating from SQL Server to PostgreSQL, PostgreSQL is the target type) is used as the query condition and searched in the pre-built "database type-policy class" mapping table. This mapping table records the correspondence between each database type and the policy class required to process its characteristics (for example, PostgreSQL needs to adapt to the conversion policy class of its function syntax). By accurately matching the target type, the policy class set required for subsequent migration tasks can be quickly located, laying a technical foundation for subsequent instance creation and policy chain generation.

[0040] S32. Create a policy class instance through the system's built-in class loading mechanism, and set database connection information, configuration parameters and common dependent components for the policy class instance.

[0041] Among them, step S32 instantiates and initializes the retrieved policy class. Use the built-in class loading mechanism (such as Java's ClassLoader) to dynamically create a running instance of the policy class, so that the instance has executable capabilities. At the same time, inject key operating parameters into each instance: including database connection information (such as IP address, port, username and password) to establish communication with the target database. Configuration parameters (such as character encoding, transaction isolation level) to ensure that the query complies with the target library specifications. And public dependency components (such as database drivers, logging tools) to ensure the normal operation of the instance. Through instantiation and parameter configuration, the policy class is transformed from a code definition to an execution unit that can handle actual migration tasks.

[0042] S33. Determine different stages of query execution according to the target database type, and allocate a corresponding strategy class instance to each query stage.

[0043] Among them, step S33 performs modular disassembly and allocation of the strategy chain. According to the characteristics of the target database (for example, data storage structure, query optimization rules), the complete query execution process is divided into multiple logical stages (for example, data reading, format conversion, and writing to the target database). Each stage corresponds to specific processing requirements and needs to match different strategy class instances. For example, the data reading stage is assigned a "source database query strategy class", the data conversion stage is assigned a "data format adaptation strategy class", and the writing stage is assigned a "target database write strategy class". By allocating instances on demand, it is ensured that each link in the migration process is handled by the most suitable strategy class, thereby improving execution efficiency and accuracy.

[0044] S34. Combining the strategy class instances into an orderly processing flow in the order of execution, and passing the processing results of the previous stage to the next stage for further processing in the processing flow.

[0045] Among them, step S34 realizes the concatenation of strategy class instances and data flow. According to the standard business logic of database migration (for example, extract data first, then convert the format, and finally write), the assigned strategy class instances are arranged into an ordered query strategy chain. During the execution process, after each strategy class instance completes the current task, it will pass the output result as an input parameter to the next instance, forming a data processing pipeline. For example, after the data extraction strategy class obtains the source library data, it passes the result to the data conversion strategy class for format adjustment, and then the writing strategy class stores the converted data into the target library. Through this sequential execution and data transfer mechanism, the integrity and consistency of complex migration tasks are ensured.

[0046] S35. Perform data caching processing on the created policy class instance, wherein the cache identifier is composed of the target database type and policy class information.

[0047] Among them, step S35 improves system performance through a caching mechanism. The created and initialized policy class instances are stored in the cache to avoid resource consumption caused by repeated creation. The cache identifier uses a combination of "target database type + policy class information" (for example, "PostgreSQL-data conversion policy class") to ensure the uniqueness of each instance in the cache. Through caching, when subsequent query requests involve the same database type and policy class, instances can be obtained directly from the cache, tasks can be responded to quickly, and the time overhead of instance creation can be reduced. It is especially suitable for high-frequency and repetitive database migration operation scenarios.

[0048] S36. When a new database query request is received, a matching policy class instance is obtained from the cache. If it does not exist in the cache, it is recreated. At the same time, the cache validity period and maximum capacity are set.

[0049] Among them, step S36 improves the closed-loop logic of cache management. After receiving a new query request, the matching instance is retrieved in the cache based on the target database type and policy requirements in the request. If the cache hits, the instance is reused directly to improve execution efficiency. If it misses, the instance re-creation process is triggered (repeating steps S31 to S34). At the same time, in order to avoid infinite expansion of the cache, the cache validity period (for example, automatic expiration after 1 hour) and the maximum capacity (for example, a maximum of 100 instances can be stored) are set. When the cache reaches the threshold, the space is released through the elimination strategy (for example, LRU algorithm) to ensure efficient use of cache resources and system stability.

[0050] As an example, in a core system migration scenario at a bank, the original Oracle database needed to be replaced with GoldenDB, a domestic distributed database. After receiving the GoldenDB type specified by the target business system, it dynamically loaded the "sharding strategy class" and "transaction consistency strategy class" designed for the distributed architecture. Using the policy context management container, these strategy class instances were orchestrated into a complete query strategy chain encompassing data extraction, distributed syntax conversion, read / write load balancing, and cross-node transaction validation. Specifically, leveraging GoldenDB's distributed nature, sharding rules and connection parameters were injected into the strategy class instances, breaking down complex multi-table join queries into steps such as data shard extraction and cross-node function adaptation. These steps were executed sequentially to ensure even distribution of account data across different database nodes. Furthermore, the created strategy class instances were cached, stored using the "GoldenDB-Distributed Query Strategy" identifier. Subsequent requests for loan approvals, account balance inquiries, and other requests were prioritized and reused from the cache, avoiding the performance penalty associated with duplicate creation. This caching mechanism reduced query response times, especially during peak daily trading hours, ensuring the continuity and stability of core business operations.

[0051] As another example, a tertiary hospital implemented a database de-O transformation and migrated the electronic medical record system in the original Oracle database to MySQL. When the target database type is identified as MySQL, the "PL / SQL function conversion strategy class" and "binary data storage strategy class" are automatically loaded to build a query strategy chain that includes medical record data extraction, stored procedure syntax adaptation, image file format conversion and MySQL engine optimization. For Oracle-specific PL / SQL stored procedures (for example, the logic for calculating patient condition scores), they are converted into MySQL stored functions through strategy class instances, and character set mapping (for example, converting Oracle's NVARCHAR2 to MySQL's UTF8MB4) and index optimization parameters are configured for the instance. During the data migration process, the strategy chain processes data in the order of "extracting basic patient information → converting condition calculation logic → compressing and storing medical images → optimizing query execution plans" to ensure the integrity of medical record data and query performance. In addition, a cache strategy class instance is identified by "MySQL-Medical Record Migration Strategy". When a patient data query request is initiated by a terminal such as a nursing station or clinic, the instance is called directly from the cache. Combined with the set cache validity period (for example, 8 hours) and capacity limit, it not only improves the response speed of high-frequency queries, but also avoids migration delays caused by Oracle compatibility issues, meeting the hospital's 7×24 hours real-time data access needs.

[0052] Through the above steps S31 to S36, the automatic adaptation and efficient execution of strategies in the database migration process are realized by dynamically searching for strategy classes, instantiated configuration, phased allocation, ordered process combination, cache management and intelligent reuse mechanism. The strategy class is accurately matched based on the target database type, and the operation parameters are injected to ensure that the migration logic fits the database characteristics. The migration process is broken down into stages that can be processed independently and the corresponding strategy class instances are assigned to improve the modularity and flexibility of task processing. The integrity and consistency of complex queries are guaranteed by sequentially connecting strategy class instances and passing the processing results. The cache mechanism is used to uniquely identify and store strategy class instances to avoid resource consumption caused by repeated creation. The cache utilization rate is optimized by combining effective time and capacity control, so that the system can quickly reuse instances when facing high-frequency query requests, significantly reducing response time, improving migration efficiency and system stability, and effectively reducing performance loss in high-concurrency scenarios, ensuring the efficiency and reliability of database migration.

[0053] S4. When a database query request initiated by the target business system is received, the policy context management container identifies a matching policy class instance according to the database structured query language, and processes the original database query statement through the matching policy class instance to generate an executable instruction for the target database.

[0054] Specifically, when the target business system sends a database query request, it first parses the database Structured Query Language (SQL) identifiers in the request (e.g., syntax format, function type, operator, and other features). This identifier is then used as a matching key to retrieve a loaded policy class instance from the policy context management container. The policy class instance pre-encapsulates the syntax mapping rules, function conversion logic, and execution optimization strategies between the source and target databases (e.g., converting Oracle PL / SQL stored procedures to MySQL stored functions or adjusting SQL Server paging syntax to PostgreSQL LIMIT / OFFSET structures). The matching policy class instance parses, rewrites, and optimizes the original query statement, ultimately generating an executable instruction that conforms to the target database's syntax specifications and optimizes performance, achieving cross-database query compatibility. This process dynamically binds the policy class instance to the query request, avoiding the scalability limitations of hard-coding. The encapsulation nature of the policy class also enhances the flexibility and maintainability of converting between different database dialects, ensuring seamless migration of queries across heterogeneous databases without modifying the business system code, reducing migration costs and guaranteeing accurate and efficient query execution.

[0055] S5. Control the query strategy chain to execute a single path or dual write path mode through a pre-configured public switch, pass the target database executable instructions to the corresponding strategy class instance for execution, and automatically switch the execution path according to the real-time monitored performance indicators.

[0056] Among them, step S5 realizes execution path management and adaptive tuning during database migration through a public switch mechanism. Two modes of the public switch are pre-configured: single path mode (queries are executed only through the target database) and dual write path mode (queries are executed in parallel on the old and new databases). When a query request is received, the switch determines the execution path based on the current database performance status. The single path mode is used in the normal migration phase to improve efficiency, and the dual write path mode is used in the fault tolerance or verification phase to ensure data consistency. At the same time, path performance indicators (such as response time and error rate) are collected in real time, and the switch status is automatically switched based on preset rules to balance stability and efficiency during the migration process.

[0057] As an optional implementation, see Figure 4 , Figure 4 This is a schematic diagram of the execution flow of a strategy class instance in the database migration method provided in the embodiment of the present application, such as Figure 4 As shown, the following steps S51 to S55 may be included.

[0058] S51 : When the public switch is configured in a single path mode, the target database executable instruction is sent to the policy class instance corresponding to the target database for execution through the query policy chain.

[0059] When the public switch is in single-path mode, the target database's executable instructions are sent directly to the target database's corresponding policy instance through a generated query strategy chain. This instance is responsible for executing the instructions and returning the results. This is suitable for scenarios where the target database has stable performance and has passed dual-write verification. In this mode, the policy instance can further optimize the execution logic based on the characteristics of the target database (for example, leveraging its indexing mechanism to accelerate queries), avoiding performance bottlenecks in the legacy database and improving post-migration business processing efficiency. This is particularly suitable for core businesses with high real-time requirements (such as financial transactions and real-time medical data queries).

[0060] S52. When the common switch is configured in dual write path mode, the target database executable instructions are sent to the policy class instances corresponding to the old database and the target database in parallel through the query policy chain for execution, and the consistency of the results returned by the database is verified through the result mapping logic in the policy class.

[0061] In dual-write path mode, the query strategy chain sends the same instruction in parallel to the corresponding strategy class instances of the old and new databases, enabling synchronous query execution. The result mapping logic in the strategy class performs consistency checks on the results returned from both paths (for example, data value comparison and field order matching) to ensure that there is no data loss or inconsistency during the migration process. This mode is mainly used in the migration transition phase. For example, when the target database is first launched, the correctness of the migration is verified by executing the old and new databases in parallel, while recording the difference data to correct the strategy class, providing reliability guarantees for the eventual switch to a single path.

[0062] S53 , collecting corresponding response time, error rate, and throughput indicator data in the single-path mode and the dual-write path mode according to a preset sampling period.

[0063] For example, AOP aspect technology is used to embed points at the entry and exit of query requests, calculate the time it takes from sending instructions to receiving results, and use a sliding window algorithm to calculate the mean and quantile. Capture exceptions during the execution of strategy class instances (for example, SQL syntax errors, connection timeouts), and calculate the proportion of failed requests by time window. The token bucket algorithm is used to count the number of query requests successfully processed per unit time, and the system load is evaluated in combination with the status of the database connection pool. The aforementioned indicators are written to a time series database (for example, Prometheus) in real time, and customized alarm rules (for example, an alarm is triggered when the response time exceeds the threshold) provide data support for path switching decisions, ensuring that the system can quickly perceive fluctuations in database performance.

[0064] S54: When the query response time for a preset first number of consecutive times in the single path mode exceeds a preset first time threshold, and / or the error rate exceeds a preset first ratio threshold, switching the common switch to the dual write path mode.

[0065] When a performance metric in single-path mode reaches a preset threshold (e.g., response time exceeds T milliseconds N times in a row, or error rate exceeds R%), the target database is determined to have a performance bottleneck or failure, and the public switch is automatically switched to dual-write path mode. Parallel execution of the old and new databases shields the target database from single-point risks, ensuring business continuity. For example, if the target database of a financial transaction system experiences a sudden increase in transfer query response time due to missing indexes, switching to a dual-write path allows the request to be temporarily processed through the old database, avoiding transaction interruptions and buying time to troubleshoot the target database issue.

[0066] S55. When the consistency of the return results of the old database and the target database in the dual-write path mode reaches a preset second ratio threshold for a second consecutive preset number of times, and the response time of the target database is lower than a preset third ratio threshold of the response time of the old database, switch the common switch to the single path mode.

[0067] For example, through the result mapping logic in the policy class, the result sets returned by the old and new databases are compared field by field (for example, using hash verification and precise matching of field values), and the consistency ratio is ≥99.9% in 100 consecutive verifications. The average response time of the target database continues to be more than 30% lower than that of the old database, and the throughput reaches 120% of the old database, proving that it has the ability to independently carry business. The switching process adopts a progressive grayscale strategy: first cut 5% of the traffic to a single path, observe for 10 minutes without any abnormalities, and then gradually expand the proportion, and finally achieve full switching to ensure that the migration process is smooth and imperceptible. It is especially suitable for scenarios with extremely high stability requirements such as medical HIS systems and bank core transaction systems.

[0068] Through the above steps S51 to S55, the dynamic path switching and adaptive optimization mechanism significantly improves the system stability, data consistency and performance during the database migration process. The single path mode focuses on optimizing execution efficiency when the target database is stable, and the dual-write path mode ensures the accuracy of data migration through parallel execution and result verification. The two are combined to form a resilient fault-tolerant architecture. Real-time performance indicator collection establishes a quantitative monitoring system to provide a data-driven decision-making basis for path switching. The intelligent threshold trigger mechanism realizes the automatic adjustment of the execution path. When the target database has performance fluctuations, it quickly switches to the dual-write mode to ensure business continuity. After verification, it smoothly switches back to the single path to improve overall processing efficiency. Ultimately, in highly sensitive scenarios such as financial transactions and medical data queries, zero interruption and zero data loss in the migration process are achieved, while reducing the cost and potential risks of manual intervention.

[0069] S6. Parse the return result of the target database, call the corresponding policy class instance through the policy context management container to perform conversion and adaptation, and return the conversion and adaptation result to the target business system.

[0070] Among them, step S6 solves the compatibility problem between the result returned by the target database and the data model of the target business system. After receiving the response data from the target database, the adapted policy class instance is retrieved and called through the policy context management container. The policy class instance has built-in conversion logic for different database types and business requirements, which can parse and convert the original data into a format that can be directly used by the target business system. The conversion process covers operations such as data structure reorganization, data type mapping, and business rule adaptation to ensure that the data remains accurate and available in cross-system interactions. Finally, the converted results are returned to the target business system to achieve seamless data docking and ensure the normal operation of business functions.

[0071] As an optional implementation, the above step S6 may specifically include the following steps S61 to S63.

[0072] S61. When the target database is a relational database, the returned table structure data is converted into an object list that conforms to the data model of the target business system through a policy class instance, wherein the first rule of the conversion includes field mapping, data type conversion, and null value processing.

[0073] Among them, for the table structure data (presented in the form of a two-dimensional table) returned by the relational database (such as MySQL, Oracle), the strategy class instance is used to perform structured data conversion. Specifically, the field mapping is responsible for adjusting the database field name and order to the format required by the target business system. Data type conversion handles the data type differences between different databases and business systems (for example, converting the database's DATE type to the business system's date string). Null value processing fills or specially marks NULL values ​​according to business rules. Through the aforementioned rules, the original table data is converted into a list of objects that can be recognized by the target business system (for example, List<T> in Java). <pojo>), so that business logic can directly operate on data and avoid errors caused by data format mismatch.

[0074] S62. When the target database is a non-relational database, the returned unstructured data is converted into an object list that conforms to the data model of the target business system through a policy class instance, wherein the second rule of the conversion includes tree structure linearization, set data processing, and association relationship analysis.

[0075] For example, for unstructured or semi-structured data (e.g., JSON documents, key-value pairs) returned by non-relational databases (e.g., MongoDB, Redis), this step uses strategy class instances to perform data reconstruction. Tree structure linearization converts hierarchical data (e.g., nested JSON objects) into a flat structure for easier processing by the business system. Collection data processing filters, aggregates, or splits data types such as arrays and collections. Association parsing extracts relationship information between entities from unstructured data (e.g., establishing associations through foreign keys or reference fields). After the aforementioned operations, the unstructured data is converted into a list of objects that conforms to the data model of the target business system, enabling the business system to process data from different types of databases in a unified manner.

[0076] S63. If the public switch is in dual-write path mode, after conversion and adaptation, the returned conversion and adaptation result is secondary verified through the result comparison logic in the strategy class instance, where the verification rules include business field comparison, collection element comparison and business rule verification.

[0077] Among them, when in dual-write path mode (i.e., the old and new databases execute queries in parallel), in order to ensure data consistency, the above step S63 performs a deep verification on the converted results. For example, the business field comparison checks field by field whether the values ​​of the data returned by the old and new databases are consistent. The set element comparison verifies the consistency of the number, order and content of elements for data containing multiple elements (such as lists, sets). The business rule verification verifies the rationality of the data based on the business logic (for example, data range, calculation formula). If a difference is found during the verification process, an alarm or automatic rollback operation can be triggered in time to prevent erroneous data from flowing into the business system and ensure the accuracy and integrity of the data during the migration transition phase.

[0078] As an example, during the migration of a bank's core system from Oracle to MySQL, when processing customer account queries, the table structure data returned by MySQL was converted according to field mapping rules, converting the ACCT_BALANCE field to the business system's accountBalance. The database's DECIMAL type was accurately converted to Java's BigDecimal type, and any NULL values ​​that might appear were automatically filled with the default value of 0.00. During the dual-write verification phase, key business fields such as account balances and transaction records returned from the old and new databases were compared to verify the consistency of each transaction's amount and timestamp. The account status was also verified to comply with business rules such as "normal / frozen / cancelled," ensuring the accuracy of customer financial data during the migration process.

[0079] As another example, after migrating their HIS system from SQL Server to MongoDB, when querying patient electronic medical records, they flattened the nested JSON documents returned by MongoDB into a tree structure, expanded nested fields such as diagnosis.hospitalization.record into a list of diagnosisRecord objects recognizable by the business system, and deduplicated and sorted the array-type data in the examination results. During double-write verification, the old and new databases are compared to verify the consistency of the drug name, dosage, and usage on the medication list line by line. Furthermore, the diagnosis results and medication usage are verified according to clinical business rules to ensure the integrity and compliance of patient medical data.

[0080] Through the above steps S61 to S63, the differentiated data conversion and verification mechanism realizes the seamless connection of data between heterogeneous databases and business systems and high reliability assurance. For relational databases, structured conversion rules based on field mapping, type conversion and null value processing ensure that the two-dimensional table data is accurately adapted to the business model, avoiding system anomalies caused by type mismatch. For non-relational databases, through tree structure linearization, set data processing and association relationship analysis, semi-structured data is converted into an object format that can be uniformly processed by the business system, eliminating the integration barriers caused by data structure differences. In the dual-write path mode, business field comparison, set element verification and business rule verification form a triple verification line of defense to ensure the consistency of the results returned by the old and new databases, timely discover and correct potential data deviations, and provide strong protection for data quality during database migration. Especially in scenarios with extremely high requirements for data accuracy, such as financial transactions and medical records, the business risks caused by data conversion errors are significantly reduced.

[0081] As a preferred implementation, after the above step S6, the proportion of the strategy class instances may be dynamically adjusted, which may specifically include the following steps S71 to S73.

[0082] S71. Monitor the execution load of the strategy class instance in real time through the runtime optimization module.

[0083] S72: When it is detected that the load of the policy class instance exceeds a preset threshold, a new policy class instance corresponding to the policy class is created.

[0084] S73. Allocate new database query requests to new policy class instances, and dynamically adjust the proportion of each policy class instance allocated through weighted round-robin or minimum connection number algorithm.

[0085] Among them, the runtime optimization module collects and analyzes the execution load of the policy class instances in real time when processing database query requests, including key indicators such as CPU usage, memory usage, and task queue length. Once it is detected that the load of one or some policy class instances exceeds the pre-set threshold, indicating that its processing capacity is close to saturation, a new instance corresponding to the policy class will be automatically created to expand processing resources. After the new instance is created, a weighted polling or minimum connection number algorithm is used to dynamically allocate subsequent database query requests according to the load status of each instance, so that instances with high load receive fewer new requests, and instances with low load take on more tasks, thereby achieving load balancing between policy class instances, ensuring the efficiency and stability of query processing during database migration in high concurrency or complex query scenarios, and avoiding system performance degradation or response delays caused by overloading of a single instance.

[0086] As another preferred implementation, after the above step S73, a query execution path optimization model may be constructed and applied, which may specifically include the following steps S74 to S77.

[0087] S74: Obtain request feature information data, execution path data, and performance data of historical database query requests.

[0088] S75. Construct a query execution path optimization model based on the request feature information data, the execution path data, and the performance data, wherein the query execution path optimization model establishes a mapping relationship between query features and the optimal execution path through statistical analysis or a machine learning algorithm.

[0089] S76: When a new database query request is received, the optimal execution path corresponding to the new database query request is predicted by the query execution path optimization model, and the public switch is switched according to the obtained optimal execution path.

[0090] S77. Regularly use the newly added request feature information data, execution path data, and performance data to update and train the query execution path optimization model, and use the updated training results to update the currently running query execution path optimization model.

[0091] Among them, firstly, the request feature information data (for example, query statement structure, involved tables and fields, request initiation frequency, etc.), execution path data (single path or dual write path) and performance data (response time, error rate, throughput) of historical database query requests are collected, and based on the aforementioned data, statistical analysis methods or machine learning algorithms (such as decision trees, reinforcement learning models) are used to build a query execution path optimization model to explore the potential mapping relationship between different query features and the optimal execution path. When a new database query request is received, the model will quickly predict the optimal execution path (single path or dual write path) that matches it based on the characteristics of the input request, and drive the public switch to switch accordingly to ensure efficient query execution. At the same time, the newly added request feature information, execution path and performance data are regularly incorporated into the model training, and the model parameters and mapping rules are continuously optimized so that the query execution path optimization model can adapt to changes in database load, adjustments to business needs, etc., and continuously improve the accuracy and timeliness of query execution path decisions during database migration.

[0092] As an example, during the migration of the bank's core system database, the runtime optimization module monitors the load of policy instances that handle account transfers, transaction flow inquiries, and other businesses in real time. When it detects that the CPU usage of policy instances handling large-value transfer transactions continues to exceed 80%, it immediately creates a new instance to share the pressure, and uses the minimum connection number algorithm to distribute subsequent transfer requests to each instance to ensure fast transaction processing. At the same time, it collects request feature information such as the amount range and timestamp of historical transfer requests, as well as records of executing single or dual write paths and corresponding performance data such as response time and success rate. A query execution path optimization model is constructed through machine learning algorithms. For example, if it is found that transfers with an amount greater than 500,000 yuan have a lower error rate under the dual write path, subsequent transfer requests of this type will be executed preferentially using the dual write path, and the model will be regularly updated based on new transaction data to continuously optimize transfer business processing efficiency and data accuracy.

[0093] As another example, when a hospital is migrating its electronic medical record system database, the runtime optimization module monitors the load of policy instances that handle patient medical record retrieval and diagnostic data queries. If the memory usage of the instance processing CT image data queries is higher than 90% for a long time, a new instance is created and subsequent image query requests are reasonably distributed through a weighted polling algorithm. The module collects characteristic information such as patient type (emergency / general), query time, and departments involved from past medical record query requests. The module combines the execution path with performance data such as query time and data integrity, and uses statistical analysis methods to build an optimization model. It was found that medical record queries for emergency patients during peak hours respond faster under a single path. Subsequent queries of this type will automatically switch to a single path for execution, and the model will be regularly updated based on the newly added query data to ensure that medical staff can quickly and accurately obtain patient information, improving diagnosis and treatment efficiency and data security.

[0094] Through the above steps S71 to S77, the runtime optimization module monitors the load of the policy class instance in real time. Once an overload is detected, a new instance is immediately created and a weighted polling or minimum connection number algorithm is used to dynamically allocate query requests to achieve load balancing and ensure that the system runs efficiently under high concurrency. The characteristics, execution paths and performance data of historical query requests are collected, and a query execution path optimization model is constructed using statistical analysis or machine learning algorithms to explore the relationship between query characteristics and the optimal execution path. When a new request arrives, the model quickly predicts the adaptation path and drives the public switch to switch. At the same time, the training model is regularly updated with new data to adapt it to load changes and business needs, continuously improve the query path decision-making ability, and enhance the stability of database migration.

[0095] As another preferred implementation, the database migration process may be assisted by a knowledge graph system, which may specifically include the following steps S81 to S84.

[0096] S81. When a database query request with multiple table associations is received, the foreign key relationships, data dependency paths, and business semantic associations between tables are analyzed through the pre-deployed knowledge graph system.

[0097] For example, when a database query request involving multi-table associations is received, the pre-deployed knowledge graph system is activated. The system builds a knowledge network based on a graph database (e.g., Neo4j) that includes table structures, foreign key relationships, and business semantic constraints. First, all tables involved in the query are parsed, and the direct or indirect foreign key associations between tables are identified through a graph traversal algorithm (e.g., the dept_id of table A is associated with the id of table B). The data dependency path is then constructed in combination with predefined business rules (e.g., "the customer table and the account table are associated through the customer ID"). At the same time, the semantic layer in the knowledge graph (e.g., "the account balance must be greater than or equal to 0") is used to analyze the business intent of the query, for example, to determine whether the query is for financial report generation or real-time transaction verification, providing a semantic basis for subsequent strategy optimization.

[0098] S82: Filter out the optimal policy class combination from the policy context management container based on the analysis result, generate a corresponding customized migration policy chain based on the optimal policy class combination, and use the customized migration policy to replace the generated query policy chain.

[0099] For example, based on the analysis results of the knowledge graph, multi-dimensional screening is performed in the policy context management container: first, based on the complexity of table associations (for example, N-table joins), a policy class that supports efficient association queries (for example, a "distributed join strategy") is selected, and then the storage optimization policy class is matched based on the characteristics of the target database (for example, OceanBase's partitioned table mechanism). The aforementioned policy classes are dynamically combined into a customized migration policy chain, for example, "foreign key constraint conversion strategy → distributed query optimization strategy → result set aggregation strategy", replacing the original general query policy chain. This process is instantiated through the policy factory pattern and the execution order is orchestrated through the responsibility chain pattern to ensure that each processing link is optimized for the characteristics of the current query.

[0100] S83. When generating executable instructions for the target database, automatically complete the missing association conditions and constraints based on the semantic information stored in the knowledge graph system.

[0101] For example, when generating executable instructions for the target database, the semantic information stored in the knowledge graph is used to intelligently complete the query conditions. For example, when the knowledge graph detects that the query involves the "order table" and the "customer table" but lacks clear association conditions, a connection condition based on the customer ID is automatically added. If there is field ambiguity in the query (for example, both tables have a name field), a table alias qualification is added based on the field description in the knowledge graph (for example, "the name of the order table refers to the product name"). For complex business constraints (for example, "cross-departmental data requires permission verification"), filter conditions are automatically injected into the SQL to ensure that the generated instructions conform to business semantics and reduce the error rate of manually writing complex SQL.

[0102] S84. Perform semantic consistency check on the generated target database executable instructions to verify whether they comply with the predefined business rules in the knowledge graph.

[0103] Among them, the generated executable instructions for the target database must undergo semantic consistency verification of the knowledge graph. The instructions are parsed into an abstract syntax tree (AST) and compared with the predefined business rules in the knowledge graph. For example, if the knowledge graph defines that "financial statement queries must include a time range", and the generated instructions lack date filtering conditions, an alarm will be triggered and a default time window will be automatically added. If the aggregation operation in the instruction (for example, SUM) conflicts with the rule in the knowledge graph that "the amount field must be rounded", the calculation logic will be automatically adjusted. The aforementioned verification process is implemented through a rule engine (for example, Drools) to ensure that the generated instructions are not only syntactically correct, but also conform to the semantic constraints of the business field, especially in scenarios such as financial transactions and medical data statistics to avoid decision-making errors caused by semantic deviations.

[0104] As an example, during the migration of a bank's core systems, when processing a cross-departmental customer asset summary query, the knowledge graph system analyzed and discovered the need to link multiple tables, including the customer table, account table, and wealth management product table. It automatically identified the link path through the customer ID and product ID, and combined it with the business rule that "assets in different currencies must be converted according to the current exchange rate" to build data dependencies. Based on this, the "distributed association optimization strategy" and "real-time exchange rate calculation strategy" were selected from the policy container, and a customized policy chain was generated to replace the original general policy. When generating SQL instructions, the ROUND function was automatically completed based on the semantic information in the knowledge graph that "asset balances must be rounded to two decimal places" and the instructions were verified to ensure that they complied with the predefined rule that "wealth management product return calculations must include risk level filtering," ensuring that the query results accurately reflect the customer's comprehensive asset status.

[0105] As another example, when a hospital upgrades its electronic medical record system and processes multi-table relational queries involving patient basic information, test results, and medication records, the knowledge graph system analyzes the relationships between tables via patient ID and visit ID, while also interpreting the business semantics of "abnormal test results require warnings." It dynamically combines the "cross-database query optimization strategy" with the "outlier marking strategy" to form a customized strategy chain. When generating execution instructions, it automatically completes the timestamp matching conditions between different data sources and, based on the knowledge graph constraint that "antimicrobial drug use must comply with prescription rules," verifies whether the query includes the necessary medication permission filtering conditions, ensuring that the patient information obtained by medical staff is complete and complies with medical standards.

[0106] Through the above steps S81 to S84, with the help of the knowledge graph system, the inter-table relationships and business semantics of multi-table association queries are deeply analyzed, the optimal strategy class combination is accurately screened and a customized migration strategy chain is generated, which significantly improves the execution efficiency and accuracy of complex queries. The automatic completion mechanism improves the query conditions based on semantic information, effectively avoiding query errors caused by missing conditions. The semantic consistency check strictly follows the predefined business rules to ensure that the generated instructions conform to the business logic. In key areas such as finance and healthcare, it effectively avoids decision-making errors and data risks caused by semantic deviations, realizes the intelligent and automated processing of complex queries during database migration, greatly reduces the cost of manual intervention, and ensures the quality of data migration and the stability of system operation.

[0107] The database migration method provided in the embodiment of the present application shields the syntax differences of heterogeneous databases through standardized SQL function identifiers and policy class encapsulation mechanisms, thereby realizing cross-database adaptation and reuse of query logic. Dynamic policy chain generation and cache management technology are used to improve migration efficiency and reduce resource consumption. A resilient fault-tolerant architecture is built through a dual-path execution mode controlled by a public switch and real-time performance monitoring to ensure business continuity and data consistency during the migration process. Differentiated data conversion and triple verification mechanisms eliminate structural differences and semantic deviations to ensure data quality. Runtime load balancing and machine learning-driven path optimization models realize intelligent tuning of query processing and improve stability in high-concurrency scenarios. Complex query analysis and policy customization assisted by knowledge graphs deeply analyze business semantics and data dependencies, further enhancing the system's processing capabilities for complex scenarios. The overall solution achieves zero interruption, zero data loss and efficient automation of database migration in key areas such as finance and healthcare through multi-level technical collaboration, significantly reducing labor costs and business risks, and improving the system's scalability, compliance and long-term reliability.

[0108] Please continue reading Figure 5 , Figure 5 This is a schematic diagram of the system structure of the database migration device provided in the embodiment of the present application. Figure 5 As shown, the database migration device 50 includes: a query language identification module 51, a context management container module 52, a query strategy chain module 53, an executable command module 54, a public gateway management module 55 and a conversion and adaptation result module 56.

[0109] The query language identification module 51 is used to define structured query language identifiers of different databases to be migrated, wherein the database structured query language identifiers are used to represent different database query functions.

[0110] The context management container module 52 is used to encapsulate the query statement conversion, execution and result mapping logic of each database into the corresponding policy class, and to create a mapping relationship between the database structured query language identifier and the policy class, as well as a policy context management container.

[0111] The query strategy chain module 53 is used to receive the target database type input by the target business system, dynamically load the corresponding strategy class instance according to the target database type, and generate an executable query strategy chain according to the strategy class instance through the strategy context management container.

[0112] The executable command module 54 is configured to, upon receiving a database query request initiated by the target business system, match the policy class instance according to the database structured query language identifier through the policy context management container, and process the original database query statement through the matched policy class instance to generate an executable instruction for the target database;

[0113] The public gateway management module 55 is used to control the query strategy chain to execute a single path or dual write path mode through a pre-configured public switch, and pass the target database executable instructions to the corresponding strategy class instance for execution, and automatically switch the execution path according to the real-time monitored performance indicators;

[0114] The conversion and adaptation result module 56 is used to parse the return result of the target database, call the corresponding policy class instance through the policy context management container to perform conversion and adaptation, and return the conversion and adaptation result to the target business system.

[0115] As an optional implementation manner, the public gateway management module 55 is specifically used to, when the public switch is configured in a single path mode, send the target database executable instructions to the policy class instance corresponding to the target database through the query strategy chain for execution; when the public switch is configured in a dual write path mode, send the target database executable instructions to the policy class instances corresponding to the old database and the target database in parallel through the query strategy chain for execution, and verify the consistency of the database return results through the result mapping logic in the strategy class; collect the corresponding response time, error rate and throughput indicator data under the single path mode and the dual write path mode according to a preset sampling period; when the query response time of the single path mode exceeds the preset first time threshold for a consecutive preset first number of times, and / or the error rate exceeds the preset first ratio threshold, switch the public switch to the dual write path mode; when the consistency of the return results of the old database and the target database in the dual write path mode reaches the preset second ratio threshold for a consecutive preset second number of times, and the response time of the target database is lower than the preset third ratio threshold of the response time of the old database, switch the public switch to the single path mode.

[0116] As an optional implementation, the conversion adaptation result module 56 is specifically used to, when the target database is a relational database, convert the returned table structure data into an object list that conforms to the data model of the target business system through the policy class instance, wherein the first rule of conversion includes field mapping, data type conversion and null value processing; when the target database is a non-relational database, convert the returned unstructured data into an object list that conforms to the data model of the target business system through the policy class instance, wherein the second rule of conversion includes tree structure linearization, set data processing and association relationship analysis; if the common switch is the dual-write path mode, then after conversion adaptation, the returned conversion adaptation result is secondary verified through the result comparison logic in the policy class instance, wherein the verification rules include business field comparison, set element comparison and business rule verification.

[0117] As an optional implementation, the query strategy chain module 53 is specifically used to find the corresponding strategy class from the pre-configured strategy class and database type mapping relationship based on the target database type; create the strategy class instance through the system's built-in class loading mechanism, and set database connection information, configuration parameters and common dependency components for the strategy class instance; determine the different stages of query execution according to the target database type, and assign corresponding strategy class instances to each query stage; combine the strategy class instances into an orderly processing flow in the order of execution, and pass the processing results of the previous stage to the next stage for further processing in the processing flow; perform data caching on the created strategy class instance, wherein the cache identifier consists of the target database type and the information of the strategy class; when a new database query request is received, obtain the matching strategy class instance from the cache, and recreate it if it does not exist in the cache, and set the cache's effective time and maximum capacity.

[0118] As an optional implementation, the database migration device 50 also includes a runtime optimization module, which is specifically used to monitor the execution load of the policy class instance in real time through a preset runtime optimization module; when it is detected that the load of the policy class instance exceeds a preset threshold, a new policy class instance corresponding to the policy class is created; a new database query request is assigned to the new policy class instance, and the proportion of each policy class instance assigned is dynamically adjusted through weighted polling or a minimum connection number algorithm.

[0119] As an optional implementation, the runtime optimization module is further specifically used to obtain request feature information data, execution path data and performance data of historical database query requests; construct a query execution path optimization model based on the request feature information data, the execution path data and the performance data, wherein the query execution path optimization model establishes a mapping relationship between query features and optimal execution paths through statistical analysis or machine learning algorithms; when a new database query request is received, the query execution path optimization model is used to predict the optimal execution path corresponding to the new database query request, and the common switch is switched according to the obtained optimal execution path; the query execution path optimization model is regularly updated and trained using the newly added request feature information data, the execution path data and the performance data, and the currently running query execution path optimization model is updated using the updated training results.

[0120] As an optional implementation, the database migration device 50 also includes a knowledge graph auxiliary module, which is specifically used to analyze the foreign key relationship, data dependency path and business semantic association between tables through a pre-deployed knowledge graph system when receiving a database query request with multiple tables associated; based on the analysis results, the optimal policy class combination is screened out from the policy context management container, and a corresponding customized migration policy chain is generated according to the optimal policy class combination, and the customized migration policy is used to replace the generated query policy chain; when generating the target database executable instructions, the missing association conditions and constraints are automatically completed based on the semantic information stored in the knowledge graph system; and the generated target database executable instructions are subjected to semantic consistency verification to verify whether they comply with the business rules predefined in the knowledge graph.

[0121] It should be noted that the above-mentioned database migration device can execute the database migration method provided in the embodiment of this application, and has the corresponding functional modules and beneficial effects of the execution method. For technical details not fully described in the embodiment of the database migration device, please refer to the database migration method provided in the embodiment of this application.

[0122] Figure 6 Schematic diagram of the hardware structure of an electronic device for executing a database migration method according to an embodiment of the present application. Figure 6 As shown, the electronic device 600 includes:

[0123] One or more processors 610 and memory 620, Figure 6 A processor 610 is taken as an example.

[0124] The processor 610 and the memory 620 may be connected via a bus or other means. Figure 6 The bus connection is taken as an example.

[0125] Memory 620, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs, and modules, such as the program instructions / modules corresponding to the database migration method in the embodiments of the present application. Processor 610 executes the non-volatile software programs, instructions, and modules stored in memory 620 to execute various server functional applications and data processing, thereby implementing the database migration method in the aforementioned method embodiment.

[0126] Memory 620 may include a program storage area and a data storage area. The program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created based on the use of the database migration device. Furthermore, memory 620 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state memory device. In some embodiments, memory 620 may optionally include memory remotely located relative to processor 610. Such remote memory may be connected to the database migration device via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0127] The one or more modules are stored in the memory 620, and when executed by the one or more processors 610, execute the database migration method in any of the above method embodiments, for example, execute the above described Figure 2 Steps S1 to S6 of the method, Figure 3 Steps S51 to S55 of the method, Figure 4 Steps S31 to S36 of the method are implemented Figure 5 The functions of modules 51-56 in.

[0128] The above-mentioned product can execute the method provided in the embodiment of this application, and has the functional modules and beneficial effects corresponding to the execution method. For technical details not fully described in this embodiment, please refer to the method provided in the embodiment of this application.

[0129] An embodiment of the present application provides a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are executed by one or more processors, for example Figure 6 A processor 610 in the embodiment may enable the one or more processors to execute the database migration method in any of the above method embodiments, for example, executing the above described Figure 2 Steps S1 to S6 of the method, Figure 3 Steps S51 to S55 of the method, Figure 4 Steps S31 to S36 of the method are implemented Figure 5 The functions of modules 51-56 in.

[0130] The present application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by the electronic device, the electronic device is enabled to perform the database migration method in any of the above method embodiments, for example, performing the above described Figure 2 Steps S1 to S6 of the method, Figure 3 Steps S51 to S55 of the method, Figure 4 Steps S31 to S36 of the method are implemented Figure 5 The functions of modules 51-56 in.

[0131] 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.

[0132] 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. Those skilled in the art can understand that all or part of the processes in the above embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

[0133] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Based on the concept of the present application, the technical features in the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations in different aspects of the present application as described above. For the sake of simplicity, they are not provided in detail. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.< / pojo>

Claims

1. A database migration method, characterized in that: include: defining different database structured query language identifiers to be migrated, wherein the database structured query language identifiers are used to represent different database query functions; Encapsulate the query statement conversion, execution and result mapping logic of each database into the corresponding policy class, create a mapping relationship between the database structured query language identifier and the policy class, and a policy context management container; Receiving a target database type input by a target business system, dynamically loading a policy class instance of the corresponding policy class according to the target database type, and generating an executable query policy chain according to the policy class instance through the policy context management container; When receiving a database query request initiated by the target business system, matching the policy class instance according to the database structured query language identifier through the policy context management container, and processing the original database query statement through the matched policy class instance to generate a target database executable instruction; Controlling the query strategy chain to execute a single path or dual write path mode through a pre-configured common switch, passing the target database executable instructions to the corresponding strategy class instance for execution, and automatically switching the execution path based on real-time monitored performance indicators; Parse the return result of the target database, call the corresponding policy class instance through the policy context management container to perform conversion and adaptation, and return the conversion and adaptation result to the target business system.

2. The database migration method according to claim 1, characterized in that: The steps of controlling the query strategy chain to execute a single path or dual write path mode through a pre-configured common switch, transferring the target database executable instruction to the corresponding strategy class instance for execution, and automatically switching the execution path according to the real-time monitored performance indicators include: When the common switch is configured in a single path mode, the target database executable instruction is sent to the policy class instance corresponding to the target database through the query policy chain for execution; When the common switch is configured in dual write path mode, the target database executable instructions are sent to the policy class instances corresponding to the old database and the target database in parallel through the query policy chain for execution, and the consistency of the results returned by the database is verified through the result mapping logic in the policy class; Collecting response time, error rate, and throughput indicator data corresponding to the single path mode and the dual write path mode according to a preset sampling period; When the query response time for a preset first number of consecutive times in the single path mode exceeds a preset first time threshold, and / or the error rate exceeds a preset first ratio threshold, switching the common switch to the dual write path mode; When the consistency of the return results of the old database and the target database in the dual write path mode reaches a preset second ratio threshold for a second consecutive preset number of times, and the response time of the target database is lower than a preset third ratio threshold of the response time of the old database, the common switch is switched to the single path mode.

3. The database migration method according to claim 1, characterized in that: The step of calling the corresponding policy class instance through the policy context management container to perform conversion and adaptation, and returning the conversion and adaptation result to the target business system includes: When the target database is a relational database, the returned table structure data is converted into an object list that conforms to the data model of the target business system through the strategy class instance, wherein the first rule of the conversion includes field mapping, data type conversion, and null value processing; When the target database is a non-relational database, the returned unstructured data is converted into an object list that conforms to the data model of the target business system through the strategy class instance, wherein the second rule of the conversion includes tree structure linearization, set data processing, and association relationship analysis; If the common switch is in the dual-write path mode, after conversion adaptation, the returned conversion adaptation result is secondary verified through the result comparison logic in the strategy class instance, wherein the verification rules include business field comparison, collection element comparison and business rule verification.

4. The database migration method according to claim 1, characterized in that: The step of receiving a target database type input by a target business system, dynamically loading a policy class instance of the corresponding policy class according to the target database type, and generating an executable query policy chain according to the policy class instance through the policy context management container includes: Based on the target database type, searching for the corresponding policy class from a pre-configured mapping relationship between policy classes and database types; Create the policy class instance through the system's built-in class loading mechanism, and set database connection information, configuration parameters and common dependent components for the policy class instance; Determine the different stages of query execution based on the target database type and assign corresponding strategy class instances to each query stage; Combining the strategy class instances into an orderly processing flow in the order of execution, wherein the processing result of the previous stage is passed to the next stage for further processing; Performing data caching processing on the created policy class instance, wherein the cache identifier is composed of the target database type and information of the policy class; When a new database query request is received, the matching policy class instance is obtained from the cache. If it does not exist in the cache, it is recreated, and the cache validity period and maximum capacity are set.

5. The database migration method according to claim 1, characterized in that: After the step of calling the corresponding policy class instance through the policy context management container to perform conversion and adaptation, and returning the conversion and adaptation result to the target business system, the method includes: Monitor the execution load of the strategy class instance in real time through a preset runtime optimization module; When it is detected that the load of the policy class instance exceeds a preset threshold, a new policy class instance corresponding to the policy class is created; Allocate new database query requests to the new policy class instance, and dynamically adjust the proportion of each policy class instance allocated through weighted round-robin or minimum connection number algorithm.

6. The database migration method according to claim 5, characterized in that: After the step of allocating new database query requests to the new policy class instance and dynamically adjusting the proportion of each policy class instance allocated by weighted round-robin or minimum connection number algorithm, the method further includes: Obtain request feature information data, execution path data, and performance data of historical database query requests; Constructing a query execution path optimization model based on the request feature information data, the execution path data, and the performance data, wherein the query execution path optimization model establishes a mapping relationship between query features and optimal execution paths through statistical analysis or a machine learning algorithm; When a new database query request is received, the query execution path optimization model is used to predict an optimal execution path corresponding to the new database query request, and the common switch is switched according to the obtained optimal execution path; The query execution path optimization model is regularly updated and trained using the newly added request feature information data, the execution path data, and the performance data, and the currently running query execution path optimization model is updated using the updated training results.

7. The database migration method according to claim 1, characterized in that: After the step of calling the corresponding policy class instance through the policy context management container to perform conversion and adaptation, and returning the conversion and adaptation result to the target business system, the method further includes: When receiving a database query request involving multiple tables, the pre-deployed knowledge graph system analyzes the foreign key relationships, data dependency paths, and business semantic associations between tables. Based on the analysis results, an optimal policy class combination is selected from the policy context management container, and a corresponding customized migration policy chain is generated according to the optimal policy class combination, and the generated query policy chain is replaced with the customized migration policy; Automatically completing missing association conditions and constraints based on semantic information stored in the knowledge graph system when generating executable instructions for the target database; The generated executable instructions of the target database are subjected to semantic consistency check to verify whether they comply with the business rules predefined in the knowledge graph.

8. A database migration device, characterized in that: include: A query language identification module, used to define structured query language identifiers of different databases to be migrated, wherein the database structured query language identifiers are used to represent different database query functions; A context management container module is used to encapsulate the query statement conversion, execution and result mapping logic of each database into the corresponding policy class, create a mapping relationship between the database structured query language identifier and the policy class, and a policy context management container; A query policy chain module is configured to receive a target database type input by a target business system, dynamically load a policy class instance of the corresponding policy class according to the target database type, and generate an executable query policy chain according to the policy class instance through the policy context management container; an executable command module, configured to, upon receiving a database query request initiated by the target business system, match the policy class instance according to the database structured query language identifier through the policy context management container, and process the original database query statement through the matched policy class instance to generate an executable instruction for the target database; A public gateway management module, configured to control the query strategy chain to execute a single path or dual write path mode through a pre-configured public switch, pass the target database executable instructions to the corresponding strategy class instance for execution, and automatically switch the execution path based on real-time monitored performance indicators; The conversion and adaptation result module is used to parse the return result of the target database, call the corresponding policy class instance through the policy context management container to perform conversion and adaptation, and return the conversion and adaptation result to the target business system.

9. An electronic device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the database migration method according to any one of claims 1 to 7.

10. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer-readable storage medium stores computer-executable instructions. When the computer-executable instructions are executed by an electronic device, the electronic device executes the database migration method according to any one of claims 1 to 7.

Images