Heterogeneous data migration method and device, equipment and storage medium

Abstract

The invention discloses a heterogeneous data migration method and device, equipment and a storage medium, and relates to the technical field of data migration, and the method comprises the steps: obtaining a heterogeneous mapping rule between a source database and a target database; creating a migration transition table in the target database according to the heterogeneous mapping rule, and synchronizing the to-be-migrated data in the source database to the migration transition table to generate isomorphic mirror image data; performing batch screening on the isomorphic mirror image data based on the target migration factor to generate a batch migration list; and performing format conversion on the batch migration list according to a heterogeneous mapping rule to obtain target format data, and writing the target format data into a target database. The data heterogeneous difference is shielded through the migration transition table, the format conversion process is postposed, and the precision and stability of format conversion are improved; and the risk of single migration is reduced through gradual batch migration, so that the risk of switching between a new system and an old system is reduced. The heterogeneous data migration complexity can be reduced, and the migration efficiency can be integrally improved.

Description

Technical Field

[0001] This application relates to the field of data migration technology, and in particular to a heterogeneous data migration method, apparatus, device and storage medium. Background Technology

[0002] In traditional data migration processes, due to the significant structural differences between the source and target databases, complex data conversion and adaptation processes are often required. Furthermore, existing data migration solutions typically only handle heterogeneous data transfer from one database to another, failing to address data migration issues in multi-database scenarios. This results in a complex migration process that is not only inefficient but also prone to errors.

[0003] Therefore, existing data migration solutions have limited support for heterogeneous environments and lack versatility and flexibility. How to provide an efficient and stable heterogeneous data migration solution to meet the diverse needs of business scenarios has become an urgent problem to be solved. Summary of the Invention

[0004] The main purpose of this application is to provide a heterogeneous data migration method, apparatus, device and storage medium, aiming to solve the technical problem of how to provide an efficient and stable heterogeneous data migration solution to meet the needs of diverse business scenarios.

[0005] To achieve the above objectives, this application proposes a heterogeneous data migration method, which includes: Obtain the heterogeneous mapping rules between the source database and the target database; According to the heterogeneous mapping rules, a migration transition table is created in the target database, and the data to be migrated in the source database is synchronized to the migration transition table to generate homogeneous mirror data; Based on the target migration factor, the isomorphic mirror data is filtered in batches to generate a batch migration list; The batch migration list is format-converted according to the heterogeneous mapping rules to obtain target format data, and the target format data is written into the target database.

[0006] In one embodiment, the step of creating a migration transition table in the target database according to the heterogeneous mapping rule includes: Key elements are extracted from the heterogeneous mapping rules to obtain mapping structure information; The mapping structure information is converted into migration table creation statements corresponding to the database schema name of the target database; Execute the migration table creation statement in the target database to create a migration transition table in the target database.

[0007] In one embodiment, the step of batch filtering the isomorphic mirror data based on the target migration factor to generate a batch migration list includes: Obtain the migration factor candidates selected by the user from the migration dimension information, which includes customer dimension, user dimension and business dimension; The candidate migration factors are screened based on preset evaluation rules to obtain the target migration factors; The range of values ​​for the target migration factor is divided into several migration sub-intervals; The isomorphic mirror data is filtered in batches according to the migration sub-intervals to generate a batch migration list.

[0008] In one embodiment, after performing batch filtering of the isomorphic mirror data based on the target migration factor to generate a batch migration list, the method further includes: Write the batch migration list into the data routing decision table of the target database; Upon receiving a data retrieval request, the data retrieval request is routed based on the data routing determination table. The data retrieval request is distributed based on the routing determination result.

[0009] In one embodiment, the step of performing route determination on the data call request based on the data routing determination table upon receiving a data call request includes: Upon receiving a data call request, the service identifier carried in the data call request is parsed, and the data routing determination table is queried to determine whether the service identifier is within the migrated range; If the service identifier is within the migrated range, the target database is determined as the routing decision result.

[0010] In one embodiment, the step of distributing the data retrieval request based on the routing determination result includes: When the routing determination result is the source database, the data call request is subjected to interface normalization conversion to generate a standard routing request; The standard routing request is distributed to the source database.

[0011] In one embodiment, after writing the target format data into the target database, the method further includes: The system checks whether all the data to be migrated has been migrated to the target database. If so, delete the data to be migrated from the source database and delete the data routing decision table corresponding to the target database.

[0012] Furthermore, to achieve the above objectives, this application also proposes a heterogeneous data migration apparatus, which includes: The rule determination module is used to obtain the heterogeneous mapping rules between the source database and the target database; The data push module is used to create a migration transition table in the target database according to the heterogeneous mapping rules, and synchronize the data to be migrated in the source database to the migration transition table to generate homogeneous mirror data; The data filtering module is used to filter the isomorphic mirror data in batches based on the target migration factor and generate a batch migration list; The data migration module is used to convert the batch migration list according to the heterogeneous mapping rules to obtain target format data, and write the target format data into the target database.

[0013] In addition, to achieve the above objectives, this application also proposes a heterogeneous data migration device, which includes: a memory, a processor, and a heterogeneous data migration program stored on the memory and executable on the processor, wherein the heterogeneous data migration program is configured to implement the steps of the heterogeneous data migration method described above.

[0014] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, on which a program for implementing a heterogeneous data migration method is stored, and the program for implementing the heterogeneous data migration method is executed by a processor to implement the steps of the heterogeneous data migration method as described above.

