Shared query tree for complex event query and construction method and query method thereof

Abstract

The application discloses a shared query tree for complex event query and a construction method and a query method thereof. When the shared query tree is constructed, firstly, query instances of multiple complex events are reconstructed, then the multiple reconstructed queries are combined by adopting a shared prefix query node mode to obtain the shared query tree. The shared query tree can be regarded as a query containing multiple complex event queries, the semantics of the multiple queries are unified into one query, and the multiple queries are connected by sharing the prefix. The query nodes in the shared prefix only need to complete one event processing, thereby providing services for all single queries with the common query nodes, reducing repeated calculation of the complex event query, and greatly improving the processing efficiency of the complex event.

Description

Technical Field

[0001] This disclosure relates to the technical field of complex event query processing, and in particular to a shared query tree for complex event queries, a method for constructing the tree, and a query method thereof. Background Technology

[0002] With the emergence of event-driven architecture, the automation of business activities and industrial production, and the widespread application of distributed large-scale systems, massive amounts of data have been generated. Simultaneously, many rules regarding legitimacy and operability have been added to existing systems, resulting in an increasing number of events within the data. Consequently, there is growing concern about the automatic monitoring and management of these events. Complex event processing (CEP) technology addresses this problem. Whenever an event occurs in the event stream, the CEP system uses predefined rules to identify the higher-level events of interest from the underlying events.

[0003] Complex event processing (CEP) technology has applications in many scenarios, such as real-time analysis and monitoring services for sensor telemetry data during aircraft test flights and financial services. The two main models of event processing are Data Stream Processing (DSP) and Complex Event Processing (CEP). DSP generates new data streams by processing data from different data sources in real time. DSP continuously executes given queries on high-speed data streams and provides new data. Therefore, system users do not need to request updated data; the system automatically provides data update notifications based on the given query. In contrast, CEP treats each data point as a simple event occurring in the external environment. When an event arrives, the CEP system performs filtering, correlation, and aggregation operations on these events to determine whether a higher-level event has occurred.

[0004] Currently, the main methods for querying complex events are NFA-based methods and tree-based methods. NFA-based methods use local matching and centralized processing, which is inefficient and involves a lot of redundant calculations when events are unevenly distributed. Tree-based methods match complex events in batches, and the matching results spanning two batches may be missed, resulting in a lot of redundant calculations.

[0005] Therefore, whether it is possible to study a query method for complex events to reduce redundant calculations and improve query efficiency has become an urgent problem to be solved. Summary of the Invention

[0006] In view of this, the present invention provides a shared query tree for complex event queries, a method for constructing the tree, and a query method thereof, which solves the problem of low query efficiency due to a large amount of repetitive calculations in previous complex event queries.

[0007] On one hand, the present invention provides a method for constructing a shared query tree for complex event queries, the method comprising the following steps:

[0008] S1: Obtain query instances of multiple complex events, each of which is composed of multiple simple events;

[0009] S2: Based on the statistical information of the simple events, the simple events in each query instance are reconstructed in order to obtain a reconstructed query instance. If the order of the simple events in the reconstructed query instance is reversed from the order before reconstruction, then the node is a reverse node; otherwise, it is a forward node.

[0010] S3: Based on the method of shared prefix query nodes, multiple reconstructed query instances are merged to obtain a shared query tree.

[0011] Preferably, in step S2, based on the statistical information of the simple events, the simple events in each query instance are reconstructed sequentially, specifically as follows:

[0012] S201: Obtain the arrival rate r and condition selectivity s of the simple event, where the arrival rate r represents the probability of the simple event occurring, and s represents the probability of the simple event passing the condition constraint check of the complex event.

[0013] S202: Combine the arrival rate r of the simple event and the conditional selectivity s to obtain the selectivity sel, and use the selectivity sel as statistical information;

[0014] S203: Based on the statistical information, sort the simple events from smallest to largest to obtain a reconstructed order.

[0015] Further optimized, in step S202, the specific formula for combining the arrival rate r of the simple event and the conditional selectivity s to obtain the selectivity sel is as follows:

