Speculative JSON path evaluation on OSON-encoded JSON documents

Abstract

The present disclosure relates to improving performance of evaluating path expressions on hierarchical data objects represented by binary encoded documents. An abstract syntax tree (AST) representing a path expression can be generated, where the AST includes one or more syntax nodes that implement one or more respective execution steps for evaluating the path expression, and the path expression is contained in a query to a database management system (DBMS). The AST can be modified and compiled into machine code based at least in part on profiling information. The path expression can be executed on a binary encoded hierarchical document using the machine code.

Description

Technical Field

[0001] This disclosure relates to evaluating path expressions for binary-encoded documents. Background Technology

[0002] Hierarchical data objects (such as JavaScript Object Notation (JSON) documents) are supported in databases as a data type for storing semi-structured data. Hierarchical data objects are textual representations of data that can include nested objects containing name-value pairs, arrays containing values, and scalar data. While hierarchical data objects are organized using concepts such as arrays and objects, there is generally no fixed pattern that hierarchical data objects must follow.

[0003] Hierarchical data object path expressions are used to extract values ​​or check the existence of specific data within a hierarchical data object. Many database management systems (DBMS) provide functionality for evaluating path expressions on hierarchical data objects stored in their database tables. However, existing path expression engines suffer from latency and throughput issues, which reduce their usefulness.

[0004] The methods described in this section are permissible methods, but not necessarily methods that have been previously conceived or adopted. Therefore, unless otherwise indicated, no method described in this section should be presumed to be qualified as prior art simply because it is included in this section. Attached Figure Description

[0005] In the attached diagram: Figure 1 This is a block diagram illustrating an example path expression engine in an embodiment.

[0006] Figure 2A An example of an abstract syntax tree corresponding to the example path expression is shown in the embodiment.

[0007] Figure 2B An example of an optimized AST after specialization of the path expression and one or more input hierarchical data objects is shown in the embodiment.

[0008] Figure 2C An example representation of the optimized compilation 215 in the embodiment is shown.

[0009] Figure 3 This is a flowchart depicting an example process executed by the path expression engine in an embodiment for generating optimized compiled samples based on path expressions.

[0010] Figure 4 This is a block diagram illustrating a computer system on which embodiments of the present invention can be implemented.

[0011] Figure 5 It is a block diagram of a basic software system that can be used to control the operation of a computing system. Detailed Implementation

[0012] In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of the invention. However, it will be apparent, however, that the invention may be practiced without these specific details. In other instances, well-known structures and devices are illustrated in block diagram form to avoid unnecessarily obscuring the invention.

[0013] General Overview

[0014] This disclosure relates to improving the performance of evaluating path expressions for hierarchical data objects represented by binary-encoded documents. While hierarchical data objects may not have an explicit schema, hierarchical data objects within the same domain can share data shape characteristics. This similarity in data shape can be leveraged while maintaining the schema-less nature of the hierarchical data objects. To this end, machine code can be generated that makes assumptions about the data shape of the hierarchical data objects, invalidates any incorrect assumptions, and adapts to variations in the input hierarchical data objects. As used herein, the term "data shape" or "shape" refers to the structure and format of a hierarchical data object, including, for example, the type of data represented by the hierarchical data object, the organization and relationships of the data, the cardinality of the data, and other characteristics and properties that define how the data is structured and organized.

[0015] Data from hierarchical data objects can be stored in a binary encoded document, which can be a tree encoding of the hierarchical data objects. The binary encoded document can store the field names of objects within the hierarchical data object in a dictionary used to omit duplicates of field names. This dictionary maps unique numeric field identifiers to each field name in the data object. Because the dictionary is contained within the binary encoded data object, it can be called an inline dictionary. Fields within the hierarchical data object are stored as an encoded hierarchical tree. The hierarchical structure of the same structured object can be determined and stored once, allowing efficient navigation through the encoded tree using field identifiers without accessing unnecessary parts or scanning the entire hierarchical data object. Scalar values ​​from hierarchical data objects can be stored using existing data formats to enable rapid comparison and extraction of values ​​from the hierarchical data object. Alternatively, the scalar values ​​of the encoded data object can be mapped by an inline dictionary and encoded accordingly. The binary encoded document may include headers that set various parameters, such as variable size. The binary encoding document is discussed in detail in U.S. Patent Application No. 14 / 836,680, filed August 26, 2015, which is incorporated herein by reference in its entirety.

