The UNIX and Linux Forums  


Go Back   UNIX e Linux Forum > Special Forum > UNIX e Linux Applicazioni > Complex Event Processing RSS News
.
google unix.com



Complex Event Processing RSS News Aggregate RSS notizie su CEP, ESP e PE.

Più di UNIX e Linux Forum Argomenti potreste trovare utili
Filo Thread Starter Forum Risposte Ultimo Post
Il trattamento di eventi di rete e l'elaborazione delle transazioni iBot Complex Event Processing RSS News 0 10-04-2008 10:10 AM
CEP, evento di rumore e di elaborazione di eventi asimmetrica iBot Complex Event Processing RSS News 0 10-02-2008 02:30 AM
Il Kum Bai Ya Elaborazione di eventi iBot Complex Event Processing RSS News 0 09-01-2008 10:00 AM
Il Web 2.0 e degli Eventi di elaborazione iBot Complex Event Processing RSS News 0 08-21-2008 11:20 PM
Simple Event Processing! \u003d Complex Event Processing iBot Complex Event Processing RSS News 0 12-16-2007 12:10 PM

Closed Thread
English Japanese Spanish French German Portuguese Italian Dutch Swedish Russian Norwegian Hungarian Hebrew Danish Bulgarian Greek Powered by Powered by Google
 
LinkBack Thread Tools Cerca in questo Thread Rate Thread Modalità di visualizzazione
  #1 (permalink)  
Old 01-06-2009
iBot's Avatar
iBot iBot is offline
Forum Robot Girl
  
 

Join Date: Sep 2000
Messaggi: 22.216
Il caso di trasformazione e di alcune interessanti ricerche

2009-01-05T23: 45:00.017 +02:00
Alcune persone hanno fatto ritorno dalla vacanza, con un surplus di energia, altrimenti non riesco a spiegare il motivo per cui oggi la mia casella di posta era piena di messaggi provenienti dallo stesso thread di discussione in eterno Yahoo CEP gruppo d'interesse trigerred da una domanda inviata da Luis Poreza, uno studente laureato presso l'Università di Coimbra in Portogallo. Sono una libertà di ri-scrittura, dato che la questione era formulata come una questione di sistema di scambio, di conseguenza, alcuni dei responder risposto in negoziazione connessi roba che non aiutano a rispondere a Luis' questione, ottenendo così il più lontano possibile dal mercato azionario, io base rewriten la questione nel mercato del pesce. Così la storia è la seguente: il prezzo di 1 kg di pesce è determinata secondo le ore, la domanda, la fornitura e l'umore generale del venditore. In 10:50 ha fatto il prezzo di 71, poi a 11:15 il prezzo è sceso a 69 non cambia da 12:00. Vi è un sistema che funziona in tempo finestre di un'ora di partenza ogni ora. La richiesta è quella di trovare il tempo per finestra 11:00 - 12:00 se il prezzo di 1 kg di pesce è sempre> 70. La richiesta è intuitivo che la risposta è sì, dal momento che il prezzo per l'intervallo [10:50, 11:15] è 71, ma se guardiamo a tutti gli eventi che si sono verificati in questa finestra vi è stato nessun caso con valore> 70, così attuale "finestra orientata" strumenti --- nessuna risposta.

Ci sono state molte risposte, alcune anche cercato di rispondere alla domanda, per esempio con l'aggiunta di manichino eventi (uno alla fine del l'intervallo? Ogni minuto?) Con il valore 71.

Tuttavia - mi recherò a rivendicare le seguenti affermazioni:

(1). L'obbligo dato non è un evento di trasformazione del modello.
(2). I tentativi di trattare come evento di trasformazione modelli non sono molto utili.
(3). Si tratta infatti di una sorta di ricerca temporale
(4). Ci può essere un senso di avere la capacità di emettere temporale query come una risposta agli eventi (AKA retrospettiva caso di trasformazione), ma questo deve essere fatto a destra.

Uno affermazione - il requisito non è un evento di trasformazione del modello. Evento di trasformazione del modello è una funzione di eventi, non è sorpresa che Luis trovato qualche difficoltà di espressione in quanto tale. Permettetemi di prendere altri due esempi che sembrano sintatticamente lo stesso e cercare di capire qual è il problema qui:



L'agenzia governativa esempio: un ente conosciuto per le sue lunghe code per ottenere il servizio cerca di controllare la lunghezza della coda. Periodicamente alcuni impiegato esce e conta il numero di persone in attesa nella coda. In 10:50 ha trovato 71 persone in coda, a 11:15 69 persone in coda, non più da campioni 12:00. Ora la questione è - se vi sia stato un certo punto nella finestra temporale tra il [11:00, 12:00] in cui il numero di persone in coda> 70.

Prima di iniziare la discussione, diamo un'occhiata a un altro esempio, il conto bancario esempio.
In 10:50 Mr. X ha depositato $ 30, il suo precedente bilancio è stato di $ 41, che ha reso il suo equilibrio $ 71;
11:15 in Mr. X ha ritirato $ 2, il suo equilibrio è stato fissato a $ 69.