[0016] And sel x ∈[0,2], where x is the label of the simple event, C i This is the set of conditional constraints for the query instance where the simple event occurs.

[0017] Further optimization involves merging multiple reconstructed query instances in step S3, based on the shared prefix query node method, to obtain a shared query tree, specifically:

[0018] Find the longest common prefix among multiple reconstructed query instances and merge the longest common prefixes to obtain a shared query tree. The time window size matched by each node in the shared query tree is the maximum time window containing the query of that node.

[0019] On the other hand, the present invention also provides a shared query tree for complex event queries, wherein the shared query tree is constructed using any of the methods described above.

[0020] Furthermore, this invention also provides a complex event query method based on a shared query tree, wherein the query method uses the aforementioned shared query tree for querying, and the specific query steps are as follows:

[0021] 1) Obtain the event stream to be queried;

[0022] 2) Read the simple events in the event stream to be queried in sequence, and starting from the root node, perform one-to-one matching on the nodes in the form of breadth-first traversal on the shared query tree to obtain the query results.

[0023] Preferably, in step 2), simple events in the event stream to be queried are read sequentially, and starting from the root node, a breadth-first traversal is performed on each node in the shared query tree to obtain the query result, specifically:

[0024] 2.1) Read the Nth simple event from the event stream to be queried, and perform local matching processing starting from the root node of the shared query tree;

[0025] 2.2) If the local matching at the root node fails, determine whether there is a local matching at the root node. If there is no local matching, store the Nth simple event in the cache area corresponding to the event type. If there is a local matching, traverse the shared query tree to see if there is a forward node corresponding to the event type of the Nth simple event. If there is, and there is a local matching in the parent node of the forward node corresponding to the event type of the Nth simple event, then perform local matching processing at the forward node. Otherwise, store the Nth simple event in the cache area corresponding to the event type.

[0026] When the Nth simple event is processed locally at the forward node, if the match fails, the Nth simple event is stored in the cache of the corresponding event type. If the match succeeds, a new local match is generated, which triggers all child nodes with the forward node as the parent node to extract the events in the cache of their corresponding event type for local matching, generating local matches for each node. If a forward node exists in the newly generated local matching node, it will trigger all child nodes with the forward node as the parent node to extract the events in the cache of their corresponding event type for local matching, until all local matching processes are completed.

[0027] 2.3) Read the (N+1)th simple event in the event stream to be queried, perform local matching processing at the root node of the shared query tree, and repeat step 2.2) until all simple events in the event stream to be queried have been processed, where N is a natural number greater than or equal to 1;

[0028] 2.4) Determine whether the query node of the shared query tree is a leaf node. If it is a leaf node, the local match corresponding to the node is the query result.

[0029] This invention provides a method for constructing a shared query tree for complex event queries. This method first reconstructs multiple query instances of complex events, then merges these reconstructed queries using shared prefix query nodes to obtain a shared query tree. This shared query tree can be viewed as a single query containing multiple complex event queries, where the semantics of these queries are unified into a single query, linked together by a shared prefix. Query nodes within the shared prefix only need to complete event processing once to provide services to all individual queries sharing that common query node, reducing redundant computation and significantly improving the processing efficiency of complex events.

[0030] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit the disclosure of this invention. Attached Figure Description

[0031] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0032] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1This is a flowchart illustrating a method for constructing a shared query tree for complex event queries, as provided in an embodiment of the present invention.

[0034] Figure 2 A comparison chart of query status before and after the reconstruction;

[0035] Figure 3 This is a diagram illustrating the forward and reverse query nodes after the query has been reconstructed.

[0036] Figure 4 This is a schematic diagram of the reconstructed query and its local matching of query nodes;

[0037] Figure 5 To query the reconstruction diagram of q1 and q2;

[0038] Figure 6 To query the shared query tree formed by q1 and q2;

[0039] Figure 7 This is a schematic diagram illustrating the query restructuring for queries Q1, Q2, and Q3;

