访问顺序表中任意元素的时间都相等，具有这一特点的存储结构称为随机存取结构。

根据个人猜测，可能是为了控制primary.idx文件的大小。order by 决定了数据写入文件的顺序，primary key 决定了索引文件primary.idx的大小。如果order by指定的字段过大，可能会导致索引文件超级大，影响查询效率。此时可以通过单独指定primary key来解决这个问题。

当然为了防止出现小文件问题，ch有后台进程合并文件夹，减少小文件的负担。

向clickhouse插入数据的时候，每次insert都会产生一个文件夹

就像选择算法一样，它将输入分成已排序的和还未排序的区域，它通过提取未排序的区域内最大的元素并将其移动到已排序的区域来迭代缩小未排序的区域。堆排序相对选择排序改进的部分包括使用堆数据结构而不是线性时间的搜索来找到最大值。

值得一提的是，通常只有在使用SummingMergeTree或AggregatingMergeTree的时候，才需要同时设置ORDER BY与PRIMARY KEY。 显式的设置PRIMARY KEY，是为了将主键和排序键设置成不同的值，是进一步优化的体现。

对于表的并发访问，我们使用多版本机制。换言之，当一张表同时被读和更新时，数据从当前查询到的一组片段中读取。没有冗长的的锁。插入不会阻碍读取。对表的读操作是自动并行的。

每个数据片段被逻辑的分割成颗粒（granules）。颗粒是 ClickHouse 中进行数据查询时的最小不可分割数据集。ClickHouse 不会对行或值进行拆分，所以每个颗粒总是包含整数个行。每个颗粒的第一行通过该行的主键值进行标记， ClickHouse 会为每个数据片段创建一个索引文件来存储这些标记。

Compact 格式可以提高插入量少插入频率频繁时的性能。

因此，仅使用日期而没有用主键字段作为条件的查询将会导致需要读取超过这个指定日期以外的数据。

在块中，数据按主键排序，主键第一列可能不包含日期

要检查 ClickHouse 执行一个查询时能否使用索引，可设置 force_index_by_date 和 force_primary_key 。

对排序键进行 ALTER 是轻量级的操作，因为当一个新列同时被加入到表里和排序键里时，已存在的数据片段并不需要修改。由于旧的排序键是新排序键的前缀，并且新添加的列中没有数据，因此在表修改时的数据对于新旧的排序键来说都是有序的。

但这将导致排序键中包含大量的列，并且排序键会伴随着新添加的维度不断的更新。在这种情况下合理的做法是，只保留少量的列在主键当中用于提升扫描效率，将维度列添加到排序键中。

由于 SummingMergeTree 和 AggregatingMergeTree 会对排序键相同的行进行聚合，所以把所有的维度放进排序键是很自然的做法

可以使用 ORDER BY tuple() 语法创建没有主键的表。在这种情况下 ClickHouse 根据数据插入的顺序存储。如果在使用 INSERT ... SELECT 时希望保持数据的排序，请设置 max_insert_threads = 1。

该命令将表的排序键更改为 new_expression(表达式或表达式元组)。主键保持不变。

Flink supports Counters, Gauges, Histograms and Meters.

拥有一个预先存在的集群可以节省大量时间申请资源和启动 TaskManager

每个 TaskManager 有一个 slot，这意味着每个 task 组都在单独的 JVM 中运行（例如，可以在单独的容器中启动）。具有多个 slot 意味着更多 subtask 共享同一 JVM。同一 JVM 中的 task 共享 TCP 连接（通过多路复用）和心跳信息。它们还可以共享数据集和数据结构，从而减少了每个 task 的开销。

调整 task slot 的数量，用户可以定义 subtask 如何互相隔离

每个 worker（TaskManager）都是一个 JVM 进程

算子链接成 task 是个有用的优化：它减少线程间切换、缓冲的开销，并且减少延迟的同时增加整体吞吐量。链行为是可以配置的；请参考链文档以获取详细信息。

JobMaster 负责管理单个JobGraph的执行。Flink 集群中可以同时运行多个作业，每个作业都有自己的 JobMaster。

决定何时调度下一个 task（或一组 task）、对完成的 task 或执行失败做出反应、协调 checkpoint、并且协调从失败中恢复等等

JobManager 具有许多与协调 Flink 应用程序的分布式执行有关的职责

自定义指标

You can use the --hive-drop-import-delims option to drop those characters on import to give Hive-compatible text data.

您可以使用 typedef 为一个已有的类型取一个新的名字。下面是使用 typedef 定义一个新类型的语法：

下一行 using namespace std; 告诉编译器使用 std 命名空间。命名空间是 C++ 中一个相对新的概念。

we define a tumbling window with the size of 2 milliseconds, which results in windows of the form [0,1], [2,3],

Because this behaves like an inner join, elements of one stream that do not have elements from another stream in their tumbling window are not emitted!

Those elements that do get joined will have as their timestamp the largest timestamp that still lies in the respective window. For example a window with [5, 10) as its boundaries would result in the joined elements having 9 as their timestamp.

like an inner-join

通过ClickHouse官方的JDBC向ClickHouse中批量写入数据时，必须控制每个批次的数据中涉及到的分区的数量，在写入之前最好通过Order By语句对需要导入的数据进行排序。无序的数据或者数据中涉及的分区太多，会导致ClickHouse无法及时的对新导入的数据进行合并，从而影响查询性能。

为每一个账户添加join_use_nulls配置。ClickHouse的SQL语法是非标准的，默认情况下，以Left Join为例，如果左表中的一条记录在右表中不存在，右表的相应字段会返回该字段相应数据类型的默认值，而不是标准SQL中的Null值。对于习惯了标准SQL的我们来说，这种返回值经常会造成困扰。

zookeeper压力太大，clickhouse表处于”read only mode”，插入失败

建表的时候添加use_minimalistic_part_header_in_zookeeper参数，对元数据进行压缩存储

上面有说过clickhouse对zookeeper的依赖非常的重，表的元数据信息，每个数据块的信息，每次插入的时候，数据同步的时候，都需要和zookeeper进行交互，上面存储的数据非常的多。

分区字段的设置要慎重考虑，如果每次插入涉及的分区太多，那么不仅容易出现上面的异常，同时在插入的时候也比较耗时，原因是每个数据目录都需要和zookeeper进行交互。

文件夹的生成速度太快，merge速度跟不上了，所以官方文档的上每秒不超过1个插入请求，更准确的说是每秒不超过1个数据目录。

当order by已使用max_bytes_before_external_sort内存就进行溢写磁盘(基于磁盘排序)，如果不设置该值，那么当内存不够时直接抛错，设置了该值order by可以正常完成，但是速度相对存内存来说肯定要慢点(实测慢的非常多，无法接受)

在进行group by的时候，内存使用量已经达到了max_bytes_before_external_group_by的时候就进行写磁盘(基于磁盘的group by相对于基于磁盘的order by性能损耗要好很多的)，一般max_bytes_before_external_group_by设置为max_memory_usage / 2，原因是在clickhouse中聚合分两个阶段：

对于JOIN场景，我们需要注意的是clickhouse在进行JOIN的时候都是将"右表"进行多节点的传输的(右表广播)

zookeeper主要存放了两类文件，一个是snapshot和log,前者是内存数的快照，后者类似mysql的binlog，将所有与修改数据相关的操作记录在log中，两类文件的目录可在配置文件中指定。