这里的sharding我理解成分表了,我就对分表提出一些自己的见解。就是有存储压力时,即数据库服务器存储能力变为系统瓶颈: 数据量太大,造成读写能力下降,即使有索引,索引也很大,性能也很差 数据文件太大,数据库备份和恢复都需要很大的时间 数据文件越大,丢失数据的风险越高。 这事有两种选择,分库和分表。一般可以考虑根据业务来分库,业务量增长到当分库也不好使时,也应该分表了。 垂直分表,一般按业务来,例如将user表中的常用的姓名字段和不常用的电话身份证号分开。 水平分表,例如按城市分表 单数据库服务器一般可以支撑起10万左右用户量级的业务,所以初创团队,开始时不用考虑这么多,从0到10万这个过程是十分漫长的。如果是大公司的在原有成熟项目基础上的新功能,这时可以考虑分库分表
这里的sharding我理解成分表了,我就对分表提出一些自己的见解。
就是有存储压力时,即数据库服务器存储能力变为系统瓶颈:
这事有两种选择,分库和分表。
一般可以考虑根据业务来分库,业务量增长到当分库也不好使时,也应该分表了。
单数据库服务器一般可以支撑起10万左右用户量级的业务,所以初创团队,开始时不用考虑这么多,从0到10万这个过程是十分漫长的。如果是大公司的在原有成熟项目基础上的新功能,这时可以考虑分库分表