A method and device for storing and indexing ephemeris data based on a distributed database

Abstract

The present invention discloses a method and device for storing and indexing ephemeris data based on a distributed database, belonging to the technical field of ephemeris data management. The method significantly improves the query performance of massive spatiotemporal data through dual-table collaborative storage and dynamic index optimization mechanisms. The method comprises: constructing a dual-table collaborative storage structure of an ephemeris data table and an ephemeris index table; converting the ephemeris data into structured data after preprocessing, and arranging and storing the data in the dual-table collaborative storage structure in the order of satellite numbers and global positioning system weeks, thereby optimizing the continuity and distribution of the data; updating the ephemeris index table in real time based on a dynamic maintenance mechanism and triggering adaptive index reorganization based on data shard splitting events; adopting a two-level retrieval strategy, quickly locating the target data primary key range and data shards through a joint index, and processing queries in parallel to achieve cross-node precise retrieval, and finally feeding back the results to the client, thereby reducing query delays in massive ephemeris data and improving query efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of ephemeris data management, and in particular to an ephemeris data storage and indexing method and device based on a distributed database. Background Art

[0002] With the rapid development of the Global Navigation Satellite System (GNSS), multiple constellation systems, including the Global Positioning System and Beidou, continue to expand. As core spatiotemporal reference information, ephemeris data plays an irreplaceable role in positioning, navigation, and timing (PNT) services. High-precision ephemeris data is not only a critical input for real-time navigation systems, but is also widely used in geophysical monitoring, precision agriculture, intelligent transportation, aerospace, and other fields. Modern global navigation satellite systems feature multiple satellites, multiple frequency bands, and a high update rate. The dynamic, massive, and time-sensitive nature of the ephemeris data they generate poses significant challenges to traditional data management technologies. On the one hand, ephemeris data must support high-concurrency queries with millisecond-level response times to meet the demands of real-time applications. On the other hand, its spatiotemporal correlation requires storage systems to possess efficient multidimensional indexing capabilities. Therefore, achieving efficient storage, rapid retrieval, and dynamic expansion of ephemeris data has become a key issue in the development of satellite navigation data infrastructure.

[0003] To address the significant technical bottlenecks faced by traditional databases in ephemeris data management, open-source distributed databases can be used. These databases combine the advantages of traditional relational databases and non-relational databases (NoSQL), enabling horizontal scalability of large-scale data while ensuring transaction consistency. Through automatic sharding and efficient distributed query optimization, these databases address the challenges of high concurrency, low latency, and large data storage. They can also scale horizontally to store massive amounts of data and support both online transaction processing (OLTP) and online analytical processing (OLAP), effectively improving query efficiency. However, ephemeris data is frequently updated, and these updates typically require recalculation and updating of indexes, resulting in increased overhead. Furthermore, data is distributed across multiple nodes, increasing query latency when cross-node queries are involved. Reducing data indexing latency while meeting the requirements for large-scale, high-throughput data processing is a key issue for distributed databases. Summary of the Invention

[0004] The present invention aims to overcome the problem of long data indexing delay in large-scale high-throughput data processing in the prior art, and provides an ephemeris data storage and indexing method and device based on a distributed database.

[0005] To achieve the above object, the technical solution of the present invention is to provide an ephemeris data storage and indexing method based on a distributed database, comprising the following steps:

[0006] Step S1, constructing the ephemeris data table and the ephemeris index table into a dual-table collaborative storage structure;

[0007] Step S2, pre-processing the ephemeris data to convert it into structured data, and storing the structured data in the dual-table collaborative storage structure according to the order of satellite numbers and global positioning system weeks;

[0008] Step S3, updating the ephemeris index table in real time during the storage phase of the structured data based on a dynamic maintenance mechanism;

[0009] Step S4: obtaining the primary key range of the target data through the ephemeris index table, quickly locating the data shard where the target data is located based on the primary key range, and querying.

[0010] In one embodiment, in the above step S4, the specific steps include the following:

