Upload
griselda-miles
View
215
Download
1
Tags:
Embed Size (px)
Citation preview
Event-Condition-Action Rule
Languages over Semistructured Data
George Papamarkos
13/10/2006 2
OutlineWhat Event-Condition-Action (ECA) Rules are and what we can do with them?
ECA Rules for XML ECA Langugage System Architecture Performance
ECA Rules for RDF ECA Langugage System Architecture Performance
13/10/2006 3
What is an ECA Rule?An Event-Condition-Action rule performs actions in response to events, given that a stated condition holds
An event in a database system can be the insertion of a new tuple
The condition can be a queryThe action may be a relational table update
This behaviour is called reactive functionality
13/10/2006 4
What is an ECA Rule?An ECA rule has the general syntax:
on event if condition do actionThe event part specifies when the rule is triggered
The condition part determines if the data are in a particular state, in which case the rule fires
The action part describes the actions to be performed if the rule fires.
13/10/2006 5
Advantages of using ECA Rules
Allow applications reactive functionality to be defined and managed within a single rule base rather than being encoded in the programs
Use of a high-level declarative syntax and are thus amenable to analysis and optimisation techniques that cannot be applied if the functionality was encoded in the programming code
13/10/2006 6
Outline
What Event-Condition-Action (ECA) Rules are and what we can do with them?
ECA Rules for XMLECA Language System ArchitecturePerformance
ECA Rules for RDFECA Langugage System ArchitecturePerformance
13/10/2006 7
ECA Rules for XML - Outline
Design issues of an ECA language for XML
The XTL Language Implementing an XTL rules processing system
Performance Study
13/10/2006 8
Design issues of an ECA language for XML Comparing with relational triggers the following are the most important XML-specific issues on designing an ECA language for XML
Event Granularity: Specifying the granularity of where data has be modified is more complex and requires path expressions
Action Granularity: Action may affect an entire sub-document meaning that: An action can trigger a different set of
events The analysis of which events are triggered by
an action cannot be based on syntax alone
13/10/2006 9
The XTL LanguageThe general syntax of XTL rules is:
on event if condition do action
Fragments of XPath and XQuery are used to specify the event, condition and action parts of XTL rules.
XPath is used for selecting and matching fragments of XML
XQuery is used withing actions where it is needed to construct a new XML fragment
13/10/2006 10
The XTL Language
Event Part Syntax: (INSERT | DELETE) e where e is an XPath expression evaluating to a set of nodes.
A rule is triggered if this set of nodes includes any node in the XML fragment inserted or deleted
The system-defined variable $delta contains this set of nodes and is available for use in condition and action part of the rule
13/10/2006 11
The XTL Language
Condition PartThe condition part is either the constant TRUE or one or more XPath expressions connected by the boolean connectives and, or, not.
Each of these expressions is evaluated on the data to tell whether the condition is TRUE or FALSE
13/10/2006 12
The XTL Language
Action Part: The action part is a sequece of one or more actions
Syntax: INSERT r BELOW e (BEFORE | AFTER) q r is an XQuery expression specifying the XML fragment
to be inserted, e is an XPath expression specifying the set of nodes under which the new fragment will be inserted, q is either a constant or an XPath qualifier specifying the set of nodes BEFORE or AFTER which the new nodes will be placed.
DELETE ee is an XPath expression specifing the set of nodes to
be deleted.
13/10/2006 13
XTL Language
Example rule:ON INSERT doc(‘s.xml’)/shares/share/day-info/prices/price
IF $delta > $delta/../../high
DO DELETE $delta/../high;
INSERT <high>$delta/text()</high>
BELOW $delta/../.. AFTER prices
13/10/2006 14
XTL rule processing system
13/10/2006 15
XTL rule processing system - Architecture
ECA Rules Management: Validates and registers a rule to the Rule Base
ECA Rule Processing Engine: Evaluates the Event and Condition Parts of the rules and schedules their actions for execution in the Action Schedule
13/10/2006 16
System Performance
The system performance was studied by: Developing an analytical model of the system
Performing experiments in the actual system
We have studied the effects of rule base indexes in system performance
Performance criterion: Update response time: The mean time taken to complete all rule execution resulting from a single update submitted by a top-level update transaction
13/10/2006 17
System Performance
Varying quantities:Number of rules in the rule base
Experiments on the actual performed with three (3) different rule sets
XML data set: a fragment of DBLP database
13/10/2006 18
System Performance - Analytical ModelThe analytical model is a mathematical description of the system behaviour
Uses queue theory to simulate the transaction queues and database processing
Uses a set of simplifying assumptions to emulate the behaviour of some system parameters (e.g. triggering probability, transaction arrival rate etc.)
13/10/2006 19
System Performance - Analytical Model Results
13/10/2006 20
System Performance - Analytical ModelResponse time increases non-linearly for as long as the system is stable (I.e. arrival rate in the transaction queue is less that the service rate)
After the stability point the transaction queue grows uncontrollably large, flooding the memory and slowing it down
Reasons: Everything served by a single queue High number of event query evaluations to find what is triggered
13/10/2006 21
System Performance - Experimental Results
13/10/2006 22
System Performance - Experimental Results
Difference with Analytical Model due to:implementation choices (use of DOM etc.) and
the simplification assumptions made in the analytical model
13/10/2006 23
System Performance
13/10/2006 24
System Performance - Indexing Rule Base
13/10/2006 25
System Performance - Indexing Rule BaseBetter overall behaviour and scalability characteristics due to smaller number of rules that need to be checked for triggering
Smaller number of rules checked --> smaller number of queries need to be evaluated
13/10/2006 26
OutlineWhat Event-Condition-Action (ECA) Rules are and what we can do with them?
ECA Rules for XMLECA Langugage System ArchitecturePerformance
ECA Rules for RDFECAPerformance Langugage System Architecture
13/10/2006 27
ECA Rules for RDF
The RDFTL ECA LanguageImplementing RDFTL processing system in P2P environments
System performance
13/10/2006 28
The RDFTL Language
We have designed the language from scratch specifically for RDF
General Syntax:ON event IF condition DO action
13/10/2006 29
The RDFTL LanguageEvent Part:
May contain let expressions of the form: LET $var := e
(INSERT | DELETE) e e is a path expression that evaluates on a set of RDF nodes. Catches the insertion or deletion of a node
(INSERT | DELETE) triple triple is an expression of the form (source,arc, target) specifying an RDF triple. Catches the insertion or deletion of a property in an RDF triple.
UPDATE upd_triple upd_triple is an expression of the form (source, arc, old_target->new_target). Catches the update of a property from one RDF node to another.
13/10/2006 30
The RDFTL Language
Condition Part: It is a boolean-valued expression May consist of conjunctions, disjunctions and negations
May also contain let expressions The $delta variable bound to the set of nodes or arcs modified and caught by the event part
Action Part: A sequence of actions Each action has similar syntax with the event part
13/10/2006 31
RDFTL Rules in P2P EnvironmentsSystem Architecture
13/10/2006 32
RDFTL Rules in P2P EnvironmentsEach peer (P) is supervised by a superpeer (SP)
The set of Ps supervised by an SP form a peergroup
At each SP there is an RDFTL processing engine installed
Each P or SP hosts a fragment of the RDF schema that may change due to updates
Hybrid fragmentation with possible replication
13/10/2006 33
RDFTL Rules in P2P EnvironmentsPs notify the SPs for any updates on their local data
An ECA rule generated at one P or SP may be replicated, triggered, evaluated or executed in different sites in the net.
13/10/2006 34
Distributed Rule Registration A rule generated is sent from P to SP for validation and storage
From there it is sent to all other SPs A replica of it will be stored also to those SPs that are e-relevant to the rule. I.e. the event part queries of a rule can be evaluated on SP
At each SP each rule is annotated with IDs of local peers that are e-, c- and a-relevant to the rule
c- and a- relevance have a similar meaning with e-relevance for the condition and action part
13/10/2006 35
Distributed Rule Execution Each SP manages its own rule execution schedule Each execution schedule is a sequence of updates to be executed on the local peergroup
Once an update u occurs in P, SP is notified SP determines if u may trigger any rule whose event part is annotated with P’s ID.
If yes, the event query is sent to P for evaluation If the rule is triggered, its condition will be evaluated
If the condition is true SP will send each instance of r’s action part to local peers that are a-relevant to it
13/10/2006 36
System Performance
The system performance was studied by: Developing an analytical model of the system Developing a system simulator and performing experiments with it
Performance criterion: Update response time: The mean time taken to complete all rule execution resulting from a single update submitted by a top-level update transaction
13/10/2006 37
System Performance
Cases studied with both the Analytical Model and the Simulator : Random Network topology between SPs, with various data replication degree
HyperCup Network topology between SPs, with various data replication degree
Varying quantities: Number of peergroups Number of rules
13/10/2006 38
System Performance
Random topology - Replication 10%
Analytical Model Simulation
13/10/2006 39
System Performance
With random topology system does not scale well even with low replication and number of rules and peergroups
Exponential update response timeSystem becomes unusable due to high load
13/10/2006 40
System Performance
HyperCup organises the SPs into hypercubes
HyperCup topology guarantees that: Each peer receives a message only once A total number of N-1 hops is necessary to broadcast a message to N peers
The more distant peers are reached after log2N hops
13/10/2006 41
System Performance
HyperCup - Replication 10%
Analytical Model Simulation
13/10/2006 42
System Performance
HyperCup - Replication 90%
Analytical Model Simulation
13/10/2006 43
System Performance
With HyperCup we achieve higher performance for various replication levels and number of peergroups
System scales betterSystem remains stable and the update response time within acceptable values
Analytical with simulation approach show good agreement
13/10/2006 44
Conclusions
We have described two ECA languages for XML and RDF
We have studied and defined the architectural characteristics for an ECA rule processing system in centralised and distributed environment
We have conducted a study to determine the system performance in both the centralised and distributed case
13/10/2006 45
Conclusions
The whole study shows that ECA rules is a usable technology for various different application environments over semi-structured data
13/10/2006 46
Thank you !!