Elasticsearch database data migration method, device, equipment and storage medium

Abstract

The present invention provides a data migration method, device, equipment and storage medium of an Elasticsearch database. When the data migration method of the Elasticsearch database of the present invention obtains the field name of the table header of a relational database data table from the indexed type type data, the full path field name defined by each field is used as the field name in the table header of the relational database data table, and each full path field name that needs to be split is split according to the field type attached to each full path field name. The field name of the table header of the relational database data table generated by the data migration method of the Elasticsearch database of the present invention is flatter, which avoids the loss of the field name recorded in the type type data during the data migration process and improves the readability of the generated relational database data table.

Description

Technical Field

[0001] The present invention relates to the technical field of database migration, and in particular to a data migration method, device, equipment and storage medium for an Elasticsearch database. Background Art

[0002] Elasticsearch is a Lucene-based search server that provides a distributed, multi-user, full-text search engine based on a RESTful web interface. On the other hand, Elasticsearch is a non-relational database like MongoDB and redis, and is also a near real-time search platform.

[0003] For existing tools for extracting data from Elasticsearch databases, when extracting data of complex data types from the Elasticsearch database, the table structure data extracted from the relational database data table is directly extracted into the data table without being processed, which can easily cause the loss of some table structure data and poor readability of the data table. When it is necessary to analyze the data in the data table, it is even more difficult to process and analyze.

[0004] Therefore, the prior art still needs to be improved and developed. Summary of the invention

[0005] The main purpose of the present invention is to solve the technical problems that the existing Elasticsearch database data migration method easily causes data loss and has poor data readability.

[0006] A first aspect of the present invention provides a data migration method for an Elasticsearch database, comprising the steps of:

[0007] Access the index of the data to be extracted in the Elasticsearch database;

[0008] Get the type data under the index;

[0009] Traverse each field definition in the type data;

[0010] Get the full path field name of each field definition and the field type attached to each full path field name;

[0011] Write the full path field names of each entry into the first row of the relational database data table in the order of traversal;

[0012] Determine whether each of the full path field names needs to be split based on the field type attached to each of the full path field names;

[0013] If the full path field name needs to be split, N split field names are obtained based on the splitting rule corresponding to the field type of the full path field name that needs to be split;

[0014] In the first row of the relational database data table, the column where the full path field name to be split is located is split into N columns, and the N split field names are filled into the N columns;

[0015] The document corresponding to the type type data is obtained, and the data corresponding to each full path field name recorded in the document is filled into the relational database data table according to the mapping relationship.

[0016] In an optional implementation of the first aspect of the present invention, the obtaining of the full path field name of each field definition and the field type attached to each full path field name includes:

[0017] For each of the field definitions, if the field definition has only one root node, the full path field name of the field definition is the field name of the root node; if the field definition has several child nodes and leaf nodes in addition to the root node, the full path field name of the field definition is a combination of the field name of the root node, the field names of several child nodes and the field name of the leaf node, and in the full path field name, the field name of the root node, the field names of several child nodes and the field name of the leaf node are separated by English periods.

[0018] In an optional implementation of the first aspect of the present invention, the determining whether each of the full path field names needs to be split based on the field type attached to each of the full path field names includes:

[0019] Determine whether the field type attached to each of the full path field names is a multi-value type;

[0020] If the field type is a multi-value type, it is determined that the full path field name needs to be split;

[0021] If the field type is not a multi-value type, it is determined that the full path field name does not need to be split.

[0022] In an optional implementation of the first aspect of the present invention, the multi-value type includes a numerical range type, a geographic location type, and an array type.

[0023] In an optional implementation of the first aspect of the present invention, if the full path field name needs to be split, obtaining N split field names based on the splitting rule corresponding to the field type of the full path field name that needs to be split includes:

[0024] If the field type is a numerical range type, there are two split field names, one of which is the full path field name that needs to be split and the path combination field name of .gte, and the other is the full path field name that needs to be split and the path combination field name of .lte.

[0025] In an optional implementation of the first aspect of the present invention, if the full path field name needs to be split, obtaining N split field names based on the splitting rule corresponding to the field type of the full path field name that needs to be split also includes:

[0026] If the field type is a geographic location type, there are also two split field names, one of which is the path combination field name of the full path field name to be split and .lat, and the other is the path combination field name of the full path field name to be split and .lon.

