An automated migration method and system for graph database metadata

Abstract

This invention discloses an automated migration method and system for graph database metadata, belonging to the field of graph database data migration technology. The method includes: acquiring metadata from a source graph database, including structural definitions of vertex and edge types; performing full sampling analysis on vertex and edge data in the source graph database to construct a distribution mapping relationship from vertices to types and a connection mapping relationship from edges to vertex types; generating graph structure definition statements for the target graph database based on the metadata, distribution mapping relationship, and connection mapping relationship, combined with a preset migration strategy; and sending the graph structure definition statements to the target graph database for execution to complete graph structure modeling. This application can meet the migration needs between different versions of graph databases and ensure data consistency and integrity, thus having broad application prospects.

Description

Technical Field

[0001] This invention relates to the field of graph database data migration technology, and in particular to an automated method and system for migrating graph database metadata. Background Technology

[0002] With the rapid development of graph database technology, its underlying data model and query language are constantly evolving, leading to increasingly frequent needs for cross-version system upgrades and data migration. In this process, the migration quality of graph database metadata directly affects the smoothness of the system transition and the reliability of the data, becoming a core challenge impacting migration efficiency and the accuracy of results.

[0003] Currently, most common data migration tools are designed for basic data records and lack in-depth support for graph structure metadata. Specifically, existing tools struggle to effectively handle complex metadata elements such as node types, edge types, attribute structures, and their constraints, and their mechanisms for ensuring data consistency and integrity during migration are generally insufficient. Furthermore, structural differences in data models among different graph database products further increase the difficulty of metadata mapping and transformation.

[0004] At the migration methodology level, traditional approaches heavily rely on manual operation, inferring the type of nodes and edges by comparing entities and business logic in the source database one by one. This method is suitable for simple scenarios where node and edge types are singular and the types of nodes connected by edges are fixed. However, faced with the multi-type node models commonly supported by modern graph databases (such as NebulaGraph 3.x and Neo4j), existing methods cannot achieve complete identification and accurate mapping of the type system, nor can they cope with complex type combinations and structural constraints. This directly leads to coverage defects and semantic distortion problems in metadata migration.

[0005] Therefore, in the current graph database technology ecosystem, there is an urgent need for a metadata migration solution that can achieve automation, high accuracy and high efficiency to cope with the increasingly frequent version upgrades and cross-system migration requirements, and to ensure the structural consistency and business continuity of graph data systems during the evolution process. Summary of the Invention

[0006] The purpose of this invention is to provide an automated migration method and system for graph database metadata, so as to solve the problems of low migration efficiency, incomplete coverage and poor semantic consistency of existing technologies when facing complex types of systems and multi-source heterogeneous environments.

[0007] To achieve the above objectives, this application adopts the following technical solution:

[0008] This application discloses an automated migration method for graph database metadata, comprising the following steps:

[0009] Obtain the metadata from the source graph database, including the structural definitions of vertex and edge types;

[0010] A full sampling analysis is performed on the vertex and edge data in the source graph database to construct the distribution mapping relationship from vertex to type and the connection mapping relationship from edge to vertex type;

[0011] Based on the metadata, distribution mapping relationship, and connection mapping relationship, and in conjunction with the preset migration strategy, the graph structure definition statement of the target graph database is generated.

[0012] The graph structure definition statement is sent to the target graph database for execution to complete the graph structure modeling.

[0013] Preferably, the acquisition of metadata from the source graph database includes:

[0014] The metadata client obtains basic information about the source graph database graph space, as well as a list of names for all vertex and edge types. The basic information includes the number of slices and the vertex identifier type.

[0015] By executing the structure description command through the graph service client, detailed attribute definitions for all vertex and edge types can be obtained. These detailed attribute definitions include attribute name, data type, whether it can be nullable, and default value.

[0016] Preferably, the step of obtaining metadata from the source graph database further includes:

[0017] The metadata is read and cached using a distributed computing framework.

[0018] Preferably, the step of performing full sampling analysis on the vertex and edge data in the source graph database to construct the distribution mapping relationship from vertex to type and the connection mapping relationship from edge to vertex type includes:

[0019] The sampled vertex data is fully sampled, and the sampled vertex data is grouped according to the vertex identifier to obtain the type set corresponding to each vertex. Based on the type set, a distribution mapping relationship from vertex to type is formed.

