WO2011091472A1 - Traitement de requête - Google Patents

Traitement de requête Download PDF

Info

Publication number
WO2011091472A1
WO2011091472A1 PCT/AU2011/000084 AU2011000084W WO2011091472A1 WO 2011091472 A1 WO2011091472 A1 WO 2011091472A1 AU 2011000084 W AU2011000084 W AU 2011000084W WO 2011091472 A1 WO2011091472 A1 WO 2011091472A1
Authority
WO
WIPO (PCT)
Prior art keywords
state
label
computer
data
automaton
Prior art date
Application number
PCT/AU2011/000084
Other languages
English (en)
Other versions
WO2011091472A8 (fr
Inventor
Sebastian Maneth
Kim Nguyen
Original Assignee
National Ict Australia Limited
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
Priority claimed from AU2010900321A external-priority patent/AU2010900321A0/en
Application filed by National Ict Australia Limited filed Critical National Ict Australia Limited
Publication of WO2011091472A1 publication Critical patent/WO2011091472A1/fr
Publication of WO2011091472A8 publication Critical patent/WO2011091472A8/fr

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/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/83—Querying
    • G06F16/835—Query processing
    • G06F16/8365—Query optimisation

Definitions

  • This disclosure relates generally to query processing, and more particularly to computer-implemented method, system and computer program for processing a query.
  • XML a tree-structured data model defined by the World Wide Web Consortium (W3C)
  • W3C World Wide Web Consortium
  • an XML document contains not only data, but also the relationship of the data using tags or markup constructs such as ⁇ section> and ⁇ /section>.
  • XPath XML Path Language
  • XQuery XML Path Language
  • XPath query engines can be divided into two categories: sequential and indexed. In the sequential or streaming approach, each query must sequentially read a whole collection of data such that, ideally, only one pass over the data is required. In the indexed approach, the tree-structured data is pre-processed to build an index to guide query processing, such that traversal of the whole collection is avoided. For many time- critical applications, query run time is important. Summary
  • a computer-implemented method for processing a query of a set of data comprising:
  • automaton is constructed based on the query and comprises one or more states, one or more labels, and one or more transitions each associated with a state and a label;
  • Steps (a) to (c) may be performed dynamically during execution of the automaton. Steps (a) to (c) may also be repeatedly performed during execution of the automaton on multiple states of the automaton and nodes in the set of data.
  • the step of determining the one or more transitions in step (c) may involve determining one or more transitions that are valid for the state and the label.
  • the compiled code may be stored in a data store at an address associated with the state and the label.
  • the computer-implemented method may further comprise initialising a plurality of memory blocks in a data store, each memory block being initialised with instructions to call a function to determine the one or more transitions.
  • the step of storing the compiled code comprises replacing the instructions in a memory block at an address associated with the state and the label.
  • the method may further comprise constructing the automaton based on the query.
  • the automaton may be non-deterministic.
  • the data may be tree-structured, such as Extensible Markup Language (XML) data.
  • XML Extensible Markup Language
  • traversal of the data, or a subset of the data, during execution of the automaton may be according to a top-bottom traversal order.
  • the query may be an XPath query.
  • the method may further comprise indexing the set of data prior to steps (a) to (c). In this case, indexing the set of data generates a tree index or a text index, or both.
  • a computer program to implement the method of the first aspect The computer program may be embodied in a computer-readable medium such that when code of the computer program is executed, causes a computer system to implement the method according to the first aspect.
  • a computer system for processing a query of a set of data comprising a processing unit to:
  • automaton is constructed based on the query and comprises one or more states, one or more labels, and one or more transitions each associated with a state and a label;
  • Fig. 1 is a schematic diagram of an exemplary system for query processing.
  • Fig. 2 is a flowchart of steps performed by a query engine.
  • Fig. 3(a) is a diagram of an exemplary XML document.
  • Fig. 3(b) is a diagram of a text collection created based on the XML document in Fig. 3(a).
  • Fig. 3(c) is a diagram of a tree structure created based on the XML document in
  • Fig. 3(d) is an XML model created based on the XML document in Fig. 3(a).
  • Fig. 4 is a diagram of an exemplary tree.
  • Fig. 5 is a flowchart of steps performed by a processing unit of the query engine during query processing.
  • Fig. 6(a) is a schematic diagram of an exemplary memory area that is initialised by the processing unit prior to query processing.
  • Fig. 6(b) is a schematic diagram of the memory area in Fig. 6(a) after a first iteration.
  • Fig. 7(a) and Fig. 7(b) are schematic diagrams of the memory area in Fig. 6(b) after one or more iterations.
  • the system 100 comprises a query engine 1 10 and a data store 120 in communication with a plurality of communications devices 152 over a communications network 140, 142.
  • the devices 152 are each operated by a user 150.
  • the communications network 140 may be a local area network (LAN) or wide area network (WAN), wireless or wired.
  • the query engine 1 10 comprises an indexing unit 1 12, a query parsing unit 1 14 and a processing unit 1 16.
  • the query engine 1 10 processes queries of a collection of XML documents 122 (tree-structured data) in the data store 120.
  • a query may be submitted by a user 150, or by a server 154.
  • a memory area 128 in the data store 120 is allocated for use during query processing.
  • the query engine 1 10 uses an indexed approach to pre-process the XML collection 122, so that later queries can be solved without traversing the entire collection.
  • This indexed approach is distinguishable from streaming approach where XML documents are not stored on disk but rather fed "bits by bits" to the "streaming" query engine that is unable to keep track of what it has seen of the document. That is, upon seeing a piece of the input document, the streaming query engine decides whether to flag that piece of a result or pass it to another process.
  • indexed documents are stored the data store 120. '
  • the indexing unit 1 12 performs pre-processing data analysis on documents in the XML collection to determine the structure and content of the documents 122; see step 210. Results of the data analysis are used during index generation to build a text index 124 and a tree index 126 for use in query processing; see step 220.
  • the parsing unit 1 14 analyses or parses a path expression, for the query; see step 230. Based on the query, an automaton is constructed by the parsing unit 1 14 before further processing is performed; see step 235.
  • the constructed automaton comprises one or more states, each state being associated with one or more transitions.
  • the processing unit 1 16 executes the constructed automaton. Specifically, the processing unit 1 16 first determines whether compiled code is available for a label associated with a node in the set of data and a state of the constructed automaton. If the determination is in the affirmative, the processing unit 1 16 proceeds to execute the compiled code. Otherwise, it determines one or more transitions associated with the state, compiles code for the determined one or more transitions for execution, and stores the compiled code.
  • the results of the query are then presented to the user 150; see step 250.
  • the indexing 220, automaton construction 235 and query processing 240 steps performed by the query engine 1 10 will now be explained further below.
  • XML documents can be regarded as a "text collection” or a set of strings organised into a labelled “tree structure".
  • the strings correspond to textual content of the data while the tree structure defines the hierarchical structure of the tree.
  • the tree in Fig. 3(d) corresponds to the XML data in Fig. 3(a).
  • the tree is formed by solid edges, whereas dotted edges display the connection with the set of texts.
  • & is a dummy root (labelled 1) that is added to create a tree instead of a forest;
  • # is a node (6, 8, 10, 16) associated with a string or textual content ("soon discontinued”, “blue”, “40” and “30” respectively),
  • @ is a node (3,12) associated with an attribute (“name")
  • % is a leaf node (1,5) of an attribute node (3,12) and is associated with a value ("pen”, "rubber") to an attribute ("name").
  • the indexing unit 1 12 analyses the XML data in Fig. 3(a) to create the text index in Fig. 3(b) and the tree index in Fig, 3(c), which have been described in corresponding patent applications both entitled "Query Processing of Tree-Structured Data” and filed by the same applicant.
  • An XML model created based on the indices is shown in Fig. 3(d) and explained in the applications.
  • the indices 124 and 126 support various operations, including traversing to the first child of a current node, traversing to a sibling of the current node and reading a label of a current node.
  • a tree automaton is an abstract machine, consisting of states and transitions, which can then be used to traverse a tree.
  • An automaton ⁇ is a tuple , where L is the infinite set of all possible tree labels, Q is the finite set of states, Q l - s t ne se t of initial states, and ⁇ is the set of transitions.
  • the translation from XPath query to automata can be done in one pass through a parse tree created by the parsing unit 1 14; see step 230 in Fig. 2.
  • the resulting automaton is, roughly speaking, "isomorphic" to the original query.
  • Each transition is characterised by a starting state (qo or qi) and at least one condition such as whether the current node is labelled ⁇ listitem ⁇ or ⁇ keyword ⁇ . If the condition is satisfied, the action on the right hand side of the transition is performed.
  • Action ma k represents marking a node as a result node.
  • Action represents traversing to the next child node and changing to state qi.
  • action J- 1 *?0 represents traversing to the next child node, but remaining in state q 0 .
  • actions 12 QO (transition 3) and ⁇ ⁇ (transition 6) represent traversing to the next sibling node; and changing to state q 0 and qi respectively.
  • the automaton is non-deterministic, in that for a given state and label, the automaton can jump to more than one state.
  • the above automaton starts in initial state ⁇ qo ⁇ and traverses the tree until it finds a subtree labelled listitem. If the subtree is found, the automaton changes to state ⁇ qi ⁇ and continues to traverse the subtree to look for a label or tag keyword, or possibly another tag listitem. In the latter case, the automaton returns to state ⁇ qo ⁇ according to transition 1.
  • transitions 2 and 5 ensure that, according to the semantics of the descendant axis, only element nodes (i.e. not text # or attributes @) are considered. According to transition 4, a node labelled keyword that is found in state ⁇ qi ⁇ will be marked as a result node.
  • the tree 400 includes a root node labelled "Bibliography” 410, first-level child nodes labelled “book” (420, 422, 424, 428) or “magazine” (426), second-level child nodes labelled “title” (430, 432, 434, 436, 438) and third-level child nodes storing actual titles (440, 442, 444, 446, 448).
  • An input XPath query for extracting all title elements below book elements in the tree 400 is specified as:
  • the parsing unit 1 14 constructs the following Automaton 1 according to step 235 in Fig. 2.
  • (Tl ) instructs the processing unit 1 16 to determine whether the label of the Current Node is "book”. If the determination is in the affirmative, action j i qi in (Tl) instructs the processing unit 1 16 to go to the next child node and change to state ⁇ qi ⁇ . Otherwise, l i qo in (T2) instructs the processing unit 1 16 to go to the next child while remaining in state ⁇ qo ⁇ .
  • a naive implementation of the automaton would, at each Current Node, perform an iteration over all transitions to determine a list of valid transitions for a (State, Label(Current Node)) pair.
  • the list of valid transitions specifies a set of state(s) to go into for the first child or the next sibling of the current node.
  • This implementation is inefficient because the valid transitions have to be repeatedly computed every time the same State and Label(Current Node) are encountered.
  • the processing unit 1 16 reduces or avoids such expensive repetition by compiling an automaton into a binary program.
  • query run time is improved because compiled code for various (State, Label(Current Node)) pairs are cached during query processing.
  • the compiled code can be executed without having to determine the list of valid transitions and then transforming the transitions into compiled (binary) code again.
  • the processing unit 1 16 first initialises a memory area 128 in the data store 200 with a plurality of memory blocks, each block for storing compiled code associated with a (State, Label) pair; see step 505.
  • the processing unit 1 16 identifies the Current Node in the tree-structured data and the State of the automaton and reads the label of the Current Node; see steps 510 and 520.
  • the processing unit 1 16 determines whether compiled code has been previously cached for the current (State, Label(Current Node)) pair; see step 530. This involves checking whether the compiled code is stored in a block in the memory area 128.
  • the processing unit 1 16 proceeds to determine valid transitions for the current (State, Label(Current Node)) pair; see step 540.
  • the valid transitions in Automaton 1 are then transformed into compiled code, which is then cached in the Memory 128; see steps 542 and 544.
  • Compiled code is not available, for example, when the valid transitions for the current (State, Label(Current Node)) pair are executed for the first time.
  • the processing unit 1 16 simply retrieves the compiled code from Memory 128. Compiled code is available if it has been executed in a previous iteration, thereby reducing query run time because expensive operations to determine a list of valid transitions and then compiling the code for valid transitions is avoided in this instance.
  • the compiled code is then executed, and any results stored; see step 560.
  • the processing unit 1 16 then identifies the new Current Node and new Current State according to the automaton and repeats the process if there are more nodes to consider; see steps 570 and 590.
  • the new Current Node may be a child or sibling of the previous Current Node.
  • results of the query is presented to the user 150; see step 580.
  • the processing unit 1 16 first initialises a large area of memory 128 according to step 510.
  • the memory area 128 comprises a plurality of memory blocks 602, 604, 606, 608, 610 and 620 and starts at address @code with assembler instructions CALL @compute_actions repeated in sequence to fill the memory blocks 602, 604, 606, 608.
  • Function compute _actions() is stored at memory block 610 with address @compute_actions and will be executed when CALL @compute_actions is called.
  • function compute _actions() determines the valid actions or transitions for pair (State s, Label /).
  • the calling conventions depend on the specific architecture. AMD64 (trade mark of Advanced Micro Devices, Inc) architecture passes all parameters in up to 25 registers.
  • Intel x86 (trade mark of Intel Corporation, Inc) possesses less registers and pushes its parameters on the call stack.
  • the processing unit 1 16 stores state s in register Rl and label / in register R2 prior to executing function compute _actions().
  • Function return _result ⁇ ) is also initialised at memory block 620 with address @return_result and can be executed using assembly instructions GOTO @return_result for results presentation according to step 250 in Fig. 2 and step 580 in Fig. 5.
  • the processing unit 1 16 is at the root node 410 (i.e. Current Node) of the tree 400 and the initial state is ⁇ q 0 ⁇ ; see step 510 in Fig. 5.
  • the processing unit 1 16 reads the label of the root node 410 to be "Bibliography" according to step 520.
  • function id(x) that returns unique integer id(x) encoding x, where x may be a state q e Q or label / e C. Techniques such as hash consing can be used to implement this function to map an input x to integer id(x).
  • the processing unit 1 16 determines whether compiled code is available for this pair in the memory area 128 according to step 530. Specifically, the processing unit 1 16 executes the following:
  • GOTO @code[W(q 0 )][/ ⁇ /(/o)], where /o "Bibliography”
  • @code[jcf(q 0 )][iGi(/o)] 630 is an address in the memory area 128, id(qo) and id(k) are unique integers.
  • Parameters state ⁇ q 0 ⁇ and label / 0 are stored in registers Rl and R2 respectively.
  • the code for performing valid transition (T2) is compiled and stored at address @code[/d(qo)] [id(k) ⁇ 630 in memory area 128 according to steps 542 and 546, The updated memory area is shown in Fig. 6(b).
  • the compiled code for valid transition (T2) is executed; see step 560.
  • i qo in (T2) the new Current Node is child node 420 and the new state remains to be ⁇ qo ⁇ ; see step 590.
  • the above steps are then repeated for new Current Node 420.
  • the processing unit 1 16 reads the label of the Current Node to be "book” and determines whether compiled code is available for (State ⁇ qo ⁇ , "book") according to steps 520 and 530. Again, the processing unit 1 16 executes the following;
  • Steps 520 to 590 are again repeated for new Current Node 430.
  • the processing unit 1 16 reads the label of the Current Node 430 to be "title” and determines whether compiled code is available for (State ⁇ qi ), "title") according to steps 520 and 530.
  • the processing unit 1 16 executes the following:
  • @code[ i/(qi)][/i/(/2)] 650 is an address of memory block 606 in the memory area 128, id ⁇ ⁇ ) and id ⁇ lj) are unique integers. Parameters state ⁇ q i ⁇ and label are stored in registers Rl and R2 respectively. In this case, there is no compiled code for (State ⁇ qi ⁇ , "title") because it is the first time it is encountered; see step 530. At address @code[ e?(qi)][/i/(/2)] 650 in the memory area 128 in Fig. 6(a), the processing unit 1 16 will only find CALL @compute_actions which instructs it to execute function compute _actions().
  • Function compute _actions() determines all valid transitions for (State ⁇ qi ⁇ , "title"). For the tree 400 in Fig. 4, only transition (T4) is valid according to step 540. The code for this transition is compiled and stored at address @code[W(qi)][irf(/ 2 )] 650 in memory area 128 according to steps 542 and 546.
  • the updated memory area is shown in Fig. 7(b).
  • GOTO @code[W(qi)][/ ' i/(/2)] is called, function compute _actions ⁇ ) does not have to be performed because compiled code is already available.
  • the compiled code stored at @code[/cf(qi)][/i/(/2)] 650 is then executed according to step 560 in Fig. 5, in which case child node 430 is marked as the first result.
  • sequences of compiled codes are stored or cached in the memory area, indexed by (State, Label(Current Node)) pair and at the offset of @code[ i/(q 0 )][/c?(/o)], @code[ i/(q 0 )][i (/i)], @c0de[ £/(qi)][/ ' c/(/2)] and so on.
  • queries, and automatons constructed from the queries can be processed more efficiently because the naive and expensive function of compute _actions() is avoided if compiled code is available in the memory area 128.
  • a result set is allocated in the memory area 128 to store marked nodes.
  • a transition that contains a "mark" operation is required, a sequence of instructions is generated to add the Current Node to the result set.
  • the result set is configured to hold results (node identifiers) and support a few operations such as:
  • the result set can be implemented as a stack.
  • the stack is described using a fixed address @bottom and an offset top that is incremented every time a result is found.
  • the pseudo code for the mark operation is:
  • top - top + 1 ;
  • @current_node is the address of the Current Node
  • @bottom[/o/?] is the address at which the Current Node or its node identifier will be stored.
  • the addQ operation is implemented as storing the object at the top of the stack and incrementing offset top.
  • the sizeQ operation is implemented as returning the value of top, which is the size of the collection.
  • the nthQ operation is implemented as returning @bottom[ «].
  • the nodes between memory location @bottom and @bottom+fop-l (inclusive) are the nodes which were "marked”. It will be appreciated that other types of data structure such as linked lists can also be used to store the results. Structure of Data
  • a text database can be seen as a linear tree where the root is the first letter of the text, the first child of the root the second letter and so on. Using automaton-based querying, there would only operations that visit the first child (i 1 ) which would mean "go to the next letter”. Similarly, a graph database having a set of nodes linked by edges can also be queried using an automaton.
  • the method described may also be used with a range of optimisation techniques, such as code specialisation and runtime code profiling.
  • Code specialisation involves determining the next operation based on properties of the data set, which may be are stored in the text 124 and tree 126 indices or a schema. For example, assuming that the Current Node is a node with label "book" in state ⁇ qi ⁇ , the processing unit 1 16 compiles code for a transition that goes to state ⁇ q 2 ⁇ on the first child node. The processing unit 1 16 then analyses the corresponding automaton to find that the only transition in state ⁇ q 2 ⁇ is for label "title”. Based on this analysis, the processing unit 1 16 determines whether there are any "title” nodes below "book” in the data set based on the indices or schema.
  • processing unit 1 16 does not compile code for the transition to state ⁇ q2 ⁇ and generates a "NOOP" (empty instructions) instead.
  • NOOP empty instructions
  • Runtime code profiling involves a dynamic analysis of a piece of code before storing it. For example, when there is no compiled code available for a particular (State, Label), the processing unit 1 16 compiles the required code. However, before storing it, the processing unit 1 16 checks whether an identical piece of code has already been generated. If this is the case, the processing unit 1 16 replaces the generated code with a jump instruction to the identical piece of code.
  • the code By calling the same piece of code over and over again, the code will be placed in the instructions cache accessible by the processing unit 1 16. This is to be contrasted with the case whether the same piece of code is replicated several times in memory. In this case, the caching strategy of the CPU could be defeated by fetching and replacing some code in the cache by something identical but stored at a different address.
  • the size of the memory area 128 allocated depends on specific applications and size of data. Considering computer memory is inexpensive, the situation of the memory area 128 getting full is unlikely in practice. However, in the event that the memory area 128 is full during the querying process of a highly complex and memory-intensive data structure, several techniques can be employed. For example, a memory block can be selected blindly to have its compiled code replaced with a newer piece of compiled code. This may involve selecting the block sequentially, from the first (602) to the second (604) and so on; see Figs. 6 and 7. The block may also be selected at random. In another example, a counter can be stored with each memory block to keep track of the number of times the compiled code in the memory block is accessed. If the memory area 128 is full, the block with the lowest counter value will be selected to have its code replaced with a newer piece of code. Caching may also be disabled to free up more memory.
  • the constructed automaton may be improved or updated based on properties of the XML collection, or a subset of the XML collection.
  • Properties are stored in an index comprising the text 124 and tree 126 indices created by the indexing unit 1 12.
  • the text index 124 is used to facilitate counting of the number of text nodes matching a simple predicate in a query.
  • the tree index 126 provides an approximation on the number of nodes or potential results in a subset of nodes in the tree starting from a particular node.
  • the processing engine 1 16 does not have to rely on any indices for traversing to the first child of a current node, traversing to a sibling of the current node and reading a label of a current node.
  • the term "unit" is intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software or software in execution.
  • a unit may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program and/or a computer.
  • both an application running on a server and the server can be a computing unit.
  • One or more units may reside within a process and/or thread of execution and a component may be reside on a single computer and/or distributed between two or more computers.
  • Suitable computer readable media may include volatile (e.g. RAM) and/or non-volatile (e.g. ROM, disk) memory, carrier waves and transmission media (e.g. copper wire, coaxial cable, fibre optic media).
  • exemplary carrier waves may take the form of electrical, electromagnetic or optical signals conveying digital data steams along a local network or a publically accessible network such as the Internet.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

L'invention concerne un procédé mis en oeuvre par ordinateur permettant de traiter une requête d'un ensemble de données, le procédé comprenant les étapes suivantes consistant à : (a) déterminer si un code compilé est stocké pour un état d'un automate et une étiquette associée à un nœud dans l'ensemble de données, dans lequel l'automate est construit sur la base de la requête et comprend un ou plusieurs états, une ou plusieurs étiquettes, et une ou plusieurs transitions associées chacune à un état et à une étiquette ; et (b) si la détermination est positive, exécuter le code compilé pour l'état et pour l'étiquette afin d'exécuter une ou plusieurs transitions associées à l'état et à l'étiquette ; et (c) dans le cas contraire, déterminer une ou plusieurs transitions associées à l'état et à l'étiquette, et compiler, stocker et exécuter le code pour réaliser lesdites une ou plusieurs transitions déterminées.
PCT/AU2011/000084 2010-01-27 2011-01-27 Traitement de requête WO2011091472A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2010900321A AU2010900321A0 (en) 2010-01-27 Query Processing
AU2010900321 2010-01-27

Publications (2)

Publication Number Publication Date
WO2011091472A1 true WO2011091472A1 (fr) 2011-08-04
WO2011091472A8 WO2011091472A8 (fr) 2011-10-13

Family

ID=44318543

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2011/000084 WO2011091472A1 (fr) 2010-01-27 2011-01-27 Traitement de requête

Country Status (1)

Country Link
WO (1) WO2011091472A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115061717A (zh) * 2022-06-30 2022-09-16 北京亚控科技发展有限公司 应用管理方法、应用订阅方法及相关设备

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ERTL ET AL.: "Fast and Flexible Instruction Selection with On-Demand Tree-Parsing Automata", PROCEEDINGS OF THE 2006 ACM SIGPLAN CONFERENCE ON PROGRAMMING LANGUAGE DESIGN AND IMPLEMENTATION, 2006, Retrieved from the Internet <URL:http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.7008&rep=rep1&type=pdf> [retrieved on 20100910] *
GREEN ET AL., PROCESSING XML STREAMS WITH DETERMINISTIC AUTOMATA AND STREAM INDEXES, 11 May 2004 (2004-05-11), Retrieved from the Internet <URL:http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.146.1736&rep=repl&type=pdf> [retrieved on 20100910] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115061717A (zh) * 2022-06-30 2022-09-16 北京亚控科技发展有限公司 应用管理方法、应用订阅方法及相关设备
CN115061717B (zh) * 2022-06-30 2023-09-05 北京亚控科技发展有限公司 应用管理方法、应用订阅方法及相关设备

Also Published As

Publication number Publication date
WO2011091472A8 (fr) 2011-10-13

Similar Documents

Publication Publication Date Title
Green et al. Processing XML streams with deterministic automata and stream indexes
Chan et al. Efficient filtering of XML documents with XPath expressions
US8447785B2 (en) Providing context aware search adaptively
Kwon et al. FiST: scalable XML document filtering by sequencing twig patterns
US7458022B2 (en) Hardware/software partition for high performance structured data transformation
US8566343B2 (en) Searching backward to speed up query
US7437666B2 (en) Expression grouping and evaluation
Bikakis et al. The XML and semantic web worlds: technologies, interoperability and integration: a survey of the state of the art
US7747633B2 (en) Incremental parsing of hierarchical files
US8935267B2 (en) Apparatus and method for executing different query language queries on tree structured data using pre-computed indices of selective document paths
US7627589B2 (en) High performance XML storage retrieval system and method
US20060167869A1 (en) Multi-path simultaneous Xpath evaluation over data streams
US7328403B2 (en) Device for structured data transformation
O'Connor et al. Desirable properties for XML update mechanisms
Diewald et al. Krill: KorAP search and analysis engine
Sakamoto et al. Extracting partial structures from HTML documents
WO2011091472A1 (fr) Traitement de requête
Consens et al. Exploring XML web collections with DescribeX
Kamali et al. Improving mathematics retrieval
WO2011091470A1 (fr) Traitement de requête de données arborescentes
Kwon et al. Fast XML document filtering by sequencing twig patterns
Šestáková Indexing XML documents
WO2011091471A1 (fr) Traitement de requête de données arborescentes
Brennan An XPath Query Evaluator for Filesystems EECS 433 Final Project
Kamali Querying Large Collections of Semistructured Data

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: 11736537

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11736537

Country of ref document: EP

Kind code of ref document: A1