A method, apparatus and system for cluster data query

Abstract

This application discloses a cluster data query method, apparatus, and system. It receives a data query request from a client, generates cluster information based on the request, and obtains real-time data from multiple data producers corresponding to the cluster information. When the data readiness rate exceeds a preset proportion, the real-time data is sent to the client. The data readiness rate represents the proportion of real-time data corresponding to the obtained cluster information to the required data corresponding to the cluster information. Upon receiving a data query request from a client, cluster information is generated based on the request, and real-time data from the corresponding data producers is obtained based on the cluster information. The real-time data of the cluster is only sent to the client when the data readiness rate exceeds a preset proportion. This method performs data querying in steps, decouples the data, and automatically manages cluster relationships, reducing the number and frequency of interactions between the client and the data producers, thereby improving the real-time performance and efficiency of client data queries.

Description

Technical Field

[0001] This application relates to the field of cluster data query technology, specifically to a cluster data query method, apparatus and system. Background Technology

[0002] The producer-consumer pattern is a data transmission model unique to ControlNet networks. In this pattern, messages on an IoT platform are processed using a multi-first-in, first-out (MLI) queue. In real-time message consumption, the time difference between the earliest and latest messages (the real-time threshold) is an adjustable threshold. Clearly, a larger time difference theoretically results in a richer pool of real-time messages, but also lowers the time efficiency of consumption and distribution.

[0003] Unmanned surface vehicles (USVs) can achieve both manual control and autonomous navigation through an onboard intelligent control system combined with a remote wireless control system. USVs can also be viewed as intelligent robots performing tasks on the water's surface. They can be equipped with corresponding functional modules to create robots with specific functions, allowing them to perform various tasks on our behalf.

[0004] In intelligent vessel big data platforms, real-time monitoring and decision-making require not only clear and accurate historical trajectories for command and control, but also rapid real-time data feedback to further improve the precision of command and control. Therefore, intelligent vessel big data platforms are characterized by multiple clusters, large cluster size, dense messages, large message data volume, and high real-time requirements. This necessitates real-time messaging based on message middleware to support the application. Consequently, the real-time threshold cannot be set too low. However, a large real-time threshold leads to a sharp increase in the amount of real-time message data, causing a significant deterioration in system pressure. Furthermore, the limited bandwidth of open water wireless communication, numerous interference factors, and high data packet loss rates further exacerbate this situation. Summary of the Invention

[0005] To address the aforementioned technical problems, this application is proposed. Embodiments of this application provide a cluster data query method, apparatus, and system, which solve the above-mentioned technical problems.

[0006] According to one aspect of this application, a cluster data query method is provided, applied to a cluster system including multiple data production terminals; the cluster data query method includes: receiving a data query request from a client; generating cluster information based on the data query request; wherein the cluster information corresponds to multiple data production terminals; acquiring real-time data from the multiple data production terminals corresponding to the cluster information; and sending the real-time data to the client when the data readiness rate is greater than a preset ratio; wherein the data readiness rate represents the proportion of the real-time data corresponding to the acquired cluster information to the required data corresponding to the cluster information.

[0007] In one embodiment, generating cluster information based on the data query request includes: generating at least one cluster sequence number based on the data query request; wherein the cluster sequence number corresponds to multiple data production terminals; constructing a topic data table, a cluster correspondence table, and a cluster location table; wherein the topic data table includes the client address corresponding to the data query request, a character identifier corresponding to the data query request, and the topic of the data query request, wherein the character identifier represents a unique identifier corresponding to the cluster sequence number; the cluster correspondence table includes the character identifier, the cluster sequence number, and the data acquisition status; the cluster location table includes the cluster sequence number and the location information of multiple data production terminals.

[0008] In one embodiment, obtaining the real-time data of multiple data production terminals corresponding to the cluster information includes: comparing the topic and character identifier of the real-time data corresponding to the cluster sequence number with the topic and character identifier of the topic data table to obtain the real-time data corresponding to the cluster information.

[0009] In one embodiment, after generating cluster information according to the data query request, the cluster data query method further includes: sending the cluster information to the client; receiving a status query request from the client; wherein the status query request includes the cluster information; querying the status information of the real-time data corresponding to the cluster information based on the cluster information; and sending the status information to the client.