[0011] Step S41, parsing and extracting filtering conditions based on the query request including the satellite number and the global positioning system week;

[0012] Step S42: Initiate a query to the ephemeris index table based on the filtering condition, and establish a joint index of the satellite number and the global positioning system week in the ephemeris index table to match target index records that meet the conditions and obtain the start primary key and end primary key of the target data;

[0013] Step S43: Combine the start primary key and end primary key of the target data obtained by the query and the filter condition in the query request to generate a query condition, and locate the data shard number and storage node range of the target data according to the range of the start primary key and the end primary key of the target data to obtain an index range;

[0014] Step S44: query the index range in the ephemeris data table based on the query condition to obtain an output result.

[0015] In one embodiment, in the above step S44, when the target data spans multiple primary key ranges, the query task will be automatically split and the relevant data shards will be accessed in parallel.

[0016] In one embodiment, in the above step S4, the query adopts the index cost model, and the specific formula is as follows:

[0017] TC = ITC 1 + NC 1 + SC 1

[0018] + RLC + TSC + NC 2 + SC 2

[0019] + MC + RC

[0020] in, TC is the total index cost, ITC 1 、 NC 1 、 SC 1 is the query cost model in step S42; RLC 、 TSC 、 NC 2 and SC 2 is the query cost model in step S43; MC and RC This is the cost model in step S44; each cost factor is dynamically calibrated through the open source distributed relational database execution plan statistical information.

[0021] In one embodiment, the above step S2 specifically includes the following steps:

[0022] Step S21, parsing and standardizing the ephemeris data, performing hash grouping according to the satellite number and the GPS week, filtering redundant data and completing verification to generate structured data;

[0023] In step S22, the user or the data access layer submits a write request to the open source distributed relational database based on the structured data, specifies that the storage target of the structured data is the ephemeris data table, and completes operations including data sharding strategy selection and transaction consistency check;

[0024] Step S23, storing the structured data in the ephemeris data table, and triggering an update condition judgment mechanism for the ephemeris index table;

[0025] Step S24: dynamically determine whether to update the ephemeris index table or update the index record according to the GPS week and the satellite number.

[0026] In one embodiment, the above step S3 specifically includes the following steps:

[0027] Step S31, querying the ephemeris index table according to the satellite number and the global positioning system week of the structured data;

[0028] Step S32: if there is a matching index record, update the end primary key value of the index record;

[0029] Step S33: If there is no matching index record, a new index record is inserted.

[0030] In one embodiment, in the above step S1, the ephemeris data table includes the primary key of the ephemeris data, satellite number, global positioning system week, reference time and orbit parameter set; the ephemeris index table includes a joint primary key, a start primary key and an end primary key.

[0031] In one embodiment, in the above step S42, ITC 1 = iRC × sF , represents the cost of scanning the ephemeris index table to locate records that meet the query conditions, iRC Indicates the number of hit records in the ephemeris index table, sF Indicates the cost of a single row scan; NC 1 = iRC × nF , represents the network transmission cost of transmitting the index query result, i.e., the starting primary key or the ending primary key, from the distributed key-value storage component node to the open source distributed relational database server, nF represents the network transmission factor; SC 1 = iRC × selF , represents the cost of calculating the filter condition, selF represents the conditional calculation factor; in step S43, RLC = log 2 (N_Regions) × rF , which means that the open source distributed relational database determines the location cost of the data shard where the data is located based on the primary key range. rF Indicates the data sharding positioning factor; TSC = dRC × sF , represents the data scanning cost in the distributed key-value storage component node, where dRC Indicates the number of records returned by the data table; NC 2 = dRC × nF , represents the network transmission cost of transmitting the data table query results from the distributed key-value storage component node to the open source distributed relational database server; SC 2 = dRC × selF, represents the computational cost of executing the final filtering condition of the data table; in step S44, MC = dRC × mF , represents the cost of sorting the results returned by multiple data shards, where mF Represents the merge operation factor.