[0020] The edge data is fully sampled, and the sampled edge data is connected to the type set corresponding to the vertex. Based on the connection results, the start type and end type of each edge are determined, forming a connection mapping relationship from edge to vertex type.

[0021] Preferably, the migration strategy includes an attribute name conflict resolution strategy and a data type mapping rule.

[0022] Preferably, the attribute name conflict resolution strategy includes:

[0023] When a property name conflict is detected, the property name is renamed by concatenating a type name prefix.

[0024] Preferably, the data type mapping rules include:

[0025] Convert the data types in the source graph database to the data types supported by the target graph database.

[0026] Preferably, the migration strategy includes a target mode strategy for handling multiple vertex types, the target mode strategy including a merge mode and a non-merge mode.

[0027] Preferably, the graph structure definition statement for generating the target graph database includes:

[0028] Based on the vertex type definitions and the distribution mapping relationship from vertex to type, determine the vertex type definitions in the target graph database;

[0029] Based on the edge type structure definition and the connection mapping relationship from edge to vertex type, determine the edge type definition in the target graph database;

[0030] According to the migration strategy, the attributes in the vertex type definition and edge type definition are processed;

[0031] Based on the processed vertex type and edge type definitions, generate definition statements for creating the target graph database graph structure.

[0032] Preferably, sending the graph structure definition statement to the target graph database for execution to complete the graph structure modeling includes:

[0033] The graph structure definition statement is sent to the metadata service of the target graph database for execution to create the graph space and schema.

[0034] Preferably, after completing the graph structure modeling, the following is also included:

[0035] Initiate a data migration job to import data from the source graph database into the target graph database.

[0036] An automated migration system for graph database metadata includes:

[0037] The metadata extraction module is used to obtain the metadata of the source graph database, which includes the structural definitions of vertex type and edge type;

[0038] The data-driven analysis module is used to perform full sampling analysis on the vertex data and edge data in the source graph database, and to construct the distribution mapping relationship from vertex to type and the connection mapping relationship from edge to vertex type.

[0039] The statement conversion and generation module is used to generate graph structure definition statements for the target graph database based on the metadata, distribution mapping relationship and connection mapping relationship, combined with a preset migration strategy.

[0040] The target library execution module is used to send the graph structure definition statement to the target graph database for execution, thereby completing the graph structure modeling.

[0041] The present invention has the following beneficial effects:

[0042] The automated graph database metadata migration method provided in this application can meet the migration needs between different versions of graph databases, ensuring data consistency and integrity. Furthermore, through distributed data processing and flexible configuration options, it can also handle large-scale graph database migration tasks, demonstrating broad application prospects. Attached Figure Description

[0043] 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, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a flowchart of an automated migration method for graph database metadata provided in an embodiment of this application;

[0045] Figure 2 This is a flowchart illustrating the process of obtaining metadata from a source graph database, as provided in an embodiment of this application.

[0046] Figure 3 This is a flowchart illustrating the construction of the distribution mapping relationship from vertex to type and the connection mapping relationship from edge to vertex type provided in the embodiments of this application;

[0047] Figure 4 This is a flowchart of the graph structure definition statement for generating a target graph database provided in an embodiment of this application;

[0048] Figure 5 This is a schematic diagram of the structure of an automated migration system for graph database metadata provided in an embodiment of this application. Detailed Implementation

[0049] To make the technical solution of this application clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The terms "first," "second," etc., in the claims and specification of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate. This is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0050] Example 1

[0051] like Figure 1 As shown, this embodiment provides an automated migration method for graph database metadata, including steps S110-S140.

[0052] S110. Obtain the metadata of the source graph database, including the structural definitions of vertex type and edge type;

[0053] During the initialization phase, the user-input parameters (from the command line or configuration file) are first parsed to convert them into structured configuration objects that the program can directly use. These parameters include the source graph database's server address (data retrieval address), the target graph database's server address (data import address), authentication information such as the username and password required to connect to the database, the name of the graph space to be migrated, and the migration strategy.

[0054] After parameter conversion is completed, a validity check is performed. If the check fails, the program terminates immediately; if the check passes, metadata is retrieved from the source graph database based on the parsed configuration information, specifically including the structural definitions of vertex and edge types.

[0055] In some embodiments, such as Figure 2 As shown, obtaining metadata from the source graph database includes the following steps:

[0056] S210. Obtain basic information about the source graph database graph space and a list of names for all vertex and edge types through the metadata client. The basic information includes the number of slices and the vertex identifier type.

