迁移到 ClickHouse:3 年后

三年前,Yandex 的 Viktor Tarnavsky 和 ​​Alexey Milovidov 登上舞台 高负荷++ 告诉,ClickHouse 有多好,以及它如何不慢下来。 在下一阶段有 亚历山大扎伊采夫 с 报告 关于搬到 点击之家 来自另一个分析 DBMS 的结论是 点击之家当然好,但是不是很方便。 2016年公司什么时候 LifeStreet亚历山大当时工作的地方,正在将一个多 PB 的分析系统转换为 点击之家,这是一条充满未知危险的迷人“黄砖路”—— 点击之家 那时它看起来就像一个雷区。

三年后 点击之家 变得好多了 - 在此期间,Alexander 创立了 Altinity 公司,该公司不仅帮助人们搬到 点击之家 数十个项目,同时还与 Yandex 的同事一起改进产品本身。 现在 点击之家 仍然不是无忧无虑的漫步,但不再是雷区。

Alexander 自 2003 年以来一直致力于分布式系统,开发大型项目 MySQL、甲骨文 и Vertica的。 在最后 HighLoad ++ 2019 亚历山大,使用的先驱之一 点击之家,告诉我们这个 DBMS 现在是什么。 我们将了解主要功能 点击之家:它与其他系统有何不同以及在什么情况下使用它更有效。 通过示例,我们将了解基于以下内容构建系统的最新实践和经过项目测试的实践: 点击之家.


回顾:3年前发生的事情

三年前我们转让了公司 LifeStreet 点击之家 来自另一个分析数据库,广告网络分析迁移如下所示:

  • 2016 年 XNUMX 月。 开放源代码 出现 点击之家 我们的项目开始了;
  • 八月。 概念证明:大型广告网络、基础设施和 200-300 TB 的数据;
  • 十月。 第一生产数据;
  • 十二月。 完整的产品负载为每天 10-50 亿个事件。
  • 2017年XNUMX月,用户成功迁移至 点击之家,由 2,5 台服务器组成的集群上的 60 PB 数据。

在迁移过程中,人们越来越认识到: 点击之家 是一个使用起来很愉快的好系统,但这是 Yandex 的内部项目。 因此,存在细微差别:Yandex 会首先处理自己的内部客户,然后才处理社区和外部用户的需求,而 ClickHouse 在很多功能领域都没有达到企业级别。 这就是我们于 2017 年 XNUMX 月成立 Altinity 的原因 点击之家 不仅对 Yandex 而言更快、更方便,对其他用户也同样如此。 现在我们:

  • 我们培训并帮助构建基于以下内容的解决方案 点击之家 以免客户陷入麻烦,并使解决方案最终发挥作用;
  • 我们提供 24/7 支持 点击之家- 装置;
  • 我们开发自己的生态系统项目;
  • 我们积极承诺自己 点击之家,响应想要查看某些功能的用户的请求。

当然,我们会帮助您搬到 点击之家 с MySQL的, Vertica的, 神谕, 青梅, 红移 和其他系统。 我们参与了各种举措,而且都取得了成功。

迁移到 ClickHouse:3 年后

为什么搬到 点击之家

不减速! 这是主要原因。 点击之家 - 适用于不同场景的非常快的数据库:

迁移到 ClickHouse:3 年后

长期与人共事的人的随机引述 点击之家.

可扩展性。 在其他一些数据库上,您可以在一台硬件上实现良好的性能,但是 点击之家 您不仅可以垂直扩展,还可以水平扩展,只需添加服务器即可。 一切并不像我们希望的那样顺利,但它确实有效。 您可以随着业务的增长扩展系统。 重要的是,我们不被现在的解决方案所限制,并且永远有发展的潜力。

可移植性。 对一件事没有执着。 例如,与 亚马逊Redshift 很难搬到某个地方。 A 点击之家 您可以将其安装在您的笔记本电脑、服务器上,将其部署到云端,前往 Kubernetes — 基础设施的运行没有任何限制。 这对于大家来说都是方便的,这是很多其他同类数据库无法夸耀的一大优势。

