CN111639075A - Non-relational database vector data management method based on flattened R tree - Google Patents

Abstract

The invention provides a vector data management method in a non-relational database, which is oriented towards a distributed non-relational database, and designs an index structure based on an R-tree flattening strategy for vector data; establishes a library table structure including the vector data and the index structure, and related to each other; encode vector data into the database, and build a flattened R-tree index at the same time; provide a spatial query processing algorithm based on flattened R-tree for vector data; maintain vector data in non-relational databases, including update and delete . By establishing an R-tree index based on a flattening strategy, the present invention provides the non-relational database with the vector data query processing capability supported by the R-tree, and can support the organization and management of large-scale vector data, enabling mass storage and parallel computing of the non-relational database. , and technical dividends such as high availability and high reliability benefit vector data types.

Description

A non-relational database vector data management method based on flattened R tree

technical field

The invention belongs to the technical field of databases, in particular to a vector data management method in a non-relational database.

Background technique

More than 85% of the data in the real world is related to geographic location. According to the McKinsey Global Institute report, the total amount of global geospatial data in 2016 has exceeded 6000PB, and it is still increasing at the speed of PB level every year. Compared with the simple structure of raster data, the structure of vector data is complex, and it undertakes the main tasks of spatial analysis and spatial data query. Heterogeneous and unstructured vector data increases the difficulty of using traditional relational database management; in the face of huge and continuously growing massive data sets, relational databases also have insurmountable problems in scalability.

The non-relational database follows the CAP theory and the BASE principle. While weakening the transactional nature, it emphasizes schema freedom, read and write efficiency, and horizontal scalability. It can provide efficient random access, multi-format data storage, and highly concurrent data read and write. It provides new ideas and methods for this problem with its powerful expansion ability and computing power. Non-relational database systems usually use the Key-Value storage model to store data, and automatically establish an index on the key to ensure efficient data query. In addition, the query capability of the database can be enriched by establishing a secondary index.

The purpose of spatial index is to improve query efficiency. Traditional spatial index is not designed for distributed environment. When storing and managing massive vector data, there are many problems such as difficulty in data storage organization and difficulty in meeting real-time query requirements. The native spatial index of non-relational database has poor support for vector data. Taking MongoDB as an example, 2d index and 2dsphere index are the two spatial indexes natively supported by MongoDB. 2d index only supports index of point elements, and 2dsphere index does not support it. Problems such as plane coordinate data and poor adaptability to data make it difficult to support the query processing of vector data.

It can be seen that there is no suitable index when using a non-relational database to manage massive vector data. Using the native spatial index method will cause the database to be unable to efficiently organize and manage data, and it is difficult to take advantage of the high concurrency of non-relational databases.

SUMMARY OF THE INVENTION

The technical problem to be solved by the present invention is to provide a vector data management method in a non-relational database, which provides the distributed non-relational database with the ability to organize and manage massive vector data.

The technical scheme adopted by the present invention to solve the above-mentioned technical problems is: a vector data management method in a non-relational database, characterized in that: the method comprises the following steps:

S1. In a non-relational database environment, design an auxiliary index structure based on the R-tree flattening strategy for vector data;

S2. Establish a library table structure including vector data and an index structure, and associate each data table in the library table structure with an explicit association record and an implicit naming rule;

S3. Encode the vector data into the library for storage, organize the geometry and attribute information in GeoJSON and JSON respectively, and build a flattened R-tree index at the same time;

S4. When a query request is received, the index metadata ID is determined according to the query conditions, and then the R-tree root node ID is obtained, so that the vector data retrieval is performed in parallel based on the R-tree index table, and the query result is finally returned;

S5. Maintain the vector data in the non-relational database, including updating and deleting.

According to the above method, in the S1, the specific design steps of the auxiliary index structure based on the R-tree flattening strategy are as follows:

1.1. The vector object is abstracted as the Minimum Bounding Rectangle (Minimum Bounding Rectangle), and the MBRs with adjacent spatial positions will be recursively merged into a higher-level MBR, and finally form a hierarchical tree structure based on the minimum outer rectangle;

