Den begivenhed forarbejdning og nogle interessante forespørgsler

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

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

Nogle mennesker er vendt tilbage fra ferie med et overskud af energi, ellers kan jeg ikke forklare, hvorfor min indbakke i dag var fyldt med mails fra samme tråd af drøftelsen på det evige Yahoo CEP interessegruppe trigerred af et spørgsmål sendt af Luis Poreza, en ph.d.-studerende fra universitetet i Coimbra i Portugal. Jeg tager en frihed til at omskrive det spørgsmål, da det blev formuleret som et spørgsmål i handelssystem, således nogle af de respondenter svarede i handel relaterede ting, som ikke bidrager til at besvare Luis 'spørgsmål, så at komme så langt væk som muligt fra aktiemarkedet, vil jeg basere rewriten spørgsmål i fiskemarked. Så historien er som følger: prisen på 1 kg fisk er fastsat i henhold til time, efterspørgsel, udbud og den generelle stemning af sælgeren. I 10:50 han denne pris som 71, så i 11:15 prisen var nede på 69 ikke flere ændringer af 12:00. Der er et edb-system, der fungerer i tid vinduer på en time startende hver time. Anmodningen er at finde ud af for den tid vinduet fra 11:00 til 12:00, om prisen på 1 kg fisk var stadig> 70. Påstanden er, at intuitivt svaret er ja, da prisen i intervallet [10:50, 11:15] var 71, men hvis vi ser på alle de begivenheder, der fandt sted i dette vindue, var der ingen tilfælde med værdi> 70, således løbende "vindue orienterede" værktøjer vil svare --- nej.

Der har været masser af svar, nogle endda forsøgt at besvare spørgsmålet, for eksempel ved at tilføje dummy begivenheder (en i slutningen af intervallet? Hvert minut?) Med værdien 71.

Men - jeg vil til at kræve følgende påstande:

(1). Kravet givet er ikke en begivenhed behandling mønster.
(2). Forsøg på at behandle det som begivenhed behandling mønstre er ikke meget nyttige.
(3). Det er i virkeligheden en slags tidsmæssig forespørgsel
(4). Der kan være en følelse at have kapacitet til at udstede tidsmæssige søgninger som en reaktion på begivenheder (AKA retrospektiv begivenhed behandling), men dette skal gøres rigtigt.

Påstand om en - kravet er ikke en begivenhed behandling mønster. Event behandling mønster er en funktion af begivenheder, er det ingen overraskelse, at Luis fundet nogle vanskeligheder at formulere det som sådan. Lad mig tage to andre eksempler, der ser syntaktisk det samme, og forsøge at forstå, hvad der er problemet her:

Det statslige organ eksempel: En offentlig myndighed er kendt for sin lange køer for at få service forsøger at kontrollere længden af køen. Jævne nogle degnen går ud og tæller antallet af mennesker, som venter i køen. I 10:50 fandt han 71 mennesker i køen, i 11:15 69 mennesker i køen, ikke flere prøver ved 12:00. Nu er spørgsmålet - om der er sket et eller andet tidspunkt i den tid vindue mellem [11:00, 12:00], hvor antallet af mennesker i køen> 70.

Før du starter diskussionen, lad os se på et andet eksempel, den bankkonto eksempel.

I 10:50 Mr. X har deponeret $ 30, hans tidligere balance var $ 41, som fik sin balance $ 71;
i 11:15 Mr. X har trukket $ 2, hans balance var sat til 69 dollar.

Fiskemarkedet eksempel ser ud fra syntaks synspunkt nøjagtig som køen overvågning eksempel, i begge tilfælde har vi begivenhederne i de timer, 10:50, 11:15 med attributter 71 og 69 hhv. De er dog ikke det samme, årsagen er, at prisen på fiskemarkedet er fastsat indtil ændret, men længden af køen kan være blevet ændret flere gange op og ned siden begivenheden her er kun en prøve, og dækker ikke alle hændelser. Begge disse begivenheder overholde nogle tilstand (pris eller længden af køen), men den semantik er helt anderledes. Hvis vi vil bruge løsningen af dummy begivenhed for køen tilfældet, så værdien vil sandsynligvis være forkert, desuden kan vi ikke rigtig svare på forespørgslen i køen tilfældet i "sande" eller "falske", men i virkeligheden, periodisk prøveudtagning er en helt gyldig type arrangementer. Desuden, hvis vi ser på en bankkonto eksempel, det ser meget anderledes fra fiskemarkedet eksempel - det er to typer af begivenheder, og de begivenheder, der ikke overholder en stat, men rapport om forandring, og rapporterer om ændringen værdi ( " delta "). Således ser på de to begivenheder af depositum og tilbagetrækning vil vi ikke være i stand til også at besvare spørgsmålet, men kender tilstand (saldoen på den konto) og delta (for deponering og tilbagetrækning) vi får noget, der er semantisk lignende til fiskemarkedet eksempel.