[0010] In one embodiment, the step of querying the status information of the real-time data corresponding to the cluster information based on the cluster information includes: querying the data acquisition status of the corresponding real-time data based on the cluster sequence number.

[0011] In one embodiment, sending the real-time data to the client when the data readiness rate is greater than a preset ratio includes: receiving a data acquisition request from the client when the data readiness rate is greater than the preset ratio; and sending the real-time data to the client according to the data acquisition request.

[0012] In one embodiment, before receiving the data acquisition request from the client, the cluster data query method further includes: calculating the ratio of real-time data corresponding to the cluster information to demand data corresponding to the cluster information, so as to obtain the data readiness rate.

[0013] According to another aspect of this application, a cluster data query device is provided, applied to a cluster system, the cluster system including multiple data production terminals, the cluster data query device being communicatively connected to the multiple data production terminals in the cluster system; the cluster data query device includes: a data request module for receiving data query requests from clients; a status management module for generating cluster information based on the data query requests; wherein the cluster information corresponds to the multiple data production terminals; a data transceiver module for acquiring real-time data from the multiple data production terminals corresponding to the cluster information; and a data feedback module for sending the real-time data to the client when the data readiness rate is greater than a preset ratio; wherein the data readiness rate represents the proportion of the real-time data corresponding to the acquired cluster information to the required data corresponding to the cluster information.

[0014] In one embodiment, the cluster data query device further includes a status query module, used to receive the status query request from the client and send the status information of the real-time data corresponding to the cluster information to the client.

[0015] According to another aspect of this application, a cluster data query system is provided, comprising: multiple data production terminals; a client; and a cluster data query device as described above, wherein the cluster data query device is communicatively connected to the multiple data production terminals and the client.

[0016] This application provides a cluster data query method, apparatus, and system. The system receives a data query request from a client, generates cluster information based on the request, and obtains real-time data from multiple data producers corresponding to the cluster information. When the data readiness rate exceeds a preset proportion, the real-time data is sent to the client. The data readiness rate represents the proportion of real-time data corresponding to the obtained cluster information to the required data corresponding to the cluster information. Upon receiving a data query request from a client, cluster information is generated based on the request, and real-time data from the corresponding data producers is obtained based on the cluster information. The real-time data is only sent to the client when the data readiness rate exceeds a preset proportion. This step-by-step data query reduces the number and frequency of interactions between the client and the data producers, thereby improving the real-time performance and efficiency of client data queries. Attached Figure Description

[0017] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0018] Figure 1 This is the system diagram to which this application applies.

[0019] Figure 2 This is a flowchart illustrating a cluster data query method provided in an exemplary embodiment of this application.

[0020] Figure 3 This is a flowchart illustrating a cluster data query method provided in another exemplary embodiment of this application.

[0021] Figure 4 This is a flowchart illustrating a cluster data query method provided in another exemplary embodiment of this application.

[0022] Figure 5 This is a flowchart illustrating a cluster data query method provided in another exemplary embodiment of this application.

[0023] Figure 6 This is a schematic diagram of the structure of a cluster data query device provided in an exemplary embodiment of this application.

[0024] Figure 7 This is a schematic diagram of the structure of a cluster data query device provided in another exemplary embodiment of this application.

[0025] Figure 8 This is a schematic diagram of the structure of a cluster data query system provided in an exemplary embodiment of this application.

[0026] Figure 9 This is a structural diagram of an electronic device provided in an exemplary embodiment of this application. Detailed Implementation

[0027] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0028] Figure 1 This is the system diagram to which this application applies. For example... Figure 1 As shown, for an IoT platform with a producer-consumer model, producers typically generate real-time messages and store them in a message middleware for consumers to access (consume). Producers can be intelligent devices such as unmanned surface vessels (USVs), and consumers can be clients such as web pages. The IoT platform also includes a data warehouse to store historical messages generated by producers. Numerous producers produce messages, each message being a triple (MSG(aid, topic, info)), where aid is the producer identifier, topic is the message subject, and info is the message content. Numerous consumers consume messages, with each consumption request being a QUERY(bid, topic) tuple, where bid is the consumer identifier and topic is the requested message subject. The message middleware matches and filters messages according to topic and supports permission management between aid and bid to achieve controlled and efficient message distribution. In application, the IoT platform also needs to design dedicated consumers (data warehouses) to store historical messages. To maintain the efficiency of the message middleware, message expiration handling is also required, with the middleware's support, to promptly delete expired messages and ensure the data conciseness of real-time messages to maintain distribution efficiency.

