WO2023202497A1 - 用于全链路追踪事务的方法及原生分布式数据库 - Google Patents

用于全链路追踪事务的方法及原生分布式数据库 Download PDF

Info

Publication number
WO2023202497A1
WO2023202497A1 PCT/CN2023/088497 CN2023088497W WO2023202497A1 WO 2023202497 A1 WO2023202497 A1 WO 2023202497A1 CN 2023088497 W CN2023088497 W CN 2023088497W WO 2023202497 A1 WO2023202497 A1 WO 2023202497A1
Authority
WO
WIPO (PCT)
Prior art keywords
execution
span
transaction
distributed database
information
Prior art date
Application number
PCT/CN2023/088497
Other languages
English (en)
French (fr)
Inventor
杨志丰
Original Assignee
北京奥星贝斯科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京奥星贝斯科技有限公司 filed Critical 北京奥星贝斯科技有限公司
Publication of WO2023202497A1 publication Critical patent/WO2023202497A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing

Definitions

  • This application relates to the field of database technology, specifically, to a method for tracking transactions across all links and a native distributed database.
  • a distributed database is composed of multiple distributed data storage nodes. Each storage node is independent of each other and communicates with each other. In a distributed database, in order to execute a SQL, each storage node can communicate with each other through the RPC protocol. Therefore, in a distributed database, executing a SQL sometimes requires multiple components such as multiple storage nodes. Each component To perform a part of the operation, the operations performed on all components that the SQL passes through can constitute the complete execution process of the SQL.
  • this application provides a method and a native distributed database for full-link transaction tracking. Through the technical solution provided by this application, full-link tracking of transactions in distributed databases is achieved.
  • a method for full-link tracing of transactions in a distributed database wherein the transaction in the distributed database consists of at least one SQL, and the execution plan of each SQL Including at least one DFO, each DFO includes at least one operator, the method includes: during the execution process of the transaction to be tracked, determine the current execution stage to which the current execution action belongs, wherein the information transferred by the execution process includes the The Trace ID of the transaction to be tracked and the Span ID corresponding to the Span to which each executed execution stage included in the execution process belongs; record the Span information corresponding to the Span to which the current execution stage belongs locally, where the Span has The semantics of are defined based on the transaction execution logic in the distributed database, and each Span information is used to determine the reference relationship between the corresponding Span and other Spans belonging to the same transaction; After the execution of the transaction to be tracked is completed, Span information of each execution stage included in the transaction to be tracked is collected; and the full-link execution process of the transaction to be
  • a method for full-link tracking of transactions in a distributed database is also provided.
  • the method is executed by a storage node included in the distributed database, and the storage node
  • the transaction consists of at least one SQL, the execution plan of each SQL includes at least one DFO, and each DFO includes at least one operator.
  • the method includes: during the execution of the transaction to be tracked in the storage node, determine the current The current execution stage to which the execution action belongs, wherein the information transferred by the execution process includes the Trace ID of the transaction to be tracked and the Span ID corresponding to the Span to which each executed execution stage belongs; and the Span ID to which the current execution stage belongs
  • the Span information corresponding to the Span is recorded locally, so that the collection device collects the Span information of each execution stage of the transaction to be tracked in the storage node from the storage node, and collects the Span information based on the collected Span information to be tracked.
  • Each Span information of the transaction is used to determine the full-link execution process of the transaction to be tracked.
  • the semantics of the Span to which each execution node belongs is defined based on the transaction execution logic in the distributed database.
  • Each Span information is used To determine the reference relationship between the corresponding Span and other Spans belonging to the same transaction.
  • a native distributed database including multiple storage nodes.
  • the transaction executed in each storage node consists of at least one SQL.
  • the execution plan of each SQL includes at least one DFO.
  • Each DFO includes at least one operator, and each storage node includes an execution phase determination unit and a Span information recording unit.
  • the execution phase determination unit is configured to determine the current The current execution stage to which the execution action belongs, wherein the information transferred by the execution process includes the Trace ID of the transaction to be tracked and the Span ID corresponding to the Span to which each executed execution stage belongs; and the Span information recording unit is Configured to record locally the Span information corresponding to the Span to which the current execution phase belongs, so that the collection device collects from the storage node to which the Span information recording unit belongs, each of the transactions to be tracked executed in the storage node.
  • Span information in the execution stage and determine the full-link execution process of the transaction to be tracked based on the collected Span information of the transaction to be tracked, where the semantics of the Span to which each execution node belongs is based on the distribution
  • the transaction execution logic in the database is defined, and each Span information is used to determine the reference relationship between the corresponding Span and other Spans in the same transaction.
  • an electronic device including: at least one processor, a memory coupled to the at least one processor, and a computer program stored on the memory, the at least one processor The computer program is executed to implement the method for full-link tracing of transactions in a distributed database as described in any one of the above.
  • a computer-readable storage medium which stores a computer program, When the computer program is executed by the processor, the method for full-link tracing of transactions in a distributed database is implemented as described above.
  • a computer program product including a computer program that, when executed by a processor, implements any one of the above for full-link tracking of transactions in a distributed database.
  • Figure 1 shows a schematic diagram of an example of a distributed database.
  • Figure 2 shows a schematic diagram of an example of interaction between the OceanBase database and an application.
  • Figure 3 shows a flow chart of an example of a method for full-link tracing of transactions in a distributed database according to an embodiment of the present application.
  • Figure 4 shows a schematic diagram of an example of a tree structure corresponding to an SQL execution plan.
  • FIG. 5 shows a schematic diagram showing an example of a full-link execution process of a transaction according to an embodiment of the present application.
  • Figure 6 shows a flow chart of an example of a method for full-link tracing of transactions in a distributed database according to an embodiment of the present application.
  • Figure 7 shows a block diagram of an example of a native distributed database according to an embodiment of the present application.
  • Figure 8 shows a block diagram of an electronic device used to implement a full-link tracking method for transactions according to an embodiment of the present application.
  • the term "includes” and variations thereof represent an open term meaning “including, but not limited to.”
  • the term “based on” means “based at least in part on.”
  • the terms “one embodiment” and “an embodiment” mean “at least one embodiment.”
  • the term “another embodiment” means “at least one other embodiment”.
  • the terms “first”, “second”, etc. may refer to different or the same object. Other definitions may be included below, whether explicit or implicit. The definition of a term is consistent throughout this specification unless the context clearly dictates otherwise.
  • FIG. 1 shows a schematic diagram of an example of a distributed database 1 .
  • the distributed database 1 may include multiple storage nodes 10-1 to 10-4.
  • Storage nodes 10-1 to 10-4 are distributed storage nodes, and each storage node can independently perform data processing and data storage. It should be noted that the example shown in FIG. 1 is only illustrative. In other embodiments, the distributed database 1 may include more or fewer storage nodes.
  • the distributed database 1 can adopt the share nothing architecture, such as the OceanBase database.
  • data is stored distributedly in various storage nodes.
  • data can be divided into multiple data partitions (also called data partitions), and the divided data partitions are stored in different storage nodes.
  • Each storage node can store one or more data partitions.
  • the CPU resources and IO resources required for data access on each storage node occur locally and are executed by the storage node.
  • Figure 2 shows a schematic diagram of an example of interaction between the OceanBase database and an application.
  • the OceanBase database can include multiple OBServers.
  • Each OBServer is equivalent to a storage node and is used to provide data storage and data processing.
  • Each OBServer included in the OceanBase database can communicate with each other through the RPC protocol. It should be noted that the three OBServers in Figure 2 are only examples, and in other embodiments, more or fewer OBServers may be included.
  • OBProxy OceanBase Database Proxy, ODP.
  • OBProxy is a stateless proxy server.
  • the OceanBase database can communicate with multiple OBProxys. It should be noted that the three OBProxys in Figure 2 are only used as examples, and in other embodiments, more or fewer OBProxys can be deployed.
  • OBProxy connects the application and the OceanBase database at the same time. OBProxy is used to receive SQL requests sent by the application, forward the SQL requests to the target OBServer, and feed back the execution results to the application. There is no connection between each OBProxy, and a load balancing cluster can be formed through F5/SLB. Each OBProxy can be deployed on the same physical machine as OBServer, or can also be deployed on the application server.
  • Figure 3 shows a method for full-link tracing of transactions in a distributed database according to an embodiment of the present application.
  • a transaction is composed of all operations performed between the start of the transaction and the end of the transaction. Transactions in the distributed database need to be executed via the distributed database. In one example, most of the operations included in the transaction in the distributed database are executed in the distributed database. For example, the application initiates a SQL request, and the distributed database executes the SQL.
  • a transaction in a distributed database can be an atomic execution unit composed of a series of SQLs. That is, a transaction in a distributed database includes at least one SQL. At least one SQL constituting a transaction can be executed in sequence to form a complete execution logic. process.
  • each SQL can be equivalent to a physical execution plan, and SQL can be executed according to the corresponding execution plan.
  • Each SQL execution plan can include at least one DFO (data flow object).
  • DFO is a fragment of the SQL execution plan and can be called and executed separately.
  • the execution plan of SQL can be equivalent to a DAG (Directed Acyclic Graph) composed of multiple sub-plans, and each sub-plan is a DFO.
  • Each DFO as a subplan may include at least one operator, and the operation type corresponding to the operation performed by each operator is determined.
  • Operators are the basic building blocks of DFO, and therefore the basic building blocks of SQL execution plans.
  • the execution plan of each SQL can be a state tree composed of multiple operators. Each operator in the state tree can be used to describe the basic operation corresponding to specific SQL semantics. For example, TABLE SCAN operator, EXCHANGE operator, JOIN operator, TABLE DELETE operator, GROUP BY operator, etc.
  • FIG 4 shows a schematic diagram of an example of a state tree corresponding to an SQL execution plan.
  • each circle in the state tree represents an operator. Multiple consecutive operators can form a sub-plan, that is, a DFO.
  • the first operator (LIMIT) and the second operator Operators (OC IN SORT) can form a DFO
  • the third operator (OUT.1:EX10004(4)) to the eighth operator (IN.SORT) can form another DFO.
  • the state tree composed of all operators shown in Figure 4 is the execution plan of SQL.
  • the distributed database targeted by this application may include a native distributed database.
  • the native distributed database targeted by this application may include OceanBase database.
  • the current execution stage to which the current execution action belongs can be determined.
  • each transaction executed in the distributed database may be identified as a transaction to be tracked.
  • some transactions in the distributed database can be determined as transactions to be tracked, and then only some transactions in the distributed database can be tracked. Line tracking.
  • each transaction to be executed in the distributed database can be sampled, and then the sampled transactions are determined to be the transactions to be tracked.
  • a second specified number of transactions can be sampled from the first specified number of transactions to be executed in each batch, the second specified number is smaller than the first specified number, and the transactions to be executed included in each batch are different. .
  • sampling can be based on time. In one example, sampling may be performed every specified time period, and the number of transactions sampled each time may be a third specified number. In another example, a fourth specified number of samples may be performed within each time period, and the number of transactions per sample may be a fifth specified number. In another sampling method, sampling can be done in a random manner.
  • each execution stage in the transaction execution process can be a continuous process.
  • Each execution stage can include multiple execution actions.
  • the multiple execution actions are executed in sequence to form a set of execution logic.
  • the resulting Execution logic is the execution logic of the execution phase to which it belongs.
  • Multiple execution actions belonging to the same execution phase may include a start execution action and an end execution action.
  • the start execution action may indicate the beginning of the execution phase to which it belongs, and the end execution action may indicate the end of the execution phase to which it belongs.
  • the execution process of each SQL can be regarded as a complete execution phase, and the execution phase of each SQL can include a parsing phase, an optimization phase, a specific execution phase, etc.
  • the execution process of each DFO can be used as an execution stage, and the execution process of each operator can also be used as an execution stage.
  • a Trace ID can be generated when the transaction is initiated.
  • the Trace ID can be used to identify a full-link tracking process of the transaction.
  • the Trace ID is always carried in the entire request call chain, and the upstream service carries the Trace ID and passes it to the downstream service.
  • the complete execution path of the transaction can be marked through Trace ID.
  • the information passed can also include the Span ID corresponding to the Span to which each execution stage has been executed.
  • Span represents a logical unit with a start time and execution duration. Logical causal relationships can be established between various spans through nesting or sequential arrangement.
  • Each Span has semantics, and the semantics of a Span can be defined according to the transaction execution logic in the distributed database.
  • the transaction execution logic of a transaction can be represented by SQL, DFO, operators, etc.
  • the semantics of Span can be defined based on SQL, DFO, operators, etc., for example, for SQL type Span, for DFO type Span , and for operator types Span et al.
  • each span determines the type of the span. Different types of spans can have different semantics and play different roles.
  • Each type of Span can be standardized, and the standardized Span can be directly applied to distributed database application scenarios.
  • the operation name of the Span ie, Operation Name
  • the Span Tag can be a collection of Span tags and can be used to represent the attributes of the Span.
  • the operation name and Span Tag of each Span can be used to characterize the semantics of the Span. After the Span operation name and Span Tag are determined, the semantics of the Span are also determined.
  • corresponding spans can be set for each execution stage included in the transaction execution process, and spans with different semantics can be set for different execution stages.
  • the semantics of the Span corresponding to each execution phase are determined based on the position of the execution phase in the transaction execution logic. For example, for the execution phase of one of the DFOs included in SQL, you can set the Span corresponding to the execution phase to be the Span for the DFO. The process represented by this Span is the execution process of DFO.
  • Each Span corresponds to a Span ID
  • the Span ID corresponds to the Span one-to-one.
  • the Span ID corresponding to each Span is generated by the execution phase of the Span and is used to identify the internal calling status of the execution phase. After each execution phase is completed, the Span ID of the execution phase is passed to the downstream execution phase together with the Trace ID. Therefore, the complete execution process of the transaction to be tracked can be determined through the Trace ID and the Span ID corresponding to each execution stage.
  • the execution subject that determines the current execution phase may be an execution device used to execute the current execution phase.
  • the execution of the current execution phase is determined.
  • the subjects can be different.
  • the transaction to be tracked is executed via a distributed database, and the current execution stage can be determined by the distributed database.
  • the application communicates with a distributed database, and the transaction to be tracked can be initiated by the application and executed in the distributed database, so that the distributed database performs operations that determine the current execution stage.
  • the distributed database can communicate with a proxy server.
  • the proxy server is used to forward transaction requests initiated by the driver deployed in the client to the distributed database, so that the execution process of each transaction can go through the driver separately.
  • proxy server and distributed database can be OBProxy.
  • the transaction to be tracked may be initiated by a driver deployed in the client and specifically executed in the proxy server and distributed database. Then when the current execution phase is in the proxy server, it is used to execute the determination of the current
  • the execution subject of the operations in the pre-execution phase may be a proxy server.
  • the execution subject used to perform operations that determine the current execution stage may be the distributed database.
  • the Span information corresponding to the Span to which the current execution phase belongs can be recorded locally.
  • each Span can generate corresponding Span information after the execution is completed.
  • Each Span information can be used to determine the reference relationship between the corresponding Span and other Spans in the same transaction.
  • References Relationships can include parent-child relationship (Child_Of) and following relationship (Follows_From), etc.
  • the parent-child relationship means that the execution phase of one Span occurs during the execution phase of another Span.
  • the Span generated by the called party and the Span generated by the calling party can form a parent-child relationship.
  • a Span of the SQL Insert operation and the Span of the Insert Row method of the database storage engine form a parent-child relationship.
  • the following relationship means that the execution phase of one Span is followed by the execution phase of another Span, which is used to describe the sequential execution relationship.
  • the execution phase corresponding to the Span executed first does not depend on the execution results generated by the execution phase corresponding to the Span executed later.
  • each Span corresponds to a variety of status information: operation name, start time (Start Timestamp), end time (End Timestamp), Span Tag, Span Logs, SpanContext, References, etc.
  • Span Logs can be a set of Span logs.
  • SpanContext can include global context information for full-link tracing.
  • SpanContext can include Trace ID and the Span ID corresponding to each Span.
  • References are used to represent the reference relationships between spans.
  • the reference relationships represented by References can include parent-child relationships and follower relationships.
  • the corresponding Span information can be obtained according to each status information of the Span. That is, the Span information of each Span can include the operation name, start time, end time, Span Tag, Span Logs, SpanContext and References of the Span. Different Span Each state information included in the corresponding Span information may be different. For example, compared with Span for DFO, the operation name, start time, end time, etc. in the Span information are different.
  • the execution order of the execution phases corresponding to each span can be determined, and then the full-link execution process of the transaction can be determined.
  • the execution subject that records Span information is the execution device of the current execution phase.
  • the Span information is recorded by OBProxy; the execution device of the current execution phase is distributed
  • the distributed database records Span information.
  • Each storage node in the distributed database can be used as an execution subject to perform operations independently.
  • the execution device in the current execution stage is a storage node in the distributed database, the storage node serves as the execution subject to record Span information.
  • Span information can be recorded in local log files in the form of logs. For example, in OBProxy, Span information can be recorded in OBProxy.log. In each OBServer included in the OceanBase database, Span information can be recorded in OBServer.log.
  • the execution subject of the current execution phase can cache Span information corresponding to multiple spans of the transaction to be tracked in the context of each session.
  • the context of the session can cache the Span information of the SQL when the SQL starts to execute.
  • This context can cache the Span information of SQL and the Span information of DFO at the same time.
  • the context can cache the Span information of SQL, the Span information of DFO and the Span information of the operator at the same time.
  • the Span information of that execution phase can be recorded locally and the cache in the session context can be updated. For example, when an operator is executed, the operator's Span information can be recorded locally, and the operator's Span information cached in the session context can be deleted.
  • the Span information of the DFO can be recorded locally, and the Span information of the DFO cached in the session context can be deleted.
  • the SQL execution is completed, the SQL Span information can be recorded locally, and the SQL Span information cached in the session context can be deleted.
  • Span information By recording the Span information locally, it avoids transferring the Span information during remote calls after obtaining the Span information in each execution stage, thereby reducing the resource overhead during transaction execution, saving resources and improving the execution efficiency of the transaction.
  • each execution stage included in the transaction may have the attribute of execution granularity, and the execution granularity may be divided according to the transaction execution logic.
  • the transaction execution logic of a transaction can be represented by SQL, DFO, operators, etc.
  • the execution granularity of the transaction can be represented by SQL, DFO, operators, etc.
  • SQL, DFO and Operators can each represent an execution granularity, that is, the divided execution granularity can include SQL granularity, DFO granularity, and operator granularity.
  • the granularity sizes of different execution granularities can be different.
  • the execution granularity corresponding to the execution phase is greater than the execution granularity corresponding to the sub-execution phase.
  • SQL granularity is greater than DFO granularity
  • DFO granularity is greater than operator granularity.
  • the Span to which each execution stage belongs can also correspond to an execution granularity, and the execution granularity corresponding to each Span is an execution granularity attribute of the Span.
  • the execution logic of each execution stage included in the transaction can be determined.
  • the Span corresponding to each execution stage can be determined, and the execution granularity attributes of each execution stage can be determined, so that each execution stage The execution granularity attributes of the corresponding Span can be determined.
  • the execution granularity corresponding to the current execution stage may be determined. Then, it can be determined whether the execution granularity corresponding to the current execution stage is greater than the specified execution granularity threshold.
  • the specified execution granularity threshold can be any execution granularity among transaction-specific execution granularities.
  • the Span information corresponding to the Span to which the current execution stage belongs can be recorded locally.
  • the execution granularity corresponding to the current execution phase is not greater than the execution granularity threshold, the Span information of the current execution phase may not be recorded.
  • the Span information of some execution stages can be recorded in a targeted manner according to the execution granularity threshold. There is no need to record the Span information of all execution stages included in the transaction, thus avoiding the generation of data for full-link tracking. The amount is too large, thereby reducing the performance impact of the generated full-link tracking data on the distributed database, and reducing the amount of data processing in subsequent processing of Span information.
  • Span information of each execution stage included in the transaction to be tracked can be collected.
  • a collection device external to the distributed database can be used to collect Span information of each execution stage included in the transaction to be tracked.
  • the collection device can be connected to each device through which the transaction to be traced passes, so as to collect Span information of the transaction to be traced from each device.
  • Span information is stored in OBProxy and the distributed database respectively, and the collection device can collect Span information of the transaction to be tracked from OBProxy and the distributed database respectively.
  • each storage node in the distributed database can run independently. Therefore, each storage node can store the Span information corresponding to the executed execution phase locally. Therefore, when the collection device connects to the distributed database, the The collection device can be connected to each storage node in the distributed database respectively, so that the collection device can collect the stored Span information from each storage node.
  • the collection device can be a device that matches the distributed database, and the collection device can recognize various semantics in the distributed database, such as SQL, DFO, operators, etc. in the distributed database.
  • the collection device may include a collection unit, a storage unit, and a display unit.
  • the collection unit sends the collected Span information to the storage unit for storage.
  • the display unit may execute the full link of the transaction based on obtaining the Span information from the storage unit. Demonstrate the process.
  • the collection unit can be ob_trace_agent
  • the storage unit can be OCP database
  • the display unit can be OCP UI.
  • the collection device may be a universal collection device.
  • the universal collection device can recognize the semantics of universal codes and can be applied to data collection in various application scenarios.
  • the collection unit in the general collection device can be Jaeger Agent and Jaeger Collector
  • the storage unit in the general collection device can be Jaeger DB
  • the display unit in the general collection device can be Jaeger UI.
  • the full-link execution process of the transaction to be tracked can be determined based on the collected Span information.
  • the reference relationship and execution order relationship between each Span can be determined based on the reference relationship between the corresponding Span represented by each Span information and other Spans belonging to the same transaction. Then, based on each Span, The reference relationship and execution order relationship between spans can correspondingly determine the execution order of each execution stage. According to the execution order, each execution stage can form the full-link execution process of the transaction to be tracked.
  • the execution stages corresponding to the span information can be arranged in the time dimension to show the full-link execution process of the transaction to be tracked.
  • the execution time period of the corresponding execution phase can be determined based on the start time and end time in each Span information.
  • the execution time period corresponding to the child Span is included in the execution time period corresponding to the parent Span, that is, the start time of the child Span is greater than the start time of the parent Span, and the end time of the child Span is less than The end time of the parent Span.
  • the execution time period of the upstream span is before the execution time period of the downstream span.
  • each execution stage it can be represented by a time bar, and each time bar can be determined by the start time, end time and duration.
  • the time bar corresponding to the execution stage executed first is ranked before the time bar corresponding to the execution stage executed later.
  • the time bar corresponding to the execution phase of the child Span is included in the time bar corresponding to the execution phase of the parent Span.
  • FIG. 5 shows a schematic diagram showing an example of a full-link execution process of a transaction according to an embodiment of the present application.
  • the transaction includes 3 SQLs: SQL1, SQL2 and SQL3.
  • SQL1 includes DFO1 and DFO2, and there is a parent-child relationship between SQL1 and DFO1 and DFO2.
  • DFO2 includes operator 1 and operator 2.
  • the relationship between DFO2 and operator 1 and operator 2 is a parent-child relationship, and the relationship between operator 1 and operator 2 is a follower relationship.
  • the full-link execution process of the transaction composed of SQL1, SQL2, SQL3, DFO1, DFO2, operator 1 and operator 2 is shown in Figure 5.
  • the distributed database can communicate with a proxy server, and the proxy server can also communicate with a client.
  • the external network structure of a distributed database can be shown in Figure 2.
  • each transaction to be executed can be initiated by a driver deployed in the client, so that the execution process of each transaction can pass through the driver deployed in the client, the proxy server, and the distributed database respectively.
  • a corresponding Trace ID can be generated for the transaction to be executed.
  • the Trace ID is always passed along with the execution process.
  • the driver can perform corresponding operations in the execution phase to generate corresponding Span information, which can include Trace ID.
  • the driver can send the Span information obtained locally to the proxy server, and the proxy server records the Span information received from the driver in the proxy server.
  • the driver does not record the locally generated Span information locally, but records it in the proxy server.
  • the client's Span information can be collected from the proxy server, avoiding the need to intrude into the client's Span information.
  • the client's Span information can only be collected in the application.
  • the driver can piggyback locally generated Span information to the proxy server.
  • the driver can determine a piece of information from other information that the driver needs to send to the proxy server, and add the Span information to an additional field of the determined information.
  • the Span information is also sent to the proxy server.
  • the determined information is the information that the driver will definitely send to the proxy server, for example, the transaction request information that the driver sends to the proxy server.
  • the driver can determine the next information sent by the driver to the proxy server as information carrying Span information.
  • the driver sends the Span information to the proxy server in piggyback mode. There is no need to send the Span information to the proxy server separately to avoid occupying the client's resources.
  • Figure 6 shows a flow chart of an example 600 of a method for full-link tracing of transactions in a distributed database according to an embodiment of the present application.
  • the method shown in Figure 6 can be executed by a storage node included in a distributed database.
  • the transaction in the storage node consists of at least one SQL.
  • the execution plan of each SQL includes at least one DFO, and each DFO includes at least one operator.
  • the distributed database may be a native distributed database.
  • the current execution stage to which the current execution action belongs is determined.
  • the information passed during the execution process includes the Trace ID of the transaction to be tracked and the Span ID corresponding to the Span to which each executed execution stage belongs.
  • the executed execution stages include the executed execution stages in the storage node and other storage nodes and Execution phases executed in the device.
  • the Span information corresponding to the Span to which the current execution phase belongs is recorded locally, so that the collection device collects the Span information of each execution phase of the transaction to be tracked in the storage node from the storage node, and collects the Span information according to the collected Span information to be tracked. Track each Span information of the transaction to determine the full-link execution process of the transaction to be tracked.
  • the semantics of the Span to which each execution node belongs is defined based on the transaction execution logic in the distributed database. Each Span information is used to determine the corresponding The reference relationship between a Span and other Spans belonging to the same transaction.
  • recording the Span information corresponding to the Span to which the current execution phase belongs locally includes: when the execution granularity corresponding to the current execution phase is greater than the execution granularity threshold, recording the Span information corresponding to the Span to which the current execution phase belongs locally.
  • the execution granularity is divided according to the transaction execution logic, and the Span to which each execution stage belongs corresponds to an execution granularity.
  • Figure 7 shows a block diagram of an example of a native distributed database 700 according to an embodiment of the present application.
  • the native distributed database shown in Figure 7 includes multiple storage nodes.
  • the transactions executed in each storage node consist of at least one SQL.
  • the execution plan of each SQL includes at least one DFO, and each DFO includes at least one operator.
  • Each storage node includes an execution phase determination unit 710 and a Span information recording unit 720. It should be noted that the native distributed database shown in Figure 7 includes two storage nodes only as an example. In other embodiments, the native distributed database may include more or less storage nodes.
  • the execution phase determination unit 710 may be configured to determine the current execution phase to which the current execution action belongs during the execution of the transaction to be tracked in the native distributed database. Among them, the information passed during the execution process includes the Trace ID of the transaction to be tracked and the Span ID corresponding to the Span to which each execution stage has been executed.
  • the Span information recording unit 720 may be configured to record the Span corresponding to the Span to which the current execution phase belongs. The information is recorded locally, so that the collection device collects the Span information of each execution stage of the transaction to be tracked in the storage node from the storage node to which the Span information recording unit belongs, and based on the collected Span information of the transaction to be tracked To determine the full-link execution process of the transaction to be tracked.
  • the semantics of the Span to which each execution node belongs is defined based on the transaction execution logic in the distributed database, and each Span information is used to determine the reference relationship between the corresponding Span and other Spans belonging to the same transaction.
  • the Span information recording unit 720 may also be configured to: when the execution granularity corresponding to the current execution phase is greater than the execution granularity threshold, locally record the Span information corresponding to the Span to which the current execution phase belongs, wherein the execution granularity is based on Transaction execution logic is divided, and the Span to which each execution stage belongs corresponds to an execution granularity.
  • the device of this application for full-link tracking of transactions in a distributed database can be implemented by hardware, software, or a combination of hardware and software. Taking software implementation as an example, as a device in a logical sense, it is formed by reading the corresponding computer program instructions in the memory into the memory and running them through the processor of the device where it is located. In this application, the device for full-link tracking of transactions in a distributed database may be implemented using electronic equipment, for example.
  • FIG. 8 shows a block diagram of an electronic device 800 used to implement a full-link tracking method for transactions according to an embodiment of the present application.
  • the electronic device 800 may include at least one processor 810 , storage (eg, non-volatile memory) 820 , memory 830 , and communication interface 840 , and at least one processor 810 , memory 820 , memory 830 , and communication interface 840 .
  • Interfaces 840 are connected together via bus 850.
  • At least one processor 810 executes at least one computer readable instruction stored or encoded in memory (ie, the elements described above implemented in software).
  • computer-executable instructions are stored in the memory, which when executed cause at least one processor 810 to: determine the current execution stage to which the current execution action belongs during execution of the transaction to be tracked in the storage node; and The Span information corresponding to the Span to which the current execution phase belongs is recorded locally, so that the collection device collects the Span information of each execution phase of the transaction to be traced in the storage node from the storage node, and collects the Span information according to the collected Span to be traced.
  • Each Span information of the transaction is used to determine the full-link execution process of the transaction to be tracked.
  • the semantics of the Span to which each execution node belongs is defined based on the transaction execution logic in the distributed database.
  • Each Span information is used to determine the corresponding References between a span and other spans belonging to the same transaction relation.
  • a program product such as a machine-readable medium
  • the machine-readable medium may have instructions (i.e., the above elements implemented in software form) that, when executed by a machine, cause the machine to perform the various operations and functions described above in connection with FIGS. 1-7 in various embodiments of this specification. .
  • a system or device equipped with a readable storage medium may be provided, on which the software program code that implements the functions of any of the above embodiments is stored, and the computer or device of the system or device may The processor reads and executes the instructions stored in the readable storage medium.
  • the program code itself read from the readable medium can implement the functions of any one of the above embodiments, and therefore the machine-readable code and the readable storage medium storing the machine-readable code constitute the present application. a part of.
  • the computer program code required to operate each part of this manual can be written in any one or more programming languages, including object-oriented programming languages, such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB, NET and Python, etc., conventional procedural programming languages such as C language, Visual Basic 2003, Perl, COBOL2002, PHP and ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages.
  • the program code may run on the user's computer, as a stand-alone software package, or partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server.
  • the remote computer can be connected to the user computer via any form of network, such as a local area network (LAN) or a wide area network (WAN), or to an external computer (e.g. via the Internet), or in a cloud computing environment, or as Service usage, such as Software as a Service (SaaS).
  • LAN local area network
  • WAN wide area network
  • SaaS Software as a Service
  • Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tape, non- Volatile memory cards and ROM.
  • the program code can be downloaded from the server computer or the cloud by the communication network.
  • the device structure described in the above embodiments may be a physical structure or a logical structure, that is, some units may be implemented by the same physical entity, or some units may be implemented by multiple physical entities, or may be implemented by multiple Some components in separate devices are implemented together.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请提供了用于全链路追踪事务的方法及原生分布式数据库。其中，分布式数据库中的事务由至少一个SQL构成，每个SQL的执行计划包括至少一个DFO，每个DFO包括至少一个算子。在该方法中，在待追踪事务的执行过程中，确定当前执行动作所属的当前执行阶段；将当前执行阶段所属的Span对应的Span信息记录在本地；在待追踪事务执行完成后，采集待追踪事务所包括的各个执行阶段的Span信息；以及根据所采集的各个Span信息来确定待追踪事务的全链路执行过程。