[0016] To evaluate path expressions for hierarchical data objects represented by binary-encoded documents, the path expressions can be compiled into optimized machine code. At runtime, a Just-In-Time (JIT) compiler can employ speculative logic to generate optimized machine code that specializes to the path expression and the data shape of one or more hierarchical data objects. This speculative logic can be based on assumptions about the inputs and environment of the computational task evaluating the path expression. While these assumptions may be incorrect, they are made speculatively based on profiling data collected during previous evaluations of the path expression on one or more hierarchical data objects. The resulting optimized machine code can then employ partial evaluations of one or more parts of the path expression combined with speculation about the shape of the hierarchical data object's data.

[0017] Optimized machine code can evaluate path expressions for one or more hierarchical data objects while using less CPU and memory than unoptimized execution. Therefore, optimized machine code can improve performance, for example, by reducing the latency between issuing the command to perform the evaluation of the path expression and the result of that evaluation. Consequently, optimized machine code can produce the result of a path expression much faster than existing evaluators for hierarchical data object path expressions.

[0018] Path Expression Engine

[0019] Figure 1 This is a block diagram illustrating an example path expression engine 101 in an embodiment. The path expression engine 101 can be executed to evaluate a path expression 103. Evaluating the path expression 103 may include, for example, parsing the path expression 103 and executing the parsed path expression 103 on a binary-coded document 105 representing a hierarchical data object 106, and obtaining an evaluation result 124.

[0020] The path expression engine 101 can parse a specific path expression 103 once, and the path expression engine 101 can execute the path expression 103 for each binary-encoded document 105 for which it evaluates the path expression 103. The task of executing the path expression 103 independently of the binary-encoded document 105 can be performed during parsing. Performing these tasks during parsing the path expression 103, rather than during execution, prevents these tasks from being repeated every time the path expression is executed on the binary-encoded document 105. For example, when the path expression 103 is parsed, hash values ​​of field names in the path expression 103 or conversions to efficiently comparable data types can be performed.

[0021] The path expression engine 101 can execute path expression 103 and return one or more evaluation results 124. Evaluation results 124 can be generated when executing path expression 103. One or more evaluation results 124 may include a value that matches path expression 103 in binary encoded document 105, all matching values, or the presence of any matching value, depending on which operator is used.

[0022] Abstract Syntax Tree

[0023] The result of parsing path expression 103 can be AST 109. AST 109 can include one or more syntax nodes 112, which represent the execution steps used to evaluate path expression 103 (i.e., execute the parsed path expression 103). AST 109 can include nodes for each object, array, descendant, or function step, as well as any filtering expressions in path expression 103. Furthermore, the return type specified for path expression 103—which can be used as a termination condition for evaluating the path expression—can be represented as a node in AST 109.