[0015] This application provides a heterogeneous data migration method, apparatus, device, and storage medium. The method includes: obtaining heterogeneous mapping rules between a source database and a target database; creating a migration transition table in the target database according to the heterogeneous mapping rules, and synchronizing the data to be migrated from the source database to the migration transition table to generate homogeneous mirror data; performing batch filtering of the homogeneous mirror data based on a target migration factor to generate a batch migration list; converting the format of the batch migration list according to the heterogeneous mapping rules to obtain target format data, and writing the target format data into the target database. This application masks the heterogeneous differences between the source and target databases by using a migration transition table generated based on heterogeneous mapping rules and homogeneous mirror data, and performs the format conversion process in the target database. This not only improves the accuracy and stability of the format conversion but also eliminates the need to focus on format conversion between different databases during data migration, thus improving data migration efficiency. Furthermore, this application can achieve progressive batch migration based on a target migration factor, allowing for timely verification of data correctness after each batch migration, thereby reducing the risk of a single migration, minimizing the impact of migration failures on users, and ultimately reducing the risk of switching between old and new systems. Therefore, this application can reduce migration complexity through structured rules and batch processing, thereby improving overall migration efficiency, compressing the switching time window, reducing the impact on users, and meeting the needs for efficient and stable heterogeneous data migration. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a first flowchart illustrating the first embodiment of the heterogeneous data migration method of this application; Figure 2 This is a second flowchart illustrating the first embodiment of the heterogeneous data migration method of this application; Figure 3 This is a flowchart illustrating the second embodiment of the heterogeneous data migration method of this application; Figure 4 This is a schematic diagram illustrating the routing effect of the second embodiment of the heterogeneous data migration method of this application; Figure 5 This is a schematic diagram illustrating the heterogeneous data migration method of this application; Figure 6This is a schematic diagram of the module structure of the heterogeneous data migration device according to an embodiment of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the heterogeneous data migration method in the embodiments of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of this application is as follows: obtain the heterogeneous mapping rules between the source database and the target database; create a migration transition table in the target database according to the heterogeneous mapping rules, and synchronize the data to be migrated in the source database to the migration transition table to generate homogeneous mirror data; filter the homogeneous mirror data in batches based on the target migration factor to generate a batch migration list; convert the format of the batch migration list according to the heterogeneous mapping rules to obtain the target format data, and write the target format data into the target database.

[0023] Existing data migration solutions typically only handle heterogeneous data transfer from one database to another, and cannot solve the problem of batch migration in multi-database scenarios. This results in a complex and risky migration process, and cannot flexibly handle differences in business rules.

[0024] To address the aforementioned issues, this application masks the heterogeneous differences between the source and target databases using a migration transition table generated based on heterogeneous mapping rules and homogeneous mirror data. The format conversion process is performed post-processed within the target database, improving not only the accuracy and stability of format conversion but also eliminating the need to focus on format conversion between different databases during data migration, thus enhancing migration efficiency. Furthermore, this application enables progressive batch migration based on a target migration factor, allowing for timely verification of data correctness after each batch migration. This reduces the risk of single migrations, minimizes the impact of migration failures on users, and consequently reduces the risk of switching between old and new systems. Therefore, this application, through structured rules and batch processing, reduces migration complexity, thereby improving overall migration efficiency, shortening the switchover time window, minimizing user impact, and meeting the requirements for efficient and stable heterogeneous data migration.

[0025] It should be noted that the execution subject of this embodiment can be a heterogeneous data migration system, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a heterogeneous data migration device capable of performing the above functions, or a microservice architecture, etc. This embodiment does not specifically limit it in this regard. The following uses a heterogeneous data migration device (hereinafter referred to as migration device) as the execution subject as an example to describe this embodiment and the following embodiments.

[0026] Based on this, embodiments of this application provide a heterogeneous data migration method, referring to... Figure 1 , Figure 1 This is a first flowchart illustrating the first embodiment of the heterogeneous data migration method of this application.

[0027] In this embodiment, the heterogeneous data migration method includes steps S10 to S40: Step S10: Obtain the heterogeneous mapping rules between the source database and the target database; It is easy to understand that the source database and target database mentioned above are usually of different types (such as MySQL and Oracle, relational and non-relational databases), and there can be more than one source database and one target database. That is, the migration device in this application needs to solve the data migration problem of multiple databases with multiple database relationships. To solve this problem, this embodiment proposes a data conversion process of "temporary storage of transition tables - batch filtering - format conversion", which can achieve the effect of smooth migration of many-to-many heterogeneous data even in a microservice architecture.

[0028] Understandably, the aforementioned heterogeneous mapping rules can be a set of rules that predefine the correspondence between data tables and fields in the source database and the target database, as well as the conversion logic. These rules can be stored in the migration device in the form of a unified data design template. For example, the heterogeneous mapping rules may include table-level mapping (old table name - new table name, schema name - database name), field-level mapping (original field name - new field name, format definition - field type), and conversion methods (such as "direct migration", "a→1 / b→2 encoding mapping", or "time format from minute level to date level").

[0029] For example, the above heterogeneous mapping rules may include an overview table and a detailed table. The overview table may specify the system number, module classification (the module to which the data to be migrated belongs), old table name (old_loan_info), schema name (the name used by the database to identify and organize different data structures (such as tables, views, stored procedures, etc.) in the source database), database name (the name of the new database), target migration factor (the dimension by which the data to be migrated is divided), and person in charge of the data migration process. The detailed table may include: format definition, i.e., database field type, such as char(1); whether it is a primary key, i.e., whether the field is the primary key of this table; whether it is not null, i.e. whether the field has a non-null restriction; value and meaning, i.e., the encoding meaning mapping of the field, such as gender 1 for male and 2 for female; conversion method, i.e., describing the migration method of the field, whether it is direct migration or needs to be converted, such as a->1; b->2.

[0030] Step S20: Create a migration transition table in the target database according to the heterogeneous mapping rules, and synchronize the data to be migrated in the source database to the migration transition table to generate homogeneous mirror data; It should be noted that the aforementioned migration transition table can be an intermediate table created by the migration device in the target database, with a table structure completely identical to the table structure corresponding to the data to be migrated in the source database. It can be used to temporarily store the aforementioned isomorphic mirror data, avoiding structural adaptation conflicts caused by directly manipulating the final table of the target database.

[0031] The aforementioned isomorphic mirror data can be a copy of the source data that is completely identical in structure and content to the source data after synchronizing the data to be migrated from the source database to the migration transition table. This enables "source-target database heterogeneity masking," allowing the data migration process to proceed without focusing on the format conversion process and improving the efficiency of data migration between different databases.