[0032] In one embodiment, the method optimizes the data shard location path based on the scheduler metadata cache of the distributed scheduling server.

[0033] The present invention also provides an ephemeris data storage and indexing device based on a distributed database, which executes the method described above. The device includes several servers, which are respectively used to build a distributed key-value storage component, a distributed scheduling server, and an open source distributed relational database server cluster node; data visualization tools and system monitoring and alarm toolkits are deployed on the servers of the distributed key-value storage component nodes and a 2-copy Raft protocol is used to ensure data consistency; the data shard splitting threshold is 96MB to 144MB, and the sub-data shard key range is continuous after the split.

[0034] In summary, the present invention discloses a distributed database-based ephemeris data storage and indexing method. This method is based on an open-source distributed relational database and utilizes a dual-table collaborative storage architecture, a dynamic maintenance mechanism for the ephemeris index table, and a two-level retrieval strategy to achieve efficient management of massive spatiotemporal data. By designing an ephemeris index table and combining it with the distributed data sharding storage mechanism of an open-source distributed relational database, the present invention achieves efficient retrieval of complex ephemeris data under multi-condition queries. By structured storage of ephemeris data and innovatively designing an ephemeris index table, the present invention utilizes the distributed horizontal expansion capabilities of the open-source distributed relational database to support the dynamic addition of storage nodes to cope with data volume growth, while maintaining stable query performance and ensuring long-term stable operation of the system.

[0035] In order to make the above features and advantages of the present invention more clearly understood, embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 Flow chart of the method in the present invention.

[0037] Figure 2 This is a flowchart of the ephemeris data storage in the present invention.

[0038] Figure 3 This is the ephemeris index update strategy diagram in the present invention.

[0039] Figure 4 This is a flow chart of the secondary retrieval strategy query for ephemeris data in the present invention.

[0040] Figure 5 This is a node topology diagram of the open source distributed relational database cluster in the present invention. DETAILED DESCRIPTION

[0041] To make the purpose and technical solutions of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the described embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0042] In order to achieve efficient storage and query optimization of ephemeris data in the open source distributed relational database (TiDB) and solve the problem of large indexing delay when ephemeris data grows massively, the present invention provides an ephemeris data storage and indexing method based on a distributed database. Figure 1 It is a flow chart of the method of the present invention, as shown in Figure 1 As shown, the steps include:

[0043] Step S1, constructing the ephemeris data table and the ephemeris index table into a dual-table collaborative storage structure;

[0044] Step S2, pre-processing the ephemeris data to convert it into structured data, and storing the structured data in the dual-table collaborative storage structure according to the order of satellite numbers and global positioning system (GPS) week numbers;

[0045] Step S3, updating the ephemeris index table in real time during the storage phase of the structured data based on a dynamic maintenance mechanism;

[0046] Step S4: obtaining the target data primary key range through the ephemeris index table, quickly locating the data slice (Region) where the target data is located based on the primary key range, querying, completing the indexing and outputting the result.

[0047] In step S1, the ephemeris data table is a structured database used to store broadcast ephemeris file data. The table corresponds to each field of the broadcast ephemeris data and includes the primary key, satellite number, GPS week, reference time, and orbit parameter set for the ephemeris data. The satellite number field is stored using a fixed-length string data type (CHAR format), and the GPS week field uses an integer data type (INT) to store the week count.

[0048] The ephemeris index table is used to support optimized indexing of the ephemeris data table, based on the storage indexing characteristics of an open-source distributed relational database and the structural characteristics of the ephemeris data. The ephemeris index table includes a composite primary key, a start primary key, and an end primary key. The start and end primary key fields are large integer type (BIGINT) and record the primary key range of the corresponding ephemeris data table.

[0049] In step S2, the dual-table collaborative storage model utilizes the gradual continuity of data on the storage medium and the storage characteristics of the data sharding unit in the open source distributed relational database. Specifically, the preprocessing method and storage steps of the ephemeris data are as follows: Figure 2 Shown, including:

[0050] Step S21, parsing and standardizing the ephemeris data in the original Receiver Independent Exchange (RINEX) format, extracting information such as satellite orbit parameters, time parameters, satellite number, and global positioning system week, and performing hash grouping based on the satellite number. Multiple sets of ephemeris data for the same satellite are sorted in ascending order based on the global positioning system week. After filtering redundant data and completing format verification and logic validation, structured data that conforms to database storage specifications is generated.

[0051] In step S22, the user or the data access layer submits a transactional write request to the open source distributed database based on the structured data, specifies that the storage target of the structured data is the ephemeris data table, and completes operations such as data sharding strategy selection and transaction consistency check to ensure the atomicity and traceability of the write operation;

[0052] Step S23, persistently storing the structured data in the ephemeris data table according to preset rules, and triggering the ephemeris index table update condition judgment mechanism;

[0053] Step S24: dynamically determine whether to update the ephemeris index table or update the index record based on the GPS week, the satellite number and other characteristics.

[0054] In step S21 , the Coordinated Universal Time (UTC) of the ephemeris data needs to be converted into a second-of-week format of the Global Positioning System.

[0055] In step S3, when the structured data is stored in the ephemeris data table, the update strategy of the ephemeris index table is as follows: Figure 3 As shown, the steps include:

[0056] Step S31, querying the ephemeris index table according to the satellite number and the global positioning system week of the structured data;

[0057] Step S32: if there is a matching index record, update the end primary key value of the index record;

[0058] Step S33: If there is no matching index record, a new index record is inserted.

[0059] First, check whether an index record with the same satellite number and global positioning system week as the current one already exists in the ephemeris index table. If a corresponding record already exists, it indicates that the inserted data belongs to an existing ephemeris data group. Then, only the end primary key value in the index record is updated to avoid the generation of redundant index records, and the updated value is the data primary key currently written into the ephemeris data table. If a corresponding record does not exist in the ephemeris index table, it indicates that the inserted data belongs to a new ephemeris data group. Then, a new index record is inserted, and the values ​​of the record field, global positioning system week, start primary key, and end primary key in the ephemeris index table are the values ​​of the satellite number, global positioning system week, start primary key, and end primary key in the current ephemeris data table, respectively.

[0060] In step S4, a secondary search strategy will be adopted, and its flow chart is as follows: Figure 4 As shown, the steps include:

[0061] Step S41, parsing and extracting filtering conditions such as the satellite number, the global positioning system week, etc. based on the query request including the satellite number, the time parameter, the global positioning system week, etc.;

[0062] Step S42: Initiate a query to the ephemeris index table based on the filtering condition, and establish a joint index of the satellite number and the global positioning system week in the ephemeris index table to quickly match target index records that meet the conditions and obtain the start primary key and the end primary key of the target data;

[0063] In step S43, the open source distributed relational database server generates precise query conditions based on the starting primary key and ending primary key of the target data obtained through the query and the filter conditions in the query request, and locates the data shard number and storage node range of the target data based on the range of the starting primary key and the ending primary key of the target data to obtain a narrowed index range, thereby avoiding a full database scan.

[0064] Step S44: query the ephemeris data table based on the query conditions. If the target data spans multiple primary key ranges, the query task will be automatically split and the relevant data shards will be accessed in parallel to fully utilize the performance advantages of the distributed architecture and reduce indexing latency. The query results will be sorted by time and output in the form of formatted data.

[0065] In addition, the index cost model is adopted in step S4, and the specific formula is as follows:

[0066] TC= ITC 1 + NC 1 + SC 1 (Ephemeris index table stage)

[0067] + RLC + TSC + NC 2 + SC 2 (Ephemeris data table stage)

[0068] + MC + RC (Results stage)

[0069] in, TC is the total index cost, ITC 1 、 NC 1 、 SC 1 is the query cost model in step S42; RLC 、 TSC 、 NC 2 and SC 2 is the query cost model in step S43; MC and RC This is the cost model in step S44. Each cost factor is dynamically calibrated using the open source distributed relational database execution plan statistics.

