转载一个知乎关于网站系统架构的帖子: 关于数据库该不该使用外健
https://www.zhihu.com/question/19600081/answer/94706401#comment-400660207mark一下,以防原答主删帖,侵权私信我Q 大家设计数据库时使用外键吗?@林灿斌 的回答我简单地画了一个最常见的中型网络服务的架构示意图:用户的请求,通过前端的负载均衡分发到应用服务器上,应用服务器对于数据的请求,又通过数据的负载...
https://www.zhihu.com/question/19600081/answer/94706401#comment-400660207
mark一下,以防原答主删帖,侵权私信我
Q 大家设计数据库时使用外键吗?
@林灿斌 的回答
我简单地画了一个最常见的中型网络服务的架构示意图:
用户的请求,通过前端的负载均衡分发到应用服务器上,应用服务器对于数据的请求,又通过数据的负载均衡分发的读写分离的数据库集群上(读写分离的从数据库通过二进制日志从主服务器同步数据)。
这种架构,对于系统开发的复杂度不会有什么明显的提升。
但是很容易可以注意到,这个架构下,负责写的数据库服务器,只有一个。如果用绿色圆饼代表服务器负载的话,加入约束的主服务器,insert、update、delete操作都会有更多的性能消耗。于是负责写入的主数据库服务器会很快遇到瓶颈。
根据木桶理论,我们可以知道,这个系统也遇到了瓶颈。
那么把负载最高的服务器上的干的活,转移到易于扩展的其他服务器上,可以有效提升整个系统的性能。
那么把 主数据库服务器(写) 上的约束转移到应用服务器上去做,就可以有效提升性能了——极端点的能转移就全部转移。
还有为了压榨 主数据库服务器(写) 上的一些性能,用GUID替代AutoIncrement作为主键的唯一性保障,同样也是这个道理。
这么做之后,我们可以观察到 主数据库服务器(写) 上的负载有了显著的降低,但是应用服务器的负载提升了,这时候怎么办呢?只要再加几台应用服务器就好了。
最后,再分享另一种的网络服务的系统架构:
这种情况下,把约束做到数据库里,就很方便了,降低了应用服务上逻辑层的复杂度。(有人要问了:为什么负载这么低啊?因为用户量少啊hhhhhhhhhh)
总之,加不加,还是看需求。
但是我个人倾向于把对性能的需求,放到易于扩展服务器迅速解决性能瓶颈的服务中。
更多推荐
所有评论(0)