小坏说后端

（1）问题：使用分布式 ddl 执行命令 create table on cluster xxxx 某个节点上没有创建表，但是 client 返回正常，查看日志有如下报错。（1）问题：由于某个数据节点副本异常，导致两数据副本表不一致，某个数据副本缺少表，需要将两个数据副本调整一致。表结构创建后，clickhouse 会自动从其他副本同步该表数据，验证数据量是否一致即可。在缺少表的数据副本节点上创建缺少的表，创建为本地表，表结构可以在其他数据副本。（1）问题：某个数据副本异常无法启动，需要重新搭建副本。

MySQL 的用户群体很大，为了能够增强数据的实时性，很多解决方案会利用 binlog 将数据写入到 ClickHouse。为了能够监听 binlog 事件，我们需要用到类似 canal 这样的第三方中间件，这无疑增加了系统的复杂度。

普通视图不保存数据，保存的仅仅是查询语句，查询的时候还是从原表读取数据，可以将普通视图理解为是个子查询。物化视图则是把查询的结果根据相应的引擎存入到了磁盘或内存中，对数据重新进行了组织，你可以理解物化视图是完全的一张新表。

查询 CK 手册发现，即便对数据一致性支持最好的 Mergetree，也只是保证最终一致性：我们在使用这类表引擎的时候，会出现短暂数据不一致的情况。在某些对一致性非常敏感的场景，通常有以下几种解决方案。

CK的 join ： 1 、原理：右表加载到内存、再去匹配 2 、为什么 join 不行、因为 1 3 、非要使用、怎么比较好：能过滤先过滤，特别是右表右表放小表特殊场景可以考虑使用字典表可以替换的话、尽量不要用 join ，比如用 in 实现。

要解决数据水平切分的问题，需要引入分片的概念。通过分片把一份完整的数据进行切分，不同的分片分布到不同的节点上，再通过 Distributed 表引擎把数据拼接起来一同使用。，有点类似于 MyCat 之于 MySql，成为一种中间件，通过分布式逻辑表来写入、分发、路由来操作多台节点不同分片的分布式数据。不需要求改文件引用，因为已经使用集群建表了，如果改为引用 metrika-shard.xml 的话，副本虽然能够提高数据的可用性，降低丢失风险，但是每台服务器实际上必须容纳全量数据，对数据的。

二、副本写入流程注：也可以不创建外部文件，直接在 config.xml 中指定（3）同步到 hadoop103 和 hadoop104 上（4）在 hadoop102 的/etc/clickhouse-server/config.xml 中增加分别在 hadoop102 和 hadoop103 上启动 ClickHouse 服务（6）在 hadoop102 和 hadoop103 上分别建表①hadoop102②hadoop103③参数解释第二个参数是副本名称，（8）在 hado

ClickHouse 提供了 Delete 和 Update 的能力，这类操作被称为 Mutation 查询，它可以看。➢ 支持各种 JOIN，但是 JOIN 操作无法使用缓存，所以即使是两次相同的 JOIN 语句，“重”的原因主要是每次修改或者删除都会导致放弃目标数据的原有分区，重建新分区。虽然可以实现修改和删除，但是和一般的 OLTP 数据库不一样，所以尽量做批量的变更，不要进行频繁小数据的操作。，一般不会开放这样的功能给用户，由管理员完成。，同步执行的部分其实只是进行。直到触发分区合并的时候，

写入后的某个时刻（大概 10-15 分钟后），ClickHouse 会自动执行合并操作（等不及也可以手动通过 optimize 执行），把临时分区的数据，合并到已有分区中。MergeTree 是以列文件+索引文件+表定义文件组成的，但是如果设定了分区那么这些文件就会保存到不同的分区目录中。多了一个去重的功能。设置主键的情况，很多处理会依照 order by 的字段进行处理（比如后面会讲的去重和汇总）。ClickHouse 中的主键，和其他数据库不太一样，它只提供了数据的一级索引，但是却不。

Float32 - floatFloat64 – double建议尽可能以整数形式存储数据。例如，将固定精度的数字转换为整数值，如时间用毫秒为单位表示，因为浮点型进行计算时可能引起四舍五入的误差。有三种声明：➢ Decimal32(s)，相当于 Decimal(9-s,s)，有效位数为 1~9➢ Decimal64(s)，相当于 Decimal(18-s,s)，有效位数为 1~18➢ Decimal128(s)，相当于 Decimal(38-s,s)，有效位数为 1~38字符串可以任意长度的。

把 :: 的注释打开，这样的话才能让 ClickHouse 被除本机以外的服务器访问。日志文件路径：/var/log/clickhouse-server/clickhouse-server.log。将/2.资料/ClickHouse 下 4 个文件上传到 hadoop102 的。在这个文件中，有 ClickHouse 的一些默认路径配置，比较重要的。有时候上面配置完会被这个文件覆盖、这个也得配置一下。soft 软线程 当前生效的 配的话要比硬的小。

通过类 LSM tree的结构，ClickHouse 在数据导入时全部是顺序 append 写，写入后数据段不可更改，在后台compaction 时也是多个段 merge sort 后顺序写回磁盘。顺序写的特性，充分利用了磁盘的吞吐能力，即便在 HDD 上也有着优异的写入性能。但是当想查所有人的年龄时，需要不停的查找，或者全表扫描才行，遍历的很多数据都是不需要的。几乎覆盖了标准 SQL 的大部分语法，包括 DDL 和 DML，以及配套的各种函数，用户管理及权限管理，数据的备份与恢复。