vivo 数据库降本实践：探索成本效益最优的数据库解决方案

news2024/12/25 2:57:50

vivo 自 2022 年开始调研、测试 OceanBase 至今，现已上线 17 个业务系统，涵盖日志类、分析类、交易类业务，实现了总资源节省 80%，开发、运维工作大幅简化。vivo 体系与流程 IT 部门数据库高级工程师廖光明在本文中，详细介绍了 OceanBase 应用现状、遇到的问题，以及 OceanBase 与 MySQL 在开发、运维架构的各项特性对比。

图片

vivo 是一家以智能终端和智慧服务为核心的科技公司，研发线涵盖 5G 通信、人工智能、工业设计、影像技术等。得益于 vivo 的智能制造网络（含品牌授权），截至目前，vivo 年生产能力近 2 亿台，向全球超过 60 个国家和地区的 5 亿用户提供优质产品和服务。

我所在的部门主要负责 MES、ERP、产销存等系统，比如线下门店购买系统、网上应用商城、App 端应用市场等。vivo 整体上使用的数据库种类繁多，约有 1000+ 主机，涉及 15 种数据库（见图 1），还有数据同步工具需要维护。此外，还有多区域多云的特性，包括东莞机房自建、海外使用阿里云、AWS RDS 数据库。

图片

图1 vivo 使用的数据库种类

我们使用数据库的方式也比较复杂，例如，在一个业务中同时使用 MySQL 主从和MySQL MGR，如果涉及读写分离，还要分别叠加 Proxy 使用，数据库的多种类和架构的复杂性给运维团队带来了较大压力。

此外，我们还面临资源利用率较低、机器数量多、部分系统资源扩展瓶颈等问题。

  • RDS  成本高，资源利用率低：最贵的 CPU 资源利用率较低，平均 CPU 利用率不足 5%，CPU 峰值的平均值也不到 20%；磁盘和 I/O 资源利用率也偏低。在 AWS 中，存储类型和 IOPS 有绑定关系，每个系统都按未来最大规格去分配资源，系统资源的峰值时间节点也不一样。

  • 数据库数量不断增多，资源和管理成本增加：业务微服务拆分越来越细，造成数据库实例不断增多，RDS 成本越来越高。

  • MySQL 数据库扩展性不足：MySQL 数据库的可扩展性有限，依赖于分库分表进行水平扩容，带来开发运维复杂度。

基于业务考虑，核心业务系统为分库分表架构，某些场景又避免不了跨库 JOIN 查询，运维复杂；基于成本考虑，不仅运维成本高，而且数据库成本也高。因此，我们开始探索是否有更优的数据库方案。       

图片

在选型时，我们调研了两款分布式数据库，最终选择引入OceanBase。从选型角度讲，我们看重几个方面：

  • 产品成熟度。OceanBase 在 2010 年面世，在阿里巴巴和蚂蚁经历了很多应用场景的考验，尤其是支付宝核心业务和“天猫双 11”，其产品成熟度已经得到验证。

  • 产品性能。我们对比了 OceanBase 和 MySQL 的并发性能表现（见图 2）。在 50 并发下，OceanBase 单主模式（指定主节点，仅主节点提供服务）优于多主模式（所有节点提供服务），不过，MySQL 的响应时间更短；在 50 并发以上，OceanBase 的响应更快；在复杂 SQL 场景下，OceanBase 全面优于 MySQL。

  • MySQL兼容度。我们同样看重产品和 MySQL的兼容度，经过测试发现 OceanBase 高度兼容 MySQL，支持应用系统平滑迁移，过程中未出现任何兼容性问题。尤其 OceanBase 4.2 版本基本兼容 MySQL 8.0 的语法，避免了用户改造成本。

  • 运维工具。DBA 非常关注运维配套工具是否完善，OceanBase 有完善的运维工具，如安装部署工具 OBD、集群管理平台 OCP、迁移服务 OMS 等。同时，OceanBase 支持 promethus、binlog 等 400 余种生态工具，可以兼容我们现有 Flink CDC+logproxy 的数据同步方式，

