COKETSANG 最近的时间轴更新 COKETSANG 最近的时间轴更新 |
COKETSANGV2EX 第 439156 号会员，加入于 2019-09-02 00:54:33 +08:00 |
| 收到一封微软邮箱地址但不是微软发的垃圾邮件，邮箱地址确实是微软的域名 问与答 • COKETSANG • 2024 年 8 月 31 日 • 最后回复来自 yinmin | 13 |
COKETSANG 最近回复了
2024 年 8 月 29 日 回复了 COKETSANG 创建的主题 › 问与答 › 收到一封微软邮箱地址但不是微软发的垃圾邮件，邮箱地址确实是微软的域名 |
@msg7086 随便设个服务器就能冒用别人的邮箱地址？没这么简单吧，不然就全乱套了？邮箱服务器一般都验证了才能发送的吧
2024 年 8 月 29 日 回复了 COKETSANG 创建的主题 › 问与答 › 收到一封微软邮箱地址但不是微软发的垃圾邮件，邮箱地址确实是微软的域名 |
@zk8802 基础的 from 、sender 验证应该有吧？ qq 邮箱也没显示地址转发。qq 邮箱自己的发件我记得是有 dkim 签名的
2023 年 9 月 27 日 回复了 9921 创建的主题 › 程序员 › Apache Doris 现在使用的多吗 效果怎么样啊 |
@9921 而且 ck 压缩比挺高的，就是要管下类型不能像 hive 那样 string 一把梭。但毕竟我们是服务器费用敏感的小公司
2023 年 9 月 27 日 回复了 9921 创建的主题 › 程序员 › Apache Doris 现在使用的多吗 效果怎么样啊 |
@9921 看了下我们现在也有 135 列高频查询的宽表，ck 本身列存对列数不敏感，我们也有数据不多 2000 多列的表，查询单列不多的情况下确实也很快。
ck 简单列聚合确实很牛逼，但是 join 确实不太行。当时选型也是考虑可以减少 join 进入数量解决。我们大概 21 年开始用了，早期版本不支持 2 个以上 join ，多表只能用嵌套 join 也确实恶心。不过我们是自己参考 mongodb 写的小型 orm 解决的也问题不大。
目前整体看暂时没有性能瓶颈所以还是推荐你可以试试。
ck 简单列聚合确实很牛逼，但是 join 确实不太行。当时选型也是考虑可以减少 join 进入数量解决。我们大概 21 年开始用了，早期版本不支持 2 个以上 join ，多表只能用嵌套 join 也确实恶心。不过我们是自己参考 mongodb 写的小型 orm 解决的也问题不大。
目前整体看暂时没有性能瓶颈所以还是推荐你可以试试。
2023 年 9 月 27 日 回复了 9921 创建的主题 › 程序员 › Apache Doris 现在使用的多吗 效果怎么样啊 |
@9921 ck 的话你就默认它没有 update 。需要 insert 代替 update ，搭配 replacing 引擎 final 来读数据就是，跟其他数据库有点点不同。
物化视图也是类似，一般需要搭配 aggregating 引擎用。碰上需要去重的场景就不太适用了。
那挺可惜的，目前我们有两套系统 ck 在用。有一套是单机 32 核 64G ，目前来看不过亿的数据都是随便查的，我安利你看看伴鱼和七猫的团队文档，我觉得学到挺多的。
物化视图也是类似，一般需要搭配 aggregating 引擎用。碰上需要去重的场景就不太适用了。
那挺可惜的，目前我们有两套系统 ck 在用。有一套是单机 32 核 64G ，目前来看不过亿的数据都是随便查的，我安利你看看伴鱼和七猫的团队文档，我觉得学到挺多的。
2023 年 9 月 27 日 回复了 9921 创建的主题 › 程序员 › Apache Doris 现在使用的多吗 效果怎么样啊 |
@9921 理论上 clickhouse 的机器配置不会比 habse 那些要求高啊，我们是用 clickhouse 两台 16 核 64G 的集群，平替了一个 40 台 1000 核 1TB 的集群。
不过我们的数据量不大，5TB 左右。而且 clickhouse 的并发性能确实不行，我们 qps 是不过百的。update 也支持不太行。我们用户画像虽然是 clickhouse 做的，但是是 clickhouse 计算结果，同步到到一个 mysql 去支持业务并发查询的。
不过我们的数据量不大，5TB 左右。而且 clickhouse 的并发性能确实不行，我们 qps 是不过百的。update 也支持不太行。我们用户画像虽然是 clickhouse 做的，但是是 clickhouse 计算结果，同步到到一个 mysql 去支持业务并发查询的。
Select Language