FrontPage
11/26†
This Term†
- work on improving the performance of multiple queries
Next Term†
11/21†
This Term†
- work on improving the performance of multiple queries
- share the common sub query plan tree between different queries
- deal with the master/non-master conception
Next Term†
- make a slide and talk about it on the meeting
11/14†
This Term†
Next Term†
11/07†
This Term†
Next Term†
10/24†
This Term†
- revise the paper
- related works:STREAM,Discretized Streams,borealis,aurora,S4,esper,storm
Next Term†
10/03†
This Term†
- fix the bugs and finish the experiments
Next Term†
10/03†
This Term†
- perform the experiments to test the approaches
- write paper
Next Term†
09/26†
This Term†
- perform the experiments to test the approaches
- perform different experiments and vary the arguments of input rates, window size and duration time
- try to test the system for multiple queries
Next Term†
09/18†
This Term†
- implementation and experiment
Next Term†
08/28†
This Term†
- prepare for the integration seminar presentation
Next Term†
- present in the Fit conference
07/16†
This Term†
- prepare for the integration seminar presentation
Next Term†
- present in the cs seminar
07/11†
This Term†
- prepare for the integration seminar presentation
Next Term†
- present in the cs seminar
07/02†
This Term†
- write codes to support multiple queries
Next Term†
- go on with the codes and experiments
06/26†
This Term†
Next Term†
- modify the paper
- perform experiments
06/19†
This Term†
- improve the performance of JsSpinner
- talk about implementations of BSON in the meeting
Next Term†
- modify the codes about selection condition, calculation expression
06/12†
This Term†
Next Term†
06/05†
This Term†
Next Term†
05/29†
This Term†
Next Term†
05/22†
This Term†
- perform the experiment
- connection stream : non-master stream, input rate 100~15000 tuple/s (window size:100)
- log stream : master-stream, input rate is 1/1000 of the connection stream (window size:1)
- intended: with the increase of input rate of connection stream, the smart approach can deal with more input tuples than naive approach during some period
- problem : the input rate of connection stream generated is 15000 tuple/s at most, the system can catch up with this input rate no matter smart or naive approach. So there is no difference. The system is about to catch up with 25000 tuple/s for a complex query.
- think: the system goes wrong when the system input rate is high, I want to fix this problem and increase the input rate
Next Term†
05/16†
This Term†
Next Term†
05/9†
This Term†
Next Term†
05/1†
This Term†
Next Term†
04/24†
This Term†
- upload the program on the github
- fix some bugs
- talk with Nishimura-san
- perform the experiment
Next Term†
![[PukiWiki]](image/kde_logo.gif "[PukiWiki]"){kind=logo}