[0029] In unmanned surface vessels (USVs), the application scenarios are characterized by multiple clusters, large cluster size, dense messages, large message data volume, and high real-time requirements. This presents significant challenges to system implementation. Considering that data warehouses are geared towards big data applications and are insufficient to support real-time requirements, real-time messaging based on message middleware is needed to support the application. This means that the real-time threshold cannot be set too low (e.g., more than 10 minutes). However, a large real-time threshold leads to a sharp increase in the amount of real-time message data (e.g., exceeding 1 million messages), which will drastically worsen the system pressure. This worsening situation is further exacerbated by the limited bandwidth of open water wireless communication, numerous interference factors, and high data packet loss rate. For real-time monitoring and decision-making applications, there are five important reasons for the low efficiency of data querying:

[0030] (1) Mechanical repetition problem: Tracking tasks at fixed time periods involves a large number of mechanically repetitive data acquisition instructions, requiring all intelligent vessels to report attitude and task data in real time.

[0031] (2) Refresh matching problem: The readiness of cluster data is the gradual readiness of data for each ship. If the web page refresh interval is too fast, the server will be under heavy load and the data may not be ready. If the web page refresh interval is too slow, the application will have poor real-time performance and there will be situations where the data exists but the page cannot be tracked.

[0032] (3) Cluster traversal problem: A real-time monitoring and decision-making command often involves a large number of intelligent boat clusters. In the process of mechanical repetition, the intelligent boats are traversed in a loop, and the number of interactions between the client and the server increases quadratically.

[0033] (4) Redundancy of role view: Real-time monitoring and decision-making will present different role views for different user roles. The views are different clients, and the cluster objects they want to view may be the same or different, which are very varied. However, their data queries have a large degree of similarity, resulting in a large number of repetitive query calculations.

[0034] (5) Data requirements: The majority of data requirements for real-time monitoring and decision-making are for the coordinates (x, y) of each unmanned vessel. In the message, the coordinates are often combined with the topic information of multiple topics. They have different update frequencies. Combining them together will inevitably lead to redundancy of slow-frequency data. Querying them together will generate a large amount of redundant data. Querying them separately will result in two different queries, which will increase the burden on the interface.

[0035] To address the aforementioned issues, this application proposes a method and apparatus for cluster data querying. By breaking down the data query into multiple steps, after receiving a data query request from a client, cluster information is generated based on the data query request, and corresponding real-time data is obtained. Once the obtained data is ready, it is sent to the client, thereby reducing the amount of data the client traverses and improving the real-time performance and efficiency of the client's data query.

[0036] The specific implementation of the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0037] Figure 2 This is a flowchart illustrating a cluster data query method provided in an exemplary embodiment of this application. The cluster data query method is applied to a cluster system, which includes multiple data production endpoints; such as... Figure 2 As shown, the cluster data query method includes the following steps:

[0038] Step 210: Receive data query requests from clients.

[0039] When a client (e.g., a web page) queries data from a data producer (e.g., an unmanned surface vessel), it first sends a data query request (DATA_REQ) to the server and transmits the REQ(usvids, topic) tuple information, where REQ_usvids is the serial number combination of the unmanned surface vessel, and REQ_topic is the topic of the data that the client wants to query.

[0040] Step 220: Generate cluster information based on the data query request.

[0041] The cluster information corresponds to multiple data production terminals. The server generates a CID value based on the usvids information in the data query request. This CID value is a unique value corresponding to usvids, which integrates the data from a single terminal query request into cluster data.

[0042] In one embodiment, step 220 may be implemented as follows: generating at least one cluster sequence number based on the data query request, and constructing a topic data table, a cluster correspondence table, and a cluster location table; wherein, the cluster sequence number corresponds to multiple data production ends, the topic data table includes the client address corresponding to the data query request, the character identifier corresponding to the data query request, and the topic of the data query request, the character identifier represents a unique identifier corresponding to the cluster sequence number, the cluster correspondence table includes the character identifier, the cluster sequence number, and the data acquisition status, and the cluster location table includes the cluster sequence number and the location information of multiple data production ends.

