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

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

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

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

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

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

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



我前段时间 也有问过 这个知识 , 我自己综合考虑 ,没有电商属性 es 不是必需品 .其次 也不建议 etl 到 es . 虽然 es 扩展比较容易 .但还是太耗费 内存了.
https://ex.noerr.eu.org/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 联合索引吗 ? 另外如果中间有时间类型,需要范围查找怎么办呢?

233 明明 是讨论 ide 的 怎么成了 java 垃圾 rust 牛逼的 让人捉急...

手动滑稽...坐等 rust 搞个生态链.出来..

虽然我也吐槽 java 一些设计...但就事论事..围绕着 spring 的生态很好...一些问题 有通用的解决方法.

后端维护一份 缓存字典 .
然后自己写一个反射工具类 遍历父类以及本身所有 field ,转换成相应字段..

ps .目前我们的缓存字典实际上用的是 map ,没有 lru 之类的策略 ,有什么缓存推荐的吗?

@TomVista 自己写 又麻烦了,涉及到了 ui 设计..emm 重试,目录选择..多线程设置,速度设置..emmm

@TomVista 服务端如果想实现 批量下载并保存在不同目录 ,就只能使用压缩包的方式了 ,可能有以下问题
1, 用户如果批量下载照片的时候如何实现 避免客户端白屏,等待,查看进度条等操作?
2, 用户批量下载照片时 如何避免服务端 oom
3, 名称重复时,如何处理? 大部分下载软件是能自动重命名的 xxx(1).xx 这种的

ennnn super cell 家的游戏 很容易让别人以为 操作简单的游戏 代码实现起来也很简单..

小厂还是老老实实做回合制 或者益智 或者塔防之类的游戏吧..

@lmmlwen 国内普遍现象...要么是文章牛头不对马尾 .
要么是和你聊 1+1=2
缺少深度 缺少实际场景结合

哈哈哈 ..前后端 势如水火
你说后端菜 ,后端说你娱乐圈 ..
你说后端 null 全字段 ,后端说你 不会用 GraphQL ...

老老实实搬砖吧... 不要把公司的压迫 转移成了 前后端的撕逼 ....