-
Notifications
You must be signed in to change notification settings - Fork 638
feat: implement Bloom Filter concurrent conflict detection for merge insert operations #4787
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,52 @@ | ||
| // SPDX-License-Identifier: Apache-2.0 | ||
| // SPDX-FileCopyrightText: Copyright The Lance Authors | ||
|
|
||
| syntax = "proto3"; | ||
|
|
||
| package lance.table; | ||
|
|
||
| // Value of the join key representation (reserved for future use) | ||
| // Currently filters operate on hashed values for compactness. | ||
| message JoinKeyValue { | ||
| oneof value { | ||
| string string_value = 1; | ||
| int64 int64_value = 2; | ||
| uint64 uint64_value = 3; | ||
| bytes binary_value = 4; | ||
| CompositeKey composite = 5; | ||
| } | ||
| } | ||
|
|
||
| message CompositeKey { | ||
| repeated JoinKeyValue parts = 1; | ||
| } | ||
|
|
||
| // Exact set of join keys, represented by their 64-bit hashes. | ||
| message ExactSet { | ||
| repeated uint64 key_hashes = 1; | ||
| } | ||
|
|
||
| // Bloom filter data for join key set membership tests. | ||
| message BloomFilterData { | ||
| // Bitset backing the bloom filter. | ||
| bytes bitmap = 1; | ||
| // Number of hash functions used. | ||
| uint32 num_hashes = 2; | ||
| // Total number of bits in the bitmap. | ||
| uint32 bitmap_bits = 3; | ||
| // Reserved for future fields to avoid reuse. | ||
| reserved 4, 5; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. why have all these reserved fields? I think they are not really needed until we want to add them in the future? |
||
| reserved "hash_seed", "hash_algo"; | ||
| } | ||
|
|
||
| // Join key metadata attached to a Transaction for conflict detection. | ||
| message JoinKeyMetadata { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this name does not feel right to me. Consider we use this for an INSERT, then there is not really a join key. What about just keyMetadata or something like KeySet or RowKeySet? |
||
| // Names of columns participating in the join key. | ||
| repeated string columns = 1; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this should be column field ID |
||
| oneof filter { | ||
| ExactSet exact_set = 2; | ||
| BloomFilterData bloom = 3; | ||
| } | ||
| // Reserved to allow schema evolution. | ||
| reserved 4, 5; | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -5,6 +5,7 @@ syntax = "proto3"; | |
|
|
||
| import "file.proto"; | ||
| import "table.proto"; | ||
| import "join_key.proto"; | ||
| import "google/protobuf/any.proto"; | ||
|
|
||
| package lance.table; | ||
|
|
@@ -33,6 +34,8 @@ message Transaction { | |
| // __lance_commit_message is a reserved key | ||
| map<string, string> transaction_properties = 4; | ||
|
|
||
| // Join key metadata using typed protobuf message. This is the sole carrier. | ||
| optional JoinKeyMetadata join_key_metadata = 6; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this should not be in the transaction itself, it should be unique to only a few write transactions to do detection for operations like insert or merge_insert that could add new data to the table? |
||
| // Add new rows to the dataset. | ||
| message Append { | ||
| // The new fragments to append. | ||
|
|
@@ -299,6 +302,7 @@ message Transaction { | |
| } | ||
|
|
||
| // Fields 200/202 (`blob_append` / `blob_overwrite`) previously represented blob dataset ops. | ||
| reserved 5; | ||
| reserved 200, 202; | ||
| reserved "blob_append", "blob_overwrite"; | ||
| } | ||
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 unused, should just remove