[
https://issues.apache.org/jira/browse/SAMZA-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14153832#comment-14153832
]
Chinmay Soman commented on SAMZA-424:
-------------------------------------
bq. Is there anything prohibiting us from adding delete? ...
I thought about keeping delete, range and all inside Cache since they're all
technically applicable. But then it turns out that the Cache and KeyValueStore
are exactly the same. In that case, we're back to the same problem that people
use 'KeyValueStore' in their code (with some additional config params) while
they really mean a Cache. If that doesn't sound like a big deal, then we don't
have to change anything.
bq. Cache should be called KeyValueStore, and the existing KV store should be
named RangeKeyValueStore
If the Cache implementation can do range() and all() then this problem does not
exist. We can simply use a KeyValueStore
bq. TTL seems specific to the eviction policy. LFU might want something else.
Agreed - this was simply an example. I should've clarified that this is not an
exhaustive list. We probably need more params.
bq. This could be handled the same way that the LevelDB implementation works
Yeah I was thinking we could do something like that (passing rawDB to restore)
- as is done in KeyValueStorageEngine.
bq. One thing to consider is how this implementation would integrate with the
global state store
I think if we have one interface for both Cache and KeyValueStore (which is
semantically incorrect but might be OK), then we can just use this for the
global state (in fact the introduction mentions this). In that case, the
KeyValueStore will just have a isShared property (either true or False) and
optional configs for expiration / eviction. My fear of merging this is that we
will end up with too many config params for the same thing. It becomes very
difficult to look at the code and figure out what this thing is (you then have
to combine that with the config).
> Add a Cache state API to the Samza container
> --------------------------------------------
>
> Key: SAMZA-424
> URL: https://issues.apache.org/jira/browse/SAMZA-424
> Project: Samza
> Issue Type: New Feature
> Components: container
> Reporter: Chinmay Soman
> Assignee: Chinmay Soman
> Attachments: SAMZA-424-Cache-API_0.pdf
>
>
> There are cases when the user code needs access to a 'cache' which can be
> used to store custom data. This cache is different from the KeyValue store in
> the following ways:
> * At the very least Needs to support LRU (Least Recently Used) and TTL (Time
> To Live) eviction strategies
> * May not support all() and range() operations (since this wreaks havoc with
> the eviction operation)
> * Needs to exist at a per task or a per container level.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
