1.限制那肯定是有的,因为系统数据库的表结构信息存储表,字段为:ID INT UNSIGNED 类型,最多42亿多一点,但肯定不会超过;
2.主要是文件系统,对同时打开多少个文件有限制性的:2048,但是可以修改内核参数
3.拆分过多最大的坏处,体现在:数据库的维护上面;
4.数据量没达到一定程度,且业务需求不需要,例如:新闻主题表,几百G正常,就可能不必要拆分,但是像新浪这样的公司就必须要拆分。换句话而言就是要看数据量、业务发展趋势、数据的存取需求、数据访问的并发度等综合而考虑;
5.拆分,必然对程序操纵数据的复杂度增大了,为此不得不搞一个通用的数据层,其实在数据量、并发不高、压力不大等情况下,是浪费资源,以及降低处理效率的,只有大数据量、高并发等场景下才是提高;
6.拆分之后,还可能带来隐患点,比如通用数据层,必须考虑单点等问题,同时也可能带来问题排查的难度;
7.大数据量、高并发等场景,准确说应该一般是:垂直拆分+水平拆分,肯定是提供性能、系统负载能力、支持业务增量等;
所以,综合建议大家慎重分析自己所在公司的业务模型,数据增长趋势,技术实力等综合考虑,才是最稳妥的,不要把简单的事情搞复杂了。
2.主要是文件系统,对同时打开多少个文件有限制性的:2048,但是可以修改内核参数
3.拆分过多最大的坏处,体现在:数据库的维护上面;
4.数据量没达到一定程度,且业务需求不需要,例如:新闻主题表,几百G正常,就可能不必要拆分,但是像新浪这样的公司就必须要拆分。换句话而言就是要看数据量、业务发展趋势、数据的存取需求、数据访问的并发度等综合而考虑;
5.拆分,必然对程序操纵数据的复杂度增大了,为此不得不搞一个通用的数据层,其实在数据量、并发不高、压力不大等情况下,是浪费资源,以及降低处理效率的,只有大数据量、高并发等场景下才是提高;
6.拆分之后,还可能带来隐患点,比如通用数据层,必须考虑单点等问题,同时也可能带来问题排查的难度;
7.大数据量、高并发等场景,准确说应该一般是:垂直拆分+水平拆分,肯定是提供性能、系统负载能力、支持业务增量等;
所以,综合建议大家慎重分析自己所在公司的业务模型,数据增长趋势,技术实力等综合考虑,才是最稳妥的,不要把简单的事情搞复杂了。