[ 
https://issues.apache.org/jira/browse/FLINK-6364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15996233#comment-15996233
 ] 

ASF GitHub Bot commented on FLINK-6364:
---------------------------------------

Github user shixiaogang commented on the issue:

    https://github.com/apache/flink/pull/3801
  
    @StefanRRichter  Thanks a lot for your review. I have updated the pull 
request as suggested. The following changes are made
    
    1. Remove the checkpoint type for incremental checkpoints. Now the support 
for incremental checkpointing becomes a configurable feature in 
`RocksDBKeyedStateBackend`, just like asynchronous checkpointing in 
`HeapKeyedStateBackend`. Incremental checkpointing will be performed if the 
feature is enabled and the checkpoint to perform is not a savepoint.
    
    2. Rename `RocksDBKeyedStateHandle` to `RocksDBIncrementalKeyedStateHandle` 
and do some refactoring.
    
    3. Allow `KeyedStateHandle` to register shared states.
    
    4. Maintain the information of last completed checkpoint with the 
notification of `AbstractStreamOperator`.
    
    5. Parameterize `RocksDBStateBackendTest` to test the cleanup of resources 
in both full and incremental checkpointing.
    
    6. Parameterize `PartitionedStateCheckpointingITCase` to test the 
snapshotting and restoring with different backend settings.
    
    It's appreciated if you can take a look at these changes. Any comment is 
welcome.


> Implement incremental checkpointing in RocksDBStateBackend
> ----------------------------------------------------------
>
>                 Key: FLINK-6364
>                 URL: https://issues.apache.org/jira/browse/FLINK-6364
>             Project: Flink
>          Issue Type: Sub-task
>          Components: State Backends, Checkpointing
>            Reporter: Xiaogang Shi
>            Assignee: Xiaogang Shi
>
> {{RocksDBStateBackend}} is well suited for incremental checkpointing because 
> RocksDB is base on LSM trees,  which record updates in new sst files and all 
> sst files are immutable. By only materializing those new sst files, we can 
> significantly improve the performance of checkpointing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to