[0024] For example, when parsing something like "$items". [ When the path expression 103 is defined as "]", the corresponding AST 109 will contain a first syntax node 112 for the value of the "items" field, a second syntax node 112 for wildcard field access for the values ​​of all fields of the object, and a third syntax node 112 for all values ​​of the array. However, these syntax nodes 112 may not simply be executed one after another. For example, the second syntax node 112 would need to collect the values ​​of all fields in a separate container to pass to the next syntax node 112. But this is not only too memory-intensive, but also prohibits lazy evaluation—because even if the first value evaluated is sufficient to execute the path expression 103, all values ​​will be evaluated. Instead, a single value can be passed from one syntax node 112 to another without using data structures to complete the execution of the path expression 103 as quickly as possible.

[0025] In some implementations, Oracle Truffle can parse path expression 103 to generate AST 109. A domain-specific language (DSL) can be implemented using Truffle via an AST interpreter. DSL elements can be mapped to syntax nodes 112 of the implemented AST 109 according to the Truffle language framework. Each syntax node 112 can have an execution method for the logic implementing its corresponding DSL element. To execute the language program, the Truffle language framework can invoke a language parser. The Truffle language parser can instantiate syntax nodes 112 for each parsed DSL element and link syntax nodes 112 to instantiate AST 109.

[0026] Oracle's technology stack can include Truffle, Graal, Substrate, and the Java Virtual Machine (JVM). As discussed in this article, this toolchain can provide robust optimizations such as partial evaluation, AST rewriting, JIT compilation, dynamic profiling, data type inference, and speculative logic.

[0027] AST interpretation

[0028] The path expression engine 101 can initially execute the path expression 103 by directly interpreting the AST 109. At time T1, the path expression engine 101 can cause the interpreter 114 to interpret the execution steps represented by the syntax nodes 112 of the AST 109. The interpreter 114 can then evaluate the path expression 103 against one or more binary-coded documents 105 representing one or more corresponding hierarchical data objects 106. In some implementations, the Truffle language program can be executed by interpretation, which may require invoking the execution method of the root node of the AST 109. The execution method of the root node can invoke the execution methods of one or more child nodes(s) of the root node. This process can be reproduced in a top-down, depth-first manner for the child nodes of these nodes.

[0029] During the direct interpretation of AST 109, path expression engine 101 can collect dynamic profiling data 118 associated with the input hierarchical data object 106. For example, interpreter 114 may be accompanied by mechanisms (e.g., instrumentation) that allow dynamic profiling data 118 to be recorded during interpreter 114 execution. Thus, interpretation of AST 109 can result in the generation of one or more evaluation results 124 and dynamic profiling data 118. Dynamic profiling data 118 may contain observed data types, such as those used for generating speculative logic data type inferences, and information such as the execution frequency of basic blocks or individual instructions, such as those used for dead code elimination or hotspot detection such as tight loops.

[0030] Generate optimized compilation

[0031] At time T2, the path expression engine 101 can trigger the generation of optimized compilation. Once dynamic profiling data 118 is collected from one or more executions of interpreter 114, the dynamic profiling data 118 can be used to rewrite AST 109 to incorporate one or more specializations; the rewritten AST 109 can then be used to compile optimized compilation 116. Interpreter 114 can continue execution in the main thread, while the compilation of optimized compilation 116 can occur in a background thread. Once the compilation process terminates, the background thread can feed data to the foreground thread, enabling the implementation and execution of optimized compilation 116.

[0032] JIT compiler 121 can use dynamically parsed data 118 to compile AST 109 into an optimized compilation 116. For example, JIT compiler 121 could be a Graal JIT compiler. Therefore, the optimized compilation 116 can be produced by using the Truffle language framework and the Graal JIT compiler.

[0033] An optimized compiler 116 can be executed to more efficiently evaluate the path expression 103 based on one or more speculative assumptions that form the basis of the specializations incorporated into AST 109. The optimized compiler 116 can incorporate speculative logic 133 that reflects these specializations, speculative assumptions, partial evaluations, and other optimizations.

[0034] Speculative Logic

[0035] Speculative logic 133 can be based on dynamically profiled data 118. Speculative logic 133 can include one or more specializations based on observed input data, which can include global attributes of binary-coded document 105(1 or more). For example, speculative logic 133 can include a specialization for the global size of variables. If the input binary-coded document 105 tends to have, for example, a two-byte field identifier size, then AST 109 can be specialized to directly access the bytes of field identifiers in the binary-coded document based on the observed global variable size. This specialization avoids checking the variable size of field identifiers every time a hierarchical data object is processed, which could involve performing a binary search. As another example, speculative logic 133 can include a specialization for the results of a binary search that caches a list of field names in the header of binary-coded document 105. Using the cached results, AST 109 can be specialized to begin a subsequent binary search at the location of the cached results. To provide further examples, speculative logic 133 can include a specialization for situations where hash collisions do not occur. That is, AST 109 can exclude execution methods used to handle hash collisions between strings in binary-encoded document 105. As another example, speculative logic 133 may include specialization of the header values ​​of cached binary-encoded document 105. The header of binary-encoded document 105 may include one or more global attributes with values ​​that can be cached. If these values ​​are likely to be used during path evaluation, then they can be "inlined" in AST 109.

[0036] Speculative logic 133 may also include one or more specializations based on local properties of the binary encoded document 105. An example of such a specialization could be a speculation about the local size of a variable. For illustration, speculative logic 133 could speculate that the length of each offset in an array or object is a fixed size. In that case, variables can be accessed directly without checking their length. To further illustrate, another specialization could include a speculation about the “shape” of a particular value. For example, a specialization could add or remove implicit array type casting based on whether an array exists in a portion of the input binary encoded document 105. As another example, a specialization could be based on whether objects in the binary encoded document 105 use shared field identifiers. If an object references another object of a similar structure for its list of field identifiers, then that object can use shared field identifiers. Objects storing field identifiers can be cached. As another example, a specialization could include checking once whether an array index contains “0” or “last” if arrays in the input binary encoded document 105 tend to have a size of one. As another example, depending on the maximum size of scalar values ​​in the input binary encoded document 105, a specialization could include using a primary data type instead of arbitrary precision arithmetic.

[0037] Speculative logic 133 may also include inlining, partially evaluating, and compiling constant portions of path expression 103 (e.g., steps and literals in path expression 103). Partial evaluation may include speculatively applying assumptions to AST 109 and evaluating corresponding portions of AST 109 at compile time rather than runtime. For example, partial evaluation may include eliminating branches of AST 109 that are unnecessary due to specific speculative assumptions, or performing constant folding—evaluating any expression that involves only constants. If specific features of the path syntax are not used in path expression 103, constant flags may be used to eliminate branches of AST 109 that would cover those features, simplifying the machine code created for the corresponding syntax node 112 during partial evaluation.

[0038] When the speculative assumption fails, the speculative logic 133 may be accompanied by safeguards for deoptimization. For example, if the speculative assumption fails, execution may return to the interpreter 114 or an alternative optimized compiler 116. Otherwise, at time T3, the optimized compiler 116 may be successfully executed to evaluate the path expression 103 and generate an evaluation result 124.

[0039] Failure of speculative assumptions

[0040] In some implementations, if any speculative hypothesis fails (i.e., the input binary encoded document 105 exhibits one or more properties incompatible with one or more of the hypotheses), execution can resume to the interpreter 114. In some implementations, if one or more speculative hypotheses fail, the JIT compiler 121 can recompile AST 109 with a weaker set of speculative hypotheses. In other implementations, multiple different versions of the optimized compilation 116 can be cached, each corresponding to a different speculative hypothesis.

[0041] When the input binary encoded document 105 invalidates one or more speculative assumptions that form the basis of the optimized compilation 116, the path expression engine 101 can collect additional dynamic profiling data 118. Previously, the optimized compilation 116 may have been specialized on one or more speculative assumptions derived from one or more observed properties of the previously input binary encoded document 105. However, subsequent input binary encoded documents 105 may include one or more properties inconsistent with one or more observed properties of the previously input binary encoded document 105, thus invalidating those one or more speculative assumptions. The path expression engine 101 can then collect additional dynamic profiling data 118 indicating one or more properties of the subsequently input binary encoded document 105.

[0042] JIT compiler 121 can compile another version of optimized compilation 116, which is specialized on one or more additional speculative assumptions derived from one or more properties of the subsequent input binary-coded document 105. This further iteration of optimized compilation 116 can be cached together with a previous version of optimized compilation 116 based on one or more speculative assumptions from the previous input binary-coded document 105. Execution can then be dispatched to the relevant version of optimized compilation 116.

[0043] For example, suppose that optimized compilation 116 has been specialized to speculate on the size of a first global variable already observed within the previously input hierarchical data object 106. Therefore, a subsequent input binary encoded document 105 with a different second global variable size will invalidate the speculative assumption derived from the first global variable size. In addition to the previous optimized compilation 116 specialized for the first global variable size, JIT compiler 121 can also compile another optimized compilation 116 specialized for the second global variable size. Thus, path engine 101 can execute the previous optimized compilation 116 to evaluate the binary encoded document 106 determined to have the first global variable size, while simultaneously executing the other optimized compilation 116 to evaluate the binary encoded document 105 determined to have the second global variable size.

[0044] Accessing binary encoded documents

[0045] The binary-coded document 105 can be accessed by a JIT-compliant parser 107. The parser 107 can be a general implementation that supports a set of features for binary encoding while caching observed attributes of the binary-coded document 105, attributes that may remain unchanged for structurally similar binary-coded documents 105. For example, the parser 107 can cache attributes such as whether the binary-coded document dictionary will be less than 65kB, or the used size of hash values ​​for field names. Assuming these cached attributes are constant, partial evaluation can be specialized and perform optimized machine code for the parser 107 to access the hierarchical data object 106 data encoded in the binary-coded document 105 at the byte level.

[0046] Rewriting AST 109 to remove unnecessary branches and specializing the parsing code for binary-encoded documents 105—both of which can be inlined into a single execution—could produce efficient machine code that specializes in path expressions 103 and hierarchical data objects 106. Depending on the cardinality of the data processed for each path expression 103, the increased efficiency of the parser machine code could offset the cost of JIT compilation and result in a higher-performance path expression engine 101.

[0047] Examples of specialization of observed input data

[0048] Figure 2A An example AST corresponding to the example path expression 203 "$.id" is shown in the embodiment. Path expression 203 can be represented as AST 206, where each node 209 in AST 206 corresponds to an execution method used to evaluate path expression 203. Path expression 203 targets the value of a field named "id". In the AST, root node 209a is the root of the AST and also represents the root object of the hierarchical data object. Assuming root node 209a is a context node, child node 209b represents an implicit array type casting execution method that determines whether to perform a type casting from an array to an object. Grandchild node 209c represents an execution method used to identify the field name "id" in the hierarchical data object. Great-grandchild node 209d represents an execution method that looks up the field identifier of the field name "id", and great-grandchild node 209e represents an execution method that accesses the value of the "id" field.

[0049] Figure 2B An example of an optimized AST 212 after specializing a path expression and one or more input hierarchical data objects is shown. Path expression 203 can be executed against one or more hierarchical data objects according to the AST. During this execution, the path expression engine collects profiling data about the characteristics of these one or more hierarchical data objects relative to the path expression. Assume the profiling data indicates that implicit array coercion of node 209b should not be used. In that case, node 209b can be removed from the optimized AST 212. Therefore, when executing path expression 203 according to the optimized AST 212, the implicit array coercion step can be skipped. Furthermore, assume the profiling data indicates that the field identifier of field name "id" is always 3 in one or more hierarchical data objects. Then, the great-grandchild node 209d can be modified in the optimized AST 212 to assume that the field identifier of field name "id" is 3. Therefore, when executing path expression 203 according to the optimized AST 212, the path engine can determine whether the assumption that the field identifier of field name "id" is 3 is still correct, rather than performing a new dictionary lookup.

[0050] Figure 2CAn example representation of optimized compilation 215 in an embodiment is shown. Optimized compilation 116 215 can be generated from compiling optimized AST 212. Optimized compilation 116 can be used to perform the steps of optimized AST 212 on a hierarchical data object similar to the hierarchical data object used to collect profiling information. However, if one of the assumptions does not apply to the hierarchical data object, then either of the two different optimizations can be used, or the execution can be deoptimized. For example, assume a hierarchical data object has a field name “id” with a field identifier of 4 instead of 3. In some embodiments, a second optimization assuming the field identifier of the “id” field name is 4 can be added to optimized AST 212 and optimized compilation 215, along with an execution method that determines which optimization (assuming the field identifier of the “id” field name is 3 or assuming it is 4) to use. In other embodiments, optimized AST 212 can be deoptimized at node 209d to find the field identifier of the “id” field.

[0051] Example processing used to generate optimized compilation 116

[0052] Figure 3 This is a flowchart depicting an example process performed by the path expression engine 101 in an embodiment to generate an optimized compilation 116 based on the path expression 103. Figure 3 The flowchart only provides examples of many different types of functional arrangements that can be used to implement the operations of the depicted path expression engine 101.

[0053] At step 303, the path expression engine 101 can generate an abstract syntax tree (AST) 109. The path expression 103 can be parsed to generate the AST 109. In some implementations, the AST 109 can be generated by parsing the path expression 109 using Oracle Truffle. The AST 109 may include one or more nodes, where each node represents an execution method in the processing of evaluating the path expression 103.

[0054] At step 306, the path expression engine 101 can interpret the AST 109. For example, the path expression engine 101 can execute a decoder 114 to evaluate the path expression 103 on one or more binary-coded documents 105 represented by one or more corresponding hierarchical data objects 106. The decoder 114 can traverse the AST 109 starting from the root syntax node 112. At each syntax node 112, the decoder 114 can invoke the execution method represented by that syntax node 112 to perform the corresponding steps in the processing for evaluating the path expression 103.

[0055] At step 309, the path expression engine 101 can collect dynamic profiling data 118 from the interpretation of AST 109. For example, the interpreter 114 can record data observed in one or more evaluated binary encoded documents 105, such as variable sizes, data types, binary search results, header values, offset lengths in arrays and / or objects, and other global and local attributes of one or more binary encoded documents 105, which may include attributes of the corresponding one or more hierarchical data objects 106 and the data therein. The path expression engine 101 can cache this data as dynamic profiling data 118. Steps 306 and 309 can be as follows: Figure 1 The events shown occur simultaneously at time T1.

[0056] At step 312, the path expression engine 101 may rewrite the AST 109. The AST 109 may be rewritten to incorporate one or more specializations. These specializations may be based on properties of one or more binary encoded documents 105 observed during evaluation by the interpreter 114, which are reflected in the dynamically profiled data 118.

[0057] At step 315, the path expression engine 101 can generate an optimized compilation 116. For example, in Figure 1 At time T2, an optimized compilation 116 can be generated, at least in part, based on AST 109 and dynamic profiling data 118. JIT compiler 121 can use dynamic profiling data 118 to compile the rewritten AST 109 into the optimized compilation 116. When generating the optimized compilation 116, JIT compiler 121 can perform partial evaluation by computing a portion of the rewritten AST 109 at compile time. Partial evaluation may include computing (and thus eliminating) one or more branches of AST 109 or performing constant folding.

[0058] At step 318, the path expression engine 101 can perform optimized compilation 116. For example, as Figure 1 As shown, an optimized compilation 116 can be performed at time T3 to evaluate the path expression 103 on one or more binary encoded documents 105 in an optimized manner. Therefore, performing the optimized compilation 116 can produce one or more evaluation results 124.

[0059] Hardware Overview

[0060] According to one embodiment, the techniques described herein are implemented by one or more dedicated computing devices. The dedicated computing device may be hardwired to execute the techniques, or may include digital electronic devices permanently programmed to execute the techniques, such as one or more application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs), or may include one or more general-purpose hardware processors programmed to execute the techniques according to program instructions in firmware, memory, other storage devices, or combinations thereof. Such a dedicated computing device may also combine custom hardwired logic, ASICs, or FPGAs with custom programming to implement the techniques. The dedicated computing device may be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that combines hardwired and / or program logic to implement the techniques.

