NOSQL 追随者
之前在DBA+社区分享了表格存储的负载均衡,在此记录分享。
SOSP2017[1]于10月底在上海举办,因为离得比较近,笔者也去参加学习了一下。会议上的大部分文章都相当的务实,有的甚至可以直接辅助工程实践,比如将要分享的PebblesDB[2]。 10年前Google发表BigTable[3]的论文,推动了基于LSM的KV系统架构的流行,而随着
在QCon2017的基础设施专场,笔者以表格存储为基础分享了分布式系统设计的几点考虑,主要是扩展性、可用性和性能。每个点都举了一个具体的例子来阐述。这里对这次分享做一次简单的总结。 首先,说到了表格存储产生的背景,大规模、弱关系数据,对灵活schema变动的需求,传统数据库无法很好的满足,
几个月前,AWS在SIGMOD 17上发表了《Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases》,详细解读了Aurora的背景、设计思想以及效果。即使本人不搞关系数据库,也没有读过MySQL内核源码,读完后也觉得
概述 随着软件架构的愈发复杂,了解系统现状、调查问题的困难度也增加了很多。此时,一套完善的监控方案能够让开发和运维工程师快速排查问题,更好的维护系统的稳定性。 开源监控方案中,Zabbix、Nagios都是不错的监控软件,可以针对数十万的设备监控数百万的指标,强大的
对一个复杂系统来说,监控是保证其正确工作必不可少的一部分;对各种各样的联网设备来说,监控是其存在的根本意义。附件以阿里云自研NoSQL数据库表格存储为基础,对大规模监控数据的存储和计算提供了一个建议的架构,并具体说明该架构如何演进以便进一步节约成本。
TableStore设计目标是快速读写简单的表数据,所以对单列大小限制在2M Byte(一次写入超大cell会引起系统波动),对大部分用户来说,这个值都是足够的,但是仍然有一些用户碰到了如下问题:用户自身绝大部分cell都能保证低于2M,按时有极个别的Cell高达20M,此时如果专门为这些大cell
随着软件架构的愈发复杂,借助强大的监控系统提高工作效率已经成为工程师的共识。监控系统会产生很多的监控信息,同时也要求对这些监控信息进行运算,此时就要求有一个扩展能力强、性能高的的存储系统来支撑监控信息的存储。本文以表格存储为例介绍NoSQL系统如何助力监控系统的构建。
这个文章用于保存某些技术文档,便于事后参考。
整体而言,Kudu似乎想做一个集合OLTP/OLAP的东西,在线写入,高可用,可选的一致性,即时快速的扫描分析,好嘛。大一统的产品能不能做成要打个问号,不过我个人倒觉得如果沿着这条路,MySQL类似的产品们希望更大。
表格存储(Table Store)是构建在阿里云飞天分布式系统之上的NoSQL数据存储服务,提供海量结构化数据的存储和实时访问。表格存储以实例和表的形式组织数据,通过数据分片和负载均衡技术,实现规模上的无缝扩展。应用通过调用表格存储 API / SDK 或者操作管理控制台来使用表格存储服务。
spanner的前身是big table,让我们先来看看big table这个老子的方方面面,然后再来看看儿子spanner为啥一出世就吸引了全球技术人员的眼球。 2006年,google 发表了big table [1]的文章,为什么要做big table,下面有一个简短的总结[2]: 就