请问像记账软件，背单词软件这种一个用户可能有独属于它的一大块数据的数据库该采用什么比较好？

[Newyorkcity]

以背单词软件为例，如果是在传统的关系型数据库比如 MySQL 里，一个名为 notes 表存储用户的笔记，那这个表里有一个 user_id 字段，并以这个字段建立 BTree 索引的话吧？尽管这里使用了 BTree 索引，性能上还是会有不必要的开销？

那关系型数据库能不能干脆为每个用户建立一个表？表名是 notes_${user_id} ，相当于一个用户的所有笔记单独成一个文件这样去管理。。

应该是有专门针对这种特征的数据存储的数据库的吧？谢谢指点。

[Light3]

亲 都 2021 年了 你不知道 非关系型数据库吗

[Newyorkcity]

@Light3 亲 你用 redis 来实现我这个需求看看？

[Light3]

关于用户数据 完全可以使用 MongoDB 然后将用户记录组装成一个 json 格式来存储
用户登录时 将 json 取出 存放于 Redis 来加快操作 操作完 事实更新 并同步存储
至于你所嘲讽的 用 redis 做一个 请问 json 你不会写吗? 还是?

[Kilerd]

分库分表，常规配置了。如果就这么做的话，就叫 Paas 平台了，俗称分租户。

[loginbygoogle]

过度设计

[Newyorkcity]

@Light3 换到记账软件一个用户可能产生近千条条目你也用 redis 里的哈希表？亲 都 2021 年了 会有人不知道非关系型数据库？

[supermoonie]

当时做记账的时候用的 hbase

[ch2]

放到一个表里是没问题的，底层索引一个用户的数据都是放一块的
你没有必要逻辑上自行做这种事

[3dwelcome]

楼主你也太小看 B 树索引后的查找速度了，一个用户几千条毛毛雨，绝不可能翻车的。

[yeqizhang]

结合 8 楼的，我感觉如果用户数也不是那么多的话，可以给用户编号 1...1000000，使用一张表来维护然后每 5w 用户对应用一张表是否可行？
另外，网上看到的笔记这种数据，应该存文档型数据库比较好。

[des]

我实在没搞懂你的纠结点在哪里
btree 索引耗性能？你这个表也到不了一天千万的写入吧？
再有存一千条 hash 到 redis，又不是什么大问题，存用户 id 到 note id 的映射就完了

[Newyorkcity]

@des 对 MySQL 的性能了解不深所以有所担忧