[0040] Figure 8 To query the shared query tree formed by Q1, Q2, and Q3;

[0041] Figure 9 To adopt Figure 8 This is a diagram illustrating event flow queries using a shared query tree. Detailed Implementation

[0042] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of methods consistent with some aspects of the invention as detailed in the appended claims.

[0043] To address the issue of low query efficiency due to excessive repetitive calculations in complex event queries, this implementation scheme provides a shared query tree for complex event queries. In complex event processing systems, different complex event queries exhibit varying processing efficiencies. This is caused by the distribution patterns of events and attribute values ​​within the event stream. Factors influencing the event stream can be obtained through event stream statistics. Utilizing these statistics to optimize queries and even adjust query structures can significantly improve the performance of single queries in complex event processing, and subsequently, multi-query optimization can also benefit. Therefore, this implementation scheme requires query reconstruction of query instances before constructing the shared query tree. For specific construction steps, please refer to [link to relevant documentation]. Figure 1 Specifically:

[0044] S1: Obtain query instances of multiple complex events, each of which is composed of multiple simple events;

[0045] S2: Based on the statistical information of the simple events, the simple events in each query instance are reconstructed in order to obtain a reconstructed query instance. If the order of the simple events in the reconstructed query instance is reversed from the order before reconstruction, then the node is a reverse node; otherwise, it is a forward node.

[0046] S3: Based on the method of shared prefix query nodes, multiple reconstructed query instances are merged to obtain a shared query tree.

[0047] The following sections will provide detailed explanations of query reconstruction in step S2 and shared query tree construction in step S3.

[0048] Query Refactoring:

[0049] Event streams are a type of streaming data characterized by real-time arrival and large scale. Statistical analysis of event streams can only be performed synchronously as events arrive. Information about future event instances is inferred by continuously collecting information from currently arriving event instances. Two statistical values ​​in event stream statistics are closely related to queries: the event arrival rate *r*, and the selectivity *s* of the attribute values ​​assigned to simple events. *r* represents the probability of an event occurring in the event stream, while *s* represents the probability of a simple event passing the conditional constraint check of a complex event.

[0050] In this implementation scheme, Q = {q1,q2,q3,...,q} is used. n} represents the query group, S = {e1, e2, e3, ..., e m} represents an event stream, and the statistics within the event stream are represented by M. A single query can be represented as... in q i The sequence of event types for simple events within a complex event sequence defined in C. i q i The set of conditions and constraints in the context contains the constraints defined for each simple event. The final w... i Then it means q i The time window constraint. This implementation only discusses complex event sequence queries based on the SEQ definition, because the processing of complex event queries containing closures and negations can be easily extended using the basic complex event query techniques defined by SEQ.

[0051] M contains the event arrival rate r and the event selectivity s, where s is formed by the combined effect of the conditional constraints on each simple event in the query. For example, query q i Simple event type E x If there are conditional constraints that are not related to other events, then E x The selectivity of a condition can be expressed as Where q i ∈Q, and When the maximum value is 1, it represents E. x There are no conditional constraints. If event type E x With E y If there are related conditional constraints, then their conditional selectivity is expressed as: In summary, the statistical information M-format is defined as follows:

[0052]

[0053] The event arrival rate and condition selectivity in the statistical information M are combined to obtain the selectivity sel. x Then event type E x The final selectivity is And sel x ∈[0,2].

[0054] The following example illustrates how to reconstruct queries based on event stream statistics and improve query matching efficiency.

[0055] Suppose there exists a query q:SEQ(A,B,C), where sel B ≤sel C ≤se AIn a complex event sequence, event type A has the highest selectivity, while event type B has the lowest. Following a traditional matching process, we first acquire event instances of type A, generate local matches, and wait for event instances of type B to arrive. Then, we further match based on the existing local matches, and so on, until a complex event matching instance is generated. Since event type A has the highest selectivity, it means that event A will have more verified event instances in the event stream than other event types. However, in a complex event sequence, event type B has the lowest selectivity. This means that if we first verify and match events of type A, many local match instances will be created in memory that will be discarded in subsequent matches. If we first verify and match events of type B with the lowest selectivity, the number of local matches in memory can be reduced, and the computational overhead of re-matching local matches can be saved.