Description

用于全链路追踪事务的方法及原生分布式数据库 技术领域
本申请涉及数据库技术领域，具体地，涉及用于全链路追踪事务的方法及原生分布式数据库。
背景技术
分布式数据库由多个分布式数据存储节点构成，各个存储节点之间相互独立又相互之间通信连接。在分布式数据库中，为了执行一条SQL，各个存储节点之间可以通过RPC协议进行通信，因此，在分布式数据库中，执行一条SQL有时需要经过多个存储节点等多个组件，每个组件上执行一部分操作，SQL所经过的所有组件上所执行的操作可以构成该SQL的完整执行过程。
目前，在传统的单机数据库中，SQL仅在一个机器上执行，因此可以通过记录该SQL的执行过程中各个动作的执行时间点便能够方便地对该SQL的执行过程进行全链路追踪。然而，对于分布式数据库而言，由于SQL的执行过程需要经过多个组件，这使得对该SQL的追踪较困难。此外，由于各个组件的时间存在差异，导致无法根据各个动作的时间点来进行全链路跟踪。因此，如何实现在分布式数据库中对事务进行全链路跟踪是亟待解决的问题。
发明内容
鉴于上述，本申请提供了用于全链路追踪事务的方法及原生分布式数据库。通过本申请提供的技术方案，实现了对分布式数据库中的事务进行全链路追踪。
根据本申请的一个方面，提供了一种用于对分布式数据库中的事务进行全链路追踪的方法，其中，所述分布式数据库中的事务由至少一个SQL构成，每个SQL的执行计划包括至少一个DFO，每个DFO包括至少一个算子，所述方法包括：在待追踪事务的执行过程中，确定当前执行动作所属的当前执行阶段，其中，所述执行过程传递的信息包括所述待追踪事务的Trace ID以及所述执行过程包括的已执行的各个执行阶段所属的Span对应的Span ID；将所述当前执行阶段所属的Span对应的Span信息记录在本地，其中，所述Span具有的语义是根据所述分布式数据库中的事务执行逻辑定义的，每个Span信息用于确定对应的Span与所属同一事务中的其他Span之间的引用关系； 在所述待追踪事务执行完成后，采集所述待追踪事务所包括的各个执行阶段的Span信息；以及根据所采集的各个Span信息来确定所述待追踪事务的全链路执行过程。
根据本申请的另一方面，还提供一种用于对分布式数据库中的事务进行全链路追踪的方法，所述方法由所述分布式数据库包括的存储节点来执行，所述存储节点中的事务由至少一个SQL构成，每个SQL的执行计划包括至少一个DFO，每个DFO包括至少一个算子，所述方法包括：在待追踪事务在所述存储节点中的执行过程中，确定当前执行动作所属的当前执行阶段，其中，所述执行过程传递的信息包括所述待追踪事务的Trace ID以及已执行的各个执行阶段所属的Span对应的Span ID；以及将所述当前执行阶段所属的Span对应的Span信息记录在本地，以使采集设备从所述存储节点中采集所述待追踪事务在所述存储节点中所执行的各个执行阶段的Span信息，并根据所采集的所述待追踪事务的各个Span信息来确定所述待追踪事务的全链路执行过程，其中，各个执行节点所属的Span具有的语义是根据所述分布式数据库中的事务执行逻辑定义的，每个Span信息用于确定对应的Span与所属同一事务中的其他Span之间的引用关系。
根据本申请的另一方面，还提供一种原生分布式数据库，包括多个存储节点，各个存储节点中所执行的事务由至少一个SQL构成，每个SQL的执行计划包括至少一个DFO，每个DFO包括至少一个算子，所述各个存储节点包括执行阶段确定单元和Span信息记录单元，所述执行阶段确定单元，被配置为在待追踪事务在原生分布式数据库中的执行过程中，确定当前执行动作所属的当前执行阶段，其中，所述执行过程传递的信息包括所述待追踪事务的Trace ID以及已执行的各个执行阶段所属的Span对应的Span ID；以及所述Span信息记录单元，被配置为将所述当前执行阶段所属的Span对应的Span信息记录在本地，以使采集设备从所述Span信息记录单元所属的存储节点中采集所述待追踪事务在该存储节点中所执行的各个执行阶段的Span信息，并根据所采集的所述待追踪事务的各个Span信息来确定所述待追踪事务的全链路执行过程，其中，各个执行节点所属的Span具有的语义是根据所述分布式数据库中的事务执行逻辑定义的，每个Span信息用于确定对应的Span与所属同一事务中的其他Span之间的引用关系。
根据本申请的另一方面，还提供一种电子设备，包括：至少一个处理器，与所述至少一个处理器耦合的存储器，以及存储在所述存储器上的计算机程序，所述至少一个处理器执行所述计算机程序来实现如上述任一所述的用于对分布式数据库中的事务进行全链路追踪的方法。
根据本申请的另一方面，还提供一种计算机可读存储介质，其存储有计算机程序， 所述计算机程序被处理器执行时实现如上所述的用于对分布式数据库中的事务进行全链路追踪的方法。
根据本申请的另一方面，还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上任一所述的用于对分布式数据库中的事务进行全链路追踪的方法。
附图说明
通过参照下面的附图，可以实现对于本申请实施例内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。
图1示出了分布式数据库的一个示例的示意图。
图2示出了OceanBase数据库与应用交互的一个示例的示意图。
图3示出了根据本申请实施例的用于对分布式数据库中的事务进行全链路追踪的方法的一个示例的流程图。
图4示出了SQL执行计划对应的树状结构的一个示例的示意图。
图5示出了根据本申请实施例的展示事务的全链路执行过程的一个示例的示意图。
图6示出了根据本申请实施例的用于对分布式数据库中的事务进行全链路追踪的方法的一个示例的流程图。
图7示出了根据本申请实施例的原生分布式数据库的一个示例的方框图。
图8示出了本申请实施例的用于实现事务进行全链路追踪方法的电子设备的方框图。
具体实施方式
以下将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本申请实施例内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。
如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。
图1示出了分布式数据库1的一个示例的示意图。
如图1所示，分布式数据库1可以包括多个存储节点10-1到10-4。存储节点10-1到10-4为分布式存储节点，每个存储节点可以独立地进行数据处理和数据存储。需要说明的是，图1示出的示例仅仅是例示性的。在其它实施例中，分布式数据库1可以包括更多或更少的存储节点。
分布式数据库1例如可以采用share nothing架构，比如，OceanBase数据库。在这种分布式数据库中，数据分布式地存储在各个存储节点中。例如，数据可以被分割为多个数据分区(也可以称为数据分块)，所分割出的数据分区分别存储到不同的存储节点中。每个存储节点可以存储一个或多个数据分区。每个存储节点上涉及的数据访问所需要的CPU资源和IO资源都发生在本地，由该存储节点执行。
图2示出了OceanBase数据库与应用交互的一个示例的示意图。
如图2所示，OceanBase数据库可以包括有多个OBServer，每个OBServer相当于一个存储节点，用于提供数据存储和数据处理。OceanBase数据库所包括的各个OBServer之间可以通过RPC协议进行通信。需要说明的是，图2中的三个OBServer仅作为示例，在其它实施例中，可以包括更多或更少的OBServer。
应用可以通过OBProxy(OceanBase Database Proxy，ODP)来访问OceanBase数据库，OBProxy是无状态的代理服务器，OceanBase数据库可以与多个OBProxy通信连接。需要说明的是，图2中的三个OBProxy仅作为示例，在其它实施例中，可以部署更多或更少的OBProxy。
OBProxy同时连接应用和OceanBase数据库，OBProxy用于接收应用发送的SQL请求，并将SQL请求转发至目标OBServer上，并将执行结果反馈给应用。各个OBProxy之间无联系，可以通过F5/SLB组成负载均衡集群。各个OBProxy可以与OBServer部署在同一台物理机上，或者还可以部署在应用服务器上。
图3示出了根据本申请实施例的用于对分布式数据库中的事务进行全链路追踪的 方法的一个示例300的流程图。
在本申请中，事务(Transaction)是由事务开始和事务结束之间执行的全部操作组成。分布式数据库中的事务需要经由分布式数据库来执行，在一个示例中，分布式数据库中的事务所包括的大部分操作在分布式数据库中执行。例如，应用发起SQL请求，分布式数据库执行该SQL。
分布式数据库中的事务可以是由一系列的SQL组成的原子执行单元，即，分布式数据库中的事务包括至少一个SQL，构成一个事务的至少一个SQL可以按序执行，形成一个完整的执行逻辑过程。
每个SQL的执行可以相当于是一个物理执行计划，SQL可以按照对应的执行计划来执行。每个SQL的执行计划可以包括至少一个DFO(data flow object)，DFO是SQL的执行计划中的一个片段，可以被单独调用执行。SQL的执行计划可以相当于多个子计划构成的DAG(Directed Acyclic Graph)，每个子计划就是一个DFO。
作为子计划的每个DFO可以包括至少一个算子(operator)，每个算子所执行的操作对应的操作类型是确定的。算子是构成DFO的基本组成单元，从而也是构成SQL执行计划的基本组成单元。每个SQL的执行计划可以是由多个算子组成的状态树，状态树中的每个算子可以用来描述与具体的SQL语义对应的基础操作。比如，TABLE SCAN算子、EXCHANGE算子、JOIN算子、TABLE DELETE算子、GROUP BY算子等。
图4示出了SQL执行计划对应的状态树的一个示例的示意图。如图4所示，状态树中的每个圆圈表示一个算子，连续的多个算子之间可以构成一个子计划，即构成一个DFO，比如，第一个算子(LIMIT)和第二个算子(OC IN SORT)可以构成一个DFO，第三个算子(OUT.1:EX10004(4))至第八个算子(IN.SORT)可以构成另一个DFO。图4所示的所有算子构成的状态树是SQL的执行计划。
在一个示例中，本申请所针对的分布式数据库可以包括原生分布式数据库。进一步地，本申请所针对的原生分布式数据库可以包括OceanBase数据库。
如图3所示，在310，在待追踪事务的执行过程中，可以确定当前执行动作所属的当前执行阶段。
在本申请中，分布式数据库中可以同时并行执行多个事务。在一个示例中，在分布式数据库中执行的每个事务都可以被确定为待追踪事务。在另一个示例中，可以将分布式数据库中的部分事务确定为待追踪事务，则可以仅对分布式数据库中的部分事务进 行追踪。
在确定待追踪事务的一种方式中，可以对分布式数据库中待执行的各个事务进行采样，然后将采样得到的事务确定为待追踪事务。
在一种采样方式中，可以在每批第一指定数量的待执行事务中采样第二指定数量的事务，第二指定数量小于第一指定数量，各个批次所包括的待执行事务各不相同。比如，可以从每批第一指定数量的待执行事务中采样一个事务。在另一种采样方式中，可以根据时间进行采样。在一个示例中，可以每隔指定时长采样一次，每次采样的事务数量可以是第三指定数量。在另一个示例中，可以在每个时间段内执行第四指定数量的采样，每次采样的事务数量可以是第五指定数量。在另一种采样方式中，可以以随机方式进行采样。
在本申请中，事务执行过程中的每个执行阶段可以是一个持续的过程，每个执行阶段可以包括多个执行动作，该多个执行动作按序执行来形成一套执行逻辑，所形成的执行逻辑是所属执行阶段的执行逻辑。属于同一个执行阶段中的多个执行动作中可以包括起始执行动作和结束执行动作，起始执行动作可以表示所属执行阶段的开始，结束执行动作可以表示所属执行阶段的结束。例如，每个SQL的执行过程可以作为一个完整的执行阶段，每个SQL的执行阶段可以包括解析阶段、优化阶段、具体执行阶段等。每个DFO的执行过程可以作为一个执行阶段，每个算子的执行过程也可以作为一个执行阶段。
针对每个事务，在发起该事务的同时可以生成一个Trace ID，Trace ID可以用于对事务的一次全链路跟踪过程进行标识。在事务的完整执行过程中，整个请求的调用链中始终携带Trace ID，上游服务携带Trace ID往下游服务进行传递。从而，通过Trace ID可以标记事务的完整执行路径。
此外，在待追踪事务的执行过程中，传递的信息还可以包括已执行的各个执行阶段所属的Span对应的Span ID。
在本申请中，Span表示具有开始时间和执行时长的逻辑单元，各个Span之间可以通过嵌套或者顺序排列建立逻辑因果关系。每个Span具有语义，Span所具有的语义可以是根据分布式数据库中的事务执行逻辑定义的。例如，一个事务的事务执行逻辑可以利用SQL、DFO以及算子等来表示，则Span具有的语义可以根据SQL、DFO以及算子等来定义，比如，针对SQL类型的Span，针对DFO类型的Span，以及针对算子类型 的Span等。
每个Span所具有的语义确定了该Span的类型，不同类型的Span所具有的语义可以不同，所起的作用也可以不同。每个类型的Span可以是经过标准化设置的，经过标准化的Span可以直接应用于分布式数据库的应用场景中。
在Span标准化的一种方式中，可以将Span的操作名称(即，Operation Name)以及Span对应的Span Tag进行标准化设置，Span Tag可以是构成Span标签的集合，可以用于表示Span的属性。每个Span的操作名称和Span Tag可以用于表征该Span所具有的语义，在Span的操作名称和Span Tag确定后，则该Span的语义也被确定。
在本申请中，事务执行过程包括的各个执行阶段可以设置有对应的Span，不同执行阶段可以设置不同语义的Span。每个执行阶段对应的Span的语义根据该执行阶段在事务执行逻辑中的位置确定，例如，针对SQL所包括的其中一个DFO的执行阶段，可以设置该执行阶段对应的Span是针对DFO的Span，该Span所表示的过程是DFO的执行过程。
每个Span对应有Span ID，Span ID与Span一一对应，每个Span对应的Span ID是该Span的执行阶段生成的、用于标识该执行阶段的内部调用状况。每个执行阶段完成后，该执行阶段的Span ID与Trace ID一起传递给下游的执行阶段。从而，通过Trace ID和各个执行阶段对应的Span ID可以确定出待追踪事务的完整执行过程。
在本申请中，确定当前执行阶段的执行主体可以是用于执行该当前执行阶段的执行设备，当待追踪事务需要经由多个设备来执行时，在不同的执行阶段，确定当前执行阶段的执行主体可以不同。
在一个示例中，待追踪事务经由分布式数据库来执行，则可以由分布式数据库来确定当前执行阶段。例如，应用与分布式数据库通信连接，待追踪事务可以由应用发起，在分布式数据库中执行，从而由该分布式数据库来执行确定当前执行阶段的操作。
在另一个示例中，分布式数据库可以与代理服务器通信连接，代理服务器用于将部署在客户端中的驱动发起的事务请求转发至分布式数据库中，从而每个事务的执行过程可以分别经过驱动、代理服务器以及分布式数据库。例如，在分布式数据库是OceanBase数据库时，代理服务器可以是OBProxy。
在该示例中，待追踪事务可以是由部署在客户端中的驱动发起，在代理服务器和分布式数据库中具体执行。则在当前执行阶段是处于代理服务器中时，用于执行确定当 前执行阶段的操作的执行主体可以是代理服务器。在当前执行阶段是处于分布式数据库中时，用于执行确定当前执行阶段的操作的执行主体可以是分布式数据库。
回到图3，在320，可以将当前执行阶段所属的Span对应的Span信息记录在本地。
在本申请中，每个Span所对应的执行阶段在执行完成后可以生成相应的Span信息，每个Span信息可以用于确定对应的Span与所属同一事务中的其他Span之间的引用关系，引用关系可以包括父子关系(Child_Of)和跟随关系(Follows_From)等。
父子关系是指在一个Span的执行阶段中发生了另一个Span的执行阶段。例如，在一个事务请求中，被调用的一方产生的Span与发起调用的一方所产生的Span可以构成父子关系。又例如，一个SQL Insert操作的Span和数据库存储引擎的Insert Row方法的Span构成父子关系。
跟随关系是指在一个Span的执行阶段之后发生了另一个Span的执行阶段，用来描述顺序执行关系。在跟随关系中，优先执行的Span对应的执行阶段不依赖于后执行的Span对应的执行阶段所生成的执行结果。
在一个示例中，每个Span对应包括有多种状态信息：操作名称、起始时间(Start Timestamp)、结束时间(End Timestamp)、Span Tag、Span Logs、SpanContext以及References等。其中，Span Logs可以是一组Span的日志集合。SpanContext可以包括进行全链路追踪的全局上下文信息，比如，SpanContext可以包括Trace ID以及各个Span对应的Span ID。References用于表示Span之间的引用关系，References表示的引用关系可以包括父子关系和跟随关系等。
可以按照Span的各个状态信息，获取相应的Span信息，即，每个Span的Span信息可以包括该Span的操作名称、起始时间、结束时间、Span Tag、Span Logs、SpanContext以及References等，不同Span对应的Span信息中所包括的各个状态信息可以不同。例如，针对SQL的Span与针对DFO的Span相比，Span信息中的操作名称、起始时间、结束时间等都不同。
通过各个Span之间的引用关系，可以确定各个Span对应的执行阶段的执行顺序，进而能够确定出事务的全链路执行过程。
在本申请中，记录Span信息的执行主体是当前执行阶段的执行设备，例如，在当前执行阶段的执行设备是OBProxy时，则由OBProxy来记录Span信息；在当前执行阶段的执行设备是分布式数据库时，则由分布式数据库来记录Span信息。在一个示例中， 分布式数据库中的各个存储节点可以作为独立执行操作的执行主体，在当前执行阶段的执行设备是分布式数据库中的一个存储节点时，则由该存储节点作为执行主体来记录Span信息。
Span信息可以以日志的形式记录在本地的日志文件中。例如，在OBProxy中，可以将Span信息记录到OBProxy.log中，在OceanBase数据库包括的各个OBServer中，可以将Span信息记录到OBServer.log中。
当前执行阶段的执行主体可以在每个会话的上下文中缓存所针对待追踪事务的多个Span对应的Span信息。例如，当一个SQL包括多个DFO且每个DFO包括多个算子时，在该SQL开始执行时，会话的上下文可以缓存该SQL的Span信息，在该SQL包括的其中一个DFO开始执行时，该上下文可以同时缓存SQL的Span信息以及DFO的Span信息，在DFO包括的其中给一个算子开始执行时，该上下文可以同时缓存SQL的Span信息、DFO的Span信息以及算子的Span信息。
在每个执行阶段完成时，可以将该执行阶段的Span信息记录到本地中，并更新会话的上下文中的缓存。例如，在算子执行完成时，可以将算子的Span信息记录到本地中，并将会话的上下文中缓存的算子的Span信息删除。在DFO执行完成时，可以将DFO的Span信息记录到本地中，并将会话的上下文中缓存的DFO的Span信息删除。在SQL执行完成时，可以将SQL的Span信息记录到本地中，并将会话的上下文中缓存的SQL的Span信息删除。
通过将Span信息记录在本地，避免各个执行阶段在获取到Span信息后在远程调用时将Span信息进行传递，从而减少事务执行过程中的资源开销，节省资源的同时能够提高事务的执行效率。
在一个示例中，事务包括的各个执行阶段可以具有执行粒度的属性，执行粒度可以是根据事务执行逻辑所划分的。在一种粒度划分方式中，一个事务的事务执行逻辑可以利用SQL、DFO以及算子等来表示，则针对事务的执行粒度可以使用SQL、DFO以及算子等来表示，比如，SQL、DFO和算子可以分别表示一种执行粒度，即，所划分的执行粒度可以包括SQL粒度、DFO粒度以及算子粒度。
不同执行粒度的粒度大小可以不同，在事务执行逻辑中，在一个执行阶段包括子执行阶段时，该执行阶段对应的执行粒度大于该子执行阶段对应的执行粒度。例如，SQL粒度大于DFO粒度，DFO粒度大于算子粒度。
在每个执行阶段具有执行粒度的属性的情况下，每个执行阶段所属的Span也可以对应一种执行粒度，每个Span对应的执行粒度是该Span的一种执行粒度属性。在一个事务的执行过程确定的情况下，该事务包括的各个执行阶段的执行逻辑可以确定，相应地，各个执行阶段对应的Span可以确定，各个执行阶段的执行粒度属性可以确定，从而各个执行阶段对应的Span的执行粒度属性可以确定。
在确定当前执行阶段时，可以确定该当前执行阶段对应的执行粒度。然后，可以判断当前执行阶段对应的执行粒度是否大于指定的执行粒度阈值，所指定的执行粒度阈值可以是针对事务的执行粒度中的任一种执行粒度。
在当前执行阶段对应的执行粒度大于执行粒度阈值时，可以将该当前执行阶段所属的Span对应的Span信息记录在本地。在当前执行阶段对应的执行粒度不大于执行粒度阈值时，则可以不记录该当前执行阶段的Span信息。
通过各个执行阶段的执行粒度，可以根据执行粒度阈值有针对性地记录部分执行阶段的Span信息，无需将事务包括的所有执行阶段的Span信息进行记录，从而避免产生用于全链路追踪的数据量太大，从而减小所产生的全链路追踪数据对分布式数据库的性能影响，以及减少了后续对Span信息进行处理时的数据处理量。
在330，在待追踪事务执行完成后，可以采集待追踪事务所包括的各个执行阶段的Span信息。
在一个示例中，可以使用分布式数据库外部的采集设备来采集待追踪事务所包括的各个执行阶段的Span信息。采集设备可以与待追踪事务所经过的各个设备连接，以从各个设备中采集待追踪事务的Span信息。
例如，待追踪事务经由OBProxy和分布式数据库执行时，则在OBProxy和分布式数据库中分别存储有Span信息，采集设备可以分别从OBProxy和分布式数据库中采集待追踪事务的Span信息。
在一个示例中，分布式数据库中的各个存储节点可以独立运行，因此，各个存储节点可以将所执行的执行阶段对应的Span信息存储在本地，从而，采集设备在与分布式数据库连接时，该采集设备可以与该分布式数据库中的各个存储节点分别连接，以便于采集设备可以从各个存储节点中分别采集所存储的Span信息。
在一个示例中，采集设备可以是与分布式数据库相匹配的设备，则该采集设备可以识别分布式数据库中的各种语义，比如，分布式数据库中的SQL、DFO以及算子等。 在该示例中，采集设备可以包括采集单元、存储单元和展示单元，采集单元将采集的Span信息发送给存储单元进行存储，展示单元可以根据从存储单元中获取Span信息对事务的全链路执行过程进行展示。比如，采集单元可以是ob_trace_agent，存储单元可以是OCP database，展示单元可以是OCP UI。
在另一个示例中，采集设备可以是通用采集设备，通用采集设备可以识别通用代码的语义，能够应用于各种应用场景下进行数据采集。例如，通用采集设备中的采集单元可以是Jaeger Agent和Jaeger Collector，通用采集设备中的存储单元可以是Jaeger DB，通用采集设备中的展示单元可以是Jaeger UI。
在340，可以根据所采集的各个Span信息来确定待追踪事务的全链路执行过程。
在本申请中，可以根据每个Span信息所表征出的对应的Span与所属同一事务中的其他Span之间的引用关系，来确定各个Span之间的引用关系以及执行顺序关系，然后，根据各个Span之间的引用关系以及执行顺序关系，可以相应地确定出各个执行阶段的执行顺序，各个执行阶段按照执行顺序可以组成待追踪事务的全链路执行过程。
在一个示例中，可以根据各个Span信息所确定的各个Span之间的引用关系，将该各个Span信息对应的执行阶段在时间维度上进行排布，以展示待追踪事务的全链路执行过程。
在该示例中，根据每个Span信息中的起始时间和结束时间可以确定对应的执行阶段的执行时间段。当两个Span是父子关系时，子Span对应的执行时间段被包含在父Span对应的执行时间段内，即，子Span的起始时间大于父Span的起始时间，子Span的结束时间小于父Span的结束时间。当两个Span是跟随关系时，上游Span的执行时间段在下游Span的执行时间段之前。
对于每个执行阶段，可以用时间条来表示，每个时间条可以由起始时间、结束时间以及时长来确定。在对各个执行阶段在时间维度上进行排布时，先执行的执行阶段对应的时间条排在后执行的执行阶段对应的时间条之前，针对父子关系的两个Span对应的两个执行阶段，子Span的执行阶段对应的时间条被包含在父Span的执行阶段对应的时间条内。
图5示出了根据本申请实施例的展示事务的全链路执行过程的一个示例的示意图。如图5所示，该事务包括3个SQL：SQL1、SQL2和SQL3，SQL1、SQL2和SQL3之间是跟随关系。SQL1包括DFO1和DFO2，SQL1与DFO1和DFO2之间均为父子关系， DFO1和DFO2之间是跟随关系。DFO2包括算子1和算子2，DFO2与算子1和算子2之间均是父子关系，算子1和算子2之间是跟随关系。SQL1、SQL2、SQL3、DFO1、DFO2、算子1以及算子2所构成的事务的全链路执行过程如图5所示。
通过将事务的全链路执行过程进行展示，可以清楚地了解事务的各个执行阶段的耗时以及相邻的各个执行阶段之间的时间间隔，从而可以基于所展示的全链路执行过程分析事务执行过程以及分析执行过程中存在的问题，比如，耗时问题。针对耗时问题，可以根据各个执行阶段的耗时来找出事务执行耗时问题所在，从而可以有针对性地对有问题的执行阶段进行优化，进而从整体上提升事务的执行效率。
在一个示例中，分布式数据库可以与代理服务器通信连接，代理服务器还可以与客户端通信连接。比如，分布式数据库的外部网络结构可以如图2所示。在该示例中，每个待执行的事务可以由部署在客户端中的驱动发起，从而每个事务的执行过程可以分别经过部署在客户端中的驱动、代理服务器以及分布式数据库。
在驱动处，在发起待执行事务时，可以为该待执行事务生成一个对应的Trace ID，在该待执行事务的后续执行过程中，该Trace ID始终跟随着执行过程进行传递。在发起待执行事务后，驱动可以在执行阶段执行相应的操作，从而生成相应的Span信息，该Span信息可以包括有Trace ID。驱动可以将从本地所获取的Span信息发送给代理服务器，代理服务器将从驱动接收到的Span信息记录在代理服务器中。
在该示例中，驱动将本地生成的Span信息不记录在本地，而记录在代理服务器中，这样在Span信息的采集阶段，可以从代理服务器中采集到客户端的Span信息，避免需要侵入到客户端的应用中才能采集客户端的Span信息。
在一个示例中，驱动可以将本地生成的Span信息以piggyback方式发送给代理服务器。在该示例中，驱动在生成Span信息后，可以从驱动需要发送给代理服务器的其他信息中确定一个信息，将Span信息增加至所确定的信息的附加字段中。当驱动将该信息发送给代理服务器时，Span信息也随之发送给代理服务器。其中，所确定的信息是驱动必然会发送给代理服务器的信息，比如，驱动发送给代理服务器的事务请求信息。例如，驱动在生成Span信息后，可以将下一个驱动发送给代理服务器的信息确定为携带Span信息的信息。
在该示例中，驱动以piggyback方式将Span信息发送给代理服务器，无需单独将Span信息发送给代理服务器，避免占用客户端的资源。
图6示出了根据本申请实施例的用于对分布式数据库中的事务进行全链路追踪的方法的一个示例600的流程图。
图6所示的方法可以由分布式数据库所包括的存储节点来执行，存储节点中的事务由至少一个SQL构成，每个SQL的执行计划包括至少一个DFO，每个DFO包括至少一个算子。在一个示例中，分布式数据库可以是原生分布式数据库。
如图6所示，在610，在待追踪事务在存储节点中的执行过程中，确定当前执行动作所属的当前执行阶段。
其中，执行过程传递的信息包括待追踪事务的Trace ID以及已执行的各个执行阶段所属的Span对应的Span ID，已执行的各个执行阶段包括该存储节点中已执行的执行阶段以及其他存储节点和设备中已执行的执行阶段。
在620，将当前执行阶段所属的Span对应的Span信息记录在本地，以使采集设备从存储节点中采集待追踪事务在存储节点中所执行的各个执行阶段的Span信息，并根据所采集的待追踪事务的各个Span信息来确定待追踪事务的全链路执行过程，其中，各个执行节点所属的Span具有的语义是根据分布式数据库中的事务执行逻辑定义的，每个Span信息用于确定对应的Span与所属同一事务中的其他Span之间的引用关系。
在一个示例中，将当前执行阶段所属的Span对应的Span信息记录在本地包括：在当前执行阶段对应的执行粒度大于执行粒度阈值时，将当前执行阶段所属的Span对应的Span信息记录在本地。其中，执行粒度根据事务执行逻辑来划分，每个执行阶段所属的Span对应一种执行粒度。
图7示出了根据本申请实施例的原生分布式数据库700的一个示例的方框图。
图7所示的原生分布式数据库包括有多个存储节点，各个存储节点中所执行的事务由至少一个SQL构成，每个SQL的执行计划包括至少一个DFO，每个DFO包括至少一个算子，各个存储节点包括执行阶段确定单元710和Span信息记录单元720。需要说明的是，图7所示的原生分布式数据库包括两个存储节点仅作为一个示例，在其它实施例中，原生分布式数据库可以包括更多或更少的存储节点。
执行阶段确定单元710，可以被配置为在待追踪事务在原生分布式数据库中的执行过程中，确定当前执行动作所属的当前执行阶段。其中，执行过程传递的信息包括待追踪事务的Trace ID以及已执行的各个执行阶段所属的Span对应的Span ID。
Span信息记录单元720，可以被配置为将当前执行阶段所属的Span对应的Span 信息记录在本地，以使采集设备从Span信息记录单元所属的存储节点中采集待追踪事务在该存储节点中所执行的各个执行阶段的Span信息，并根据所采集的待追踪事务的各个Span信息来确定待追踪事务的全链路执行过程。其中，各个执行节点所属的Span具有的语义是根据分布式数据库中的事务执行逻辑定义的，每个Span信息用于确定对应的Span与所属同一事务中的其他Span之间的引用关系。
在一个示例中，Span信息记录单元720还可以被配置为：在当前执行阶段对应的执行粒度大于执行粒度阈值时，将当前执行阶段所属的Span对应的Span信息记录在本地，其中，执行粒度根据事务执行逻辑来划分，每个执行阶段所属的Span对应一种执行粒度。
以上参照图1到图7，对根据本申请实施例的用于对分布式数据库中的事务进行全链路追踪的方法及装置的实施例进行了描述。
本申请的用于对分布式数据库中的事务进行全链路追踪的装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将存储器中对应的计算机程序指令读取到内存中运行形成的。在本申请中，用于对分布式数据库中的事务进行全链路追踪的装置例如可以利用电子设备实现。
图8示出了本申请实施例的用于实现事务进行全链路追踪方法的电子设备800的方框图。
如图8所示，电子设备800可以包括至少一个处理器810、存储器(例如，非易失性存储器)820、内存830和通信接口840，并且至少一个处理器810、存储器820、内存830和通信接口840经由总线850连接在一起。至少一个处理器810执行在存储器中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。
在一个实施例中，在存储器中存储计算机可执行指令，其当执行时使得至少一个处理器810：在待追踪事务在存储节点中的执行过程中，确定当前执行动作所属的当前执行阶段；以及将当前执行阶段所属的Span对应的Span信息记录在本地，以使采集设备从存储节点中采集待追踪事务在存储节点中所执行的各个执行阶段的Span信息，并根据所采集的所述待追踪事务的各个Span信息来确定待追踪事务的全链路执行过程，其中，各个执行节点所属的Span具有的语义是根据分布式数据库中的事务执行逻辑定义的，每个Span信息用于确定对应的Span与所属同一事务中的其他Span之间的引用 关系。
应该理解，在存储器中存储的计算机可执行指令当执行时使得至少一个处理器810进行本说明书的各个实施例中以上结合图1-7描述的各种操作和功能。
根据一个实施例，提供了一种例如机器可读介质的程序产品。机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本说明书的各个实施例中以上结合图1-7描述的各种操作和功能。
具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。
在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本申请的一部分。
本说明书各部分操作所需的计算机程序代码可以用任意一种或多种程序语言编写，包括面向对象编程语言，如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB、NET以及Python等，常规程序化编程语言如C语言、Visual Basic 2003、Perl、COBOL2002、PHP以及ABAP，动态编程语言如Python、Ruby和Groovy，或者其他编程语言等。该程序编码可以在用户计算机上运行，或者作为独立的软件包在用户计算机上运行，或者部分在用户计算机上运行另一部分在远程计算机运行，或者全部在远程计算机或服务器上运行。在后一种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或者在云计算环境中，或者作为服务使用，比如软件即服务(SaaS)。
可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。
在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。
以上结合附图详细描述了本说明书的实施例的可选实施方式，但是，本说明书的实施例并不限于上述实施方式中的具体细节，在本说明书的实施例的技术构思范围内，可以对本说明书的实施例的技术方案进行多种简单变型，这些简单变型均属于本说明书的实施例的保护范围。
本说明书内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本说明书内容。对于本领域普通技术人员来说，对本说明书内容进行的各种修改是显而易见的，并且，也可以在不脱离本说明书内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本说明书内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。

