为什么说tidb是最省钱的架构

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】

原有的mysql架构

原本我们公司的数据库架构如上。系统的性能是被mysql写库固定死的。扩容有上线。所以会买几百台mysql 做acount0—100 的分库分表。因为用户交易散落在各地。又需要合并所以又aggr合并库。整套架构费用贵性能差。应用效果差。一个大的并发打过来。不是slave报警了。就是dms同步慢了。或着kafka挂了。维护非常繁琐。

如果改成tidb的架构

其实 云上的rds本身也是存储和运算分离的。但你一份数据需要为mysql付费 salve付费 dms的转换付费,redshift付费,kafka的存储付费。

真正做到了费用贵五倍。

只有自己掌握底层,费用才是最省钱的。如果你懂技术,结合tidb,你能在ec2上玩出花来。

这不太清楚,需要对比

哈哈哈

:call_me_hand:完美解决方案

数据无价,有钱还是用商业版

不能说最了,只有更合适

不能说是最省钱啊,只能说是TiDB很适合这个架构,有很大优势

这个相对来说,集中式可能能节省资源

就是有点耗硬件

感觉确实tidb比较合适

架构精简一些

:muscle: :muscle: :muscle: :muscle:

感觉可以可维护性确实会提高

光tidb这套运维体系就感觉可以省不少人力成本

确实,说道运维不得不夸tiup yyds

厉害了我的哥

适合的才是最好的 :100:

我们都是物理机,节约不了成本

这个话题和讨论比较笼统了。犯错成本,部署成本,运维成本,开发成本,升级成本。需要展开对比

硬件费钱