Selftuning of the Relationships among Rules Components in

  • Slides: 16
Download presentation
Self-tuning of the Relationships among Rules’ Components in Active Database Systems David Botzer and

Self-tuning of the Relationships among Rules’ Components in Active Database Systems David Botzer and Opher Etzion IEEE Transactions on Knowledge and Data Engineering, Mar. 2004

Active Database Systems n Detect events and trigger actions according to specified conditions. n

Active Database Systems n Detect events and trigger actions according to specified conditions. n Event-Condition-Action (ECA) Rules 1. Event detected 2. Rules identified 3. Conditions evaluated 4. Actions activated (event triggered)

Performance Issues n No flexibility for: – Partitioning rules to transactions – Specifying timing

Performance Issues n No flexibility for: – Partitioning rules to transactions – Specifying timing constraints n Possible solution: – Add design primitives – Use “Coupling Modes” as a design primitive

Coupling Modes n Definition: – A package of decisions about the interrelationships among ECA

Coupling Modes n Definition: – A package of decisions about the interrelationships among ECA components. n Example: – A condition should be evaluated immediately when the event is detected, delaying any other activity in the transaction.

Solution Problems n Coupling mode research prototypes express only a subset of design alternatives.

Solution Problems n Coupling mode research prototypes express only a subset of design alternatives. 1. 2. n Event/Condition/Action Systems designers might not employ design primitives / coupling modes correctly.

Author’s Proposed Solution n Self-tuning model for optimizing: 1. 2. 3. n n Response

Author’s Proposed Solution n Self-tuning model for optimizing: 1. 2. 3. n n Response time of system activities (esp. time critical) Storage space of system parameters/variables Goal (cost-benefit) function for system needs Uses independent, specified “goal function” Two-phase: 1. 2. Select from original coupling modes Select from new “coupling policies”

Original Coupling Modes n n n Immediate Deferred Detached Parallel Dependent Detached Sequential Dependent

Original Coupling Modes n n n Immediate Deferred Detached Parallel Dependent Detached Sequential Dependent Detached Independent

Coupling Mode Extension n Reason: – Provides a significant quantity of new possible combinations

Coupling Mode Extension n Reason: – Provides a significant quantity of new possible combinations – Allows for interrule coupling, i. e. , rule -> event -> rule n Basic Assumption: – Any ECA component can be located in any transaction, and any transaction can include any ECA component.

Coupling Policies (1) n Five coupling modes are extended to “coupling policies” Transaction 2.

Coupling Policies (1) n Five coupling modes are extended to “coupling policies” Transaction 2. Timing 3. Abort 4. Commit 5. Synchronization Let ‘X’ and ‘Y’ be various rule components (event, condition, action) 1. n

Coupling Policies (2) n The Transaction Policy – Partition ECA components into transactions –

Coupling Policies (2) n The Transaction Policy – Partition ECA components into transactions – X and Y are executed in same/different transaction n The Timing Policy – Temporal relationship between ECA execution times – Given X and Y are in the same transaction, Y is executed immediately/generally after X

Coupling Policies (3) n The Abort Policy – Abort dependencies among transactions that execute

Coupling Policies (3) n The Abort Policy – Abort dependencies among transactions that execute related components n The Commit Policy – A transaction may commit when it finishes, or wait for the commit of related transactions

Coupling Policies (4) The Synchronization Policy n – – The synchronization between components and

Coupling Policies (4) The Synchronization Policy n – – The synchronization between components and the conclusion of related transactions Seven possibilities n X Y n X Commit/Abort (Y Transaction) n Y Commit/Abort (X Transaction) n Commit/Abort (X Transaction) Y n Commit/Abort (X Transaction) Commit/Abort (Y Transaction) n Commit/Abort (Y Transaction) Commit/Abort (X Transaction) n No Synchronization

The Optimization Model

The Optimization Model

The Goal Function n Definition: – A function that the optimization model strives to

The Goal Function n Definition: – A function that the optimization model strives to minimize. n n n Independent of the solution’s algorithm Provided for every specific application Configured by system designer via GUI

Goal Function Establishment n Consider: – – – n Important activities for system evaluation

Goal Function Establishment n Consider: – – – n Important activities for system evaluation Negligible activities Parameter stabilization Parameter Measurement: – – – Time costs Rules probabilities Etc.

Conclusion n Author’s Further Research: – Creation/evaluation of specific goal functions – Establishment of

Conclusion n Author’s Further Research: – Creation/evaluation of specific goal functions – Establishment of appropriate learning mechanism