灵活性. 点击之家 并不局限于一件事,例如Yandex.Metrica,而是在越来越多的不同项目和行业中开发和使用。 它可以通过添加新功能来扩展以解决新问题。 例如,人们认为将日志存储在数据库中是不礼貌的行为,因此他们想出了 Elasticsearch。 但得益于灵活性 点击之家,您还可以在其中存储日志,通常这比在 Elasticsearch - 在 点击之家 这需要的铁量减少了十倍。

免费 开源。 您无需支付任何费用。 无需协商在笔记本电脑或服务器上安装系统的许可。 无隐藏费用。 同时,没有其他开源数据库技术可以在速度上与 点击之家. MySQL、MariaDB、Greenplum - 他们都慢得多。

社区、驱动力和 开玩笑。 在 点击之家 优秀的社区:聚会、聊天和阿列克谢·米洛维多夫(Alexey Milovidov),他给我们所有人带来了活力和乐观。

迁移到 ClickHouse

要去 点击之家 由于某种原因,你只需要三件事:

  • 了解限制 点击之家 以及它不适合什么。
  • 充分利用 技术及其最大的优势。
  • 实验。 甚至了解它是如何工作的 点击之家,并不总是能够预测什么时候会更快,什么时候会更慢,什么时候会更好,什么时候会更差。 所以尝试一下吧。

搬家问题

只有一个“但是”:如果你搬到 点击之家 如果是由于其他原因造成的,那么通常会出现问题。 我们已经习惯了一些在我们最喜欢的数据库中有效的实践和事物。 例如,任何与 SQL-数据库认为以下一组功能是强制性的:

  • 交易;
  • 限制;
  • 一致性;
  • 指数;
  • 更新/删除;
  • 空值;
  • 毫秒;
  • 自动类型转换;
  • 多重连接;
  • 任意分区;
  • 集群管理工具。

招聘是强制性的,但三年前 点击之家 这些功能都无法使用! 现在,还剩下不到一半尚未实现的内容:事务、约束、一致性、毫秒和类型转换。

最主要的是在 点击之家 一些标准做法和方法不起作用或与我们习惯的方式不同。 出现在的所有内容 点击之家,对应于“ClickHouse方式“, IE。 功能与其他数据库不同。 例如:

  • 索引未被选择,而是被跳过。
  • 更新/删除 不是同步,而是异步。
  • 有多个连接,但没有查询规划器。 对于数据库领域的人们来说,它们的执行方式通常不是很清楚。

ClickHouse 脚本

1960年,一位匈牙利裔美国数学家 维格纳EP 写了一篇文章“数学在自然科学中的不合理有效性”(《数学在自然科学中难以理解的有效性》)认为,由于某种原因,我们周围的世界可以用数学定律很好地描述。 数学是一门抽象的科学,以数学形式表达的物理定律并非微不足道,而且 维格纳EP 强调这很奇怪。

从我的观点, 点击之家 ——同样的陌生感。 用维格纳的话来说,我们可以这样说:不可思议的效率是惊人的 点击之家 在各种分析应用中!

迁移到 ClickHouse:3 年后

例如,我们以 实时数据仓库,数据几乎连续加载到其中。 我们希望在第二次延迟后收到来自它的请求。 请-使用它 点击之家,因为这是它设计的场景。 点击之家 这正是它的使用方式,不仅在网络上,而且在营销和财务分析中, AdTech,以及在 欺诈识别名词在 实时数据仓库 使用像“星”或“雪花”这样的复杂结构方案,许多表都带有 注册 (有时是多个),并且数据通常在某些系统中存储和更改。