[0043] Specifically, the server splits usvids into at least one independent usvid sequence, thus obtaining the corresponding cluster sequence number, and establishes three data structures for each usvid sequence: the CCT(ip, CID, topic) table, the CUL(CID, usvid, data_ready) table, and the UDS(usvid, x, y) table; where CCT_ip is the client address, CCT_CID is the unique character identifier corresponding to usvid, CCT_topic is the topic of the data query request, CUL_CID is the unique character identifier corresponding to usvid, CUL_usvid is the cluster sequence number, CUL_data_ready is the data acquisition status (specifically, CUL_data_ready = 0 indicates that the data has not been acquired, and CUL_data_ready = 1 indicates that the data has been acquired), UDS_usvid is the cluster sequence number, and UDS_x and UDS_y are the location information of the unmanned surface vessel. CCT records the query topics of different clients and different clusters (a client's cluster is only allowed to query one topic at a time, and can be changed at any time), ensuring that multiple clients can share the cluster (depending on the same combination of usvid). CUL records the many-to-many relationship between different CID values ​​and usvid. UDS records the position of a single usvid.

[0044] Step 230: Obtain real-time data from multiple data production terminals corresponding to the cluster information.

[0045] After receiving the data message MSG reported by the unmanned surface vessel, the server queries the CCT table based on information such as usvid and topic in the MSG, modifies the CUL_data_ready field in the corresponding CUL, and inserts the data message into the real-time message middleware for clients to obtain and consume.

[0046] Step 240: When the data readiness rate is greater than the preset ratio, send the real-time data to the client.

[0047] The data readiness rate represents the proportion of real-time data corresponding to the acquired cluster information to the required data corresponding to the cluster information. Specifically, when the data readiness rate of the data needed by the client is greater than a preset proportion (e.g., 90%), the server can start sending real-time data to the client. Preferably, data is sent to the client when the time after the client initiates a data query request is sufficiently long (e.g., greater than a preset time threshold) and the data readiness rate is greater than the preset proportion, in order to improve the effectiveness of data acquisition.

[0048] This application provides a cluster data query method that receives a data query request from a client, generates cluster information based on the request, obtains real-time data from multiple data producers corresponding to the cluster information, and sends the real-time data to the client only when the data readiness rate is greater than a preset ratio. The data readiness rate represents the proportion of real-time data corresponding to the obtained cluster information to the required data corresponding to the cluster information. Upon receiving a data query request from a client, cluster information is generated based on the request, and real-time data from the corresponding data producers is obtained based on the cluster information. The real-time data is only sent to the client when the data readiness rate is greater than a preset ratio. This method performs data querying in steps, reducing the number and frequency of interactions between the client and the data producers, thereby improving the real-time performance and efficiency of client data querying.

[0049] Figure 3 This is a flowchart illustrating a cluster data query method provided in another exemplary embodiment of this application. For example... Figure 3 As shown, step 230 above may include:

[0050] Step 231: Compare the topic and character identifier of the real-time data corresponding to the cluster sequence number with the topic and character identifier of the topic data table to obtain the real-time data corresponding to the cluster information.

[0051] After the server receives the data message from the unmanned surface vessel, it solves the problem of combining and reusing the unmanned surface vessel's usvid with multiple cluster CIDs through the CCT(ip, CID, topic) table, CUL(CID, usvid, data_ready) table, and UDS(usvid, x, y) table. Different usvid sequences, query topics, data readiness cycles and readiness rates can be used in parallel without conflict.

[0052] Figure 4 This is a flowchart illustrating a cluster data query method provided in another exemplary embodiment of this application. For example... Figure 4 As shown, after step 220, the above cluster data query method may further include:

[0053] Step 250: Send cluster information to the client.

[0054] After the server generates a CID value based on the usvids information in the data query request, it returns the CID value to the client, thus ending the data request process. This allows the data request process to end quickly, avoiding prolonged occupation of communication resources.

[0055] Step 260: Receive the client's status query request.

[0056] The status query request includes cluster information. The web page sends a status query request (DATA_STA) carrying the CID value to the server. The server obtains the location information (x and y from UDS) and data_ready (ready status, from CUL) of all usvid records corresponding to the CID value, DATA_STA, and queries the data status.

[0057] Step 270: Query the status information of the real-time data corresponding to the cluster information based on the cluster information.

[0058] In one embodiment, step 270 can be implemented by querying the data acquisition status of the corresponding real-time data based on the cluster sequence number. After querying the data acquisition status, the server serializes it into a string "status" in a predetermined order and returns it to the web page. The string "status" represents the coordinates of all usvids in the current cluster, and whether new coordinate data or topic data has arrived and is ready since the last request for DATA_REQ.

[0059] Step 280: Send the status information to the client.

[0060] The web page obtains the status string of DATA_STA, which solves the location problem and also shows the readiness progress of the entire cluster's topic data. The web page receives status query requests from clients, and the requests end quickly, thus avoiding prolonged occupation of communication resources.

[0061] Figure 5 This is a flowchart illustrating a cluster data query method provided in another exemplary embodiment of this application. For example... Figure 5 As shown, step 240 above may include:

[0062] Step 241: When the data readiness rate is greater than the preset ratio, receive the client's data acquisition request.

[0063] Step 242: Send real-time data to the client according to the data acquisition request.

[0064] The web page sends a DATA_REQ request to the server and transmits CID information. The server queries a list of all usvids with a CUL.data_ready value of 1 under the CID, retrieves the topic of that CID under that IP from the CCT, and combines a valid usvid sequence with the topic to request messages from the message middleware as a consumer. This improves the validity of DATA_GET and reduces message filtering for invalid usvids. When the data readiness rate reaches the client's expectation, the client retrieves cluster data. For example, when the data readiness rate is greater than a preset proportion, the server receives the client's data retrieval request and responds to the request to send data to the client.

[0065] In one embodiment, such as Figure 5 As shown, prior to step 241, the above cluster data query method may further include:

[0066] Step 290: Calculate the ratio of real-time data corresponding to cluster information to required data corresponding to cluster information to obtain the data readiness rate.

[0067] The data readiness rate is calculated by determining the proportion of data with a data_ready value of 1 among the data required by the client. Based on this data readiness rate, the accuracy of the required data can be determined, thereby reducing the need for invalid message filtering in the message middleware.

[0068] Figure 6 This is a schematic diagram of the structure of a cluster data query device provided in an exemplary embodiment of this application. The cluster data query device is applied to a cluster system, which includes multiple data production terminals. The cluster data query device is communicatively connected to these multiple data production terminals within the cluster system; for example... Figure 6 As shown, the cluster data query device 60 includes: a data request module 61 for receiving data query requests from clients; a status management module 62 for generating cluster information based on the data query requests; wherein the cluster information corresponds to multiple data production ends; a data transceiver module 63 for acquiring real-time data from the multiple data production ends corresponding to the cluster information; and a data feedback module 64 for sending real-time data to the client when the data readiness rate is greater than a preset ratio; wherein the data readiness rate represents the proportion of real-time data corresponding to the acquired cluster information to the required data corresponding to the cluster information.

[0069] This application provides a cluster data query device that receives data query requests from clients via a data request module 61, generates cluster information based on the data query requests via a status management module 62, and acquires real-time data from multiple data production terminals corresponding to the cluster information via a data transceiver module 63. When the data readiness rate is greater than a preset ratio, a data feedback module 64 sends the real-time data to the client. The data readiness rate represents the proportion of real-time data corresponding to the acquired cluster information to the required data corresponding to the cluster information. Upon receiving a data query request from a client, cluster information is generated based on the request, and real-time data from the corresponding data production terminals is acquired based on the cluster information. Real-time data is only sent to the client when the data readiness rate is greater than a preset ratio. This step-by-step data query reduces the number and frequency of interactions between the client and the data production terminals, thereby improving the real-time performance and efficiency of client data queries.

[0070] In one embodiment, the status management module 62 can be further configured to: generate at least one cluster sequence number according to the data query request, and construct a topic data table, a cluster correspondence table, and a cluster location table; wherein, the cluster sequence number corresponds to multiple data production terminals, the topic data table includes the client address corresponding to the data query request, the character identifier corresponding to the data query request, and the topic of the data query request, the character identifier represents a unique identifier corresponding to the cluster sequence number, the cluster correspondence table includes the character identifier, the cluster sequence number, and the data acquisition status, and the cluster location table includes the cluster sequence number and the location information of multiple data production terminals.

[0071] In one embodiment, the data transceiver module 63 can be further configured to: compare the topic and character identifier of the real-time data corresponding to the cluster sequence number with the topic and character identifier of the topic data table to obtain the real-time data corresponding to the cluster information.

[0072] Figure 7 This is a schematic diagram of the structure of a cluster data query apparatus provided in another exemplary embodiment of this application. For example... Figure 7 As shown, the cluster data query device 60 may further include: a status query module 65, used to receive status query requests from clients and send the status information of real-time data corresponding to the cluster information to the clients.

[0073] In one embodiment, the data request module 61 can be further configured to send cluster information to the client; the status query module 65 can be further configured to receive the status query request from the client; the status management module 62 can be further configured to query the status information of the real-time data corresponding to the cluster information based on the cluster information; and the status query module 65 can be further configured to send the status information to the client.

[0074] In one embodiment, the status management module 62 can be further configured to query the data acquisition status of the corresponding real-time data based on the cluster sequence number.

[0075] In one embodiment, the data feedback module 64 can be further configured to: receive a data acquisition request from the client when the data readiness rate is greater than a preset ratio, and send real-time data to the client according to the data acquisition request.

[0076] In one embodiment, the state management module 62 can be further configured to: calculate the ratio of real-time data corresponding to cluster information to demand data corresponding to cluster information, so as to obtain the data readiness rate.

[0077] Figure 8 This is a schematic diagram of the structure of a cluster data query system provided in an exemplary embodiment of this application. For example... Figure 8As shown, the cluster data query system includes: multiple data production terminals (USV), a web client, and the cluster data query device described above. The cluster data query device communicates with the multiple data production terminals (USV) and the web client. Specifically, the cluster data query device may include: a Netty-based message server S1 (corresponding to data sending and receiving module 63), a socket-based microservice S2 (corresponding to state management module 62), S3 (corresponding to data request module 61), S4 (corresponding to state query module 65), and S5 (corresponding to data feedback module 64). S1 provides long-lived connections and binary message communication to the USV, while S3, S4, and S5 provide HTTP text protocol interface services to the web page. The web page data request interface is divided into three types: data request (DATA_REQ), state query (DATA_STA), and data retrieval (DATA_GET). S2 (cluster and state manager) has a built-in cluster registry, supporting automatic cluster registration based on USV serial number (usvid) combinations on the web page, and sharing it among different clients. Users retrieve data using any combination of usvid, and each time they obtain a unique corresponding cluster number (CID). Subsequent commands can be based on the CID. The query object list for different clients and roles is a combination of USV serial numbers (usvid). If the serial number combination is the same, the CID is the same; otherwise, the CID is different. At the same time, the usvid corresponding to different clusters is ultimately unique. Thus, cluster data is a reuse and combination of data corresponding to usvid. S2 (Cluster and State Manager) is responsible for splitting and combining CID to usvid. This application divides data query into three steps: DATA_REQ, DATA_STA, and DATA_GET. After splitting, the time consumption of a single query interface is greatly shortened, and each interface completes quickly and efficiently, which is beneficial to server performance stability and concurrency. In particular, DATA_REQ and DATA_STA have almost instantaneous responses, while the resource consumption of the DATA_GET command is difficult to reduce. However, with the help of the DATA_STA interface, it can be called only after the state is ready, which is very efficient. The DATA_STA interface simply queries the status of the corresponding devices for each usvid. The process is short and the resource consumption is extremely low, resulting in a very fast response. In addition, considering real-time monitoring and decision-making applications, which are highly concerned about the location information of intelligent vessels, this application records the coordinates (x, y) of the unmanned vessel as a status parameter in S2 to provide a fast refresh channel for the location, which is more sensitive and reduces the dependence on the DATA_GET interface.S1, S2, S3, S4, and S5 together form a non-blocking, asynchronous, collaborative service group, providing a quick and efficient interface processing mode for the web client's data retrieval loop. Furthermore, it reduces the coupling of the complete loop traversal process, and simplifies the data processing of DATA_REQ, DATA_STA, and DATA_GET, thereby ensuring higher efficiency.

[0078] The specific process of querying data using the cluster data query system provided in this application is as follows:

[0079] (1) Data request: The web page sends a DATA_REQ request to S3, transmitting the REQ(usvids, topic) tuple information. After receiving the request, S3 transmits the REQ to S2. S2 uses usvids to generate a CID value and returns it to S3. S3 returns the CID value to the web page, and the DATA_REQ request ends quickly.

[0080] (2) Cluster registration and management: After S2 receives the REQ(usvids, topic) triple and returns the CID value to S3, it splits usvids into independent usvid sequences and creates three data structures for each usvid: CCT(ip, CID, topic) table, CUL(CID, usvid, data_ready) table, and UDS(usvid, x, y) table.

[0081] (3) Data Readiness Status Management: When the S1 receiver receives a data message MSG reported by a certain usvid, it reports the status DRS(usvid, x, y, topic) table to S2. All the information in this table comes from MSG. After receiving the DRS, S2 modifies the data_ready field of the CUL record (sets it to 1 if the match is successful) according to the matching result of usvid, CCT.topic and DRS.topic, and updates DRS.x and DRS.y to UDS.x and UDS.y. At the same time, S1 inserts the data message MSG into the message middleware.

[0082] (4) Data status acquisition: The web page sends a DATA_STA request carrying the CID to S4. S4 requests the status from S2. S2 obtains the x (from UDS), y (from UDS), and data_ready (from CUL) of all usvid records corresponding to the CID, serializes them into the string status in a predetermined order and returns them to S4. S4 returns the status to the web page, and the DATA_STA request ends quickly.

[0083] Obtaining the status string of DATA_STA from the web page can solve the location problem and also provide information on the readiness progress of the entire cluster's topic data. When sufficient time has passed and the data readiness rate is high (e.g., >90%), a DATA_GET request is sent to S5. Conversely, if insufficient time has passed and the readiness rate is low (e.g., <90%), a DATA_STA request is sent to S4 to improve the effectiveness of DATA_GET.

[0084] (5) Data Acquisition: The web page sends a DATA_REQ request to S5 and transmits CID information. S5 requests a list of CIDs from S2; S2 queries a list of all usvids with a CUL.data_ready value of 1 under the CID, retrieves the topic of the CID under the IP from CCT, and returns it to S5; S5 combines the valid usvid sequence and topic, and requests messages from the message middleware as a consumer to improve the validity of DATA_GET and reduce message filtering of invalid usvids.

[0085] (6) Continue fetching: After the web page sends a DATA_GET request and obtains the data, it can send the next DATA_REQ request and enter the next data request loop. At this time, if the usvid combination has not changed, REQ(CID, topic) is sent without cluster registration processing, but all CUL.data_ready related to the current CID are set to 0 to give full play to the efficiency advantage of cluster registration.

[0086] This application provides a cluster data query system that receives data query requests from clients, generates cluster information based on the requests, and obtains real-time data from multiple data producers corresponding to the cluster information. When the data readiness rate exceeds a preset proportion, the real-time data is sent to the client. The data readiness rate represents the proportion of real-time data corresponding to the obtained cluster information to the required data corresponding to the cluster information. Upon receiving a client's data query request, the system generates cluster information based on the request and obtains real-time data from the corresponding data producers. The real-time data is only sent to the client when the data readiness rate exceeds a preset proportion. This step-by-step data query process reduces the number and frequency of interactions between the client and the data producers, thereby improving the real-time performance and efficiency of client data queries.

[0087] Below, for reference Figure 9 This application describes an electronic device according to embodiments thereof. The electronic device may be either or both of a first device and a second device, or a standalone device independent of them, which may communicate with the first device and the second device to receive acquired input signals from them.

[0088] Figure 9 A block diagram of an electronic device according to an embodiment of this application is illustrated.

[0089] like Figure 9 As shown, the electronic device 10 includes one or more processors 11 and memory 12.

[0090] The processor 11 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 10 to perform desired functions.

[0091] The memory 12 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 11 may execute the program instructions to implement the methods of the various embodiments of this application described above and / or other desired functions. Various contents such as input signals, signal components, and noise components may also be stored in the computer-readable storage medium.

[0092] In one example, the electronic device 10 may also include an input device 13 and an output device 14, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0093] When the electronic device is a standalone device, the input device 13 can be a communication network connector for receiving the collected input signals from the first device and the second device.

