V2EX › heiya 的所有回复 › 第 2 页 / 共 7 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7

❮

❯

4 天前

回复了 heiya 创建的主题 › 程序员 › 对搭建 MinIO 对象存储的一些疑问

@CHS 你的逻辑十分混乱。首先我从未说过不喜欢别人的回复，请看一下他回复的内容。社区指导规则中明确指出：友好互助，保持对陌生人的友善。用知识去帮助别人。他的回答既看不出友善，更谈不上帮助，短短两行充斥着不屑。就这种严重背离社区原则的回答你竟然还帮着说话，足见你没什么正确的价值观。其次，“你自己都说了瓶颈是带宽，那用 Nginx 集群又有什么用？” 这句话感觉你基本没理解我的疑惑在哪，这很可能是我的语言表达能力有问题，不怪你。

4 天前

回复了 heiya 创建的主题 › 程序员 › 对搭建 MinIO 对象存储的一些疑问

@sujin190 嗯嗯，在背景中的第三条中说明了是外网带宽是瓶颈。实际上目前是 OSS+MinIO 都使用了，OSS 中存储的一些热点资源、静态文件、小文件等，MinIO 存了一些大文件，比如动辄就几百 M ，一个 G 多。这么用的原因是当时我看到 OSS 忙时外网流出收费的价格是 0.50 元/GB ，比 ECS 的流量费贵。

4 天前

回复了 heiya 创建的主题 › 程序员 › 对搭建 MinIO 对象存储的一些疑问

@hefish 我觉得你要不想赐教可以不答，一味的反问衬托自己有多么精通只显得你素质低下。在这种社区有你这样的回答真是拉低档次。话都不会好好说吗？我图啥？我图明天多吃俩馍！

32 天前

回复了 metavacuum 创建的主题 › 生活 › 你们眼中的春天是什么时候开始，什么时候结束？

@jun771480011 我现在秋天还得来一次，美滋滋

33 天前

回复了 metavacuum 创建的主题 › 生活 › 你们眼中的春天是什么时候开始，什么时候结束？

以开始打喷嚏为开始，以结束打喷嚏为结束

34 天前

回复了 Joker123456789 创建的主题 › Java › 微服务是不是一种错误的方向？

我浅显的理解是项目流量高且必须满足项目大、复杂这两个条件才可以上微服务，其余不用。

45 天前

回复了 happydayandnight 创建的主题 › 生活 › 想问下大家每个月给女朋友多少生活费

你有点毛病

80 天前

回复了 irisdev 创建的主题 › 数据库 › 关于分库分表的一点疑惑

1.分库分表是有一些中间件能做的，按照现有数据及未来规划把已有的一张大表均匀的分散到一些实际小表上（比如按照 id 取模分成 32 、64 、1024 张物理表），查询时只需要查逻辑表就可以了。
2.分表之后可能会有效率问题，这取决于你的业务。有些查询很复杂，速度比较慢，流量一上来就会噶。这时候需要其他数据库对查询进行辅助，不走分表的数据。

87 天前

回复了 heiya 创建的主题 › 北京 › 北京的朋友们，最近怎么回事？又开始刀片嗓了。

@ruuu 我不发烧的，就是嗓子痛流鼻涕

87 天前

回复了 heiya 创建的主题 › 北京 › 北京的朋友们，最近怎么回事？又开始刀片嗓了。

@KimGuo 发烧太难受了，整个人都是懵逼状态。话说还是北京厉害，甲流 500 万，新冠 100 万。

87 天前

回复了 heiya 创建的主题 › 北京 › 北京的朋友们，最近怎么回事？又开始刀片嗓了。

@HappyFox 感谢建议，症状再持续就去医院了。

87 天前

回复了 heiya 创建的主题 › 北京 › 北京的朋友们，最近怎么回事？又开始刀片嗓了。

@irever 听说最近又是一波

87 天前

回复了 heiya 创建的主题 › 北京 › 北京的朋友们，最近怎么回事？又开始刀片嗓了。

@showonder 是的，药我先停了，这次不对劲。症状再持续就去医院检查。

87 天前

回复了 heiya 创建的主题 › 北京 › 北京的朋友们，最近怎么回事？又开始刀片嗓了。