让我们来看另一个场景—— 时间序列:设备、网络、使用统计、物联网的监控。 在这里,我们遇到了按时间顺序排列的相当简单的事件。 点击之家 最初并不是为此开发的,但已证明其运行良好,这就是大公司使用的原因 点击之家 作为监控信息的存储库。 来探讨一下是否合适 点击之家 对于时间序列,我们根据方法和结果制定了基准 数据库 и 时标数据库 - 专门化 时间序列 数据库。 事实证明点击之家,即使没有对此类任务进行优化,也能在国外领域获胜:

迁移到 ClickHouse:3 年后

В 时间序列 通常使用窄表 - 几个小列。 监控可以产生大量数据——每秒数百万条记录——而且它们通常是小突发的(实时的 流式传输)。 因此,需要不同的插入脚本,并且查询本身有其自己的细节。

日志管理。 将日志收集到数据库通常是不好的,但是 点击之家 这可以通过如上所述的一些注释来完成。 许多公司使用 点击之家 正是为了这个目的。 在这种情况下,我们使用一个平坦的宽表来存储整个日志(例如,以形式 JSON),或切成块。 数据通常是大批量(文件)加载的,并且我们通过某个字段进行搜索。

对于这些功能中的每一个,通常使用专门的数据库。 点击之家 一个人可以做所有的事情,而且做得很好,甚至超越了他们。 现在让我们仔细看看 时间序列 情景,以及如何正确“做饭” 点击之家 对于这种情况。

时间序列

目前主要场景是这样的 点击之家 考虑标准解决方案。 时间序列 是一组按时间排序的事件,表示某个过程随时间的变化。 例如,这可能是每天的心率或系统中的进程数。 一切能够给时间滴答声和某些维度的东西都是 时间序列:

迁移到 ClickHouse:3 年后

大多数此类事件来自监控。 这不仅可以监控网络,还可以监控真实设备:汽车、工业系统、 IoT、工厂或无人驾驶出租车,Yandex 已经将其放入后备箱中 点击之家-服务器。

例如,有些公司从船舶收集数据。 每隔几秒钟,集装箱船上的传感器就会发送数百个不同的测量结果。 工程师们研究它们,建立模型,并试图了解船舶的使用效率,因为集装箱船不应该闲置一秒钟。 任何停机都会造成金钱损失,因此预测路线非常重要,这样可以最大限度地减少停机时间。

如今,测量专业数据库的数量不断增加 时间序列。 在现场 数据库引擎 不同的数据库以某种方式排名,您可以按类型查看它们:

迁移到 ClickHouse:3 年后

增长最快的类型是 时间序列s。 图数据库也在增长,但是 时间序列过去几年增长速度更快。 该数据库家族的典型代表是 数据库, 普罗米修斯, KDB, 时标数据库 (建立在 PostgreSQL的),解决方案来自 Amazon. 点击之家 这里也可以使用,并且被使用。 我举几个公开的例子。

公司是先驱者之一 CloudFlare的 (- 提供商)。 他们监控他们的 通过 点击之家 (DNS-要求, HTTP-查询)具有巨大的负载 - 每秒 6 万个事件。 一切都会过去 卡夫卡,转到 点击之家,它提供了实时查看系统中事件仪表板的机会。

康卡斯特 - 美国电信领域的领导者之一:互联网、数字电视、电话。 他们创建了一个类似的控制系统 开源 项目 阿帕奇流量控制 处理您的海量数据。 点击之家 用作分析的后端。

佩尔科纳 内置 点击之家 在你的里面 PMM存储各种监控 MySQL的.

具体要求

