跳至主要内容

SharedMergeTree 表引擎

*仅在 ClickHouse 云（和第一方合作伙伴云服务）中可用

SharedMergeTree 表引擎系列是 ReplicatedMergeTree 引擎的云原生替代方案，经过优化，可在共享存储（例如 Amazon S3、Google Cloud Storage、MinIO、Azure Blob Storage）之上运行。每个特定 MergeTree 引擎类型都有一个 SharedMergeTree 类似物，例如 ReplacingSharedMergeTree 替换 ReplacingReplicatedMergeTree。

SharedMergeTree 表引擎系列为 ClickHouse 云提供动力。对于最终用户，无需更改任何内容即可开始使用 SharedMergeTree 引擎系列而不是基于 ReplicatedMergeTree 的引擎。它提供以下额外优势

  • 更高的插入吞吐量
  • 改进后台合并的吞吐量
  • 改进突变的吞吐量
  • 更快的扩展和缩减操作
  • 更轻量级的强一致性，适用于选择查询

SharedMergeTree 带来的一个重大改进是，它与 ReplicatedMergeTree 相比，提供了更深层的计算与存储分离。您可以看到 ReplicatedMergeTree 如何分离计算与存储

ReplicatedMergeTree Diagram

如您所见，即使 ReplicatedMergeTree 中存储的数据在对象存储中，元数据仍然驻留在每个 clickhouse-server 上。这意味着对于每个复制操作，元数据也需要在所有副本上复制。

ReplicatedMergeTree Diagram with Metadata

与 ReplicatedMergeTree 不同，SharedMergeTree 不需要副本相互通信。相反，所有通信都通过共享存储和 clickhouse-keeper 进行。SharedMergeTree 实现异步无领导复制，并使用 clickhouse-keeper 进行协调和元数据存储。这意味着当您的服务扩展和缩减时，元数据不需要复制。这将导致更快的复制、突变、合并和扩展操作。SharedMergeTree 允许每个表拥有数百个副本，从而可以在没有分片的情况下动态扩展。ClickHouse 云使用分布式查询执行方法来利用更多计算资源来执行查询。

自省​

用于自省 ReplicatedMergeTree 的大多数系统表都存在于 SharedMergeTree 中，除了 system.replication_queue 和 system.replicated_fetches，因为没有发生数据和元数据的复制。但是，SharedMergeTree 针对这两个表提供了相应的替代方案。

system.virtual_parts

此表充当 SharedMergeTree 对 system.replication_queue 的替代方案。它存储有关最新一组当前部分的信息，以及正在进行的未来部分，例如合并、突变和删除分区。

system.shared_merge_tree_fetches

此表是 SharedMergeTree 对 system.replicated_fetches 的替代方案。它包含有关当前正在进行的将主键和校验和提取到内存中的信息。

启用 SharedMergeTree​

SharedMergeTree 默认启用。

对于支持 SharedMergeTree 表引擎的服务，您无需手动启用任何内容。您可以像以前一样创建表，它会自动使用与您在 CREATE TABLE 查询中指定的引擎相对应的基于 SharedMergeTree 的表引擎。

CREATE TABLE my_table(
 key UInt64,
 value String
)
ENGINE = MergeTree
ORDER BY key

这将使用 SharedMergeTree 表引擎创建表 my_table。

您无需指定 ENGINE=MergeTree，因为 ClickHouse 云中的 default_table_engine=MergeTree。以下查询与上面的查询相同。

CREATE TABLE my_table(
 key UInt64,
 value String
)
ORDER BY key

如果您使用 Replacing、Collapsing、Aggregating、Summing、VersionedCollapsing 或 Graphite MergeTree 表，它将自动转换为相应的基于 SharedMergeTree 的表引擎。

CREATE TABLE myFirstReplacingMT
(
    `key` Int64,
    `someCol` String,
    `eventTime` DateTime
)
ENGINE = ReplacingMergeTree
ORDER BY key;

对于给定表，您可以使用 SHOW CREATE TABLE 检查使用哪个表引擎创建了 CREATE TABLE 语句。

SHOW CREATE TABLE myFirstReplacingMT;
CREATE TABLE default.myFirstReplacingMT 
( `key` Int64, `someCol` String, `eventTime` DateTime ) 
ENGINE = SharedReplacingMergeTree('/clickhouse/tables/{uuid}/{shard}', '{replica}') 
ORDER BY key 
SETTINGS index_granularity = 8192

设置​

某些设置的行为已发生重大变化

  • insert_quorum -- 对 SharedMergeTree 的所有插入都是仲裁插入（写入共享存储），因此在使用 SharedMergeTree 表引擎时不需要此设置。
  • insert_quorum_parallel -- 对 SharedMergeTree 的所有插入都是仲裁插入（写入共享存储），因此在使用 SharedMergeTree 表引擎时不需要此设置。
  • select_sequential_consistency -- 不需要仲裁插入，将在 SELECT 查询上触发对 clickhouse-keeper 的额外负载

一致性​

SharedMergeTree 提供比 ReplicatedMergeTree 更好的轻量级一致性。当您插入 SharedMergeTree 时，您无需提供诸如 insert_quorum 或 insert_quorum_parallel 之类的设置。插入是仲裁插入，这意味着元数据将存储在 ClickHouse-Keeper 中，并且元数据将复制到至少 ClickHouse-Keeper 的仲裁数量。您的集群中的每个副本将异步从 ClickHouse-Keeper 提取新信息。

大多数情况下，您不应该使用 select_sequential_consistency 或 SYSTEM SYNC REPLICA LIGHTWEIGHT。异步复制应该涵盖大多数场景，并且延迟非常低。在您绝对需要防止陈旧读取的极少数情况下，请按照优先顺序遵循以下建议

  1. 如果您在同一会话或同一节点中执行您的查询以进行读取和写入，则无需使用 select_sequential_consistency，因为您的副本将已经拥有最新的元数据。

  2. 如果您写入一个副本并从另一个副本读取，则可以使用 SYSTEM SYNC REPLICA LIGHTWEIGHT 强制副本从 ClickHouse-Keeper 获取元数据。

  3. 将 select_sequential_consistency 用作查询的一部分的设置。

相关内容​