图片

图2 OceanBase和MySQL的Sysbench 压测情况（ 三节点 32C 128G ）

此外，相比 MySQL，OceanBase 拥有极高的压缩率，可以节省存储成本；原生分布式，可以更快地完成数据横向扩展和纵向平滑扩展，并且原生高可用。

对于部分功能如数据压缩率、性能、成本等，我们也进行了测试。

▷ 数据压缩与性能

我们基于在云上和线下都有分布的产销存业务观察 OceanBase 的压缩率和响应时间，通过捕捉 MySQL 全量日志，同时全路径回放 MySQL 和 OceanBase 数据库，比对其 SQL 执行效率。

在云上，我们开启 RDS SLS 审计日志，捕获 RDS 时间段内的业务负载，并投递至 OSS，通过 OMA 读取 OSS 审计日志，解析成 SQL 文件，并记录审计日志中的 RDS 内核执行时间，然后使用解析文件，按用户定义回放倍速，向 OceanBase 上发送回放流量，记录 RT 时间，并结合 SLS 中的 RDS 整理最终结果报告。

线下回放同样开启 RDS SLS 审计日志，捕获 RDS 时间段内的业务负载，并投递至 OSS，但仅使用 SLS 解析出的 SQL 内容，不使用 SLS 中的 RDS 时间记录。从生产环境备份恢复出临时 RDS 实例，供流量回放，然后线下部署 OMA，将 SQL 负载同时回放至 RDS 和 MySQL，并分别统计执行时间，生成最终报告。

从图三的测试结果可见，相较于源数据库（MySQL），OceanBase 的效率较有优势，数据存储方面，OceanBase 的压缩比能达到 5.7 倍至 15.3 倍。最重要的是业务系统中的 MySQL 语句迁移到 OceanBase 完全兼容，没有修改。

图片

图3 源数据库（MySQL）与OceanBase的数据压缩率对比

同时通过应用回放，统计执行较为频繁的 SQL 响应时间对比（前者 MySQL，后者 OceanBase，小于 1ms 记为 0ms），从图 4 可见，一半的业务 SQL 性能持平，大约在 1ms 左右；另一半的业务 SQL 有数十上百倍的提升。

图片

图4 MySQL 与 OceanBase 的响应时间对比

由于产销存的线下业务数据量较大，这也是我们引入 OceanBase 的直接诉求。

vivo 各省业务系统的数据量并不一致，比如广东省的业务量比较大，一个门店的业务系统，最大的数据库为 2TB，大省份会独立个库，小省份会共库，但是所有省份又有整合数据的需求。

此前，整个业务系统采用分库分表架构，在查询场景，通过将各库数据聚合起来，难以保证查询的实时性和准确性。经过对 OceanBase 的性能测试，我们可以将汇总库和全国十余个分库合并为一个独立的 OceanBase 库，满足原来的跨库查询需求，较好地满足业务需求。

▷ 降本经验

OceanBase 基于 LSM-Tree 架构的存储引擎和数据压缩比为企业降低存储与硬件成本提供了更多可能。从硬件方面考虑，OceanBase 的降本优势在于超卖，各系统错峰使用超分资源，不同租户之间的弹性可以分时复用，提升资源利用率。假设对应以下三个系统，高峰期使用的资源都需要 4C8G。如果使用 MySQL，需要为三个业务系统都分配 3 个 4C8G 规格的资源；如果使用 OceanBase，只需要分配三个 1C8G 的租户，余 3 个CPU 资源可以共享。另外，如果开启 OceanBase 的读写分离特性，CPU 资源还能进一步充分利用。

图片

图5 OceanBase 降本

图片

