首页 文章 精选 留言 我的

精选列表

搜索[nosql],共2477篇文章
优秀的个人博客,低调大师

海量吞吐的实时NoSQL—HBase的七剑和20151111圣战(数据脱敏版)

2015年11月11日,作为媒体大屏(dataV)、消费记录、支付宝风控、物流详情、库存对账核心数据库的集团HBase,当天稳定运行,顺利完成了任务。并交出了非常漂亮的几项数据: QPS=1993W,TPS=3656W,读流量=56GBps,写流量=40.6GBps,全天吞吐读2.0PB,写1.28PB。 由于HBase团队的组织架构变动,使得今年2015双11的备战重责落在了几杆稚嫩的小枪身上了,不是双11运维、开发新人就是应届毕业生。备战过程的『点』,若从DB集群老核心业务整合开始算起,战役从今年5月就打响了第一枪。备战过程的『面』,涉及支付宝、安全部、菜鸟、天猫、淘宝技术部、共享业务事业部、航旅、阿里云等几乎所有BU。今年我想从HBase系统层面和业务层面两个大方向谈谈整个备战过程,对整个2015年进行一次较为全面的总结。

优秀的个人博客,低调大师

数据分析≠Hadoop+NoSQL,不妨先看完善现有技术的10条捷径

让业务搭乘大数据技术确实是件非常有吸引力的事情,而Apache Hadoop让这个诱惑来的更加的猛烈。Hadoop是个大规模可扩展数据存储平台,构成了大多数大数据项目基础。Hadoop是强大的,然而却需要公司投入大量的学习精力及其它的资源。 如果得到正确的应用,Hadoop确实能从根本上提升你公司的业务,然而这条Hadoop的应用之路却充满了荆棘。另一个方面,许多企业(当然不是Google、Facebook或者Twitter)也没有做大数据分析所需要的巨型集群,他们纯粹是被“大数据”这个热门的词语给吸引的。 就像Dabid Wheeler所说“计算机科学的所有问题都有另一个层次间接的解决方案”,而Hadoop正是类似间接解决方案;当你的上司被一些流行词汇所吸引时,做正确的软件架构决策将变的非常艰难。 下文将给出一些对Hadoop进行投资

优秀的个人博客,低调大师

「腾讯云 NoSQL」技术之 MongoDB 篇:游戏大文档写性能最高 77% 提升的内核优化实践

