珠宝网站官网建设需求,项目之家app,校园网站建设的基本条件,个人备案20字备注文章目录 1、为什么对数据库做优化2、双主架构双主架构的工作方式如下#xff1a;双主架构的优势包括#xff1a;但是一般不用这种架构#xff0c;原因是#xff1a; 3、主从复制主从复制的工作方式如下#xff1a;主从复制的优势包括#xff1a;主从复制的缺点 4、冷热分… 文章目录 1、为什么对数据库做优化2、双主架构双主架构的工作方式如下双主架构的优势包括但是一般不用这种架构原因是 3、主从复制主从复制的工作方式如下主从复制的优势包括主从复制的缺点 4、冷热分离冷数据热数据 1、为什么对数据库做优化
对数据库架构进行优化是为了提高数据库系统的性能、可扩展性、稳定性和可维护性。MySQL官方说单表2000万数据性能就达到瓶颈了为了保证查询效率需要让每张表的大小得到控制。 再来说为什么要提高查询效率呢 除了普通的用户查询操作增、删、改操作都包含查询操作所以说在一个应用中查询操作是占比最高的提高了查询效率整体性能都会有所提升。 下面介绍几种常见方案
2、双主架构
它旨在提高数据库的可用性和负载均衡。在双主架构中有两个主数据库实例也称为主节点每个主数据库都可以处理读写操作而不仅仅是一个主数据库处理写操作另一个主数据库处理读操作。
双主架构的工作方式如下
数据同步 两个主数据库之间需要建立数据同步机制以保持数据的一致性。通常使用主从复制或双向复制来实现数据同步。这意味着任何一个主数据库上的写操作都会同步到另一个主数据库从而保持数据的同步。读写操作 由于双主架构允许两个主数据库都处理读写操作因此应用程序可以同时向这两个主数据库发送写操作和读操作。这可以减轻单个主数据库的负载。故障切换 如果其中一个主数据库发生故障应用程序可以切换到另一个正常运行的主数据库以保持系统的可用性。故障切换时应该确保切换后的主数据库是最新的并且可以快速地切换到备用主数据库。
双主架构的优势包括
高可用性 双主架构可以提供较高的可用性因为即使一个主数据库发生故障另一个主数据库仍然可以继续处理读写操作。负载均衡 两个主数据库可以分摊读写负载从而提高数据库的性能和响应性能。容错性 如果一个主数据库出现问题可以快速切换到另一个主数据库从而减少系统的停机时间。
但是一般不用这种架构原因是
这种架构只是做了负载均衡当写操作频繁时会导致两个主数据库之间的数据同步压力增大。还有就是现实中一天可能就会产生1000w条数据两个主数据库的单表会很大影响读和写的性能。
3、主从复制
主从复制是一种常见的数据库复制技术用于在多个MySQL数据库之间实现数据同步。在主从复制中有一个主数据库主节点负责处理写操作而一个或多个从数据库从节点将主数据库的数据复制到自身用于处理读操作。 主从复制和双主架构都实现了负载均衡但主从复制将读操作和写操作进行了分离主数据库只承担写操作从数据库只承担读操作从而减轻主库的负载。对于频繁的写操作场景将读操作分散到从库可以提高主库的性能从而更好地处理写入请求。 主从复制的工作方式如下
主库主节点 主库负责处理所有的写操作如插入、更新和删除操作。主库上的写操作会被记录在二进制日志binary log中这是一个记录数据库变更的日志文件。从库从节点 从库通过读取主库的二进制日志将主库的写操作逐一复制到自身。从库会保持与主库的数据一致性。从库可以用于处理查询操作从而分担主库的负载。
主从复制的优势包括 高可用性 主从复制提供了一种冗余备份如果主库发生故障可以切换到从库以保持系统的可用性。 负载均衡 从库可以用于处理读操作从而减轻主库的负载提高数据库的性能和响应性。 数据备份 从库可以用于数据备份和恢复因为它保留了与主库相同的数据。
主从复制的缺点
不满足强一致性 在MySQL中主节点入库的时候可以选择采用某种方式来判定入库成功 主节点入库以后不管从节点是否同步成功直接返回sql执行成功。 这种方式的特点就是快但是不满足强一致性由于延迟和复制过程中的一些异常情况从库和主库之间可能会出现数据不一致的问题。在复制链路上发生故障或者复制操作出现错误时可能会导致从库数据与主库不一致。 在存储一些不太敏感的数据操作记录日志时可以采用。主节点入库以后等所有的从节点都同步完成以后才返回sql执行成功当有一个从节点落库失败返回执行失败。 这种方式可以满足强一致性会比较慢。 对于存储敏感数据跟钱有关采用这种方式。 同步延迟问题 我刚提交了订单就去查询订单列表这时主库刚入库从库还没去主库同步。有可能看不到我新下的订单。还有可能是我去申请退款并且已经显示了退款成功我去查订单列表由于从库还没有同步主库的数据还会显示购买成功。 可以采用分布式全局锁等查询从库的时候如果退款状态是false未退款再去redis中查看分布式全局锁是否存在如果存在就说明主库已经完成退款操作只是从库还没同步过来可以通知用户后台正在处理请稍后再试。如果redis中不存在这个锁就说明该订单的确未退款。 上述的主从复制对读、写操作进行了分离将读操作平摊给了注册的从数据库分担了主数据库的查询压力。但是没有解决表大小的问题当单表的数据达到2000w后主数据库的写操作包含查询达到瓶颈从数据库的读操作也达到了瓶颈。针对表大下于是有了下面的架构 就是将原本要装几千万数据的单表进行拆分如下图 就是在执行入库或查询之前可以通过数据的id%主库的数量将操作均分到每个主从复制单位上。
当数据量过亿时此时要是延续上面的方案至少需要10个数据库当数据量再多过10亿时至少需要100个数据库,这是不现实的。那么好哈哈哈哈下面就来介绍一下当数据量破亿后该如何优化。
4、冷热分离
表数据量增长速度快或数据量较大时 我们就该考虑是否使用冷热分离解决方案了
冷数据
这是不经常被访问的数据好比打入冷宫通常是历史数据或者很少被查询的数据。冷数据不需要频繁的访问速度因此可以存储在较慢但成本更低的存储介质中如磁盘存储或者分布式文件系统。冷数据可以通过归档、压缩等手段来节省存储空间。 好比你要查询美团外卖的订单你应该很少或者从不去查询1年以前或者更久远的订单吧。这种冷数据如果和其他表没有关联的话可以直接扔eses在数据量1TB的情况下单次查询可达到秒级。
热数据
这是经常被访问的数据通常是最近的数据或者是频繁被查询和更新的数据。热数据对于应用的性能至关重要因此可以采用较快的存储介质如内存或快速的闪存存储设备。对于关系型数据库热数据可以存储在主数据库中。
