-
Notifications
You must be signed in to change notification settings - Fork 474
[kv] Add an implementation of AutoIncIDBuffer #2161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
45dc38a to
4d674d7
Compare
fluss-common/src/main/java/org/apache/fluss/metadata/Schema.java
Outdated
Show resolved
Hide resolved
fluss-common/src/test/java/org/apache/fluss/metadata/TableDescriptorTest.java
Show resolved
Hide resolved
fluss-server/src/main/java/org/apache/fluss/server/kv/autoinc/SegmentIDGenerator.java
Outdated
Show resolved
Hide resolved
|
hi, I had created this Pr: #2119 for this issue. Do we want to prefer this one over that? |
|
Hi @vamossagar12 , we prefer this one to work on since it is more comprehensive. |
19d0475 to
697dbcf
Compare
fluss-server/src/main/java/org/apache/fluss/server/utils/TableDescriptorValidation.java
Outdated
Show resolved
Hide resolved
fluss-common/src/main/java/org/apache/fluss/utils/json/ColumnJsonSerde.java
Outdated
Show resolved
Hide resolved
fluss-common/src/main/java/org/apache/fluss/config/ConfigOptions.java
Outdated
Show resolved
Hide resolved
| new Column( | ||
| column.getName(), | ||
| column.getDataType().copy(false), | ||
| column.getDataType().copy(true), |
There was a problem hiding this comment.
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.
fluss-server/src/main/java/org/apache/fluss/server/kv/autoinc/AutoIncProcessor.java
Outdated
Show resolved
Hide resolved
fluss-server/src/main/java/org/apache/fluss/server/zk/data/ZkData.java
Outdated
Show resolved
Hide resolved
platinumhamburg
left a comment
There was a problem hiding this 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.
fluss-server/src/main/java/org/apache/fluss/server/zk/ZkSequenceIDCounter.java
Outdated
Show resolved
Hide resolved
fluss-server/src/main/java/org/apache/fluss/server/kv/autoinc/AutoIncProcessor.java
Outdated
Show resolved
Hide resolved
fluss-server/src/main/java/org/apache/fluss/server/kv/autoinc/AutoIncProcessor.java
Outdated
Show resolved
Hide resolved
fluss-server/src/main/java/org/apache/fluss/server/kv/autoinc/IncIDGenerator.java
Outdated
Show resolved
Hide resolved
fluss-server/src/main/java/org/apache/fluss/server/kv/autoinc/SegmentSequenceGenerator.java
Show resolved
Hide resolved
fluss-client/src/test/java/org/apache/fluss/client/table/FlussTableITCase.java
Show resolved
Hide resolved
fluss-common/src/main/java/org/apache/fluss/config/ConfigOptions.java
Outdated
Show resolved
Hide resolved
| throws Exception { | ||
| walBuilder.append(ChangeType.INSERT, latestSchemaRow.replaceRow(currentValue.row)); | ||
| kvPreWriteBuffer.put(key, currentValue.encodeValue(), logOffset); | ||
| BinaryValue newValue = autoIncProcessor.processAutoInc(currentValue); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
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. |
fluss-server/src/main/java/org/apache/fluss/server/kv/autoinc/IncIDGenerator.java
Outdated
Show resolved
Hide resolved
fluss-server/src/main/java/org/apache/fluss/server/kv/autoinc/SegmentIncIDGenerator.java
Outdated
Show resolved
Hide resolved
fluss-server/src/main/java/org/apache/fluss/server/kv/autoinc/AutoIncProcessor.java
Outdated
Show resolved
Hide resolved
| throws Exception { | ||
| walBuilder.append(ChangeType.INSERT, latestSchemaRow.replaceRow(currentValue.row)); | ||
| kvPreWriteBuffer.put(key, currentValue.encodeValue(), logOffset); | ||
| BinaryValue newValue = autoIncProcessor.processAutoInc(currentValue); |
There was a problem hiding this comment.
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.
fluss-server/src/main/java/org/apache/fluss/server/kv/autoinc/AutoIncColumnProcessor.java
Outdated
Show resolved
Hide resolved
| // 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. |
There was a problem hiding this comment.
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.
platinumhamburg
left a comment
There was a problem hiding this 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)))) |
There was a problem hiding this comment.
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"} |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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."); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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)); | ||
| } |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Purpose
Linked issue: close #2111
Brief change log
Tests
API and Format
Documentation