[
https://issues.apache.org/jira/browse/FLINK-14997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986042#comment-16986042
]
Andrey Zagrebin commented on FLINK-14997:
-----------------------------------------
[~yunta]
Looks reasonable to me.
is it only about RocksDBListState? because from what I see,
RocksDBReducingState and RocksDBAggregatingState also have this.
We do not allow for null user value but return null byte[] always means that
there was nothing stored for the key according to RocksDB get API.
> Avoid to call unnecessary delete within RocksDBState's mergeNamespaces
> implementation
> -------------------------------------------------------------------------------------
>
> Key: FLINK-14997
> URL: https://issues.apache.org/jira/browse/FLINK-14997
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / State Backends
> Reporter: Yun Tang
> Priority: Minor
> Fix For: 1.10.0
>
>
> After FLINK-7700, we delete old state when merging namespaces of RocksDB
> state. However, this change still leaves some performance space to improve:
> {code:java}
> byte[] valueBytes = backend.db.get(columnFamily, sourceKey);
> backend.db.delete(columnFamily, writeOptions, sourceKey);
> if (valueBytes != null) {
> backend.db.merge(columnFamily, writeOptions, targetKey, valueBytes);
> }
> {code}
> As you can see, we would call delete instantly after we get the
> {{valueBytes}}. However, since we did not allow {{null}} in list state value
> and the delete operation could be removed to the statement block which has
> verified the {{valueBytes}} is not null. By doing this, we could avoid
> unnecessary {{delete}} calls if {{sourceKey}} not existed actually.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