[0056] See Figure 2 The diagram shows a comparison of the query states before and after the reconstruction. (a) represents the query before reconstruction; (b) represents the query after reconstruction. As shown in (b), in the "init" query initialization state, if type A or type C events are encountered, they are stored in their respective buffers. Event verification is not performed immediately until the currently arriving event is a type B event, at which point complex events begin to be verified. If the verification of type B events passes, a partial match is generated, and previously arrived events are retrieved from the buffer of type C events for verification. This process continues until a complex event matching instance is finally generated.

[0057] Query refactoring improves the performance of individual complex event queries by leveraging event stream statistics. It's important to note that query refactoring means adjusting the processing order of events in a complex event query based on event stream statistics for optimal performance; the semantics of the complex event query itself cannot be altered during refactoring. In complex event queries defined using a complex event description language, simple events have strict temporal constraints. If the semantic consistency of the query cannot be guaranteed after refactoring, the refactored query will become a completely different query.

[0058] Because query refactoring alters the processing order of simple events in complex event queries, and a cache is used to store temporarily unused event instances, the concepts of forward and reverse query nodes are proposed to ensure semantic consistency of queries after refactoring.

[0059] For a complex event query q i In this case, the tree-structured monitoring model has n nodes, each corresponding to... Each event type in the model. To be precise, it's not a traditional tree structure; for a single query, it's more like a linked list because the model has only one root node and only one leaf node, and the node order is... In this system, events are ordered sequentially, and each node is a query node. Only in a multi-query environment are multiple single-query tree-structured monitoring models merged, thus resembling a traditional tree structure. When query refactoring occurs, this tree structure generates forward and reverse query nodes to maintain semantic consistency of the queries.

[0060] In the tree-structured monitoring model for complex event queries, if the target event instance matched on a query node is the latest event instance in the event stream, then the query node is called a forward query node; if the target event matched on a query node is an event that has already arrived and is stored in the event cache, then the query node is called a reverse query node.

[0061] Reverse lookup nodes are generated based on inversions of the node label sequence after the query reconstruction. For example... Figure 3 As shown, for the tree-structured monitoring model of query q:SEQ(A,B,C,D), all query nodes are forward query nodes because the matching is performed sequentially. If the reconstructed event sequence order becomes C, B, A, and D, the indices of the query nodes in the tree-structured monitoring model will change with the order of the query nodes. Therefore, the reconstructed query node index sequence will generate two pairs of inversions: (2,1) and (2,0). The reverse query nodes are determined by the second index in the inversion pair, resulting in indices 1 and 0, corresponding to nodes B and A, respectively. Figure 3 The query nodes marked with "-" are considered as query nodes. The remaining non-reverse query nodes are considered as forward query nodes in the tree-structured monitoring model.

[0062] The existence of forward and reverse query nodes lays the foundation for ensuring semantic consistency in the complex event tree monitoring model. However, forward and reverse query nodes only specify the source of the event instances matched at the node: the most recently arrived event instance in the current event stream or an already arrived event instance in the cache. To ensure that the final complex event matching instance generated during the matching process conforms to the semantics of the query before reconstruction, the local matching event sequence to be generated for each query node must be specified. Figure 3 Taking the reconstructed query as an example, the sequence of local matching events specified on each query node is as follows: Figure 4 As shown.

