På arrangementet behandling og noen interessante spørsmål

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

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

Noen mennesker har returnert fra ferie med et overskudd av energi, ellers kan jeg ikke forklare hvorfor innboksen min i dag var full av post fra samme tråd for diskusjon i det evige Yahoo CEP interesseorganisasjon trigerred av et spørsmål sendt av Luis Poreza, en graduate student fra Universitetet i Coimbra i Portugal. Jeg tar en frihet til å omskrive spørsmålet siden den ble formulert som et spørsmål i handelssystem dermed noen av de reagerer besvart i handel relaterte ting som ikke hjelper å svare Luis 'spørsmål, så å komme så langt unna som mulig fra aksjemarkedet, vil jeg basere rewriten spørsmålet på fisketorget. Så historien er som følger: prisen på 1 kg fisk er fastsatt i henhold til time, etterspørselen, tilbudet og den generelle stemningen av selgeren. I 10:50 gjorde han denne prisen som 71, så i 11:15 var prisen ned til 69 noen flere endringer etter 12:00. Det er et datastyrt system som fungerer i tid vinduer i én time starter hver time. Forespørselen er å finne ut om det tidsvinduet 11:00 til 12:00 om prisen av 1 kg fisk ble stadig> 70. Påstanden er at intuitivt svaret er ja, siden kursen i intervallet [10:50, 11:15] var 71, men hvis vi ser på alle de hendelsene som skjedde i dette vinduet, det var ikke tilfelle med verdi> 70, dermed gjeldende "vindu orientert" verktøyene vil besvare --- nei.

Det har vært mange svar, noen også forsøkt å besvare spørsmålet, for eksempel ved å legge Dummy hendelser (ett på slutten av intervallet? Hvert minutt?) Med verdien 71.

Men - jeg skal kreve følgende påstander:

(1). Kravet gitt er ikke en hendelse behandling mønster.
(2). Forsøk på å behandle det som event behandling mønstre er ikke veldig nyttig.
(3). Det er faktisk en slags verdslig søket
(4). Det kan være fornuftig å ha evne til å utstede timelige spørringer som en reaksjon på hendelser (AKA retrospektiv begivenhet behandling), men dette må gjøres riktig.

Påstand one - kravet er ikke en hendelse behandling mønster. Event prosessering mønsteret er en funksjon av begivenheter, er det ingen overraskelse at Luis funnet noen problemer med å setning det som sådan. La meg ta to eksempler som ser syntactically samme og prøve å forstå hva som er problemet her:

Regjeringen byrået eksempel: Et offentlig organ kjent for sine lange køer for å få tjenesten forsøker å overvåke lengden på køen. Periodisk noen clerk går ut og teller antall personer som venter i køen. I 10:50 fant han 71 personer i køen, i 11:15 69 personer i køen, ingen flere prøver med 12:00. Nå er spørsmålet - om det har vært noen mening i det tidsvinduet mellom [11:00, 12:00] hvor mange mennesker i køen> 70.

Før du starter diskusjonen, la oss se på et annet eksempel bankkontoen eksempel.

I 10:50 Mr. X har avsatt $ 30, hans tidligere balansen var på $ 41, som gjorde sin balanse $ 71;
i 11:15 Mr. X har trukket $ 2, hans balanse er satt til $ 69.

Fisketorget eksempel ser fra syntaks synspunkt akkurat som køen overvåking eksempel, i begge tilfeller har vi arrangementer i timene 10:50, 11:15 med attributter 71 og 69 hhv. Men de er ikke det samme, er grunnen til at prisen på fisketorget er fast inntil endres, mens lengden på køen kan ha blitt endret flere ganger opp og ned etter hendelsen er her bare et eksempel, og dekker ikke alle hendelser. Begge disse hendelsene observere noen stat (pris og lengden på køen), men semantikk er ganske annerledes. Hvis vi vil bruke løsningen av dummy begivenhet for køen tilfellet da verdien vil sannsynligvis være galt, dessuten kan vi egentlig ikke svare på spørsmål i køen saken i "true" eller "false", men i realiteten periodisk prøvetaking er en helt gyldig type hendelser. Dessuten, hvis vi ser på bankkontoen eksempel, ser det svært forskjellig fra fisketorget eksempel - det har to typer arrangementer, og hendelsene ikke observerer en stat, men rapport om endring, og rapportere endre verdien ( " Delta "). Dermed ser på de to hendelsene i innskudd og uttak vil vi ikke være i stand til også å besvare spørsmålet, men megetsigende staten (saldo på kontoen) og Delta (for innskudd og uttak) vi får noe som er semantisk like til fisketorget eksempel.

