Fancy的技术博客 Fancy的技术博客
Tags Archives Links
  • 开始使用
  • Tags
  • Archives
  • Links
  • Search
  • RSS
开客目标 分享工作心得 分享新发现的技术信息 有困扰你的技术问题需要解答 技术分享资料 技术培训资料 ... 如何注册 木有注册,请使用OA账号登录哦 登录后才可以评论哦 谁能投稿 所有同学都可投稿 投稿方式: 自由写文章和发布 呼朋唤友给你评论 投稿收益 每月评选【最佳技术大拿奖】 发送成就小礼品
置顶!

Fancy最靓技术博客上线啦!!!

公告
如果说前面关于网络的分享只是开胃菜,那么这一篇绝对是重头戏,相信我,网络绝对是值得我们花时间学习的一块内容!

与容器相关的那些事——Kubernetes网络篇

容器
骚年,不要再神话Docker了,相信我,真的没什么高不可攀的技术!

与容器相关的那些事——底层原理探秘

容器
如何辨别某人是Kubernetes高手还是水货,就问懂不懂Kubernetes的资源抢占和持久化!

与容器相关的那些事——Kubernetes资源抢占和持久化

容器
提到垃圾回收,估计很多同学会认为是Java的专属,其实不然,例如运行JavaScript的V8虚拟机、Lua、Python和Go等都采用了自动内存管理技术,所以垃圾回收绝对是一个有逼格的话题!

垃圾回收逻辑推演

GC
为什么很多同学不愿意看Kubernetes官方文档?其实很好理解,试想一下有多少人会兴致勃勃地背一本《英汉词典》,说白了字典或者官方文档仅能提供枯燥的知识,大概率没有任何逻辑。。。

与容器相关的那些事——Kubernetes带你飞

容器
容器是一个很好的技术窗口,可以帮助我们更好地学习和掌握很多底层技术,绝不是什么所谓的“内卷”,就问你怕不怕摸着黑写代码!?

与容器相关的那些事(二)

容器
提到性能分析估计很多同学会一脸懵,如果再扯上Flink和容器,那么估计会劝退更多的同学,但是这些真的没有我们想象中那么高深莫测!

与容器相关的那些事——Flink性能优化案例

容器
MySQL默认的事务隔离级别是RR,这个隔离级别引入了间隙锁和临键锁,解决了不可重复读和幻读问题,但这两把锁让很多CRUD攻城狮理解不了风马牛不相及的SQL为什么会被锁住。所以,骚年,一定不要错过这篇能够带你飞的分享!

MySQL加锁分析专题

MySQL
性能怎么定义?平均负载高是什么意思?IOWAIT高就一定说明IO有问题吗?

“性能”漫谈

性能
很多CRUD攻城狮都知道,在MySQL中使用隐式类型转换会导致索引失效,但你有没有好奇这是为什么啊,真的是因为MySQL的开发是脑残吗?相信我,这篇文章会带你看到时光背面真实的MySQL!

MySQL查询优化探秘

MySQL
期待已久的ShardingSphere终于发布5.0.0正式版了,经过两周的深度研究和使用,惊喜之余还是有一些槽点想分享给大家!

简陋却不简单的ShardingSphere

分库分表
在ClickHouse中可以使用MySQL引擎查询MySQL表,但是ClickHouse为什么不下推LIMIT给MySQL呢?读完这篇分库分表的博文或许能帮助你找到答案!

分库分表理论篇

分库分表
想学Presto吗?你以为会写SQL就足够了吗?同学,天真是可以的,但是不要幼稚无知,好好看看这篇博文吧,说不定会让你发现新世界!

你可能真的不懂Presto

Presto
Apache Flink 是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架。本篇博文可以带你快速入门如此【流批一体】的框架,就问你惊不惊喜、意不意外吧

Flink 入门篇

Flink
如果你对“不忠”有误解,不好意思,我帮不了你,但是如果你对NULL和IN有误解,这篇博文也许能够为你拨开云雾!

你可能不够了解的NULL和IN

MySQL
热身 在开始之前,请先看下以下四条SQL,请问它们的数据逻辑是一样的吗,或者说它们的结果必然一样的吗?(这里不考虑SQL的效率,优化) -- SQL1 select a.k1, a.v1, b.k2, b.v2 from A a left join B b on a.k1=b.k2 and b.status = 0 where a.status = 0 -- SQL2 select a.k1, a.v1, b.k2, b.v2 from A a left join B b on a.k1 = b.k2 where a.status = 0 and b.status = 0 -- SQL3 select a.k1, a.v1, b.k2, b.v2 from A a left join ( select k2, v2 from B where status = 0 ) b on a.k1 = b.k2 where a.status = 0 -- SQL4 select a.k1, a.v1, b.k2, b.v2 from ( select k1, v1 from A where sta....

JoinOnConstant(常数)的逻辑拾遗

MySQL
问题:测试一个新素材的效果(点击率)时,需要跑多少CPM才合适呢,或者多少CPM就能比较精准测出其效果(点击率)? 直观上来看,当然是测的越多就越精准,但成本有限的,所以必须在成本与精度之间做一个权衡,那么如何权衡呢? 假如预算很少,跑出来的结果可信吗? 或者预算比较多时,是否可以节省预算呢? 或无明显预算限制时,该如何抉择? 再把问题拓展下,假如是做一次AB测试,那么此时的对比是有效的吗,能说明AB两个实验的点击率是有明显区别的吗 上述问题实际可以归结到统计学中的以抽样的占比反推整体占比的一个统计推断问题,前提是每次抽样都是真随机的,那么假设测试的曝光数为n,点击率为p, 那么可算出一个标准误差值 stderr=sqrt(p*(1-p)/n),那么整体的CTR 有68%的可能性是落在[p-1*stderr, p+1*stderr]这个范围内 有95%的可能性是落在[p-2*stderr, p+2*stderr]这个范围内 有99%的可能性是落在[p-3*stderr, p+3*stderr]这个范围内 基于上述理论,我们就可以比较精准的回答上述问题了 根据测试的曝光数及CT....

精准评估点击率需要多少个CPM呢

数据分析
ClickHouse的JOIN, LEFT JOIN, RIGHT JOIN, FULL JOIN都是不支持在ON中都只支持等式判定,无法支持不等式判定。因此提供了一个叫ASOF JOIN的功能,其支持在ON写不等式,但依旧有以下限定 只支持一个不等式,即 N 个等式 + 1个不等式的写法。 不等式的触发逻辑是最近匹配(closest match condition),具体含义见如下栗子

ClickHouse的ASOF JOIN功能的使用探索

ClickHouse
总结如下 同一层级不允许使用两个及两个以上的(非LEFT/INNER)JOIN,除非所有都是LEFT JOIN/INNER JOIN。 ClickHouse会把同一层多个JOIN的语句重构成多层,每一次只会有一个JOIN。常规情况下数据表都会在第一个,在此前提下只要出现至少一个 RIGHT JOIN、FULL JOIN,那么WHERE条件就不会下推导第一层JOIN,从而会出现数据表被全表做JOIN的情况,从而使性能急剧下降。 不推荐通过对数据表单独封装子查询的方案原因为,在维度表用的是local表时,此方案会造成数据不准,具体详见CH查询逻辑

ClickHouse多个同层JOIN的使用优化

ClickHouse
1 2
RSS 开始使用
记录精彩的程序人生

Open Source, Open Mind,
Open Sight, Open Future!
32 文章
0 浏览     0 当前访客
© 2025 Fancy的技术博客

Copyright©FancyDigital.All Rights reserved.