[0032] In one feasible implementation, refer to Figure 2 , Figure 2 This is a second flowchart illustrating the first embodiment of the heterogeneous data migration method of this application. In this embodiment, step S20 may include steps A1 to A3: Step A1: Extract key elements from the heterogeneous mapping rules to obtain mapping structure information; It is easy to understand that the migration equipment can be equipped with a pre-built DDL (Data Definition Language) table creation statement generation tool, which can have the functions of "Excel template parsing - key element extraction - database syntax adaptation - SQL generation", and can automatically adjust the syntax of the table creation statement according to the target database type (MySQL / Oracle) (e.g., Oracle requires adding SEQUENCE, MySQL supports AUTO_INCREMENT).

[0033] At this point, the aforementioned mapping structure information can be the core information defining the migration transition table structure extracted from heterogeneous mapping rules by a DDL table creation statement generation tool. This information may include table name, field name, field type, whether it is a primary key (yes / no), whether it is NOT null (yes / no), whether it is auto-incrementing (yes / no), and field description (such as loan number). For example, the DDL table creation statement generation tool can automatically extract the mapping structure information contained in the heterogeneous mapping rules through a table parsing algorithm (such as the open-source library Apache POI). For example, it can extract "table name (trans_loan_info), database name (new_fin_db), schema name (FIN_NEW)" from the overview table, and extract "field name (loan_id), format definition (varchar(32)), whether it is a primary key (yes), whether it is NOT null (yes), field description (loan number)" from each field in the detail table. It can also verify the legality of the elements (such as whether the field type conforms to the target database specification) and generate standardized mapping structure information.

[0034] Step A2: Convert the mapping structure information into migration table creation statements corresponding to the database schema name of the target database; Step A3: Execute the migration table creation statement in the target database to create a migration transition table in the target database.

[0035] Understandably, the migration equipment can further utilize a DDL table creation statement generation tool to convert the mapping structure information into SQL statements that can be directly executed in the target database, i.e., the aforementioned migration table creation statements, based on the target database's database schema name. These migration table creation statements can include key element table structure definitions, constraints (primary key / NOT), field comments, and sequences (such as in Oracle) corresponding to the mapping structure information. They can be used to create the aforementioned migration transition tables in the target database. At this point, the automated extraction of the mapping structure information to generate migration table creation statements with comments and sequences not only avoids syntax errors and constraint omissions caused by manual coding, improving the accuracy of subsequent migration transition table creation, but also ensures a clear and maintainable migration transition table structure, laying the foundation for subsequent data synchronization and shortening the migration time.

[0036] The database schema name can be a name used to identify and organize different data structures (such as tables, views, stored procedures, etc.) in a database. In database systems, schema names are typically used to distinguish different users, applications, or datasets, especially in multi-user or multi-tenant environments. Therefore, this embodiment supports syntax adaptation for multiple database types (MySQL / Oracle) without requiring separate tools for each database, thus improving the versatility of the solution.

[0037] Finally, the migration device can connect to the target database and execute the migration table creation statements in the target database, thus creating a migration transition table. Furthermore, this embodiment supports dynamic mapping of Excel template field headers after adjustments to adapt to the management requirements of various products.

[0038] Step S30: Based on the target migration factor, the isomorphic mirror data is filtered in batches to generate a batch migration list; Understandably, the aforementioned target migration factor can be selected from the migration business dimensions set in advance according to different business dimensions, and must meet the evaluation principles of "customer insensitivity, acceptable impact on users, and minimal modification of old applications" to be the best migration factor.

[0039] In one feasible implementation, step S30 may include steps B1 to B4: Step B1: Obtain the migration factor candidates selected by the user from the migration dimension information, which includes customer dimension, user dimension and business dimension; It's easy to understand that the aforementioned migration dimension information can also be a predefined set of three core dimensions used to define the migration scope, which may include: customer dimension, user dimension, and business dimension. The candidate options for the customer dimension may include: the customer's region (e.g., Guangdong Province, Zhejiang Province), customer level (VIP customer, regular customer), etc.; the candidate options for the user dimension may include: user role (account manager, system administrator), user's department (personal finance department, corporate finance department), etc.; the candidate options for the business dimension may include: business type (small consumer loan, mortgage loan, business loan), business scale (amount <100,000,000, 100,000 - 1,000,000, >1,000,000), etc.

[0040] Therefore, the above migration factor candidates can be dimensions that users initially screen from migration dimension information based on migration scenarios (such as migration of a bank's personal loan system) and that may be used for batch migration (such as business type, customer's region). Further evaluation is needed to determine the final target migration factor.

[0041] For example, in the scenario of "migrating a bank's personal loan system", the corresponding business characteristics may be a small number of small consumer loan users and a large number of cross-regional businesses. In this case, candidates are selected from the "customer dimension" as "customer's region" (if migrating by region, Guangdong Province can be prioritized for piloting); candidates are selected from the "business dimension" as "business type" (small consumer loan users account for only 10%, and the migration risk is low); and candidates are excluded from the "user dimension" (users often collaborate across departments, and migrating by department may lead to the splitting of business data), thus finally determining the candidate list: "customer's region and business type".

[0042] Step B2: Based on preset evaluation rules, the candidate migration factors are screened to obtain the target migration factors; It is easy to understand that the above-mentioned preset evaluation rules can be the core criteria for determining the target migration factors, namely, "customer is not aware of the data migration process, user impact is acceptable (user business is not hindered during the migration period), and old application transformation is as small as possible (the amount of code modification to the old system is small)," which are used to select the optimal dimensions from the "candidates".

