Op gebeurtenis verwerken en een aantal interessante vragen - De UNIX-en Linux Forum

iBot · #1 (**permalink**) 01-06-2009

2009-01-05T23: 45:00.017 +02:00

Sommige mensen zijn teruggekeerd van de vakantie met een overschot aan energie, anders kan ik niet uitleggen waarom mijn inbox vandaag was vol met mails van dezelfde draad van discussie in de eeuwige Yahoo CEP interest group trigerred door een vraag gestuurd door Luis Poreza, een afgestudeerde student van de Universiteit van Coimbra in Portugal. Ik ben het nemen van een vrijheid te herschrijven omdat het de vraag is geformuleerd als een vraag in de regeling voor de handel, dus een deel van de responders beantwoord in de handel gerelateerde spullen die niet bijdragen aan Luis vraag 'te beantwoorden, zodat je zo ver weg als mogelijk van de beurs, zal ik de basis van de rewriten vraag in de vismarkt. Dus het verhaal is als volgt: de prijs van 1 kg vis wordt bepaald volgens het uur, de vraag, het aanbod en de algemene stemming van de verkoper. In 10u50 maakte hij deze prijs als 71, vervolgens in 11:15 de prijs was gedaald tot 69 geen veranderingen meer door 12:00. Er is een geautomatiseerd systeem dat werkt in de tijd ramen van een uur starten elk uur. Het verzoek is om uit te vinden voor de tijd venster 11u00-12u00 of de prijs van 1 kg vis ooit> 70. De bewering is dat intuïtief het antwoord ja is, aangezien de prijs in het interval [10:50, 11:15] was 71, maar als we kijken naar alle evenementen die zich op dit raam was er geen evenement met een waarde> 70, dus huidige "venster georiënteerde" tools zal beantwoorden --- no.

Er zijn veel van de antwoorden zijn, sommigen zelfs geprobeerd om de vraag te beantwoorden, bijvoorbeeld door toevoeging van dummy gebeurtenissen (een aan het eind van het interval? Elke minuut?) Met de waarde 71.

Maar - ik ga de vordering van de volgende stellingen:

(1). De gegeven eis is niet een gebeurtenis verwerking patroon.
(2). Pogingen om te behandelen als event processing patronen zijn niet erg nuttig.
(3). Het is in feite een soort van tijdelijke query
(4). Er kan een gevoel te hebben de mogelijkheid om tijd te vragen als een reactie op gebeurtenissen (AKA retrospectief evenement verwerking) probleem, maar dit moet recht worden gedaan.

Assertion een - de eis is niet een gebeurtenis verwerking patroon. Event verwerking patroon is een functie van de gebeurtenissen, is het geen verrassing dat Luis vond enkele moeite om woorden als zodanig. Laat me twee andere voorbeelden die syntactisch zien er hetzelfde uit en proberen te begrijpen wat het probleem is hier:

De overheidsinstelling voorbeeld: Een overheidsinstelling bekend om zijn lange wachtrijen bij het verkrijgen van dienst probeert te zien op de lengte van de wachtrij. Periodiek sommige klerk gaat uit en telt het aantal wachtenden in de wachtrij. In 10:50 vond hij 71 mensen in de wachtrij, in 11:15 69 mensen in de wachtrij, niet meer monsters van 12:00. Nu is de vraag - of er sprake is van een bepaald punt in het tijdsinterval tussen [11:00, 12:00 is], waarin het aantal mensen in de wachtrij> 70.

Voordat de discussie, laten we eens kijken naar een ander voorbeeld, de bankrekening voorbeeld.

In 10:50 Mr X heeft neergelegd $ 30, zijn vorige saldo was 41 dollar, die zijn evenwicht 71 dollar gemaakt;
in 11:15 Mr X heeft teruggetrokken $ 2, zijn evenwicht is ingesteld op 69 dollar.

De vismarkt voorbeeld ziet van de syntaxis oogpunt precies zoals de wachtrij toezicht bijvoorbeeld in beide gevallen hebben we de gebeurtenissen in de uren 10:50, 11:15 met attributen 71 en 69 respectievelijk. Zij zijn echter niet hetzelfde, de reden is dat de prijs in de vismarkt is vast tot veranderd, terwijl de lengte van de wachtrij kunnen zijn meerdere keren veranderd op en neer omdat het evenement is hier slechts een steekproef en niet op alle evenementen. Beide gebeurtenissen observeren sommige toestand (de prijs of de lengte van de wachtrij), maar de semantiek is heel anders. Als we de oplossing van pop evenement zullen gebruiken voor de wachtrij geval dan is de waarde zal waarschijnlijk verkeerd zijn, bovendien kunnen we niet echt antwoord geven op de vraag in de wachtrij geval in "true" of "false", maar in werkelijkheid periodieke bemonstering is een volledig geldig type van evenementen. Bovendien, als we kijken naar de bankrekening voorbeeld, het ziet er heel anders uit de vismarkt bijvoorbeeld - het heeft twee soorten van gebeurtenissen, en de gebeurtenissen niet in acht geen staat, maar over de verandering, en het verslag van de verandering waarde ( " delta "). Zo kijken de twee gebeurtenissen van nederlegging en intrekking we niet in staat zijn om ook de vraag te beantwoorden, maar kennen van de staat (saldo van de rekening) en de delta (voor de borg en intrekking) krijgen we iets dat vergelijkbaar is semantisch de vismarkt voorbeeld.

