ClickHouse到底改写本地表还是分布式表

TL;DR

如果预估自己的业务数据量不大(日增不到百万行), 那么写分布式表和本地表都可以, 但要注意如果选择写本地表, 请保证每次写入数据都建立新的连接, 且每个连接写入的数据量基本相同

如果预估自己的业务数据量大(日增百万以上, 并发插入大于10), 那么请写本地表

建议每次插入50W行左右数据, 最多不可超过100W行. 总之CH不像MySQL要小事务. 比如1000W行数据, MySQL建议一次插入1W左右, 使用小事务, 执行1000次. CH建议20次,每次50W. 这是MergeTree引擎原理决定的, 频繁少量插入会导致data part过多, 合并不过来.

再有, AP不像TP, TP为了避免建立新连接产生的损耗影响性能, 通常会使用长连接, 连接池等技术做优化. 但AP业务不需要, 因为AP的属性就不会有高并发, 小SQL.

增强半同步会不会丢数据

只讨论5.7增强半同步和双1的情况

增强半同步会不会丢数据?

这里涉及两个过程:

  • 主库 Innodb与Binlog日志的2PC
  • 增强半同步

Innodb与Binlog日志的2PC

image-20200920221245427

在开启Binlog后, MySQL内部会自动将普通事务当做一个XA事务来处理:

  • 自动为每个事务分配一个唯一的ID
  • COMMIT会被自动的分成Prepare和Commit两个阶段
  • Binlog会被当做事务协调者(Transaction Coordinator), Binlog Event会被当做协调者日志

innodb_status_file innodb_status_output innodb_status_output_locks和innodb_show_verbose_locks

innodb_status_file

这个参数官方文档https://dev.mysql.com/doc/refman/5.7/en/server-system-variable-reference.html 中没有

https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html 中有

--innodb-status-file

Property Value
Command-Line Format `–innodb-status-file[={OFF ON}]`
Type Boolean
Default Value OFF

The --innodb-status-file startup option controls whether InnoDB creates a file named innodb_status.*pid* in the data directory and writes SHOW ENGINE INNODB STATUS output to it every 15 seconds, approximately.

The innodb_status.*pid* file is not created by default. To create it, start mysqld with the --innodb-status-file option. InnoDB removes the file when the server is shut down normally. If an abnormal shutdown occurs, the status file may have to be removed manually.

The --innodb-status-file option is intended for temporary use, as SHOW ENGINE INNODB STATUS output generation can affect performance, and the innodb_status.*pid* file can become quite large over time.

For related information, see Section 14.18.2, “Enabling InnoDB Monitors”.

ClickHouse查询分布式表LEFT JOIN改RIGHT JOIN的大坑

由一个慢查询衍生出的问题

我们线上有一个ClickHouse集群, 总共6个服务器, 配置均为16C 64G SSD, 集群配置为三分片两副本

有两个表这里称为small_tablebig_table. 都是ReplicatedMergeTree引擎(三个分片两个副本).

small_table有79w数据, big_table有5亿数据(数据在之后的示例中没有任何变化), 在下文中small_tablebig_table都为分布式表, 可以获取全量数据, small_table_localbig_table_local为各节点上的本地表名称

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT 
table,
formatReadableSize(sum(data_compressed_bytes)) AS tc,
formatReadableSize(sum(data_uncompressed_bytes)) AS tu,
sum(data_compressed_bytes) / sum(data_uncompressed_bytes) AS ratio
FROM system.columns
WHERE (database = currentDatabase()) AND (table IN ('small_table_local', 'big_table_local'))
GROUP BY table
ORDER BY table ASC

┌─table─────────────────────────┬─tc────────┬─tu────────┬──────────────ratio─┐
│ small_table_local │ 12.87 MiB │ 14.91 MiB │ 0.8633041477100831
│ big_table_local │ 15.46 GiB │ 57.31 GiB │ 0.2697742507036428
└───────────────────────────────┴───────────┴───────────┴────────────────────┘

译文 ClickHouse Materialized Views Illuminated, Part 1

ClickHouse Materialized Views Illuminated, Part 1

header

Altinity blog的读者们知道我们喜欢ClickHouse的物化视图. 物化视图可以实现聚合计算, 从Kafka读取数据, 实现最后点查询(last point queries)以及重组表主键索引和排序顺序. 除了这些功能之外, 物化视图可以在大量节点上很好地扩缩, 并可以处理大型数据集. 它们是ClickHouse的独特功能之一.

在计算领域, 强大的功能至少意味着一点点复杂性. 这篇由两部分组成的文章通过解释物化视图的工作原理来填补空白, 从而使初学者也可以有效地使用它们. 我们将通过几个详细的示例, 您可以根据自己的使用进行调整. 在此过程中, 我们将探索用于创建视图的语法的确切含义, 并让您深入了解ClickHouse在做什么. 示例是完全自包含的, 因此您可以将它们复制/粘贴到clickhouse-client中并自己运行它们.


Powered by Hexo and Hexo-theme-hiker

Copyright © 2013 - 2021 Fan() All Rights Reserved.

访客数 : | 访问量 :