[0027] In an optional implementation of the first aspect of the present invention, in the type type data, each of the field definitions is defined using JSON syntax rules.

[0028] A second aspect of the present invention provides a data migration device for an Elasticsearch database, the data migration device for an Elasticsearch database comprising:

[0029] Access module, used to access the index of the data to be extracted in the Elasticsearch database;

[0030] A first acquisition module is used to acquire type data under the index;

[0031] A traversal module, used to traverse each field definition in the type data;

[0032] The second acquisition module is used to obtain the full path field name of each field definition and the field type attached to each full path field name;

[0033] A writing module, used to write each of the full path field names into the first row of the relational database data table in the order of traversal;

[0034] A judgment module, used for judging whether each of the full path field names needs to be split based on the field type attached to each of the full path field names;

[0035] A field name splitting module, for obtaining N split field names based on the splitting rule corresponding to the field type of the full path field name that needs to be split, if the full path field name needs to be split;

[0036] A splitting module, used for splitting the column where the full path field name to be split is located into N columns in the first row of the relational database data table, and filling the N split field names into the N columns;

[0037] The second writing module is used to obtain the document corresponding to the type type data, and fill the data corresponding to each full path field name recorded in the document into the relational database data table according to the mapping relationship.

[0038] A third aspect of the present invention provides a data migration device for an Elasticsearch database, the data migration device for an Elasticsearch database comprising: a memory and at least one processor, the memory storing instructions, the memory and the at least one processor being interconnected via a line;

[0039] The at least one processor calls the instructions in the memory so that the database iteration test device executes the data migration method of the Elasticsearch database as described in any one of the above items.

[0040] A fourth aspect of the present invention provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the data migration method of the Elasticsearch database as described in any one of the above items is implemented.

[0041] Beneficial effect: The present invention provides a data migration method, device, equipment and storage medium for an Elasticsearch database. When the data migration method for an Elasticsearch database of the present invention obtains the field name of the table header of a relational database data table from the indexed type type data, the full path field name defined by each field is used as the field name in the table header of the relational database data table, and each full path field name that needs to be split is split according to the field type attached to each full path field name. The field name of the table header of the relational database data table generated by the data migration method for an Elasticsearch database of the present invention is flatter, which avoids the loss of the field name recorded in the type type data during the data migration process and improves the readability of the generated relational database data table. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 A schematic diagram of an embodiment of a data migration method for an Elasticsearch database according to the present invention;

[0043] Figure 2A schematic diagram of an embodiment of a data migration device for an Elasticsearch database according to the present invention;

[0044] Figure 3 A schematic diagram of an embodiment of a data migration device for an Elasticsearch database of the present invention. DETAILED DESCRIPTION

[0045] Embodiments of the present invention provide a data migration method, device, equipment and storage medium for an Elasticsearch database. The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" or "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0046] For ease of understanding, the specific process of the embodiment of the present invention is described below. Figure 1 The first aspect of the present invention provides a data migration method for an Elasticsearch database, comprising the steps of:

[0047] S100. Access the index of the data to be extracted in the Elasticsearch database. Elasticsearch is a search server based on Lucene. It provides a distributed multi-user full-text search engine based on the RESTful web interface. On the other hand, Elasticsearch is a non-relational database like MongoDB and redis, and is also a near real-time search platform.

[0048] Elasticsearch (ES for short) includes index, type and document. Type is used to define the data structure. Under each index, there can be one or more types, which is like a table in a database, which is equivalent to the description of the table structure and the type of each field. Document is the final data. It can be considered that a document is a record, which is the smallest data unit in ES, just like a piece of data in a table.

[0049] For example, a poem has fields such as title, author, dynasty, word count, and content. First, we can create an index called Poems, and then create a type called Poem. The type is defined by Mapping to define the type of each field. For example, the title, author, and dynasty are all Keyword types, the content is Text type, and the word count is Integer type. Finally, the data is organized into Json format and stored.

[0050] S200, obtaining the type data under the index; in this embodiment, after accessing the index to be extracted, it is necessary to obtain the type data corresponding to the index and obtain the table structure description corresponding to the index, and then extract the field names required by the database data table from the table structure description;

[0051] S300, traversing each field definition in the type data; in the type data, each field definition is defined using JSON syntax rules.

[0052] For example, there is an index called user_sample in elasticsearch, and its structure is as follows:

[0053]

[0054]