[0094] In addition, the input device 13 may also include, for example, a keyboard, a mouse, etc.

[0095] The output device 14 can output various information to the outside, including determined distance information, direction information, etc. The output device 14 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0096] Of course, for the sake of simplicity, Figure 9 Only some of the components of the electronic device 10 relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device 10 may include any other suitable components depending on the specific application.

[0097] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0098] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0099] The above description has been given for illustrative and descriptive purposes. Furthermore, this description is not intended to limit the embodiments of this application to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A cluster data query method, characterized in that, Applied to a cluster system, the cluster system includes multiple data production terminals; the cluster data query method includes: Receive data query requests from clients; Cluster information is generated based on the data query request; wherein, the cluster information corresponds to multiple data production terminals; Obtain real-time data from multiple data production terminals corresponding to the cluster information; and When the data readiness rate is greater than a preset ratio, the real-time data is sent to the client; wherein, the data readiness rate represents the proportion of the real-time data corresponding to the obtained cluster information to the required data corresponding to the cluster information; The process of generating cluster information based on the data query request includes: At least one cluster sequence number is generated based on the data query request; wherein, the cluster sequence number corresponds to multiple data production terminals; Construct a topic data table, a cluster correspondence table, and a cluster location table; wherein, the topic data table includes the client address corresponding to the data query request, the character identifier corresponding to the data query request, and the topic of the data query request, wherein the character identifier represents a unique identifier corresponding to the cluster sequence number; the cluster correspondence table includes the character identifier, the cluster sequence number, and the data acquisition status; the cluster location table includes the cluster sequence number and the location information of multiple data production terminals.