[0043] For example, the above-mentioned candidate options are evaluated one by one according to the "preset evaluation rules". First, the "customer's region" is evaluated: Regarding customer insensitivity: Yes (customers do not need to know the regional migration logic); Regarding impact on users: No (cross-regional business such as "loans processed by Guangdong customers in Zhejiang" need to be split into the old and new systems, and users may miss data when querying); Regarding the transformation of old applications: No (the old system needs to add "regional filtering + cross-regional data association" logic, which requires a large amount of transformation); Next, the "business type" is evaluated: Regarding customer insensitivity: Yes (customers only care about the business processing results and are unaware of the migration); Regarding impact on users: Yes (small consumer loan users are few, and migration failure only affects 10% of users, which can be quickly rolled back); Regarding the transformation of old applications: Yes (only "business type filtering" logic needs to be added, which requires a small amount of transformation); After comprehensive evaluation, "business type" can be determined as the "target migration factor".

[0044] Step B3: Divide the range of values ​​for the target migration factor into several migration sub-intervals; Step B4: Filter the isomorphic mirror data in batches according to the migration sub-intervals to generate a batch migration list.

[0045] Understandably, after determining the target migration factor, this embodiment can divide the value range of the target migration factor into multiple continuous / discrete small ranges. For example, when the target migration factor is a business type and the corresponding specific content is a small consumer loan, the data can be further divided according to the business amount range (such as "amount < 100,000", "100,000-500,000", etc.) to generate the aforementioned migration intervals. The aforementioned batch migration list can be a data subset list generated after filtering isomorphic mirror data based on the interval conditions of each migration sub-interval. Subsequently, a gradual migration "from less to more, from partial to overall" can be achieved based on the batch migration list.

[0046] At this point, the migration device can query the synchronous mirror data stored in the migration transition table according to the value conditions of each migration sub-interval, and then move the data that meets the conditions into the corresponding batch migration list so that subsequent orderly batch migration can be carried out based on the batch migration list.

[0047] For example, assuming a "bank personal loan system migration" scenario, the corresponding business data distribution is as follows: Small consumer loans: 60% for amounts <100,000, 30% for amounts between 100,000 and 500,000, and 10% for amounts >500,000; Mortgage loans: 20% for Shenzhen branches and 80% for other branches; Business loans: managed centrally across the entire bank. The migration sub-intervals can then be divided as follows: 1) Sub-interval 1: Small consumer loans (amount < 100,000), priority will be given to migration verification; 2) Sub-range 2: Small consumer loans (100,000-500,000 RMB) + Shenzhen branch mortgage loans, expanding the scope of verification; 3) Sub-interval 3: Small consumer loans (>500,000) + mortgage loans from other branches + business loans from the entire bank, all migrated; Finally, the corresponding batch migration data can be filtered according to the value range of each migration sub-interval (such as "business type = small consumer loan and amount < 100,000 yuan"), and the corresponding allocation migration list can be generated. Then, based on the allocation migration list, the isomorphic image data corresponding to the original business data in the target database can be converted in an orderly batch.

[0048] In this implementation, target migration factors can be screened through "preset evaluation rules" to ensure that the migration process meets the requirements of "customer-unobtrusive, minimal user impact, and minimal modification," avoiding business interruptions caused by improper dimension selection. Based on the flexible and adaptable migration sub-intervals that can be adjusted to suit business changes, a batch migration list for filtering the amount of data in each batch is automatically generated, reducing manual operations and improving the accuracy of batch transfer. Finally, single-batch data is filtered based on the batch migration list, and then orderly data migration is performed based on each batch of data, thereby achieving a gradual migration. This allows for verification of data correctness after each batch migration (e.g., checking the number of data entries and field consistency after the migration of sub-interval 1), timely repair of problems, and reduction of the risk of full migration.

[0049] Step S40: Convert the batch migration list according to the heterogeneous mapping rule to obtain target format data, and write the target format data into the target database.

