AI药企“未知君”完成A+轮融资，利和宏芯领投
06-18
背景当今时代，人们对??互联网的依赖程度非常高，从而产生了大量的数据，企业视之为宝。而这些被视为宝石的数据却给我们的系统带来了很多麻烦。
这些海量数据的存储和访问已经成为系统设计和使用的瓶颈，而这些数据往往存储在数据库中。传统数据库有固有的缺点，那就是单机（单数据库）性能瓶颈，并且扩展非常困难。
在当今的大数据时代，我们迫切需要解决这个问题。如果单机数据库易于扩展并且数据可以分段，这些问题就可以避免。
但是目前的数据库厂商，包括开源数据库MySQL，提供这些服务都是收费的，所以我们求助于一些第三方软件。利用这些软件对数据进行切分，将原来在一个数据库上的数据分布到多个数据库上，以减少各个数据库的负载。
那么我们如何对数据进行分段呢？数据分割 数据分割，简单来说就是将我们之前存储在一个数据库中的数据通过一定的条件分散到多个数据库中，从而达到减少单个数据库负载的效果。数据分割，根据其分割规则，大致分为垂直分割和水平分割两种。
垂直切分 垂直切分是指根据不同的表或模式拆分成不同的数据库。例如：在我们的课程中，订单表（order）和产品表（product）在同一个数据库中，现在我们要对其进行Segment，使得订单表（order）和产品表（product）落入不同的数据库分别位于不同的物理机中，使它们完全隔离，从而达到减轻数据库负载的效果。
如图： 8 垂直细分的特点是规则简单、易于实现、可以按照业务模块进行划分。各业务之间耦合度低，相互影响小。
一个架构设计良好的应用系统的整体功能一定是由多个不同的功能模块组成的。每个功能模块对应数据库中的一系列表。
例如，在我们的课程中，产品功能模块对应的表包括：类别、属性、属性值、品牌、产品、sku等表。订单模块中，对应的表包括：订单、订单详情、订单配送地址、订单日志等。
如图： 4 在架构设计中，功能模块之间越统一、交互越少越好。这样，系统模块之间的耦合度就会很低，各个系统模块的可扩展性和可维护性都会大大提高。
有了这样的系统，就很容易实现数据的垂直分割。但在实际的系统架构设计中，有些表很难做到完全独立，经常会出现跨库join的情况。
还是用上面的例子，比如我们收到一个请求，查询某个品类产生了多少订单。如果是在单个数据库中，我们可以直接连表查询。
但现在垂直分为两个数据库。跨库连接表查询对性能影响很大，不建议使用。
服务只能通过接口来调用，增加了系统的复杂度。对于这种很难做到完全独立的表，作为系统架构设计者，你必须要做出权衡。
数据库是不是应该向业务让步，把这些表放到数据库里呢？还是应该拆分成多个数据库，业务之间通过接口调用？系统早期，数据量比较小，资源有限，所以往往选择放在数据库中。随着业务的发展，数据量达到一定规模，就需要对数据进行垂直细分。
如何分割、分割到什么程度，对建筑师来说是一个艰难的考验。我们来看看垂直切分的优缺点： 优点：切分后业务清晰，切分规则清晰；系统易于扩展和集成；数据维护简单缺点：部分业务表无法Join，只能通过接口调用。
增加了系统的复杂性；跨数据库事务处理困难；垂直切分后，部分业务数据量过大，仍存在单一性能瓶颈；正如最后一个缺点所说，当某个业务模块的数据急剧增加时，仍然存在单机性能缺陷。还是用前面的例子，如果一款热门产品出现，订单量急剧上升，达到单机性能瓶颈，那么你所有与订单相关的业务都会受到影响。
这时候我们就要用到水平分割。水平分割 水平分割比垂直分割更复杂。
它需要将一张表中的数据按照一定的规则拆分到不同的数据库中。例如：以订单库1结尾的奇数订单号的订单，以订单库1结尾的偶数订单号的订单在数据库2中。
这样，原本存在于一个数据库中的订单数据就被水平拆分到了两个数据库中。在查询订单数据时，我们还需要根据订单的尾号来判断该订单是在数据库1还是数据库2中，然后将这条SQL语句发送到正确的数据库中来查出订单。
水平切分的架构图如下： 8 要对数据进行水平切分，首先需要找到切分的顺序规则，找出要按照哪个维度来切分。或者在前面的订单示例中，我们按照奇偶订单号进行拆分，那么这种拆分会有什么影响呢？假设我是一个用户，我下了两个订单。
一种顺序以奇数结束，另一种以偶数结束。这时我进入个人中心和订单列表页面查看我的订单。
那么如何查看这个订单列表页面呢？我必须根据我的用户ID分别获取订单1数据库和订单2数据库来查询订单，然后将它们合并到一个列表中。是不是很麻烦呢？因此，我们在拆分数据时，一定要结合业务，选择适合当前业务场景的拆分规则。
那么按照用户ID来拆分数据合理吗？不一定，例如：我们的身份发生了变化，不是作为买家，而是作为卖家。作为卖家，我有很多订单，卖家后台系统也有订单列表页面。
那么如何查看这个订单列表页面呢？我们是否还需要检查所有的订单数据库，然后将它们聚合成一个订单列表？那么这样看来，根据用户ID来分单是不是不合理呢？因此，在做数据水平拆分的时候，对架构师来说是一个真正的考验。我们看一下水平分割的几种典型的分片规则：对用户id取模，我们之前已经提到过；根据日期分割数据；基于其他字段对数据进行模分割； 8 以上是根据用户id查找模块化拆分的示意图。
我们看一下水平拆分的优缺点： 优点：解决了单库大数据、高并发的性能瓶颈；拆分规则封装良好，对应用端几乎透明，开发者无需关心拆分细节；它提高了系统的效率。稳定性和负载能力；缺点：分裂规则难以抽象；分片事务一致性难以解决；二次扩容时数据迁移和维护困难。
比如：一开始我们根据用户id建模为2个，但是随着业务的增长，2个数据库无法支撑，所以我们继续拆分为4个数据库。那么就需要进行数据迁移。
总而言之，世界上没有什么是完美的。就像数据分割一样，有优点也有缺点。
无论是垂直切片还是水平切片，它们解决了海量数据的存储和访问性能问题，但也带来了很多新的问题。它们共同的缺点是：分布式事务问题；数据库连接问题；多数据源的管理问题。
对于多数据源的管理问题，主要有两种思路：客户端模式。在每个应用模块中，配置您需要的数据源并直接访问数据库。
在各个模块中，完成数据集成；中间代理模式，中间代理统一管理所有数据源，数据库层对开发者完全透明，开发者无需关注拆分细节。基于这两种模式，目前已有成熟的第三方软件。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-18
06-18
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用