学习
实践
活动
工具
TVP
写文章

存储世界,不止如此 : EB存储引擎背后的技术

TFS存储家族总存储量突破1EB,相当于1亿部蓝光高清视频的数据总量,在这1EB的数据中,图片数突破万亿,文件数超过5000亿,从2007年1PB到2012年100PB,每一个存储量级的突破,都意味着不同的挑战 ,下文阐述了由1PB到1EB的过程中,存储引擎背后的技术。 在新时代新存储矛盾的触发下,TFS家族由1.0升到了2.0版本,从而应对降低存储成本以及新存储功能的需求。 验证是否解决等,以及对现网质量关键的保障一环就是模块开发完成后发布到现网前,还需要先过自动化测试这一环节,以便发现潜在的BUG; 质量监控:我们的眼睛,时刻盯着数十万台服务器、成百上千个业务,一旦出现异常,最快秒主动通知到负责人 4、结束语 正是有了新TFS家族,定制的KV引擎,文件存储引擎,以及对业务数据的深度理解,多年来积累的现网运营经验,才确保了EB的数据,安全稳定的运行。

1.4K20

刘金明:腾讯云 EB 对象存储架构深度剖析及实践

腾讯云存储业务中心副总监-刘金明,在云+未来峰会上做了主题为《腾讯云 EB 对象存储架构深度剖析及实践》的分享,以下内容整理自演讲。 1.png 刘金明:大家好。 说到对象存储,我们不得不提一下腾讯存储平台PFS,早在2016年我还在学校的时候,对分布式存储还没有任何概念的时候,我的前辈就推出第一款腾讯存储平台PFS,几年间也为微信、QQ、相册,包括腾讯视频,腾讯内部所有的资源业务来负责他们的存储服务 到了2015年的时候,我们把整个接口标准化,并且在整个数据层面已经到了EB级别。 然后我们在最底层的硬件层面,我们逐年一直在硬件存储密度上做文章,包括我们的功耗等等,一直在节省整个存储成本。 腾讯云EB对象存储架构剖析及实践.pptx