[0070] In step S42, ITC 1 Index scan cost, cost model ITC 1 This corresponds to a process of using a joint index of a satellite number and a global positioning system week to determine the data slice where the target data is located and filtering irrelevant data slices to quickly locate the target index record. ITC 1 It is positively correlated with the number of records hit in the index table. Specifically, ITC 1 = iRC × sF , represents the cost of scanning the ephemeris index table to locate the record that meets the query condition, iRC Indicates the number of hit records in the ephemeris index table, sF Represents the cost of a single row scan. Cost model NC 1 This corresponds to the process of transmitting query results from the distributed key-value storage component node to the open source distributed relational database server. Specifically, NC1 = iRC × nF , represents the network transmission cost of transmitting the index query result (starting primary key / ending primary key) from the distributed key-value storage component node to the open source distributed relational database server, where nF Represents the network transmission factor. Cost model SC 1 This corresponds to the process of verifying conditions such as time range boundaries. Specifically, SC 1 = iRC × selF , represents the cost of calculating the filter condition, selF In step S42, the scanning range can be compressed to avoid full table traversal.

[0071] In step S43, RLC For data sharding location overhead, determine the location cost of the data shard where the data is located based on the primary key range, cost model RLC The time taken to locate the target data shard based on the primary key range is logarithmically positively correlated with the number of data shards. RLC It can reduce the probability of cross-node queries. Specifically, RLC = log 2 (N_Regions) × rF , which means that the open source distributed relational database determines the location cost of the data shard where the data is located based on the primary key range. rF Indicates the data sharding location factor. Cost model TSC and SC 2 They correspond to the process of optimizing the scanning data and executing the time interpolation calculation through the log structure merge tree (LSM-Tree) in the target data shard. Specifically, TSC = dRC × sF , represents the data scanning cost in the distributed key-value storage component node, where dRC Indicates the number of records returned by the data table; NC 2 = dRC × nF , represents the network transmission cost of transmitting the data table query results from the distributed key-value storage component node to the open source distributed relational database server; cost model NC 2 This corresponds to the process of transferring the result set to the open source distributed relational database server. Specifically, SC 2 = dRC × selF, represents the computational cost of executing the final filter condition of the data table. Step S43 implements distributed acceleration by querying multiple data shards in parallel.

[0072] In step S44, MC Merge cost for the result, cost model MC Using the parallel merge algorithm of the open source distributed relational database, the results of multiple data shards are sorted in memory. The query results of the corresponding multiple data shards are fed back to the open source distributed relational database server, and the memory merge sorting process is performed according to the ephemeris reference time. The time consumption is linearly logarithmically related to the amount of data. Specifically, MC = dRC × mF , represents the cost of sorting the results returned by multiple data shards, where mF Represents the merge operation factor. Cost model RC Corresponding to the process of serializing the results into the format specified by the client; RC Indicates that the final result is returned to the client, which is related to the network bandwidth.

[0073] The index cost model effectively shows that the scanning range is compressed by the ephemeris index table to reduce ITC 1 and RLC , and use distributed parallel query to reduce costs MC , which can effectively improve index query performance.

[0074] Furthermore, in step S44, the data shard where the target data is located is located according to the range of the starting primary key and the ending primary key of the target data, and parallel queries are performed on multiple distributed key-value storage component nodes; in step S45, each data shard returns the query result to the open source distributed relational database server. After receiving the data streams from the multiple distributed key-value storage component nodes, the open source distributed relational database server stores them in the memory buffer, sorts them in ascending order according to the ephemeris reference time field, converts the final result into MySQL protocol format, and returns it to the client for receipt.

[0075] In addition, the data shard location path can be optimized based on the scheduler metadata cache of the distributed scheduling server.