[0063] Since the simplest event that the reconstructed query first matches is a C-type event, the local match on query node C is...<c>When the event currently arriving in the event stream is a type C event and passes the matching check, a corresponding local match is generated on the C query node. The next B node is a reverse query node. After a local match is generated on the C node, the B node is notified to perform a reverse query (event instances matched on the reverse query node are stored in the event buffer, while event instances matched on the forward node are not cached). Event matching for the corresponding window is performed in the B type event buffer. Since the B node is a reverse query node, the successfully matched B type event instance in the buffer will be inserted before the C type event instance in the local match according to its node index, forming a local match.<B,C> The same process is performed on the next reverse query node A to produce a local match.<A,B,C> The last D node is a forward matching node, so successfully matched D-type events will be added to the end of the local matching event sequence generated by node A. Therefore, the complex event matching generated after the final matching process is the same as the matching result generated before query reconstruction. Meanwhile, the local matching event sequence specified on the query node plays a role in determining whether to share the query node in the subsequent construction of the shared query tree.

[0064] By using forward and reverse query nodes and specifying a sequence of local matching events on each query node, the semantic consistency of the reconstructed query is ensured.

[0065] Shared query tree construction:

[0066] A shared query tree is constructed by merging query instances after query restructuring, using shared prefix query nodes. Shared prefixes achieve local matching by merging common prefix nodes from multiple complex event queries based on a tree-structured monitoring model. The changes brought about by query restructuring go beyond simply altering the order of query nodes based on event flow statistics to make the matching process more efficient. More importantly, it adjusts the matching order within each query to be more consistent based on event flow statistics, making previously nonexistent sharing opportunities easily discoverable and exploitable.

[0067] The common prefix of complex event queries based on a tree-structured monitoring model is the longest mergeable prefix query node sequence among two reconstructed queries. For each query node in the common prefix, firstly, the query node types must be consistent, i.e., both must be either forward query nodes or both must be reverse query nodes; secondly, the local matching event sequences specified on the query nodes must be consistent; and finally, the constraints on the query nodes must be identical. Only the longest prefix query node sequence that meets these three requirements can be merged.

[0068] like Figure 5 The diagram illustrates the reconstruction of queries q1:SEQ(D,A,C,B) and q2:SEQ(A,E,C,B,D), where W1=50 and W2=70. To more clearly illustrate prefix sharing, the constraints in complex event queries are set to empty by default. In the tree structure after the two queries are reconstructed, the longest common prefix nodes are nodes B, C, and A. These three query nodes satisfy the three requirements for prefix node sequence merging. Having found the longest common prefix, the next step is to merge these common prefixes to obtain a new query structure, called a shared query tree. A shared query tree can be viewed as a query containing multiple complex event queries, where the semantics of multiple queries are unified into a single query, and these queries are linked together through a shared prefix. Query nodes in the shared prefix only need to complete event processing once to provide services to all individual queries that share that common query node, thus greatly improving the processing efficiency of complex events.

[0069] Figure 6 This demonstrates the shared query tree constructed by merging the prefixes of queries q1 and q2 after reconstruction. Of particular note is the change in the time window W on the query nodes. In the tree-structured monitoring model instance for a single query, each node has its own time window, which is derived from the time window defined by the original query to which the node belongs. The time window of shared prefix query nodes in the shared query tree comes from the largest query time window contained within that tree, while the time windows of independent query nodes that have not been merged come from the query to which they belong. Figure 6 In this system, by sharing a query tree, the number of monitoring models that originally performed complex event processing tasks in the system was reduced from two to only one. This saves memory overhead, and by sharing local matches on query nodes in the common prefix, it reduces the generation of a large number of duplicate local matches, speeds up the efficiency of complex event matching, and improves the throughput of the multi-complex event processing system.

[0070] The process of performing complex event queries using the shared query tree constructed above is as follows:

[0071] 1) Obtain the event stream to be queried;

[0072] 2) Read the simple events in the event stream to be queried in sequence, and starting from the root node, perform one-to-one matching on the nodes in the form of breadth-first traversal on the shared query tree to obtain the query results.

[0073] In step 2), simple events in the event stream to be queried are read sequentially, and starting from the root node, a breadth-first traversal is performed on each node in the shared query tree to obtain the query results. Specifically:

[0074] 2.1) Read the Nth simple event from the event stream to be queried, and perform local matching processing starting from the root node of the shared query tree;

