ClickHouse 特性

简介: ClickHouse 特性

1、真正的列式数据库管理系统

   支持固定长度数值类型

   允许在运行时创建表和数据库、加载数据和运行查询,无需重新配置或者重启服务

2、数据压缩

   达到优异的性能呢,数据压缩起到了至关重要的作用

3、数据的磁盘存储

   支持内存和磁盘存储

4、多核心并行处理

   使用一切可以用的资源,以最自然的方式并行处理大型查询

5、多服务器分布式处理

   支持分布式查询处理

   数据保存在不同的shard上,每一个shard都由一组用于容错的replica组成,查询可以并行在所有shard上进行处理

6、支持SQL

   基于SQL的声明式查询语言,执行SQL标准兼容并支持包括group by,order by,in,join以及非相关子查询

   不支持串口函数和相关子查询

7、向量引擎

   数据不仅仅按列存储,同时还按向量(列的一部分)进行处理,更加高效实用CPU

8、实时的数据更新

   支持在表中定义主键,为了使查询能够快速在主键中进行范围查找,数据总是以增量的方式有序的存储在MergeTree中。因此,数据可以持续不断地高效的写入到表中,并且写入的过程中不会存在任何加锁的行为。

9、索引

   按照主键对数据进行排序,在几十毫秒内完成对数据特定值或范围的查找

10、适合在线查询

   在线查询意味着在没有对数据做任何预处理的情况下以极低的延迟处理查询并将结果加载到用户的页面中

11、支持近似计算

   提供各种各样在允许牺牲数据精度的情况下对数据查询进行加速的方法:

       1、用于近似计算各类聚合函数,入:distinct values,medians,quantiles

       2、基于数据的部分样板进行近似查询。这时,仅会从磁盘检索少部分比例的数据

       3、不适用全部的聚合条件,通过随机选择有限个数据聚合条件进行聚合。这在数据聚合条件满足某些分布式条件下,在提供相当于准确的聚合结果的不同时降低了计算资源的使用。

12、支持数据复制和数据完整性

   使用异步的多主复制技术。当数据被写入任何一个可用副本后,系统会在后台将数据分发给其它副本,以保证系统在不同副本上保持相同的数据。在大多数情况下能在故障后启动恢复,一些少数的复杂情况下需要手动恢复

13、限制

   1、没有完整的事物支持

   2、缺少高频率,低延迟的修改或删除已存在的数据能力。仅能用于批量删除或修改数据,这符合GDPR

   3、稀疏索引使得不适合通过其键检索单行的点查询


相关文章
|
存储 缓存
clickhouse新特性之————MergeTree启动加速(使用篇)
clickhouse新特性之————MergeTree启动加速(使用篇)
1080 0
|
存储 SQL JSON
一文读懂 ClickHouse V22.8 新版本重要特性
ClickHouse 又双叒叕发布新版本了。
一文读懂 ClickHouse V22.8 新版本重要特性
|
存储 SQL 数据采集
ClickHouse V22.8 新特性介绍
ClickHouse V22.8 版本作为社区推荐的 LTS 版本经过几个月的稳定性后迭代后,已经完全可以应用于生产环境。本文将介绍V22.8版本的重要特性发布,包括半结构化数据的存储和分析性能的增强,轻量 Delete 标准 SQL支持,引擎内置远程文件的查询缓存机制等能力的详细介绍,同时对于社区的技术演进方向进行探讨。
1424 1
|
存储 SQL JSON
ClickHouse特性
ClickHouse特性
180 0
|
5月前
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替"Greater Seattle Area"),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
59 6
|
5月前
|
XML NoSQL 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 概念 + 数据模型
【6月更文挑战第5天】本文探讨了数据模型的分析,关注点包括数据元素、关系及不同类型的模型(关系、文档、图)与Schema模式。查询语言的考量涉及与数据模型的关联及声明式与命令式编程。数据模型从应用开发者到硬件工程师的各抽象层次中起着简化复杂性的关键作用,理想模型应具备简洁直观和可组合性。
39 2
|
5月前
|
SQL 人工智能 关系型数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展,允许节点有多重父节点,但导航复杂,需要预知数据库结构。关系模型将数据组织为元组和关系,强调声明式查询,解耦查询语句与执行路径,简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据,提供弱模式灵活性,但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系,适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read,写入时不校验,读取时解析,牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
49 0
|
5月前
|
SQL JSON NoSQL
【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型
【6月更文挑战第6天】关系模型是主流数据库模型,以二维表形式展示数据,支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战,如网状和层次模型,但关系模型仍占主导。然而,随着大数据增长和NoSQL的出现(如MongoDB、Redis),强调伸缩性、专业化查询和表达力,关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题,ORM框架缓解但未完全解决。文档模型(如JSON)提供更自然的嵌套结构,适合表示复杂关系,具备模式灵活性和更好的数据局部性。
53 0
|
5月前
|
敏捷开发 存储 缓存
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可维护性
【6月更文挑战第4天】本文探讨了Twitter面临的一次发推文引发的巨大写入压力问题,指出用户粉丝数分布是决定系统扩展性的关键因素。为解决此问题,Twitter采用混合策略,大部分用户推文扇出至粉丝主页时间线,而少数名人推文则单独处理。性能指标包括吞吐量、响应时间和延迟,其中高百分位响应时间对用户体验至关重要。应对负载的方法分为纵向和横向扩展,以及自动和手动调整。文章强调了可维护性的重要性,包括可操作性、简单性和可演化性,以减轻维护负担和适应变化。此外,良好设计应减少复杂性,提供预测性行为,并支持未来改动。
60 0
|
5月前
|
缓存 关系型数据库 数据库
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可扩展性
【6月更文挑战第3天】可扩展性关乎系统应对负载增长的能力,但在产品初期过度设计可能导致失败。理解基本概念以应对可能的负载增长是必要的。衡量负载的关键指标包括日活、请求频率、数据库读写比例等。推特的扩展性挑战在于"扇出",即用户关注网络的广度。两种策略包括拉取(按需查询数据库)和推送(预计算feed流)。推送方法在推特案例中更为有效,因为它减少了高流量时的实时计算压力。
53 0