sharding - yandex 如何实现 2 层分片

Question

在 clickhouse 文档中，提到了 Yandex.Metrica，它实现了双层分片。

“或者，正如我们在 Yandex.Metrica 中所做的那样，您可以设置双层分片:将整个集群划分为“层”，其中一个层可能由多个分片组成。单个客户端的数据位于在单个层上，但可以根据需要将分片添加到层中，并且数据在其中随机分布。”

是否有这个分片方案的详细实现，记录在某个地方。

Answer 1

从逻辑上讲，Yandex.Metrica 只有一个高基数 ID 列用作主分片键。

默认从表中选择 Distributed引擎从每个分片的一个副本请求部分结果。如果您有数百台或更多服务器，查询所有分片(可能是所有服务器的 1/2 或 1/3)需要大量网络通信，这可能会比实际查询执行引入更多延迟。这种行为的原因是 ClickHouse 允许直接将数据写入分片(绕过分布式引擎及其配置的分片键)并且不强制应用程序遵守分布式表的分片键(它可以选择不同的方式来传播数据更均匀或任何其他原因)。

因此，双层分片的想法是将大型集群拆分为较小的子集群(每个子集群 10-20 台服务器)，并使大多数 SELECT 查询通过针对子集群配置的分布式表，从而减少必要的网络通信并降低可能掉队者的影响。Global Distributed tables for whole large cluster 也被配置为一些ad-hoc 或overview 风格的查询，但它们不是那么频繁并且对延迟要求较低。这仍然为写入数据的应用程序留下了自由，可以在形成子集群的碎片之间任意平衡它(通过直接写入它们)。但是为了让这一切一起工作，写入和读取数据的应用程序需要有一个一致的映射，从使用的任何高基数 ID(在 Metrica 的情况下是 CounterID)到它包含的子集群 ID 和主机名。 Metrica 将此映射存储在 MySQL 中，但在其他情况下，其他内容可能看起来更适用。​​

另一种方法是使用“optimize_skip_unused_shards”设置，使对分布式表的分片键有条件的 SELECT 查询跳过不应包含数据的分片。它引入了数据在分片之间分布的要求，就像它是通过这个分布式表写入的一样，否则报告将不会包含一些错位的数据。