[0076] Figure 5This is a node topology diagram of the open-source distributed relational database cluster of the present invention. The present invention also includes a distributed database-based ephemeris data storage and indexing device. This device can adopt the cluster architecture of the open-source distributed relational database (TiDB v7.5.1) and use seven servers to build the open-source distributed relational database cluster. Among them, three independent servers are used for distributed key-value storage component cluster nodes, each equipped with an Intel Xeon Platinum 8374C processor, 64GB of memory, and 20TB of solid-state drive (SSD) storage; two independent servers are used for distributed scheduling server cluster nodes, equipped with Intel Xeon Silver 4210R processors, 64GB of memory, and 1.2TB of solid-state drive storage; two independent servers are used for open source distributed relational database server cluster nodes, equipped with Intel Xeon Silver 4210R processors, 64GB of memory, and 1.2TB of solid-state drive storage; and the data visualization tool (Grafana) and the system monitoring and alarm toolkit (Prometheus) are deployed simultaneously on the servers of the distributed key-value storage component nodes to monitor the nodes for real-time monitoring of cluster status, namely, query rate per second (QPS), latency (the time interval from request issuance to response receipt), and resource utilization indicators. Furthermore, the distributed key-value storage component nodes use a two-replica consensus algorithm (Raft protocol) to ensure data consistency. In the open source distributed relational database, the granularity of each data shard ranges from 96MB to 144MB. When the data volume continues to grow and reaches a threshold, the distributed key-value storage component node automatically triggers a split operation based on the data distribution characteristics, dividing the original data shard into two sub-shards. However, the key ranges of the newly generated sub-shard and the original data shard remain globally ordered and non-overlapping, meaning that the key ranges of the split sub-shards are continuous. Furthermore, servers are connected via a Gigabit Ethernet network to ensure efficient data transmission within the cluster. Each server within the data center is interconnected via a high-speed local area network, ensuring low latency and high-bandwidth communication between nodes.

[0077] In summary, the present invention discloses a distributed database-based ephemeris data storage and indexing method and device. The present invention is based on an open source distributed relational database and utilizes a dual-table collaborative storage architecture, a dynamic maintenance mechanism for the ephemeris index table, and a two-level retrieval strategy to achieve efficient management of massive spatiotemporal data. By designing an ephemeris index table and combining it with the distributed data sharding storage mechanism of an open source distributed relational database, the present invention achieves efficient retrieval of complex ephemeris data under multi-condition queries. By structured storage of ephemeris data and innovatively designing an ephemeris index table, the present invention utilizes the distributed horizontal expansion capabilities of the open source distributed relational database to support the dynamic addition of storage nodes to cope with data volume growth, while maintaining stable query performance and ensuring long-term stable operation of the system.

[0078] Although the present invention has been disclosed above with reference to the embodiments, they are not intended to limit the present invention. Anyone with ordinary skill in the art may make slight changes and modifications without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be determined by the scope of the appended patent applications.

Claims

1. A method for storing and indexing ephemeris data based on a distributed database, characterized in that: The steps are as follows: Step S1, constructing the ephemeris data table and the ephemeris index table into a dual-table collaborative storage structure; Step S2, pre-processing the ephemeris data to convert it into structured data, and storing the structured data in the dual-table collaborative storage structure according to the order of satellite numbers and global positioning system weeks; Step S3, updating the ephemeris index table in real time during the storage phase of the structured data based on a dynamic maintenance mechanism; Step S4, obtaining the primary key range of the target data through the ephemeris index table, quickly locating the data shard where the target data is located based on the primary key range, and querying; when the target data spans multiple primary key ranges, the query task will be automatically split and the relevant data shards will be accessed in parallel; Among them, in the above step S2, the specific steps include the following: Step S21, parsing and standardizing the ephemeris data, performing hash grouping according to the satellite number and the GPS week, filtering redundant data and completing verification to generate structured data; In step S22, the user or the data access layer submits a write request to the open source distributed relational database based on the structured data, specifies that the storage target of the structured data is the ephemeris data table, and completes operations including data sharding strategy selection and transaction consistency check; Step S23, storing the structured data in the ephemeris data table, and triggering an update condition judgment mechanism for the ephemeris index table; Step S24, dynamically determining whether to update the ephemeris index table or update the index record according to the GPS week and the satellite number; In the above step S3, the specific steps include the following: Step S31, querying the ephemeris index table according to the satellite number and the global positioning system week of the structured data; Step S32: if there is a matching index record, update the end primary key value of the index record; Step S33: if there is no matching index record, insert a new index record; In the above step S4, the specific steps include the following: Step S41, parsing and extracting filtering conditions based on the query request including the satellite number and the global positioning system week; Step S42: Initiate a query to the ephemeris index table based on the filtering condition, and establish a joint index of the satellite number and the global positioning system week in the ephemeris index table to match target index records that meet the conditions and obtain the start primary key and end primary key of the target data; Step S43: Combine the start primary key and end primary key of the target data obtained by the query and the filter condition in the query request to generate a query condition, and locate the data shard number and storage node range of the target data according to the range of the start primary key and the end primary key of the target data to obtain an index range; Step S44: query the index range in the ephemeris data table based on the query condition to obtain an output result.

