På händelsehantering och några intressanta frågor

iBot · #1 (**permalänk**) 01-06-2009

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

Vissa människor har återvänt från semester med ett överskott av energi, annars kan jag inte förklara varför min inkorg i dag var fylld av brev från samma tråd för diskussion i den eviga Yahoo CEP intressegrupp trigerred av en fråga skickas med Luis Poreza, doktorand från universitetet i Coimbra i Portugal. Jag tar en frihet att skriva om frågan, eftersom den var formulerad som en fråga i handelssystemet, alltså, några av respondenterna svarade i handeln related stuff det hjälpte inte att besvara Luis "fråga, så att komma så långt bort som möjligt från aktiemarknaden kommer jag basera rewriten frågan på fiskmarknaden. Så historien är följande: priset på 1 kg fisk bestäms med hänsyn till tid, efterfrågan, utbudet och den allmänna stämningen av säljaren. I 10:50 han gjorde detta pris som 71, sedan 11:15 priset var nere på 69 inga fler förändringar av 12:00. Det finns ett datoriserat system som fungerar i tidsfönster på en timme startar varje timme. Begäran är att ta reda på det tidsintervall från 11:00 till 12:00 om priset på 1 kg fisk var någonsin> 70. Påståendet är att intuitivt svaret är ja, eftersom priset i intervallet [10:50, 11:15] var 71, men om vi tittar på alla de händelser som inträffade vid fönstret fanns det ingen händelse med värde> 70, alltså nuvarande "gyllene orienterade" verktyg svarar --- nej.

Det har funnits gott om svar, en del försökte även att besvara frågan, till exempel genom att lägga provdocka händelser (en i slutet av intervallet? Varje minut?) Med värdet 71.

Men - Jag kommer att göra anspråk på följande påståenden:

(1). Kravet ges är inte en händelse bearbetning mönster.
(2). Försök att behandla det som händelsehantering mönster är inte särskilt användbar.
(3). Det är i själva verket ett slags temporal query
(4). Det kan finnas en mening har möjlighet att utfärda tidsmässiga frågor som en reaktion på händelser (AKA retrospektiv händelsehantering) men detta måste göras rätt.

Påstående ett - kravet är inte en händelse bearbetning mönster. Händelsehantering mönster är en funktion av händelser, är det ingen överraskning att Luis fann vissa svårigheter att formulera det så. Låt mig ta två exempel som ser syntaktiskt samma och försöka förstå vad som är problemet här:

Den myndighet exempel: En myndighet känd för sin långa köer skaffa service försöker kontrollera längden på kön. Periodvis några kontorist går ut och räknar antalet människor som väntar i kön. I 10:50 fann han 71 personer i kön, i 11:15 69 personer i kö, inga fler prover från 12:00. Nu är frågan - huruvida det har skett någon gång under det tidsintervall mellan [11:00, 12:00] där antalet personer i kön> 70.

Innan du börjar diskussionen, låt oss titta på ett annat exempel, det bankkonto exempel.

I 10:50 Mr X har satt in $ 30, hans tidigare balansen var $ 41, vilket gjorde hans balans $ 71;
på 11:15 Mr X har återkallat $ 2, hans balans var satt till $ 69.

Fiskmarknaden exemplet ser ut syntax synvinkel exakt samma kön övervakning exempel i båda fallen har vi händelserna i timmar 10:50, 11:15 med attribut 71 och 69. De är dock inte samma sak, anledningen till att priset på fiskmarknaden är fast till och förändrats, medan längden på kön kan ha ändrats flera gånger upp och ner eftersom händelsen är här bara ett urval och omfattar inte alla händelser. Båda dessa händelser se vissa tillstånd (pris eller längd på kön), men semantik är helt annorlunda. Om vi använder den lösning av bulvaner händelse för kön fall då värdet troligen kommer att bli fel, dessutom kan vi egentligen inte svara på frågan i kön fall i "sann" eller "falskt", men i verkligheten Regelbunden provtagning är en helt giltig typ av händelser. Dessutom, om vi tittar på det bankkonto som exempel, det ser väldigt annorlunda från fiskmarknaden exempel - det har två typer av händelser och evenemang som inte följer en stat, men om förändring, och rapportera ändra värdet ( " Delta "). Med avseende på de två händelserna insättning och uttag vi inte också kunna besvara frågan, men vet staten (saldot på kontot) och delta (för insättning och uttag) får vi något som är semantiskt liknande till fiskmarknaden exempel.

