虽然自己对数据库并没有深入了解,但看到帖子 “一个非常复杂的需求,如何设计表结构” ,感觉数据库还是挺有意思的。想聊聊自己的思考,抛砖引玉。
上面这个帖子,提到的问题是比较经典的树状节点的查找、修改。从中可以明显地感受到操作“内存对象”和操作“关系型数据库数据”的差异——内存中,对象之间可以互相指向,像是修改子节点结构、查找子节点,这些操作都可以很直接,顺着节点的指向,可以很自然很快地完成想要的操作,数据的一致性也很容易保证。而关系型数据库存储则只能通过“查表”这种间接方式,远远没有操作内存对象那样直接快速,还要考虑各个表中的数据一致性。
虽然看起来内存对象和数据库数据的形式差异太大了,但追根溯源,最根本的差异可能就只有一个:
可以想象一下,在上面的帖子中,如果将内存对象节点树,照搬到关系型数据库中,表结构应该是这样的:
id, parent_id, children_ids
上面的表结构,在内存对象与数据库记录之间建立了一种对应。对内存对象的操作,可以简单的映射到对数据库记录的操作,只不过复杂度倍增了 O(lgT)。
例如对于查找某个节点的所有子节点这个操作,
但 O(N)*O(lgT)的时间复杂度应该是可以优化的。这引出了一个问题,怎么通过改进表结构,来优化数据库的性能呢,而这种优化有没有规律可循呢?
1
darksword21 2021-03-31 17:50:45 +08:00
一楼蹲,一楼蹲完了
|
2
Hieast 2021-03-31 17:50:57 +08:00
可以了解一下图数据库
|
3
nulIptr 2021-03-31 18:21:50 +08:00
思考问题的时候一定要考虑场景
古时候内存没那么大,硬盘访问速度也很慢。现在看起来没那么大的数据量那时候处理起来也比较麻烦。 抛开物理机性能不谈关系型数据库还要有 acid 特性。 大学里教数据结构的老师一般都会说一句,自己实现是数据结构比 stl 快很正常,因为 stl 要处理各种情况以适应各种各样的场景,而你只需要处理你这块的问题。 我敢说任何键值型数据库查询速度都不如各种语言内置的 Map 结构。那又如何呢,这俩根本不是一个等级的东西啊。你正文举例的内存对象和数据库怎么比?关系型数据库查询最终不也是落在数据结构的查询上面? |
4
xupefei 2021-03-31 18:29:14 +08:00 via iPhone 1
看了几遍没看懂在说啥…我觉得楼主把数据库索引和真正的数据搞混了
|
5
tabris17 2021-03-31 18:30:58 +08:00 via iPhone
没错对象持久化储存不一定要用到关系数据库
|
6
auxox 2021-03-31 19:04:05 +08:00
所以文档数据库不能解决这个问题吗。
|
7
hxndg 2021-03-31 22:56:20 +08:00
?????????坦白说我没看懂你在说啥?
你再说索引?还是文档模型和关系模型?抑或说图数据库? 而且表的结构和索引也不是必然联系? 而且内存对象可以随机访问,关系数据库不能随机访问这个事情(你说的该是硬盘吧,关系数据库不是完全不能随机访问的) 建议先看看《数据密集型系统设计》前三章? |
8
sillydaddy OP |
9
hxndg 2021-04-01 13:54:51 +08:00
@sillydaddy
首先,数据结构和关系型数据库没有必然联系, 其次,关系型数据库是可以放一部分在内存里的, 你需要区分开抽象层面和实现层面,不要混为一谈,先找点资料查询一下, 最后,内存里面就随机访问?你说的是什么,是 hash 吧. 你再看看 SSTables ? 有序性的思考应该集中在数据结构层面,而不是上层抽象上。 |