1.2. Expand the R-tree index structure into a flat set of index nodes, that is, express each index node as a JSON structure, and use the unique identifier of the node as the pointer of the parent index item to the child index node;

1.3. Set the fan-out coefficient M of the R-tree, except for the root node, specify that the number of child nodes of the remaining R-tree nodes is between the interval [2, M].

According to the above method, in the R tree node, the record format of the R leaf node is <OID, MBR>, and the record format of the intermediate node is <OID, Pointer, MBR>; wherein OID is the unique identifier of the node, Pointer OID pointing to its child node, MBR is the smallest enclosing rectangle.

According to the above method, in the described S2, the design of the library table structure is as follows:

2.1. Manage multi-source heterogeneous vector data in the form of data sets, each vector data set organizes logically related vector data of the same type;

2.2. Design the vector data table, the R-tree index table, the vector metadata table and the index metadata table, which are used to store the vector elements, the index structure of the vector data set, and the metadata of both;

2.3. Establish the relationship between the four types of tables: vector data table, R-tree index table, vector metadata table and index metadata table. Each vector data set corresponds to a vector data table and an R-tree index table, and respectively. Metadata descriptions are made in the vector metadata table and the index metadata table.

According to the above method, the S3 specifically includes:

3.1. Take the vector dataset as a unit, encode all the vector elements in it and write it into the vector data table, and organize the geometry and attribute information in the form of GeoJSON and JSON respectively; GeoJSON is a geospatial information data based on JavaScript object notation exchange format;

3.2. Query the geometric metadata information of the spatial domain where the vector elements are located in the vector metadata table, and obtain the corresponding index metadata ID;

3.3. Obtain the R-tree index table and its root node ID from the index metadata table. According to the geometric relationship between the minimum enclosing rectangle of the vector element and the enclosing rectangle of the index item, navigate to the destination leaf node of the R-tree index table, and insert the information about the vector element. Index item, update the R-tree index table;

3.4. After completing the writing of the vector dataset, update the vector metadata table and the index metadata table.

According to the above method, in 3.3, the specific method of ID node navigation and R-tree index table update includes the following steps:

3.3.1. According to the geometric relationship between the minimum outer rectangle of the vector element and the outer rectangle of the index item, use the ID node navigation to find the best insertion node, and judge whether the number of child nodes of the node exceeds the set fan-out coefficient, if it exceeds Fan-out coefficient, go to step 3.3.2, otherwise go to step 3.3.3;

3.3.2. Perform node splitting operation, divide the node into two new nodes through the R-tree node splitting algorithm, and navigate again to find the best insertion node;

3.3.3. Insert the index item of the vector element into the node, and update the node;

3.3.4. If the root node is split, update the information of the root node in the index metadata table.

According to the above method, the structure of the JSON is {ID,L,C,D}; where ID is the unique identifier of the index node, namely OID; L(Level) is the level of the node in the tree; C(Count) The number of child nodes that the node has; D (Descendants) is a JSON nested structure, which records the unique identifier and minimum bounding box of the child nodes owned by the node; the detailed structure of D (Descendants) is D:{{P,M },...,{P,M}}, where P(Pointer) points to the OID of its child node, and M(MBR) is the smallest enclosing rectangle of the child node, organized in the form of GeoJSON.

According to the above method, the S4 specifically includes:

4.1. The user specifies the query conditions such as the dataset name, query scope, etc.;

4.2. Query the geometric metadata information of the spatial domain in the vector metadata table according to the given query conditions, and obtain the ID information of the corresponding index metadata;

4.3. Obtain the ID of the R-tree index table and its root node from the index metadata table;

4.4. Query the R-tree index table, and take out the index items of the vector elements that meet the query conditions;

4.5. Take out the vector data from the vector data table, perform fine filtering, and finally get the query result.

According to the above method, the specific method of querying the R-tree index table in 4.4 includes the following steps:

