表格存储在QCon2017的分享

本文涉及的产品
表格存储 Tablestore,50G 2个月
日志服务 SLS,月写入数据量 50GB 1个月
简介:         在QCon2017的基础设施专场,笔者以表格存储为基础分享了分布式系统设计的几点考虑,主要是扩展性、可用性和性能。每个点都举了一个具体的例子来阐述。这里对这次分享做一次简单的总结。        首先,说到了表格存储产生的背景,大规模、弱关系数据,对灵活schema变动的需求,传统数据库无法很好的满足,

        在QCon2017的基础设施专场,笔者以表格存储为基础分享了分布式系统设计的几点考虑,主要是扩展性、可用性和性能。每个点都举了一个具体的例子来阐述。这里对这次分享做一次简单的总结。

        首先,说到了表格存储产生的背景,大规模、弱关系数据,对灵活schema变动的需求,传统数据库无法很好的满足,NOSQL的出现是一个很好的补充。NOSQL不是为了取代SQL,也无法取代SQL,是已有数据库生态的很好补充。我认为未来会出现更多种类的数据库,面向不同的业务,使用不同的硬件,数据库市场将迎来更多的成员。

        然后介绍了表格存储的功能、生态、架构以及数据模型,有了这些基础才能更好的理解后面的内容。

        在论述扩展能力的时候,笔者举了个例子。HBase在一次分裂之后,需要做Compaction才能继续分裂,Compaction时间可能数个小时,而表格存储支持连续分裂。那么,为什么表格存储要支持连续分裂呢?主要原因在于多租户服务和企业内产品的不同。对于表格存储而言,用户点点鼠标就可以开通,业务访问随时可能大幅上涨,用户不会提前告诉我们,即使告诉了也人力也没那么多。而访问量上涨有很大的可能导致分区内访问热点,这些热点需要系统能够快速的处理,1个分裂成2个,2个分裂成4个...。而在企业内部,业务一般可以预期的,很难出现运维不期望的巨量上升,所以对于HBase而言,连续分裂的必要性就降低了。这个不同,看似技术的不同,实际则是用户不同、产品形态不同带来的的不同选择。

        在论述可用性的时候,特别讲了一个例子,就是谷歌BigTable和开源HBase都采用的在worker层聚合日志以提高性能。这个思路很好理解,就是将多个分区的日志聚合在一起,写入文件系统中,这样就能减少文件系统的IOPS,提高性能。但是,这对可用性是个很大的伤害,因为一旦机器发生failover,意味着日志文件需要被读出来按照分区进行分割,这些分割完的日志文件再被相应的分区replay,然后相应分区才能提供服务。显然,上面这个过程会使得机器failover时候分区不可用的时间变长(想想看谁来分割日志呢?这是否会成为瓶颈?)。如果考虑到全集群重启,或者交换机down导致较多机器失联,那么其对可用性的影响将十分可观。这里是一个可用性和性能的权衡,表格存储在设计之初,是选择了可用性的,也就是每个分区有独立的日志文件,以降低在机器failover场景下不可服务时间。但是这是否意味着性能的下降?是的,但是我们相信可用性优先级更高,而性能总会被解决,后来我们也找到了非常不错的办法,见下。

        上面说到可用性和性能的权衡,表格存储选择了可用性,而放弃了性能。但是性能显然十分重要,于是我们重新思考了这个问题。BigTable和HBase的核心思想是聚合以减少IOPS,从而提高性能;那么聚合是否一定要做在table这一层呢?是否可以下推做到分布式文件系统层?结论当然是可以,而且效果更好,受益方更多。具体架构见附件里面的说明,我们通过将聚合下推到文件系统、RPC层小包聚合、Pipeline传输等大幅改进了性能,在可用性和性能之间取得了很好的平衡。
        继续向下,我们说到了,作为一个平台,如何向用户学习。附件中给出了PK自增列用于消息推送系统的例子,这方面我们写过不少文章,见[2][3]。


[1]. QCon 2017资料:  http://ppt.geekbang.org/qconsh2017 
[2]. 高并发IM架构: https://yq.aliyun.com/articles/66461
[
3]. 打造千万级Feed流系统: https://yq.aliyun.com/articles/224132
[
4]. 演讲PPT下载: http://ppt.geekbang.org/slide/show/1122

