wordpress全站音频,上海环球金融中心美食,seo 网站改版,大连网站建设方案咨询#x1f9d1;#x1f4bc; 作者简介 冯光普#xff1a;多点 DMALL 数据库团队负责人#xff0c;负责数据库稳定性建设与 DB PaaS 平台建设#xff0c;在多活数据库架构、数据同步方案等方面拥有丰富经验。 杨家鑫#xff1a;多点高级 DBA#xff0c;擅长故障分析与性能…
作者简介 冯光普多点 DMALL 数据库团队负责人负责数据库稳定性建设与 DB PaaS 平台建设在多活数据库架构、数据同步方案等方面拥有丰富经验。 杨家鑫多点高级 DBA擅长故障分析与性能优化喜欢探索新技术。
多点 DMALL 作为中国及亚洲最大的零售云解决方案数字零售服务商是中国唯一的端到端全渠道零售云解决方案服务商目前其业务据点覆盖六个国家和地区商业模式受到广泛验证其发展历程可以说是中国乃至世界零售数字化进程的缩影。 但在业务高速增长、成果光鲜亮丽的背后多点 DMALL 也面临着诸多来自零售 SaaS 场景和业务系统瓶颈的挑战本文针对零售 SaaS 场景数据处理的痛点从业务视角出发讲述多点 DMALL 如何在做到保障业务数据库稳定可靠的同时还能兼顾更高的读写性能与更低的存储成本。 多点 DMALL 服务对象横跨国内、海外等众多零售商在国内有物美、中百等大型商超覆盖麦德龙、Seven Eleven 711 便利店等跨国零售商。同时还为众多海内外品牌商提供服务让品牌商、供应商、零售商能够链接起来让数据和信息更好地流动让服务对象能够更好地支撑服务 C 端用户。 从生产商、品牌商、供应商再到各个商场门店的零售商最后到消费者不难想象超长的服务链路会产生超级庞大的数据量系统的复杂度也将随着数据量呈指数级增长。在此背景下多点零售 SaaS 系统数据库面临三大难题 第一运维复杂度高。多点 DMALL 使用微服务架构全流程业务环节多系统应用规模大对应数据库的数量超过了 500 个。且随着系统不断迭代数据的规模还在持续增加运维管理难度越来越大。 第二业务增长快水平扩展需求增多。随着业务的增长我们制定了出海战略需要在海外展开业务基于地区数据安全法的要求需要独立部署一整套全新的系统去承接海外业务流量。在初始的部署阶段对后期业务规模及数据增长速度是难以准确预估的。因此数据库资源在初始阶段的分配就变得十分困难。为了节约成本常见的做法是给到较少的部署资源。但很快我们发现业务的快速增长数据的增长特别迅猛带给我们的是如何快速扩容这一难题。 第三需要在同一个集群中服务大量商家。便利店/连锁商超的 SKU最小存货单位规模从几千到几万我们很难做到给每个商家独立部署一套系统。因此我们 SaaS 系统支持上百个中小商家客户所有商家产生的数据在底层共享数据库资源。还有一个显著特点在我们系统中存在非常大的单个租户比如大型连锁商超我们希望能让大型连锁商超所在的租户与其他租户有一定的资源隔离。 综上我们希望数据库能够支撑庞大数据规模还能应对数据快速增长。 为了解决上述难题我们开始了数据库选型。由于分布式数据库支持更大的容量规模具备透明扩展的能力提供金融级数据安全并且可以提高开发效率以及降低运维成本能够更好地支撑业务发展。因此我们坚定地认为它是数据库未来的趋势此次选型仅调研了分布式数据库产品。 一基于业务的选型考虑因素 首先从扩展性考虑我们有很多 MySQL 单库数据量超过了 4TB并且还在快速增长。我们将最大 MySQL 切换到分布式数据库后数据增长到了 29TB。对于数据快速增长及面临的 MySQL 容量瓶颈DBA 非常担忧 要么我们不断推动研发清理数据做数据归档然而结果往往很被动因为研发的重点工作是业务需求迭代 要么继续扩展磁盘如果是在云上扩展空间比较容易云厂商提供的块存储单盘可以达到 32TB 甚至更大但数据继续增长仅仅是将风险延后, 治标不治本, 后续会更加被动。 当然我们还可以选择分库分表的方案但这是一件操作繁琐、风险很高的事情且需要耗时数月因为 SQL 能力有损代码改造不可避免。 因此我们希望利用分布式数据库透明可扩展的能力平滑支撑业务快速增长。 首先从运维成本考虑在保证系统稳定性前提下降低运维复杂度。假设 MySQL 中的一个 database 是一颗蛋一个 MySQL 实例是一个篮子那么部署 1000 个 database应该放到多少 MySQL 实例中把哪些库放在同一个实例中如果把两个对资源要求都很高的重要库放在同一个实例中就有可能会互相抢占资源。还有例如支付类的数据量虽然不大但对业务的要求很高也不能和其他库放在同一个实例中。 因为业务不同优先级不同数据增长速度不同QPS 要求不同所以 DBA 常常需要 “挪蛋”。哪怕抛开资源成本不谈本身的运维挑战就很大我们希望分布式数据库可以解决这个问题帮助 DBA 去自动 “挪蛋”。 其次从高可用考虑期望保证集群高可用能力。运维 MySQL 集群我们基本都是使用 MHA、Orchestrator 去实现高可用但他们都是“外挂”形式的本质上是解决不了网络分区导致的脑裂问题因为数据库和 HA 组件之间是两个独立的软件不在同一个进程里他们之间没有一致性协同控制。 对于 MySQLGroup Replication 这类高可用架构其内置实现的高可用是可靠的它与 OceanBase 或者 TiDB 等分布式数据库一样是基于Paxos 或者 Raft 分布式一致性协议可以实现 RPO0RTO30s。 二产品选型测试数据 基于上述选型因素我们选择了原生分布式数据库 OceanBase并进一步对比了 OceanBase 与MySQL 在表读写、表只读、表只写等方面 QPS 的表现以及二者在存储成本方面的表现。下表为此次测试相关配置。 OceanBase MySQL 社区版本 v4.1.0 v5.7.16 内存配置 租户memory_size 16G innodb_buffer_pool_size 16G 单机器配置 32C RAID10 SSD 32C RAID10 SSD 刷盘配置 默认强制刷盘 sync_binlog1 innodb_flush_log_at_trx_commit2 并发数 5,10,20,30,60,120 5,10,20,30,60,120 测试模式 read_write,read_only,write_only read_write,read_only,write_only 单次测试时间 300s共18种测试并发数x测试模式 300s共18种测试并发数x测试模式 每种测试方法 obd test sysbenchobd自带 会先 prepare、再 run、再cleanup sysbench prepare sysbench run sysbench cleanup 在 OceanBase 与 MySQL 配置相同的情况下对比 10 张 3 千万 sysbench我们发现当并发数小于 200 的时候MySQL 的表现略好于 OceanBase。但无论是 QPS 还是延迟随着并发数的上涨OceanBase 的性能都会逐渐接近 MySQL。 三OceanBase 不同配置的对比 对于单机部署的模式选择通过连接 OBProxy 访问 OBServer 还是直接 OBServer也会影响其在 10 张 3 千万 Sysbench 表读写 QPS 的表现。 我们来看选择连接 OBProxy 和选择直连 OBServer 时的表现可以看到直连 OBServer 性能比通过 OBProxy 连接的性能高 30-50%。 所以对于单机部署的模式来说我们建议直接 OBServer避免通过 OBProxy 访问 OBServer 多走一次网络带来的额外代价。 在不同租户内存配置下性能也会有所不同。可以看到 32GB 租户内存相比 16GB 租户内存性能提升约 14%。 四OceanBase 与 MySQL 表空间对比 在生产环境监控快照场景将 20 张表共 5 亿数据量从 MySQL 迁移 OceanBase表空间占用降低 6 倍。 基于上述测试数据我们最终决定上线 OceanBase总的来说 生产环境监控快照场景 MySQL 存储单副本对比 OceanBase 存储单副本数据压缩率为 6:1OceanBase 的数据压缩比优秀 单机部署并且连接 obproxy在并发度较低时OceanBase QPS 和平均延迟表现稍逊 MySQL最低 QPS 也过万租户内存越高 QPS 性能越好最低平均延迟 3ms。在并发度逐渐上升的过程中OceanBase 各项性能的提升比例会高于 MySQL当并发度超过 200 之后OceanBase 各项性能会逼近甚至超过 MySQL MySQL 一层架构、OceanBase 二层架构obproxy observer单机部署时直连 observer 比连 obproxy 性能会提升 30%~50%。每多一层网络层面的延迟消耗会增加。 第一OceanBase 是单机分布式一体化数据库。从两个方面来讲单机是指性能可以像 MySQL 单机一样做到低延迟、高性能分布式是指当我们需要去规模化扩容时可以轻松扩展。那这两个特性可以帮我们解决什么问题呢 从业务发展阶段及价值来看在业务初期数据量较小享受 MySQL 般极致性能在业务高速增长期可以透明扩展几乎不限容量在业务的全生命周期里可以轻松做到不改代码、不停机迁移并保证高性能。 第二OceanBase 作为原生的分布式数据库天然具备分片自动迁移、负载均衡的可扩展能力可以在业务无感知的情况下透明扩缩容。基于 Paxos 协议的极致追求OceanBase 4.x 版本进一步的极致优化可以做到 RPO0RTO8s保证系统高可用。 第三OceanBase 通过最小化分布式开销的架构设计保证数据库高性能而 OceanBase 的高压缩比相对 MySQL 节省成本6倍以上。同时 OceanBase 多租户十分契合 SaaS 客户的业务场景资源隔离、扩缩容非常容易。 分布式数据库的数据处理涉及内存、磁盘、网络交互在延迟方面内存中读写数据在 0.1 微秒级别SSD 延迟约为 0.1 毫秒机房内网络延迟约为 0.1 毫秒同城机房间延迟约 3 毫秒。整体来看内存的读写延迟与 SSD、网络之间相差了 100-1000 倍吞吐方面内存读写可达到 100GB/s而 SSD 约为 12 GB/s万兆网络约为 1.2GB/s内存与 SSD、网络之间吞吐能力相差约 100 倍差了两个数量级。 MySQL 作为单机数据库InnoDB 和 Server 层是在同一进程中数据交互非常高效在性能和延迟方面基本是无敌的。但对于分布式数据库来说往往采用了计算存储分离架构由于计算和存储层之间网络 I/O 开销不可避免这种设计上就带来的性能瓶颈很难被优化。 OceanBase 的架构设计独特之处就是 SQL引擎存储引擎事务引擎实现在一个进程里OBServer 既做计算又做存储。应用通过 OBProxy 连接 OBServer 集群OBSever 节点会把数据路由信息上报给 OBProxyOBProxy 在接收到应用层 SQL后根据路由信息直接转发 SQL 到最合适的 OBSever 上去执行。如果数据都在 1 个 OBServer 节点上那么 SQL 执行过程就是单机的类似于 MySQL最大程度减少了网络 I/O 。 一为什么 OceanBase 性能更好 当数据量大时或者更高并发时, OceanBase 性能明显优于MySQL, 于是我们对OceanBase 架构进行深入研究。 第一OceanBase 同时兼具单机低延时、分布式高吞吐特性。在面对生产业务数据时OceanBase 单机事务占比可以达到 80% 以上因为 OceanBase 中数据分片的粒度是一个表或分区。因此如果更新的只是一张非分区表或者分区表的单个分区那么它必定是一个单机事务。更进一步如果事务中涉及的多个表都在同一台机器中也会是单机事务。 第二通过 Table group 优化跨机 join可以将跨机事务优化成单机事务。分区粒度的设计可以保证 80% 的事务是单机的再通过 Table group 机制优化高频的跨机 join 后单机事务占比可以进一步提升如果整个业务中有 90% 以上的事务都是单机事务性能肯定会很好。 第三系统会通过 Query 优先级的区分使得小查询优先大查询最多占用 30% 工作线程通过 arge_query_worker_percentage 配置在没有小查询时大查询可用到 100% 工作线程。整个机制类似于高速公路通行规则例如高速公路有 3 条车道如果 3 条车道都有车那么后车很难超车。如果制定一个规则大车只能走最右侧车道小车还有两个车道可以通行这样的运行机制就能很好地预防慢 SQL、大查询堵塞或拖垮系统。 以上三点来自于架构设计以及实践中的优化是保证 OceanBase 高性能的原因。那么为什么 OceanBase 能够在拥有更高性能的同时成本却更低呢 二为什么 OceanBase 成本更低 OceanBase 使用 LSM-Tree 存储引擎同时支持编码压缩和通用压缩具有高压缩比根据我们的测试数据见下图可看出集群存储空间相比 MySQL节省 75%成本更低。 随着多点 DMALL 业务的发展数据量激增节点数也在呈指数级变化眼看着MySQL 的成本很快将超过 OceanBase。如下图所示6 倍压缩是我们在真实生产环境中得到的测试结论。未来业务数据一直增长OceanBase 可以不停地加新的节点而对应的存储成本的增长却是远远慢于 MySQL的。 三OceanBase 的多租户和资源隔离能力 OceanBase 的多租户特性更契合 SaaS 场景从租户间的资源隔离能力与租户的弹性伸缩能力可见一斑。 租户之间的资源隔离能力OceanBase 的多租户是从CPU、 内存、I/O 上进行物理隔离这非常关键保证了业务之间不会出现资源争抢相互影响不会因为一个业务而影响其他的租户。 租户的快速弹性伸缩能力对于一个租户而言假设有 3 个 Zone,每个 Zone 有 2 台机器一共 6 台机器每台机器 有 1 个资源单元。如果想去扩容只需要一条 SQL语句就可以加上 Zone 4、加上 Zone 5变成更多的 Zone从 6 个资源单元变成了 10 个轻松完成水平扩容。同时垂直类的扩容也很简单比如初期给定的资源是 2C8G业务增长后又不想加机器可以把资源单元从 2C8G 变更为 6C12G整个过程是动态无损的业务无感知。这对 DBA 来讲也是一条 SQL 就能搞定极大降低了工作量。因此多租户能力很好地解决了 SaaS 场景需要部署一套系统想要节省成本且方便后期扩容的需求。 多点 DMALL作为 SaaS 场景服务商本身面临着数据库多、数据增速快、资源成本高、运维难度大等诸多痛点。分布式数据库可以很好地支撑业务增长提升开发效率解放 DBA是未来数据库转型坚定的方向。经过探索测试验证了 OceanBase 在扩展性、性能、成本方面的优势符合当前业务发展的需求且多租户能力方面与零售 SaaS 场景非常契合后续必定会有更加深入的合作。