Hva kan vi lære av disse eksemplene? først at eiendommen "verdien er den samme før det er forandret" er ikke en egenskap ved et attributt i tilfelle, er det eiendommen av staten (data) som kan opprettes eller oppdateres ved hendelser. Dette gjelder for noen stat, dette er ikke sant for andre. Løsning gitt basert på det faktum at et menneske kjenner semantikken av denne tilstanden, og skriver ad-hoc spørring. Men dette er behandling av staten, basert på semantiske egenskaper, og ikke av hendelsene.

Påstand to - Forsøk på å behandle det som hendelsen behandlingen ikke er nyttig.

I det siste har jeg blogged om hammeren og spikeren. Det er en natal tendens noen som har et produkt å prøve og stivelse sine grenser. Dette kan også slå tilbake, siden hvis prøver å gjøre noen funksjoner som dette produktet er god på, og ikke gjør store verk kan overskygge de gode delene av produktet. Løsning som å legge "dummy hendelser" er en form for hacking. Det overgrep forestillingen om hendelsen (siden dummy hendelsen ikke egentlig skje), dessuten gitt det faktum at dette bare er ad-hoc spørring, og det kan være mange slike søk, for å dekke alle dem, trenger vi eksponentiell nummer av dummy hendelser ... Allikevel-event tekstbehandleren er bare en del av større bilde, og i stedet for å improvisere, hacking eller få til denne funksjonaliteten, kan det være mer fornuftig å bruke et produkt med bedre passform.

Påstand tre - Dette kravet er faktisk en timelig søk. Jeg vil ikke tråkke i timelige søk nå, men selve spørringen er over prisen på 1 kg fisk som endres etter tid. Det er et eksistensielt spørsmål - så hvis noen predikat holder sted i intervallet. Andre eksempler på timelige spørsmål kan være: var det noen dager i løpet av de siste 30 dagene der kunden har trukket mer enn $ 10000 i et enkelt uttak.

Og dette eksemplet bringer oss tilbake til påstanden fire --- det kan være fornuftig å par hendelse prosessering programvare med timelige spørringer. Eksempel er at vi har et arrangement som gjør en kunde "mistenkt" i mange av penger, men vi trenger forsterkning ved å se på noen timelige søk i fortiden - som den som skrevet ovenfor ... Jeg skal skrive om denne typen funksjonalitet i en senere fase.

Vel - det er 1:15, så jeg bør nok ta litt søvn, er i morgen igjen en travel dag. Så konklusjonen - ikke alt som ser enkelt å gjøre manuelt, er enkelt å bli gjort av en generisk type tenkning, andre - event prosessering programvare bør konsentrere seg om å gjøre arrangementet behandling høyre, og ikke gjør andre ting galt ... Noen oppfølging Blogg innlegg - senere

Kilde ...

Mer UNIX og Linux Forum Emner Du kan finne nyttig
Tråd	Tråd startet	Forum	Svar	Siste innlegg
På Event Processing Nettverk og transaksjonsbehandling	iBot	Complex Event Processing RSS Nyheter	0	10-04-2008 09:10
CEP, Event støy og Asymmetriske Event Processing	iBot	Complex Event Processing RSS Nyheter	0	10-02-2008 01:30
Den Kum Bai Ya of Event Processing	iBot	Complex Event Processing RSS Nyheter	0	09-01-2008 09:00
På Web 2.0 og Event Processing	iBot	Complex Event Processing RSS Nyheter	0	08-21-2008 10:20
Enkelt Event Processing! \u003d Complex Event Processing	iBot	Complex Event Processing RSS Nyheter	0	12-16-2007 12:10

Thread Tools	Søk i denne tråden
Vis Printable Version Email denne siden	Søk i denne tråden: Avansert søk
Visningsmoduser	Ranger denne tråden
Switch to Linear Mode Bytt til hybridmodus Gjengede Mode	Ranger denne tråden:


	Powered by