ClickHouse 性能

简介: ClickHouse 性能

1、单个大查询的吞吐量

   数据在page cache中,不复杂查询单个服务器大约2-10GB/S(未压缩)的速度进行处理(简单查询速度可以达到30GB/S),不在page cache中,速度取决于磁盘和数据压缩率,例如:磁盘允许400MB/S速度读取数据,数据压缩率是3,则数据处理速度为1.2GB/S,如果是在提取一个10字节的列,处理速度大约是1-2亿行每秒。

2、处理短查询的延迟时间

   一个查询使用主键并没有太多行(几十万)进行处理,并且没有查询太多的列,数据在page cache的情况,延迟应小于50ms(最佳小于10ms),否则延迟取决于数据的查询次数,如果使用的是磁盘,在数据没有加载的情况,查询所需要的延迟可以通过以下公式计算:查找时间(10ms)*查询的列的数量*查询的数据块的数量

3、处理大量段查询的吞吐量

   单个服务器上每秒处理数百个查询(最佳可以处理上千个),由于这不适用于分析场景,建议每秒查询最多100次

4、数据的写入性能

   建议每次写入不少于1000行或每秒不超过一个写入请求。当使用tab-separated格式将一份数据写入到MergeTree表中时,写入速度大约为50~200MB/S。如果写入数据每行为1kb,写入速度为5W~20W行每秒。如果行更小,写入速度更高。为了提高写入性能,您可以使用多个insert进行并列写入,将带来线性的性能提升。


相关文章
|
15天前
|
存储 SQL 缓存
优化ClickHouse查询性能:最佳实践与调优技巧
【10月更文挑战第26天】在大数据分析领域,ClickHouse 以其卓越的查询性能和高效的列式存储机制受到了广泛的关注。作为一名已经有一定 ClickHouse 使用经验的开发者,我深知在实际应用中,合理的表设计、索引优化以及查询优化对于提升 ClickHouse 性能的重要性。本文将结合我的实践经验,分享一些有效的优化策略。
38 3
|
1月前
|
存储 关系型数据库 MySQL
四种数据库对比MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景
四种数据库对比 MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景
|
存储 SQL 人工智能
ClickHouse创始人:融合数据库该“卷”的还是性能和速度
在刚刚结束的阿里云瑶池数据库峰会上,阿里云宣布与全球流行的开源分析型数据库 ClickHouse 正式签订战略合作协议,成为 ClickHouse 在中国独家的云服务提供商,并提供具备独有企业能力的 ClickHouse 版本。借此机会,王一鹏有幸独家专访了 ClickHouse 创始人兼 CTO Alexey Milovidov、阿里云数据库事业部 OLAP 产品部负责人林亮,围绕 ClickHouse 演进迭代的历程、双方此次合作的契机、当前数据库技术所面临的挑战和机遇,以及 OLAP 数据库未来发展趋势等问题展开深度对谈。
58796 3
ClickHouse创始人:融合数据库该“卷”的还是性能和速度
|
存储 SQL 人工智能
用C++写出比MySQL快800倍的数据库,ClickHouse创始人:融合数据库该“卷”的还是性能和速度
ClickHouse经历了怎样的演进迭代历程?当前数据库行业面临哪些挑战?AIGC火热发展会给数据库带来哪些新机遇?
|
5月前
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替"Greater Seattle Area"),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
58 6
|
5月前
|
XML NoSQL 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 概念 + 数据模型
【6月更文挑战第5天】本文探讨了数据模型的分析,关注点包括数据元素、关系及不同类型的模型(关系、文档、图)与Schema模式。查询语言的考量涉及与数据模型的关联及声明式与命令式编程。数据模型从应用开发者到硬件工程师的各抽象层次中起着简化复杂性的关键作用,理想模型应具备简洁直观和可组合性。
39 2
|
5月前
|
SQL 人工智能 关系型数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展,允许节点有多重父节点,但导航复杂,需要预知数据库结构。关系模型将数据组织为元组和关系,强调声明式查询,解耦查询语句与执行路径,简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据,提供弱模式灵活性,但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系,适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read,写入时不校验,读取时解析,牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
48 0
|
5月前
|
SQL JSON NoSQL
【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型
【6月更文挑战第6天】关系模型是主流数据库模型,以二维表形式展示数据,支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战,如网状和层次模型,但关系模型仍占主导。然而,随着大数据增长和NoSQL的出现(如MongoDB、Redis),强调伸缩性、专业化查询和表达力,关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题,ORM框架缓解但未完全解决。文档模型(如JSON)提供更自然的嵌套结构,适合表示复杂关系,具备模式灵活性和更好的数据局部性。
53 0
|
5月前
|
敏捷开发 存储 缓存
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可维护性
【6月更文挑战第4天】本文探讨了Twitter面临的一次发推文引发的巨大写入压力问题,指出用户粉丝数分布是决定系统扩展性的关键因素。为解决此问题,Twitter采用混合策略,大部分用户推文扇出至粉丝主页时间线,而少数名人推文则单独处理。性能指标包括吞吐量、响应时间和延迟,其中高百分位响应时间对用户体验至关重要。应对负载的方法分为纵向和横向扩展,以及自动和手动调整。文章强调了可维护性的重要性,包括可操作性、简单性和可演化性,以减轻维护负担和适应变化。此外,良好设计应减少复杂性,提供预测性行为,并支持未来改动。
59 0
|
5月前
|
缓存 关系型数据库 数据库
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可扩展性
【6月更文挑战第3天】可扩展性关乎系统应对负载增长的能力,但在产品初期过度设计可能导致失败。理解基本概念以应对可能的负载增长是必要的。衡量负载的关键指标包括日活、请求频率、数据库读写比例等。推特的扩展性挑战在于"扇出",即用户关注网络的广度。两种策略包括拉取(按需查询数据库)和推送(预计算feed流)。推送方法在推特案例中更为有效,因为它减少了高流量时的实时计算压力。
53 0