[0055] Type data is the content included in the "properties" after "user_sample", where the fields of the records are defined as "id", "user age", "user name first", "user name last", "userweight", "location", etc.

[0056] S400, obtaining the full path field name of each field definition and the field type attached to each full path field name; in this embodiment, each field type corresponds to a field definition, that is, as many full path field names as there are field types;

[0057] Specifically, the obtaining of the full path field name of each field definition and the field type attached to each full path field name includes:

[0058] For each of the field definitions, if the field definition has only one root node, the full path field name of the field definition is the field name of the root node; if the field definition has several child nodes and leaf nodes in addition to the root node, the full path field name of the field definition is a combination of the field name of the root node, the field names of several child nodes and the field name of the leaf node, and in the full path field name, the field name of the root node, the field names of several child nodes and the field name of the leaf node are separated by English periods.

[0059] Taking the index of user_sample as an example, "id":{"type":"long"} has only one root node, so the full path field name is id, and the field type is long. For "user", it includes two child nodes, "age" and "name", and "name" includes two leaf nodes, "first" and "last". Since "age" has no node, "age" is also called a leaf node. "user" includes three full path field names, user.Age, user.name.first, and user.name.last. The field types are integer, text, and text respectively.

[0060] S500, writing each of the full path field names into the first row of the relational database data table in the order of traversal;

[0061] In this embodiment, taking the above-mentioned index of user_sample as an example, the data recorded in the first row of the relational database data table are / id / , / user.Age / , / user.name.first / , / user.name.last / , / weight / and / location / .

[0062] S600. Determine whether each of the full-path field names needs to be split based on the field type attached to each of the full-path field names. In the present embodiment, each full-path field name corresponds to a field type, such as id corresponds to long, user.Age corresponds to integer, weight corresponds to integer_range, and location corresponds to geo_point. After the field name is subdivided by the full path, it is necessary to further determine whether it needs to be further split based on the corresponding field type.

[0063] Specifically, judging whether each of the full path field names needs to be split based on the field type attached to each of the full path field names includes:

[0064] Determine whether the field type attached to each of the full path field names is a multi-value type; a multi-value type is literally understood as a type with multiple values, and the multi-value type includes a value range type, a geographic location type, and an array type. If the field type is a multi-value type, it is determined that the full path field name needs to be split; if the field type does not belong to a multi-value type, it is determined that the full path field name does not need to be split.

[0065] S700: If the full path field name needs to be split, obtain N split field names based on the splitting rule corresponding to the field type of the full path field name that needs to be split;

[0066] Specifically, if the full path field name needs to be split, the N split field names obtained based on the splitting rule corresponding to the field type of the full path field name that needs to be split include:

[0067] If the field type is a numeric range type, there are two split field names, one of which is the path combination field name of the full path field name to be split and .gte (greater than or equal to), and the other is the path combination field name of the full path field name to be split and .lte (less than or equal to); taking the above-mentioned user_sample index as an example, the field type integer_range corresponding to the field name weight belongs to the numeric range type, so weight is split into weight.gte and weight.lte;

[0068] If the field type is a geographic location type, there are also two split field names, one of which is the path combination field name of the full path field name to be split and .lat (latitude), and the other is the path combination field name of the full path field name to be split and .lon (longitude). Taking the above user_sample index as an example, the field type geo_point corresponding to the field name location belongs to the geographic location type, so location is split into location.lat(x) and location.lon(y).

[0069] S800. In the first row of the relational database data table, split the column where the full path field name to be split is located into N columns, and fill the N split field names into the N columns; in this embodiment, taking the above-mentioned user_sample index as an example, when all the full path field names are split, the data recorded in the first row of the relational database data table is / id / , / user.Age / , / user.name.first / , / user.name.last / , / weight.gte / , / weight.lte / , / location.lat(x) / and / location.lon(y) / .

[0070] S900, obtaining the document corresponding to the type data, and filling the data corresponding to each full path field name recorded in the document into the relational database data table according to the mapping relationship. In this embodiment, when the document data is filled into the relational database data table, since the format of the data recorded in the document is consistent with the type description table, it is only necessary to fill the obtained value into the bottom of each field of the relational database data table according to the corresponding mapping relationship.

[0071] The specific implementation process of an exemplary data migration method of the present invention is as follows: Assume that there is an index called user_sample in elasticsearch, and its structure is as follows:

[0072]

[0073]

[0074] Taking the above index as an example, when extracting the table structure, the id field will be extracted to the target table as an independent field because it is already a leaf node.

