- 主题:大神们，都用过哪些分库分表框架
分库不需要什么框架吧，微服务天生不就是分库的？
当存在极少数需要分表的情况(比如部分核心业务过亿条？)，完全可以靠拆分该部分业务到更高性能的数据库来解决
真的普遍需要分库分表了（比如连活跃用户数都超过一亿了），可以考虑直接全部换集群版的数据库了？到时候养一堆开源社区大神来做DBA神挡杀神佛挡杀佛，还怕啥
综上，java本身的分表框架/插件比如Sharding什么的，感觉都是脱裤子放屁啊。。。
P.S. 求大神们指教我yy的是否正确
【 在 kangqi 的大作中提到: 】
: 大神们，你们都用过哪些分库分表框架，支持了多大数据量
--
修改:Xjt FROM 101.228.42.*
FROM 101.228.42.*
3个数量级的预留？……这太疯狂了
【 在 javafish 的大作中提到: 】
: 现在流行架构做3个数量级的预留
: 虽然结果通常是连扩容都没机会
--
FROM 223.104.213.*
可以开除了？shading-jdbc一堆坑，完全不如db cluster
另外你们单表多少条数据了呢？
【 在 guestking 的大作中提到: 】
: 我们的dba建议我们用shading-jdbc来分库分表
: 这里面压根没有dba的活
:
--
修改:Xjt FROM 211.144.19.*
FROM 211.144.19.*
详细说说？我理解都是解决表内数据行数过多的问题哎
这里只讨论OLTP
【 在 nswdxqq 的大作中提到: 】
: sharding和cluster解决的是不同的问题吧
:
--
修改:Xjt FROM 223.104.212.*
FROM 223.104.212.*
和钱没关系，关键业务数据到1亿条以上，请几个高端dba都请不起，这个公司可以关门了，说明做的就不是赚钱的业务。不赚钱的业务建议还是不要再坚持了。
非关键业务数据（比如行为数据）或者表没到1亿行的，买个大点的mysql实例就得了。根本不需要分表。
sharding的问题是分表分的太傻了，sharding分表分完了之后，结果就是除了用了sharding的本微服务以外，其他人都没法碰这个表了（比如ETL去数据湖等等），然后sharding本身也容易出bug和性能问题(程序员不靠谱得时候).我以前碰到用sharding得，后来渐渐就都废了。假装没用
【 在 wudashu 的大作中提到: 】
: 这方案需要高端的数据库和高端的dba，都比较贵而且出问题的时候很难找到有经验的人来处理。
: 实际生产中，MySQL分库分表更实惠一些。业务侧自己定分库分表规则，加个路由映射，只用开发一次，工作量有限。而dba只管维护普通的MySQL。
: 发自「今日水木 on M2011K2C」
--
修改:Xjt FROM 211.144.19.*
FROM 211.144.19.*
所以各大公司包括阿里，号称自研了那么多解决双十一压力的分布式数据库，都是研究了个寂寞？
另外分库没问题，这个肯定是要分的。
【 在 wudashu 的大作中提到: 】
: 用分布式数据库，不是钱的问题，是找不到人。不仅dba不好找，开发也不好找。更实际的是，如果某一天出线上问题，到底是开发的问题还是数据库的问题可能都要花不少时间定位，到时候扯起皮来线上都没人修。
: 另外MySQL现在很强，实际线上用过单表五亿行，日增量数百万的MySQL，性能很稳定。这也就导致线上真的需要分表的场景很少，只有当这种场景积累到一定量级的时候，换分布式数据库的收益才会明显大于分库分表，这种时候才值得换。
: (可以参考，国内的各大互联网公司的业务基本都是MySQL分库分表，很少业务上分布式数据库)
: ...................
--
FROM 211.144.19.*