Claims (14)

  1. 一种用于对分布式数据库中的事务进行全链路追踪的方法，其中，所述分布式数据库中的事务由至少一个SQL构成，每个SQL的执行计划包括至少一个DFO，每个DFO包括至少一个算子，
    所述方法包括：
    在待追踪事务的执行过程中，确定当前执行动作所属的当前执行阶段，其中，所述执行过程传递的信息包括所述待追踪事务的Trace ID以及所述执行过程包括的已执行的各个执行阶段所属的Span对应的Span ID；
    将所述当前执行阶段所属的Span对应的Span信息记录在本地，其中，所述Span具有的语义是根据所述分布式数据库中的事务执行逻辑定义的，每个Span信息用于确定对应的Span与所属同一事务中的其他Span之间的引用关系；
    在所述待追踪事务执行完成后，采集所述待追踪事务所包括的各个执行阶段的Span信息；以及
    根据所采集的各个Span信息来确定所述待追踪事务的全链路执行过程。
  2. 如权利要求1所述的方法，其中，将所述当前执行阶段所属的Span对应的Span信息记录在本地包括：
    在所述当前执行阶段对应的执行粒度大于执行粒度阈值时，将所述当前执行阶段所属的Span对应的Span信息记录在本地，其中，执行粒度根据事务执行逻辑来划分，每个执行阶段所属的Span对应一种执行粒度。
  3. 如权利要求2所述的方法，其中，所划分的执行粒度包括SQL粒度、DFO粒度以及算子粒度。
  4. 如权利要求1所述的方法，还包括：
    对所述分布式数据库中待执行的各个事务进行采样；以及
    将采样得到的事务确定为待追踪事务。
  5. 如权利要求1所述的方法，其中，根据所采集的各个Span信息来确定所述待追踪事务的全链路执行过程包括：
    根据所采集的各个Span信息所确定的各个Span之间的引用关系，将该各个Span信息对应的执行阶段在时间维度上进行排布，以展示所述待追踪事务的全链路执行过程。
  6. 如权利要求1所述的方法，其中，所述分布式数据库与代理服务器通信连接，所述代理服务器用于将部署在客户端中的驱动发起的事务请求转发至所述分布式数据库，每个事务的执行过程分别经过所述驱动、所述代理服务器以及所述分布式数据库。
  7. 如权利要求6所述的方法，还包括：
    在所述驱动处，为待执行事务生成一个对应的Trace ID；以及
    在所述驱动处，将本地生成的包括有所述Trace ID的Span信息发送给所述代理服务器，以使所述代理服务器将该Span信息记录在所述代理服务器中。
  8. 如权利要求7所述的方法，其中，在所述驱动处，将本地生成的包括有所述Trace ID的Span信息发送给所述代理服务器包括：
    在所述驱动处，将本地生成的包括有所述Trace ID的Span信息以piggyback方式发送给所述代理服务器。
  9. 如权利要求1所述的方法，其中，所述分布式数据库包括原生分布式数据库，所述原生分布式数据库包括OceanBase数据库。
  10. 一种用于对分布式数据库中的事务进行全链路追踪的方法，所述方法由所述分布式数据库包括的存储节点来执行，所述存储节点中的事务由至少一个SQL构成，每个SQL的执行计划包括至少一个DFO，每个DFO包括至少一个算子，
    所述方法包括：
    在待追踪事务在所述存储节点中的执行过程中，确定当前执行动作所属的当前执行阶段，其中，所述执行过程传递的信息包括所述待追踪事务的Trace ID以及已执行的各个执行阶段所属的Span对应的Span ID；以及
    将所述当前执行阶段所属的Span对应的Span信息记录在本地，以使采集设备从所述存储节点中采集所述待追踪事务在所述存储节点中所执行的各个执行阶段的Span信息，并根据所采集的所述待追踪事务的各个Span信息来确定所述待追踪事务的全链路执行过程，
    其中，各个执行节点所属的Span具有的语义是根据所述分布式数据库中的事务执行逻辑定义的，每个Span信息用于确定对应的Span与所属同一事务中的其他Span之间的引用关系。
  11. 一种原生分布式数据库，包括多个存储节点，各个存储节点中所执行的事务由至少一个SQL构成，每个SQL的执行计划包括至少一个DFO，每个DFO包括至少一个算子，所述各个存储节点包括执行阶段确定单元和Span信息记录单元，
    所述执行阶段确定单元，被配置为在待追踪事务在原生分布式数据库中的执行过程中，确定当前执行动作所属的当前执行阶段，其中，所述执行过程传递的信息包括所述待追踪事务的Trace ID以及已执行的各个执行阶段所属的Span对应的Span ID；以及
    所述Span信息记录单元，被配置为将所述当前执行阶段所属的Span对应的Span 信息记录在本地，以使采集设备从所述Span信息记录单元所属的存储节点中采集所述待追踪事务在该存储节点中所执行的各个执行阶段的Span信息，并根据所采集的所述待追踪事务的各个Span信息来确定所述待追踪事务的全链路执行过程，
    其中，各个执行节点所属的Span具有的语义是根据所述分布式数据库中的事务执行逻辑定义的，每个Span信息用于确定对应的Span与所属同一事务中的其他Span之间的引用关系。
  12. 一种电子设备，包括：至少一个处理器，与所述至少一个处理器耦合的存储器，以及存储在所述存储器上的计算机程序，所述至少一个处理器执行所述计算机程序来实现如权利要求10所述的方法。
  13. 一种计算机可读存储介质，其存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求10所述的方法。
  14. 一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如权利要求10所述的方法。