2. The cluster data query method according to claim 1, characterized in that, The acquisition of real-time data from multiple data production terminals corresponding to the cluster information includes: The topic and character identifier of the real-time data corresponding to the cluster sequence number are compared with the topic and character identifier of the topic data table to obtain the real-time data corresponding to the cluster information.

3. The cluster data query method according to claim 1, characterized in that, After generating cluster information based on the data query request, the cluster data query method further includes: Send the cluster information to the client; Receive the status query request from the client; wherein the status query request contains the cluster information; Based on the cluster information, the status information of the real-time data corresponding to the cluster information is obtained by querying; and The status information is sent to the client.

4. The cluster data query method according to claim 3, characterized in that, The status information of the real-time data corresponding to the cluster information obtained by querying the cluster information includes: Query the data acquisition status of the corresponding real-time data based on the cluster sequence number.

5. The cluster data query method according to claim 1, characterized in that, The step of sending the real-time data to the client when the data readiness rate is greater than a preset ratio includes: When the data readiness rate is greater than a preset ratio, receive the data acquisition request from the client; and The real-time data is sent to the client according to the data acquisition request.

6. The cluster data query method according to claim 1, characterized in that, Before receiving the data retrieval request from the client, the cluster data query method further includes: The ratio of real-time data corresponding to the cluster information to the required data corresponding to the cluster information is calculated to obtain the data readiness rate.