4.4.1. Obtain the corresponding key-value pair in the R-tree index table through the ID information of the root node, take it out and deserialize it;

4.4.2. Determine the relationship between the MBR of each child node and the query range from the geometric information in GeoJSON, find out the child nodes where the MBR intersects with the query range or are within the query range, and retrieve the corresponding child index node according to the pointer of the parent index item to the child index node. child node key-value pair and deserialize;

4.4.3. Repeat step 4.4.2 until the leaf node of the R tree is queried.

According to the above method, in the described S5, the process of deleting the vector data includes:

5.1. Query the geometric metadata information of the spatial domain where the data to be deleted is located in the vector metadata table, and obtain the corresponding index metadata information;

5.2. Obtain the R-tree index table and its root node from the index metadata table, and locate the index item associated with the vector element to be deleted according to the geometric relationship between the minimum outer rectangle of the R-tree node and the query box;

5.3. Delete the corresponding vector data in the vector data table;

5.4. Delete the index entry associated with the vector data in the R-tree index table.

According to the above solution, the index information of the corresponding data is updated only after the data insertion operation is completed, in order to ensure the integrity of the content entry. In a non-relational database, errors are the norm. If an index entry is inserted first, the system crashes after the index entry is inserted. After restarting, the system will consider that the data has been stored in the database, resulting in data loss.

The beneficial effects of the present invention are as follows: the method of the present invention stores the geometric information of the vector data in the GeoJSON file, and encodes the data in the form of key-value pairs and stores it in the library; by designing the index structure based on the flattened R tree, the adjacent space in the space is guaranteed. Entities are stored in the same or adjacent storage nodes; it provides R-tree-supported vector data query processing for distributed non-relational databases, and can use the distributed storage characteristics of non-relational databases to perform multi-node parallel execution of R-tree query operations , making full use of the distributed and high concurrency characteristics of non-relational databases, greatly improving query efficiency; the update and deletion of vector data will not cause index errors and meet the requirements of real-time data access.

Description of drawings

FIG. 1 is a flowchart of a method according to an embodiment of the present invention.

FIG. 2 is a spatial distribution of a vector element MBR according to an embodiment of the present invention.

FIG. 3 is a schematic diagram of an R-tree structure corresponding to FIG. 2 .

FIG. 4 is an example of a storage structure of vector data in an embodiment of the present invention.

FIG. 5 is a library table structure and an association relationship including vector data and an index structure established by an embodiment of the present invention.

FIG. 6 is a flowchart of vector data insertion and R-tree index construction.

FIG. 7 is a flow chart of vector data query.

FIG. 8 is a flow chart of vector data deletion.

Detailed ways

The present invention will be further described below with reference to specific examples and accompanying drawings.

As shown in Figure 1, the present invention provides a non-relational database vector data management method based on a flattened R tree, the method specifically includes:

101. In a non-relational database environment, an auxiliary index structure based on the R-tree flattening strategy is designed for vector data.

Specifically, the embodiment of the present invention designs a flattened R-tree index storage scheme for HBase database. The scheme uses the unique identifier of the R-tree node as the row key, and the node information is in the JSON nested format as each item in the column family E. Columns are stored in the database. Among them, the spatial information of vector data is organized in GeoJSON format. Each row in the data table represents a node, and all nodes with the same index are stored in the same R-tree index table. The detailed structure is shown in Table 1-1.

Table 1-1 R-tree index table structure

The fields and types of the R-tree index table are described in Table 1-2.

Table 1-2 R-tree index table structure description

Exemplarily, in the embodiment of the present invention, the vector data in the preset area are located in the same spatial domain, and the distribution is shown in FIG. 2 . The fan-out coefficient of the R tree is set to M=3, the boundary range of each node is represented by the minimum outer rectangle MBR, and the index items about the vector elements are stored in the leaf nodes. The corresponding R tree structure is shown in Figure 3. Based on the R-tree index table structure in Table 1-2, the R-tree in Figure 3 is expanded into a flat document collection, as shown in Table 1-3, so that the tree query operation can be completed by node ID navigation.