[0061] For example, Figure 4 This is a block diagram illustrating a computer system 400 on which embodiments of the present invention may be implemented. The computer system 400 includes a bus 402 or other communication mechanism for transmitting information and a hardware processor 404 coupled to the bus 402 for processing information. The hardware processor 404 may be, for example, a general-purpose microprocessor.

[0062] Computer system 400 also includes main memory 406, such as random access memory (RAM) or other dynamic storage devices, coupled to bus 402 for storing information and instructions to be executed by processor 404. Main memory 406 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 404. When such instructions are stored in non-transitory storage media accessible to processor 404, such instructions make computer system 400 a dedicated machine customized to perform the operations specified in the instructions.

[0063] The computer system 400 also includes a read-only memory (ROM) 408 or other static storage device coupled to the bus 402 for storing static information and instructions of the processor 404. A storage device 410, such as a disk, optical disk, or solid-state drive, is provided and coupled to the bus 402 for storing information and instructions.

[0064] Computer system 400 may be coupled via bus 402 to a display 412, such as a cathode ray tube (CRT), for displaying information to a computer user. Input device 414, including alphanumeric keys and other keys, is coupled to bus 402 for transmitting information and command selections to processor 404. Another type of user input device is a cursor control 416, such as a mouse, trackball, or arrow keys, for transmitting directional information and command selections to processor 404 and for controlling cursor movement on display 412. Such input devices typically have two degrees of freedom on two axes (a first axis (e.g., x) and a second axis (e.g., y)) to allow the device to specify a position in a plane.

