vcrfxia commented on code in PR #13126: URL: https://github.com/apache/kafka/pull/13126#discussion_r1093909835
########## streams/src/main/java/org/apache/kafka/streams/state/internals/RocksDBVersionedStoreSegmentValueFormatter.java: ########## @@ -0,0 +1,518 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.kafka.streams.state.internals; + +import java.nio.ByteBuffer; +import java.util.ArrayList; +import java.util.List; + +/** + * Helper utility for managing the bytes layout of the value stored in segments of the {@link RocksDBVersionedStore}. + * The value format is: + * <pre> + * <next_timestamp> + <min_timestamp> + <list of <timestamp, value_size>, reverse-sorted by timestamp> + <list of values, forward-sorted by timestamp> + * </pre> + * where: + * <ul> + * <li>{@code next_timestamp} is the validTo timestamp of the latest record version stored in this + * segment,</li> + * <li>{@code min_timestamp} is the validFrom timestamp of the earliest record version stored + * in this segment, and</li> + * <li>Negative {@code value_size} is used to indicate that the value stored is a tombstone, + * in order to distinguish from empty array which has {@code value_size} of zero. In practice, + * {@code value_size} is always set to -1 for the tombstone case, though this need not be true + * in general.</li> + * </ul> + * <p> + * Note that the value format above does not store the number of record versions contained in the + * segment. It is not necessary to store this information separately because this information is + * never required on its own. Record versions are always deserialized in order, and we can + * determine when we have reached the end of the list based on whether the (validFrom) timestamp of + * the record version equals the {@code min_timestamp}. + * <p> + * There is one edge case with regards to the segment value format described above, which is useful + * to know for understanding the code in this file, but not relevant for callers of the class. + * In the typical case, all record (validFrom) timestamps and the {@code next_timestamp} of the Review Comment: The pattern I was going for was: * validTo and validFrom timestamps are not styled in code markup, except when literally referring to code, e.g., in the javadoc for a method which literally takes parameters called "validFrom" and "validTo". There are very few of these latter cases. * `nextTimestamp` and `minTimestamp` are styled as code markups (they are code concepts only). I think all the docs are consistent with this stylization, but if that's not the case I can fix it. I can also change "validFrom" and "validTo" to be "valid-from" and "valid-to" when used as regular English, if you think that'd help. ########## streams/src/main/java/org/apache/kafka/streams/state/internals/RocksDBVersionedStoreSegmentValueFormatter.java: ########## @@ -0,0 +1,518 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.kafka.streams.state.internals; + +import java.nio.ByteBuffer; +import java.util.ArrayList; +import java.util.List; + +/** + * Helper utility for managing the bytes layout of the value stored in segments of the {@link RocksDBVersionedStore}. + * The value format is: + * <pre> + * <next_timestamp> + <min_timestamp> + <list of <timestamp, value_size>, reverse-sorted by timestamp> + <list of values, forward-sorted by timestamp> + * </pre> + * where: + * <ul> + * <li>{@code next_timestamp} is the validTo timestamp of the latest record version stored in this + * segment,</li> + * <li>{@code min_timestamp} is the validFrom timestamp of the earliest record version stored + * in this segment, and</li> + * <li>Negative {@code value_size} is used to indicate that the value stored is a tombstone, + * in order to distinguish from empty array which has {@code value_size} of zero. In practice, + * {@code value_size} is always set to -1 for the tombstone case, though this need not be true + * in general.</li> + * </ul> + * <p> + * Note that the value format above does not store the number of record versions contained in the + * segment. It is not necessary to store this information separately because this information is + * never required on its own. Record versions are always deserialized in order, and we can + * determine when we have reached the end of the list based on whether the (validFrom) timestamp of + * the record version equals the {@code min_timestamp}. + * <p> + * There is one edge case with regards to the segment value format described above, which is useful + * to know for understanding the code in this file, but not relevant for callers of the class. + * In the typical case, all record (validFrom) timestamps and the {@code next_timestamp} of the + * segment will form a strictly increasing sequence, i.e., it is not valid to have a record version + * with validTo timestamp equal to (or less than) its validFrom timestamp. The one edge case / + * exception is when the latest record version (for a particular key) is a tombstone, and the + * segment in which this tombstone is to be stored contains currently no record versions. + * This case will result in a "degenerate" segment containing the single tombstone, with both + * {@code min_timestamp} and {@code next_timestamp} equal to the (validFrom) timestamp of the + * tombstone. (It is valid to interpret this tombstone's validTo timestamp as being equal to its + * validFrom timestamp, as querying for the latest record version as of a later timestamp will + * correctly return that no record version is present.) Note also that after a "degenerate" segment + * has formed, it's possible that the segment will remain degenerate even as newer record versions + * are added. (For example, if additional puts happen with later timestamps such that those puts + * only affect later segments, then the earlier degenerate segment will remain degenerate.) + * <p> + * Callers of this class need not concern themselves with this detail because all the exposed + * methods function as expected, even in the degenerate segment case. All methods may still be + * called, with the exception of {@link SegmentValue#find(long, boolean)} and those that depend Review Comment: Fair enough. I'll remove these. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
