问题导读 1.什么是ClickHouse? 2.ClickHouse适合哪些场景? 3.为什么面向列的数据库查询如此快? 关注最新经典文章,欢迎关注公众号 1.什么是ClickHouse ClickHouse是一个面向列的数据库管理系统(DBMS),用于在线分析处理查询(OLAP)。 在“传统”面向行的DBMS中,数据按以下顺序存储: 换句话说,与行相关的所有值都物理地存储在彼此旁边。 面向行的DBMS的示例是MySQL,Postgres和MS SQL Server。 在面向列的DBMS中,数据存储如下: 这些示例仅显示数据的排列顺序。不同列的值分别存储,同一列的数据存储在一起。 面向列的DBMS的示例:Vertica,Paraccel(Actian Matrix和Amazon Redshift),Sybase IQ,Exasol,Infobright,InfiniDB,MonetDB(VectorWise和Actian Vector),LucidDB,SAP HANA,Google Dremel,Google PowerDrill,Druid和KDB +。 存储数据的不同顺序更适合于不同的场景。数据访问场景是指进行了哪些查询,多长时间以及以何种比例进行查询;为每种类型的查询读取多少数据 - 行,列和字节;读取和更新数据之间的关系;数据大小以及如何使用本地数据;transactions是否被使用,以及它们是否隔离;数据replication和逻辑完整性的要求;每种类型的查询的延迟和吞吐量要求,等等。 系统负载越高,定制系统设置以匹配使用方案的要求就越重要,并且此定制变得越精细。没有一个系统同样适用于明显不同的场景。如果系统适应各种场景,在高负载下,系统将同样处理所有场景,或者仅适用于一种或几种可能的场景。 2.OLAP场景的关键属性
很容易看出OLAP场景与其他流行场景(例如OLTP或键值访问)非常不同。 因此,如果希望获得不错的性能,尝试使用OLTP或键值DB来处理分析查询是没有意义的。 例如,如果尝试使用MongoDB或Redis进行分析,则与OLAP数据库相比,性能会非常差。 3.为什么面向列的数据库在OLAP场景中更好地工作 面向列的数据库更适合OLAP场景:它们在处理大多数查询时至少快100倍。 原因在下面详细解释,但事实更容易在视觉上展示: 面向行的DBMS 面向列的DBMS 看到不同? 输入/输出
例如,查询“计算每个广告平台的记录数”需要读取一个“广告平台ID”列,其占用未压缩的1个字节。 如果大多数流量不是来自广告平台,则可以预期此列的压缩率至少为10倍。 当使用快速压缩算法时,数据解压缩可以每秒至少几千兆字节的未压缩数据的速度进行。 换句话说,可以在单个服务器上以每秒大约几十亿行的速度处理该查询。 这种速度实际上是在实践中实现的。 例子: [Bash shell] 纯文本查看 复制代码 $ clickhouse-client CPU 由于执行查询需要处理大量行,因此有助于为整个向量而不是单独的行调度所有操作,或者实现查询引擎以便几乎不需要调度成本。如果不这样做,使用任何半正常的磁盘子系统,查询解释器将不可避免地停止CPU。将数据存储在列中并在可能的情况下按列处理它是有意义的。 有两种方法可以做到这一点: 向量引擎:所有操作都是为向量而不是为单独的值编写的。这意味着不需要经常调用操作,并且调度成本可以忽略不计。操作代码包含优化的内部循环。 代码生成:为查询生成的代码中包含所有间接调用。 这不是在“传统”数据库中完成的,因为在运行简单查询时没有意义。但是,也有例外。例如,MemSQL使用代码生成来减少处理SQL查询时的延迟。 (为了进行比较,分析DBMS需要优化吞吐量,而不是延迟。) 请注意,对于CPU效率,查询语言必须是声明性的(SQL或MDX),或者至少是向量(J,K)。查询应该只包含隐式循环,允许优化。 |
|小黑屋|about云开发-学问论坛|社区 ( 京ICP备12023829号 )
GMT+8, 2018-11-1 20:25 , Processed in 0.350824 second(s), 30 queries , Gzip On.