[0075] The user field is different. We cannot simply use the user field as a field in the target table because it has child nodes. For such fields with child nodes, we will flatten the fields. In the above example, the user field has three child nodes:

[0076] 2.1. First, traverse to the age node. By querying the node information, it is found that age is a leaf node. Therefore, the age field under the user field is flattened into the user.age field as the field of the target table.

[0077] 2.2. Then traverse to the name node. By querying the node information, it is found that there are still child nodes under the name node, so continue to traverse the child nodes under the name node. There are two child nodes under the name field:

[0078] 2.2.1. First, traverse to the first node. By querying the node information, it is found that first is a leaf node. Therefore, the first field under the name field under the user field is flattened into the user.name.first field, which is used as the field of the target table.

[0079] 2.2.2, Then traverse to the last node, and by querying the node information, it is found that last is a leaf node, so the last field under the name field under the user field is flattened into the user.name.last field, which is used as the field of the target table;

[0080] 2.3. After the child nodes under the name node are traversed, the weight node is traversed. By querying the node information, it is found that although weight is a leaf node, it is a range data type in elasticsearch, which represents a range, so it will also be flattened. For the range type, it will be flattened into two fields, weight.gte and weight.lte, which means greater than or equal to a certain value, and less than or equal to a certain value. In the above example, it is integer_range, so the values ​​of the two fields weight.gte and weight.lte are both int data types;

[0081] After the above sub-node traversal under the user node is completed, the location node is traversed next. By querying the node information, it is found that although location is a leaf node, it is a geo_point data type in elasticsearch, which represents the geographic location, so it will also be flattened. For the geo_point type, it will be flattened into two fields, location.lat and location.lon, which means the values ​​of longitude and latitude.

[0082] When all child nodes under the user_sample index are traversed, the table structure is extracted.

[0083] Assume that the data of the user_sample index in Elasticsearch is as follows:

[0084]

[0085]

[0086]

[0087] When extracting table data, some steps are the same as when extracting table structure. The biggest difference is that array data in elasticsearch will be split into multiple rows and inserted into the target table. Take the second element in hits as an example, that is, the object element (_source) with _id 1:

[0088] Traverse the data of the id field. Since the id node has no sub-options, that is, no child nodes, the data is directly extracted.

[0089] When traversing the data of the user field, since the user node contains sub-options, it will also be flattened. As shown in the figure above, it contains two sub-options, and then traverse each sub-option obtained;

[0090] 2.1. First, traverse to the age node. By querying the node information, it is found that the age node does not contain sub-options, so the value of age is directly extracted as the value of the flattened field user.age in the target table;

[0091] 2.2. Then traverse to the name node. By querying the node information, it is found that the name node still contains sub-options, so continue to traverse the sub-nodes under the name node. There are two sub-nodes under the name field:

[0092] 2.2.1. First, traverse to the first node. By querying the node information, it is found that the first node does not contain sub-options, so the value of the first node is extracted as the value of the flattened field user.name.first in the target table;

[0093] 2.2.2, then traverse to the last node, query the node information, find that the last node does not contain sub-options, so extract the value of the last as the value of the flattened field user.name.last in the target table;

[0094] 2.3. After the above sub-node traversal under the name node is completed, the weight node is traversed. By querying the node information, it is found that the weight node still contains sub-options, so it is necessary to continue to traverse the sub-nodes under the weight node in the same way as traversing the name. The process is the same as 2.2

[0095] 2.4. At this point, the traversal of the first sub-option under the user node is completed, so the second sub-option under the user node is traversed, that is, the process of 2.1-2.3 is repeated;

[0096] After traversing all the sub-options under the obtained user node, continue to traverse the location node. This process is still the same as 2.2

[0097] After traversing one element in hits, traverse the other elements in hits until all elements in hits are traversed.

[0098] In the above steps 2.1-2.4, that is, in the user with id=1, the data volume in elasticsearch is 1, but when it is extracted to the target table, there will be two records, that is, the data volume extracted to the target table is 2. This is what is said above, the data is split into multiple rows.

[0099] See also Figure 2 According to a second aspect of the present invention, a data migration device for an Elasticsearch database is provided. The data migration device for an Elasticsearch database comprises:

[0100] Access module 10, used to access the index of the data to be extracted in the Elasticsearch database;

[0101] A first acquisition module 20 is used to acquire type data under the index;

