1
Light3 2021-05-12 17:05:06 +08:00
亲 都 2021 年了 你不知道 非关系型数据库吗
|
2
Newyorkcity OP @Light3 亲 你用 redis 来实现我这个需求看看?
|
3
Light3 2021-05-12 17:37:14 +08:00
关于用户数据 完全可以使用 MongoDB 然后将用户记录组装成一个 json 格式来存储
用户登录时 将 json 取出 存放于 Redis 来加快操作 操作完 事实更新 并同步存储 至于你所嘲讽的 用 redis 做一个 请问 json 你不会写吗? 还是? |
4
Kilerd 2021-05-12 17:57:40 +08:00 1
分库分表,常规配置了。如果就这么做的话,就叫 Paas 平台了,俗称分租户。
|
5
loginbygoogle 2021-05-12 18:12:08 +08:00 2
过度设计
|
6
Newyorkcity OP @Light3 换到记账软件一个用户可能产生近千条条目你也用 redis 里的哈希表?亲 都 2021 年了 会有人不知道非关系型数据库?
|
7
supermoonie 2021-05-12 18:39:50 +08:00 via iPhone 1
当时做记账的时候用的 hbase
|
8
ch2 2021-05-12 18:42:58 +08:00 1
放到一个表里是没问题的,底层索引一个用户的数据都是放一块的
你没有必要逻辑上自行做这种事 |
9
3dwelcome 2021-05-12 20:25:15 +08:00 1
楼主你也太小看 B 树索引后的查找速度了,一个用户几千条毛毛雨,绝不可能翻车的。
|
10
yeqizhang 2021-05-12 21:55:19 +08:00 via Android
结合 8 楼的,我感觉如果用户数也不是那么多的话,可以给用户编号 1...1000000,使用一张表来维护然后每 5w 用户对应用一张表是否可行?
另外,网上看到的笔记这种数据,应该存文档型数据库比较好。 |
11
des 2021-05-12 22:10:34 +08:00 via iPhone
我实在没搞懂你的纠结点在哪里
btree 索引耗性能?你这个表也到不了一天千万的写入吧? 再有存一千条 hash 到 redis,又不是什么大问题,存用户 id 到 note id 的映射就完了 |
12
Newyorkcity OP @des 对 MySQL 的性能了解不深所以有所担忧
|