[
https://issues.apache.org/jira/browse/SAMZA-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14048354#comment-14048354
]
Jakob Homan commented on SAMZA-256:
-----------------------------------
Is the key difference here whether or not the kv store persists to disk or not?
I could see implementations that provided such persistence as a configurable
option, not as an existential feature.
Also, Option 2 breaks our current pattern of one factory per implementation and
loading the factory via reflection. Keeping that pattern would allow us to
break out RocksDB, LevelDB or other implementations that bring substantial
baggage, into their own modules, thus making it easier to keep that baggage
sorted and segregated. Would it be better to have separate a
LevelDBKeyValueStorageEngineFactory, RocksDBKeyValueStorageEngineFactory,
HashMapKeyValueStorageEngineFactory, etc?
> Provide in-memory data store implementation
> -------------------------------------------
>
> Key: SAMZA-256
> URL: https://issues.apache.org/jira/browse/SAMZA-256
> Project: Samza
> Issue Type: Improvement
> Components: kv
> Affects Versions: 0.6.0
> Reporter: Jakob Homan
> Assignee: Chinmay Soman
> Fix For: 0.8.0
>
>
> The sole current kv store, LevelDbKeyValueStore, works well when the amount
> of data to be stored is prohibitively large to keep it all in memory.
> However, in cases where the state is small enough to comfortably fit in
> whatever memory is available, it would be better to provide an in-memory
> implementation. This can be backed by either a native Java class, or perhaps
> a Guava class, if that is found to scale better (or, of course, the backing
> implementation could be configurable).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