Vad kan vi lära av dessa exempel? först att fastigheten "värdet är detsamma tills den ändras" är inte en egenskap hos ett attribut i händelse är det statens egendom (data) som kan skapas eller uppdateras av händelser. Detta är sant för någon stat, är detta inte sant för andra. Lösningen ges baserat på det faktum att en människa känner semantiken i denna stat, och skriver ad-hoc-fråga. Men detta är behandlingen av staten, baserat på dess semantiska egenskaper, och inte av händelserna.

Påstående två - Försök att behandla det som händelsehantering är inte användbar.

Under de senaste jag har bloggat om hammaren och spiken. Det finns en natal tendens alla som har en produkt att försöka stärkelse dess gränser. Detta kan också slå tillbaka, eftersom om att försöka göra några funktioner som denna produkt är bra på, och inte jobbar hårt kan överskugga de goda delarna av produkten. Lösning som lägger till "dummy händelser" är en slags hacking. Det missbruk av begreppet händelse (eftersom dummy fall inte riktigt hända), dessutom med tanke på att detta bara är ad-hoc-fråga, och det kan finnas många sådana frågor, i syfte att täcka alla dem, kan vi behöva exponential nummer av attrapp händelser ... Anyway-event programvara är bara en del av helheten, och istället för att improvisera, hacking eller komma till denna funktion, kan det vara lämpligt att använda en produkt med bättre passform.

Påstående tre - Detta krav är i själva verket en tidsmässig fråga. Jag kommer inte att gå in timliga frågor nu, men den verkliga frågan är om priset på 1 kg fisk som förändrats med tiden. Det är en existentiell fråga - ser om vissa predikat håller någonstans i intervallet. Andra exempel på temporal frågor kan vara: var det någon dag under de senaste 30 dagarna där kunden har återkallat mer än $ 10.000 i en och samma uttag.

Och det här exemplet för oss tillbaka till påståendet fyra --- det kan finnas en mening med att par händelse programvara med temporal queries. Exempel är att vi har en händelse som gör en kund "misstänkt" i många tvättning, men vi behöver förstärkning genom att titta på några tidsmässiga frågor i det förflutna - som den som skrivs ovan ... Jag ska skriva om denna typ av funktionalitet i ett senare skede.

Tja - det är 1:15, så jag är bäst att ta lite sömn, imorgon är åter en hektisk dag. Så slutsatsen - inte allt som verkar enkel att göra manuellt är enkel att ske genom en allmän typ av tänkande, andra - programvara vid behandling bör inriktas på att göra rätt händelsehantering, och inte gör andra saker fel ... Viss uppföljning blogginlägg - senare

Källa ...

Mer UNIX och Linux Forum Ämnen Du kan hitta Helpful
Tråd	Thread Starter	Forum	Svar	Senaste Inlägg
På Event Processing Network och Transaction Processing	iBot	Complex Event Processing RSS Nyheter	0	10-04-2008 10:10
CEP, Event Buller och Asymmetrisk Event Processing	iBot	Complex Event Processing RSS Nyheter	0	10-02-2008 02:30
Den Kum Bai Ya av Event Processing	iBot	Complex Event Processing RSS Nyheter	0	09-01-2008 10:00
På Web 2.0 och Event Processing	iBot	Complex Event Processing RSS Nyheter	0	08-21-2008 11:20
Enkel Event Processing! \u003d Complex Event Processing	iBot	Complex Event Processing RSS Nyheter	0	12-16-2007 12:10

Thread Tools	Sök i denna tråd
Visa Utskriftsversion Mejla den här sidan	Sök i denna tråd: Avancerad sökning
Visningslägen	Betygsätt denna tråd
Switch to Linear Mode Switch to Hybrid Mode Gängade Mode	Betygsätt denna tråd:


	Powered by