古老的榕树

分表分库浅谈 - 数据库最佳实践系列

发表 2016-02-22 18:49 阅读(2765) 评论(0) 赞(0)

早在 Web 互联网时代,数据已经很庞大,到了移动互联时代,数据更大了,一个稍微知名的 App ,不到半年的光景,数据已经不是一台服务能装得下了,工作中,碰到了这样的事情,喜出望外之后,有点发愁了,数据日益剧增,小团队找不到更好的方案。


看了很多知名团队的方案,都如出一辙,基本原理就是数据库分布式架构,分表分库。


分表分库,其实是两个不同的策略,什么时候需要分表(或表分区)呢?个人认为,单表数据量很大,一张表接近千万条记录的时候,就应该做好分表的事情了,实际应用中,个人发现 MySQL 单表到了 300 万条,读写数据已经不是那么流畅了。


至于分库又是什么时候需要做的?分库通常是把数据库安装在一个以上的服务器上(也可以单机开多个数据库实例,前提服务器资源足够大,io 足够强),多个服务器上安装一样结构的数据库,分若干个主从库,保持数据同步,保证数据的一致性,更细致的话,需要读写分离。由此得知,分库是一个比较繁琐的事情,不得已不轻易用,只有到了整个数据库的请求响应时间很缓慢,已不能正常响应程序的大部分请求,才会考虑。请求响应时间缓慢也是有其他原因的,比如某些表数据量太大而缓慢,其他表都正常,这种不宜马上分库,优先考虑先局部分表。


如果分表分库,引发一些程序结构上的变化,那么就需要考虑该方案的合不合适了。分库,有时候也会影响程序事务的正常运转,搞不好,之前好好的程序,分库之后,一切就不那么正常了,比如事务,延时等等问题。

Donate

如果文章对您有帮助,请使用手机支付宝扫描二维码,捐赠X元,作者离不开读者的支持!

0 条网友评论

哇~~~ 竟然还没有评论!

称呼*
邮箱*
内容*
验证码*
验证码 看不清换张