
为了将来节省 mysql 压力,现将部分表移到 oss 上,并做 redis 缓存处理, 这会不会有什么问题? 个人觉得有缓存了, 将来数据量大了放 mysql 也不会有压力,但有什么理由拒绝这种建议呢?
1 myd 2021-09-03 09:48:58 +08:00 OSS 好像不支持随机写吧 |
2 py88pQ2hZ7PJw0v4 2021-09-03 09:51:51 +08:00 juicefs 挂载一个硬盘 |
3 Mithril 2021-09-03 09:53:18 +08:00 做过,没什么问题。文件存 OSS,属性挂 metadata 。非常轻量的读写问题不大。 适合以文件操作为主要流程的场景。 |
4 JingKeWu 2021-09-03 09:58:36 +08:00 什么神仙操作 |
5 cheng6563 2021-09-03 10:00:54 +08:00 除非你 100%缓存,否则没缓存的那点数据就能要你老命 |
6 securityCoding 2021-09-03 10:06:30 +08:00 via Android 连野路子都算不上 |
7 lscexpress 2021-09-03 10:10:26 +08:00 请用 oss 来做一次事务让我瞧瞧 |
8 rogwan 2021-09-03 10:25:50 +08:00 via Android 对象存储要计算请求次数费用的,确定 MYSQL 是低频数据 IO |
9 xsm1890 2021-09-03 10:32:14 +08:00 写到 oss 不就是一个文件了。最最开始的时候,数据就是写到磁盘上的,为了方便管理搞了一个数据管理系统,也就是最原始的数据库了,然后这个系统慢慢发展才有了现在的数据库的各种功能。这么一搞直接回到了解放前??? |
10 wellsc 2021-09-03 10:32:34 +08:00 看需求,如果你只是给个人博客用用的话完全可以,毕竟日活大概率不到 10,以前还有人把 github repo 当 kv store 用呢 |
11 F281M6Dh8DXpD1g2 2021-09-03 10:59:11 +08:00 自己搞个 snowflake |
12 zhangxudong 2021-09-03 11:28:11 +08:00 有,然后因为请求量过大,被阿里云警告了 |
13 BBCCBB 2021-09-03 11:32:43 +08:00 你该看看 table storage, 而不是 oss.. |
14 Exdui 2021-09-03 11:39:00 +08:00 试过,高频读 低频写的数据放在 oss,走内网请求数据 这种算是野路子,主要看你是用在什么场景的 |
15 koolob 2021-09-03 11:41:13 +08:00 我这边把 oss 当作一种可批量覆盖数据的只读数据库来用的。 文件形式组织好,然后数据湖建立外表。读取就跟 mysql 一样。而更新数据时,就批量把文件替换就行。 适合大数据原始数据处理。 |
16 ClutchBear 2021-09-03 11:41:25 +08:00 同楼上, 用阿里云的表格存储呗, 价格也不贵. 我测试过, 通过主键读 10000 条数据, 大概 35 秒. |
17 gancl OP @Exdui 暂时先用在自定义字段上, saas 系统不是要设置很多自定义字段给各种行业自己用, 有自定义模板、自定义字段类型、自定义字典列表、关联各业务的中间关联表等 |
18 yrj 2021-09-03 13:43:46 +08:00 via iPad 你确定内存比硬盘更便宜?这不就是钱包负优化嘛 |
19 THESDZ 2021-09-03 15:14:06 +08:00 见过用 cdn 的,商品 sku 这种. |
20 joesonw 2021-09-03 15:31:48 +08:00 https://github.com/phiresky/sql.js-httpvfs 这个就是, 不过是只读的. |
21 tojike 2021-09-03 19:57:22 +08:00 如果是流水表的话完全可以,我们几十亿的流水记录表,跑存储脚本跑了 1 个多月,路径 "uid+date(Ymd).json" 存储到 oss,前端那边只有当天的数据才会查询接口,之前的数据全部先从 oss 里面取,拿不到再拿接口那边的数据。减轻了服务器很多压力 |
22 whileFalse 2021-09-03 20:32:07 +08:00 via iPhone 遇上并发写操作那不是废了吗 |
23 whileFalse 2021-09-03 21:17:43 +08:00 当然 ls 的各种大数据用法是合适的。 |