[0065] Computer system 400 may implement the techniques described herein using custom hard-wired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which, in combination with the computer system, enable computer system 400 to become a special-purpose machine or to program computer system 400 as a special-purpose machine. According to one embodiment, the techniques herein are executed by computer system 400 in response to processor 404 executing one or more sequences of one or more instructions contained in main memory 406. These instructions may be read into main memory 406 from another storage medium, such as storage device 410. Execution of the sequence of instructions contained in main memory 406 causes processor 404 to perform the processing steps described herein. In alternative embodiments, hard-wired circuitry may be used instead of software instructions or in combination with software instructions.

[0066] As used herein, the term "storage medium" refers to any non-transitory medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such storage media can include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs, magnetic disks, or solid-state drives, such as storage device 410. Volatile media include dynamic memory, such as main memory 406. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips, or magnetic tape cassettes.

[0067] Storage media differ from transmission media but can be used in conjunction with them. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including wires containing bus 402. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0068] Various forms of media can involve carrying one or more sequences of instructions to processor 404 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and transmit them over a telephone line using a modem. A modem local to computer system 400 may receive data over the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data carried in the infrared signal, and appropriate circuitry may place the data on bus 402. Bus 402 carries the data to main memory 406, from which processor 404 retrieves and executes the instructions. The instructions received by main memory 406 may optionally be stored on storage device 410 before or after execution by processor 404.