目前，我们已经上线了 17 个业务系统，包括日志类、分析类、交易类等。原有业务系统架构为分库分表，以每个省份数据量切分，大省份会独立个库，小省份会共库；另将需要汇总查询的数据通过 DTS 汇总在一起；总计主机台数为 20 台，数据约 4.5T。在上线 OceanBase 后，整合后的资源为 12C，20G 租户规格，并开启读写分离，数据约 600GB。将各分库汇总为一个 OceanBase 库后，总资源节省 80%，也不再需要汇总库，查询时的准确性和实时性也得到了保障。

图片

图6 上线OceanBase节省80%总资源

不过，在使用过程中，我们也遇到了一些问题。

其一，OceanBase 4.2 之前的版本中语句在有大字段的情况下，我们写场景执行计划选择不正确，应该走索引走了全表，研发反馈是成本评估模型未考虑大字段场景而导致的，该问题目前在 4.2 版本已解决。

表：t_log_record` (`inter_param` longtext outer_param` longtext ,create_time` timestamp NOT NULL)  索引列为 create_time
         select * from t_log_record WHERE create_time >= '2023-08-11 09:00:00’  and create_time <= '2023-08-11 23:59:59';

其二，备份时段采用适当错开，NAS 资源挂载采用官方推荐的参数，NAS 资源不够会有出现 hang 住情况。

其三，OCP 管理资源应用容器的问题，当集群管理较多时，应该对 OCP 容器进行扩容，避免出现 OCP 卡顿现象。

我们也发现了部分参数设置的问题，在此列举一下供大家参考。第一个问题是默认的自增序列，如果 OceanBase 设置成和 Oracle Sequence 类似的 Order 模式，并发度也会下降。第二个问题是参数自增列，如果大家比较关注自增值的情况，存在业务含义，可以尽量把该值设小一点，避免某些场景下存在跳号情况，沿用默认参数会跳的比较大。

另外，查询参数默认只有10s，如果不调大，遇到某些场景容易超时，典型场景如创建索引。

图片

我们在使用 OceanBase 过程中开启了读写分离，能更加充分的利用机器资源。之所以不采用多主写模式，是因为 OceanBase 多主的模式在并发度较低的场景下，响应时间和 TPS 不及 MySQL ，在公有云也默认推荐单主的模式。

目前，我们接触 OceanBase 已有半年，从整体的测试和体验来看，符合预期。

图片

基于目前对 OceanBase 和 MySQL 的了解与应用经验，我总结了OceanBase对比MySQL 的优势和不足，供大家参考。

图片

  • 兼容性：从 MySQL 5.7 版本迁移至 OceanBase 无需修改代码，不过目前OceanBase 4.0 版本不支持逆序索引。

  • 在线 DDL ：尽管 MySQL 5.7 是弱支持，但不得不说这是 MySQL 的一个痛点，需要借助扩展工具，而 OceanBase 可以支持几乎所有常用的功能，除了在线分区表模式。

  • 高可用和读写分离：MySQL 需要借助第三方工具来实现高可用、读写分离和审计，OceanBase 原生支持。

  • 执行计划固定：众所周知在 Oracle 里面机器是正常用的，但 MySQL 里面没有，支持 Query write 改写，但不容易管控，而支持 OceanBase 支持 Outline 固定。

  • 全局索引：MySQL 虽然有分区表，但不支持全局索引。但是有些场景其实避免不了使用全局索引，这方面 OceanBase 也是完全支持的。

  • 序列：我们在一些日志场景下，有时希望日志能够保存是哪个月，MySQL 没有序列特性，还需要写脚本，带来高水位的问题。OceanBase 对序列的支持避免了此类问题的发生。

  • TTL 特性：MySQL 不支持，OceanBase 4.2 版本开始支持。

  • 大事务支持：MySQL 容易引起主从延时，如果用 Mgr，一旦事务大就容易有流控剔除节点。我们在数据迁移场景下，发现即使是 TB 级别的数据，OceanBase 也毫无压力。

  • hash join：MySQL 8.0 支持，但比较弱；OceanBase 支持。

  • 并行：MySQL 不支持，这也是慢的原因之一；OceanBase 支持并行，而且在查询优化不动的情况下，如果 CPU 足够，还可以用蛮力。

  • 死锁：MySQL 不支持死锁检测视图，如果遇到死锁，只能去后台翻日志；OceanBase 有死锁检测视图查询。

  • DBLink：MySQL 虽然号称有第三方组件，但基本没人这么用；OceanBase 4.2 开始支持。

  • SQL限流：其实 OceanBase 是可以通过去加 hint 并发来限制 SQL 的并发度。而用 MySQL 或 Oracle 都没有特别好的方式对 SQL 的流量做限制。OceanBase 在不停应用的情况下，还有自动限制慢 SQL 的能力，超过默认 10s 的话，只会给慢 SQL 默认 30% 的资源使用，防止一个慢 SQL 拖垮整个系统。

  • 数据压缩比：MySQL 的数据压缩依赖于操作系统文件系统，相较之下，OceanBase 的数据压缩比是 MySQL 的 6～7 倍。

  • 内存回收：如果我们用 MySQL 的话，经常在使用过程中会发现内存使用的百分比较高，但是这块内存如果想要去回收的话，并不是很好办，因为看内存占用比并不知道 MySQL 实际需要占用多少内存。但 OceanBase 会定期回收合并，释放内存，更容易监控数据库所需实际内存。

  • 碎片：使用 MySQL 的时候频繁 DML 容易有碎片，由于 OceanBase 使用 LSM  架构，会定期合并，不容易有碎片。

  • 备份恢复（闪回查询）：MySQL 不支持，依赖 binlog ，OceanBase 支持表级闪回查询，租户级闪回操作，可以同一份数据进行多次测试。

  • 规格变更：使用 MySQL 的时候云 RDS 在资源规格扩容时，应用会有闪断；OceanBase 租户规格变更没有闪断。

  • 版本升级、变更：MySQL 无官方工具，需要自行开发，这对于升级工作量较大的部门非常不友好，OceanBase 提供了原生的升级工具，比较顺畅。

另外，生态工具对 DBA 而言是减负和提效的利器，MySQL 依赖自行开发，OceanBase 有 ODC、OCP、OMS 等自行开发的工具，可以支持开发自助 SQL 审核、数据执行、数据归档、数据删除、DDL 等常规繁锁危险的操作，可以协助 DBA 完成监控构建、高可用演练、定位问题、备份恢复、规格扩容、语句审核与执行，以及数据的导入、导出、迁移、同步、清理等。目前，我们通过 OceanBase 工具的 WEB 界面基本可以完成相关运维工作，其有细粒度权限管控，可以开放相关权限与相关人员自助，进一步简化了 DBA 的重复工作。OceanBase 还与 400+ 上下游生态工具进行了兼容和集成，对用户来说也很方便。

同时，我也总结了在使用 OceanBase 的工具时，需要注意的事项，以及我们希望优化的细节。

▷ 首先在功能性方面：

  • OCP 上升级 OceanBase 版本时不允许租户有多个 primary_zone 存在，升级时如果租户多，切换主节点会比较繁琐。目前 4.2 版本已经支持。

  • 如果用户手动改了集群的 root 密码或者租户的 root 密码时（不通过 OCP 平台），密码没法重置，这个如果有人故意使坏，比较危险。（OceanBase 计划 4.2.3 版本支持）

  • OCP 查看执行计划时，只有已知索引列统计信息，没有其他列统计信息，希望能补充下相关 where 条件列后的列统计信息。比如 create_time 列区分度不佳，但我想知道 time_cost 列是否适合建索引。（官方告知 obdiag 工具支持该功能）

  • CPU 内存能隔离时能支持最小、最大范围，保证最小资源，很多场景都是用户初始化时资源要多，其他时候资源比较闲。（OCP 4.3 计划支持）

  • OBProxy 读写节点支持权重配置，防止负载不均衡。

  • OceanBase 支持类似 Oracle Intervel 分区特性。当前可以通过 ODC 工具进行支持，但更希望数据库内核原生支持，OceanBase 计划在明年的内核 4.4 版本支持该功能。

  • OMS 管理平台支持第三方登录，角色映射。

▷ 其次在易用性方面：

        

  • OCP 平台上，如果是脚本创建的租户，OCP 控制台登陆时需要手动输入密码；然后如果切换 OCP 用户又要再输入一次密码。（OCP 4.2.2 密码箱易用性改进）

  • OCP 租户界面能有用户说明，这样便于用户侧知道自己名下系统。（OCP 4.2.2 支持标签管理）

  • OMS 添加数据源，在输入 OceanBase 连接串时，能根据 OCP 选择相关信息，减少输入工作量。

图片

此次数据库的选型与替换历经半年，最终取得了不错的效果，主要体现为：OceanBase 与 MySQL 高度兼容，迁移时无需修改代码；MySQL 分库分表架构替换为OceanBase后，总资源占用节省了 80%，也极大地降低了运维成本；OceanBase 的运维工具和社区支持帮助 DBA 简化了运维复杂度，减轻了运维负担。

vivo 对应用 OceanBase 的计划分为三步。

第一步，试点运行。以 OceanBase 社区版替代 MySQL 为起点，优先选择存在分库分表痛点或资源占用成本高的业务，作为迁移到 OceanBase 的试点。将功能模块以影响度从低到高的顺序改造或迁移上线，过程中开发、DBA 或相关团队同步建设 OceanBase 的技术能力。

第二步，业务扩散并规模化改造。传统数据库架构向 OceanBase 数据库架构改造，同时，结合 OceanBase 的特性，选择适用且有改造价值的业务改造，将 OceanBase 作为 MySQL 能力不足场景的补充，依然保留 MySQL 适用场景。

第三步，规模化改造并全面保障业务。将 OceanBase 技术能力在 IT 建设成熟，并落地于更多 vivo 的业务场景，同时进行成本优化、降本增效，以及建设灾备环境。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1195080.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

利用MSF设置代理

利用MSF设置代理

1、介绍&#xff1a; 通过MSF拿到一个机器的权限后&#xff0c;通过MSF搭建socks代理&#xff0c;然后通内网。 拿到目标权限&#xff0c;有很多方法&#xff0c;比如&#xff1a;①ms17-010 ②补丁漏洞 ③MSF生成后门 在此直接使用MSF生成后门 MSF中有三个代理模块&#x…
阅读更多...
【Kurbernetes部署】知识点总结（部署方式、网络插件.....）

【Kurbernetes部署】知识点总结（部署方式、网络插件.....）

知识点合集 一、Kurbernetes常见的部署方式1.1 Minikube&#xff08;一般不用&#xff09;1.2 Kubeadm1.3 二进制安装部署&#xff08;推荐使用的方式&#xff09; 二、二进制部署Kurbetnetes的思路Step1 部署etcdStep2 部署master组件Step3 部署node组件Step4 部署多master高可…
阅读更多...
leetcode：160. 相交链表

leetcode：160. 相交链表

一、题目 原题链接&#xff1a;160. 相交链表 - 力扣&#xff08;LeetCode&#xff09; 函数原型&#xff1a; struct ListNode *getIntersectionNode(struct ListNode *headA, struct ListNode *headB) 二、思路 判断两个链表是否相交&#xff0c;只要判断两个链表是否有相同的…
阅读更多...
3 分钟看完 NVIDIA GPU 架构及演进

3 分钟看完 NVIDIA GPU 架构及演进

近期随着 AI 市场的爆发式增长&#xff0c;作为 AI 背后技术的核心之一 GPU&#xff08;图形处理器&#xff09;的价格也水涨船高。GPU 在人工智能中发挥着巨大的重要&#xff0c;特别是在计算和数据处理方面。目前生产 GPU 主流厂商其实并不多&#xff0c;主要就是 NVIDIA、AM…
阅读更多...
利用IP风险画像强化金融行业网络安全防御

利用IP风险画像强化金融行业网络安全防御

在数字化时代&#xff0c;金融行业日益依赖互联网和技术创新&#xff0c;但这也使得金融机构成为网络攻击的主要目标。为了应对日益复杂的网络威胁&#xff0c;金融机构迫切需要采用先进的安全技术和工具。其中&#xff0c;IP风险画像技术成为提升网络安全的一项重要策略。 1.…
阅读更多...
深度学习检测小目标常用方法

深度学习检测小目标常用方法

前言 在深度学习目标检测中&#xff0c;特别是人脸检测中&#xff0c;小目标、小人脸的检测由于分辨率低&#xff0c;图片模糊&#xff0c;信息少&#xff0c;噪音多&#xff0c;所以一直是一个实际且常见的困难问题。不过在这几年的发展中&#xff0c;也涌现了一些提高小目标…
阅读更多...
国家数据局正式揭牌，2030年数据要素市场规模或破万亿

国家数据局正式揭牌，2030年数据要素市场规模或破万亿

10月25日&#xff0c;国家数据局正式挂牌&#xff01; 自今年3月国务院通过《党和国家机构改革方案》提出组建国家数据局以来&#xff0c;国家数据局的组建工作一直在紧锣密鼓地进行中。经过7个月的筹备工作&#xff0c;国家数据局于2023年10月25日挂牌成立。 根据《党和国家机…
阅读更多...
使用Dockerfile依赖maven基础镜像部署springboot的程序案例

使用Dockerfile依赖maven基础镜像部署springboot的程序案例

1、准备springboot Demo代码 就一个controller层代码&#xff0c;返回当前时间及hello world 2、项目根目录下&#xff0c;新建DockerFile文件 注意&#xff0c;等本地配置完毕后&#xff0c;Dockerfile文件需要与项目helloworld同级&#xff0c;这里先放项目里面 3、docker …
阅读更多...
从零开始搭建React+TypeScript+webpack开发环境-基于lerna的webpack项目工程化改造

从零开始搭建React+TypeScript+webpack开发环境-基于lerna的webpack项目工程化改造

项目背景 在实际项目中&#xff0c;我们的前端项目往往是一个大型的Webpack项目&#xff0c;结构较为复杂。项目根目录下包含了各种配置文件、源代码、以及静态资源&#xff0c;整体布局相对扁平。Webpack的配置文件分散在不同的部分&#xff0c;包括入口文件、输出目录、加载…
阅读更多...
【JMeter】组件之 Listener监听器选择

【JMeter】组件之 Listener监听器选择

JMeter中监听器的作用就是收集、显示JMeter取样器的结果&#xff0c;并以树形、图表、表格的形式显示出来。还可以将监听结果保存成文件。 View Results Tree-->察看结果树 Summary Report-->汇总报告 为测试中的每个不同命名的请求创建一行。这与聚合报告类似&#xff…
阅读更多...
【扩散模型】实战：创建一个类别条件扩散模型

【扩散模型】实战：创建一个类别条件扩散模型

创建一个类别条件扩散模型 1. 配置和数据准备2. 创建一个以类别为条件的UNet模型3. 训练和采样 本文介绍一种给扩散模型添加额外条件信息的方法。具体地&#xff0c;将在MNIST数据集上训练一个以类别为条件的扩散模型。并且可以在推理阶段指定想要生成的是哪个数字。 1. 配置和…
阅读更多...
Conda executable is not found 三种问题解决

Conda executable is not found 三种问题解决

如果在PyCharm中配置Python解释器时显示“conda executable is not found”错误消息&#xff0c;这意味着PyCharm无法找到您的Conda可执行文件。您可以按照以下步骤解决此问题&#xff1a; 1.方法一 确认Conda已正确安装。请确保您已经正确安装了Anaconda或Miniconda&#xff…
阅读更多...
数字化工厂管理系统的三个关键技术是什么

数字化工厂管理系统的三个关键技术是什么

随着科技的飞速发展&#xff0c;数字化工厂管理系统已经成为了现代制造业的重要发展方向。数字化工厂管理系统通过充分运用建模技术、仿真技术和单一数据源技术&#xff0c;实现了产品设计和生产的虚拟化&#xff0c;为制造业带来了前所未有的效率和创新能力。本文将深入探讨这…
阅读更多...
Matlab的多项式留数与极点的计算

Matlab的多项式留数与极点的计算

Matlab的多项式留数与极点的计算 以下面的多项式为例&#xff1a; 运算代码&#xff1a; clc clear closesyms p % 定义多项式 Zp(5*p^571*p^370*p)/(2*p^635*p^4117*p^236); % 提取分子与分母 [I,D]numden(Zp); Idouble(coeffs(I,p,"All"));%分子 Ddouble(coeffs…
阅读更多...
轻量日志管理方案-[EFK]

轻量日志管理方案-[EFK]

使用FileBeat进行日志文件的数据收集&#xff0c;并发送到ES进行存储&#xff0c;最后Kibana进行查看展示&#xff1b; 这个应该是最简单&#xff0c;轻量的日志收集方案了。 最总方案为&#xff1a;FileBeatESKibana ; 【Kibana过于强大&#xff0c;感觉可以无限扩展】 文章目…
阅读更多...
css：文本对齐属性vertical-align实现化学元素上标下标的显示

css：文本对齐属性vertical-align实现化学元素上标下标的显示

文档 https://developer.mozilla.org/zh-CN/docs/Web/CSS/vertical-align 语法 vertical-align: <value>;可选值&#xff1a; sub&#xff1a;使元素的基线与父元素的下标基线对齐。 super&#xff1a;使元素的基线与父元素的上标基线对齐。 text-top&#xff1a;使…
阅读更多...
24张宇八套卷数一复盘（六）

24张宇八套卷数一复盘（六）

张八&#xff08;六&#xff09;11/10107选择45填空20高数大题22线代大题12概率大题8 前言 临近考试冲刺阶段&#xff0c;感觉做过的卷子很难再提起精神去复盘&#xff0c;于是在这里进行一下复盘。 主要是对于整体试卷结构的把握&#xff0c;以及考试状态的复盘。 简单的卷子把…
阅读更多...
说说React render方法的原理？在什么时候会被触发？

说说React render方法的原理？在什么时候会被触发？

一、原理 首先&#xff0c;render函数在react中有两种形式&#xff1a; 在类组件中&#xff0c;指的是render方法&#xff1a; class Foo extends React.Component { render() { return <h1> Foo </h1>; } } 在函数组件中&#xff0c;指的是函…
阅读更多...
虹科分享 | 2023温控生物技术和医药物流前景展望专题报告

虹科分享 | 2023温控生物技术和医药物流前景展望专题报告

2023温控生物技术和医药物流前景展望专题报告 全球供应链正在发生根本性的变化&#xff0c;而制药业对供应链的使用也在不断发展。突破性疗法和个性化药品有望带来崭新的未来&#xff0c;这也改变了我们如今的行医方式。然而&#xff0c;在监管和基础设施方面还面临着许多挑战…
阅读更多...
常见排序算法之插入排序类

常见排序算法之插入排序类

插入排序&#xff0c;是一种简单直观的排序算法&#xff0c;工作原理是将一个记录插入到已经排好序的有序表中&#xff0c;从而形成一个新的、记录数增1的有序表。在实现过程中&#xff0c;它使用双层循环&#xff0c;外层循环对除了第一个元素之外的所有元素&#xff0c;内层循…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023