[0057] S220. Execute the structure description command through the graph service client to obtain the detailed attribute definitions of all vertex and edge types. The detailed attribute definitions include attribute name, data type, whether nullables are allowed, and default value.

[0058] In graph databases, metadata is the core data that describes the graph space, vertex types (tags), and edge types (edge ​​types) and their attribute definitions. Metadata is typically obtained by executing structure description commands (such as DESC EDGE) or querying through a dedicated metadata client, yielding detailed definitions including names, data types, constraints (such as whether null values ​​are allowed), and default values.

[0059] In this embodiment, the metadata acquisition process is divided into two main stages, corresponding to different service components and operation methods. Specifically, firstly, a metadata client (such as Nebula Graph's MetaClient) connects to the graph database's metadata service (such as Meta Service) to obtain basic information about the specified graph space, including but not limited to the number of shards and vertex identifier (VID) types, and extracts a list of names for all vertex and edge types in the graph space. Next, a graph service client (such as Graph Client) executes structural description commands, specifically the DESC TAG command for each vertex type and the DESC EDGE command for each edge type, to obtain its detailed attribute definitions. The DESC TAG command queries the metadata of vertex types, returning information such as attribute names, data types, whether null values ​​are allowed, and default values; the DESC EDGE command queries the metadata of edge types, covering attribute definitions and related constraint rules.

[0060] By using the metadata client and the graph service client together, the structural metadata in the source graph database can be extracted systematically and completely, providing an accurate structural foundation for subsequent data migration or structural synchronization.

[0061] In some embodiments, obtaining metadata from the source graph database further includes:

[0062] Use a distributed computing framework to read and cache metadata.

[0063] In this embodiment, after obtaining the metadata of the source graph database, the method further includes the step of reading and caching the metadata using a distributed computing framework.

[0064] Specifically, a connection to the source graph database is established using a distributed computing framework (such as Apache Spark), and complete metadata information is obtained through parallel reading. This metadata includes, but is not limited to, basic graph space information, a list of vertex and edge types, and detailed attribute definitions for each type.

[0065] After the data is read, the distributed computing framework persists this metadata to its memory, forming a metadata cache. This cache serves as the source of metadata for subsequent data processing tasks (such as data transformation or migration), effectively avoiding repeated access to the source graph database's metadata service, thereby reducing the load on the source system and improving overall processing efficiency.

[0066] By introducing a distributed computing framework for unified reading and caching of metadata, this embodiment can effectively address the metadata management needs under large-scale graph structures, improve the stability of metadata acquisition, and enhance the execution performance of subsequent data migration processes.

[0067] S120. Perform full sampling analysis on the vertex data and edge data in the source graph database, and construct the distribution mapping relationship from vertex to type and the connection mapping relationship from edge to vertex type;

[0068] After obtaining the metadata of the source graph database, the vertex and edge data in the source graph database are subjected to hierarchical full sampling processing based on a distributed computing architecture. Through type distribution analysis and edge relationship association analysis, a distribution mapping table from vertex to type and a connection mapping table from edge to vertex type are dynamically generated.

[0069] In some embodiments, such as Figure 3 As shown, a full sampling analysis is performed on the vertex and edge data in the source graph database to construct the distribution mapping relationship from vertex to type and the connection mapping relationship from edge to vertex type. The specific steps include:

[0070] S310. Fully sample vertex data, group the sampled vertex data according to vertex identifiers to obtain the type set corresponding to each vertex, and form a distribution mapping relationship from vertex to type based on the type set;

[0071] S320. Fully sample edge data, perform connection operations between the sampled edge data and the type set corresponding to the vertex, and determine the start type and end type of each edge based on the connection results, forming a connection mapping relationship from edge to vertex type.

[0072] Specifically, all vertex data is extracted from the source graph database through the connector of the distributed computing framework, and a two-stage operation is performed: First, a `groupBy` operation is performed to group and cluster the sampled vertex data according to the vertex identifier, ensuring that all data of the same vertex are grouped into the same group; then, a `collect_list` operation is performed to aggregate the type information of all vertices within the group into a list of type sets, and finally, a distribution mapping table of vertices to types is generated based on this list. This mapping table can be represented as a key-value pair structure of {(VID,[Type1,Type2,...])}.

[0073] Similarly, all edge data is first extracted through the connector of the distributed computing framework, and the start identifier, end identifier, and edge type information of each edge are extracted. Then, a vertex type cache table is established to store the identifier of each vertex and its associated type set. Next, a two-way association operation is performed, matching the start identifier and end identifier of the edge data with the vertex type cache table according to the vertex identifier to determine the type combination information of the corresponding vertex. Finally, based on the three elements of start type combination StartTypeSet, end type combination EndTypeSet, and edge type EdgeType, the type of the edge in the target graph database is defined through a pattern matching algorithm, thereby obtaining the connection mapping relationship table from edge to vertex type. This connection mapping relationship table can be represented as a structured record {(EdgeID,(StartTypeSet,EndTypeSet,EdgeType))}, where EdgeID represents the edge identifier.

[0074] Data-driven analysis ensures the accuracy of edge type mapping and composite node type definition, avoids ambiguity that may arise from analysis based on pure structure definition, and perfectly maintains the original business intent and data relationship.

[0075] Assume the sampled edges are e1 and e2, where e1 has a start identifier of user100, an end identifier of user200, and an edge type of follow; e2 has a start identifier of user100, an end identifier of prod500, and an edge type of purchase. The known vertex type information is: user100 corresponds to the type set {"user", "VIP"}, vertex user200 corresponds to the type set {"user"}, and vertex prod500 corresponds to the type set {"product"}. By associating the edge data with the vertex type data according to the start and end identifiers, the start type combination of e1 is {"user", "VIP"}, the end type combination is {"user"}, and the edge type is follow, defining the edge type user_follow_user in the target graph database; the start type combination of e2 is {"user", "VIP"}, the end type combination is {"product"}, and the edge type is purchase, defining the edge type user_purchase_product in the target graph database.

[0076] Through hierarchical full sampling and association analysis, this embodiment can dynamically derive the node type system and edge type system of the target graph database based on the actual data distribution characteristics of the source graph database. Simultaneously, the efficient processing capabilities of the distributed computing framework ensure the accuracy of type inference even in scenarios with massive graph data, providing a precise type foundation for subsequent graph model construction. This is a key technical path to guarantee model fidelity.

[0077] S130. Based on metadata, distribution mapping relationships, and connection mapping relationships, and combined with the preset migration strategy, generate the graph structure definition statement for the target graph database;

[0078] In this embodiment, the migration strategy mainly covers three aspects: attribute name conflict resolution strategy, data type mapping rules, and target pattern strategy for handling multiple vertex types. These strategies work together to ensure the consistency, integrity, and availability of data during cross-version or cross-system migration.

[0079] Firstly, regarding attribute name conflict resolution, an automatic detection and handling mechanism is built-in to identify and eliminate potential attribute name conflicts between different vertex or edge types. The default strategy is "attribute name prefix concatenation," for example, mapping the attribute 'name' belonging to Tag: player in the source graph database to 'player_name' in the target graph database. This strategy, implemented through the configuration option 'noModifyNodePropName,' effectively prevents data confusion caused by duplicate attribute names at the structural level, enhancing the clarity of model representation and query accuracy.

[0080] Secondly, to address the differences in data type systems, the migration strategy established clear data type mapping rules to ensure compatibility in type representation between the source and target graph databases. For example, the FIXED_STRING type in Nebula Graph v3 is mapped to the STRING type in v5, and the TIMESTAMP type is mapped to the INT64 type. This mechanism not only ensures semantic consistency of data during migration but also fully considers the preservation of data precision and representation range, effectively avoiding information loss or format errors caused by type conversion.

[0081] In addition, to adapt to diverse business scenarios, this migration strategy also introduces a target mode strategy, which includes two options: Merge Mode and Non-Merge Mode, to guide the organization of vertex types in the target graph database.

[0082] In the merge mode, multiple types associated with the same vertex in the source graph database will be merged into a single composite node type (Node Type with Multiple Labels) in the target graph database. This mode is suitable for scenarios where it is desirable to maintain the multi-label characteristics of the source data, allowing the original complex type logic to continue in the target graph database, and facilitating cross-label joint queries and analysis.

[0083] In the non-merge mode, each type in the source and target graph databases is mapped to an independent vertex type in the target graph database. This mode is more suitable for scenarios with relatively simple model structures or where clear type separation is desired on the target side, helping to reduce the complexity of the data model and improve maintainability.

[0084] Users can flexibly choose the target model according to their actual business needs, thereby achieving fine-grained control over the target graph database model during the migration process.

[0085] In some embodiments, such as Figure 4 As shown, the graph structure definition statement for generating the target graph database is generated, specifically including steps S410-S440.

[0086] S410. Based on the vertex type definition and the distribution mapping relationship from vertex to type, determine the vertex type definition in the target graph database;

[0087] In this step, the original definitions of vertex types in the source graph database are first read. Then, based on the vertex-to-type distribution mapping relationship obtained from the analysis, the vertex types in the target graph database are reconstructed. This mapping relationship precisely describes the affiliation of each vertex instance in the source graph database with one or more vertex types. When merging types, a vertex may correspond to multiple types in the source graph database; in this case, it needs to be merged into a composite vertex type in the target graph database. When maintaining type independence, the mapping relationship is usually one-to-one, and the source type is directly mapped to the independent type of the target. The output of this step is the vertex type system of the target graph database, which clarifies whether the relationships between types are merged or independent.

[0088] S420. Based on the edge type structure definition and the connection mapping relationship from edge to vertex type, determine the edge type definition in the target graph database;

[0089] This step is executed in parallel with or after S410, and its processing logic depends on the target vertex type definition output by S410. Based on the edge type structure definition in the source graph database, the connection mapping relationship from edge to vertex type is comprehensively analyzed. This relationship clarifies how each edge should connect to the redefined vertex type in the target graph database. For example, when two vertex types connected by an edge in the source graph database have been merged in the target graph database, the connection semantics of the edge need to be redefined to ensure it points to the correct composite vertex type; when vertex types are mapped independently, the connection relationship of the edge is adjusted accordingly to point to the independent vertex type in the target graph database. The output of this step is a set of edge type definitions in the target graph database that strictly corresponds to the vertex type system, ensuring the correctness and integrity of the topological associations after migration.

[0090] S430. Process the attributes in the vertex type definition and edge type definition according to the migration strategy;

[0091] After defining the type structure of vertices and edges, the attributes attached to these types are refined according to a predetermined migration strategy. This migration strategy covers the type merging or independence relationships determined in steps S410 and S420, and includes specific attribute processing rules. Specifically, it applies an attribute name conflict resolution strategy, particularly for vertex types merged in step S410, automatically handling potential attribute name conflicts between attributes from different source types to ensure the global uniqueness and semantic clarity of each attribute in the target graph database. Based on data type mapping rules, the data types in the source graph database are converted to types supported by the target graph database, with a focus on resolving the unification of attributes with the same name but different types resulting from type merging, ensuring that the precision, range, and semantics of data values ​​are fully preserved during the conversion process.

[0092] This step standardizes and normalizes all types of attribute definitions according to a unified strategy, laying a solid foundation for subsequent data import and querying.

[0093] S440. Based on the processed vertex type definition and edge type definition, generate the definition statement for creating the target graph database graph structure.

[0094] The vertex and edge type definitions, processed by the migration strategy and output from the previous steps, are used as input. Then, based on the specific syntax and specifications of the target graph database, a complete and error-free set of graph structure definition statements (such as CREATE TAG, CREATE EDGE, etc.) is automatically generated. These statements are operation instructions that can be directly executed on the target graph database, automatically constructing a target graph schema that corresponds to the source data structure and meets design expectations. This step greatly reduces the workload of manually writing table creation statements and effectively avoids errors that may be introduced by manual operation, ensuring migration efficiency and reliability.

[0095] S140. Send the graph structure definition statement to the target graph database for execution to complete the graph structure modeling.

[0096] This step is the final execution stage of graph structure migration. It involves automatically and accurately executing the graph structure definition statements generated in the previous steps, which are fully compatible with the target graph database syntax, in order to complete the physical graph structure modeling.

[0097] Specifically, through the standard data operation interfaces provided by the target graph database (such as Graph API, JDBC driver or custom client), the generated definition statements such as CREATE TAG and CREATE EDGE are sent to the target graph database's meta service in batch or sequential execution.

[0098] During execution, the response status of the target graph database is monitored to ensure that every statement is executed correctly. If a statement fails to execute due to network interruption, syntax errors, or insufficient permissions, the system can trigger predefined fault tolerance mechanisms, such as logging errors, attempting automatic retry, or interrupting the entire modeling process and rolling back successfully executed statements, thereby ensuring the consistency and controllability of the target graph database schema state.

[0099] Once all definition statements are successfully executed, it signifies that all metadata, including vertex types, edge types, and related attributes, in the target graph database has been created. An empty graph structure corresponding to the source data model and conforming to the established migration strategy has been formally established on the target side. This empty graph structure provides an indispensable, predefined structured container for the subsequent import of large-scale vertex and edge data records, ensuring the accuracy and efficiency of data import.

[0100] In some embodiments, after completing the graph structure modeling, the method further includes:

[0101] Start the data migration job to import data from the source graph database into the target graph database.

[0102] After successfully completing the graph structure modeling of the target graph database (i.e., establishing empty vertex types, edge types, and related indexes), the system can initiate a data migration operation to import the actual data records from the source graph database into the target database in batches.

[0103] Specifically, this data migration operation typically involves two main data flows: vertex data migration and edge data migration. Vertex data migration begins by scanning and extracting vertex records from the source graph database. Each vertex record contains its unique identifier and one or more associated attribute data types. When writing to the target graph database, the target vertex type definition and attribute name processing strategy established in steps S410 and S430 are strictly followed. In this way, vertices are written to the correct type, and their attribute names and data types have been converted according to the migration strategy.

[0104] During edge data migration, records are first scanned from the source graph database. Each record contains its starting vertex ID, target vertex ID, edge type, and related attributes. During writing, based on the target edge type definition and attribute name processing strategy established in steps S420 and S430, it is ensured that the edge connection relationships are accurately reconstructed between the corresponding vertices in the target graph database, and its attributes also follow the established mapping and conflict resolution rules.

[0105] Once all vertex and edge data has been successfully imported, a complete and usable graph dataset that corresponds structurally to the source graph database and conforms to the migration strategy in terms of data is constructed in the target graph database.

[0106] In this embodiment, distributed data reading and processing are performed through a distributed computing engine, which can efficiently handle the migration of metadata from large-scale graph databases. It also supports user-defined configurations and migration strategies, such as whether to merge multiple node types in v3 or merge nodes with the same attributes, to meet different migration requirements. During the migration process, full data reading and analysis are employed to obtain new metadata information in a data-driven manner, ensuring the consistency of metadata in the target graph database and the source graph database, and avoiding data loss or errors.

[0107] Example 2

[0108] like Figure 5 As shown, this embodiment provides an automated migration system for graph database metadata, including:

[0109] The metadata extraction module is used to obtain the metadata from the source graph database, which includes the structural definitions of vertex types and edge types.

[0110] The data-driven analysis module is used to sample and analyze vertex and edge data in the source graph database, and to construct the distribution mapping relationship from vertex to type and the connection mapping relationship from edge to vertex type.

[0111] The statement conversion and generation module is used to generate graph structure definition statements for the target graph database based on metadata, distribution mapping relationships, and connection mapping relationships, combined with preset migration strategies.

[0112] The target library execution module is used to send the graph structure definition statements to the target graph database for execution, thereby completing the graph structure modeling.

[0113] This embodiment is used to implement the method provided in the above embodiments and has the corresponding beneficial effects of the method. Technical details not described in detail in this embodiment can be found in the methods provided in all the foregoing embodiments of this invention.

[0114] Example 3

[0115] This embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of the above-described method for automatically migrating metadata of a graph database.

[0116] This computer device can be a server or a terminal. It includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps of an automated migration method for graph database metadata.

[0117] This embodiment also provides a computer-readable storage medium storing a computer program or instructions thereon, which, when executed by a processor, implements the steps of the above-described method for automatically migrating metadata of a graph database.

[0118] This embodiment also provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps of the above-described method for automatically migrating metadata of a graph database.

[0119] These computer-readable programs / instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0120] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A method for automated migration of graph database metadata, the method comprising: The method comprises the following steps: obtaining metadata of a source graph database, the metadata comprising structure definitions of vertex types and edge types; performing full sampling analysis on vertex data and edge data in the source graph database to construct a distribution mapping relationship of vertices to types to which the vertices belong and a connection mapping relationship of edges to vertex types; based on the metadata, the distribution mapping relationship and the connection mapping relationship, combining a preset migration strategy to generate graph structure definition statements of a target graph database, the migration strategy comprising an attribute name conflict resolution strategy, data type mapping rules and a target schema strategy for processing vertex multiple types, the target schema strategy comprising a merge schema and a non-merge schema; sending the graph structure definition statements to the target graph database for execution to complete graph structure modeling; wherein the full sampling analysis on the vertex data and the edge data in the source graph database to construct the distribution mapping relationship of vertices to types to which the vertices belong and the connection mapping relationship of edges to vertex types comprises: full sampling of vertex data, grouping the sampled vertex data according to vertex identifiers to obtain a type set corresponding to each vertex, and forming a distribution mapping relationship of vertices to types to which the vertices belong based on the type set; full sampling of edge data, connecting the sampled edge data with the type set corresponding to the vertices, and determining the start type and the end type connected by each edge based on the connection result to form a connection mapping relationship of edges to vertex types; the attribute name conflict resolution strategy comprises: when an attribute name conflict is detected, renaming the attribute name by concatenating a type name prefix; the data type mapping rules comprise: converting data types in the source graph database to data types supported by the target graph database; the generation of the graph structure definition statements of the target graph database comprises: determining vertex type definitions in the target graph database based on the structure definitions of the vertex types and the distribution mapping relationship of vertices to types to which the vertices belong; determining edge type definitions in the target graph database based on the structure definitions of the edge types and the connection mapping relationship of edges to vertex types; processing attributes in the vertex type definitions and the edge type definitions according to the migration strategy; generating definition statements for creating a graph structure of the target graph database according to the processed vertex type definitions and edge type definitions.