[0050] In essence, the migration device can ultimately adjust the field format of the selected data in the target database based on heterogeneous mapping rules (e.g., converting "loan_date=20250925112400" to "20250925") and perform encoding mapping (e.g., converting "status='a' to 1)) to generate target format data that matches the data format of the target database. The target format data is then inserted into the final table in the target database that stores the data to be migrated through database transaction operations (ensuring data consistency).

[0051] In summary, existing data migration solutions can only handle heterogeneous data transmission between single databases, and cannot adapt to complex scenarios involving multiple databases. Furthermore, they lack a batch migration solution based on business rules, resulting in concentrated migration risks (such as the failure of a single batch of migration affecting all data). Moreover, existing migration solutions require direct handling of heterogeneous differences between the source and target databases (such as different field types and formats), leading to high complexity in migration application development and low data conversion efficiency.

[0052] In contrast, this embodiment can shield the heterogeneous differences between the source database and the target database by using a migration transition table generated based on heterogeneous mapping rules and homogeneous mirror data. The format conversion process can be performed in the target database, which can not only improve the accuracy and stability of the format conversion, but also eliminate the need to focus on the format conversion between different databases during the data migration process, thereby improving the efficiency of data migration. Meanwhile, this embodiment can achieve gradual batch migration based on the target migration factor, so that the correctness of the data can be verified in a timely manner after each batch of data migration, thereby reducing the risk of a single migration, reducing the impact of migration failure on users, and thus reducing the risk of switching between old and new systems. Therefore, this embodiment can reduce migration complexity through structured rules and batch processing, thereby improving overall migration efficiency, compressing the switchover time window, reducing the impact on users, and meeting the needs of efficient and stable heterogeneous data migration.

[0053] This embodiment provides a heterogeneous data migration method, which includes: obtaining heterogeneous mapping rules between a source database and a target database; extracting key elements from the heterogeneous mapping rules to obtain mapping structure information; converting the mapping structure information into migration table creation statements corresponding to the database schema name of the target database; and executing the migration table creation statements in the target database to create a migration transition table. The method involves obtaining migration factor candidates selected by the user from migration dimension information, including customer, user, and business dimensions; filtering the migration factor candidates based on preset evaluation rules to obtain target migration factors; dividing the value range of the target migration factors into several migration sub-intervals; filtering isomorphic mirror data in batches according to the migration sub-intervals to generate a batch migration list; converting the format of the batch migration list according to the heterogeneous mapping rules to obtain target format data, and writing the target format data into the target database. This application achieves a unified design specification for data tables between databases with different structures through heterogeneous mapping rules, generates migration table creation statements, and realizes rapid design and creation of migration transition tables, effectively enabling many-to-many database synchronization. Meanwhile, this embodiment uses migration factors to define the scope of batch migration. These migration factors can be selected from multiple dimensions such as customers, users, and business processes, and can be freely combined to perform orderly batch data conversion, ensuring a smooth data migration implementation. Therefore, this embodiment can achieve compatibility and smooth switching between old and new applications through decoupling, penetration, and data synchronization between the source and target databases, reducing implementation risks. It also effectively improves data migration efficiency, shortens the switching time window, and minimizes the impact on users.

[0054] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the first embodiment described above can be referred to the above description, and will not be repeated hereafter.

[0055] It is easy to understand that existing data migration solutions, after phased migration, can only solve the technical issue of message routing and forwarding, and cannot completely solve the compatibility problem of business rule differences between the old and new systems. Therefore, this embodiment can configure a compatibility routing layer or routing judgment module for the target database in the migration device. This module can be used to receive data call requests (such as data queries, data downloads, etc.) sent by external systems, and perform routing and forwarding between the old and new systems (i.e., the source database and the target database) according to the request parameters contained in the data call request.

[0056] Based on the first embodiment, please refer to Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the heterogeneous data migration method of this application. In this embodiment, after step S30, the heterogeneous data migration method further includes steps C1 to C3: Step C1: Write the batch migration list into the data routing decision table of the target database; Step C2: Upon receiving a data retrieval request, perform a routing determination on the data retrieval request based on the data routing determination table; Step C3: Distribute the data retrieval request according to the routing determination result.

[0057] Understandably, the aforementioned data retrieval requests can be business requests (such as loan inquiries or repayment applications) initiated by external systems (e.g., mobile banking software, counter systems) to the source and target databases. The format can be HTTP (Hypertext Transfer Protocol), and the request parameters can include migration factor-related business identifiers, such as loan_id=LOAN20250001, loan_type=small consumer loan. It's important to understand that, regardless of whether the data retrieval request sent by the external system targets the source or target database, it will uniformly be routed through a newly added compatible routing layer.

[0058] The aforementioned data routing decision table can be a core table set in the compatible routing layer, generated based on the batch migration list, that records the range of migrated data. This data routing decision table can include business identifiers (such as business serial number loan_id), migration status (migrated / not migrated), routing target, batch number, etc., and is used by the compatible routing layer to determine the distribution direction of data processing requests.

[0059] As one possible implementation, in this embodiment, step C2 includes steps C21 to C22: Step C21: When a data call request is received, the service identifier carried in the data call request is parsed, and the data routing determination table is queried to determine whether the service identifier is within the migrated range. Step C22: If the service identifier is within the migrated range, determine the target database as the routing determination result.

[0060] It is easy to understand that the aforementioned business identifier can be a parameter used to uniquely identify a certain business in the data to be called by the corresponding peripheral device in the data call request, such as a business serial number or user identifier. This embodiment supports parsing of business identifiers for multiple request parameters (URL, JSON, form) to adapt to the request methods of different peripheral systems and improve the versatility of the solution. The aforementioned migrated range can correspond to the set of business identifiers with a migrated status in the data routing determination table (such as the loan_ids that have been successfully migrated in all batches B001 and B002), representing the range of data to be routed to the target database. Therefore, the migration device can determine whether the data to be called has been migrated to the target database by querying whether the data to be migrated exists and whether the migration range has been reached based on the business identifier through the compatible routing layer. Therefore, the routing determination logic in this embodiment is dynamically associated with the data routing determination table, so that the determination code does not need to be modified during the batch data migration process; only the table data needs to be updated, which can effectively reduce maintenance costs. Furthermore, the determination process only requires one SQL (Structured Query Language) query, with a short response time (milliseconds) and does not affect the processing efficiency of business requests.

[0061] At this point, if the business identifier is within the migrated range, the target database is determined as the routing result, and the data call request is forwarded to the target database for data call; if the business identifier exists but is not within the migrated range, the source database is determined as the routing result, and the data call request is forwarded to the source database for data call.

[0062] In this implementation, dual judgment can be made based on business identifier and migration status to ensure accurate routing determination and avoid misrouting of failed migration data to the target database.

[0063] As one possible implementation, in this embodiment, step C3 includes steps C31 to C32: Step C31: When the routing determination result is the source database, the data call request is subjected to interface normalization conversion to generate a standard routing request; Step C32: Distribute the standard routing request to the source database.

[0064] It is easy to understand that, since the data retrieval requests mentioned above in this embodiment are all request packets accessing the compatible routing layer located in the target database, they may not match the request data format of the source database. Therefore, in this embodiment, when the migration device detects that the routing determination result is the source database, it can perform interface normalization conversion on the data retrieval requests based on the pre-configured new and old interface mapping rules, converting data retrieval requests that conform to the target database interface specifications into standard routing requests that conform to the source database's recognizable specifications. After obtaining a standard routing request that conforms to the old system interface specifications, the migration device can send it to the source database's interface.

[0065] For example, suppose an external system needs to call a text printing interface to print, requiring the input of a text number parameter and a print time parameter. The source database number corresponding to the old application starts with "old", and the target database number corresponding to the new application starts with "new"; and the print time of the old application is accurate to the date, such as 20250925, while the print time of the new application is accurate to the minute, such as 20250925112400.

[0066] In actual scenarios, data requests from external systems may include the parameter text ID "old12345" and the print time "20250928112400". The migrating device can then determine the starting number; if it begins with "old", the request needs to be forwarded to the old application for processing. Next, the print time field is converted to a date-accurate format (e.g., "20250928"), and finally, the old application's interface is called to process the request and return the result.

[0067] It's important to understand that the aforementioned interface standardization process may include steps such as input parameter format conversion (e.g., converting time format YYYYMMDD to YYYYMMDDHHMMSS), parameter name mapping (e.g., converting new_loan_id to loan_id), and output parameter format conversion (e.g., converting XML returned by the old system to JSON returned by the new system). The configuration parameters in this process can be flexibly adjusted, so that if any database changes, the corresponding configuration file can be adjusted to complete the adaptation, effectively reducing maintenance costs.

[0068] In this embodiment, the input / output parameter conversion between databases with different structures is automatically completed based on the pre-configured interface standardization conversion function. No manual adaptation code is required, which reduces the development workload and improves the success rate of request processing. Moreover, the external system only needs to connect to the new system interface and does not need to adapt to the old system, achieving "seamless connection" and avoiding the need to modify the external system.

[0069] As one possible implementation, this embodiment further includes steps S50-S60 after step S40: Step S50: Detect whether all the data to be migrated has been migrated to the target database; It is easy to understand that the migration device can determine that all the data to be migrated in the source database has been effectively migrated to the target database only if the data status of all batches (such as B001, B002, B003) in each batch migration list is migrated and the data verification confirms that the data to be migrated in the source database is completely consistent with the data in the target database (same number of records, same field values).

[0070] During this process, the amount of data migration can be confirmed by generating a migration data list. This migration data list is a table that records key information for each batch of migrated data, including batch number (identifying which batch the current data belongs to); business type (identifying the business segment of the current data, such as customer type or user type); business serial number (specifically identifying a business data entry, such as ID number or license plate number); rollback flag (identifying whether the current data has been migrated and rolled back); timestamp (identifying the migration time); and status (identifying whether the current data has been migrated and whether there are any anomalies), etc., so as to facilitate unified management of migrated data and simplify rollback operations later. Since the migration data list table basically only has a limited number of fields such as batch number, business type, business serial number, rollback flag, timestamp, and status, the table storage footprint is small. It can be used as the basis for task sharding, improving the performance of SQL joins for mapping transformation and data deletion, and improving data mapping performance.

[0071] At this point, after confirming based on the migration data list that there is no unmigrated and / or abnormal data to be migrated, the migration device can further verify the number of records based on the migration data list, i.e., whether the total number of records in the source database to be migrated in the migration data list is equal to the total number of records in the final target database; and perform field verification, i.e., randomly selecting data from the source database and comparing field values ​​with data from the target database to determine whether they are consistent. Once both the record count verification and field verification are successful, it can be determined whether all the data to be migrated has been migrated to the target database. Therefore, this embodiment can solve the problems of existing data migration schemes lacking a unified batch migration management tool, having cumbersome data rollback operations (requiring individual location of rollback data), and failing to guarantee migration stability, based on the migration data list.

[0072] Step S60: If yes, delete the data to be migrated from the source database and delete the data routing determination table corresponding to the target database.

[0073] It should be noted that after confirming that all data to be migrated has been migrated, the migration device can delete the migrated historical data in the source database using SQL statements or database tools (such as MySQL's TRUNCATE). This completes the migration process for the data to be migrated. Furthermore, the data routing decision table in the target database can be deleted using SQL statements, and the corresponding compatible routing layer can be disabled, allowing the target database to directly interface with external systems.

[0074] Therefore, in this embodiment, the specific routing effect of the newly added compatible routing layer can be referred to Figure 4 , Figure 4 This is a schematic diagram illustrating the routing effect of the second embodiment of the heterogeneous data migration method of this application. Figure 4 As shown, before data migration: the peripheral system completes interface modification and switching, that is, the old system connects to the peripheral system through the new system routing layer as shown in 4. At this time, the migration factor is not configured. During the parallel data migration period: the migration batch configures the migration factor. The peripheral system is unaware of this. Data call requests submitted by the peripheral system can be automatically forwarded to the corresponding old system or new system through the newly added new system routing layer according to the migration progress. After data migration is completed: the new system removes the compatibility routing layer and directly connects to the peripheral system. The migration factor is removed. The peripheral system is still unaware of this.

[0075] Therefore, this newly added compatible routing layer will not affect the integration efficiency of external systems or the data migration process, ensuring migration stability. In other words, this embodiment addresses the problems caused by the existence of new and old data in different libraries and with different data structures during data migration by adding a routing application layer between the external caller and the old application. This avoids extensive code adaptation and modification for external callers, allowing the migration work to proceed more flexibly, controllably, and securely without waiting for external caller scheduling.

[0076] For example, if the migration factor is selected as "customer," the compatibility routing layer, upon receiving customer information from an external source, can determine whether the customer has been migrated or not based on the batch information of the current migration factor. Migrated customers undergo structural adaptation and are forwarded to the new application (i.e., the target database), while unmigrated customers are directly forwarded to the old application (i.e., the source database). For instance, if one batch has already been migrated, and the batch content consists of customers in Guangdong Province, then a customer from Shenzhen will be routed to the new application; a customer from Hangzhou will be routed to the old application. This embodiment can manage external interface calls through the compatibility routing layer, recording each call and distribution, tracing the correctness of new and old distributions, and statistically analyzing the distribution of new and old data calls.

[0077] In summary, this embodiment can record all migration data information based on the migration data list, support batch / single rollback, ensure that the migration process is controllable and traceable, and improve the stability of data migration. Furthermore, by unifying interface messages through the newly added routing gateway layer and data routing decision table, it completes the routing distribution of old and new data, shields the upstream system from the perception of database changes, avoids the need for adaptation and modification of external systems, facilitates data migration scheduling, and avoids the impact of external calls on data migration, making the data migration process flexible and secure.

[0078] This embodiment discloses a method for writing a batch migration list into a data routing determination table in the target database. Upon receiving a data call request, the service identifier carried in the request is parsed, and the data routing determination table is queried to determine whether the service identifier is within the migration range. If the service identifier is within the migration range, the target database is determined as the routing determination result. The data call request is distributed according to the routing determination result. When the routing determination result is the source database, the data call request undergoes interface normalization conversion to generate a standard routing request; the standard routing request is then distributed to the source database. It is checked whether all the data to be migrated has been migrated to the target database; if so, the data to be migrated in the source database is deleted, and the corresponding data routing determination table in the target database is deleted. This embodiment can record all migration data information based on the migration data list, supports batch / single rollback, ensures that the migration process is controllable and traceable, and improves the stability of data migration. Furthermore, it unifies interface messages through the newly added routing gateway layer and data routing determination table, and completes the routing distribution of old and new data, shielding the upstream system from the perception of database changes, avoiding the need for external system adaptation and modification, facilitating data migration scheduling, and preventing external calls from affecting data migration in various ways, making the data migration process flexible and secure.

[0079] For example, to help understand the technical concept or principle of the heterogeneous data migration method after combining this embodiment with the above-described Embodiments 1 and 2, please refer to Figure 5 , Figure 5 The following is a schematic diagram illustrating the heterogeneous data migration method of this application: like Figure 5 As shown, the migration device can be configured with a data synchronization tool and a data migration program to perform many-to-many data migration. These tools can also be two microservice architectures. In this case, the data migration process can be divided into the following four steps: 1) Source data push: Figure 5 The source databases and target databases are heterogeneous databases, with many-to-many relationships between them, and the source tables and target tables have the same structure.

[0080] During the source data push phase, the data synchronization tool simply pushes the original table A from the source database to table A' in the target database with the same structure. Only after data migration will the data be transferred to the new table B in the target database. At this stage, the data synchronization tool does not need to consider the heterogeneous differences between the source and target databases; it directly pushes the table from the source database to a table with the same structure in the target database for transition. This simplifies the data migration process, avoids spending a significant amount of time on format conversion in the source database, reduces the complexity of application development, minimizes memory pressure on the data migration application, and improves data mapping performance.

[0081] 2) Filter the batch migration list: The selection of batch migration lists can be carried out in parallel with data push. The source database is read-heavy and write-light, while the target database is read-light and write-heavy, which can make full use of database resources and smooth the database and migration application load.

