腾讯云
开发者社区
文档
建议反馈
控制台
首页
学习
活动
专区
工具
TVP
最新优惠活动
文章/答案/技术大牛
搜索
搜索
关闭
发布
登录/注册
首页
学习
活动
专区
工具
TVP
最新优惠活动
返回腾讯云官网
数据计算
专栏成员
举报
15
文章
1680
阅读量
13
订阅数
订阅专栏
申请加入专栏
全部文章(15)
sql(9)
高性能计算(5)
性能优化(5)
数据库(4)
java(3)
大数据(2)
bi(2)
python(1)
大数据解决方案(1)
存储(1)
开源(1)
数据分析(1)
高性能计算平台(1)
clickhouse(1)
data(1)
hash(1)
join(1)
lambda(1)
olap(1)
pandas(1)
size(1)
存储技术(1)
大数据处理(1)
代码优化(1)
排序(1)
软件(1)
软件开发(1)
索引(1)
性能(1)
性能分析(1)
搜索文章
搜索
搜索
关闭
列式存储的另一面
存储
存储技术
性能优化
sql
列存是常见的数据存储技术,说到列存常常就意味着高性能,现代分析型数据库基本都会把列存作为标配, 列存的基本原理是减少硬盘的读取量。一个数据表有多个列,但运算可能只会用到其中少数几列,采用列存时,用不着的列就不必读出来了,而采用行式存储时,则要把所有列都扫描一遍。当取用列只占总列数的小部分时,列存的 IO 时间优势会非常大,就会显得计算速度快了很多。 不过,列存也有另一面,并不是在任何场景下都有优势。
朱迪
2024-05-20
91
0
其实你就学不会 Python
pandas
size
python
lambda
标题党一下,Python 程序员成千上万,当然有很多人学得会。这里说的“你”,是指职场中的非专业人员。 职场人员一般会用 Excel 处理数据,但也会有很多无助的情况,比如复杂计算、重复计算、自动处理等,再遇上个死机没保存,也常常能把人整得崩溃。如果学会了程序语言,这些问题就都不是事了。那么,该学什么呢? 无数培训机构和网上资料都会告诉我们:Python! Python 代码看起来很简单,只要几行就能解决许多麻烦的 Excel 问题,看起来真不错。 但真是如此吗?作为非专业人员,真能用 Python 来协助我们工作吗? 嘿嘿,只是看上去很美! 事实上,Python 并不合适职场人员,因为它太难了,作为职场非专业人员的你就学不会,甚至,Python 的难度可能会大到让你连 Python 为什么会难到学不会的道理都理解不了的地步。
朱迪
2024-05-16
78
0
写着简单和跑得快是一回事,SQL 为什么不可能跑得快?
高性能计算
高性能计算平台
性能分析
性能优化
sql
我们讨论过代码编写的难和繁的原理问题,现在关注性能问题,运行速度当然是非常重要的事情。 我们知道,软件不能改变硬件的性能,CPU 和硬盘该多快就多快。不过,我们可以设计出低复杂度的算法,也就是计算量更小的算法,计算机执行的动作变少,自然也就会快了。本来要做 1 亿次运算,如果有个好算法能把计算量降低到 100 万次,那快出 100 倍就不奇怪了。但是,光想出算法还不够,还要把这个算法实实在在地用某种程序语言写出来,否则计算机不会执行。 然而,如果采用的程序语言不给力,就有可能真地写不出来,这时候就干瞪眼忍受低速度。
朱迪
2024-05-11
59
0
索引的本质是排序
排序
索引
数据库
hash
索引是经常用到的技术,但有些程序员对索引的原理了解不深,发现数据查询性能有问题立刻想起建索引,当然经常也没啥效果,反而消耗资源。那么到底什么时候该用索引以及该怎么用?我们来分析索引清理背后的技术原理就知道了。 索引技术的初衷是为了快速从一个大数据表中找出某个字段等于确定值(比如按身份证号找出某个人)的记录。一个 N 行的数据表,遍历查找则需要比较 N 次,而如果数据按该字段值(在索引中称为键值)有序,那么就可以用二分法查找,只要比较 logN 次(以 2 为底),比如 10 亿行数据只要比较 30 次(10 亿约是 2^30),这显然能大大提高性能。有时可能还会有键值有重复的情况(按出生日期找人)或按键值区间的查找需求(按出生日期区间找人),比较次数会比 logN 大一些,但基本仍是这个数量级的。 索引的本质就是排序。
朱迪
2024-05-10
84
0
再来谈离散性,Java 比 SQL 又有什么优势?
高性能计算
代码优化
性能优化
java
sql
我们讨论了 SQL 对 Java 的优势,也就是集合化特性,我们现在再来看看 Java 比 SQL 有什么优势。 Java 的代码长是长了,看起来也乱,但仔细研读会发现,它描述的运算逻辑并不困难,基本上就是按部就班地实现业务目标。也就是说,Java 是书写繁琐,而不是思考困难。 但 SQL 却不一样,看懂每一个子查询的技术意义并不难,但你却很难明白它到底想干吗,是怎样为最终的业务目标服务的。也就是说,SQL 写起来要简洁一些,但思维难度却更大了。 这是为什么? 我们之前讲过一期 三行五行的 SQL 只存在于教科书和培训班 ,指出 SQL 有集合化不彻底、缺乏有序支持等问题,这些问题,以及 SQL 还有的其它问题,都有一个共同的根源,这导致虽然 SQL 的繁琐度低于 Java,但难度却更大。
朱迪
2024-05-09
67
0
硬盘的性能特征
性能优化
高性能计算
性能
我们知道内存比硬盘要快得多,大概能快出一两个数量级(当然价钱也贵得多)。不过,硬盘的问题并不只是速度慢。
朱迪
2024-05-08
79
0
从 SQL 和 Java 的对比理解集合化,SQL 到底比 Java 优势在哪?
java
sql
同样的数据计算任务,用 SQL 写和用 Java 写,后者常常会长出数倍。代码长不仅仅是写起来很繁琐,也不利于理解整体业务逻辑结构,算法过程都湮没在细节中。 为什么 Java 会比 SQL 长这么多?我们来回答这个问题,并引出程序语言的集合化概念。
朱迪
2024-05-07
143
0
BI 软件能对付多少数据分析任务?
软件
软件开发
bi
其实没多少! 从早期喊的多维分析到近年来喊敏捷 BI,BI 厂商一直在强调自助能力,宣称可以由业务人员自己随心所欲地分析数据,而用户也常常有强烈的需求,双方一拍即合,很容易形成购买行为。 不过,就大多数缺乏 BI 应用经验的用户所期望的工作内容而言,自助分析的目标就可以说远远达不到!从经验上看,最好情况也就能解决 30% 左右的问题而已,而大多数 BI 产品连这个数也达不到,只能处理 10% 左右的需求。
朱迪
2024-04-30
68
0
我们需要怎样的 OLAP
大数据
数据分析
olap
大数据处理
sql
OLAP 这个词从字面上理解是在线分析的意思,也就是由人员面对数据进行各种交互式的分析操作。 但是,现在的OLAP 概念被 BI 软件给严重狭义化了。面向业务分析时说到 OLAP,在技术上经常就只有多维分析的功能,也就是针对一个事先建设好的数据立方体,按指定维度层次进行汇总并呈现成表格或图形,再辅以钻取、聚合、旋转、切片等操作以变换维度层次及汇总范围。这些大家都很熟悉,就不再细说了。 多维分析就是在线分析的全部吗?
朱迪
2024-04-28
66
0
数据库的 IO 到底有多慢?
大数据
性能优化
数据库
sql
有过多年应用开发经验的同学大都会体验过数据库 IO 比较慢的情况,但到底会慢到什么程度,特别是和其它读写数据的手段相比的差距,可能很多人还没有感性认识。 Java 是普遍采用的应用开发技术,我们来实际测试一下,Java 程序从 Oracle 和 MySQL 这两种典型数据库中读数的性能,并和读文本文件对比。 用国际标准 TPCH 的工具生成数据表,选用其中的 customer 表,3000 万行,8 个字段。生成的原始文本文件有 4.9G。将这些数据导入到 Oracle 和 MySQL 中。 硬件环境是单台 2CPU 共 16 核的服务器,文本文件和数据库都在 SSD 硬盘上。所有测试都在本机完成,没有实质上的网络传输时间。
朱迪
2024-04-25
133
0
ClickHouse 在什么场景下才管用?
数据库
大数据解决方案
clickhouse
ClickHouse 是近年来分析型数据库的热点,一向以快著称,很多其它以性能为卖点的分析型数据库也常常会用它作为一个对比标杆。很多用户碰到数据库运算性能问题时,也会考虑转向求助于 ClickHouse 解决 ClickHouse 确实是有过人之处,它的列式宽表速度很快,估计是压缩做得非常好。然而,除此之外,再无长处。希望用 ClickHouse 解决数据库计算性能问题的用户,大概率会失望的。
朱迪
2024-04-22
123
0
自助关联查询难在哪里
bi
data
join
事物是普遍联系的,很多有业务意义的查询也会涉及多个数据表的关联。 BI 类软件通常会提供自助查询功能,有些软件还能支持关联查询,但实际使用的大多数还是单表的,关联查询功能很少被业务人员使用。涉及到关联表的查询常常需要由技术人员事先准备好,也就是我们常说的宽表。业务人员通常只会基于单一的宽表来做查询。关联查询是几乎所有 BI 类软件的软肋,无论大牌还是新秀,几乎一试一个准,全军覆没。 为什么会这样呢? 因为很多人不会用这些软件提供的多表关联查询功能。
朱迪
2024-04-15
141
0
SQL 的困难源于关系代数
高性能计算
数据库
sql
在结构化数据计算领域,SQL 现在还是应用最广泛的工作语言,不仅被所有关系数据库采用,许多新进的大数据平台也将实现 SQL 作为目标。
朱迪
2024-03-21
200
0
三行五行的 SQL 只存在于教科书和培训班
高性能计算
开源
java
sql
教科书中 SQL 例句通常都很简单易懂,甚至可以当英语来读,这就给人造成 SQL 简单易学的印象。 但实际上,这种三行五行的 SQL 只存在于教科书和培训班,我们在现实业务中写的 SQL 不会论行,而是以 K 计的,一条 SQL 几百行 N 层嵌套,写出 3K5K 是常事,这种 SQL,完全谈不上简单易学,对专业程序员都是恶梦。 以 K 计本身倒不是大问题,需求真地复杂时,也只能写得长,Python/Java 代码可能会更长。但 SQL 的长和其它语言的长不一样,SQL 的长常常会意味着难写难懂,而且这个难写难懂和任务复杂度不成比例。除了一些最简单情况外,稍复杂些的任务,SQL 的难度就会陡增,对程序员的智商要求很高,所以经常用作应聘考题。
朱迪
2024-02-29
235
0
怎样做多数据源的混合计算
sql
早期应用通常只会连接一个数据库,计算也都由数据库完成,基本不存在多数据源混合计算的问题。而现代应用的数据源变得很丰富,同一个应用也可能访问多种数据源,各种 SQL 和 NoSQL 数据库、文本 /XLS、WebService/Restful、Kafka、Hadoop、…。多数据源上的混合计算就是个摆在桌面需要解决的问题了。
朱迪
2023-12-21
113
0
没有更多了
社区活动
RAG七天入门训练营
鹅厂大牛手把手带你上手实战
立即学习
Python精品学习库
代码在线跑,知识轻松学
立即查看
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
立即体验
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
立即查看
领券
问题归档
专栏文章
快讯文章归档
关键词归档
开发者手册归档
开发者手册 Section 归档