incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron McCurry (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (BLUR-229) Make V2 of the Block Cache production ready.
Date Thu, 31 Oct 2013 17:45:17 GMT

     [ https://issues.apache.org/jira/browse/BLUR-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aaron McCurry closed BLUR-229.
------------------------------

    Resolution: Fixed

I am going to consider this issue closed.  A lot of testing has been performed on the new
block cache and I think it's ready to go.

> Make V2 of the Block Cache production ready.
> --------------------------------------------
>
>                 Key: BLUR-229
>                 URL: https://issues.apache.org/jira/browse/BLUR-229
>             Project: Apache Blur
>          Issue Type: New Feature
>          Components: Blur
>    Affects Versions: 0.3.0, 0.2.1
>            Reporter: Aaron McCurry
>             Fix For: 0.3.0, 0.2.1
>
>
> This task will be to make the new version of the Block Cache production ready.
> The code can be found in:
> https://git-wip-us.apache.org/repos/asf?p=incubator-blur.git;a=shortlog;h=refs/heads/0.2.1
> The big features for this new code are the following:
> 1. Variable length cache block sizes.  The big need for this is in filtering.  Creating
huge bits sets on the heap to cache filters created by inbound queries can be hard to manage.
 It can also production performance problems (GC issues) and can cause OOM errors if too many
filters are created.  If a filter can be written as a file per segment and cached as a single
unit in the block cache, then it will be as performant as on heap bitset but will live off
the heap and under the same resource constraints placed on the block cache.  So basically
when a cluster is over allocated (when it comes to caching filters) the cluster will be less
likely to fail and instead will perform more slowly.
> 2. Block cache size can be dynamically changed.
> 3. Simpler implementation for the off heap slabs of memory.  Which should also make it
faster.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message