Table 1-3 Flattened storage of R-tree nodes

The JSON detailed structure is {ID,L,C,D}. Where ID(OID) is the unique identifier of the index node, L(Level) is the level of the node in the tree, C(Count) is the number of child nodes the node has, D(Descendants) is the JSON nested structure, record The unique identifier and minimum bounding box of the child nodes this node has.

The detailed structure of D(Descendants) is D:{{P,M},…,{P,M}}, where P(Pointer) points to the OID of its child node, M(MBR) is the smallest enclosing rectangle of the child node, Organized in GeoJSON.

102. Establish a library table structure including vector data and an index structure, and associate each data table in the library table structure with an explicit association record and an implicit naming rule.

Exemplarily, the storage, organization, and management of vector data in the non-relational database HBase in the embodiment of the present invention involve various library tables. Except for the R-tree index table designed above, the structure design and description of other library tables are as follows:

The vector metadata table is used to store vector metadata, interpret the detailed information of each vector data set in the database, and help the indexing system filter some meaningless requests. The vector metadata table is named "VO_METADATA", and its row key is the name of the dataset (DatasetName); the metadata table contains two column families, the necessary column family (E) and the optional column family (F). Other user-defined fields are placed under column family F. The structure of the metadata table is shown in Table 2-1.

Table 2-1 Vector metadata table structure

The fields and types of the vector metadata table are described in Table 2-2.

Table 2-2 Vector metadata table structure description

The index metadata stored in the index metadata table is the description information of the R-tree spatial index. This information is referenced by the vector metadata information, which associates the vector data table with the R-tree index table, and then determines the internal structure of the R-tree node and the starting node position of the algorithm by recording the R-tree parameters. The index metadata table is named "IDX_METADATA", and its row key is the name of the index table (IndexTableName). The detailed structure is shown in Table 3-1.

Table 3-1 Index metadata table structure

The fields and types of the index metadata table are described in Table 3-2.

Table 3-2 Index metadata table structure description

The original vector data information is stored in the vector data table. FIG. 4 shows the storage structure of a vector element in the vector data table in the embodiment of the present invention, and the geometric information of the vector data is organized in the form of GeoJSON. Specifically, the geometric information is stored in the "GEOINFO" field, where the "type" field identifies the geometry type of the element, and the "coordinate" field stores the vertex coordinate array of the geometric object. Non-geometric information for features is also stored in different fields, such as the "NAME" field that represents the name of the vector feature. The detailed structure of the vector data table is shown in Table 4-1.

Table 4-1 Vector data table structure

The fields and types of the vector data table are described in Table 4-2.

Table 4-2 Vector data table structure description

Specifically, according to the characteristics of HBase database, the vector database mode supported by R-tree index is designed, as shown in Figure 5. The association rules of vector data table, R-tree index table, vector metadata table and index metadata table are as follows:

The vector metadata table records the spatial domain name of the vector data table and its corresponding namespace. When a vector data set has more than one spatial domain, multiple records will be stored in the vector metadata set.

The R-tree index table corresponding to each spatial domain is bound to its corresponding vector data table through a specific naming convention. The naming method of the index table is "Rtree_spatial domain name_namespace", and the naming method of the data table is "spatial domain name" _Namespaces".

The index metadata information is associated with the vector metadata table by recording the ID, and the root node in the R-tree index table is also associated with the index metadata table by recording the ID.

103. Encode the vector data into the library for storage, organize the geometry and attribute information in the form of GeoJSON and JSON, and build a flattened R-tree index at the same time.

Exemplarily, a flowchart of vector data insertion and R-tree index construction proposed by the embodiment of the present invention is shown in FIG. 6 . First, take the vector dataset as a unit, encode all the vector elements in it, and write it into the vector data table. Then query whether the geometric metadata information of the spatial domain where the vector element is located in the vector metadata table exists, if not, store the geometric metadata information in the vector metadata table, and update the index metadata information at the same time.