2. The method for storing and indexing ephemeris data based on a distributed database according to claim 1, wherein: The above step S4 adopts the index cost model, and the specific formula is as follows: TC = ITC1 + NC1 + SC1 + RLC + TSC + NC2 + SC2 + MC + RC Among them, TC is the total index cost, ITC1, NC1, and SC1 are the query cost models in step S42; RLC, TSC, NC2, and SC2 are the query cost models in step S43; MC and RC are the cost models in step S44; each cost factor is dynamically calibrated through the execution plan statistics of the open source distributed relational database.

3. The method for storing and indexing ephemeris data based on a distributed database according to claim 1, wherein: In the above step S1, the ephemeris data table includes the primary key of the ephemeris data, satellite number, global positioning system week, reference time and orbit parameter set; the ephemeris index table includes a joint primary key, a start primary key and an end primary key.

4. The method for storing and indexing ephemeris data based on a distributed database according to claim 1, wherein: In the above step S42, ITC1 = iRC × sF, which represents the cost of scanning the ephemeris index table to locate records that meet the query condition, iRC represents the number of hit records in the ephemeris index table, and sF represents the cost of a single row scan; NC1 = iRC × nF, which represents the network transmission cost of transmitting the index query result, i.e., the starting primary key or the ending primary key, from the distributed key-value storage component node to the open source distributed relational database server, and nF represents the network transmission factor; SC1 = iRC × selF, which represents the cost of calculating the filter condition, and selF represents the condition calculation factor; In step S43, RLC = log2(N_Regions)× rF, which represents the cost of locating the data shard where the data is located by the open source distributed relational database according to the primary key range, and rF represents the data shard location factor; TSC = dRC×sF, which represents the cost of scanning data at the distributed key-value storage component node, where dRC represents the number of records returned by the data table; NC2 = dRC×nF, which represents the network transmission cost of transmitting the data table query results from the distributed key-value storage component node to the open source distributed relational database server; SC2 = dRC×selF, which represents the computational cost of executing the final filtering condition of the data table; in step S44, MC = dRC×mF, which represents the cost of sorting the results returned by multiple data shards, where mF represents the merge operation factor.

5. The method for storing and indexing ephemeris data based on a distributed database according to claim 4, wherein: The method optimizes the data sharding location path based on the scheduler metadata cache of the distributed scheduling server.

6. An ephemeris data storage and indexing device based on a distributed database, characterized in that: The device executes the method according to any one of claims 1 to 5, and the device includes several servers, which are respectively used to build a distributed key-value storage component, a distributed scheduling server, and an open source distributed relational database server cluster node; data visualization tools and system monitoring and alarm toolkits are deployed on the servers of the distributed key-value storage component nodes and a 2-replica Raft protocol is used to ensure data consistency; the data shard splitting threshold is 96MB to 144MB, and the sub-data shard key range is continuous after the split.

Images