本文的内容主要涵盖。只要这是个人经验和观点，如果有问题，我希望指出并一起讨论：
Suning的购买，Suning Tesco的E -Commerce App，7月18日总共有3000万用户，面对每日 +数千万的每日SKU + 1000万级每日订单，每日增长数据超过1亿，峰值100,000 QP是一致的。大量数据在数据库压力以及数据操作和维护成本上造成了很大的麻烦，一旦有一个尚未达到缓存的SQL，这就是灾难级别 -对于整个应用程序。
因此，您必须考虑系统的稳定性和长期业务支持。
16年前，公众评论的订单库超过200克。面对越来越复杂的查询尺寸，为了获得稳定的查询，该索引得到了优化，并且两个从数据库中分散了数据库压力。但是，仍然有很多效率。出现了理想的数据库请求，随后的价格战和大量的抢购活动。订单数据库很快很难支持。仅保护当前的限制和消息队列峰以保护它们，以便几乎无法维持每日数据阅读Write的需求，并且随着业务模型的增加，无法再满足原始订单模型。如果DDL经常用于构建表，那么对于如此巨大的库来说，索引非常困难。
因此，审核团队不会担心未来十年的订单能力，并开始削减仓库。
实际上，没有非常定量的指标来确定库的瓶颈，因为每个系统的业务场景都有不同的查询复杂性。但是，当我们精疲力尽时，尽管我们可以优化加拿大以从库中进行分离，但优化SQL，，优化索引，重复使用连接等，当达到限制时始终更改数量变化时，总是会发生性别更改。即使在实际生产环境中，我们也必须计划更多，并且您不能考虑直到倒塌之前考虑。
2.1业务数据解耦 - 纵向拆分不同的业务数据，将不同的业务数据拆分到其各自的数据库中以独立维护。那么最底层的原因是什么？
它是Micro -service.I中的上层服务，以解决快速迭代，安全释放，链接降级和分离的主要业务解耦，以解决大规模代码冲突，小功能的问题排队等待大版本等。高并发流的影响，这将导致基础数据库的承载压力和连接急剧增加。
因此，业务数据通过垂直分裂解耦，每个控制都是为了最大程度地提高微服务的效率。
2.2解决了某个商业库的容量和绩效压力 - 荷里底层。当数据增加到达瓶颈或表瓶颈时，需要库表的水平拆分。
我之前遇到的许多情况，我总是首先将表格分开以解决容量并读写单个表的性能问题。随着业务的开发，单个图书馆也遇到了瓶颈，然后考虑数据库。为什么？
就像在Ali中一样，在新应用程序中进入新应用程序？一个是因为某些用户的大小和一些路由规则。更重要的是，并非所有公司实际上都像ALI一样丰富，并且应在更重要的生存问题上使用有限的资源。如果您是启动结构，则提供了一系列可能支持10年的存储解决方案。感觉就像一个同事会在心中。该公司可以居住3年吗？但是没有人必须这么说，因为我们仍然希望所有公司都能蓬勃发展和蓬勃发展。
因此，分裂方法非常特殊。随后的迭代开发价格如何成为最小的？
2.3多少？表主要取决于容量。许多经验表明，在数千万人之后，性能将显着降低。因此，我们可以将桌子容量设置为一半以上600W。
库主要取决于连接的数量。Ali出售的云存储大致估计了我们要出售。单个库的连接数量设置为4000。在实际评估案例中：如果当前平台每天生成10W订单，则峰值为8000QPS，然后考虑业务扩展和增长速度：
例如，业务是与银行合作以扩大业务，而大小银行的订单平均是。据估计，每次合作都可以带来大量增长。假定它是5,000单身/天/家。如果业务计划每年为10，则业务计划为每年10个。这是5W，每天5年后的每日卷，从理论上讲，它可能达到25W /天。与现有的10W，峰值35W相加。我们的计划需要得到3年的支持，或者三年后，业务扩展将变得温柔，然后我们可以大致估算：
表：（3年365天35W = 3.8亿）/600W = 63大约64张桌子
库：10000并发 / 4000 = 2.5，可以由4个库处理
2.4如何将适用于TAOBAO超级级别的交易形式分开，如何解决存储性能和其他问题：
以上是本文的索引。如果存在遗漏和错误，请补充并正确。
原始：https：//juejin.cn/post/7099322743522328583