schemeboard: pass describe-result as an opaque payload #2083
Conversation
|
⚪
|
|
⚪
|
be95526 to
ba5f107
Compare
|
⚪
|
|
⚪
|
ba5f107 to
4760387
Compare
|
⚪
|
|
⚪
|
4760387 to
4488b95
Compare
PathOwner field was replaced by PathOwnerId a long time ago.
Change type of `{TEvUpdate,TEvNotify}.DescribeSchemeResult` from transparent
`TEvDescribeSchemeResult` to opaque `bytes` and support that throughout
Populator, Replica, Subscriber actors.
Properly typed TEvDescribeSchemeResult induce additional overhead to
automatically serialize and deserialize this message when transfering over
the wire.
This performance cost is usually either negligible or imperceptible.
But in specific situations, particularly when rapidly updating partitioning
information for tables with huge number of shards, this overhead could lead
to significant issues. Schemeboard replicas could get overloaded and become
unresponsive to further requests. This is problematic, especially considering
the schemeboard subsystem's critical role in servicing all databases within
a cluster, making it a SPOF.
The core realization is that the schemeboard components do not require
the full content of a TEvDescribeSchemeResult message to operate efficiently.
Instead, only a limited set of fields (path, path-id, version and info about
subdomain/database) is required for processing.
And a whole TEvDescribeSchemeResult could be passed through as an opaque payload.
Type change from TEvDescribeSchemeResult to bytes without changing field number
is a safe move. Actual value of the field remains unchanged at the wire
protocol level.
Thus, older implementations will interpret the payload as
a TEvDescribeSchemeResult message and proceed with deserialization as usual.
And newer implementations will recognize the data as a binary blob and will
deserialize it explicitly only when necessary.
KIKIMR-14948
4488b95 to
56b61d3
Compare
|
⚪ |
|
⚪ |
|
⚪ |
|
⚪
|
|
⚪
|
|
⚪
|
|
⚪
|
|
Test failures (in linux-x86_64-relwithdebinfo build conf) have known causes and are not related to this pr. |
|
|
||
| // Context->SetLogPriority(NKikimrServices::SCHEME_BOARD_REPLICA, NLog::PRI_DEBUG); | ||
| // Context->SetLogPriority(NKikimrServices::SCHEME_BOARD_SUBSCRIBER, NLog::PRI_DEBUG); | ||
| // Context->SetLogPriority(NKikimrServices::TX_PROXY_SCHEME_CACHE, NLog::PRI_DEBUG); | ||
| // Context->SetLogPriority(NKikimrServices::FLAT_TX_SCHEMESHARD, NLog::PRI_DEBUG); |
Cherry-pick 3819aed from main (ydb-platform#2083). Change type of `{TEvUpdate,TEvNotify}.DescribeSchemeResult` from transparent `TEvDescribeSchemeResult` to opaque `bytes` and support that throughout Populator, Replica, Subscriber actors. Properly typed TEvDescribeSchemeResult induce additional overhead to automatically serialize and deserialize this message when transfering over the wire. This performance cost is usually either negligible or imperceptible. But in specific situations, particularly when rapidly updating partitioning information for tables with huge number of shards, this overhead could lead to significant issues. Schemeboard replicas could get overloaded and become unresponsive to further requests. This is problematic, especially considering the schemeboard subsystem's critical role in servicing all databases within a cluster, making it a SPOF. The core realization is that the schemeboard components do not require the full content of a TEvDescribeSchemeResult message to operate efficiently. Instead, only a limited set of fields (path, path-id, version and info about subdomain/database) is required for processing. And a whole TEvDescribeSchemeResult could be passed through as an opaque payload. Type change from TEvDescribeSchemeResult to bytes without changing field number is a safe move. Actual value of the field remains unchanged at the wire protocol level. Thus, older implementations will interpret the payload as a TEvDescribeSchemeResult message and proceed with deserialization as usual. And newer implementations will recognize the data as a binary blob and will deserialize it explicitly only when necessary. KIKIMR-14948
Cherry-pick 3819aed from main (#2083). Make schemeboard replicas consume less CPU, especially when processing rapid updates for tables with huge amount of partitions. Schema information on a path exist in the form of `DescribeSchemeResult` object: schemeshard generates those objects and publishes them to the schemeboard, schemeboard notifies scheme-caches on the nodes about path info changes. So schemeshard generates `DescribeSchemeResult`, scheme-cache serves `DescribeSchemeResult` to the consumers. But schemeboard components in-between do not require the full content of a TEvDescribeSchemeResult to operate efficiently. This update enables the schemeboard to transmit `DescribeSchemeResult` through as an opaque payload rather than as a fully detailed protobuf object. Thus reducing the unnecessary memory management and serialization/deserialization overhead.
Changelog entry
Make schemeboard replicas consume less CPU, especially when processing rapid updates for tables with huge amount of partitions.
Changelog category
Additional information
Schema information on a path exist in the form of
DescribeSchemeResultobject: schemeshard generates those objects and publishes them to the schemeboard, schemeboard notifies scheme-caches on the nodes about path info changes. So schemeshard generatesDescribeSchemeResult, scheme-cache servesDescribeSchemeResultto the consumers. But schemeboard components in-between do not require the full content of a TEvDescribeSchemeResult to operate efficiently.This update enables the schemeboard to transmit
DescribeSchemeResultthrough as an opaque payload rather than as a fully detailed protobuf object. Thus reducing the unnecessary memory management and serialization/deserialization overhead.