[0075] 2.2) If the local matching at the root node fails, determine whether there is a local matching at the root node. If there is no local matching, store the Nth simple event in the cache area corresponding to the event type. If there is a local matching, traverse the shared query tree to see if there is a forward node corresponding to the event type of the Nth simple event. If there is, and there is a local matching in the parent node of the forward node corresponding to the event type of the Nth simple event, then perform local matching processing at the forward node. Otherwise, store the Nth simple event in the cache area corresponding to the event type.

[0076] When the Nth simple event is processed locally at the forward node, if the match fails, the Nth simple event is stored in the cache of the corresponding event type. If the match succeeds, a new local match is generated, which triggers all child nodes with the forward node as the parent node to extract the events in the cache of their corresponding event type for local matching, generating local matches for each node. If a forward node exists in the newly generated local matching node, it will trigger all child nodes with the forward node as the parent node to extract the events in the cache of their corresponding event type for local matching, until all local matching processes are completed.

[0077] 2.3) Read the (N+1)th simple event in the event stream to be queried, perform local matching processing at the root node of the shared query tree, and repeat step 2.2) until all simple events in the event stream to be queried have been processed, where N is a natural number greater than or equal to 1;

[0078] 2.4) Determine whether the query node of the shared query tree is a leaf node. If it is a leaf node, the local match corresponding to the node is the query result.

[0079] The invention will be further explained below using a specific complex event query as an example.

[0080] like Figure 7 As shown, the three query events Q1, Q3, and Q4 are reconstructed to obtain three reconstructed query instances. These three reconstructed query instances are then merged using a shared prefix query node method to obtain the following result: Figure 8 The shared query tree shown.

[0081] When using Figure 8 When performing a query on event stream C0D1A2E3F4C5C6B7A8 using the shared query tree, the specific steps are as follows (see [link]). Figure 9 :

[0082] Read simple event C0 from the event stream, from B + Starting from the root node, perform local matching. If no match is found, store C0 in the C event buffer.

[0083] Read simple event D1 from the event stream, from B + Starting from the root node, perform local matching. If no match is found, store D1 in the D event buffer.

[0084] Read simple event A2 from the event stream, from B + Starting from the root node, a local matching process is performed, but no match is found, and its parent node C... - If no local match is found, store A2 in the A event buffer.

[0085] Read simple event E3 from the event stream, from B + Starting from the root node, perform local matching. If no match is found, store E3 in the E event buffer.

[0086] Read simple event F4 from the event stream, from B + Starting from the root node, a local matching process is performed. If no match is found, and since there is no query node for the F event, there is no cache for the F event, so F4 ​​is discarded.

[0087] Read simple events C5 and C6 sequentially from the event stream, starting from B. + Starting from the root node, perform local matching. If no match is found, store C5C6 in the C event buffer.

[0088] Read simple event B7 from the event stream, from B + Starting from the root node, perform local matching. If the match is successful, proceed to B. + The root node generates a local match B7, triggering C. - The node extracts simple events from the corresponding event buffer and performs local matching, where, in C - At the node, C5C6 matched successfully, while C0 did not match successfully, resulting in a new local match (C5B7)(C6B7), triggering A. + Nodes and A - The node extracts simple events from the corresponding event buffer and performs local matching in A. + At point A2, no match was found; there is currently no local match. - At the node, A2 matches successfully, obtaining a partial match (A2C5B7)(A2C6B7), triggering E. - Nodes and D - The node extracts simple events from the corresponding event buffer and performs local matching in E. - At node D, E3 did not match successfully; there is currently no local match. - At node D, D1 matched successfully, but (A2C5B7) failed to pass D. - The node verification ultimately yields a local match of (D1A2C6B7);

[0089] Read simple event A8 from the event stream, from B + Local matching was performed starting from the root node, but no match was found due to C. - The nodes have a local match, therefore, in simple event A8, in A... + Nodes perform local matching; A8 matches successfully, but (C6B7) fails the matching. + The node is verified, and therefore, the final local match is (C5B7A8).

[0090] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the following claims.

[0091] It should be understood that the present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.< / c>