Exemplarily, the index metadata ID is obtained, the R-tree index table and its root node ID are obtained from the index metadata table, and the optimal insertion node is found by navigation. Among them, it is necessary to judge whether the number of child nodes of the optimally inserted node exceeds the preset fan-out coefficient.

Specifically, starting from the root node, first judge whether the MBR of the current node contains the MBR of the vector element to be inserted, if not, continue to judge whether the next node contains the MBR until the MBR of the vector element to be inserted is contained, judge the child node of the node Whether the MBR contains the vector element MBR to be inserted. The optimal insertion node should satisfy that the MBR of the node itself contains the MBR of the vector element to be inserted and the MBR of its child node does not contain the MBR of the vector element to be inserted. After navigating to the destination leaf node, determine whether the number of child nodes of the current node exceeds the preset fan-out coefficient, if not, insert the index item about the vector element; otherwise, use the R-tree splitting strategy to split the node, and perform the id node navigation again , insert the index item of the vector element into the best node after splitting. If the root node is split, update the information of the root node in the index metadata table. Finally, update the R-tree index item and metadata table information to complete the data insertion operation.

After the data insertion operation is completed, the index information of the corresponding data is updated, in order to ensure the integrity of the content entry. In a non-relational database, errors are the norm. If an index entry is inserted first, the system crashes after the index entry is inserted. After restarting, the system will consider that the data has been stored in the database, resulting in data loss.

104. Provide query support for vector data: When a query request is received, the index metadata ID is determined according to the query conditions, and then the R-tree root node ID is obtained, so that the vector data retrieval is performed in parallel based on the R-tree index table, and finally returned search result.

Exemplarily, a vector data query flowchart proposed by an embodiment of the present invention is shown in FIG. 7 , including the following steps:

Step 1: The user specifies query conditions such as the name of the dataset and the query range, and the corresponding query range in the embodiment of the present invention is shown in the query box in FIG. 2, and the query polygon area is obtained;

Step 2: Query the geometric metadata information of the spatial domain in the vector metadata table. If the information does not exist, the query ends, and there are no vector elements that meet the query conditions in the dataset; if the information exists, obtain the ID of the corresponding index metadata;

Step 3: query the index metadata table to obtain the R-tree index table corresponding to the query polygon area and the ID of its root node;

Step 4: Query the R-tree index table, take out the key-value pair of the root node and deserialize it. Judging from the geometric information recorded in GeoJSON: the query box in Figure 2 intersects with the MBR of the child node N1, and is contained by the MBR of the child node N2. According to the pointer of the parent index item to the child index node, the key-value pairs corresponding to the N1 and N2 nodes are extracted from the index table in a multi-threaded parallel manner. , the MBR of N7 intersects. Recursively, the key-value pairs corresponding to N4, N6, and N7 are taken out in parallel and deserialized, and the geometric relationship is judged in parallel by using multi-threading. and the MBR of L18 intersects the query box. It can be seen from the judgment that the current leaf node has been queried, and the set of leaf nodes that meet the conditions can be obtained as: {L10, L12, L16, L18, L19};

Step 5: extracting vector data from the vector data table according to the index item, and filtering the obtained data by geometric information through precise query to obtain a vector data set that meets the query conditions. In addition, the filtering process can also be attribute information filtering, such as whether the building area of the building is greater than 2500m ² , whether the name string contains the name of a shopping mall, and so on.

105. Maintain vector data, including updating and deleting.

Specifically, the update of the data can be performed in real time through the pre-established R-tree index based on the flattening strategy, and the implementation manner of the update process is similar to the establishment process of the R-tree index. When the vector data stored in the database is modified, the index data of the nodes affected by the modified data is updated at the same time, which ensures the validity of the data.

Exemplarily, a vector data deletion flowchart proposed by an embodiment of the present invention is shown in FIG. 8 , and the deletion of the vector data corresponding to the index item of the leaf node L17 in the R tree includes the following steps:

