网站平台架构演变史 - 数据库表的查询优化

Posted 风间影月の技术小站

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了网站平台架构演变史 - 数据库表的查询优化相关的知识,希望对你有一定的参考价值。

上篇说道了数据库读写分离,对于大型网站来说这么说是十分有必要的。数据库在整个互联网架构中担当的角色无法有两个,存储和运算,很多时候这两个是并存的,但是在后期,对于上亿条数据来说,让数据库既要存储,又要运算,那么是这是不可行的,为了保证性能,我们仅仅只需要最大化利用DB的存数就行了,连数据库之间的外键管理都不需要,只要有对应的id即可。那么既然如此,相互关联的表肯定会存在删除业务,而事实上我们如今处理删除操作并不是真正的删除,只不过我们添加了is_delete这个字段来标注逻辑是否删除即可。不然在表关联的时候可能会查询不到对应的数据。

如下最重要的用户表中的记录就是绝对不能删除的

举个栗子,我们办理信用卡后会有对应银行中的一个账户,就算你不用卡了,销卡注销了,那么你的账户记录还是会存在的,只不过标志位更改了而已。曾经我有张工行的信用卡,后来不用了,于是在我注销的第二个月我还款错了,但是没有提醒我此卡已经注销,还是照样把钱打了进去,于是就只能很麻烦的跑到总行去走流程把钱取出来了。。。

(注:有些表中的记录可以直接删除的,比如无所谓的消息表,公告表,这些数据在过期后是不会用到的,那么删了也无所谓)

大数据量的情况下查询怎么做?

这里举两个栗子:

1、商品表,我们在电商平台查询商品的时候,其后台并没有真正的去数据库查询,比如淘宝的店铺就有上千万家甚至更多,每家店铺发布的商品又是数以万计,那么商品表中的数据就十分庞大了,直接查询肯定会受到性能影响,那么这个时候不论做水平拆分还是垂直拆分,最终要做的就是使用搜索引擎技术,比如solr或者ES,这样每次查询的时候都是去文件系统中找对应的索引,这样效率会十分高,商品表对于读写来说,写明显要比读要来的多,那么在这种情况下使用搜索引擎是理想的。

2、交易记录表,对于交易来说,每天的交易量也会很多,这个时候很大的情况下会进行数据迁移,也就是水平分表,参照京东的设计,在查询交易的时候把时间分为了多个维度,也就是查询的时候其实是进行了不同表之间的查询,这样可以加速了查询效率。只不过要设定某一时间要进行不同表之间的数据同步以及切换

总结,查询效率的提示本质上是缩小查询范围,范围小了,效率就上去了。水平拆分以及垂直拆分要根据实际情况的业务来进行,不能随意。

 

以上是关于网站平台架构演变史 - 数据库表的查询优化的主要内容,如果未能解决你的问题,请参考以下文章

网站平台架构演变史

网站平台架构演变史

高性能高可用平台架构演变史

高性能高可用平台架构演变史

直播平台的数据库架构演变

阶段一-01.万丈高楼,地基首要-1-3 大型网站架构演变历程