时间序列数据库有其特定的要求。

  • 来自多个代理的快速插入。 我们必须非常快速地从许多流中插入数据。 点击之家 它做得很好,因为它的所有插入都是非阻塞的。 任何 是磁盘上的一个新文件,小插入可以以一种或另一种方式缓冲。 在 点击之家 最好批量插入数据,而不是一次插入一行。
  • 灵活的方案。 在 时间序列 我们通常不完全了解数据结构。 可以为特定应用程序构建监控系统,但很难将其用于其他应用程序。 这就需要更灵活的方案。 点击之家,允许您执行此操作,即使它是强类型基础。
  • 数据的高效存储和遗忘。 通常在 时间序列 数据量巨大,因此必须尽可能高效地存储。 例如,在 数据库 良好的压缩性是其主要特点。 但除了存储之外,您还需要能够“忘记”旧数据并执行某种操作 下采样 — 聚合体的自动计数。
  • 聚合数据快速查询。 有时以毫秒的精度查看最后 5 分钟很有趣,但对于每月的数据,可能不需要分钟或秒的粒度 - 一般统计数据就足够了。 这种支持是必要的,否则3个月的请求即使在国内也需要很长时间才能完成。 点击之家.
  • 请求如“最后一点,截至»。 这些是典型的 时间序列 查询:查看系统某一时刻的最后一次测量或状态 t。 对于数据库来说,这些查询并不是非常令人愉快的查询,但您也需要能够执行它们。
  • “粘合”时间序列. 时间序列 是一个时间序列。 如果有两个时间序列,往往需要将它们连接起来并相互关联。 在所有数据库上执行此操作并不方便,尤其是对于未对齐的时间序列:这里有一些时间点,还有其他时间点。 你可以考虑平均,但是突然那里还是会有一个洞,所以不清楚。

让我们看看如何满足这些要求 点击之家.

方案

В 点击之家 计划 时间序列 根据数据的规律性程度,可以通过不同的方式来完成。 当我们提前知道所有指标时,就可以基于常规数据构建系统。 例如,我这样做了 CloudFlare的 带监控 是一个优化良好的系统。 您可以构建一个更通用的系统来监控整个基础设施和各种服务。 在数据不规则的情况下,我们事先并不知道我们正在监控什么——这可能是最常见的情况。

常规数据。 列。 该方案很简单 - 具有所需类型的列:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

这是一个监视某种系统加载活动的常规表(用户, 系统, 闲置, 不错)。 简单方便,但不灵活。 如果我们想要更灵活的方案,那么我们可以使用数组。

不规则数据。 数组:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

产品管理 嵌套 是两个数组: 指标名称 и 指标值。 在这里,您可以将任意监控数据存储为每个事件的名称数组和测量值数组。 为了进一步优化,您可以创建多个这样的结构,而不是一个。 例如,一个用于 浮动-值,另一个 - 为 INT- 意思是因为 INT 我想更有效地存储。

但这样的结构比较难访问。 您将必须使用特殊的构造,使用特殊的函数来首先提取索引的值,然后提取数组的值:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

但它仍然工作得很快。 存储不规则数据的另一种方法是按行。

不规则数据。 弦乐。 在这种传统方法中,没有数组,名称和值是同时存储的。 如果一台设备同时发出 5 个测量值,则数据库中会生成 000 行:

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

点击之家 解决这个问题 - 它有特殊的扩展 点击之家 SQL。 例如, 最大If — 一种特殊函数,在满足某些条件时计算度量的最大值。 您可以在一个请求中编写多个此类表达式,并立即计算多个指标的值。

让我们比较一下三种方法:

迁移到 ClickHouse:3 年后

Детали

这里我为一些测试数据集添加了“磁盘数据大小”。 就列而言,我们拥有最小的数据大小:最大压缩、最大查询速度,但我们必须一次记录所有内容。

对于数组来说,一切都有点糟糕。 数据仍然被很好地压缩并且可以存储不规则的模式。 但 点击之家 - 列式数据库,当我们开始将所有内容存储在数组中时,它就会变成行一,我们为灵活性和效率付出了代价。 对于任何操作,您都必须将整个数组读入内存,然后在其中找到所需的元素 - 如果数组增长,则速度会降低。

在使用这种方法的公司之一(例如, 尤伯杯),数组被切割成 128 个元素的块。 每天200TB数据量的数千个指标的数据不是存储在一个阵列中,而是存储在具有特殊存储逻辑的10或30个阵列中。

最简单的方法是使用字符串。 但数据压缩率很差,表大小很大,即使基于多个指标进行查询,ClickHouse 也无法以最佳方式工作。

