产品定价
计费模式
游戏数据库 TcaplusDB 仅支持按量计费模式,提供如下两种版本:
版本 | 计费模式 | 适用场景 |
---|
标准集群版 | 按量计费模式 | 针对测试业务、审核服务和开发业务而设计的根据每日使用峰值流量进行计费;当没有请求访问数据库时,只需要结算最低预留资源的费用即可。 |
独立集群版 | 按量计费模式 | 一般用于线上正式业务,主要是根据接入层和存储层数量来按日计费,当线上业务需要做活动时,提前预估业务峰值,提前对集群进行扩容;活动完成后将集群进行缩容,可灵活配置降低资费。 |
结算周期
按天结算,次日自动对前一天服务产生的费用进行扣费。
标准集群模式计费规则
标准集群版是按量计费模式,根据每天对数据库的读写峰值以及磁盘占用量来计算每日费用。
TcaplusDB 每日费用 = 容量每日最高空间占用费用 + 每日读 CU 峰值费用 + 每日写 CU 峰值费用
名词解释
容量:主键列列名及属性列列名会在每行记录中计算入数据大小。
读 CU:以每秒1次4KB单行读操作为1个预留读 CU(Read Capacity Unit,RCU,读能力单元)。
写 CU:以每秒1次4KB单行写操作为1个预留写 CU(Write Capacity Unit,WCU,写能力单元)。
CU 计算规则:每个请求响应完成后独立算 CU,然后再累加,按请求、响应中大的数值进行结算。不足4KB的按4KB算,超过4KB的以倍数算,多出部分按4KB算。例如,1秒内,1KB的请求操作带来9KB的响应。由于响应的大小大于请求的大小,所以按响应的值进行估算。9KB是4KB的2倍,算2个CU,另外多出1KB,按1CU算,合计3个CU。
CU 统计规则:根据每日对数据库访问的峰值来决定本日结算时的费用,如当日中午12:00:00达到最高的数据库读峰值,那么就以此刻所产生的 RCU 作为今日的结算 RCU;如当日中午15:01:00达到最高的数据库写峰值,那么就以此刻所产生的 WCU 作为今日的结算 WCU。
价格表
地区 | 容量(元/GB/天) | 预留读(元/CU/天) | 预留写(元/CU/天) |
---|
中国大陆 | 0.036 | 0.013 | 0.030 |
中国香港 | 0.038 | 0.013 | 0.038 |
硅谷 | 0.040 | 0.014 | 0.038 |
弗吉尼亚 | 0.038 | 0.014 | 0.038 |
法兰克福 | 0.041 | 0.015 | 0.039 |
新加坡 | 0.042 | 0.017 | 0.040 |
东京 | 0.038 | 0.013 | 0.038 |
首尔 | 0.038 | 0.01756 | 0.04133 |
说明:
计费示例
例如,您在上海地域新创建一个集群,每日访问量为80次/s读访问,26次/s写访问,共0.5GB磁盘容量。
则当日的费用应该为:
容量(GB) | 读请求(CU) | 写请求(CU) | 费用计算 |
---|
1 | 80 | 26 | (1GB × 0.036元/GB/天 + 80 RCU × 0.013元/RCU/天 + 26 WCU × 0.030元/WCU/天) × 1天 = 1.856元 |
例如由于业务推广访问量增长,应用程序与该集群交互增多,读写访问频率上涨,当日峰值达到了1000 RCU/s、300 WCU/s,数据总量达到1.5GB。那么当日的费用应该为:
容量(GB) | 读请求(CU) | 写请求(CU) | 费用计算 |
---|
1.5 | 1000 | 300 | (1.5GB × 0.036元/GB/天 + 1000 RCU × 0.013元/RCU/天 + 300 WCU × 0.030元/WCU/天) × 1天 = 22.054元 |
独立集群模式计费规则
独立集群版是按量计费模式,根据每天对实际使用的存储层和接入层资源来计算每日费用。
TcaplusDB 每日费用 = 接入层每日单价 × 接入层数量 + 存储层机型每日单价 × 存储层数量
价格表
地区 | 接入层(元/个/天) | 存储层-标准实例T1(元/组/天) |
---|
中国大陆 | 3.50 | 450 |
中国香港 | 5.50 | 623.24713626 |
弗吉尼亚 | 4.62 | 567.53872621 |
硅谷 | 4.62 | 617.27929097 |
法兰克福 | 6.04 | 670.52352793 |
新加坡 | 5.30 | 659.16728607 |
东京 | 6.04 | 642.28441920 |
首尔 | 6.04 | 607.38296859 |
计费示例
例如,您在上海地域新创建一个独立集群,申请了两组标准T1机型作为存储层,4个接入层。
则当日的费用应该为:
接入层当日费用 = 3.5 × 4 = 14元
存储层当日费用 = 450 × 2 = 900元
当日总费用为:14元 + 800元 = 814元
背景
随着游戏数据的爆炸式增长,传统关系型数据库越来越难以满足高并发读写、海量数据的高效率存储和访问、高可扩展性和高可用性等需求。NoSQL 数据库则由于其简单的拓展,快速的读写等优势得到了非常迅速的发展。
腾讯云游戏数据库 TcaplusDB 借鉴非关系型数据库的设计理念和技术,结合游戏特点,平衡性能和成本,专为游戏数据存储打造。目前已为《王者荣耀》、《穿越火线》、《火影忍者》等*** DAU(Daily Active User)大作提供了稳定的数据存储服务。
简介
游戏数据库 TcaplusDB 是专为游戏设计的 NoSQL 分布式数据存储服务,支持 Protobuf 接口访问,Tcaplus 将 Cache 与硬盘结合,追求高性能的同时,也节省成本,很好地支持全区全服和分区分服,并针对游戏爆发增长和长尾运维特点提供不停机扩缩容、备份容灾、快速回档等全套解决方案,安全可信赖。目前应用于《王者荣耀》、《穿越火线》、《火影忍者》等数百款流行游戏。
产品功能
Cache 与持久存储结合
功能介绍:Cache + 磁盘存储,冷热数据自动换入换出。
用户价值:不需要使用两种数据库,简化应用程序架构。
支持全区全服
功能介绍:存储空间无上限,单表**支持50TB,不停服扩缩容,支持全区全服、分区分服。
用户价值:无需考虑存储空间扩容问题。
支持 PB 访问
功能介绍:结合 Protobuf 提供灵活的数据访问,支持指定字段的访问与抽取。
用户价值:节省带宽,降低成本。
快速回档
功能介绍:快速拉取冷备并行解压,全流程自动化回档,支持数据精准时间点回档,每个节点300GB数据冷备,2小时之内所有节点完成极速恢复。
用户价值:极速回档,减少故障损失。
备份容灾
功能介绍:过载保护;双机热备;每日冷备容灾机制,数据保留达30天,Binlog 流水保留15天。
用户价值:数据安全保障,轻松应对运营故障。
低成本
以内存为主、磁盘为辅的 key-table NoSQL 存储服务,提供进程内数据在内存和磁盘切换的能力,提供多进程之间动态扩容的能力,保证活跃数据保存在内存,非活跃数据存磁盘。比全内存型存储节省约70%成本,比 Redis+MySQL 节省约40%。
高性能
内存和硬盘热冷数据 LRU(Least Recently Used)交换、数据落地 SSD 盘、数据多机分布等保障性能**化,单机 QPS 达10万/秒,时延小于10毫秒。
高可用
双机热备容灾机制,保证系统故障时的快速恢复。
针对游戏的个性化需求
支持分区分服模型,提供快速开服的能力,跨区访问,跨区数据合并,支持数据压缩等个性化需求,并会根据游戏需要不断优化。
动态拓展
存储空间无上限,容量可以根据游戏的实际需要进行动态的扩展和收缩,且不影响游戏运营,轻松应对业务规模急剧变化。
学习门槛低
继承客户端游戏的开发技术,端游团队开发经验得到延续,服务化 API 提供简单的同步和异步操作接口。
服务化运营
便捷的资源申请方式,业务不再需要自行部署存储服务环境。
优化资源利用率提升运营效率
集成告警等基础系统,提供进程级监控能力,服务化 API 提供接入服务器扩容、负载均衡、容灾的能力,降低产品接入门槛。
手游
移动游戏时间碎片化,玩家之间交互多,数据量大,全区全服和分区分服都很普遍,游戏发展变化快,运营活动多,数据存储层对低时延要求高。TcaplusDB 采用批量操作、自动合服、不停服无损扩缩容、冷热数据交换等技术,对手游这些特点做了针对性支持和优化。同时 TcaplusDB 对数据回档、高可用、数据更新多等游戏数据特点也专门做了支持和优化。
端游
玩家在线时间长,游戏业务生命周期较长,大部分是分区分服,数据记录大,对低时延要求高。TcaplusDB 采用自动容灾、数据分区、记录自动分包、Cache 结合高速硬盘存储等技术,对端游这些特点做了针对性支持和优化。
页游
开服合服频繁,一般是7 x 24小时不停服,浏览器数据缓存能力弱所以对后台数据存储系统要求高。TcaplusDB 采用自动合服、不停服无损扩缩容、Cache 结合高速硬盘存储等技术,对页游这些特点做了针对性支持和优化。
社交
用户可以自由创建数据,评论使用频繁,内容按主题聚合,文本、链接、时间等字段长度比较稳定,数据活跃度按时间分布,读多写少。TcaplusDB 采用列表存储、异构数据类型支持、冷热数据交换、读写分离等技术,对社交这些特点做了针对性支持和优化。
TcaplusDB 是一种完全托管的分布式 NoSQL 数据库服务,主要由管理层,接入层,以及存储层构成,其中接入层与存储层由多个连接节点,多个存储节点组成,并且支持横向的扩缩节点。每一层有着不同作用,整体架构图如下:
管理层
TcaplusDB 管理层用于存放元数据以及管理信息,负责 TcaplusDB 系统的调度与数据管理。
接入层
TcaplusDB 接入层用于处理用户请求,与存储层数据节点交互,并获取数据返回给用户。
存储层
存储层服务为 TcaplusDB 核心服务,用于存放用户数据,并响应接入层请求,返回数据信息。
TcaplusDB 逻辑结构
TcaplusDB 逻辑结构由集群,表格组,表格组成,其关系图如下:
腾讯云数据库托管机房分布在全球多个位置,这些位置节点称为地域(Region)。每个地域(Region)都是一个独立的地理区域。
地域名称是对机房覆盖范围最直接的体现,为便于客户理解,命名规则如下:
地域命名采取【覆盖范围+机房所在城市】的结构,前半段表示该机房的覆盖能力,后半段表示该机房所在或临近的城市。
说明:
TcaplusDB 不区分可用区。
如何选择地域
腾讯云不同地域之间完全隔离,保证不同地域间**程度的稳定性和容错性。建议您选择最靠近您用户的地域,可降低访问时延、提高下载速度。用户启动实例、查看实例等操作都是区分地域属性的。
云产品内网通信的注意事项如下:
同地域下(保障同一账号,且同一个 VPC 内)的云资源之间可通过内网互通,可以直接使用 内网 IP 访问。
不同地域之间网络完全隔离,不同地域之间的云产品默认不能通过内网互通。
不同地域之间的云产品,可以通过 公网 IP 访问 Internet 的方式进行通信。处于不同私有网络的云产品,可以通过 云联网 进行通信,此通信方式更较为高速、稳定。
地域列表
TcaplusDB 仅区分地域(Region),其构成如下:
中国
地域 | 地域标识 |
---|
华东地区(上海) | ap-shanghai |
港澳台地区(中国香港) | ap-hongkong |
其他国家和地区
地域 | 地域标识 |
---|
亚太东南(新加坡) | ap-singapore |
亚太东北(首尔) | ap-seoul |
亚太东北(东京) | ap-tokyo |
美国西部(硅谷) | na-siliconvalley |
美国东部(弗吉尼亚) | na-ashburn |
欧洲地区(法兰克福) | eu-frankfurt |