Claims

1. A method for constructing a shared query tree for complex event queries, characterized in that, Includes the following steps: S1: Obtain query instances of multiple complex events, each of which is composed of multiple simple events; S2: Based on the statistical information of the simple events, the simple events in each query instance are reconstructed in order to obtain a reconstructed query instance. Each simple event in the reconstructed query instance corresponds to a query node. If the order of the simple events corresponding to a certain query node in the reconstructed query instance is reversed relative to the order before reconstruction, then the query node is defined as a reverse node; otherwise, it is defined as a forward node. S3: Based on the method of shared prefix query nodes, multiple reconstructed query instances are merged to obtain a shared query tree; In step S2, based on the statistical information of the simple events, the simple events in each query instance are reconstructed sequentially, specifically as follows: S201: Obtain the arrival rate r and condition selectivity s of the simple event, where the arrival rate r represents the probability of the simple event occurring, and s represents the probability of the simple event passing the condition constraint check of the complex event. S202: Combine the arrival rate r and conditional selectivity s of the simple event to obtain the selectivity. and with selectivity As statistical information; S203: Based on the statistical information, sort the simple events from smallest to largest to obtain a reconstructed order; In step S202, the arrival rate r and conditional selectivity s of the simple event are combined to obtain the selectivity. The specific formula is: ,and ,in, The label for the simple event. This is the set of conditional constraints for the query instance where the simple event occurs.

2. The method for constructing a shared query tree for complex event queries according to claim 1, characterized in that, In step S3, based on the method of shared prefix query nodes, multiple reconstructed query instances are merged to obtain a shared query tree, specifically: Find the longest common prefix among multiple reconstructed query instances and merge the longest common prefixes to obtain a shared query tree. The time window size matched by each node in the shared query tree is the maximum time window containing the query of that node.

3. A shared query tree for complex event queries, characterized in that, It is constructed using any one of the methods described in claims 1-2.

4. A method for complex event querying based on a shared query tree, characterized in that, The query method employs the shared query tree described in claim 3 for querying. The shared query tree has a root node, a parent node, and child nodes. The specific query steps are as follows: 1) Obtain the event stream to be queried; 2) Read the simple events in the event stream to be queried in sequence, and starting from the root node, perform one-to-one matching on the nodes in the form of breadth-first traversal on the shared query tree to obtain the query results.

5. The complex event query method based on a shared query tree according to claim 4, characterized in that, In step 2), simple events in the event stream to be queried are read sequentially, and starting from the root node, a breadth-first traversal is performed on each node in the shared query tree to obtain the query results. Specifically: 2.1) Read the Nth simple event from the event stream to be queried, and perform local matching processing starting from the root node of the shared query tree; 2.2) If the local matching at the root node fails, determine whether there is a local matching at the root node. If there is no local matching, store the Nth simple event in the cache area corresponding to the event type. If there is a local matching, traverse the shared query tree to see if there is a forward node corresponding to the event type of the Nth simple event. If there is, and there is a local matching in the parent node of the forward node corresponding to the event type of the Nth simple event, then perform local matching processing at the forward node. Otherwise, store the Nth simple event in the cache area corresponding to the event type. When the Nth simple event is processed locally at the forward node, if the match fails, the Nth simple event is stored in the cache of the corresponding event type. If the match succeeds, a new local match is generated, which triggers all child nodes with the forward node as the parent node to extract the events in the cache of their corresponding event type for local matching, generating local matches for each node. If a forward node exists in the newly generated local matching node, it will trigger all child nodes with the forward node as the parent node to extract the events in the cache of their corresponding event type for local matching, until all local matching processes are completed. 2.3) Read the (N+1)th simple event in the event stream to be queried, perform local matching processing at the root node of the shared query tree, and repeat step 2.2) until all simple events in the event stream to be queried have been processed, where N is a natural number greater than or equal to 1; 2.4) Determine whether the query node of the shared query tree is a leaf node. If it is a leaf node, the local match corresponding to the node is the query result.

Images