[0069] Computer system 400 also includes a communication interface 418 coupled to bus 402. Communication interface 418 provides bidirectional data communication coupled to network link 420, which is connected to local network 422. For example, communication interface 418 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem providing data communication connectivity to a corresponding type of telephone line. As another example, communication interface 418 may be a LAN card providing data communication connectivity to a compatible local area network (LAN). A wireless link may also be implemented. In any such implementation, communication interface 418 transmits and receives electrical, electromagnetic, or optical signals carrying streams of digital data representing various types of information.

[0070] Network link 420 typically provides data communication to other data devices via one or more networks. For example, network link 420 may provide a connection to host computer 424 or to data devices operated by Internet Service Provider (ISP) 426 via local network 422. ISP 426, in turn, provides data communication services via a global packet data communication network now commonly referred to as the “Internet” 428. Both local network 422 and Internet 428 use electrical, electromagnetic, or optical signals that carry digital data streams. Signals through various networks, as well as signals on network link 420 and through communication interface 418, are example forms of transmission media that carry digital data to or from computer system 400.

[0071] Computer system 400 can send messages and receive data, including program code, through one or more networks, network links 420, and communication interfaces 418. In the Internet example, server 430 can transmit requested code for the application through the Internet 428, ISP 426, local network 422, and communication interface 418.