[0082] Furthermore, the data migration program (which can be clustered) can filter data based on the migration data manifest table generated during the migration process. This migration data manifest table typically contains only a limited number of fields such as batch number, business type, business serial number, rollback flag, timestamp, and status. It has a small storage footprint and can serve as the basis for task sharding, improving the performance of SQL joins for mapping transformation and data deletion, and enhancing data mapping performance. Simultaneously, the migration data manifest table can be shared across different migration applications, effectively reducing the complexity of data rollback scenarios.

[0083] 3) Data migration to the target database has been rolled back: For migrated data, the system needs to support single-item and batch rollback functionality. This is to handle situations where a single piece of data exceeds the migration logic, or where the migration is incomplete due to other exceptional circumstances.

[0084] 4) Data verification: Data consistency verification can be performed through... Figure 5 Data synchronization tools are implemented in the system; Data consistency verification during migration involves checking the number of migrated data entries using a checklist and verifying the consistency of data fields using the source data being pushed. Figure 5 Data migration procedures are implemented in the process; Data consistency verification during deletion involves checking the consistency of the number of deleted records in the source data using a list table. Figure 5 Data migration procedures are implemented in the process.

[0085] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the heterogeneous data migration method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0086] This application also provides a heterogeneous data migration device; please refer to... Figure 6 , Figure 6 This is a schematic diagram of the module structure of the heterogeneous data migration device according to an embodiment of this application. In this embodiment, the heterogeneous data migration device includes: Rule determination module 601 is used to obtain heterogeneous mapping rules between the source database and the target database; Data push module 602 is used to create a migration transition table in the target database according to the heterogeneous mapping rules, and synchronize the data to be migrated in the source database to the migration transition table to generate homogeneous mirror data; Data filtering module 603 is used to filter the isomorphic mirror data in batches based on the target migration factor and generate a batch migration list; The data migration module 604 is used to convert the format of the batch migration list according to the heterogeneous mapping rules, obtain target format data, and write the target format data into the target database.

