- 主题:大神们，都用过哪些分库分表框架
这方案需要高端的数据库和高端的dba，都比较贵而且出问题的时候很难找到有经验的人来处理。
实际生产中，MySQL分库分表更实惠一些。业务侧自己定分库分表规则，加个路由映射，只用开发一次，工作量有限。而dba只管维护普通的MySQL。
【 在 Xjt 的大作中提到: 】
: 分库不需要什么框架吧，微服务天生不就是分库的？
:
: 当存在极少数需要分表的情况(比如部分核心业务过亿条？)，完全可以靠拆分该部分业务到更高性能的数据库来解决
:
: 真的普遍需要分库分表了（比如连活跃用户数都超过一亿了），可以考虑直接全部换集群版的数据库了？到时候养一堆开源社区大
: ..................
发自「今日水木 on M2011K2C」
--
FROM 114.254.2.*
用分布式数据库，不是钱的问题，是找不到人。不仅dba不好找，开发也不好找。更实际的是，如果某一天出线上问题，到底是开发的问题还是数据库的问题可能都要花不少时间定位，到时候扯起皮来线上都没人修。
另外MySQL现在很强，实际线上用过单表五亿行，日增量数百万的MySQL，性能很稳定。这也就导致线上真的需要分表的场景很少，只有当这种场景积累到一定量级的时候，换分布式数据库的收益才会明显大于分库分表，这种时候才值得换。
(可以参考，国内的各大互联网公司的业务基本都是MySQL分库分表，很少业务上分布式数据库)
【 在 Xjt 的大作中提到: 】
:
: 和钱没关系，关键业务数据到1亿条以上，请几个高端dba都请不起，这个公司可以关门了，说明做的就不是赚钱的业务。不赚钱的业务建议还是不要再坚持了。
:
: 非关键业务数据（比如行为数据）或者表没到1亿行的，买个大点的mysql实例就得了。根本不需要分表。
:
: sharding
: ..................
发自「今日水木 on M2011K2C」
--
FROM 114.254.2.*
这不用太复杂，需要分库分表的场景很少。
如果业务小，让业务方自己写分库分表代码(比如直接在代码里指定目标库表)，多不了多少工作量，质量由业务自己负责。
如果业务够大，需要分库分表的场景够多，招个人维护一套db的工具，让他负责质量。
【 在 oldwatch 的大作中提到: 】
:
: 然后压力全部压在某个来路不明无人维护的路由中间件上
: --
: 我明白，”罗拉娜喃喃道，史东被杀的景象和龙的尖叫声又鲜活地混杂在一起.
: 别感到羞傀，泰斯。要感激上天，你还可以对死去的敌人感到同情。只要我们变得冷血，
: 甚至是对我们的敌人，那就是我们输掉这场战争的时候
: ..................
发自「今日水木 on M2011K2C」
--
FROM 114.254.2.*
另外你说的其他人不能用的问题，一般的解法有:
1. 数据库binlog同步到hive，合成一张离线表
2. 数据库binlog同步到es，按天分索引，可以检索
3. 数据库binlog同步到MySQL，按天分表，可以提供天维度的实时MySQL查询
这些方案实施起来都比较简单可靠。
【 在 kangqi 的大作中提到: 】
: 大神们，你们都用过哪些分库分表框架，支持了多大数据量
: --
:
发自「今日水木 on M2011K2C」
--
FROM 114.254.2.*
分区只能帮忙优化索引（我更倾向于认为分区是内置的单实例分表功能），不能水平扩展，成倍提升性能。
【 在 canper 的大作中提到: 】
: mysql分区用起来很简单
--
FROM 114.253.32.*
谁觉得自己随便寨几行代码就比db内置特性性能高?没太看懂，求解读一下。
不要join不要事务，这一套有什么问题?也帮忙解读一下。
【 在 javafish 的大作中提到: 】
:
: 为啥总有人觉得自己随便寨几行代码
: 就比DB内置特性性能高？
:
: 顺便，RDBMS的多实例分布啥时候变得这么容易了
: 自己随便写个中间件就好？
:
: 别跟我说又是互联网不要JOIN不要强事务那套
:
: :
: --
:
发自「今日水木 on M2011K2C」
--
FROM 114.253.32.*