Il mercato del pesce esempio guarda dal punto di vista della sintassi esattamente come la coda di monitoraggio esempio, in entrambi i casi ci sono eventi in ore 10:50, 11:15 con attributi di 71 e 69 rispettivamente. Tuttavia, essi non sono gli stessi, il motivo è che il prezzo del mercato del pesce è fissata fino al cambiata, mentre la lunghezza della coda di maggio sono state modificate diverse volte in alto e in basso in quanto il caso è solo un campione e non coprire tutti gli eventi. Entrambi questi eventi osservare alcuni Stato (o di coda di lunghezza), ma la semantica è molto diversa. Se si utilizza la soluzione di manichino caso per caso la coda quindi il valore sarà probabilmente sbagliato, inoltre, non si può davvero rispondere alla richiesta nel caso in coda "vero" o "false", ma, in realtà, campionamento periodico è un tipo del tutto valida di eventi. Inoltre, se guardiamo al conto corrente bancario esempio, appare molto diverso da esempio il mercato del pesce - ha due tipi di eventi, e gli eventi non rispettano uno Stato, ma di relazione sul cambiamento, e di riferire il cambiamento di valore ( " delta "). Pertanto, guardando i due eventi di deposito e di ritiro noi non essere in grado anche di rispondere alla domanda, ma conoscendo lo stato (saldo del conto) e delta (per il deposito e il ritiro) ci sono sempre qualcosa che è semanticamente simili per esempio il mercato del pesce.

Che cosa possiamo imparare da questi esempi? prima che la proprietà "il valore è lo stesso fino a quando non è cambiato" non è una proprietà di un attributo nel caso, è di proprietà dello Stato (dati) che possono essere creati o aggiornati dagli eventi. Questo è stato vero per alcuni, questo non è vero per gli altri. Soluzione dato sulla base del fatto che l'uomo conosce la semantica di questo stato, e scrive di query ad-hoc. Tuttavia, questa è la trasformazione dello Stato, sulla base delle sue proprietà semantica, e non dei fatti.

Affermazione due - i tentativi di trattare come evento di trasformazione non è utile.

In passato ho blog circa il martello e il chiodo. Vi è una tendenza natale di chi ha un prodotto e l'amido di provare i suoi confini. Questo può anche ritorcersi contro, dal momento che, se cerchiamo di fare alcune funzioni che questo prodotto è bene, e non facendo grande lavoro può oscurare la buona parte del prodotto. Soluzione, come l'aggiunta di "manichino eventi" è una sorta di "hacking". Si abusa del concetto di evento (dal manichino caso non ha realmente accadere), inoltre, considerato il fatto che si tratta solo di query ad-hoc, e non ci possono essere molte di queste domande, in modo da coprire tutti i loro, possiamo aver bisogno esponenziale il numero manichino di eventi ... Comunque l'evento di trasformazione del software è solo una parte di immagine più grande, e invece di improvvisazione, di hacking o di arrivare a questa funzionalità, può essere più consigliabile utilizzare un prodotto con una migliore vestibilità.


Tre affermazione - Questo requisito è in realtà un temporale query. Non voglio entrare in temporale query adesso, ma la richiesta è superiore al prezzo di 1 kg di pesce, come modificato dal tempo. Si tratta di una ricerca esistenziale - guardando se alcuni predicato detiene in qualche parte l'intervallo. Altro esempio di query temporale può essere: ogni giorno vi è stato nel corso degli ultimi 30 giorni in cui il cliente ha ritirato più di $ 10.000 in un solo ritiro.

E questo esempio ci riporta a quattro --- affermazione ci può essere un senso alla matura caso di trasformazione del software con temporali query. Esempio è che abbiamo un evento che rende un cliente "sospetti" in molti di denaro, ma abbiamo bisogno di rafforzare guardando qualche temporale query in passato - come quello scritto sopra ... I'll scrivere su questo tipo di funzionalità in una fase successiva.

Ebbene - è 1:15 AM, quindi meglio prendere alcuni dormire, domani è di nuovo una giornata impegnativa. Quindi la conclusione - non tutto ciò che sembra semplice da fare manualmente è semplice da fare con un pensiero di tipo generico, il secondo - caso di trasformazione del software dovrebbe concentrarsi su questo caso di trasformazione a destra, e non fare altre cose sbagliate ... Alcuni Blog di follow-up post - dopo


Fonte ...
Closed Thread

Segnalibri

Thread Tools Cerca in questo Thread
Cerca in questo Thread:

Ricerca Avanzata
Modalità di visualizzazione Vota questo thread
Vota questo thread:

Distacco regolamento
Tu non può post nuovo thread
Tu non può inviare una risposta
Tu non può postare allegati
Tu non può modificare i tuoi post

BB codice è Su
Smilies sono Su
[IMG] codice Su
Codice HTML è Chiuso
Trackbacks sono Su
Pingbacks sono Su
Refbacks sono Su




Tutti gli orari sono GMT -4. La data di oggi è 04:05 AM.


Powered by: vBulletin, Copyright © 2000 - 2006, Jelsoft Enterprises Limited. Traduzioni Powered by .
vBCredits v1.4 Copyright © 2007 - 2008, PixelFX Studios
UNIX e Linux Forum Content Copyright © 1993-2009. Tutti i diritti Reserved.Ad di gestione da RedTyger

Contenuti pertinenti URL da vBSEO 3.2.0