混合方案

假设我们选择了阵列电路。 但是,如果我们知道大多数仪表板仅显示用户和系统指标,那么我们还可以通过以下方式将这些指标具体化为表级别数组中的列:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

插入时 点击之家 会自动计算它们。 这样您就可以将工作与娱乐结合起来:该方案灵活且通用,但我们提取了最常用的列。 请注意,这不需要更改插入件和 ETL它继续将数组插入表中。 我们刚刚做了 更改表,添加了几个扬声器,我们得到了一个混合且更快的方案,您可以立即开始使用。

编解码器和压缩

时间序列 数据打包的好坏很重要,因为信息量可能非常大。 在 点击之家 有一组工具可以实现1:10、1:20、有时甚至更多的压缩效果。 这意味着磁盘上 1 TB 的解压数据占用 50-100 GB。 尺寸越小越好,可以更快地读取和处理数据。

为了实现高水平的压缩, 点击之家 支持以下编解码器:

迁移到 ClickHouse:3 年后

示例表:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

这里我们定义编解码器 双三角洲 在一种情况下,在第二种情况下 - 大猩猩,我们肯定会添加更多 LZ4 压缩。 结果,磁盘上数据的大小大大减小:

迁移到 ClickHouse:3 年后

这显示了相同的数据占用多少空间,但使用不同的编解码器和压缩:

  • 在磁盘上的 GZIP 文件中;
  • 在 ClickHouse 中,没有编解码器,但使用 ZSTD 压缩;
  • 在 ClickHouse 中,具有编解码器和压缩 LZ4 和 ZSTD。

可以看出,带有编解码器的表占用的空间要少得多。

大小很重要

不那么重要 选择 正确的数据类型:

迁移到 ClickHouse:3 年后

在上面的所有例子中我都使用了 浮点64。 但如果我们选择 浮点32,那就更好了。 Perkona 的人在上面链接的文章中很好地证明了这一点。 使用适合该任务的最紧凑的类型非常重要:磁盘大小甚至小于查询速度。 点击之家 对此非常敏感。

如果你可以使用 int32 而不是 int64,那么预计性能将提高近两倍。 数据占用的内存更少,所有的“算术”运行得更快。 点击之家 在内部,它是一个类型非常严格的系统;它最大限度地利用了现代系统提供的所有可能性。

聚合和 物化视图

聚合和物化视图允许您为不同场合创建聚合:

迁移到 ClickHouse:3 年后

例如,您可能有非聚合的源数据,您可以通过特殊引擎将各种物化视图附加到它们上并自动求和 求和合并树 (SMT). SMT 是一种特殊的聚合数据结构,可以自动计算聚合。 原始数据被插入数据库,自动聚合,并且可以立即在其上使用仪表板。

TTL - “忘记”旧数据

如何“忘记”不再需要的数据? 点击之家 知道如何做到这一点。 创建表时可以指定 TTL 表达式:例如,我们存储一天的分钟数据,30天的每日数据,并且从不触及每周或每月的数据:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

多层 - 将数据划分到磁盘上

进一步发展这个想法,数据可以存储在 点击之家 在不同的地方。 假设我们想将上周的热数据存储在一个非常快的本地 SSD,我们把更多的历史数据放在另一个地方。 在 点击之家 现在这是可能的:

迁移到 ClickHouse:3 年后

您可以配置存储策略(存储策略) 所以 点击之家 达到一定条件时会自动将数据传输到另一个存储。

但这还不是全部。 在特定表的级别,您可以准确定义数据何时进入冷存储的规则。 例如,数据在非常快的磁盘上存储 7 天,较旧的所有内容都会转移到慢速磁盘上。 这很好,因为它允许您使系统保持最佳性能,同时控制成本并且不会在冷数据上浪费金钱:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

独特的功能 点击之家