2026 年 5 月,沙利文(Frost & Sullivan)联合头豹研究院发布《亚太地区游戏行业数据库市场报告》。在这份报告里,**腾讯云 MongoDB 拿下了亚太游戏行业 MongoDB 市场的“三料第一”——市场份额第一、增速第一、综合技术排名第一,全面领先海内外厂商**。在开发兼容、性能扩展、数据可靠性、运维可观测、安全合规等多个维度均处于领先位置,尤其在游戏核心场景适配、大规模业务验证、智能运维上被单独点名为突出优势。 榜单是结果,真正支撑这个结果的,是背后一整套面向游戏场景的持续打磨。腾讯云 MongoDB 已经形成覆盖多种游戏形态的服务矩阵:从库洛《鸣潮》这样的大世界 RPG,到豪腾《咸鱼之王》这样的 SLG,再到简游《羊了个羊》这样的现象级微信小游戏——既要扛住大型游戏核心主存储的长期高压,也要接得住爆款小游戏短周期的流量冲击。这种“既要又要”的服务能力,不是靠堆机器堆出来的,而是靠内核团队针对游戏业务的真实痛点,一轮又一轮地啃硬骨头沉淀下来的。 **游戏业务痛点:大文档场景性能不足** 对绝大多数游戏来说,最核心的数据就是玩家存档——玩家的等级、经验、背包道具、已解锁英雄、任务进度、基地建筑、邮件、设置等等,共同构成了一个玩家的完整状态。由于游戏“一次登录、整体加载,实时变更、整体落盘”的天然特点,这些数据在设计上往往被聚合进同一个文档。这种“整存整取”的模型对游戏业务开发极其友好,也符合文档数据库数据局部性的优势。随着游戏不断上线新玩法、新赛季、新活动,游戏玩家数据会持续膨胀。可以说,"大文档"不是个别游戏的偶发现象,而是整个游戏行业数据模型的共性特征。 针对"游戏业务以大文档为主、而大文档场景存在性能瓶颈"这一问题,腾讯云 MongoDB 内核团队对 insert 和整文档替换这两类游戏最典型用法做了深入分析。通过 perf/top 逐层剖析,我们将瓶颈精准定位到了复制链路的默认压缩上。基于这一定位,我们最终通过将复制链路压缩与客户端链路压缩解耦,让运维可以针对复制链路单独选择最优压缩策略,从根本上消除这一大文档场景下的性能瓶颈,写性能获得极大提升。腾讯云 MongoDB 内核团队将复制链路压缩与客户端链路压缩彻底解耦后,运维可以针对复制链路单独选择最优压缩策略,两条链路互不影响。在 MongoDB 8.0 内核/4C8G 规格下实测,将复制链路压缩单独禁用后,500K 大文档写入性能可提升 12% ~ 77%。 ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/b7cb3154df66886e4cc215577a253ee2.webp) 某游戏用户采用 MongoDB 8.0 内核压测,结合腾讯云 MongoDB 新增的 repl 压缩独立配置能力, 在 4C/8G 规格、500K 大文档场景下进行了多轮验证。性能数据总结如下表所示: | | | | | | -------- | ----------- | ------------ | ---------------- | | **测试场景** | **Net压缩配置** | **Repl压缩** | **ops** | | 原生默认 | snappy | 继承net snappy | **496.40 ops/s** | | 原生zstd | zstd | 继承net zstd | **315.25 ops/s** | | 腾讯云版本 | zstd | disabled | **558.73 ops/s** | 腾讯云 MongoDB 内核版本(net-zstd + repl-disabled)性能收益总结如下: - 相比原生默认网络压缩配置场景(snappy):性能提升 12%。 - 相比原生zstd网络压缩场景:性能提升 77%。 此外,客户端网络压缩与复制链路压缩解耦后,主从节点的部署策略也更加灵活,用户可以根据自身带宽和 CPU 资源自由权衡。对于跨地域主从部署场景,公网带宽成本较高,可以为复制链路单独选择压缩比更高的算法(如 zstd),用少量 CPU 换取显著的带宽节省;而在腾讯云内部主从部署场景下,专线带宽充足、CPU 资源相对宝贵,则可以为复制链路单独禁用压缩,用带宽换 CPU,最大化大文档写入性能。无论选择哪种策略,客户端链路压缩都不受影响。 ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/8dc37ea2452e4649e60c297e05321acc.webp) 先描述一下典型的故障现场。一个 4C/8G 规格的 MongoDB 副本集,承载着某款游戏的玩家存档业务。运维监控上出现了一组非常反直觉的指标组合: - 磁盘 I/O 利用率很低,iostat 分析磁盘无瓶颈。 - 网卡带宽远未打满。 - CPU 跑满 100%。 从现象看 CPU 成为了瓶颈,因此我们重点对这个用户实例深入分析了 CPU 的消耗去向,最终定位到瓶颈点并和社区做了深入交流,问题分析流程如下: ## **2.1. 默认网络压缩场景性能瓶颈分析过程** mongod 进程 top 及 perf 分析如下: - **第一步,看整个进程的 CPU 热点** 对 mongod 进程做 perf top,采样结果如下(节选高占比符号): ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/ed25fca86478374ee49846127338b95a.webp) 第一名就非常刺眼:snappy::internal::CompressFragment 独占 30.38%  的 CPU cycles。也就是说,整个 mongod 进程有接近三分之一的 CPU,都花在了 snappy 压缩这一件事上。 - **第二步,看是哪些线程在吃 CPU** top 按线程展开(-H)后,占用最高的两个线程一目了然,采集进程top监控如下: ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/2f9d4ed39478b75a7ea22dc965cd8bb0.webp) 1.conn31 占 49.0%、conn32 占 46.3%——这两个线程正是这个节点上的主从同步连接线程; 2.两者相加 ≈ 95%,恰好约等于一个完整的 CPU 核; 3.这台机器是 4 核,所以仅这两个复制连接线程,就吃掉了该规格 25% 的 CPU; 4.对比之下,其余上百个业务 connXXX  线程每个只占 2~3%,log server线程、JournalFlusher 等后台线程也都不高。 - **第三步,线程 perf 分析** 把这两个复制线程单独拉出来 perf,看它们的 CPU 到底花在哪。分别对这两个 conn 线程采样: ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/dd3f1f8a9c5f7d8991498048c9f248f7.webp) ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/261390b2954d3c087460864ccd7f6420.webp) 两个复制线程的现象一致:它们各自约有一半的 CPU(53.73% / 48.54%)都消耗在 snappy::internal::CompressFragment 上。也就是说,它们的 CPU 时间主要不是花在读 oplog、组批次、发网络上,而是花在了对下游 oplog 数据做 snappy 压缩上。 - **总结** 把三组数据串起来,整个链路就闭环了: ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/24e21df25b1c91ef5899b92105f01381.webp) 一句话总结定位结论:这个 4C 实例上,仅仅是"给主从复制流量做 snappy 压缩"这一件事,就常态吃掉了约一个 CPU 核(整机 25% 的算力),而磁盘和网络都还很空闲。压缩在这里是在用最紧张的资源(CPU),去省本来就富余的资源(磁盘/网络)。 ## **2.2. zstd 网络压缩场景性能瓶颈分析过程** 顺着上面场景的结论,一个很自然的反问是:既然 snappy 压缩把 CPU 打满了,那换一个“压缩率更高”的算法(比如zstd)会不会更划算?为此我们又补了一组实测:原生 mongod(不含本特性),net.compression.compressors 配置为 zstd。新场景用 ycsb 进行同样的大文档 insert 压测,在主节点上同样使用 top 和 perf 进行分析,过程如下: 第一步,top 分析看线程,承载压测流量的两个连接线程直接单核打满: ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/37b8f8ab65849143fda17a1e21a413cf.webp) ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/c9275192a0957035cfc87649b0024a9c.webp) conn28/conn29 各使用100% CPU(各占满一个核),远高于 eviction(~19%)等后台线程。 第二步,perf 看热点。对整个进程、以及单独对上面那两个热点线程各采样一次,两组结果高度一致,如下2图分别是进程级和线程级 perf 分析图: ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/1778fed49b6073e0403b17db91288413.webp) ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/0a482c031ac5f9c76705b3aae6435bf4.webp) zstd 压缩一项就占了整个进程 44% 的 CPU、同步线程 74% 的 CPU,稳居第一热点;而真正的插入业务逻辑(fixDocumentForInsert、validateBSON)合计不到 1%。也就是说,主节点几乎所有 CPU 都花在给大文档做 zstd 压缩上,写入本身几乎不花 CPU。 (注:热点表里另外出现的 snappy::CompressFragment 约 14%,是 WiredTiger 的块存储压缩,与本次调整的网络压缩无关——网络压缩换成 zstd 之后,网络这部分的开销就从原来的 snappy 变成了更重的 zstd。) ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/3114701d3d274dc953084e33d454f9cd.webp) ## **3.1. 为什么不能简单地“全局关掉压缩”** 看到这里,一个自然的想法是:那就把 net.compression.compressors 设为 disabled 不就行了?问题在于,net.compression.compressors 是一个节点级全局开关,它同时管着两条性质完全不同的链路: - 客户端 → mongod:客户端可能来自公网或跨可用区,带宽是瓶颈、要省流量,这条链路需要压缩; - Secondary → Primary/Secondary:复制链路通常在数据中心内部、同可用区,带宽充裕、CPU 是瓶颈,这条链路不想要压缩。 一个全局开关,逼着用户做“全开或全关”的二选一: 1.全开: 复制链路 CPU 瓶颈(本文的问题)。 2.全关: 客户端这条链路白白多花跨区/公网流量费,且客户端场景下压缩本来是划算的。 ## **3.2. 腾讯云优化方法** 基于上面的分析,优化的目标非常明确:增加一个独立于 net.compression.compressors 的配置项,让运维可以单独控制复制(要涵盖 oplog fetcher、initial-sync cloner、rollback 回滚等 sync-source 数据面)链路的压缩策略——可以关掉、可以选不同算法、也可以继承全局默认,并且不影响客户端链路的压缩行为。 于是有了新参数 replicationNetworkCompression(对应YAML/CLI形式replication.networkCompression.compressors),它支持三种语义: - “”:继承 net.compression.compressors,保持向后兼容; - “disabled”:复制链路强制不压缩,无论全局怎么配; - “zstd”/“snappy,zstd”等:复制链路使用指定算法(按客户端偏好顺序协商),即便全局net是disabled也能启用。 | | | | | ------------------ | --------- | -------- | | 配置方式 | 功能 | 说明 | | “” | 继承net压缩 | 和net压缩一致 | | “disabled” | 复制链路强制不压缩 | 强制关闭 | | “snappy/zlib/zstd” | 任意组合 | 完全脱离net | 这样一来,本文开头的性能瓶颈就有了精准解法: - 法一:配置文件指定 ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/cb2448b3a6f448daca766034c2a117a1.webp) - 法二:命令行指定 ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/ff72f7590120b31f0ffd2953acd30591.webp) # **3.3.解耦后性能测试对比** 两条链路压缩解耦后,4C8G 规格采用 ycsb 对 500K 大文档进行写入测试,测试结果如下(为了保证数据更有说服力,每种场景跑 4 次求平均值): | | | | ------------------------------- | ------------ | | **测试场景** | **ops** | | 原生默认网络配置 | 496.40 ops/s | | 原生 zstd 网络压缩配置 | 315.25 ops/s | | 腾讯云版本(net-zstd + repl-disabled) | 558.73 ops/s | ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/eea123b38bb0c81a0716c7e00790290a.webp) 腾讯云 MongoDB 具备灵活的文档模型、高并发读写、水平扩展和高可用能力,加上智能运维、极致备份恢复能力,能够很好地适配游戏业务中玩家档案、背包道具、战绩记录、排行榜、活动进度等数据结构复杂、变化频繁且访问量波动明显的场景。因此,腾讯云 MongoDB 正成为越来越多游戏用户构建核心数据存储的优先选择。 本文分享了腾讯 MongoDB 内核团队面向游戏业务的独立复制链路压缩优化。针对大文档写入场景,用 perf 定位到复制链路默认压缩吃满 CPU 的瓶颈,通过将复制链路与客户端链路压缩解耦,写性能相比原生默认 snappy 网络压缩配置提升 12.56%、相比 zstd 网络压缩提升 77.24%,并将这一功能回馈社区。 本优化以线上真实业务性能瓶颈牵引触发进行深度分析,再依托深厚的技术积累做针对性的内核改造,最终给用户提供极致的 MongoDB 服务。本文是"游戏专题"第一期,后续我们将持续分享更多游戏场景 MongoDB 内核一线优化实践。 ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/9de6155784c686df9ebd7f24e0c1b2af.webp) 本文分享的是小规格实例上的主从复制压缩性能优化方法。而在大规格实例上,问题的性质会发生变化:由于主从复制链路的关键处理路径是单线程串行的,在大文档场景下,这个单线程极易被 CPU 打满,进而成为整个集群的性能瓶颈——此时即便禁用了复制压缩,单线程瓶颈依然存在。 基于这一背景,下期腾讯云 MongoDB 内核团队将继续分享:如何突破复制链路的单线程瓶颈,让大规格实例的大文档写入性能获得数倍甚至数十倍提升。敬请期待腾讯云 MongoDB 内核游戏场景专项优化之《游戏大文档大规格实例性能十倍提升优化实践》。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

用户登录
用户注册