[0072] The received code can be executed by processor 404 when it is received, and / or stored in storage device 410 or other non-volatile storage device for later execution.

[0073] Software Overview

[0074] Figure 5 This is a block diagram of a basic software system 500 that can be used to control the operation of computing system 400. The software system 500 and its components, including their connections, relationships, and functions, are intended to be exemplary only and are not intended to limit the implementation of one or more of the example embodiments. Other software systems suitable for implementing one or more example embodiments may have different components, including components with different connections, relationships, and functions.

[0075] Software system 500 is provided to guide the operation of computer system 400. Software system 500, which may be stored on system memory (RAM) 406 and fixed storage device (e.g., hard disk or flash memory) 410, includes a kernel or operating system (OS) 510.

[0076] OS 510 manages the low-level aspects of computer operations, including managing process execution, memory allocation, file input and output (I / O), and device I / O. One or more applications, designated 502A, 502B, 502C…502N, can be “loaded” (e.g., transferred from fixed storage device 410 to memory 406) for execution by system 500. Applications or other software intended for use on computer system 400 can also be stored as downloadable computer-executable instruction sets, for example, for downloading and installation from internet locations (e.g., web servers, app stores, or other online services).

[0077] Software system 500 includes a graphical user interface (GUI) 515 for receiving user commands and data graphically (e.g., "click" or "touch gestures"). These inputs can then be manipulated by system 500 according to instructions from operating system 510 and / or (one or more) applications 502. GUI 515 also displays the results of operations from OS 510 and (one or more) applications 502, to which the user can provide additional input or terminate the session (e.g., log off).

[0078] OS 510 can execute directly on the bare hardware 520 of computer system 400 (e.g., one or more processors 404). Alternatively, a hypervisor or virtual machine monitor (VMM) 530 can be inserted between the bare hardware 520 and OS 510. In this configuration, VMM 530 acts as a software "buffer" or virtualization layer between OS 510 and the bare hardware 520 of computer system 400.

[0079] VMM 530 instantiates and runs one or more virtual machine instances (“guest machines”). Each guest machine includes a “guest” operating system (such as OS 510) and one or more applications designed to run on the guest operating system, such as application(s)502. VMM 530 presents a virtual operating platform to the guest operating system and manages the execution of the guest operating system.

[0080] In some instances, VMM 530 can allow a guest operating system to run as if it were running directly on the bare hardware 520 of computer system 500. In these instances, the same version of the guest operating system configured to run directly on the bare hardware 520 can also run on VMM 530 without modification or reconfiguration. In other words, VMM 530 can provide full hardware and CPU virtualization to the guest operating system in some instances.

[0081] In other instances, the guest operating system can be specifically designed or configured to run on VMM 530 for improved efficiency. In these instances, the guest operating system is "aware" that it is running on the virtual machine monitor. In other words, VMM 530 can provide paravirtualization to the guest operating system in some instances.

[0082] A computer system process includes the allocation of hardware processor time and the allocation of (physical and / or virtual) memory for storing instructions executed by the hardware processor, data generated by the execution of those instructions, and / or for storing hardware processor state (e.g., register contents) between allocations of hardware processor time when the computer system process is not running. Computer system processes run under the control of the operating system and can also run under the control of other programs executing on the computer system.

[0083] The basic computer hardware and software, as well as the cloud computing environment, described above are presented to illustrate the basic underlying computer components that can be used to implement one or more example embodiments. However, the one or more example embodiments are not necessarily limited to any particular computing environment or computing device configuration. Rather, the one or more example embodiments can be implemented in any type of system architecture or processing environment that a person skilled in the art would understand from this disclosure as capable of supporting the features and functionality of the one or more example embodiments presented herein.

[0084] In the foregoing description, embodiments have been described with reference to numerous specific details that vary depending on the implementation. Accordingly, the description and drawings should be considered illustrative rather than restrictive. The sole and exclusive reference to the scope of the invention, and the content that the applicant intends to define as the scope of the invention, is the literal and equivalent scope of the set of claims issued in this application, in the specific form of such claims, including any subsequent corrections.

