23333 别玩 pt 了..都是一场梦... .下载点自己喜欢的电影 冷存储下就好了.

实在想玩了.捐个 vip 对大家都好.. 万一日后账号有问题也方便打招呼.

2333 已经习惯了 sql
昨天让同事帮忙写一个 select type ,count(*) from table group by type ..都没人记得了..

clickhouse 去掉 .不是干这个的
其次 时序数据库 了解的不多 .但是 也比较赞同 @joesonw 的说法

es 我觉得有几个问题吧.基于分词,无法保证查询结果 数据难分表. 不分表冷热数据混在一起也有点小问题.


感觉 im 这个场景还是挺大的 ,最好还是和产品一起商量下如何优化 使用体验.

cdc ,
flink cdc
datax 当然也可以 ,不过要做好 时间戳

@wu00
也不大行 ,8 个节点的时候 都不重复的概率大概就是 3% 发布 100 次可能就,期望就是 3 了.

楼上几个 回答是有偏颇的, 如果要做到 服务无感,随时扩容,缩容 ,是需要 一个类似注册中心的 .

我们之前的做法是 固定部署几个实例 ,每个实例的序号就是 机器 id. 当然这也会有问题,

比如项目部署接单会出现 旧的实例没完全下线,新的已经上线了.还有就是无法随时扩容 .

这个其实也是服务治理中的一环了.

过早的优化是万恶之源 ..

简单场景还是别分表了 后期 维护麻烦

最常见到 es 的场景 是作为 elk 日志搜集环境的一环 .
其次 es 的分词查询比较好 ,然后相比较而言 容易扩展 能存储一些海量数据
相比 mysql 随意条件组合 查询能力比较强



我前段时间 也有问过 这个知识 , 我自己综合考虑 ,没有电商属性 es 不是必需品 .其次 也不建议 etl 到 es . 虽然 es 扩展比较容易 .但还是太耗费 内存了.
https://v2ex.com/t/874663

@qW7bo2FbzbC0 这是个好问题 ,初看简单 但是想想还是蛮有趣的.

我觉得主要还是和运行环境有关 , 对于 前端来说需要充分考虑各种浏览器兼容问题 .所以需要 babel 抹平环境的差异.

而对于 后端来说 ,运行时是确定的 并且唯一的

当然现在来说 已经好很多了 , css 前缀, ajax fetch 也都已经统一了 ..

但仍旧 存在部分语法 ,高版本的浏览器 支持 ,低版本的不支持 ,这也就是 babel 的价值

spring 自带的有个 CommonsRequestLoggingFilter
另外好奇下是怎么实现的 ,
ps op 的隐私在 github 项目上有泄露 .
pps 想请教个问题.. op 知道 日志系统是怎么获取 当前日志触发的行数以及 logger 吗?

比如
```
2022-05-29 23:24:40.027 INFO 431055 --- [nio-8080-exec-6] com.manymobi.servlet.http.log.LogFilter : response status=200 time=2ms body={"key":"value"} header={Keep-Alive=timeout=60, Transfer-Encoding=chunked, Connection=keep-alive, Date=Sun, 29 May 2022 15:24:40 GMT, Content-Type=application/json}
```
中就是 `com.manymobi.servlet.http.log.LogFilter ` 这部分 , 感觉 Thread.getAllStackTraces()会有性能问题 ..

最近想做结构化日志 遇到了这个问题.

@czwstc 可以放到其他网站的邀请区域.

2333 竟然在这里 发现了 馒头.. 不过好久不玩 头像已经没有熟悉的了... 现充中..23333

@fuxkcsdn 范围查询无解 是指倒排索引对 范围无解吗..

@shuimugan 感谢回复

周末有空 尝试回放真实请求到两个数据库中. 对比下效果.

@shuimugan 啊哈 ? pg 的 日志解析那么友好吗?


@yangyaofei 可以尝试下 https://debezium.io/ flink cdc 之类的

除了模糊查询外 ,也有很多人提到了 `多字段联合查询` 这一点 . mysql 对这个的支持的确比较差劲 ,pg 会稍微好一些.
针对这种情况的其他解法 ,估计也就是分库分表以及替换成分布式数据库了.


但是国内讨论比较多的不和云服务厂商绑定在一起的原生分布式即时查询数据库除了 es 也就 mongodb 了吧? 不知道 mongodb 的查询效率如何.

另外不知道如果是针对固定的查询条件 , 联合索引能覆盖的时候效率会不会比 es 高一些 ? 以我司为例 , 查询条件是非常不均匀的.

周末有空的话 看看能不能进行一次深度测试..

@victorc no schema 但是 还是有 mapping 需要配置的.
@lovephpframework 这个看具体的查询条件吧.如果是比较好的索引 其他数据库 做起来也不一定会差.
@westoy 这个说起来 倒也算是一个理由 .下面的另一个同学也提到了 es 生态比较好

@shuimugan 和你遇到的场景类似 , 数据量也接近 . 也考虑过 es .但最后还是选择了 pg .主要是 pg 自带分区表 . 使用 es 的话就必须手动维护分区表 , 会麻烦一些 . 你当初有考虑过 分库分表 或者分区表吗?


@yjhatfdu2 是把几个字段一起放到一起 创建一个 gin 联合索引吗 ? 另外如果中间有时间类型,需要范围查找怎么办呢?