高！
【 在 javafish 的大作中提到: 】
: 等到数据量大到非分库不可了
: 自然养的起能回答这个问题的DBA
--
FROM 120.244.162.*

我们的dba建议我们用shading-jdbc来分库分表
这里面压根没有dba的活

【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 以现在硬件规格和数据库能力
: 数据规模大到数据库内置表分区/实例集群方案顶不住
: 需要手工分表的场景
: ...................
--
FROM 180.167.95.*

可以开除了？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.*

这方案需要高端的数据库和高端的dba，都比较贵而且出问题的时候很难找到有经验的人来处理。
实际生产中，MySQL分库分表更实惠一些。业务侧自己定分库分表规则，加个路由映射，只用开发一次，工作量有限。而dba只管维护普通的MySQL。
【 在 Xjt 的大作中提到: 】
: 分库不需要什么框架吧，微服务天生不就是分库的？  
:  
: 当存在极少数需要分表的情况(比如部分核心业务过亿条？)，完全可以靠拆分该部分业务到更高性能的数据库来解决  
:  
: 真的普遍需要分库分表了（比如连活跃用户数都超过一亿了），可以考虑直接全部换集群版的数据库了？到时候养一堆开源社区大
: ..................

发自「今日水木 on M2011K2C」
--
FROM 114.254.2.*