State detection method and device for graph database task
By adopting a detection gradient mechanism in graph database tasks and periodically detecting task status, we can solve the problem of excessive computing resource usage and achieve fast and accurate task status detection, which is suitable for various task durations.
Patent Information
- Application Number
- CN202511240229.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-01
- Publication Date
- 2025-10-03
- Estimated Expiration
- 2045-09-01
AI Technical Summary
Existing technologies tend to occupy too many computing resources when detecting the running status of graph database tasks, and it is difficult to accurately detect the task completion status in a short period of time.
A detection gradient mechanism is adopted to create a detection task before the graph database task runs. The task status information is periodically detected with gradually increasing time intervals and detection times. The detection gradient is customized or used by default according to the task type to reduce computing resource usage.
It achieves the rapid detection of the completion status of graph database tasks while reducing computing resource usage, taking into account the detection needs of both short-term and long-term tasks, and improving the accuracy and efficiency of detection.
Smart Images

Figure CN120743887A_ABST
Abstract
Description
Technical Field
[0001] One or more embodiments of this specification relate to the field of graph database technology, and in particular, to a method and apparatus for detecting the status of a graph database task. Background Art
[0002] In the computer field, a database is a system used to store, manage, and retrieve data. Databases can be categorized as relational or non-relational. Graph databases are a type of non-relational database that can be used to store unstructured data. Graph databases store and query graph data in a graph structure. Graph data is stored in the form of nodes and edges, where nodes represent data entities and edges represent relationships between entities. The data stored in a graph database is also called graph data. When private data is stored in graph data, managing and retrieving it requires privacy protection.
[0003] The graph platform, short for graph operation platform, is used to manage graph databases. A graph platform typically manages multiple graph clusters. Each graph cluster consists of multiple node devices, and the graph databases of these node devices store multiple graph data. Users can use the graph platform to execute graph database tasks, and the runtime of different graph database tasks varies. In practical applications, it is necessary to monitor the execution of graph database tasks to quickly determine task completion.
[0004] At present, we hope to have an improved solution that can minimize the computing resources occupied when detecting the running process of graph database tasks. Summary of the Invention
[0005] One or more embodiments of this specification describe a method and apparatus for detecting the status of a graph database task, thereby minimizing the computing resources used when detecting the running status of a graph database task. The specific technical solution is as follows.
[0006] In a first aspect, an embodiment provides a state detection method for a graph database task, wherein the graph database is located in several node devices of a graph cluster; the method includes: Before running a first task on a graph database, creating a first detection task for the first task; wherein the running logic of the first detection task includes a detection gradient, and the detection gradient includes a plurality of sequentially arranged and gradually increasing time intervals and their corresponding detection times; Running the first detection task while running the first task; Wherein, running the first task specifically includes: communicating with a plurality of node devices in the graph cluster so that the plurality of node devices execute the processing indicated by the first task on the graph database therein; running the first task also includes: storing status information of the first task; Running the first detection task specifically includes: periodically detecting the status information at the current time interval in the detection gradient, updating the status information of the first task based on the detected status information, and storing the updated status information; after detecting a corresponding number of times, if the first task has not ended, periodically detecting the status information at the next time interval.
[0007] In one implementation, the step of creating a detection task for the first task includes: A default detection gradient is set in the operation logic for the first detection task.
[0008] In one implementation, the step of creating a first detection task for the first task includes: Determining, from a plurality of preset correspondences between task types and detection gradients, a detection gradient corresponding to a first task type to which the first task belongs; The determined detection gradient is set in the operation logic for the first detection task.
[0009] In one implementation, the method is performed by a graph platform, the graph platform including a plurality of node devices; the step of running the first detection task while running the first task includes: The first task and the first detection task are respectively run in different node devices of the graph platform.
[0010] In one implementation, the graph platform further includes a database, which is used to store status information of the first task; the step of storing the status information of the first task includes: writing the status information of the first task into the database; the step of detecting the status information of the first task includes: reading the status information of the first task from the database.
[0011] In one implementation, the state information includes heartbeat data of the first task. The step of updating the state information of the first task based on the detected state information includes: determining that the first task is in a terminated state when a timestamp of the detected heartbeat data is greater than a preset time interval from a current moment.
[0012] In one implementation, the state information includes task progress information of the first task. The step of updating the state information of the first task based on the detected state information includes: When the task progress information indicates that the task has been completed, the task result of the first task is verified according to a preset verification logic, and the task progress information is updated based on the verification result.
[0013] In one implementation, the step of verifying the task result of the first task according to a preset verification logic includes: communicating with several node devices in the graph cluster according to the preset verification logic to verify the task result of the first task.
[0014] In one implementation, the method further includes: when it is determined that the state of the first task is an end state by running the first detection task, ending the running of the first detection task.
[0015] In a second aspect, an embodiment provides a state detection device for a graph database task, wherein the graph database is located in several node devices of a graph cluster; the device includes: A task creation module is configured to create a first detection task for the first task before running the first task on the graph database; wherein the running logic of the first detection task includes a detection gradient, and the detection gradient includes a plurality of sequentially arranged and gradually increasing time intervals and their corresponding detection times; a task running module, configured to run the first detection task when running the first task; Wherein, running the first task specifically includes: communicating with a plurality of node devices in the graph cluster so that the plurality of node devices execute the processing indicated by the first task on the graph database therein; running the first task also includes: storing status information of the first task; Running the first detection task specifically includes: periodically detecting the status information at the current time interval in the detection gradient, updating the status information of the first task based on the detected status information, and storing the updated status information; after detecting a corresponding number of times, if the first task has not ended, periodically detecting the status information at the next time interval.
[0016] In a third aspect, an embodiment provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute any one of the methods according to the first aspect.
[0017] In a fourth aspect, an embodiment provides a computing device comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in any one of the first aspects is implemented.
[0018] In the methods and apparatus provided in the embodiments of this specification, a first detection task for the first task is executed while the first task is being executed. By executing the first detection task, the state information of the first task is periodically detected with a corresponding number of detections, according to a number of sequentially arranged and gradually increasing time intervals as detection periods. Thus, the state information of the first task can be updated based on the detected state information of the first task. If the first task ends after a short running time, the first detection task can detect the state at a higher frequency in a shorter time. If the first task ends after a long running time, the detection gradient used by the first detection task can increase the detection time interval after a period of detection, thereby reducing the number of detections and reducing the excessive use of computing resources. BRIEF DESCRIPTION OF THE DRAWINGS
[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. Those skilled in the art can also derive other drawings based on these drawings without inventive effort.
[0020] Figure 1 A schematic diagram of an implementation scenario of an embodiment disclosed in this application; Figure 2 A flowchart of a state detection method for a graph database task provided in an embodiment; Figure 3 A schematic diagram comparing the first detection task provided in the embodiment with an operation process of the first task; Figure 4 A schematic diagram of the principle of a state detection method provided in an embodiment; Figure 5 A schematic block diagram of a state detection device for a graph database task provided in an embodiment. DETAILED DESCRIPTION
[0021] The solution provided in this specification is described below in conjunction with the accompanying drawings.
[0022] Figure 1This is a schematic diagram of an implementation scenario of an embodiment disclosed in the present application. It includes a graph platform and several graph clusters managed by it. The graph platform includes several node devices and a database, which is used to store task status information. Any graph cluster includes several node devices, and the graph database in each node device is used to store graph data. Multiple node devices start the graph engine service to form a graph cluster, and multiple graph data can be stored in the graph cluster. In order to achieve high availability of graph data, a piece of graph data is usually divided into multiple parts, which are stored in multiple node devices of the graph cluster.
[0023] The database in the graph platform is not a graph database, but a relational database. Graph software is deployed on multiple node devices in the graph platform, allowing the platform to control and manage these devices. The graph platform uses this software to initiate graph database tasks for the graph cluster.
[0024] Graph database tasks are tasks performed on graph databases, including version upgrades, graph data vertex and edge statistics, vertex and edge model (schema) changes, graph data compaction, and graph cluster creation.
[0025] above Figure 1 This is just one implementation scenario. In actual applications, the present application can also be applied in other implementation scenarios, such as where the graph platform can be implemented by a node device, and the database can be located outside the graph platform.
[0026] When running graph database tasks on the graph platform, different types of tasks have varying runtimes, and the same type of task can also take varying runtimes when running on different graph data. For example, some graphs have large data volumes, and when executing a vertex-edge model change task, data import and export operations are frequent, resulting in long task execution times. Version upgrade tasks generally take a shorter time to execute.
[0027] To more quickly detect task completion, you can periodically monitor task status information. However, if the interval between these checks is too short, frequent task status checks can consume more system resources. If the interval is too long, the completion of some short-running tasks may not be detected in a timely manner.
[0028] In order to quickly determine the task status and reduce the excessive occupation of system resources caused by frequent task status detection, the embodiment of the present application provides a state detection method for graph database tasks. This method can be applied to, but is not limited to, Figure 1 In the scenario shown below. Figure 2This embodiment will be described in detail.
[0029] Figure 2 This embodiment provides a flow chart of a method for detecting the status of a graph database task. This method is performed on a graph platform. Node devices in the graph platform and node devices in a graph cluster can be implemented using any device, equipment, platform, or device cluster with computing and processing capabilities. A node device can be a container (Pod) or a physical machine. The method includes the following steps.
[0030] Step S210 : Before running the first task task1 on the graph database, create a first detection task d-task1 for the first task task1 .
[0031] Among them, the first task task1 and the first detection task d-task1 are both a program containing operating logic, which are used to implement their respective tasks and functions. The first task task1 is any database task. For example, when the first task task1 is a graph database version upgrade task, the first task task1 contains the operating logic required to implement the graph database version upgrade operation. When the graph platform manages multiple graph clusters, the operating logic of the first task task1 includes the communication interaction logic with the corresponding graph cluster, and the logic of instructing several node devices in the graph cluster to perform corresponding processing for the graph database therein.
[0032] The first detection task d-task1 is used to detect the first task task1, specifically to detect its status information. The operation logic of the first detection task d-task1 includes a detection gradient, which includes a number of sequentially arranged and gradually increasing time intervals and their corresponding detection times.
[0033] The detection gradient is illustrated below with examples. For example, the default detection gradient may include: time intervals of 5s, 60s, 120s and the corresponding number of detections k1 times, k2 times and an unlimited number of times. That is to say, the first detection task d-task1 first detects according to a period of 5s, for a total of k1 times, then detects according to a period of 60s, for a total of k2 times, and then detects according to a period of 120s, for a total of an unlimited number of times. Among them, the time intervals of 5s, 60s and 120s are also called gradient values, and k1 times, k2 times and an unlimited number of times are called detection times. The detection gradient contains multiple gradient values arranged in sequence and gradually increasing.
[0034] When creating the first detection task d-task1, the default detection gradient can be set in the operation logic for the first detection task d-task1. The default detection gradient can also be modified according to different task types, that is, the corresponding detection gradient can be customized for different task types. Whether modifying the default detection gradient or customizing the corresponding detection gradient, the number of gradients, gradient values and corresponding detection times in the detection gradient are set. The priority of the customized detection gradient is higher than the priority of the default detection gradient.
[0035] To improve execution efficiency, several correspondences between task types and detection gradients can be pre-set and stored. When a first detection task d-task1 is to be created, the detection gradient corresponding to the first task type to which the first task task1 belongs can be determined from the stored correspondences between task types and detection gradients.
[0036] The task types may include version upgrade type, node-edge statistics type, graph cluster creation type, node-edge model change type, and graph data merging type, etc. The first task type may be any one of multiple task types.
[0037] When the detection gradient is determined, the detection gradient can be set in the operation logic of the first detection task d-task1. Specifically, the operation logic of the first detection task d-task1 can be generated based on the detection gradient. The operation logic can also include verification logic for verifying the task's operation results.
[0038] For example, when the first task, Task 1, is a graph database version upgrade task, for example, when the target version is 2.0, the verification logic can be used to verify whether the graph database version in the corresponding node device is already the target version 2.0 when confirming the completion of the first task, Task 1. The target version 2.0 can be pre-set in the verification logic.
[0039] When the first task, task1, is to create a graph cluster, the verification logic can be used to verify whether the corresponding node devices have created the graph cluster, that is, whether the corresponding files have been installed, etc., when confirming the completion of the first task, task1. The addresses of the newly created node devices can be obtained from the status information of the first task, task1.
[0040] Step S220: Running the first detection task d-task1 while running the first task task1. This step can be understood as running the first task task1 and the first detection task d-task1 simultaneously.
[0041] Among them, running the first detection task d-task1 specifically includes: periodically detecting the status information of the first task task1 at the current time interval in the detection gradient, updating the status information of the first task task1 based on the detected status information, and storing the updated status information. After detecting a corresponding number of times, if the first task task1 has not ended, then periodically detecting the status information of the first task task1 at the next time interval; when, during the process of detecting a corresponding number of times, it is determined that the status of the first task task1 is the end state, that is, the first task task1 has ended, then ending the running of the first detection task d-task1. In other words, when the first task task1 hangs up, the running of the first detection task d-task1 is also ended.
[0042] During the execution of the first detection task d-task1, the detection frequency can be gradually reduced by gradually changing the time interval of periodic detection according to the detection gradient.
[0043] During the execution of the first task, task 1, the first task can store the status information of task 1. For example, the status information can be written into a database of the graph platform. The database is used to store the status information of task 1. When detecting the status information, it can be read from the database. In this way, no matter which node device of the graph platform the first task, task 1, is specifically routed to, the task status seen by the user through the graph platform is consistent, and the task status is derived from the database.
[0044] The above-mentioned status information includes the heartbeat data of the first task task1. The first task task1 can report its heartbeat data to the database at a fixed time interval.
[0045] The first detection task d-task1 can detect the heartbeat data of the first task task1 in the database, and can determine whether the first task task1 is still in a running state or the heartbeat data has timed out based on the recorded heartbeat data. When the heartbeat data times out, it is considered that the first task task1 has ended (i.e., it has hung up). When the timestamp of the detected heartbeat data is not greater than the preset time interval from the current moment, it is considered that the first task is in an unfinished state and is still running. When the timestamp of the detected heartbeat data is greater than the preset time interval from the current moment, it is determined that the first task task1 is in an ended state. At this time, the end state of the first task task1 can be written into the database. Among them, the preset time interval can be determined based on the time interval of the heartbeat data of the first task task1. In order to make the status detection more accurate, the preset time interval can, for example, be the result of the time interval of the heartbeat data of the first task task1 plus a certain duration.
[0046] Figure 3 A schematic diagram comparing the first detection task and the running process of the first task provided in the embodiment. Among them, the detection gradient in the first detection task d-task1 includes time intervals of 5s, 60s and 120s, and the number of detections is k1 times, k2 times and unlimited times respectively. The first detection task d-task1 and the first task start running from time 0 on the time axis. When the first task is detected according to the gradient value and the number of detections in the detection gradient, its task detection moments are 5s, 10s, 70s, 130s, 250s and 370s respectively, and the time intervals in the detection gradient corresponding to these task detection moments are 5s, 5s, 60s, 60s, 120s and 120s respectively, as shown in FIG. Figure 3 As shown in the red dotted box.
[0047] Figure 3 The figure also shows situations where the first task, task1, crashes after running for different durations (8s, 85s, and 350s). When task1 crashes at the 8th second, the first detection task, d-task1, can detect the end of task1 during the task check at the 10th second, with a detection status lag of 2s. When task1 crashes at the 85th second, d-task1 can detect the end of task1 during the task check at the 130th second, with a detection status lag of 45s. When task1 crashes at the 350th second, d-task1 can detect the end of task1 during the task check at the 370th second, with a detection status lag of 20s. See Table 1 for details.
[0048] Table 1 In this example, the total lag time=2s+45s+20s=67s, and the total number of detections of the first detection task d-task1 is 7 times.
[0049] Assuming that detection is not performed according to the detection gradient, but periodically at fixed time intervals, for example, periodically at 60s, the task detection moments are 60s, 120s, 180s, 240s, 300s, and 360s, respectively. When the first task task1 fails at the 8th second, the detection task detects the end state of the first task task1 in the task detection at the 60th second, and the detection state lags by 52s. When the first task task1 fails at the 85th second, the detection task detects the end state of the first task task1 in the task detection at the 120th second, and the detection state lags by 35s. When the first task task1 fails at the 350th second, the detection task can detect the end state of the first task task1 in the task detection at the 360th second, and the detection state lags by 10s. See Table 2 for details.
[0050] Table 2 In this example, the total lag time = 52s + 35s + 10s = 97s, and the total number of detections for the detection task is 6.
[0051] As can be seen, in both examples, the total number of detection tasks (6 and 7) is similar, but the total lag time of 97 seconds for the fixed-period detection is significantly longer than the total lag time of 67 seconds for the gradient-period detection. If the fixed-period detection interval is reduced, the total number of detections will increase significantly.
[0052] Furthermore, for tasks with very short runtimes, gradient checking can detect task failures more promptly. For tasks with very long runtimes, gradient checking can reduce the total number of checks and save system computing resources.
[0053] As mentioned above, the corresponding detection gradient can be determined according to the task type, and the first detection task d-task1 can be created based on the determined detection gradient. According to the task type, the range of the task's running time can be roughly determined, thereby determining a more reasonable detection gradient for the task type. However, different tasks of the same task type have different running times and are uncertain. For example, for the point-edge statistics task, the time spent on point-edge statistics for graph clusters of different sizes is also different. In other words, whether it is different tasks of the same type or different tasks of different types, their running times are uncertain. Therefore, the detection of any first task task1 through the detection gradient can take into account both short-duration tasks and long-duration tasks.
[0054] The following will continue to explain the specific operating logic of the first task task1 and the first detection task d-task1 with reference to specific examples. In an implementation scenario including a graph platform and its graph cluster, the first task task1 and the first detection task d-task1 can be run in the graph platform. Among them, running the first task task1 specifically includes: communicating with several node devices in the graph cluster so that the several node devices execute the processing indicated by the first task task1 for the graph database therein.
[0055] The following example illustrates the first task, Task 1, which is a point-edge statistics task. The operational logic of Task 1 includes: sending a point-edge statistics instruction to several node devices in the graph cluster to be counted, and receiving statistical results fed back by the corresponding node devices. The several node devices perform corresponding processing based on the point-edge statistics instruction and send the statistical results to Task 1.
[0056] The status information reported to the database by the first task task1 during operation may also include task progress information, which is used in the verification process of the first task task1. The operation logic in the first detection task d-task1 also includes preset verification logic. During the operation of the first detection task d-task1, when it is determined that the task progress information indicates that the task has been completed, the task result of the first task task1 is verified according to the verification logic, and the task progress information is updated based on the verification result. That is, the verification result can be written into the database as the task progress information.
[0057] During execution, the first detection task d-task1 may communicate with several node devices in the graph cluster according to the verification logic to verify the task result of the first task task1 and may write the verification result into the database.
[0058] For example, when the first task is a version upgrade task, the task progress information may include upgrade success information. The first detection task d-task1 may send a version verification request to the node device in the corresponding graph cluster during execution, and determine whether the upgrade is successful based on the feedback data from the node device.
[0059] When the first task is to create a graph cluster, when the first task task1 completes the creation of the graph cluster, the address of the node device in the newly created graph cluster can be reported to the database. That is, the task progress information includes the address information of the newly created graph cluster. When the first detection task d-task1 is running, it can read the address information in the task progress information from the database, send a verification request to the node device in the corresponding graph cluster based on the address information, determine whether the graph cluster is successfully created based on the feedback data of the node device, and write the result of successful or unsuccessful creation into the database.
[0060] To achieve high availability of task detection, the first task, task1, and the first detection task, d-task1, can be run separately on different node devices in the graph platform. This way, if the node device running the first task, task1, fails, the first detection task, d-task1, can still run normally. Therefore, the failure of task1 can be determined based on the timeout of the heartbeat data of task1 in the database.
[0061] In practical applications, the first task task1 and the first detection task d-task1 can be implemented through corresponding threads. Figure 4 A schematic diagram of the principle of a state detection method provided for an embodiment. Among them, the following definitions are made in the graph platform: define the task type of the graph database, define the detection gradient: the longest is 120s, the gradient is 3 levels, i.e. 5s, 60s and 120s, and the number of detections are 2 times, 4 times and unlimited times respectively. The task types of the graph database include the task type of creating a graph cluster and the task type of changing the point-edge model. When the graph platform initiates a database task, the graph platform initiates the corresponding running task thread, i.e., the executor thread, in a certain node device, and at the same time starts a watcher thread in another node device of the graph platform to detect the running status of the executor thread. The two node devices on the left run the watcher thread and executor thread for the task of creating a graph cluster, respectively, and the two node devices on the right run the watcher thread and executor thread for the task of changing the point-edge model, respectively. The detection gradients and corresponding times of the two watcher threads are the same.
[0062] After the watcher thread starts running, it checks the executor thread's status twice, every 5 seconds. If the task is completed, the task status is updated and the watcher thread terminates. In this example, the vertex-edge model modification task is completed during the watcher thread's 5-second check, allowing the executor thread status to be updated promptly.
[0063] If the executor thread is running in the first two detections of the watcher thread, then two more detection tasks will be started, and the task status will be checked once every 60 seconds. If the task is completed, the task status will be updated and the watcher thread will also end.
[0064] If the executor thread is running during all four watcher thread checks, the watcher thread will check the task status every 120 seconds. Once the task completes, the task status is updated, and the watcher thread terminates. In this example, the graph cluster creation task completes during the watcher thread's 120-second check, allowing the executor thread to update the task status without requiring multiple checks. Creating a graph cluster is also called creating a graph database cluster.
[0065] The executor thread writes its own task progress information and heartbeat data to the database, and the watcher thread writes the updated task status to the database. The executor thread communicates with the nodes in the graph cluster to complete the execution of the database task. The watcher thread communicates with the nodes in the graph cluster to verify the task status.
[0066] In this specification, the word "first" in terms such as the first task and the first detection task, as well as the corresponding "second" (if any) in the text, are merely for the convenience of distinction and description and do not have any limiting meaning.
[0067] The foregoing description describes specific embodiments of the present disclosure, and other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than that described in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily need to be performed in the specific order shown or in a sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0068] Figure 5 The schematic block diagram of a state detection device for a graph database task provided in an embodiment. The graph database is located in several node devices of the graph cluster. Figure 2 The apparatus 500 is deployed in the image platform and includes: The task creation module 510 is configured to create a first detection task for the first task before running the first task on the graph database; wherein the running logic of the first detection task includes a detection gradient, and the detection gradient includes a plurality of sequentially arranged and gradually increasing time intervals and their corresponding detection times; The task running module 520 is configured to run the first detection task when running the first task; Among them, running the first task specifically includes: communicating with several node devices in the graph cluster so that the several node devices perform the processing indicated by the first task on the graph database therein. Running the first task also includes: storing the status information of the first task. Running the first detection task specifically includes: periodically detecting the status information of the first task at the current time interval in the detection gradient, and updating the status information of the first task based on the detected status information of the first task; after detecting the corresponding number of times, if the first task has not ended, periodically detecting the status information of the first task at the next time interval.
[0069] In one implementation, the task running module 520 includes: a detection submodule 521, an update submodule 522, and a storage submodule 523. The detection submodule 521 is specifically configured to periodically detect the status information of the first task at the current time interval in the detection gradient. After a corresponding number of detections, if the first task has not ended, the status information of the first task is periodically detected at the next time interval. The update submodule 522 is specifically configured to update the status information of the first task based on the detected status information of the first task and store the updated status information. The storage submodule 523 is specifically configured to store the status information of the first task during the execution of the first task.
[0070] In one implementation, the task creation module 510 is specifically configured to set a default detection gradient in the operation logic for the first detection task.
[0071] In one implementation, the task creation module 510 is specifically configured to: determine the detection gradient corresponding to the first task type to which the first task belongs from the preset correspondence between several task types and detection gradients, and set the determined detection gradient in the operation logic for the first detection task.
[0072] In one implementation, the apparatus 500 is executed via a graph platform, which includes a plurality of node devices. The task execution module 520 is specifically configured to execute the first task and the first detection task in different node devices of the graph platform respectively.
[0073] In one implementation, the graph platform further includes a database for storing the status information of the first task. The storage submodule 523 is specifically configured to write the status information of the first task into the database. In this embodiment, when the task execution module 520 detects the status information of the first task, it specifically includes reading the status information of the first task from the database.
[0074] In one implementation, the state information includes heartbeat data of the first task. The updating submodule 522 is specifically configured to: determine that the first task has ended when the timestamp of the detected heartbeat data is greater than a preset time interval from the current moment.
[0075] In one implementation, the status information includes task progress information of the first task. The updating submodule 522 is specifically configured to: when the task progress information indicates that the task has been completed, verify the task result of the first task according to a preset verification logic, and update the task progress information based on the verification result.
[0076] In one implementation, when verifying the task result of the first task according to the preset verification logic, the updating submodule 522 includes: communicating with several node devices in the graph cluster according to the preset verification logic to verify the task result of the first task.
[0077] In one implementation, the apparatus 500 further includes: an end-of-run module 530 configured to end the running of the first detection task when it is determined that the state of the first task is an end state by running the first detection task.
[0078] The above-mentioned device embodiments correspond to the method embodiments. For detailed descriptions, please refer to the description of the method embodiments, which will not be repeated here. The device embodiments are obtained based on the corresponding method embodiments and have the same technical effects as the corresponding method embodiments. For detailed descriptions, please refer to the corresponding method embodiments.
[0079] The embodiment of this specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute Figures 1 to 4 Any of the methods described above.
[0080] The embodiment of this specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, Figures 1 to 4 Any of the methods described above.
[0081] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences between the other embodiments. In particular, the storage medium and computing device embodiments are described briefly because they are generally similar to the method embodiments. For relevant portions, refer to the description of the method embodiments.
[0082] Those skilled in the art will appreciate that, in one or more of the above examples, the functions described in the embodiments of the present invention may be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions may be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.
[0083] The specific implementation methods described above further illustrate the purpose, technical solutions, and beneficial effects of the embodiments of the present invention. It should be understood that the above description is only a specific implementation method of the embodiments of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the present invention shall be included in the scope of protection of the present invention.
Claims
1. A method for detecting the status of a graph database task, wherein the graph database is located in several node devices of a graph cluster; the method comprises: Before running a first task on a graph database, creating a first detection task for the first task; wherein the running logic of the first detection task includes a detection gradient, and the detection gradient includes a plurality of sequentially arranged and gradually increasing time intervals and their corresponding detection times; Running the first detection task while running the first task; Wherein, running the first task specifically includes: communicating with a plurality of node devices in the graph cluster so that the plurality of node devices execute the processing indicated by the first task on the graph database therein; running the first task also includes: storing status information of the first task; Running the first detection task specifically includes: periodically detecting the status information at the current time interval in the detection gradient, updating the status information of the first task based on the detected status information, and storing the updated status information; after detecting a corresponding number of times, if the first task has not ended, periodically detecting the status information at the next time interval.
2. The method according to claim 1, wherein the step of creating a detection task for the first task comprises: A default detection gradient is set in the operation logic for the first detection task.
3. The method according to claim 1, wherein the step of creating a first detection task for the first task comprises: Determining, from a plurality of preset correspondences between task types and detection gradients, a detection gradient corresponding to a first task type to which the first task belongs; The determined detection gradient is set in the operation logic for the first detection task.
4. The method according to claim 1, wherein the method is performed through a graph platform, the graph platform comprising a plurality of node devices; the step of running the first detection task while running the first task comprises: The first task and the first detection task are respectively run in different node devices of the graph platform.
5. The method according to claim 4, wherein the graph platform further comprises a database for storing the status information; the step of storing the status information of the first task comprises: Writing the status information of the first task into the database; The step of detecting the status information of the first task includes: reading the status information of the first task from the database.
6. The method according to claim 1, wherein the state information includes heartbeat data of the first task; The step of updating the status information of the first task based on the detected status information includes: When the timestamp of the detected heartbeat data is greater than a preset time interval from the current moment, it is determined that the first task is in the end state.
7. The method according to claim 1, wherein the status information includes task progress information of the first task; and the step of updating the status information of the first task based on the detected status information comprises: When the task progress information indicates that the task has been completed, the task result of the first task is verified according to a preset verification logic, and the task progress information is updated based on the verification result.
8. The method according to claim 7, wherein the step of verifying the task result of the first task according to a preset verification logic comprises: According to a preset verification logic, communicate with several node devices in the graph cluster to verify the task result of the first task.
9. The method according to claim 1, further comprising: When it is determined that the first task is in an end state by running the first detection task, the running of the first detection task is ended.
10. A status detection device for a graph database task, wherein the graph database is located in several node devices of a graph cluster; the device comprises: A task creation module is configured to create a first detection task for the first task before running the first task on the graph database; wherein the running logic of the first detection task includes a detection gradient, and the detection gradient includes a plurality of sequentially arranged and gradually increasing time intervals and their corresponding detection times; a task running module, configured to run the first detection task when running the first task; Wherein, running the first task specifically includes: communicating with a plurality of node devices in the graph cluster so that the plurality of node devices execute the processing indicated by the first task on the graph database therein; running the first task also includes: storing status information of the first task; Running the first detection task specifically includes: periodically detecting the status information at the current time interval in the detection gradient, updating the status information of the first task based on the detected status information, and storing the updated status information; after detecting a corresponding number of times, if the first task has not ended, periodically detecting the status information at the next time interval.
11. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 9.
12. A computing device comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 9 is implemented.
Citation Information
Patent Citations
Inquiry processing method and cluster data base system
CN103136363A
Method, device and system for monitoring running of task threads of cluster
CN106940671A
Method and device for executing data processing task
CN113127158A
Task scheduling method and device, computer equipment and storage medium
CN117873679A
Distributed cluster management method and device, medium and electronic equipment
CN118945178A