1.2K148
  • 广告
    关闭

    对象存储COS专场特惠,新用户专享存储包低至1元

    一站式解决数据备份、共享、大数据处理、线上数据托管的云端存储服务

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    微信、QQ都在用的腾讯云EB对象存储架构剖析

    来自腾讯TEG技术工程事业群架构平台部的刘金明在腾讯“云+未来”峰会的「开发者专场」做了主题为“腾讯云EB对象存储架构剖析及实践”的技术内容分享。 关于对象存储,我们先从腾讯存储平台TFS开始说起,早在2016年腾讯推出了自研的云存储平台TFS,几年间为相册、QQ、微信、微云、腾讯视频等腾讯内部产品提供了优质的存储服务。 ? 2013年,腾讯云把存储能力包装之后开始对外开放。 2014年,腾讯存储突破500PB,数据量达到万亿级别。 2015年,引擎升级商用标准化,数据量达到EB级别。 在安全性方面,COS打造了从传输、访问、存储全链路安全加密存储。 成本方面,除了前面提到的图片、视频等可以采用压缩转码等技术实现成本优化外,COS本身提供了标准、低频、归档三存储产品,客户可以按自身的业务特点,选择自己的存储级别,同时可以通过生命周期在不同级别之间灵活的调度数据

    1.6K10

    快手EBHDFS挑战与实践

    从最初的千台规模,目前已经发展成拥有几万台服务器、几EB数据的超大规模存储系统。 1. 集群规模 作为数据平台中最底层的存储系统,目前也是整个快手中机器规模和数据规模最大的分布式存储系统,单个HDFS集群拥有: 几万台服务器 几EB数据规模、几百PB的EC数据量 每天拥有几百PB的数据吞吐 NameNode分级保障功能 我们深度定制了NameNode Rpc框架,将队列拆分成优先队列,Handler依据资源配比依次处理不同优先队列请求。 当磁盘资源达到上限后,高优先请求到来时,会强占低优先资源。除此之外,我们还添加了阈值调整模块,实时感知相关指标,动态调整磁盘限速器阈值,来控制单盘压力。 ? 5. 04 结尾 快手HDFS 经历了3年的发展,从最初的几百台节点支持PB级数据量的小规模集群,到现在的拥有几万台节点支持EB级数据量的超大规模集群。

    26230

    EB级别云存储是如何涨成的?

    作者:腾讯云存储产品中心 雷伟 前言 腾讯云存储服务,从开放至今,已支撑EB存储规模。面对存储规模快速增长、应用数据多样化等挑战如何应对? 早在2006年,腾讯分布式存储系统平台TFS,就开始为腾讯集团所有的业务提供数据存储的服务。至2015年,规模已达EB、用户数已达数十亿级别。 对于常见的大数据分析场景,腾讯云存储提供了多种方式,基于文件存储CFS的实时分析,或基于对象存储COS的离线分析,对象存储COS提供了对接hadoop的插件,通过此插件,hadoop框架可以直接使用云存储 微信存储使用案例 不同时代对云存储的诉求,促进了腾讯云存储的不断发展,包括在高可靠性、高性能、更丰富的功能、更完善的方案。但如何能让应用和存储完美结合,仅从存储端着手,是远远不够的。 这些为微信服务的云存储能力,现已通过腾讯云存储一一对外开放:如用于提高可靠性的多版本管理及跨区域复制;提升性能的分片上传;降低成本的生命周期管理、多种存储类别(热冷存储与归档存储);保障安全的密钥鉴权、

    1.9K53

    Dropbox存储架构:扩展至EB级别的实践

    随着规模逐渐扩大,我们需要建立专有的存储架构,这个项目被命名为“魔力口袋”(Magic Pocket)。两年半之后,如今我们很高兴地宣布:我们的自定义架构将提供90%的用户数据存储及服务。 ? Dropbox 存储两类数据:文件内容与文件/用户的元数据。 我们明了:自己想要打造全世界仅有数个的 EB 存储系统,因此从一开始就很明显,由于在开源社区中并没有能用于 Dropbox 这样规模的内容,我们必须从零开始。 全世界没有几家公司有我们这样的困扰 —— 对这样的存储规模有如此的需求,而在安全性标准上高于我们的就更少了。我们从设计之初就考虑到了可靠性与安全性的问题,确保系统所存储的数据安全可靠,且高度可用。 今年晚些时候,我们会拓展与 AWS 的关系,以便在德国存储欧洲企业用户的数据。为信任我们的用户保护及保存他们的数据,是我们贯彻始终的首要任务。

    82760

    企业存储详解

    Memory,DRAM)、本地二存储(HDD、SSD)以及由 DAS、NAS、SAN、分布式存储等组成的外部存储组成。 从存储介质的角度进行划分,企业存储可以划分为磁性存储、半导体存储、光学存储三大类,各类存储的详细信息如下。 (1)半导体存储:利用半导体特性完成存储,主要包括 SSD,相对于磁性存储和光学存储,半导体存储在读写速度、设备体积等方面优势明显,是当前整个存储产业发展的重点。 (2)磁性存储:利用磁性介质进行数据存储,主要包括机械硬盘、磁带、软盘等,机械硬盘一直以来都是企业存储的重要选择,目前仍占据较大的市场份额。 (3)光学存储:利用光学特性进行数据的存储,主要包括 CD、DVD 等,当前蓝光存储以其大容量、高可靠的特性,成为温冷数据存储的选择方案之一。从架构来分,企业存储可分为集中式存储与分布式存储

    34440

    数值信息的机器存储

    但是我们代码中定义的各种数值又是如何转换为二进制串存储在这些「字节」里面的呢?为什么两个整数相加之后的结果会变成负数? 等等这些类似问题,其实都归咎于 计算机中是如何存储各种类型的数值的。 下图是浮点数存储的标准格式,当然单双精度在各自的模块使用的位数不尽相同。 [image] IEEE 标准规定,单精度和双精度浮点数的存储格式如下: [image] 我们分几种情况来讨论这个浮点数的二进制存储。 规格化存储 非规格化存储 特殊值存储 首先,我们看看规格化的浮点数存储有哪些要求。 这里的 s 用于标识当前的浮点数的正负性,1 和 0 分别代表负数和正数,这没什么说的。 而我们只存储 f,例如: 010111.001 :1.0111001 * 2^4 -> 我们只存储 f = 0.0111001 这样会很方便我们读取,因为我们知道尾数一定位于 0 - 1 之间,所以当我们读取的时候

    61460

    Redis百亿Key存储方案

    在hdfs的帮助下离线存储千亿记录并不困难,然而DMP还需要提供毫秒的实时查询。 媒体映射是千亿、移动id是几十亿; 每天有十亿级别的mapping关系产生; 对于较大时间窗口内可以预判热数据(有一些存留的稳定cookie); 对于当前mapping数据无法预判热数据,有很多是新生成的 乃至千亿存储方案势在必行! 我们通常使用的md5是32位的hexString(16进制字符),它的空间是128bit,这个量级太大了,我们需要存储的是百亿,大约是33bit,所以我们需要有一种机制计算出合适位数的散列,而且为了节约内存 如果规划百亿存储,计划每个桶分担10个kv,那么我们只需2^30=1073741824的桶个数即可,也就是最终key的个数。

    44930

    Redis百亿Key存储方案

    在hdfs的帮助下离线存储千亿记录并不困难,然而DMP还需要提供毫秒的实时查询。 需要为全量数据提供服务,supperid是百亿、媒体映射是千亿、移动id是几十亿; 4. 每天有十亿级别的mapping关系产生; 5. 乃至千亿存储方案势在必行! 我们通常使用的md5是32位的hexString(16进制字符),它的空间是128bit,这个量级太大了,我们需要存储的是百亿,大约是33bit,所以我们需要有一种机制计算出合适位数的散列,而且为了节约内存 如果规划百亿存储,计划每个桶分担10个kv,那么我们只需2^30=1073741824的桶个数即可,也就是最终key的个数。 上面,我需要解释一下, md5是做数据摘要指纹计算的算法,具有单向性。

    1.6K60

    Redis 亿用户信息存储实践:bitmap 位图存储

    可以把bitmap想象成一个以bit为单位的数组,数组的每个单元存储0和1,数组的下标叫做偏移量。 Redis 提供 setbit,getbit,bitcount等几个 bitmap 相关命令。 not 5、统计在线人数 设置在线key:“online:active”,当用户登录时,通过setbit设置 bitmap的优势,以统计活跃用户为例 每个用户id占用空间为1bit,消耗内存非常少,存储 如果布隆过滤器认为商品不存在,就拒绝访问,这样就可以保护存储层。 Data structures are nothing different.

    81720

    入门Oracle存储过程 | oracle

    -- 第一个存储过程 hello world CREATE OR REPLACE PROCEDURE sayHello AS word VARCHAR2(10) := 'hello'; BEGIN INTO student (uuid, username, tuition) VALUES (10002, 'feng', 8000); SELECT * FROM student; -- 实现带参数的存储过程 '||curTuition||';after:'||(curTuition+1000)); END; --Execute BEGIN upTuition(10001); END; -- 存储函数 BEGIN select username into usr from student where uuid=id; return usr; END; -- in out 参数的存储过程

    33720

    RGW百亿对象存储扩容方案

    在线调整shard数量会对业务读写产生较大性能影响,并且调整时长无法预期,理论上object数量越多,reshard时间越长,随着object到达上亿别,每次reshard时间都会越来越长同时还隐藏较大的元数据丢失风险 单个集群的元数据最终都存储在RocksDB中,需要考虑到随着object数量不断增加导致RocksDB实例过大的情况,大体积的DB实例一旦发生compaction会对底层性能和稳定性造成巨大影响。 单集群就算业务能够忍受OSD的扩容影响,也会始终受限于单个集群的机柜数量限制:一个集群不可能在同一个机房无限制的新增存储节点。 3). 沿用现有的S3存储模型以及标准协议,将多个底层bucket(带权重)聚合成一个大的bigbucket,用户所有的操作都基于同一个bigbucket进行,不再需要进行bucket切换。

    1.3K20

    亿用户分布式存储

    分布式数据库和分布式存储是分布式系统中难度最大、挑战最大,也是最容易出问题的地方。互联网公司只有解决分布式数据存储的问题,才能支撑更多次亿用户的涌入。 二、数据分片 数据复制只能提高数据读并发操作能力,并不能提高数据写操作并发的能力以及数据整个的存储容量,也就是并不能提高数据库总存储记录数。 2.1、数据分片介绍 a.主要目标:将一张数据表切分成较小的片,不同的片存储到不同的服务器上面去,通过分片的方式使用多台服务器存储一张数据表,避免一台服务器记录存储处理整张数据表带来的存储及访问压力。 假设我们的数据库将数据表根据用户ID进行分片,分片的逻辑是用户ID为奇数的数据存储在服务器2中,用户ID为偶数的数据存储在服务器1中。 一个简单的解决办法就是将映射关系存储在外面。 2.3、映射表外部存储 ?

    56720

    Redis中存储亿键值对

    将数据存在内存中,理想情况下是在EC2高内存类型(17GB或34GB,而不是68GB实例类型)中 兼容我们现有的基础结构 持久化,以便在服务器宕机时我们不必重跑 这个问题的一个简单解决方案是将它们简单地存储在数据库行中 相反,我们转向Redis,一个我们在Instagram上广泛使用的键值存储。 key将是媒体ID,值将是用户ID: SET media:1155315 939 GET media:1155315 > 939 然而,在对此解决方案进行模型设计时,我们发现Redis需要大约70 MB才存储 mediabucket:1155" "1155315" > "939" 内存差异非常惊人; 使用我们的1,000,000个key(编码为1000个哈希,每个1000个子key),Redis只需要16MB存储

    53330

    虚拟存储体系由()两存储器构成。

    虚拟存储体系由()两存储器构成。 A、主存-辅存 B、寄存器-Cache C、寄存器-主存 D、Cache-主存 答案:A 答案解析:   虚拟存储器是一个容量非常大的存储器的逻辑模型,不是任何实际的物理存储器。 它借助于磁盘等辅助存储器来扩大主存容量,使之为更大或更多的程序所使用。   虚拟存储器指的是主存 - 外存层次。它以透明的方式给用户提供了一个比实际主存空间大得多的程序地址空间。

    7840

    Redis基于百亿Key存储需求

    在hdfs的帮助下离线存储千亿记录并不困难,然而DMP还需要提供毫秒的实时查询。 媒体映射是千亿、移动id是几十亿; 每天有十亿级别的mapping关系产生; 对于较大时间窗口内可以预判热数据(有一些存留的稳定cookie); 对于当前mapping数据无法预判热数据,有很多是新生成的 乃至千亿存储方案势在必行! 我们通常使用的md5是32位的hexString(16进制字符),它的空间是128bit,这个量级太大了,我们需要存储的是百亿,大约是33bit(2的33次方),所以我们需要有一种机制计算出合适位数的散列 如果规划百亿存储,计划每个桶分担10个kv,那么我们只需2^30=1073741824的桶个数即可,也就是最终key的个数。

    4910

    硬核干货 | 轻松驾驭EB千万QPS集群,TDSQL元数据管控与集群调度的演进之路

    该引擎100%兼容MySQL,计算/存储资源均可独立全透明弹性扩缩容,实现了PB存储的Online DDL;计算层每个节点均可读写,轻松支撑千万QPS流量,可以有效应对业务的变化。 TDMetaCluster 统一分配全局唯一递增事务时间戳,实现金融场景下的数据强一致。 分布式架构主要分为计算层、存储层和管控层。 首先是计算层。 通过这样的机制,存储层对每个任务的推进或回滚完全无感知,全部由MC来做协调。  该机制主要有以下三方面的效果: 首先是性能。该机制对性能提升的促进非常显著,在集群比较大时可以轻松支持EB存储。 比如创建表或二索引时,如果要表达成KV形式,主键和二索引都有对应的ID。存储层中以Key区间代表一个数据分片,如01-02数据分片,落在存储节点1上,02-03数据分片,落到存储节点2上。 我们设立表内数据的概念,每个数据在物理层面都可以知道每个Key落在哪个TDStore,但无法感知到它们属于哪个二索引。

    21740

    扫码关注腾讯云开发者

    领取腾讯云代金券