Skip to content

Conversation

@beryllw
Copy link
Contributor

@beryllw beryllw commented Dec 12, 2025

Purpose

Linked issue: close #2111

Brief change log

Tests

API and Format

Documentation

@beryllw beryllw marked this pull request as draft December 12, 2025 08:14
@beryllw beryllw force-pushed the auto-inc-impl branch 2 times, most recently from 45dc38a to 4d674d7 Compare December 12, 2025 15:04
@vamossagar12
Copy link
Contributor

hi, I had created this Pr: #2119 for this issue. Do we want to prefer this one over that?

@xx789633
Copy link
Contributor

Hi @vamossagar12 , we prefer this one to work on since it is more comprehensive.

@beryllw beryllw force-pushed the auto-inc-impl branch 2 times, most recently from 19d0475 to 697dbcf Compare December 24, 2025 04:33
@beryllw beryllw marked this pull request as ready for review December 24, 2025 06:03
@beryllw beryllw requested a review from xx789633 December 24, 2025 06:10
new Column(
column.getName(),
column.getDataType().copy(false),
column.getDataType().copy(true),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partial update is required, so the data type here needs to be temporarily set to nullable.

@beryllw beryllw changed the title [kv]: Add an implementation of AutoIncIDBuffer [kv] Add an implementation of AutoIncIDBuffer Dec 25, 2025
@beryllw beryllw requested a review from xx789633 December 25, 2025 03:16
@beryllw beryllw requested a review from xx789633 December 26, 2025 01:13
Copy link
Contributor

@platinumhamburg platinumhamburg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@beryllw Thanks for contribution, I left some comments.

throws Exception {
walBuilder.append(ChangeType.INSERT, latestSchemaRow.replaceRow(currentValue.row));
kvPreWriteBuffer.put(key, currentValue.encodeValue(), logOffset);
BinaryValue newValue = autoIncProcessor.processAutoInc(currentValue);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been wondering about the relationship between auto-increment column handling and the Merge Engine. I think they should probably be integrated in the design to avoid redundant encoding of row data, which would otherwise lead to significant performance overhead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. We had better handle the partial updater and auto increment column at the same time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, auto-increment is only utilized for INSERT operations, which does not overlap with the functionalities of RowMerger and PartialUpdateRowMerger. I agree integrating auto-increment into RowMerger would result in a more streamlined design, and I will try to optimize this part.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this perspective. One point worth noting is that when changelogImage == ChangelogImage.WAL, the applyInsert method might not be invoked. It would be helpful to clarify the intended design and expected behavior in this case.

Additionally, since PartialUpdater is currently used only by DefaultRowMerger and isn’t a general-purpose class, we might defer considering its consolidation for now.

Copy link
Contributor Author

@beryllw beryllw Jan 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One point worth noting is that when changelogImage == ChangelogImage.WAL, the applyInsert method might not be invoked. It would be helpful to clarify the intended design and expected behavior in this case.

Agree. When changelogImage == ChangelogImage.WAL, auto-Increment column aren't supported. We could clarify this in the docs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here, I believe we should support this. ChangelogImage.WAL is an optimization mode whose core use case is to skip generating UPDATE_BEFORE records when a user's table does not require UPDATE_BEFORE information. This significantly reduces the storage, replication (leader-follower), and read overhead associated with the changelog. Building upon this foundation, skipping the lookup of the old value to further reduce CPU and I/O overhead is merely an incremental optimization. Therefore, under the condition changelogImage == ChangelogImage.WAL, it's not that we cannot support the auto-increment columns; rather, we simply cannot benefit from this incremental optimization and would still need to look up the old value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ChangelogImage.WAL mode is already supported. My concern is that when changelogImage == ChangelogImage.WAL, the ChangelogNormalize operator will be inserted, which will introduce additional computational overhead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's okay; this is Flink's behavior and can be optimized on the Flink side.

@platinumhamburg
Copy link
Contributor

In addition to integration tests, I think we should also add several unit tests in KvTabletTest to cover behavior assertions after a TabletServer restart and after a single segment overflows.

@beryllw
Copy link
Contributor Author

beryllw commented Dec 31, 2025

In addition to integration tests, I think we should also add several unit tests in KvTabletTest to cover behavior assertions after a TabletServer restart and after a single segment overflows.

We could create a new issue to address the failover problem, including the design and implementation of its corresponding recovery mechanisms.

throws Exception {
walBuilder.append(ChangeType.INSERT, latestSchemaRow.replaceRow(currentValue.row));
kvPreWriteBuffer.put(key, currentValue.encodeValue(), logOffset);
BinaryValue newValue = autoIncProcessor.processAutoInc(currentValue);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this perspective. One point worth noting is that when changelogImage == ChangelogImage.WAL, the applyInsert method might not be invoked. It would be helpful to clarify the intended design and expected behavior in this case.

Additionally, since PartialUpdater is currently used only by DefaultRowMerger and isn’t a general-purpose class, we might defer considering its consolidation for now.

@beryllw beryllw marked this pull request as draft January 3, 2026 14:27
@beryllw beryllw marked this pull request as ready for review January 6, 2026 11:16
@xx789633 xx789633 requested review from wuchong and removed request for platinumhamburg January 7, 2026 02:22
// Optimization: when using WAL mode and merger is DefaultRowMerger (full update, not
// partial update), we can skip fetching old value for better performance since it
// always returns new value. In this case, both INSERT and UPDATE will produce
// UPDATE_AFTER.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment above should be updated. The description of TABLE_CHANGELOG_IMAGE in both ConfigOptions.java and options.md should also be updated.

Copy link
Contributor

@platinumhamburg platinumhamburg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've left some additional comments.

upsertWriter.upsert(row("e", null, "batch2")).get();
// The auto-increment column should start from a new segment for now, and local cached
// IDs have been discarded.
assertThatRow(lookupRow(lookuper, keyRow.replaceRow(row("e", null, null))))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good test addition; however, there's no need to create a new test class. The scenario can be simply incorporated into the existing tests in FlussTableITCase.java.

{"b", 1L, "batch1"},
{"c", 2L, "batch1"},
{"d", 3L, "batch1"},
{"e", 4L, "batch1"}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests are generally good, but they can be further improved by abstracting the logic for writing partial updates to a specified schema and performing query assertions into a common utility method to enhance readability—this would significantly simplify the tests. Additionally, the test data should include records with duplicate primary keys to strengthen the effectiveness of behavioral validation.

}

@Test
void testPutAutoIncColumnAndLookup() throws Exception {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test doesn't appear to include any additional behavioral verification; it could potentially be merged with the previous test (testSingleBucketPutAutoIncColumnAndLookup).

public void configureSchema(int latestSchemaId) {
if (latestSchemaId != this.schemaId) {
Schema schema = schemaGetter.getSchema(latestSchemaId);
int[] autoIncColumnIds = schema.getAutoIncColumnIds();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the schema implementation perspective, this is a high-overhead operation and should not be repeatedly computed unnecessarily; at the very least, some form of caching mechanism should be in place.

sequenceGeneratorMap.get(autoIncColumnId));
} else {
throw new IllegalStateException(
"Not supported add auto increment column for a table.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe intercepting here is unreasonable—the DDL has already succeeded, and the client has even attempted to write data. If this needs to be prohibited, it should be blocked on the DDL side.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, the validation/assertion here may be acceptable, but the error message is inappropriate—please verify whether the DDL-side interception is comprehensive.

// Supports removing or reordering columns; does NOT support adding an auto-increment column to
// an existing table.
public void configureSchema(int latestSchemaId) {
if (latestSchemaId != this.schemaId) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The condition here should be inverted with an early return to avoid deep indentation of a large code block, which would otherwise degrade readability.

int autoIncColumnId = autoIncColumnIds[0];
if (sequenceGeneratorMap.containsKey(autoIncColumnId)) {
this.autoIncUpdater =
new DefaultAutoIncUpdater(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that different versions of DefaultAutoIncUpdater can be managed using a cache.

} else {
rowEncoder.encodeField(
i, flussFieldGetters[i].getFieldOrNull(oldValue.row));
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could oldValue here be null? I don't think that's possible—this doesn't appear to be a scenario that RowMerger would encounter.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here, oldValue actually corresponds to newValue in RowMerger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[kv/auto increment column] Implement AutoIncIDBuffer on tablet server

4 participants