2. The method for automated migration of graph database metadata according to claim 1, wherein, the obtaining of the metadata of the source graph database comprises: obtaining basic information of a graph space of the source graph database and a name list of all vertex types and edge types through a metadata client, the basic information comprising the number of shards and the type of vertex identifiers; obtaining detailed attribute definitions of all vertex types and edge types through a graph service client executing a structure description command, the detailed attribute definitions comprising attribute names, data types, whether null is allowed and default values.

3. The method for automated migration of graph database metadata according to claim 2, wherein, the obtaining of the metadata of the source graph database further comprises: reading and caching the metadata using a distributed computing framework.

4. The method for automated migration of graph database metadata according to claim 1, wherein, the sending of the graph structure definition statements to the target graph database for execution to complete graph structure modeling comprises: sending the graph structure definition statements to a metadata service of the target graph database for execution to create a graph space and a schema.

5. The method for automated migration of graph database metadata according to claim 1, wherein, Further comprising after completing the graph structure modeling: Starting a data migration job to import data from the source graph database to the target graph database.

6. An automated migration system of graph database metadata characterized in that, Comprising: a metadata extraction module for obtaining metadata of the source graph database, the metadata comprising structure definitions of vertex types and edge types; a data-driven analysis module for performing full-sampling analysis on vertex data and edge data in the source graph database, constructing a distribution mapping relationship of vertices to types to which the vertices belong, and a connection mapping relationship of edges to vertex types; a statement conversion and generation module for generating graph structure definition statements of the target graph database based on the metadata, the distribution mapping relationship, and the connection mapping relationship, in combination with a preset migration strategy, the migration strategy comprising an attribute name conflict resolution strategy, a data type mapping rule, and a target schema strategy for handling vertex multi-types, the target schema strategy comprising a merge schema and a non-merge schema; a target library execution module for sending the graph structure definition statements to the target graph database for execution to complete graph structure modeling; wherein the full-sampling analysis on the vertex data and the edge data in the source graph database, the construction of the distribution mapping relationship of vertices to types to which the vertices belong, and the connection mapping relationship of edges to vertex types, comprises: full-sampling vertex data, grouping the sampled vertex data according to vertex identifiers to obtain a type set corresponding to each vertex, and forming a distribution mapping relationship of vertices to types to which the vertices belong based on the type set; full-sampling edge data, performing a join operation on the sampled edge data and the type set corresponding to the vertices, and determining a start type and an end type connected by each edge based on the join result to form a connection mapping relationship of edges to vertex types; the attribute name conflict resolution strategy comprises: renaming the attribute name by concatenating a type name prefix when an attribute name conflict is detected; the data type mapping rule comprises: converting data types in the source graph database to data types supported by the target graph database; the generation of the graph structure definition statements of the target graph database comprises: determining vertex type definitions in the target graph database based on the structure definitions of the vertex types and the distribution mapping relationship of vertices to types to which the vertices belong; determining edge type definitions in the target graph database based on the structure definitions of the edge types and the connection mapping relationship of edges to vertex types; processing attributes in the vertex type definitions and the edge type definitions according to the migration strategy; generating definition statements for creating a graph structure of the target graph database according to the processed vertex type definitions and edge type definitions.

Images