Haskell

Haskell 中文群

u-egi 1 week ago
我刚才已经基本上把思路讲了。这只是其中的一种做法,不是唯一的。
u-fbifacefhad 1 week ago
1. 在 PG 里建三张表,按分钟,按小时,按天各一张,结构一样,做一个所有纬度的复合主键。 2. 写一组流式处理器,直接消费kafka上的数据,每次取1000个,按所有纬度+时间 group by 3 次,分别写入3张表。 3. 查询: select ts, xxx, xxx, xxx, sum(展示数), sum(点击数) from 分钟表 groub by 1, 2, 3, 4 order by 1,2,3,4.
u-fbifacefhad 1 week ago
感觉做不到任意group by哦
u-fbifacefhad 1 week ago
任意维度
u-egi 1 week ago
直接写 SQL group by 就行了。
u-egi 1 week ago
写成 reporting service API 的话,Haskell 来写可能有些优势。
u-fbifacefhad 1 week ago
按分钟这个表会很大吧
u-fbifacefhad 1 week ago
那统计也有可能很慢啊
u-egi 1 week ago
这个表要按天分区,否则会爆炸。
u-egi 1 week ago
每天在几千万行的话,查一天以内的分钟纬度还是挺快的,一般在秒级。
u-fbifacefhad 1 week ago
那我觉得两年没有人回答上来,就要问问你们HR都是找什么人来面试了
u-egi 1 week ago
也不是什么大公司,不怪他们。
u-hebadiifibcefhj 1 week ago
你的表是实时出还是每天晚上出?
u-egi 1 week ago
准实时。最多延迟几秒。
u-fbifacefhad 1 week ago
跑完一批存进去
u-hebadiifibcefhj 1 week ago
简单的场景,是不是流式处理最高效?存数据库再利用,尤其是groupby不高效
u-jjghifhf 1 week ago
@凤凰木 你那种方法可以考虑把pg换成时序数据库,influxdb之类的
u-ej 1 week ago
PG的pipelinedb timescaledb插件都可以做continuous aggregation
u-jjghifhf 1 week ago
不知道pg对实时计算求导,然后计算环比,同比,差分之类的支持怎么样。
u-ej 1 week ago
先按时间段聚合,查询的时候再多算一下就可以了?
u-cbj 1 week ago
锁进不能这样写???
u-facafichciiiheihbb 1 week ago
为啥不行?
u-cbj 1 week ago
不知道 一直给我报错..
u-facafichciiiheihbb 1 week ago
data是关键字
u-cbj 1 week ago
[emoji] ..嗯 头脑不行了
u-jbefhaabe 1 week ago
你需要一个语法高亮
u-cbj 1 week ago
是高亮的 只是data高亮的不明显
u-cbj 1 week ago
data和 value 颜色不一样 ~~
u-hcfcahhi 1 week ago
vlaue?
u-cbj 1 week ago
拼写错误
u-cbj 1 week ago
@#(fnil % ::larluo) 我应该怎么约束一个类型变量 是可以被 CS的呢?
u-cbj 1 week ago
instance ConvertibleStrings a b => QueryV [(b,b)] where
u-facafichciiiheihbb 1 week ago
不是有convertible a b的typeclasss?
u-cbj 1 week ago
感觉怪怪得 俩变量 我a都不用
u-facafichciiiheihbb 1 week ago
习惯了MonadBaseControl就好了
u-gffba 1 week ago
@#(fnil % ::larluo) @Yanick 宝贝我刚看了下,pravega的人弄了个zookeeper-operator,仔细读过之后我发现zookeeper提供了reconfig方法发现新的node
u-facafichciiiheihbb 1 week ago
每次有了event,还要再去读,太麻烦了
u-facafichciiiheihbb 1 week ago
感觉这个设计有点反人类
u-jhafjh 1 week ago
Operator我去喵一下
u-facafichciiiheihbb 1 week ago
主要是源码不好读,不喜欢。其实一般够用了。我喜欢读源码
u-gffba 1 week ago
@#(fnil % ::larluo) 好,我也是觉得源码不好读才拉了个committer一起做重构的
u-facafichciiiheihbb 1 week ago
[emoji]霸气
u-egi 1 week ago
@黄毅[emoji] continuous aggregation 不能用在低延迟要求的场景。
u-egi 1 week ago
TimescaleDB 会比 PG 直接分区表的做法快一些,但不会有特别明显的性能优势。
u-egi 1 week ago
Perl 兄昨晚说的做法,在这个场景下,如果能满足要求,实质上等同于实现了一遍 PG, MySQL 的存储引擎或 leveldb, rocksdb. 按照昨晚的说法,要做到足以干翻它们。
u-facafichciiiheihbb 1 week ago
你要简单,一个kafka streams + kafka connect就搞定了。。。 或者 更简单一点,加个KAFKA SQL,就是要搭 个集群。。。。
u-facafichciiiheihbb 1 week ago
kafka stream本身就是在rocksdb, 然后 kafka connect随意同步结果到任意数据库,还可以通过REST管理 。实时查看异常 情况。