[
https://issues.apache.org/jira/browse/RATIS-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801213#comment-16801213
]
Vladimir Rodionov commented on RATIS-477:
-----------------------------------------
[~elserj], there are some open questions which need to be addressed before
considering next version of the patch:
1. Memory consumption in InMemoryLogServiceRaftLogIndex - to keep pair of 8byte
values you create 2 objects along with internal object of CSLM itself - we are
looking into 100-200 bytes overhead
2. Snapshotting of in memory index can take seconds (maybe 10s of seconds) - is
it safe? State machine snapshot is a synchronous operation
3. Scalability of an in-memory approach? I think it's good for testing only.
CSLM in pre-Java11 world does not scale beyond low 10s millions KVs.
4. How and when to clean index? No code for that yet.
5. There should range delete API for index or delete all up to recordId
6. Any other other than in-memory implementation on your mind?
> Improve LogStateMachine.processReadRequest()
> --------------------------------------------
>
> Key: RATIS-477
> URL: https://issues.apache.org/jira/browse/RATIS-477
> Project: Ratis
> Issue Type: Improvement
> Components: LogService
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Major
> Fix For: 0.3.0
>
> Attachments: RATIS-477.001.patch
>
>
> [~vrodionov] and [~rajeshbabu] were asking about this in RATIS-470. Can we
> improve the logic that reads through the "head" of the RaftLog to find the
> "LogService offset"?
> Vlad suggested:
> {quote}
> Josh, can we simplify this a little bit? Client gets Raft log ID one every
> append, for multi-get calls we can use this LogID (RAFT) as our start log ID
> to avoid iterating through all logs, then you can unwind log entries by using
> new logic, see above:
> int numRecordsInAppend = append.getDataCount();
> There is no need to iterate from the very beginning
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