[0085] In the foregoing description, embodiments have been described with reference to numerous specific details that vary depending on the implementation. Accordingly, the description and drawings should be considered illustrative rather than restrictive. The sole and exclusive reference to the scope of the invention, and the content that the applicant intends to define as the scope of the invention, is the literal and equivalent scope of the set of claims issued in this application, in the specific form of such claims, including any subsequent corrections.

Claims

1. A method comprising: Generate an abstract syntax tree (AST) representing a path expression, wherein the AST includes one or more syntax nodes that implement one or more corresponding execution steps for evaluating the path expression, and the path expression is contained in a query to a database management system (DBMS); The AST is modified at least in part based on the profiling information; The AST is compiled into machine code; The path expression is executed on a binary-encoded hierarchical document using the machine code; The method is performed by one or more computing devices.

2. The method of claim 2, wherein the binary-encoded hierarchical document includes an inline dictionary that maps field names of hierarchical data objects to field name identifiers of hierarchical data objects.

3. The method of claim 1, wherein the binary-encoded hierarchical document represents a hierarchical data object including multiple field names, wherein the binary-encoded hierarchical document includes: Map the hash codes corresponding to the field names among the plurality of field names to the hash code mapping of the field name identifier. Mapping field names to field name identifiers. A child node mapping that maps nodes to one or more child nodes, wherein the node and the one or more child nodes represent field names of hierarchical data objects, and Map field name identifiers to field name identifiers to child nodes of the one or more child nodes.

4. The method of claim 1, wherein the binary-encoded hierarchical document represents a JSON document.

5. The method of claim 1, wherein compiling the AST into machine code further comprises partially evaluating one or more constant expressions of the AST.

6. The method of claim 1, wherein the AST is compiled into machine code using a just-in-time (JIT) compiler.

7. The method of claim 1, wherein the binary-coded hierarchical document is a first binary-coded hierarchical document, and the method further comprises: The AST is partially interpreted on the second binary-encoded layered document; as well as The analysis information is collected from the direct interpretation of the AST.

8. The method of claim 7, wherein the profiling information includes at least one of the following: The predetermined size of variables in the second binary-coded hierarchical document. The cached field identifier from the second binary-encoded hierarchical document. The cached header value of the second binary-encoded layered document header. The second binary-coded hierarchical document indicates that the size of the array is one. The maximum size of scalar values ​​in the second binary-encoded hierarchical document, or The second binary-coded hierarchical document stores a cached object of a field identifier that is referenced by another object in the second binary-coded hierarchical document.

9. The method of claim 8, wherein modifying the AST based at least in part on the profiling information further comprises at least one of the following: The first syntax node of the AST is modified to enable access to one or more variables of one or more binary-coded hierarchical documents based at least in part on the size of one or more dynamically checked variables, so as to enable access to one or more variables based at least in part on a predetermined size of the variables; The second syntax node of the AST is modified to perform a binary search to access one or more field identifiers from the one or more binary-encoded hierarchical documents, so as to enable access to the one or more field identifiers at least in part based on cached field identifiers; Modify the third syntax node of the AST to identify values ​​from the headers of the one or more binary-encoded hierarchical documents to inline the cached header values; The fourth syntax node of the AST is modified to evaluate the index range of one or more arrays from the one or more binary-coded hierarchical documents, so as to determine whether the index of the one or more arrays contains "0" or "last" based on the size of the array in the profiling information. Modify the fifth syntax node of the AST to replace the variable-precision scalar data type in the one or more binary-coded hierarchical documents with a basic data type, at least in part based on the maximum size of the scalar values ​​from the profiling information decreasing below a predetermined threshold; or Modify the sixth syntax node of the AST to replace one or more objects that implement field identifier sharing with a cached object that stores field identifiers.

10. The method of claim 1, wherein executing the path expression on the binary-encoded hierarchical document using the machine code further comprises: Determine whether a value satisfying the path expression exists in the binary-encoded hierarchical document. Identify values ​​that satisfy the path expression in the binary-encoded hierarchical document, or Identify all values ​​that satisfy the path expression in the binary-encoded hierarchical document.

11. One or more storage media storing instructions that, when executed by one or more computing devices, cause the execution of the method described in any one of claims 1-10.

12. A system comprising: One or more computing devices; One or more storage media storing instructions that, when executed by the one or more computing devices, cause the execution of the method described in any one of claims 1-10.

Images