[0102] A traversal module 30, used for traversing each field definition in the type data;

[0103] The second acquisition module 40 is used to acquire the full path field name of each field definition and the field type attached to each full path field name;

[0104] A writing module 50 is used to write each of the full path field names into the first row of the relational database data table in the order of traversal;

[0105] A judgment module 60, configured to judge whether each of the full path field names needs to be split based on the field type attached to each of the full path field names;

[0106] A field name splitting module 70, for obtaining N split field names based on a splitting rule corresponding to the field type of the full path field name that needs to be split, if the full path field name needs to be split;

[0107] A splitting module 80 is used to split the column containing the full path field name to be split into N columns in the first row of the relational database data table, and fill the N split field names into the N columns;

[0108] The second writing module 90 is used to obtain the document corresponding to the type type data, and fill the data corresponding to each full path field name recorded in the document into the relational database data table according to the mapping relationship.

[0109] In an optional implementation of the second aspect of the present invention, the second acquisition module 40 includes:

[0110] A full path field name generating unit is used for, for each field definition, if the field definition has only one root node, then the full path field name of the field definition is the field name of the root node; if the field definition has several child nodes and leaf nodes in addition to the root node, then the full path field name of the field definition is a combination of the field name of the root node, the field names of several child nodes and the field names of the leaf nodes, and in the full path field name, the field name of the root node, the field names of several child nodes and the field name of the leaf node are separated by English periods.

[0111] In an optional implementation of the second aspect of the present invention, the judgment module 60 includes:

[0112] A judging unit, used for judging whether the field type attached to each of the full path field names is a multi-value type;

[0113] A first determination unit, configured to determine whether the full path field name needs to be split if the field type is a multi-value type;

[0114] The second determination unit is configured to determine that the full path field name does not need to be split if the field type is not a multi-value type.

[0115] In an optional implementation of the second aspect of the present invention, the multi-value type includes a numerical range type, a geographic location type, and an array type.

[0116] In an optional implementation of the second aspect of the present invention, the field name splitting module 70 includes:

[0117] The first field name splitting unit is used for, if the field type is a numerical range type, there are two split field names, one of which is the full path field name to be split and the path combination field name of .gte, and the other split field name is the full path field name to be split and the path combination field name of .lte.

[0118] In an optional implementation of the second aspect of the present invention, the field name splitting module 70 further includes:

[0119] The second field name splitting unit is used for, if the field type is a geographic location type, there are also two split field names, one of which is the path combination field name of the full path field name to be split and .lat, and the other is the path combination field name of the full path field name to be split and .lon.

[0120] In an optional implementation of the second aspect of the present invention, in the type type data, each of the field definitions is defined using JSON syntax rules.

[0121] Figure 3 It is a structural diagram of a data migration device for an Elasticsearch database provided by an embodiment of the present invention. The data migration device for the Elasticsearch database may have relatively large differences due to different configurations or performances, and may include one or more processors 110 (central processing units, CPU) (for example, one or more processors) and a memory 120, and one or more storage media 130 for storing applications or data (for example, one or more massive storage devices). Among them, the memory and the storage medium may be short-term storage or persistent storage. The program stored in the storage medium may include one or more modules (not shown in the figure), and each module may include a series of instruction operations in the database iteration test device. Furthermore, the processor may be configured to communicate with the storage medium to execute a series of instruction operations in the storage medium on the data migration device for the Elasticsearch database.

[0122] The data migration device of the Elasticsearch database of the present invention may also include one or more power supplies 140, one or more wired or wireless network interfaces 150, one or more input and output interfaces 160, and / or one or more operating systems, such as Windows Serve, Mac OS X, Unix, Linux, FreeBSD, etc. It can be understood by those skilled in the art that Figure 3 The structure of the data migration device for the Elasticsearch database shown does not constitute a limitation on the data migration device for the Elasticsearch database, and may include more or fewer components than shown in the figure, or a combination of certain components, or a different arrangement of components.

[0123] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When the instructions are executed on a computer, the computer executes the steps of the Elasticsearch database data migration method.

[0124] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the above-described system, device, or unit can refer to the corresponding process in the aforementioned method embodiment and will not be repeated here.

[0125] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program codes.