7. A cluster data query device, characterized in that, The cluster data query device is applied to a cluster system, which includes multiple data production terminals, and is communicatively connected to these multiple data production terminals. The cluster data query device includes: The data request module is used to receive data query requests from clients; A status management module is used to generate cluster information based on the data query request; wherein the cluster information corresponds to multiple data production terminals; generating cluster information based on the data query request includes: generating at least one cluster sequence number based on the data query request; wherein the cluster sequence number corresponds to multiple data production terminals; constructing a topic data table, a cluster correspondence table, and a cluster location table; wherein the topic data table includes the client address corresponding to the data query request, a character identifier corresponding to the data query request, and the topic of the data query request, wherein the character identifier represents a unique identifier corresponding to the cluster sequence number; the cluster correspondence table includes the character identifier, the cluster sequence number, and the data acquisition status; the cluster location table includes the cluster sequence number and the location information of multiple data production terminals; The data transceiver module is used to acquire real-time data from multiple data production terminals corresponding to the cluster information; and The data feedback module is used to send the real-time data to the client when the data readiness rate is greater than a preset ratio; wherein, the data readiness rate represents the proportion of the real-time data corresponding to the obtained cluster information to the required data corresponding to the cluster information.

8. The cluster data query device according to claim 7, characterized in that, The cluster data query device also includes: The status query module is used to receive the status query request from the client and send the status information of the real-time data corresponding to the cluster information to the client.

9. A cluster data query system, characterized in that, include: Multiple data production endpoints; Client; as well as The cluster data query device as described in claim 7 or 8 is communicatively connected to multiple data production terminals and the client.

Images