云浮北京网站建设,电销系统哪家好,设计头像网站免费推荐,营销型网站建设网络推广据国际数据公司#xff08;IDC#xff09;的报告显示#xff0c;预计到2025年#xff0c;全球范围内每天将产生高达180ZB的庞大数据量#xff0c;这一趋势预示着企业将面临着更加严峻的海量数据处理挑战。随着数据日渐庞大#xff0c;一些存储系统会出现诸如存储空间扩展…据国际数据公司IDC的报告显示预计到2025年全球范围内每天将产生高达180ZB的庞大数据量这一趋势预示着企业将面临着更加严峻的海量数据处理挑战。随着数据日渐庞大一些存储系统会出现诸如存储空间扩展难、性能下降甚至卡顿的情况影响业务系统的正常运转增加企业的数据处理成本。众多企业已经开始积极寻求如何在保证处理效率的同时进一步降低数据处理成本。特别是在历史库冷数据场景中这种需求显得尤为普遍。
那么作为一款帮助企业在历史库场景下成本至少降低50%的数据库OceanBase 的核心技术是什么本文将详细解读OceanBase 存储引擎技术。
一套存储引擎支持业务全阶段极致节约资源成本
在传统数据库选型过程中见下图起初单机小规格的 MySQL 即可支撑业务需要。但随着业务的发展MySQL 逐渐在数据增长的过程中无法满足性能和存储需求。这时将系统升级为高规格机器的 Oracle 成为众多企业的选择当高规格单机 Oracle 也无法满足的数据量时则会考虑使用 RAC 共享存储甚至为核心业务更换数据库类型如 Db2。然而众所周知数据系统作为“底座”和“心脏”在更替时不仅要将对业务的影响降至最低还必须考虑替换成本因此一套顺滑可扩展的系统会大大降低成本和风险。那么有没有一套系统可以应对客户不同业务规模下的数据管理需求呢 OceanBase 4.0提出的单机分布式一体化设计就能够满足业务不同阶段的需求。其兼具分布式的扩展性和集中式数据库的功能与单机性能。通过动态日志流的方式实现了系统静态下的单机高性能以及动态调整日志流平滑快速扩展的目的。对于存储引擎则通过资源开销的小型化轻量化使得同一个引擎支持不同部的署形态支持轻松从小数据量到海量数据的平滑增长。
因此在小型业务小数据量场景下一个小规格 OceanBase单机实例便可支撑。随着业务数据量的缓慢增长通过最简单的垂直扩容即租户配置升级到高规格即可满足。当业务发展需要有容灾或者负载均衡时OceanBase可轻松切换至三副本每个副本的数据存储仍然保证高压缩比用以降低多副本带来的成本增长。对于大型业务则可通过在集群内水平扩容的方式来满足需求。这就是OceanBase 单机分布式一体化的重要意义和作用。
另外在OceanBase 4.x 版本存储引擎在资源管理方面更加轻量化、小型化和可扩展使企业更充分、更合理地使用资源节约资源使用成本。
单机百万分区支持元数据小型化按需加载提高资源使用效率
OceanBase 创新地提出了日志流概念用以降低海量数据分区下的网络、CPU 开销。每个数据分区的多副本都是一个Paxos成员组用以保证数据的多副本的一致性。为了降低多分区或是小规格下的一致性协议开销将相同成员组的数据分区日志聚集在一起即所谓的单日志流。只需要一个日志流负责同步或选举即可实现一组分区副本的容灾及 Paxos 高可用。
而对于海量数据下的内存OceanBase 存储引擎设计了元数据按需加载智能区分冷热分区和必要的元数据极大降低内存占用。
如下图所示日志流下面有很多 Tablet 即数据分片可以理解为用户表的一个分区。它是分布式系统负载均衡和容灾恢复等最基础的单位。Tablet 的数量 与 Log Stream 相比是指数级的原因在于一个集群里的可用区的拓扑关系是有限和少量的。但是对分区来说其数量是会根据业务需求来调整分区数量可能上万。 在OceanBase 4.x版本中存储引擎不再将用户的所有分区下的元数据常驻在内存里而是按需加载。所谓元数据是指分区副本的一些基本属性用以支持数据的增删改查、LSM-Tree的变更、负载均衡、容灾恢复等单机和分布式功能。所谓按需加载是指将热分区下的元数据保持在内存里不加载不经常访问的冷分区或是其元数据。通过冷热分离手段使内存的使用效率发挥到极致。在老版本中5W 分区的元数据占用预估 600MB内而4.x 版本中100w 分区下的常驻内存可以降低到 200MB。小规格机器下就能支持更多的分区。类似历史库按时间分区的场景就能在不升级机器规格的情况下存储更久远的历史数据。
此外在OceanBase 老版本中无论是冷数据还是热数据查询这些数据依赖的数据块元数据都会常驻在内存里。预计一张 5TB 容量的表的冷启动内存占用是 5GB 内存但是随着单表或单分区内的数据量增加有限内存下很难做到同步扩展用以支撑数据查询。
对于历史库的场景而言其特点往往是写多、读极少单表体量极大企业用户在配置历史库时更关注成本往往使用小内存、大磁盘的机型。因此在OceanBase 4.X 版本中存储引擎对磁盘上的 SSTable 存储格式做了重构将原本根据数据主键定位宏块的索引层元数据的一种从一层换成了树状结构。用于数据查询的元数据不再会常驻内存而是动态地根据请求负载加载那些查询路径上有关的微块。同等对比下一张 5TB 容量的表的冷启动内存不超过 24KB不论数据规模如何膨胀也不影响单机内存的使用。进一步在历史库的机型选择上降低了对内存的要求成本。 更灵活的磁盘I/O隔离策略更安全、更充分地使用资源
OceanBase 存储引擎提供一套完整的语法支持为每个租户配置最大或最小 IOPS 及权重的能力。让用户能灵活调配租户所使用的I/O资源进一步均衡流量高低峰间对磁盘的性能要求降低成本。
如下图4 号租户蓝线可以限制 IOPS要求最大 IOPS 不超过 5000 在业务上可以防止并发流量过大影响其他租户 1 号红线、2 号绿线租户本身 IOPS 量比较大配置上限是 10 万权重比可以控制流量比较大的租户之间的关系比如永远保持 2:1 的关系。如果 3 号黄线租户新加入这个集群会对集群产生什么冲击呢由于 4 号租户有限制因此不受影响3 号租户的 IOPS 可以向 1 号、2 号租户借1 号、2 号租户按照比例下降权重这样就可以起到租户间的隔离作用。 除了租户间的隔离外还有租户内的隔离。为什么要做租户内的隔离呢
从两个场景来看第一HTAP 场景比如同时需要承担 TP 和 AP 业务流量的情况下避免对于延迟敏感的TP型请求受到干扰影响正常业务流量的稳定性第二前台流量和后台流量隔离如果后台资源隔离做不好则会影响前台的查询请求进而产生用户可感知的抖动。租户内隔离可以做到不同负载混合场景下都能安全有效地使用资源举个例子下图中ABCD 可以是不同的负载B 的 Min Percent 设置 97%意味着虽然 B 是最小的 IOPS但希望能保证最小的 IOPS 不至于跌的很低蓝线A 和 C 本身的权重是 50:25从图中也可以看到保持着 2:1 的关系去保证不同的负载能够拿到相应的 IOPS 。 Compaction优化降低空间放大和磁盘开销
作为存储引擎中另一个对系统资源依赖比较重的领域Compaction 一直是基于LSM-Tree架构的系统里最值得深入研究和探索的核心技术热点之一。各家厂商都在解决读放大、写放大和空间放大间上的权衡问题上有着这各自的优化。Compaction 的技术掌控力关系到能不能为用户节省下更多的计算资源投入到处理更多的业务请求达到更佳的性价比。OceanBase 存储引擎经过十多年的自研探索在 compaction 的计算性能提升和磁盘空间等资源成本降低方面应用了许多有效的优化方法。
OceanBase 存储引擎的 Compaction 整体采用的是业内熟知的Tiered Leveled Policy在此基础上根据事务特性、数据特征、资源依赖等因素设计不同类型的compaction。
如下图整个LSM-Tree的持久化SSTable只有三层有别于RocksDB、Cassandra和一些其他系统的多层优化。虽然层数不多但每一层SSTable都有其设计目的。L0 层目的在于尽快释放内存其中对于数据的处理逻辑必须是低耗且快速的L1 层则是尽可能地消除读放大因为数据之间可能出现交叉包括空间上的数据冗余及时间是多版本间的冗余还需要考虑磁盘开销L2层不仅要彻底解决空间放大的问题还要做到数据校验、回收和压缩等较复杂且带有事务和分布式特性的功能点。 基于数据处理和系统资源两方面的深入分析OceanBase 存储引擎在4.x版本中设计了多类型的 compaction mini、minior、medium、major能够依据系统内资源的实时状况结合统计采样自动调用相应的compaction达到动态平衡缓解资源瓶颈、提高系统稳定性的目的。其中
Mini Compaction 负责生成L0层的SSTable磁盘格式上采用高效的稠密格式不采用耗时较大的压缩技术在最大化iops的同时对CPU消耗最小。Minor Compaction 负责生成L1层合并多个L0和L1层SSTable。其功能是重新整理同一主键上的多版本数据提高查询性能自动探测增量数据间的重叠范围做宏块级别的数据块重用降低空间放大。未来还会支持数据编码和压缩进一步降低磁盘开销。Major Compaction 产生L2层的基线数据。在降本方面major是主要的贡献者。除了进一步回收增量数据中的老版本数据、磁盘格式根据用户的表格属性会采用高级压缩技术降低存储成本以外4.x版本中还对于离散插入导致的数据空洞做重整和压缩对于不同类型的数据更新模型有好的支持。另外major还负责多副本间的数据校验保证数据存储的安全可靠。
而Medium Compaction作用之一是解决LSM-Tree 架构中著名的queuing表问题。举个例子如下图中用户插入 6 行数据随后又删除这 6 行数据。从逻辑上来说Table 是空的但实际查询扫描的物理行数仍然是12 行。再例如 update 和 inset 交互的场景也会出现聚合count为2行但实际扫描代价为7行的问题。这类现象归结为物理行数与逻辑行数的巨大差异造成了查询性能的不及预期。 在 OceanBase 的老版本中用户在建表时需要显式指定 buffer 表属性以提示存储引擎发现行数比较多的buffer表尽快触发特殊的 compaction 动作把一些行压缩掉。OceanBase 4.1 版本里存储引擎在每次生成 SSTable 时会智能地对数据做统计信息收集。对于每个SSTable通过一组向量来表示这组数据的更新特征当发现符合queuing表的特征时系统会自动发起medium compaction消除冗余数据。这一过程对于用户是无感的不需要用户在建表前感知业务特性也不会在系统上线后被迫做一次DDL降低了使用OceanBase 的门槛提高业务切流后的稳定性。
编码与压缩存储空间极致降本
除了在资源利用、磁盘占用、内存占用方面降低整体成本外还有一个关键在于降低存储成本其中的核心技术在于存储引擎。尤其是在海量数据的历史库场景中越是好的存储引擎带来的降本收益越是可观。
很直白地说OceanBase 存储引擎在降成本方面有着传统数据库不具备的架构优势。一般而言基于 B Tree 的传统数据库由于是in place update底层的 block 又是定长的因此在存储压缩后会有写放大的碎片问题需要解决同时会对查询性能造成一定影响。OceanBase使用LSM-Tree 存储架构为数据库压缩提供了更多可能。首先消除了传统 BTree 的磁盘随机写瓶颈和存储空间碎片化问题相比传统实时更新数据块的方式拥有更高的写入性能。其次可以将数据更新增删改与压缩动作解耦数据更新路径中没有压缩动作对性能影响更小。同时在批量落盘的过程中数据库可以自适应地调整数据块中的数据量并在连续对数据块进行压缩的过程中利用上一个块的压缩率等先验知识对下一个块进行更好地压缩。
如下图所示OceanBase 存储引擎针对高压缩比的磁盘格式采用行列混存模式。区别于行存模式微块内的数据不再是一条条铺平的行而是按列先组织在一起。Compaction生成SStable期间对于微块的编码和压缩是分两步进行的。第一步会利用某一列上相邻行的数据特征挑选比较合适的算法进行编码经过第一层编码后的压缩率往往能够达到 50%第二步再对编码后的微块进行一次通用压缩最终甚至能达到平均30%更极致的压缩率。 OceanBase 存储引擎在选择编码算法时会自动分析数据类型、值域、NDV 等特征参考相邻微块的编码压缩历史是自适应启发式的算法。例如对于用小范围的字符串像车辆牌照等支持 Bit-packing 和 HEX 编码能够有效降低存储的位宽达到编码压缩的效果对于列数据重复率高的例如性别、星座等会采用字典编码和 RLE 编码做单列数据去重对于字符串或值域相近的采用差值编码当数据列与列之间存在关联或者前缀相近时如商品大类之间的条形码采用列间编码减小多列数据冗余。
对于编码数据的查询是不需要解码的除了直接查询以外还支持聚合与过滤的下压、支持 SIMD 向量化运算。后续OceanBase 将发布真正的列存版本能对数据编码特征做探测和自适应调整支持更高级的skip index功能对 AP 的查询性能会有非常明显的提升。
总结OceanBase 存储引擎低成本、高效管理数据的秘诀
OceanBase的存储引擎经过多年全自研探索从数据流入到流出的各个环节都对资源开销成本做了极致优化形成一套统一的高效、可扩展的数据存储架构。
在数据组织上对各层元数据采用了按需加载的方式使系统的内存资源服务于访问更频繁的热点数据进一步降低单机规格依赖提升小规格场景的收益。在数据写入路径多层次、多类型compaction策略在保证高效写入性能的同时又能保证平滑不抖动自动压缩数据空洞高压缩比基线数据降低存储成本。在数据查询方面不同格式均支持聚合和过滤下推、SIMD向量化以及未来的skip index提升了大查询和AP性能。在资源管控中租户间CPU、内存和I/O等资源隔离逐步完善使同一套集群服务于多业务系统降低系统整体成本。
以上只是存储引擎中的冰山一角希望后续有更多机会立足用户的实际体验和场景与大家交流存储引擎的技术内幕和细节。