几乎在所有事情上 点击之家 确实有这样的“亮点”,但它们被排他性所抵消——这是其他数据库所没有的。 例如,以下是一些独特的功能 点击之家:

  • 阵列。 在 点击之家 对数组非常好的支持,以及对它们执行复杂计算的能力。
  • 聚合数据结构。 这是“杀手级功能”之一 点击之家。 尽管 Yandex 的人说我们不想聚合数据,但所有内容都聚合在 点击之家,因为它又快又方便。
  • 物化视图。 与聚合数据结构一起,物化视图使您可以方便地 实时的 聚合。
  • ClickHouse SQL。 这是一个语言扩展 SQL 具有一些仅在 点击之家。 以前,一方面像是扩张,另一方面又像是一种劣势。 现在几乎所有的缺点相比 SQL 92 我们删除了它,现在它只是一个扩展。
  • LAMBDA– 表达式。 它们还在数据库中吗?
  • ML-支持。 这在不同的数据库中可用,有些更好,有些更差。
  • 开源。 我们可以扩展 点击之家 一起。 现在在 点击之家 大约有 500 名贡献者,而且这个数字还在不断增长。

棘手的查询

В 点击之家 做同一件事有很多不同的方法。 例如,您可以通过三种不同的方式返回表中的最后一个值: 中央处理器 (还有第四种,但更加奇特)。

第一个显示了它是多么方便 点击之家 当你想检查时查询 元组 包含在子查询中。 这是我个人在其他数据库中真正错过的东西。 如果我想将某些内容与子查询进行比较,那么在其他数据库中只能与标量进行比较,但是对于几个列,我需要编写 注册。 在 点击之家 你可以使用元组:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

第二种方法做同样的事情,但使用聚合函数 最大参数:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

В 点击之家 有几十个聚合函数,如果使用组合器,那么根据组合定律,您将得到大约一千个。 最大精氨酸 - 计算最大值的函数之一:请求返回值 使用用户,此时达到最大值 创建时间:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

加入 — 用不同的时间“粘合”行。 这是数据库独有的功能,仅在 kdb +。 如果有两个不同时间的时间序列, 加入 允许您在一个请求中移动和合并它们。 对于一个时间序列中的每个值,找到另一个时间序列中最接近的值,并将它们在同一行上返回:

迁移到 ClickHouse:3 年后

解析函数

在标准 SQL-2003 你可以这样写:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В 点击之家 你不能这样做——它不支持标准 SQL-2003 并且可能永远不会这样做。 相反,在 点击之家 习惯上这样写:

迁移到 ClickHouse:3 年后

我答应过 lambda - 它们就在这里!

这是标准中分析查询的模拟 SQL-2003: 他计算两者之间的差异 时间戳、持续时间、序数 - 我们通常认为的分析函数的所有内容。 在 点击之家 我们通过数组对它们进行计数:首先我们将数据折叠到一个数组中,然后我们对数组执行我们想要的所有操作,然后将其扩展回来。 它不是很方便,至少需要热爱函数式编程,但它非常灵活。

特殊功能

此外,在 点击之家 许多专门的功能。 例如,如何确定有多少会话同时进行? 一项典型的监控任务是确定一个请求的最大负载。 在 点击之家 为此有一个特殊的函数:

迁移到 ClickHouse:3 年后

总的来说,ClickHouse 有多种用途的特殊功能:

  • runningDifference、runningAccumulate、neighbor;
  • sumMap(键, 值);
  • timeSeriesGroupSum(uid, 时间戳, 值);
  • timeSeriesGroupRateSum(uid, 时间戳, 值);
  • skewPop、skewSamp、kurtPop、kurtSamp;
  • 带填充/带系带;
  • 简单线性回归,随机线性回归。

这不是完整的功能列表,总共有 500-600 个。 提示:所有函数 点击之家 位于系统表中(并非所有内容都有记录,但所有内容都很有趣):

select * from system.functions order by name