[0087] Optionally, in this embodiment, the data push module 602 is further configured to extract key elements from the heterogeneous mapping rules to obtain mapping structure information; convert the mapping structure information into migration table creation statements corresponding to the database schema name of the target database; and execute the migration table creation statements in the target database to create a migration transition table in the target database.

[0088] Optionally, in this embodiment, the data filtering module 603 is further configured to obtain migration factor candidates selected by the user from migration dimension information, wherein the migration dimension information includes customer dimension, user dimension and business dimension; filter the migration factor candidates based on preset evaluation rules to obtain target migration factors; divide the value range of the target migration factors into several migration sub-intervals; and filter the isomorphic mirror data in batches according to the migration sub-intervals to generate a batch migration list.

[0089] Optionally, in this embodiment, the data migration module 604 is further configured to write the batch migration list into the data routing determination table of the target database; when a data call request is received, perform routing determination on the data call request based on the data routing determination table; and distribute the data call request according to the routing determination result.

[0090] Optionally, in this embodiment, the data migration module 604 is further configured to, upon receiving a data call request, parse the service identifier carried in the data call request and query the data routing determination table to determine whether the service identifier is within the migrated range; if the service identifier is within the migrated range, determine the target database as the routing determination result.

[0091] Optionally, in this embodiment, the data migration module 604 is further configured to, when the routing determination result is the source database, perform interface normalization conversion on the data call request to generate a standard routing request; and distribute the standard routing request to the source database.

[0092] Optionally, in this embodiment, the data migration module 604 is further configured to detect whether all the data to be migrated has been migrated to the target database; if so, the data to be migrated in the source database is deleted, and the data routing determination table corresponding to the target database is deleted.

[0093] The heterogeneous data migration apparatus provided in this application, employing the heterogeneous data migration method in the above embodiments, can solve the technical problem of heterogeneous data migration. Compared with the prior art, the beneficial effects of the heterogeneous data migration apparatus provided in this application are the same as those of the heterogeneous data migration method provided in the above embodiments, and other technical features in the heterogeneous data migration apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0094] This application provides a heterogeneous data migration device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable 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 perform the heterogeneous data migration method in the above embodiment 1.

