关系型数据库，但千万级表关联数据库基本上不太可能做到秒出；考虑过Sharding，但数据量大，
各种成本都很高；热数据存储到ElasticSearch，但无法跨索引关联，导致不得不做宽表，
因为权限，酒店信息会变，所以每次要刷全量数据，不适用于大表更新，
维护成本也很高；Redis键值对存储无法做到实时汇总；
1. 现有一个需求需要快速访问 2个字段 至少占 128KB 的 一条记录 , 累计十多亿数据更新，如何保证数据更新过程中生产应用高可用
2. 每天有将近百万次数据查询请求
3. 让用户无论在app端还是pc端查询数据提供秒出的效果
不断扩展使用场景的，是ClickHouse
ClickHouse是一款用于大数据实时分析的列式数据库管理系统，而非数据库。通过向量化执行以及对CPU底层指令集（SIMD）的使用，它可以对海量数据进行并行处理，从而加快数据的处理速度。
主要优点有：
- 为了高效的使用CPU，数据不仅仅按列存储，同时还按向量进行处理；
- 数据压缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行；
- 索引非B树结构，不需要满足最左原则；只要过滤条件在索引列中包含即可；即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；
- 写入速度非常快，50-200M/s，对于大量的数据更新非常适用。
在某些情况下，需要使用复制配置分布式群集，但没有足够的服务器将每个复制副本放置在单独的节点上。最好在同一个节点上以特殊方式配置多个副本，这样即使在节点出现故障时也可以继续执行查询。这种复制配置可以在不同的分布式系统中找到，通常称为“循环”或“环”复制。在本文中，我们将讨论如何在ClickHouse中设置循环复制。如果您对本主题不熟悉，我们建议您从一篇介绍性文章“ClickHouse数据分发”开始。
概念
假设有3个服务器和1个表。目标是将数据分发到3个碎片中并复制两次。这需要在每个节点上有两个不同的碎片。
群集配置
让我们从定义3个碎片和2个副本的简单集群配置开始。由于我们只有3个节点可以使用，我们将以“圆形”的方式设置副本主机，这意味着我们将使用第一个和第二个节点作为第一个碎片，使用第二个和第三个节点作为第二个碎片，使用第三个和第一个节点作为第三个碎片。就像这样：
- 1st shard, 1st replica, hostname: cluster_node_1
- 1st shard, 2nd replica, hostname: cluster_node_2
- 2nd shard, 1st replica, hostname: cluster_node_2
- 2nd shard, 2nd replica, hostname: cluster_node_3
- 3rd shard, 1st replica, hostname: cluster_node_3
- 3rd shard, 2nd replica, hostname: cluster_node_1
配置文件如下:
<shard> <replica> <host>cluster_node_1</host> </replica> <replica> <host>cluster_node_2</host> </replica> </shard> <shard> <replica> <host>cluster_node_2</host> </replica> <replica> <host>cluster_node_3</host> </replica> </shard> <shard> <replica> <host>cluster_node_3</host> </replica> <replica> <host>cluster_node_1</host> </replica> </shard>
现在您可以看到，我们有以下存储架构：
- cluster_node_1 stores 1st shard, 1st replica and 3rd shard, 2nd replica
- cluster_node_2 stores 1st shard, 2nd replica and 2nd shard, 1st replica
- cluster_node_3 stores 2nd shard, 2nd replica and 3rd shard, 1st replica
这显然不起作用，因为碎片具有相同的表名，当它们位于同一服务器上时，ClickHouse无法区分一个碎片/副本。这里的诀窍是把每个碎片放到一个单独的数据库中！ClickHouse允许为每个shard定义“default_database”，然后在查询时使用它，以便将特定表的查询路由到正确的数据库。
关于在ClickHouse中使用“Circle”拓扑的另一个重要注意事项是，您应该将每个特定shard的内部复制选项设置为TRUE。定义如下：
<shard> <internal_replication>true</internal_replication> <replica> <default_database>testcluster_shard_1</default_database> <host>cluster_node_1</host> </replica> <replica> <default_database>testcluster_shard_1</default_database> <host>cluster_node_2</host> </replica> </shard>
现在让我们尝试定义与此配置相对应的shard表。
数据库架构
如上所述，为了在同一节点上彼此分离碎片，需要特定于碎片的数据库。
- 第1个节点架构
- testcluster_shard_1
- testcluster_shard_3
- 第2个节点架构
- testcluster_shard_2
- testcluster_shard_1
- 第3个节点架构
- testcluster_shard_3
- testcluster_shard_2
复制表架构
现在让我们为碎片设置复制表。ReplicatedMergeTree表定义需要两个重要参数：
Zookeeper中的表碎片路径
副本标记
Zookeeper路径对于每个碎片都应该是唯一的，副本标记在每个特定碎片中都应该是唯一的：
第1个节点:
CREATE TABLE testcluster_shard_1.tc_shard
…
Engine=ReplicatedMergeTree(‘/clickhouse/tables/tc_shard_1/events’, ‘replica_1’, …)
CREATE TABLE testcluster_shard_3.tc_shard
…
Engine=ReplicatedMergeTree(‘/clickhouse/tables/tc_shard_3/events’, ‘replica_2’, …)第2个节点
CREATE TABLE testcluster_shard_2.tc_shard
…
Engine=ReplicatedMergeTree(‘/clickhouse/tables/tc_shard_2/events’, ‘replica_1’, …)
CREATE TABLE testcluster_shard_1.tc_shard
…
Engine=ReplicatedMergeTree(‘/clickhouse/tables/tc_shard_1/events’, ‘replica_2’, …)第3个节点
CREATE TABLE testcluster_shard_3.tc_shard
…
Engine=ReplicatedMergeTree(‘/clickhouse/tables/tc_shard_3/events’, ‘replica_1’, …)
CREATE TABLE testcluster_shard_2.tc_shard
…
Engine=ReplicatedMergeTree(‘/clickhouse/tables/tc_shard_2/events’, ‘replica_2’, …)分布式表架构
剩下的就是分布式表。为了让ClickHouse为本地shard表选择合适的默认数据库，需要使用空数据库创建分布式表。这就触发了默认值的使用。
CREATE TABLE tc_distributed
…
ENGINE = Distributed( ‘testcluster’, ‘’, tc_shard, rand() )当查询到分布式表时，ClickHouse会自动为每个本地tc_shard表添加相应的默认数据库。
将“load_balancing”设置设置为“按顺序”是有意义的，否则，ClickHouse可能会偶尔选择第二个副本执行查询，从而导致从同一群集节点查询的两个碎片不是最佳的。
如果其中一个节点关闭，则仍有足够的数据运行查询：
结论
如上所示，可以在ClickHouse中设置循环或环形复制拓扑，但这并不简单，需要不明显的配置和额外的数据库来分离碎片和副本。除了复杂的配置之外，由于每个群集节点的双重插入负载，这种设置与单独的副本节点相比性能更差。虽然对副本重复使用相同的节点似乎很有吸引力，但在考虑循环复制部署时，需要考虑性能和配置问题。