@clhlc 嗯嗯，我吃着感觉不对劲就停药了，症状再持续就去医院了。

102 天前

回复了 seedhk 创建的主题 › 程序员 › 关于数据库容灾缓存方案的咨询

@seedhk
1.数据修改只能是通过待更新标记再重新同步。
2.但假如你使用 OLAP 数据库，比如 ClickHouse ，就像我之前说过的要注意是否有时不时的数据更新操作，如果有则不推荐。因为更新操作会引起索引重建，严重影响性能。非要更新的话也得是批量更新，数据更新及时性会受影响。我们之前的业务比如广告埋点，发送短信等这些数据插入/查询的业务每天几个亿数据，做数据分析连表查询性能很高，美滋滋。

102 天前

回复了 seedhk 创建的主题 › 程序员 › 关于数据库容灾缓存方案的咨询

@adoal 别盯着笔误挑毛病，我写成 abc 他那不还是不行？最烦你这种人，啥方案提供不了就知道挑别人毛病。你觉得你行就给人家一个方案，觉得我说的方案不行就指出哪里不行。逼逼赖赖显你有嘴了。

102 天前

回复了 seedhk 创建的主题 › 程序员 › 关于数据库容灾缓存方案的咨询

@seedhk

1.这个需要你们去分析。可以将关联查询出来的数据结果集作为一个大宽表同步到 ES 的索引中，这个大宽表可能有很多字段；也可以在后端业务逻辑中将需要的条件提前准备好了直接传递给 ES （如果被 jion 的表查询很快的话）；还有一种是 ES 的索引间关联查询也可以。
2.有一个数据同步中间件 datax ，可以将 Mysql 的表数据同步到各种其他数据库。
4.我感觉是哪个工作量相对小就将哪一个迁出，目标就是避免影响到核心业务。
10.还有一种查询是各种聚合查询，针对于各种大数据量下的 count 语句，那 ClickHouse 特别合适，不过使用他是有条件的，只有写入和查询的话可以使用。
11.前端页面上点击查询一时半会返回不了就不要再发送相同请求了

整体上我感觉就是现在的 Mysql 满足不了复杂的查询业务，把整个服务拖垮了，并发量其实并不高。最要紧的是把 1 和 4 搞定，其他的 6,11 同步做。不过，这么一搞就把技术复杂度提上去了，新增了 ES 和消息。

103 天前

回复了 victimsss 创建的主题 › 程序员 › 请教一下关于激活（授权）的方案

@YiXinCoding 感谢🙏 豁然开朗

103 天前

回复了 seedhk 创建的主题 › 程序员 › 关于数据库容灾缓存方案的咨询

SQL 太复杂，一查几百行，表数据量又太大导致大量的慢 sql ，是不是瓶颈在于查询而不是新增和修改？这样的话我感觉用 Redis 替代 Mysql 查询不合适，原因是即使前台没有显式的调用这些复杂 sql ，在相关业务进行新增和修改时也调用复杂 sql 同步到 Redis ；如果说不调用 sql 直接将数据存到 Redis ，那能不能确定由复杂 sql 组成的数据可以通过简单的 Redis 命令重新组成，我感觉挺困难的；还有数据量太多的话假设 Redis 挂掉，AOF 恢复是需要时间的，在这段时间内服务不可用；综上，我感觉 Redis 不合适。解决办法根据描述我感觉：1.针对那些很复杂、数据量又特别多导致慢 sql 的表，将这数据同步到 ES 的一个索引中，组成一个大宽表，所有有关的复杂查询全走 ES 2.每次新增或修改时使用消息队列同步到 ES ，不能直接同步（或者现在有一些同步组件可以用） 3.如果有很多复杂查询但彼此不相关就需要多个索引了 4. 如果条件允许的话针对这些复杂的查询单独拆出来组成查询服务 5.分库分表还是有必要搞的，不过根据我的经验用过 Sharding 和 Mycat ，复杂的 sql 还是歇菜 6. 优化还得继续，慢 sql 报警不知道有没有 7.业务上能不能限制一下查询条件，比如起始时间什么的 8.有没有数据冷热分离的可能性？ 9.据说 PG 很强，但我没有用过，得试试

1 2 3 4 5 6 7

❮

❯