[0095] The following is for reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing heterogeneous data migration devices in the embodiments of this application. The heterogeneous data migration devices in the embodiments of this application may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The heterogeneous data migration device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0096] like Figure 7As shown, the heterogeneous data migration device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the heterogeneous data migration device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the heterogeneous data migration device to communicate wirelessly or wiredly with other devices to exchange data. Although a heterogeneous data migration device with various systems is shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0097] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in this application include a heterogeneous data migration program product, which includes a heterogeneous data migration program carried on a computer-readable medium, the heterogeneous data migration program containing program code for performing the methods shown in the flowcharts. In such embodiments, the heterogeneous data migration program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the heterogeneous data migration program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0098] The heterogeneous data migration device provided in this application, employing the heterogeneous data migration method in the above embodiments, can solve the technical problem of how to provide an efficient and stable heterogeneous data migration solution to meet the needs of diverse business scenarios. Compared with the prior art, the beneficial effects of the heterogeneous data migration device provided in this application are the same as those of the heterogeneous data migration method provided in the above embodiments, and other technical features in this heterogeneous data migration device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0099] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0100] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0101] This application provides a storage medium having computer-readable program instructions (i.e., a heterogeneous data migration program) stored thereon, which are used to execute the heterogeneous data migration method in the above embodiments.

[0102] The storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of the storage medium may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0103] The aforementioned storage medium may be included in a heterogeneous data migration device; or it may exist independently and not be assembled into a heterogeneous data migration device.

[0104] The aforementioned storage medium carries one or more programs. When the aforementioned one or more programs are executed by the heterogeneous data migration device, the heterogeneous data migration device is activated.

[0105] Heterogeneous data migration program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0106] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and heterogeneous data migration program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0107] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0108] The readable storage medium provided in this application is a storage medium that stores computer-readable program instructions (i.e., a heterogeneous data migration program) for executing the above-described heterogeneous data migration method. This addresses the technical problem of how to provide an efficient and stable heterogeneous data migration solution to meet the needs of diverse business scenarios. Compared with the prior art, the beneficial effects of the storage medium provided in this application are the same as those of the heterogeneous data migration method provided in the above embodiments, and will not be repeated here.

[0109] The above are only some embodiments of this application and do not limit the scope of the solution of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A heterogeneous data migration method, characterized in that, The method includes: Obtain the heterogeneous mapping rules between the source database and the target database; According to the heterogeneous mapping rules, a migration transition table is created in the target database, and the data to be migrated in the source database is synchronized to the migration transition table to generate homogeneous mirror data; Based on the target migration factor, the isomorphic mirror data is filtered in batches to generate a batch migration list; The batch migration list is format-converted according to the heterogeneous mapping rules to obtain target format data, and the target format data is written into the target database.

2. The heterogeneous data migration method as described in claim 1, characterized in that, The step of creating a migration transition table in the target database according to the heterogeneous mapping rules includes: Key elements are extracted from the heterogeneous mapping rules to obtain mapping structure information; The mapping structure information is converted into migration table creation statements corresponding to the database schema name of the target database; Execute the migration table creation statement in the target database to create a migration transition table in the target database.

3. The heterogeneous data migration method as described in claim 1, characterized in that, The step of batch filtering the isomorphic mirror data based on the target migration factor to generate a batch migration list includes: Obtain the migration factor candidates selected by the user from the migration dimension information, which includes customer dimension, user dimension and business dimension; The candidate migration factors are screened based on preset evaluation rules to obtain the target migration factors; The range of values ​​for the target migration factor is divided into several migration sub-intervals; The isomorphic mirror data is filtered in batches according to the migration sub-intervals to generate a batch migration list.

4. The heterogeneous data migration method as described in claim 1, characterized in that, After the step of batch filtering the isomorphic mirror data based on the target migration factor to generate a batch migration list, the method further includes: Write the batch migration list into the data routing decision table of the target database; Upon receiving a data retrieval request, the data retrieval request is routed based on the data routing determination table. The data retrieval request is distributed based on the routing determination result.

5. The heterogeneous data migration method as described in claim 4, characterized in that, The step of performing route determination on the data call request based on the data routing determination table upon receiving a data call request includes: Upon receiving a data call request, the service identifier carried in the data call request is parsed, and the data routing determination table is queried to determine whether the service identifier is within the migrated range; If the service identifier is within the migrated range, the target database is determined as the routing decision result.

6. The heterogeneous data migration method as described in claim 4, characterized in that, The step of distributing the data retrieval request based on the routing determination result includes: When the routing determination result is the source database, the data call request is subjected to interface normalization conversion to generate a standard routing request; The standard routing request is distributed to the source database.

7. The heterogeneous data migration method as described in claim 4, characterized in that, After writing the target format data into the target database, the method further includes: The system checks whether all the data to be migrated has been migrated to the target database. If so, delete the data to be migrated from the source database and delete the data routing decision table corresponding to the target database.

8. A heterogeneous data migration device, characterized in that, The heterogeneous data migration device includes: The rule determination module is used to obtain the heterogeneous mapping rules between the source database and the target database; The data push module is used to create a migration transition table in the target database according to the heterogeneous mapping rules, and synchronize the data to be migrated in the source database to the migration transition table to generate homogeneous mirror data; The data filtering module is used to filter the isomorphic mirror data in batches based on the target migration factor and generate a batch migration list; The data migration module is used to convert the batch migration list according to the heterogeneous mapping rules to obtain target format data, and write the target format data into the target database.

9. A heterogeneous data migration device, characterized in that, The device includes: a memory, a processor, and a heterogeneous data migration program stored on the memory and executable on the processor, the heterogeneous data migration program being configured to implement the steps of the heterogeneous data migration method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a heterogeneous data migration program, which, when executed by a processor, implements the steps of the heterogeneous data migration method as described in any one of claims 1 to 7.

Images