N 年前也遇到了和楼主同样的情况,数据量不大. 但是 join 之后就的体积就大了.同样也是查询条件分散在不同的表上.
我当时的做法是用 debezium 重新聚合到另外一张表上 .并适当的做 水平&垂直分表, 一个完整的 etl 流程

https://juejin.cn/post/7207410405786484796
https://juejin.cn/post/7323570678690185242

ps 楼上不少同学对复杂查询的经验不太足, 可能是比较幸运的程序员没有接受过复杂 erp 中各种逆天的 sql
1) 推荐 es 的: 虽然 es 是查询引擎 但 es 的查询侧重的并不是点对点查询 ,op 的问题主要在于 join 后的笛卡尔积太大.
2) 分开查询在 join: 如果你的所有条件都在一张表上是没问题的.如果是多张表那肯定还是数据库直接写 join 吧

同时 @yiyufxst 的经验非常好 数仓其实主要优化的还是复杂查询 ,在内存充足的情况下能保证结果尽量能出来.
@jjx 的提到的 hana 的确可以搞一搞..但是就是价格也不菲.

我感觉几条可行的解决方案是 :

1) 自己写一套 etl 流程.制作宽表
2) 不写 etl 了, 直接全量 all in 到关系型数仓中 ,在关系型数仓中进行查询 (不过数仓也很耗费资源 .并且如果将来数据量大,同样也是会查询失败)
3) 内存之类的数据库 ( 这个我没试过 ,听介绍有可能可以.

你这哪里是 nas 的配置啊.找个板油一体的低压呗

@yjxjn 商业保障+ 数据库性能保障.. 开源数据库性能被商业数据库按到地上摩擦


我自己是 jdk17+ pg13 以上.. 国内云看着对 pg 很熟.. 结果一个个 pg 的版本都老掉牙. 差价也没几个.

200w 的杭州 应该算是比较差的板块了吧..
这种地方就别买了.

其实这个问题的回答已经列举了双方的不同

一个是剑走偏锋的计算机大学
一个是比较均衡的 985 大学

所以取决于你是想把专业当成一个兴趣爱好，还是仅仅一个吃饭的工具。

@mythabc 说的不错。你能离开互联网生态吗？

15l 列举的比较相信.. 变更工具太多了.

哈哈 想到了一个 比较蠢的办法.. 需要查的时候临时在 mapper 那边 override 一个插入方法..
然后看下这个方法调用情况.

@Unlikely 氦气 好像是为了数据稳定性吧... 这种一般是有些追求资料稳定性的万家了.
并且真说起来 全闪比氦气贵多了.

ps 3K 组 nas 我实在没看出来穷在哪里了....

一种精心设计的丑...

提个建议给 OP ..如果真的管控不了那么多元素 ..就尽量把元素简单话..

这一点可以参考阮一峰的博客

@syubo2810 纸上谈兵了吧..... intel 标 N100 的 tdp 标的很没有节操.
同样是 6W TDP j3160 基本上不需要散热器 .N100 的没有一个敢被动散热的..你猜猜为什么?

nodejs 比.net 好一些..
java 的 spring 比 nodejs 生态又好一些...

嘲讽一波 ...
楼上大部分上来就让楼主换数据库的 对数据库 对大数据 完全是一点都不了解..

建议 op 好好了解下瓶颈在哪里 .表设计表结构是不是有问题.. 查询方式是不是有问题.

这些才是问题的解决思路, 而不是上来就换个数据库 ..

你可能需要的并不是定时同步..

https://zhuanlan.zhihu.com/p/390888081

巧了,此时此刻我也正在做一个字符串处理工具的 V2 版本 ,其中就包含了 json 预览

之前也找过几乎所有的 json 预览库

上文提到的 jsoncrack 和 jsonhero 我都用过.是我用过比较不错的三方库
https://www.jsont.run/ 倒是第一次见.感觉像是基于 jsonhero 做的二开

不过我做的是工具比你功能更强一些 . 大部分是基于我日常使用的痛点找的解决方案

https://imgur.com/NZvdkbH