database - clickhouse 架构设计,预定义的列集
问题描述
我有多个不同模式的输入源。为了使用 Clickhouse 进行一些分析,我想到了两种处理分析工作负载的方法,使用join
或aggregation
操作:
使用连接涉及定义与每个输入对应的表。
使用聚合函数需要一个表,其中包含一组预定义的列,列的数量和列的类型将基于我的近似值,并且将来可能会改变。
我的问题是:如果我采用第二种方法,定义很多列,比如说数百列。它如何影响性能、存储成本……等?
解决方案
一般来说,一个包含所有值的大表 + 聚合函数的使用通常是 clickhouse 设计的用例。
当查询分布在机器之间时,各种类型的基于连接的查询开始在大型数据集上变得高效。但是,如果您有能力将数据保存在单个 SSD RAID 上,请尝试使用单个表和聚合函数。
当然,这是一般建议,它实际上取决于您的数据。
就不规则数据而言,根据它的变化程度,您可能需要考虑使用动态解决方案(例如 Spark 或 Elastic Search)或支持“稀疏”列的数据库(例如 Cassandra 或 ScyllaDb)。
如果您想为此使用 Clickhouse,请考虑使用数组和元组来保存它们。
总的来说,clickhouse 在压缩数据方面非常聪明,所以添加很多空值应该没问题(例如,它们几乎不会增加查询时间,也不会占用额外的空间)。查询是基于列的,因此如果您不需要特定查询的列,则性能不会受到所述列存在的简单事实的影响(例如,就像在 RDBMS 中一样)。
因此,即使您的表有 200 列,只要您的查询只使用其中 2 列,它基本上与表只有 2 列一样有效。此外,列的粒度越低,对该列的查询就越快(有一些警告)。话虽这么说,如果您计划在同一个查询中查询数百个列......它可能会变得相当慢,但 clickhouse 非常擅长并行化工作,所以如果您的数据在几十个 Tb 的较低(未压缩) ,获得一台带有一些大型 SSD 和 2 个 Xeon 的机器通常可以解决问题。
但是,这一切都在很大程度上取决于数据集,您必须解释您的数据和您需要的查询类型才能获得更有意义的答案。
推荐阅读
- airflow-scheduler - 重新处理 Airflow 的历史数据
- python - Pandas 数据类型在不使用 Try except 的情况下转换时捕获错误
- python - 在 php 中抓取受保护的电子邮件
- javascript - React native (Android) - 创建 URL.createObjectURL(blob)
- c# - 为什么我的字符串值返回为 Microsoft.EntityFrameworkCore.Query.Internal.EntityQueryable`1[System.String]
- google-cloud-dataflow - Apache Beam 有状态 ParDo 工作令牌无效
- python - 如果用户单击复选按钮,如何启用按钮
- c# - 我无法从 C# 中的子类对象获取基类字段的值
- json - 在 JSON 中具有多个条件的 AWS S3 重定向规则不会保存
- python - 删除熊猫数据框中的每一列