Hvad kan vi lære af disse eksempler? første, at ejendommen "værdien er den samme, indtil den ændres" er ikke en egenskab ved en attribut i tilfælde, det er ejet af staten (data), der kan oprettes eller opdateres af begivenheder. Dette er sandt for nogle statslige, er dette ikke tilfældet for andre. Løsning givet baseret på det faktum, at et menneske kender semantik i denne tilstand, og skriver ad hoc-forespørgsel. Men dette er behandlingen af staten, baseret på dens semantiske egenskaber, og ikke af begivenhederne.

Påstand to - Forsøg på at behandle det som hvis behandlingen ikke er nyttig.

I de sidste jeg har blogges om hammer og søm. Der er en tendens til fødslen af enhver, der har et produkt til at forsøge og stivelse dets grænser. Dette kan også give bagslag, for hvis der forsøger at gøre nogle funktioner, at dette produkt er god til, og ikke gør et stort arbejde, kan overskygge de gode dele af produktet. Løsning gerne tilføje "dummy begivenheder" er en form for hacking. Det misbrug begrebet begivenhed (da uvirksom begivenhed egentlig ikke ske), i øvrigt, i betragtning af at dette bare ad-hoc forespørgslen, og der kan være mange af sådanne forespørgsler, for at dække alle dem, vi måske eksponentiel nummer af dummy begivenheder ... Anyway-begivenhed behandling software er kun en del af større billede, og i stedet for at improvisere, hacking eller komme til denne funktionalitet, er det måske mere hensigtsmæssigt at bruge et produkt med bedre pasform.

Påstand tre - Dette krav er i virkeligheden en tidsmæssig forespørgsel. Jeg vil ikke komme ind på timelige søgninger nu, men selve forespørgslen er over prisen på 1 kg fisk, som ændret af tid. Det er en eksistentiel forespørgsel - leder, hvis nogle prædikat holder et sted i intervallet. Andet eksempel på tidsmæssige søgninger kan være: var der nogen dage i løbet af de sidste 30 dage, hvor kunden har trukket mere end $ 10.000 i en enkelt tilbagetrækning.

Og dette eksempel bringer os tilbage til påstanden om fire --- der kan være en mening at par tilfælde behandling software med tidsmæssige søgninger. Eksempel er, at vi har en begivenhed, der gør en kunde "mistænkelige" i mange penge, men vi må styrkes ved at se på nogle tidsmæssige søgninger i fortiden - som den ene skrevet ovenfor ... Jeg vil skrive om denne type funktionalitet i en senere fase.

Nå - det er 1:15, så jeg må hellere tage noget søvn, i morgen er der atter en travl dag. Så konklusion - ikke alt der ser enkel at gøre manuelt er enkel at ske ved en generisk form for tænkning, dels - hvis behandling software bør koncentrere sig om at gøre begivenheden behandling ret, og ikke laver andre ting forkert ... Nogle opfølgning blog-indlæg - senere

Kilde ...

Mere UNIX og Linux Forum Emner du måske kan finde Helpful
Tråd	Thread Starter	Forum	Svar	Last Post
På Event Processing Network og Transaction Processing	iBot	Complex Event Processing RSS Nyheder	0	10-04-2008 09:10 AM
CEP, Event Støj og Asymmetriske Event Processing	iBot	Complex Event Processing RSS Nyheder	0	10-02-2008 01:30 AM
Den kum BAI Ya af Event Processing	iBot	Complex Event Processing RSS Nyheder	0	09-01-2008 09:00 AM
Om Web 2.0 og Event Processing	iBot	Complex Event Processing RSS Nyheder	0	08-21-2008 10:20 PM
Simpelt Event Processing! \u003d Complex Event Processing	iBot	Complex Event Processing RSS Nyheder	0	12-16-2007 12:10 PM

Thread Tools	Søg denne tråd
Vis Printvenlig Version Email denne side	Søg denne tråd: Avanceret søgning
Display Modes	Bedøm denne tråd
Switch to Linear Mode Hybridtilstand Switch to Tråd Mode	Bedøm denne tråd:


	Powered by