[0126] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A data migration method for an Elasticsearch database, characterized in that: Includes steps: Access the index of the data to be extracted in the Elasticsearch database; Get the type data under the index; Traverse each field definition in the type data, wherein each field definition in the type data is defined using JSON syntax rules; Get the full path field name of each field definition and the field type attached to each full path field name; Write the full path field names of each entry into the first row of the relational database data table in the order of traversal; Determine whether each of the full path field names needs to be split based on the field type attached to each of the full path field names; If the full path field name needs to be split, N split field names are obtained based on the splitting rule corresponding to the field type of the full path field name that needs to be split; In the first row of the relational database data table, the column where the full path field name to be split is located is split into N columns, and the N split field names are filled into the N columns; Obtain the document corresponding to the type data, and fill the data corresponding to each full path field name recorded in the document into the relational database data table according to the mapping relationship; The step of obtaining the full path field name of each field definition and the field type attached to each full path field name includes: For each of the field definitions, if the field definition has only one root node, the full path field name of the field definition is the field name of the root node; if the field definition has several child nodes and leaf nodes in addition to the root node, the full path field name of the field definition is a combination of the field name of the root node, the field names of several child nodes and the field name of the leaf node, and in the full path field name, the field name of the root node, the field names of several child nodes and the field name of the leaf node are separated by English periods.

2. The data migration method of the Elasticsearch database according to claim 1, characterized in that: The determining whether each of the full path field names needs to be split based on the field type attached to each of the full path field names includes: Determine whether the field type attached to each of the full path field names is a multi-value type; If the field type is a multi-value type, it is determined that the full path field name needs to be split; If the field type is not a multi-value type, it is determined that the full path field name does not need to be split.

3. The data migration method of the Elasticsearch database according to claim 2, characterized in that: The multi-value type includes a numerical range type, a geographic location type, and an array type.

4. The data migration method of the Elasticsearch database according to claim 3, characterized in that: If the full path field name needs to be split, the N split field names obtained based on the splitting rule corresponding to the field type of the full path field name that needs to be split include: If the field type is a numerical range type, there are two split field names, one of which is the full path field name that needs to be split and the path combination field name of .gte, and the other is the full path field name that needs to be split and the path combination field name of .lte.

5. The data migration method of the Elasticsearch database according to claim 4, characterized in that: If the full path field name needs to be split, obtaining N split field names based on the splitting rule corresponding to the field type of the full path field name that needs to be split also includes: If the field type is a geographic location type, there are also two split field names, one of which is the path combination field name of the full path field name to be split and .lat, and the other is the path combination field name of the full path field name to be split and .lon.

6. A data migration device for an Elasticsearch database, characterized in that: The data migration device of the Elasticsearch database includes: Access module, used to access the index of the data to be extracted in the Elasticsearch database; A first acquisition module is used to acquire type data under the index; A traversal module, used to traverse each field definition in the type type data, wherein each field definition in the type type data is defined using JSON syntax rules; The second acquisition module is used to obtain the full path field name of each field definition and the field type attached to each full path field name; A writing module, used to write each of the full path field names into the first row of the relational database data table in the order of traversal; A judgment module, used for judging whether each of the full path field names needs to be split based on the field type attached to each of the full path field names; A field name splitting module, for obtaining N split field names based on the splitting rule corresponding to the field type of the full path field name that needs to be split, if the full path field name needs to be split; A splitting module, used for splitting the column where the full path field name to be split is located into N columns in the first row of the relational database data table, and filling the N split field names into the N columns; The second writing module is used to obtain the document corresponding to the type data, and fill the data corresponding to each full path field name recorded in the document into the relational database data table according to the mapping relationship; Wherein, the second acquisition module includes: A full path field name generating unit is used for, for each field definition, if the field definition has only one root node, then the full path field name of the field definition is the field name of the root node; if the field definition has several child nodes and leaf nodes in addition to the root node, then the full path field name of the field definition is a combination of the field name of the root node, the field names of several child nodes and the field names of the leaf nodes, and in the full path field name, the field name of the root node, the field names of several child nodes and the field name of the leaf node are separated by English periods.

7. A data migration device for an Elasticsearch database, characterized in that: The data migration device of the Elasticsearch database includes: a memory and at least one processor, the memory stores instructions, and the memory and the at least one processor are interconnected through a line; The at least one processor calls the instructions in the memory so that the database iteration test device executes the data migration method of the Elasticsearch database as described in any one of claims 1-5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the data migration method of the Elasticsearch database according to any one of claims 1 to 5 is implemented.

Images