相关实践学习
消息队列+Serverless+Tablestore:实现高弹性的电商订单系统
基于消息队列以及函数计算,快速部署一个高弹性的商品订单系统,能够应对抢购场景下的高并发情况。
阿里云表格存储使用教程
表格存储(Table Store)是构建在阿里云飞天分布式系统之上的分布式NoSQL数据存储服务,根据99.99%的高可用以及11个9的数据可靠性的标准设计。表格存储通过数据分片和负载均衡技术,实现数据规模与访问并发上的无缝扩展,提供海量结构化数据的存储和实时访问。 产品详情:https://www.aliyun.com/product/ots
相关文章
|
5月前
|
存储 SQL 缓存
【报名中】阿里云 x StarRocks:极速湖仓第二季—上海站
阿里云 x StarRocks:极速湖仓第二季,7月20日阿里巴巴上海徐汇滨江园区,现场签到丰富奖品等你拿,不见不散!
321 7
【报名中】阿里云 x StarRocks:极速湖仓第二季—上海站
|
运维 数据挖掘 OLAP
上海 Meetup 邀你来|阿里云 × StarRocks 云上StarRocks极速湖仓
7月15日下午14:00-17:00,《上海线下Meetup I 云上StarRocks极速湖仓》,欢迎参加!
578 0
上海 Meetup 邀你来|阿里云 × StarRocks 云上StarRocks极速湖仓
|
存储 SQL NoSQL
表格存储 Tablestore 十年发展总结
这篇文章接下来会先整体介绍下表格存储 Tablestore,之后会分享下在技术层面产品这几年的功能演进、技术架构演进以及稳定性优化相关的工作,以及在业务层面我们定义的核心应用场景和一些典型案例。
66842 7
表格存储 Tablestore 十年发展总结
|
数据挖掘 OLAP
北京 Meetup 邀你来|阿里云 × StarRocks 云上StarRocks极速湖仓
4月19日(周三)下午,水滴筹、猿辅导、阿里云 EMR 团队和 StarRocks 社区的技术专家,将针对开源 OLAP 技术架构、 StarRocks 产品硬核技术及 EMR StarRocks 实战经验等一系列超干货内容,为大家带来诚意满满的技术盛宴。
839 0
北京 Meetup 邀你来|阿里云 × StarRocks  云上StarRocks极速湖仓
《阿里云产品手册2022-2023 版》——表格存储
《阿里云产品手册2022-2023 版》——表格存储
149 0
|
SQL 机器学习/深度学习 分布式计算
阿里云 MaxCompute 2022-6月刊
2022年6月,MaxCompute包年包月规格支持查询加速、独占Quota、以及对单作业设置CU并发上限;同时MaxCompute支持在DataWorks公共表中查看外部数据源的元数据信息。
1411 0
阿里云 MaxCompute 2022-6月刊
|
存储 数据采集 分布式计算
MaxComputer 在优酷的应用| 学习笔记
快速学习 MaxComputer 在优酷的应用
449 0
MaxComputer 在优酷的应用| 学习笔记
|
存储 SQL 负载均衡
冷热分离之OTS表格存储实战[云栖版]
为什么要冷热分离由于2020疫情的原因,在线教育行业提前被大家所重视,钉钉教育已经服务超过21万所学校、700万教师和1.4亿学生用户,每天大量的教育数据产生。整体数据量:随着时间的积累,数据量越来直大,庞大的数据量对稳定性与性能是一个很大的挑战。当前策略:分库分表,对于大单表的场景,第一个能跳出脑海的就是分库分表。在中国互联网技术圈流传着这么一个说法:MySQL 单表数据量大于 2000 万行,
1613 0
冷热分离之OTS表格存储实战[云栖版]
|
存储 监控 NoSQL
表格存储Tablestore-新手入门攻略
这里期望给大家提供一个简易小攻略,快速上手表格存储Tablestore。期望表格存储Tablestore能够解决你当前架构与场景中遇到问题。
6763 0
表格存储Tablestore-新手入门攻略
|
存储 NoSQL 大数据
表格存储TableStore2.0重磅发布,提供更强大数据管理能力
表格存储TableStore通过同时提供具象和抽象的数据模型,来满足不同核心数据场景的要求,更贴近业务抽象;提供多元化索引(全局二级索引和多元索引)来满足不同类型场景条件查询需求;提供全新的实时数据通道,来扩充实时计算的能力以及可自定义的实时数据处理。
4280 0