点击之家 它存储了很多关于自身的信息,包括 日志表, 查询日志、跟踪日志、数据块操作日志(部分日志)、指标日志和系统日志,通常将其写入磁盘。 日志指标是 时间序列 в 点击之家 事实上 点击之家:数据库本身就可以发挥作用 时间序列 数据库,从而“吞噬”自身。

迁移到 ClickHouse:3 年后

这也是一件独特的事情——因为我们做得很好 时间序列,为什么我们不能把我们需要的一切都储存在自己身上呢? 我们不需要 普罗米修斯,我们把一切都留给自己。 连接的 格拉法纳 我们监控自己。 然而,如果 点击之家 跌倒了,我们不知道为什么,所以他们通常不会这样做。

大簇或许多小簇 点击之家

一个大型集群和许多小型 ClickHouse 哪个更好? 传统方法 W 是一个大集群,其中为每个应用程序分配了电路。 我们找到数据库管理员 - 给我们一张图表,他们给了我们一个:

迁移到 ClickHouse:3 年后

В 点击之家 你可以用不同的方式来做。 您可以将每个应用程序变成您自己的应用程序 点击之家:

迁移到 ClickHouse:3 年后

我们不再需要那个巨大的怪物了 W 和棘手的管理员。 我们可以为每个应用程序提供其自己的 点击之家,开发者可以自己做,因为 点击之家 安装非常简单,不需要复杂的管理:

迁移到 ClickHouse:3 年后

但如果我们有很多 点击之家,并且您需要经常安装它,那么您希望自动化此过程。 为此,我们可以例如使用 Kubernetes и 点击之家-操作员。 在 Kubernetes ClickHouse 您可以将其“单击”:我可以单击一个按钮,运行清单,数据库就准备好了。 我可以立即创建图表,开始上传指标,5 分钟内我就准备好了仪表板 格拉法纳。 就这么简单!

结果如何呢?

因此, 点击之家 - 这个:

  • 很快。 每个人都知道这一点。
  • 只是。 有点争议,但我认为训练难,战斗容易。 如果你明白如何 点击之家 它有效,那么一切就非常简单了。
  • 普遍地。 适用于不同场景: DWH、时间序列、日志存储。 但事实并非如此 OLTP 数据库,所以不要尝试在那里进行短插入和读取。
  • 有趣。 可能是和他一起工作的人 点击之家,经历了许多有趣的时刻,无论是好的还是坏的。 例如,新版本发布后,一切都停止了。 或者当你在一项任务上苦苦挣扎了两天,但在 Telegram 聊天中提出问题后,任务在两分钟内就得到了解决。 或者像 Lesha Milovidov 的报告中的会议一样,截图来自 点击之家 打破了广播 高负荷++。 这种事情时常发生,让我们的生活变得困难。 点击之家 明亮又有趣!

您可以观看演示 这里.

迁移到 ClickHouse:3 年后

期待已久的高负载系统开发人员会议 高负荷++ 将于 9 月 10 日至 XNUMX 日在斯科尔科沃举行。 最后,这将是一次线下会议(尽管采取了所有预防措施),因为 HighLoad++ 的能量无法在线打包。

在这次会议上,我们找到并向您展示有关技术最大能力的案例:HighLoad++ 过去、现在和将来都是您可以在两天内了解 Facebook、Yandex、VKontakte、Google 和 Amazon 如何工作的唯一地方。

自2007年以来,我们的会议从未间断过,今年我们将举行第14次会议。 在此期间,会议规模扩大了 10 倍;去年,这项重要的行业盛会汇聚了 3339 名参与者、165 位演讲嘉宾、报告和聚会,16 个分会场同时举行。
去年有20辆公共汽车、5280升茶和咖啡、1650升果汁饮料和10200瓶水。 还有2640公斤食物、16个盘子和000个杯子。 顺便说一句,我们用回收纸筹集的资金种植了 25 棵橡树苗:)

你可以买票 这里,获取有关会议的新闻 - 这里,并在所有社交网络上讨论: Telegram, Facebook, VKontakte等 и Twitter.

来源: habr.com

添加评论