PCT/CN2023/088497 2022-04-21 2023-04-14 用于全链路追踪事务的方法及原生分布式数据库 WO2023202497A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210418566.0A CN114547208B (zh) 2022-04-21 2022-04-21 用于全链路追踪事务的方法及原生分布式数据库
CN202210418566.0 2022-04-21

Publications (1)

Publication Number Publication Date
WO2023202497A1 true WO2023202497A1 (zh) 2023-10-26

Family

ID=81666998

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/088497 WO2023202497A1 (zh) 2022-04-21 2023-04-14 用于全链路追踪事务的方法及原生分布式数据库

Country Status (2)

Country Link
CN (1) CN114547208B (zh)
WO (1) WO2023202497A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114547208B (zh) * 2022-04-21 2022-09-02 北京奥星贝斯科技有限公司 用于全链路追踪事务的方法及原生分布式数据库
CN114969111B (zh) * 2022-08-01 2022-11-29 北京奥星贝斯科技有限公司 分布式数据库的逻辑子计划执行方法、装置及系统
CN115334153B (zh) * 2022-08-12 2023-10-27 北京百度网讯科技有限公司 服务网格的数据处理方法和装置
CN116225880B (zh) * 2023-05-05 2023-09-08 支付宝(杭州)信息技术有限公司 用于链路追踪的方法、装置及系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109726016A (zh) * 2017-10-30 2019-05-07 阿里巴巴集团控股有限公司 一种用于分布式系统的链路追踪方法、装置和系统
CN111385122A (zh) * 2018-12-29 2020-07-07 广州市百果园信息技术有限公司 分布式系统链路跟踪方法、装置、计算机设备及存储介质
CN113268471A (zh) * 2021-06-24 2021-08-17 京东科技控股股份有限公司 处理分布式事务的方法、代理连接池、系统、设备及介质
US11113155B1 (en) * 2015-06-19 2021-09-07 Amazon Technologies, Inc. Archiving and restoration of distributed database log records
CN113934763A (zh) * 2021-12-17 2022-01-14 北京奥星贝斯科技有限公司 分布式数据库的sql查询方法及装置
CN114547208A (zh) * 2022-04-21 2022-05-27 北京奥星贝斯科技有限公司 用于全链路追踪事务的方法及原生分布式数据库

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11113155B1 (en) * 2015-06-19 2021-09-07 Amazon Technologies, Inc. Archiving and restoration of distributed database log records
CN109726016A (zh) * 2017-10-30 2019-05-07 阿里巴巴集团控股有限公司 一种用于分布式系统的链路追踪方法、装置和系统
CN111385122A (zh) * 2018-12-29 2020-07-07 广州市百果园信息技术有限公司 分布式系统链路跟踪方法、装置、计算机设备及存储介质
CN113268471A (zh) * 2021-06-24 2021-08-17 京东科技控股股份有限公司 处理分布式事务的方法、代理连接池、系统、设备及介质
CN113934763A (zh) * 2021-12-17 2022-01-14 北京奥星贝斯科技有限公司 分布式数据库的sql查询方法及装置
CN114547208A (zh) * 2022-04-21 2022-05-27 北京奥星贝斯科技有限公司 用于全链路追踪事务的方法及原生分布式数据库

