【 TiDB 使用环境】生产环境 /测试/ Poc
这是一套很复杂的系统，读写会比较频每，考虑到IO的均衡和尽可能的减少库与库之间的IO争用，以及erp_base基础库的读写冲突，考虑采用右边的架构，不知道是否合理，但tidb本身就是为了应付大数据和分布式存储的集群方案，右边的架构是否多此一举，有没有必要，有点纠结和无法决策。
我也比较担心右边的架构会重度依赖TICDC的实时同步，不知道TICDC的稳定性如何，心里没底，因为业务库的集群会连接erp_base进行联合查询较多。
你右边的架构目的是增加一个备份机制吗？其实tidb本身具备高可用和容灾能力，部署时服务器可以选择两地三中心或者单个城市三中心的情况，当然各有利弊，异地会存在网络传输和效率问题，单个地区容灾可能没有多地区有保证，所以要根据实际情况权衡。另外，查询比较多的情况下，可以部署几个tiflash节点，可以用来提高响应速度
1 个赞
不是用来备份，是作为读写分离的读库存在另外一个集群当中，当然，在另外一个集群里，是只提供读的功能，有很多JOIN的查询需要使用。
右边的3个集群都是在本地的服务器，我的想法是3个集群或者随着后面新的集群加入，原有的集群规模不会因此而产生变化。
我很担心集群的规模变得特别大，而导致后期的对技术运维的要求特别高，甚至难以优化，因为这个库比较多，3000个左右。总数据量在30亿左右。
谢谢你的建议，我从来没有考虑过引入tiflash以提升查询速度，这对我很有帮助，我总是想把数据控制在一定量来保障数据写入和查询的效率。
ticdc不算是实时同步，并且数据量太大会不会产生延迟？
这是进行了分库分表吗
可以读写分离方式来设计架构
可以考虑将TiDB节点分开，一部分TiDB节点归为联机节点，主要用来联机查询简单写入；一部分TiDB节点归为批量节点，主要用来做批量加工或者大数据写入。我们目前都是采用这种方案，对系统来说相对比较稳定。
1 个赞
- 架构一
优势：集群少管理方便，没有 cdc 同步，大融合有利于资源复用
风险：
- 你这个 erp_xxxxxx 带数字的这些库怎么来的，如果库非常多，表非常多（指上几十万表），对应集群的元数据管理可能有压力。
- 不用业务间可能相互影响，建议使用高版本，资源管控技术+ 分离不同业务 TiDB 实例等多种手段持续优化，减少影响
- 架构二
优势：不会相互影响，都是分离的，可能机器费的更多（每套你至少最小化部署吧）
风险： cdc 维护比较麻烦，可能还会有 ddl 同步问题，不建议长期 cdc
总结建议：表多的问题建议测试下，写入注意下热点问题，个人建议用架构一
1 个赞
谢谢各位的回复，特别感谢FutureDB及小龙虾爱大龙虾、随缘天空。我应该需要做一些压力测试来验证架构二的稳定性及可行性。前期我还是采用架构一，并进行优化的方式来满足试点项目的上线。
建议你把读写放在同一套集群 tidb 不需要做主从复制 压力隔离
tidb的压力他可以自动分布的
虽然是分布式系统
单个机器性能强也要远远大于一堆小机器的堆叠
嗯，明白您的意思了。你是想做读写分离，有个从库集群专门负责数据的读取，同时又不影响主集群写的操作。但是多个集群的管理及运维成本都是挺高的，而且考虑到不能混合部署的情况下，还是很耗资源的。其实tidb是一个OLAP类型数据库，事物和分析型都支持的，而且30亿数据量其实不算大，社区好多用户单表都几亿的数据量，您的场景分析的需求可能比较多，部署时除了tidb，pd和tikv组件外，可以增加几个tiflash，专门用来查询，大致就可以了。然后你可以大致做个压测，看下查询的效率
多个集群应该会存在数据强一致性问题，另外，数据同步的过程，也要从主集群读数据，应该也会占用主集群资源和网络等
别才分出多个集群 tidb单机群性能比多集群性能好很多
架构我过两天写一下。应该有个更好用的架构。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。