Wat kunnen we leren uit deze voorbeelden? de eerste plaats dat het pand "de waarde is hetzelfde totdat het wordt gewijzigd" is niet een eigenschap van een attribuut in geval is het eigendom van de staat (gegevens) die kunnen worden gemaakt of aangepast door de gebeurtenissen. Dit geldt voor sommige staat, geldt dit niet voor anderen. Oplossing gegeven gebaseerd op het feit dat een mens weet dat de semantiek van deze staat, en schrijft ad-hoc query. Dit is echter de verwerking van de staat, op basis van de semantische eigenschappen, en niet van de gebeurtenissen.

Assertion twee - Pogingen om te behandelen als event processing is niet nuttig.

In het verleden heb ik geblogd over de hamer en de nagel. Er is een geboorte neiging van iemand die heeft een product te proberen en zetmeel zijn grenzen. Dit kan ook een averechts effect, want als proberen om een aantal functies dat dit product is goed in doen, en niet te doen geweldig werk kan overschaduwen de goede delen van het product. Oplossing, zoals het toevoegen van "dummy evenementen" is een soort van hacking. Het misbruik maakt van de notie van het evenement (sinds dummy geval niet echt gebeuren), overigens, gezien het feit dat dit slechts ad-hoc query, en er kan veel van dergelijke vragen, om ter dekking van alle hen, moeten we misschien exponentieel aantal dummy van evenementen ... Anyway-event processing software is slechts een deel van groter geheel, en in plaats van improviseren, hacking of om aan deze functionaliteit, kan het meer aan te raden om een product te gebruiken met een betere pasvorm.

Assertion drie - Deze eis is in feite een tijdelijke query. Ik zal niet te krijgen in de tijd queries nu, maar de eigenlijke vraag is over de prijs van 1 kg vis, zoals gewijzigd door de tijd. Het is een existentiële vraag - op zoek als sommige predikaat houdt ergens in het interval. Ander voorbeeld van temporele vragen kunnen zijn: was er elke dag gedurende de laatste 30 dagen waarin de klant zich heeft teruggetrokken meer dan 10.000 dollar in een terugtrekking.

En dit voorbeeld brengt ons terug naar de stelling van vier --- er kan een gevoel te koppelen event processing software met temporele queries worden. Voorbeeld is dat we een evenement dat een klant "maakt verdachte" in veel geld, maar we moeten versterken door te kijken naar een aantal temporele vragen in het verleden - zoals die hierboven geschreven ... Ik schrijf over dit type functionaliteit in een latere fase.

Nou - het is 1:15, dus ik neem maar beter wat te slapen, morgen is weer een drukke dag. Dus conclusie - niet alles dat lijkt simpel om te doen is eenvoudig handmatig worden gedaan door een algemene soort van denken, tweede - event processing software moet concentreren op het doen event processing recht en niet het doen van andere dingen verkeerd ... Sommige follow-up Blog postings - later

Bron ...

Meer UNIX en Linux Forum Onderwerpen Misschien vindt u Helpful
Draad	Thread Starter	Forum	Antwoorden	Last Post
Op Event Processing Netwerk en Transaction Processing	iBot	Complex Event Processing RSS Nieuws	0	10-04-2008 09:10
CEP, Event Geluid en Asymmetrisch Event Processing	iBot	Complex Event Processing RSS Nieuws	0	10-02-2008 01:30
De Kum Bai Ya van Event Processing	iBot	Complex Event Processing RSS Nieuws	0	09-01-2008 09:00
On Web 2.0 en Event Processing	iBot	Complex Event Processing RSS Nieuws	0	08-21-2008 10:20 PM
Simple Event Processing! \u003d Complex Event Processing	iBot	Complex Event Processing RSS Nieuws	0	12-16-2007 12:10

Thread Tools	Zoeken in deze Thread
Toon Printversie E-mail deze pagina	Zoeken in deze Thread: Uitgebreid zoeken
Display Modes	Beoordeel deze draad
Switch to Linear Mode Switch to Hybrid Mode Threaded Mode	Beoordeel deze draad:


	Powered by