Also Published As

Publication number Publication date
CN114547208A (zh) 2022-05-27
CN114547208B (zh) 2022-09-02

Similar Documents

Publication Publication Date Title
WO2023202497A1 (zh) 用于全链路追踪事务的方法及原生分布式数据库
CN109460349B (zh) 一种基于日志的测试用例生成方法和装置
US20200183929A1 (en) Database workload capture and replay
US8055649B2 (en) Scaled management system
US8577871B2 (en) Method and mechanism for out-of-the-box real-time SQL monitoring
US20020062237A1 (en) Transactional monitoring system and method
US20080250057A1 (en) Data Table Management System and Methods Useful Therefor
US6910036B1 (en) Database performance monitoring method and tool
CN111143286B (zh) 一种云平台日志管理方法及系统
US20110055151A1 (en) Processing Database Operation Requests
US11954133B2 (en) Method and apparatus for managing and controlling resource, device and storage medium
US20180129712A1 (en) Data provenance and data pedigree tracking
CN110704484A (zh) 一种对海量实时数据流进行处理的方法及系统
US20220245132A1 (en) Transaction monitoring method, apparatus and system for distributed database, and storage medium
CN114428822B (zh) 一种数据处理的方法、装置、电子设备及存储介质
CN111291054B (zh) 一种数据处理方法、装置、计算机设备和存储介质
CN110825641B (zh) 一种基于模拟数据生成器的微服务应用测试系统
US7325016B1 (en) Monitoring database performance by obtaining SQL addresses for SQL statements
CN110196835A (zh) 元数据的处理方法、元数据的处理装置以及电子设备
CN106874067A (zh) 基于轻量级虚拟机的并行计算方法、装置及系统
US8732323B2 (en) Recording medium storing transaction model generation support program, transaction model generation support computer, and transaction model generation support method
CN116628023B (zh) 等待事件类型查询方法、装置、存储介质和电子设备
CN113094154A (zh) 一种基于阿里云的大数据处理方法及系统
US10248702B2 (en) Integration management for structured and unstructured data
Koschel et al. Evaluating time series database management systems for insurance company

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23791152

Country of ref document: EP

Kind code of ref document: A1