Step 1: query the geometric metadata information of the spatial domain where the data to be deleted in the vector metadata table is located, and obtain the corresponding index metadata information;

Step 2: query the index metadata table, obtain the R-tree index table and its root node, and locate the index item associated with the vector element to be deleted according to the geometric relationship between the minimum outer rectangle of the R-tree node and the query box;

Step 3: Delete the corresponding vector data in the vector data table;

Step 4: delete the index entry associated with the vector data in the R-tree index table;

Step 5: Update the R-tree index table and index metadata table.

The invention provides a non-relational database vector data management method based on flattened R-tree, which is oriented to new non-relational databases, and provides vector data query supported by R-tree for distributed non-relational databases by establishing an R-tree index based on a flattening strategy. It can also use the distributed storage characteristics of non-relational databases to perform R-tree query operations executed in parallel on multiple nodes, thereby supporting large-scale vector data organization and management for non-relational databases, enabling mass storage and parallel computing of non-relational databases. , and technical dividends such as high availability and high reliability benefit vector data types.

The above embodiments are only used to illustrate the design ideas and features of the present invention, and the purpose is to enable those skilled in the art to understand the contents of the present invention and implement them accordingly, and the protection scope of the present invention is not limited to the above embodiments. Therefore, all equivalent changes or modifications made according to the principles and design ideas disclosed in the present invention fall within the protection scope of the present invention.

Claims (10)

1. A vector data management method in a non-relational database is characterized in that: the method comprises the following steps:

s1, in a non-relational database environment, designing an auxiliary index structure based on an R tree flattening strategy for vector data;

s2, establishing a base table structure including vector data and an index structure, wherein all data tables in the base table structure are associated through explicit association records and implicit naming rules;

s3, encoding and storing the vector data, organizing the geometric and attribute information in GeoJSON and JSON forms respectively, and constructing a flattened R tree index;

s4, when receiving the query request, determining index metadata ID according to the query condition, further obtaining R tree root node ID, thereby executing the retrieval of vector data in parallel based on the R tree index table, and finally returning the query result;

and S5, maintaining the vector data in the non-relational database, including updating and deleting.

2. The vector data management method according to claim 1, characterized in that: in S1, the specific design steps of the auxiliary index structure based on the R-tree flattening policy are as follows:

1.1, abstracting a vector object into a minimum outsourcing rectangle MBR, recursively combining MBRs adjacent to spatial positions into a higher-level MBR, and finally forming a layered tree structure based on the minimum outsourcing rectangle;

1.2, expanding the R tree index structure into a flattened index node set, namely expressing each index node into a JSON structure, and using the unique identifier of the node as a pointer of a parent index item to a child index node;

1.3, setting a fan-out coefficient M of the R tree, and except for a root node, setting the number of child nodes of other R tree nodes to be positioned between intervals [2, M ].

3. The vector data management method according to claim 2, characterized in that: in the R tree nodes, the record format of the R leaf node is < OID, MBR >, and the record format of the middle node is < OID, Pointer, MBR >; wherein the OID is the unique identifier of the node, the Pointer points to the OID of the child node, and the MBR is the minimum outsourcing rectangle.

4. The vector data management method according to claim 1, characterized in that: in S2, the library table structure is designed as follows:

2.1, managing multi-source heterogeneous vector data in a data set form, wherein each vector data set organizes logically related vector data with the same type;

2.2, designing a vector data table, an R tree index table, a vector metadata table and an index metadata table, wherein the vector data table, the R tree index table, the vector metadata table and the index metadata table are respectively used for storing vector elements, index structures and metadata of the vector elements and the index structures of the vector data set;

and 2.3, establishing an association relation among four types of tables, namely a vector data table, an R tree index table, a vector metadata table and an index metadata table, wherein each vector data set corresponds to one vector data table and one R tree index table, and metadata description is respectively carried out in the vector metadata table and the index metadata table.

