Hi Srinath,
On Fri, Mar 14, 2014 at 6:22 PM, Srinath Perera <[email protected]> wrote: > Great!! please see my comments inline. > > > On Fri, Mar 14, 2014 at 5:02 PM, Rajeev Sampath <[email protected]> wrote: > >> Following is a summary of how the current implementation of caching works: >> >> - Existing events are loaded to the cache in lazy manner when they are >> looked-up. >> - When adding/removing events both cache and table is updated accordingly. >> - When reading, cache is searched first and then the DB table. For events >> that do not exist in the cache, they get added to the cache at this moment >> and evictions happen if necessary. >> - The events in the cache are evicted based on 3 algorithms. They are >> Least Recently Used, Least Frequently Used and FIFO. User can choose what >> to use in their query. (This is configurable per-table basis). Events get >> evicted when the cache reaches the upper limit. >> - Currently upper limits are constant (this implementation can be changed >> easily to have a configurable value if needed - it's possible to allow the >> user to define upper limits in the query) >> > Can we do this for this release? > > Yes. I'll do. > - Currently caches do not support the distributed mode. This is not >> implemented since there are pending changes to our distributed processing >> implementation. >> > That we can do in next release > > >> - Also in a future release we need to change the implementation of how >> Join operations are done in Siddhi. With the current implementation, caches >> can't be used effectively for Joins. >> > What are the complications? > > Currently the joins require full iterations of the windows/tables. Hence, for large tables that have smaller caches, we can't achieve a performance gain. In order to fix this we'll have to change how the join is implemented - i.e. instead of a common implementation that iterates completely through both sides, we'll have to come up with different implementations for these, probably doing a full iteration only through one side and/or using Bloom filters etc. Thanks Rajeev > --Srinath > > >> >> The documentation can be found at [1] >> >> [1] https://docs.wso2.org/display/CEP310/Event+Table+Definitions >> >> >> On Fri, Mar 14, 2014 at 7:25 AM, Srinath Perera <[email protected]> wrote: >> >>> How it works? when does it evict things? can we set limits. >>> >>> Please respond to this with details about the design >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> http://people.apache.org/~hemapani/ >>> http://srinathsview.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Rajeev Sampath >> Senior Software Engineer >> WSO2, Inc.; http://www.wso2.com. >> >> Mobile: >> * +94716265766 <%2B94716265766>* >> > > > > -- > ============================ > Srinath Perera, Ph.D. > Director, Research, WSO2 Inc. > Visiting Faculty, University of Moratuwa > Member, Apache Software Foundation > Research Scientist, Lanka Software Foundation > Blog: http://srinathsview.blogspot.com/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > -- Rajeev Sampath Senior Software Engineer WSO2, Inc.; http://www.wso2.com. Mobile: * +94716265766*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