5. The vector data management method according to claim 1, characterized in that: the S3 specifically includes:

3.1, coding all vector elements in the vector data set by taking the vector data set as a unit, writing the vector elements into a vector data table, and organizing the geometric and attribute information in GeoJSON and JSON forms respectively; GeoJSON is a geographic space information data exchange format based on a JavaScript object representation method;

3.2, inquiring the geometric metadata information of the space domain where the vector elements are located in the vector metadata table, and acquiring the corresponding index metadata ID;

3.3, acquiring an R tree index table and a root node ID thereof from the index metadata table, navigating to a target leaf node of the R tree index table according to the geometric relationship between the minimum vector element outsourcing rectangle and the index item outsourcing rectangle, inserting an index item related to the vector element, and updating the R tree index table;

and 3.4, after the writing of the vector data set is completed, updating the vector metadata table and the index metadata table.

6. The vector data management method according to claim 5, wherein: in the step 3.3, the specific modes of ID node navigation and R-tree index table update include the following steps:

3.3.1, according to the geometric relationship between the minimum outsourcing rectangle of the vector elements and the outsourcing rectangle of the index item, searching the optimal insertion node by using ID node navigation, judging whether the number of child nodes of the node exceeds the set fan-out coefficient, if so, executing a step 3.3.2, otherwise, executing a step 3.3.3;

3.3.2, performing node splitting operation, equally dividing the node into two new nodes through an R tree node splitting algorithm, and navigating again to find an optimal insertion node;

3.3.3, inserting the index item of the vector element into the node, and updating the node;

3.3.4, if the root node is split, updating the information of the root node in the index metadata table.

7. The vector data management method according to claim 5, wherein: the JSON has a structure of { ID, L, C, D }; wherein the ID is a unique identifier of the index node, namely OID; l is the number of layers of the node in the tree; c is the number of the child nodes owned by the node; d is a JSON nested structure, and records the unique identifier and the minimum bounding box of the child node owned by the node;

the detailed structure of D is D { { P, M }, …, { P, M } }, wherein P is the abbreviation of Pointer, pointing to the OID of its child node; m is an abbreviation of MBR, the minimum bounding rectangle of the child node, organized in the form of GeoJSON.

8. The vector data management method according to claim 1, characterized in that: the S4 specifically includes:

4.1, giving query conditions such as data set names, query ranges and the like by a user;

4.2, inquiring the geometric metadata information of the space domain in the vector metadata table according to a given inquiry condition to obtain the ID information of the corresponding index metadata;

4.3, acquiring the ID of the R tree index table and the root node thereof from the index metadata table;

4.4, inquiring the R tree index table, and taking out the index items of the vector elements meeting the inquiry conditions;

and 4.5, taking out the vector data from the vector data table, and carrying out fine filtering to finally obtain a query result.

9. The vector data management method according to claim 8, wherein: in 4.4, the specific way of querying the R tree index table includes the following steps:

4.4.1, acquiring a corresponding key value pair in the R tree index table through the ID information of the root node, taking out the key value pair and deserializing the key value pair;

4.4.2, judging the relation between the MBR of each child node and the query range according to the geometric information in the GeoJSON, finding out child nodes which are intersected with the query range or in the query range of the MBR, and taking out and deserializing corresponding child node key value pairs according to pointers of the parent index items pointing to the child index nodes;

4.4.3, repeating the step 4.4.2 until the leaf node of the R tree is inquired.

10. The vector data management method according to claim 1, characterized in that: in S5, the process of deleting the vector data includes:

5.1, inquiring the geometric metadata information of the space domain where the data to be deleted is located in the vector metadata table, and acquiring corresponding index metadata information;

5.2, acquiring an R tree index table and a root node thereof from the index metadata table, and positioning an index item associated with the vector element to be deleted according to the geometric relationship between the minimum outsourcing rectangle of the R tree node and the query box;

5.3, deleting the corresponding vector data in the vector data table;

and 5.4, deleting the index item associated with the vector data in the R tree index table.

Images