eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

February 7, 2018

遇见未来 | 基于软件定义存储的数据加速解决方案:让你的系统加速跑

在互联网和大数据的压力下,很多企业面临着经济增长下滑、跨行业竞争激烈,用户需求越来越个性化。于是如何实现转型、业务创新和盈利增长成为企业的共同诉求。

而依靠硬件的提升获取系统性能大幅度提升的日子已经一去不复返。软件定义这么技术从提出到被广泛接受和利用,只用了短短几年的时间。其盛行的原因主要有以下几个方面:

1、降低系统复杂度:当前企业的IT系统变得越来越复杂,硬件种类繁多,系统交互频繁,通过软件交互可以降低复杂度;

2、降低成本在IT系统的成本中,硬件所带来的成本不仅包括系统本身所消耗的成本,更多的是随着系统变得庞大和复杂,需要的运营成本。

3、适应快速变化的市场环境:IT和业务的结合越来越紧密,业务的变化速度越来越快,IT系统的课伸缩性和适应性越发重要。通过软件定义计算,网络、存储是IT适应市场需求的基础条件。

4、支持创新:既包括IT创新也包括业务创新。例如通过软件定义的超融合架构,根据业务需要,可通过增加模块的方式增加计算能力或存储能力,用以支持大量并发的计算能力或存储能力。

作为软件定义的核心,软件定义存储则为存储行业带来了更多的可能。x86架构成为主流,不仅提供了相对廉价的计算资源,还带来了无与伦比的软件生态环境。

在本次遇见未来的专访栏目中,我们邀请了来自戴尔EMC的高级市场经理周俊杰先生,请他分享软件定义这门技术的发展现状及背景,以及戴尔EMC在软件定义存储方面所做的尝试和成果。通过基于软件定义技术的数据加速解决方案,让你的系统加速跑!

遇见未来---未来数据中心建设之软件定义专访

1、嘉宾介绍

周俊杰先生, 现任戴尔EMC大中华区企业级产品市场总监,负责服务器及相关解决方案的产品市场工作。出生于计算机家庭,从小受到计算机知识熏陶,加上在IT行业超过23年的经验中,曾经服务于奇虎360、浪潮集团、惠普等各大企业,在大客户销售,业务拓展,渠道管理,产品管理,市场营销,都有着丰富的经验。

2、软件定义存储的概念提出是基于什么样的背景,主要帮助用户在数据中心建设中解决什么样的问题和痛点?

传统的存储设备已经在行业里叱咤风云了近20年,回想起来,特别有意思的事实是:存储一开始也不是我们现在看到的传统存储设备的形态,从一开始居然也是"软件定义"的。一台服务器带着比较大的硬盘容量,通过一些标准的操作系统及功能软件的管理,就是存储设备了。通过提升客户的数据处理和保存能力,支撑着客户的数据库,邮件,文件,客户文档等业务的快速发展。随着网络技术的发展,专有形态的存储不断涌现。

而过去的10年的数据增长主要在于结构化的数据。 从2000年互联网泡沫破裂,到随着web2.0的出现再现辉煌,数据的增长也呈指数级的增长,各大公司分别作出至2020年的全球ZB级数据总和的预测,而增长的主要动力来源于非结构化化或者半结构化数据。

大部分传统存储主要为关键业务数据而设计,它的扩展性有局限,协议支持固有,数据存储类型单一,不够灵活,新技术的适配性较差,追随也较慢。面对新兴的应用场景,特别是当云,大数据等技术被用户广泛使用,传统的存储技术已经不太适合新兴的应用场景,这些场景典型的需求(相反就是痛点)包括:灵活扩展,跟新兴应用结合紧密,较低的成本,部署和管理简便,学习成本低,支持应用和存储融合,不受限于专有硬件,从闭源到开源软件的选择相对灵活,多协议支持适用多用途等特征。从2010年在行业内启动,经过6-7年的验证期,在2017年,软件定义存储的引爆点到来。

3、软件定义经历了哪些发展过程,目前的应用现状以及其最佳应用场,还面临哪些挑战?

软件定义的技术正被各行各业所看好,我们看到从传统行业中的金融,证券,电信,政府,医疗,教育,制造,物流等领域,原来越多的软件定义招标正在发生中。蓬勃发展的互联网行业早几年前,就已经开始了基于自行研发的软件定义技术的实践应用。我们认为从宏观上来看,云原生的应用,大数据的应用是软件定义存储的主战场。从具体应用角度,超融合,非结构化数据的存放及归档,多数据存储类型应用将是软件定义存储的典型应用场景。

目前在中国,客户的广泛认可度依然是一个主要挑战,特别是传统行业。软件定义存储还需要再经历几年的磨炼,形成各行各业的最佳实践,用事实说话,让用户信服。

4、软件定义存储相比较传统存储理念,有哪些主要的特点和优势?

部署和管理成本低,学习成本也低;多协议,多数据存储类型,支持超融合等多用途;扩展灵活,不受限于专有硬件设备;软件选择宽泛;基于对象的存储方面技术领先;技术迭代快,能第一时间利用到如非易失性内存,NVMe, RDMA等最新硬件技术。

5、软件定义存储如何实现数据保护,高可用和数据去重等

很多软件定义存储技术使用多副本,纠删码等技术来满足应用对数据高可用需求。

6、软件定义存储于存储虚拟化技术的区别?

方式不同,目的也不同。

SDS理论上可以运行在任何开放的工业标准服务器上,来提供一致性数据服务。即便是借助虚拟化软件,也是行业通用的Hypervisor。目的是把存储软件和硬件解耦合。具体好处如上所述。

而存储虚拟化技术一般来讲,是指通过定制的软件,运行在经过适配的专用存储硬件之上,通过网络,将原来多个不同的存储设备进行统一的一致性数据访问的池化技术。

7、现在软件定义的概念越来越火,在很多个领域都出现一些产品和解决方案,您如何看待软件定义技术的发展呢?

软件定义的归根诉求我认为来自企业自身的业务发展。有的企业为了业务效益最大化,有的为了生存,有的为了业务转型,他们加速数字化转型需求日益明显,而传统存储,传统网络等技术迭代较慢,基本以年为周期单位,甚至更长。这个大大落后于企业由于新业务的爆发或者老业务的技术改造而产生的对新技术能力的渴求。而软件定义的技术,将成倍缩短技术迭代周期。

打个比方,这个跟智能手机的迅速成为主流,而传统功能固化的手机迅速被淘汰的过程是相同的。因为智能手机硬件本身只是载体,而运行在上面的以月,以周为周期,不断迭代的APP所产生的能力才是用户所真正享受到的利益。同时软件定义技术能帮助企业在特定的业务上摆脱对专有设备的依赖和束缚。我们相信未来的数据中心将会越来越多的使用软件定义的技术,来成就企业的生存,发展和转型。

8、戴尔EMC在软件定义存储方面有哪些主要的产品和解决方案,以后的战略方向是什么样的呢?

DELL和EMC合并之后,整体软件定义存储产品形成了全面体系化的产品组合。

包括先前有的vSAN, XC系列,又增加了专门针对对象存储的Elastic Cloud System,专门针对块存储的Scale IO,专门针对数据保护的Data Domain Virtual Edition等。这些软件都可以运行在戴尔EMC的x86服务器之上,组成软件定义的存储,针对特定的客户应用场景,提供给客户多一种选择。

戴尔EMC一如既往地积极推动软件定义存储的发展,我们认为在将来的数据中心里,服务器将成为基石。在服务器的设计上,第一时间引入业内标准的,先进的,可靠的,高性价比的组件,赋能软件定义存储技术。

9、软件定义将会给企业带来什么样的价值?

增加业务的弹性,灵活性,提升业务效率;降低管理成本;降低企业业务数据风险;减轻IT选择风险。全面支持企业数字化转型。

基于软件定义存储的数据加速解决方案

未来统一的IT基础架构均是由软件定义的网络、存储、计算三大IT基础资源所构成的,并辅以自动化的运维。而在IT系统建设中,所有的核心都将围绕数据库展开。

zData light storage是云和恩墨开发的一种针对数据库领域的软件定义存储软件。最初只针对Oracle数据库,也即将支持MySQL等开源数据库。

其基本架构如下:

zData存储平台软件整合PC服务器,InfiniBand网络,传统的机械硬盘/SSD和闪存卡等开放平台硬件。为数据库提供分布的存储池。以满足高性能、高可用、易扩展等需求。

其分布式存储架构如下:

具有以下的特点和功能:

高性能:超百万IOPS,能很好地应对数据库场景下极端的性能需求;

安全性:2-3副本存储,应对去也最核心业务数据完整性和一致性的要求

扩展性:在线增加存储能力和计算能力,以满足业务交易量越来越大的需求。

推荐阅读(或了解产品详情,请加产品小助手微信:sunx5126):

加速Oracle RAC性能 软件定义存储的数据库云化实践

分布式存储解决方案zData

依托客户需求,打造场景化解决方案

zData方案在多个企业和单位有过最佳实践,以其高计算能力、高 I/O 能力、高可用能力、高可伸缩能力且极具稳健性的分布式存储架构,是具有高并发高IO需求的系统的最佳选择。在过去的实践中也得到证实和认可。

贵州交警

贵州交警某业务系统随着系统应用的深入和广泛,原有基础架构、数据架构规划和设计上的问题逐渐凸现出来,主要表现为业务数据爆炸增长、业务应用增多、系统响应缓慢、物理扩容达到瓶颈、设备达到服务年限。在经过zData一体机整合之后,整体用户体验得到了大幅改善,业务受理和办理效率均得到了用户赞誉。

性能提升效果:

1、整体性能提升18倍:重构前核心指标DBTIME每日最高单小时为3563.15,重构后每日最高单个小时指标为199.68,性能效果提升17.8倍。

2、I/O响应提升1000倍:重构前平均单次I/O请求时间为10.07毫秒,重构后平均I/O的请求时间缩短为0.01毫秒,I/O效率提升1007倍。

3、SQL性能提升117倍:考察违法审批报表SQL执行效率,重构前SQL执行需10206.1秒,重构后SQL执行完成只需87.07秒,执行效率提升117倍。

跨界与融合、机遇与挑战、个人与企业、现在与未来。让各行业、企业,以及每一个向未来而努力的人,听见时代最前沿的声音,见证成长!

Posted by enmotech at 8:02 AM | Permalink | Advanced (92)

February 5, 2018

对话张冬洪 | 全面解读NoSQL数据库Redis的核心技术与应用实践

互联网和Web的蓬勃发展正在改变着我们的世界,随着互联网的不断发展和壮大,企业数据规模越来越大,并发量越来越高,关系数据库无法应对新的负载压力,随着Hadoop,Cassandra,MongoDB,Redis等NoSQL数据库的兴起,因其良好的可扩展性,弱化数据库的设计范式,弱化一致性要求,在解决海量数据和高并发的问题上明显优于关系型数据库。因而很快广泛应用于互联网业务中。

Redis作为基于K-V的NoSQL数据库,具有高性能、丰富的数据结构、持久化、高可用、分布式、支持复制等特性。从09年至今,经历8年多的锤炼,已经非常稳定,并且得到业界的广泛认可和使用,同时社区非常活跃。

今天我们有幸邀请到了Redis中国用户组主席张冬洪老师,请他分享Redis的核心技术,应用现状及发展方向等。

遇见未来---DB舞台孰是王者之Redis专访

1、自我介绍,团队介绍

我是来自新浪微博研发中心的高级DBA 张冬洪,目前在微博带一个小组,主要负责微博平台、手机微博、话题、红包飞、开放平台、私信、以及内容管控项目的数据库产品运维和服务保障工作。工作中涉及的数据库产品主要包括MySQL、Redis、Memcached、MCQ、Kafka、Pika、Postgresql等。

2、目前您的团队工作重心是什么呢?

微博研发中心数据库部门主要负责全微博平台的后端资源的托管和运维,涉及的资源种类比较多,数据量比较大,业务线和资源实例数目也是非常之多,并发量巨大。而这些正是微博这种体量的公司应该具有的,微博作为当今中文社交媒体的第一品牌,拥有超过3.76亿的月活用户,也是当前社会热点事件传播的最主要平台,其中包括但不限制于大型活动(如:里约奥运会、朱日和沙场大点兵等),春晚,明星动态(如:王宝强离婚事件、女排夺冠、乔任梁去世、白百合出轨、TFBOYS生日、鹿晗关晓彤CP等)。

而热点事件往往具有不可预见性和突发性,并且伴随着极短时间内流量的数倍增长,甚至更多,有时持续时间较长。如何快速应对突发流量的冲击,确保线上服务的稳定性,是一个非常巨大的挑战和有意义的事情。为了达到这一目标,需要有一个完善的,稳定可靠的,健壮的数据库运维体系来提供支撑和管理,所以我们团队也是在领导的指导下,有目标、有计划的开展一些数据库自动化运维平台的建设工作。

在业余的时间我和其他几大互联网公司的朋友一起发起了Redis中国用户组(简称CRUG),也欢迎大家加入我们。

3、Redis在过去的版本演进中,比较重大的变化包括哪些呢?在最新4.0版本上,您认为最核心的变化是什么呢?您关注的新特性有哪些,可以简单介绍下吗?

我最早接触应该是在12年的时候,当时最新的版本应该是2.6.x。那个时候也没有在线上用,只是学习Linux的时候了解过。所以知道Redis的版本号命名规则借鉴了Linux的方式,版本号第二位如果是奇数,则为非稳定版本,如果为偶数,则为稳定版本。

这里我说下稳定版本的一些主要改进吧:

•Redis2.6

1)键的过期时间支持毫秒

2)从节点提供只读功能

3)服务端支持Lua脚本

4)放开客户端连接数的硬编码限制

5)去掉虚拟内存相关功能等

• Redis2.8

1)完善主从复制功能,实现增量复制

2)Redis设置明显的进程名,在系统中ps命令即可查看

3)发布/订阅添加pub/sub命令

4)Redis Sentinel第二版发布,较Redis 2.6更加完善,可以线上使用

5)可以通过config set命令设置maxclients等

• Redis3.0

1)推出Redis的分布式集群 Redis Cluster

2)全新的embedded string对象编码结果,优化小对象的内存访问,在特定的工作负载下能大幅度提升性能

3)LRU算法提升

4)config set 设置maxmemory的时候可以设置不用的单位

5)新的Client pause命令,在指定时间内停止处理客户端请求等

• Redis3.2

1)添加GEO功能

2)新的List编码类型quicklist

3)SDS在速度和节省空间上都做了优化

4)Lua脚本功能增强

5)新的RDB格式,仍兼容旧版RDB,同时加载速度上也有提升

6)Cluster nodes命令加速等

在Redis4.0版本上,我认为最核心的功能应该是支持了module,这极大的丰富的Redis的功能,使得许多Redis本身不具有的,第三方开发者拓展的功能也能加载到Redis中当一个功能进行使用,比如RediSearch、ReJSON、Redis-ML等。除此之外,还看到有很多新特性:

1)psync2.0,优化了之前版本主从节点切换必然引起全量复制的问题

2)提供全新的缓存剔除算法LFU,并对已有算法进行了优化

3)提供了非阻塞del和flushall和flushdb功能,有效解决了删除bigkey可能造成的Redis阻塞

4)提供了RDB-AOF混合持久化格式

5)提供memory命令,实现对内存的更为全面的监控统计

6)Redis Cluster 兼容NAT和Docker

7)引入Jemalloc库,优化内存访问等等

4、您能介绍一下Redis中的数据类型和它们的使用场景吗?

Redis之所以能够被广泛的应用于企业的架构中,而且是不可或缺的重要组成部分,也可以说是标配吧,其中很重要的一点就是得益于它具有丰富的数据结构,这也是它逐渐替代Memcached,备受青睐的重要原因。那么Redis都提供哪些数据类型呢?

相信对Redis有了解过的同学都知道,它的数据类型有:String、Hash、List、Set、Zset、Bitmaps、HyperLogLog、GEO等。

随着互联网的兴起和Redis技术的不断完善和发展,它已经被广泛应用于各行各业中,应用场景也是百花齐放。比如:会话缓存(Session cache)、全页缓存(FPC)、手机验证码、访问频率限制/黑白名单、消息队列、发布与订阅、消息通知、排名/排行榜/最新列表、计数器(比如微博的转评赞计数、阅读数(浏览数,视频播放计数)、博文数(发帖数)、粉丝数、关注数(喜欢商品数)、未读数(动态数))、共同好友/喜好/标签、推送、下拉刷新、私信、商品库存管理(限时的优惠活动信息)、证券指标实时计算,发号器/UUID、以及随着LBS(基于位置服务)的发展,加入的GEO(地理信息定位)的功能和基于Lua自定义命令或功能等等。大家在使用过程中,需要结合自己的业务场景,选择正确的数据类型。

5、Redis数据库有哪些主要的特点和优势?使用时有什么需要关注的点,可能会带来哪些问题,可否通过实践案例详细描述一下?

Redis作为基于K-V的NoSQL数据库,具有高性能、丰富的数据结构、持久化、高可用、分布式、支持复制等特性。从09年至今,经历8年多的锤炼,已经非常稳定,并且得到业界的广泛认可和使用,同时社区非常活跃,开发者又很严谨,这使得Redis版本非常精简,bug fix非常高效。根据similarweb.com的统计,中国Redis用户占全球Redis用户的40.96%,所以我们在使用的过程中遇到的问题,大部分可能都有解决方案。

需要关注的点比较多,之前在CRUG深圳站活动的分享中也提到过一些,下面举一些例子吧:

1)安全问题:Redis用非root用户启动,并且运行在内网,尽可能不要暴露在外网,配置认证requirepass xxx,减少被攻击的风险;开启危险命令认证(keys-need-auth yes rename-command KEYS MY_KEYS)

2)容量问题:合理评估;合理使用内存分配策略(no-enviction、allkeys-random、allkeys-lru、volatile-random、volatile-ttl、volatile-lru);检查是否有内存碎片;选择合适的服务类型(Redis cluster或者pika);水平拆分;性能满足的条件下选择诸如ziplist类的内部编码

3)big-key问题:可能会引起慢查或者带宽瓶颈,按照业务逻辑拆成小key或者业务解耦剥离big-key或直接改用其他存储方式

4)hot-key问题:Redis是单进程,节点实例很容易成为系统的短板,垂直扩容;增加local cache;如果只是简单的k-v结构,可以考虑使用Memcached

5)使用姿势问题:避免使用阻塞操作(如:flushall、flushdb、keys *等);尽量使用Pipeline,减少syscall带来的网络IO,但要注意限制数据量大小;对多个元素操作时,像使用SORT、LREM、SUNION,计算复杂度为O(N), 避免线上乱用;尽可能使用最新的版本

6)Key过期问题:合理设置过期时间;如果存在许多该过期的key而没被及时删除,可以通过命令scan、hscan、sscan、zscan、keys *遍历一遍key的方式实现

7)配置上:建议开启tcp-keepalive,tcp-backlog,从库设置readonly yes

8)系统设置:关闭NUMA;关闭transparent _hugepage; 关闭swap

等等,大家有问题的时候可以相互交流。

6、Redis如何做消息队列?

Redis做消息队列,有两种实现方式:

第一种:通过数据结构List来实现

优点:能够实现持久化;支持集群;接口使用简单

缺点:

  • 如上图所示,一条消息只会被一个消费者消费,所以不存在有多个消费者消费一条消息

  • 生产者和消费者的高可用或崩溃后的处理机制需要自己实现

  • 当生产者消息写入太快,消费者消费太慢,则有可能会导致内存溢出问题,导致进程crash

第二种:通过pub/sub来实现

优点:

一个生产者可以对应多个消费者,但是必须保证消息发布者和消息的订阅者同时在线,否则,否则一旦消息订阅者由于各种异常情况而被迫断开连接,在其重新连接后,其离线期间的消息是无法被重新通知的(即发即弃)。当然,生产者不需要关心有多少的订阅者,也不用关心订阅者的具体信息,而订阅者可以根据需要自由选择订阅哪些频道:支持集群;接口使用简单等。

缺点:

  • 没有持久化机制,属于即发即弃模式,因此也不需要制定消息的备份和恢复机制

  • Redis没有提供保证pub/sub消息性能的方案

  • 当大量的消息到达Redis服务时,如果订阅者不能及时完成消费,则就会导致消息堆积,引发上面一样的内存问题

7、您可以介绍下当前Redis的集群功能和实现吗?

要了解Redis的集群功能,可以从数据分片、数据迁移、集群通讯、故障检测以及故障转移等方面进行了解,Cluster相关的代码也不是很多,注释也很详细,可自行查看,地址是:https://github.com/antirez/redis/blob/unstable/src/cluster.c。

这里由于篇幅的原因,主要从数据分片和数据迁移两方面进行详细介绍:

  • 数据分片

Redis cluster在设计中没有使用一致性哈希(consistency hashing),而是使用数据分片(sharding),引入哈希槽(hash slot)来实现;一个 redis cluster包含16384(0~16383)个哈希槽,存储在redis cluster中的所有的键都会被映射到这些slot中,集群中的每个键都属于这16384个哈希槽的其中一个,集群使用公式slot=CRC16(key)/16384来计算key属于哪个槽,其中CRC16(key)语句用于计算key的CRC16 校验和。

集群中的每个主节点(Master)都负责处理16384个哈希槽中的一部分,当集群处于稳定状态时,每个哈希槽都只由一个主节点进行处理,每个主节点可以有一个到N个从节点(Slave),当主节点出现宕机或网络断线等不可用时,从节点能自动提升为主节点进行处理。

如上,clusterNode数据结构中的slots和numslots属性记录了节点负责处理哪些槽。其中,slot属性是一个二进制位数组(bitarray),其长度为16384/8=2048 Byte,共包含16384个二进制位。集群中的master节点用bit(0和1)来标识对于某个槽是否拥有。比如,对于编号为1的槽,master只要判断序列的第二位(索引从0开始)的值是不是1即可,时间复杂度为O(1)。

集群中所有槽的分配信息都保存在clusterState数据结构的slots数组中,程序要检查槽i是否已经被分配或者找出处理槽i的节点,只需要访问clusterState.slots[i]的值即可,复杂度也为O(1)。clusterState数据结构如下所示:

查找关系如下图:

  • 数据迁移

数据迁移可以理解为slot和key的迁移,这个功能很重要,极大的方便了集群做线性扩展,实现平滑的扩容或缩容。

那么它是一个怎样的实现过程呢?

下面举个例子:现在要将Master A节点中的编号为1、2、3的slot迁移到Master B节点中,在slot迁移的中间状态下,slot 1、2、3在Master A节点的状态表现为MIGRATING,在Master B节点的状态表现为IMPORTING。

MIGRATING状态

这个状态如上图所示是被迁移slot在当前所在Master A节点中出现的一种状态,预备迁移slot从Mater A到Master B的时候,被迁移slot的状态首先变为MIGRATING状态,当客户端请求的某个key所属的slot的状态处于MIGRATING状态的时候,可能会出现以下几种情况:

1)如果key存在则成功处理

2)如果key不存在,则返回客户端ASK,客户端根据ASK首先发送ASKING命令到目标节点,然后发送请求的命令到目标节点

3)当key包含多个命令时:

  • 如果都存在则成功处理

  • 如果都不存在,则返回客户端ASK

  • 如果一部分存在,则返回客户端TRYAGAIN,通知客户端稍后重试,这样当所有的key都 迁移完毕的时候客户端重试请求的时候回得到ASK,然后经过一次重定向就可以获取这批键

此时并不刷新客户端中node的映射关系

IMPORTING状态

这个状态如上图所示是被迁移slot在目标Master B节点中出现的一种状态,预备迁移slot从Mater A到Master B的时候,被迁移slot的状态首先变为IMPORTING状态。在这种状态下的slot对客户端的请求可能会有下面几种影响:

1)如果key不存在则新建

2)如果key不在该节点上,命令会被MOVED重定向,刷新客户端中node的映射关系

如果是ASKING命令则命令会被执行,从而key没在被迁移的节点,已经被迁移到目标节点的情况命令可以被顺利执行。

键空间迁移

这是完成数据迁移重要的一步,键空间迁移是指当满足了slot迁移前提的情况下,通过相关命令将slot 1、2、3中的键空间从Master A节点转移到Master B节点,这个过程由MIGRATE命令经过3步真正完成数据转移。步骤示意如下:

经过上面三步可以完成键空间数据迁移,然后再将处于MIGRATING和IMPORTING状态的槽变为常态即可,从而完成整个重新分片的过程。

8、请您简单介绍下Redis的高可用方案,如果可以,结合您的实践经验和案例进行分析

根据业务的规模以及Redis使用环境的不同,Redis的高可用方案也比较多。这里举一些例子说明一下业界比较常用的一些方案吧。需要说明一下的是下面的这些方案不涉及到同城多活或异地多活的场景,但是部分方案能够做到跨数据中心的灾备。

•Keepalive + Redis

•Redis Sentinel

•Twemproxy + Redis Sentinel + Redis

•Redis Cluster

•Redis Sentinel + Proxy + Zookeeper + Redis

•Zookeeper + MySQL + Redis + DNS

9、Redis数据库在向着自动化运维的方向发展的过程中,面临的最大的挑战是什么?如何克服?

如果不强调"最大的"话,我知道有不少的挑战,哈哈。

我想最大的挑战应该是"智能化"吧。现在业界都在追捧DevOps、AIOps,那么在Redis的自动化运维过程中,也需要学习行业的先进思想,结合部门自身的实际稳扎稳打,逐一突破。

首先在智能化实现之前,我们要尽力实现下面的一些需求:

1)数据库运维自动化平台的建设,为RD和DBA提供较全面的自助服务和数据库管理功能

2)工单事件关联任务系统,一键完成自动安装部署,添加产品线和报警

3)海量报警智能分类(比如按产品线或按DBA分类),实现部分报警故障自愈 (比如:从库readonly设置、内存使用率超过95%自动扩容)

4)基于队列分布式批量部署,可横向扩展,任务异步调度,满足大规模部署、扩容的需求

5)日志实时展示,监控数据实时采集,图形化多维度展示,满足可视化的需求

6)RedisHA支持秒级响应,实现故障无缝切换,满足高可用的需求

7)缓存弹性扩缩容(利用私有云和公有云,结合Docker容器化技术实现),满足对热点的快速应对

8)内部开发了各种通用的管理和运维脚本,化繁为简,提高工作效率

9)根据历史/晚高峰资源的性能指标设置水位线,和报警阈值,提供决策支持

10)在Redis集群、容灾、异地多活(跨数据中心数据同步)、微服务等等方面还需要花很大的力气去建设,目前依旧比较欠缺

智能化的实现还需要持续的投入和迭代。

10、近几年随着大数据时代的到来,NoSQL数据库在处理海量数据上表现出越来越多的优势,请问您如何看待数据库的未来,会朝着什么样的方向发展?

是的,这几年从运维的角度看,明显能感觉到数据体量上的膨胀,一个实例动不动就几十G,一个集群动不动几百G、几T,甚至更多。以Redis为代表的NoSQL数据库在处理这方面的表现还是令人非常满意的。它的高性能表现得淋漓尽致,从微博的业务来看,Redis实例每天承载着千亿级的写QPS、万亿级的读QPS,数据量TB级,确实没有Redis,且不说能不能用关系型数据库存储,单是硬件成本就几何倍增长了吧。

未来,随着硬件成本的降低,硬件性能优化的极致,比如PCIE、25GE网络的升级,一定是软硬结合,会出现更多的Redis的相关产品和服务。包括收费的Redis Enterprise,Cloud Redis等,也包括开源的Pika、TiDB等NewSQL。正如阿里云的同学所说,"数据库终极是九九归一 -- 量子数据库",一起期待吧。

11、对于初学Redis的同学,您有什么好的学习方法和技巧给他们吗?

首先当然还是需要多看官方文档,多看看业界大牛的技术博客。其次可以买几本书对比着学习下,目前市面上的相关书籍也就4,5本的样子。然后主要的还是要多动手,实践出真知,在使用的过程中,还是要结合具体的业务场景,灵活使用。有能力的时候,看看源码,了解底层的实现原理。最后,多思考多总结,好记性不如烂笔头,每一次踩坑都是一次成长,遇到解决不了的问题的时候多向业界大牛们请教学习,平时多关注一些业界相关技术的最新动态。

12、您如何看待Redis的未来?从技术和非技术的多个维度,您如何看待Redis的发展方向

纵观Redis的发展,无独有偶的与互联网的发展浪潮紧紧相随,从web1.0到web2.0的转变,从博客、贴吧、论坛到社交媒体,从文本到图文再到短视频的兴起,从互联网到移动互联网,从3G到4G到即将普及的5G,从异军突起的新兴产业,如:团购、电商、外卖、旅游、游戏、互联网金融和证券、出行和直播等等,商业模式在不断的改变,不断的在刷新人们的生活方式。

但是在这些变化的背后,不变的是Redis作为基础服务为企业的高可用架构保驾护航,变化的是Redis的使用案例越来越丰富、服务体验越来越好。在Redis的发展过程中,由于企业需求的多样化,对Redis的要求越来越高,许多场景Redis的功能显得相形见绌,因此出现了诸如Codis、Pika、CounterService、ApsaraCache、CacheCloud、smartClient(Redisson)等产品,它们是对Redis的有益补充。

随着4.0版本module功能的推出,使得Redis拥有更多的想象和发展空间,在全文索引(RediSearch),AI(Redis-ML)、云计算、大数据、物联网、人工智能、BlockChain等领域,模块化的融合能力将极大的丰富Redis的功能,从而为企业构建更为多元化、立体化的数据库使用方式。

13、您还有什么想要分享的吗?

在使用Redis的过程中,还需要保持关注官方的动态,多看看github上的changelog和issue,因为随着Redis的用户群体的增多,使用场景的复杂化,Redis自身隐藏的问题或瓶颈也会暴露出来,这样有助于我们避免踩一些不必要的坑,及早规避一些风险。

不仅仅是Redis,学习其他的数据库也是一样的。另外,我们在关注Redis本身以外,还需要关注一些其他的Redis的替代产品(比如:SSDB、Pika、Codis、ApsaraCache、TiDB等),Redis的周边工具(如:redis-migrate-tool、redis-faina、redis-audit、redis-rdb-tools、RedisMyAdmin等)、中间件(如:twemproxy、corvus、redis-cerberus)等。如果你想要从事Redis的开发,那么你可能需要关注的更多,比如各种锁的实现。

跨界与融合、机遇与挑战、个人与企业、现在与未来。让各行业、企业,以及每一个向未来而努力的人,听见时代最前沿的声音,见证成长!

Posted by enmotech at 7:52 AM | Permalink | Advanced (92)

February 2, 2018

遇见未来 | 超融合如何兼顾企业的"敏态"和"稳态"的业务需求

超融合的概念自2012年被提出到现在,经历了6年的时间。其技术已经从最初的以存储的融合为重点,经历过计算、存储、网络的全面融合,到现在,重心落在云计算平台的交付,整个技术趋于成熟。

今天我们有幸邀请到青云QingCloud青立方产品总监廖洋(Lester)老师,请他分享青云在超融合的技术和产品上所做的一些尝试,我们一起来学习超融合的发展现状和未来方向,以及超融合是如何兼顾企业的"敏态"和"稳态"的业务需求的。

遇见未来---未来数据中心的建设战略之超融合


1、自我介绍,团队介绍

廖洋(Lester Liao),青云QingCloud青立方产品总监。15年IT行业从业经验,专注于存储及云计算产品,对超融合系统、SAN存储、分布式存储系统、虚拟化、云计算等领域有较深入的研究。

目前团队的工作重心主要在青云QingCloud的硬件产品线--"青立方",包括青立方超融合一体机、青立方对象存储一体机和青立方NeonSAN一体机等。团队涵盖以上产品线的硬件设计、云平台及存储集成、测试与服务等产品技术人员。

2、作为超融合领域资深的专家,请您简单介绍下超融合技术的发展历程和现状,它主要帮助用户在数据中心建设中解决什么样的问题和痛点,以及其最佳应用场景

超融合(HCI :HyperConverge Infrastructure)最初是借鉴了Google、Facebook等互联网公司的技术,通过产品化的包装,导入到企业级IT市场。2012年美国Nutanix公司提出超融合的概念至今已有6年的时间。

市场上的超融合产品至今也经历了三个阶段的发展。

  • 第一个阶段,融合1.0。重点在存储:以Nutanix为例,其产品刚推向市场的时候主要强调其分布式存储技术。从技术本身来看并没有什么创新,而主要的创新其实是在其部署架构上,即将VMware的虚拟机与分布式存储部署在相同的服务器上。这一阶段的主要价值是帮助用户从传统的集中存储架构切换到以软件定义存储为核心的分布式存储架构,简化了存储管理的复杂性,提高了存储的可扩展及利用率,从而降低了存储成本,并且在某些特定的场景中提供比集中存储更高的性能和可用性。

  • 第二个阶段,融合2.0,重点在于计算、存储、网络的融合,即将数据中心基础架构的三大件----计算、存储、网络实现软件定义,通过软件+通用服务器的方式,在同一个架构里进行交付。这一阶段的主要价值是:简化了用户对IT的管理,从计算、存储、网络三个层面实现横向扩展。

  • 第三个阶段,融合3.0,重点在于云计算平台的交付,实现应用(PaaS、SaaS等企业级应用)的横向扩展。青云QingCloud在2015年发布超融合产品时,就强调超融合不仅是计算、存储、网络等资源层面的问题,还要交付完整的云计算。

在第三个阶段以前,业界普遍认为超融合仅适用于面向互联网、横向扩展的分布式业务,而一些传统应用很难构建在超融合架构上。但是青云QingCloud提供的超融合一体机积累了大量公有云的实践经验,融合了多种创新技术来解决扩展性问题。

  • 在存储层面,青云不仅提供分布式存储(SDS 2.0),也提供NeonSAN共享块存储;

  • 在计算层面,青云不仅提供虚拟主机和容器主机,还提供物理主机,在统一架构上满足应用对基础架构的所有需求;

  • 在应用层面,QingCloud AppCenter能够实现应用的横向扩展。

这也是全模云的概念,即面向企业兼顾"敏态"和"稳态"的需求,为分布式和集中式业务架构进行云端部署提供一体化解决方案。企业用户可以根据自身业务特点灵活选择不同类型的云端资源,构建灵活、敏捷、高效的全模式业务系统,并实现统一管理。

3、超融合给用户带来的主要价值是什么呢?
  • 降低基础架构复杂度,易于管理;

  • 采用横向扩展方式,易于扩展;

  • 采用通用硬件,可降低成本;

  • 更加适合承载云计算业务,提高了性能;

  • 支持全模云,兼顾企业"敏态"和"稳态"的业务需求。(青云QingCloud独有的价值)

4、目前市面上比较流行的超融合技术派系及其优缺点分析

  • 第一类是传统IT厂商,他们的产品更关注硬件层面的融合,软件层面一般采用开源技术,缺乏自己的核心技术;

  • 第二类是专注软件定义存储的IT厂商,他们将以往的软件存储方案加上计算,以超融合一体机的形式交付。但是产品成熟度较差,在功能、可扩展性和稳定性上还有待提升;

  • 第三类是云计算厂商,把云计算技术,通过超融合一体机的形式,形成私有云的交付。以青云QingCloud为例,从软件层面来看,不管是公有云、私有云还是混合云,青云QingCloud采用统一的代码、自研的技术,核心代码自主可控。因此无论从需求自定义还是产品更新迭代的能力上,都优于开源软件。从硬件层面,青云QingCloud对底层硬件持开放态度,兼容各种主流硬件,不存在硬件绑定。成熟度、稳定性,自研、定制化,兼容性,技术演进路线清晰。

5、目前超融合技术涉及到的似乎都是IaaS层面,也就是都只在基础架构上,那么未来会朝着什么方向发展呢,会上升到PaaS层吗?

上面融合3.0里有提到应用层面的扩展,不仅是PaaS,也有SaaS,主要通过QingCloudAppCenter实现。

6、在IT的管理维护上,数据架构的高可用与安全总是备受关注的两个问题,请您简单介绍下贵公司的超融合产品在实现高可用和数据保护上,都有哪些具体的方案,达到的效果如何?

首先从管理架构上看,青云QingCloud支持计算、存储与管理节点分离的部署模式,从而在高可用和安全性上达到高可靠性。其次是P2P运维机器人系统,能够自动处理各类硬件故障、数据中心级的灾难等。此外,青云的高可用和数据保护可以细致到"卷"的级别,这是很多超融合厂商无法做到的。同时,青云QingCloud支持各种容灾级别,如同步复制、异步复制、同中心三副本、异地副本等,都可以自定义。

7、在您看来,超融合技术会朝着什么样的方向发展呢? 在贵公司下一步产品在超融合这些方面进行哪些优化?

接下来,青立方超融合一体机将做到更精简的交付。我们现在最小可以做到两台服务器交付,未来从交付规模上会做到更小的集群交付。随着业务规模的不断扩展,能够从1-2台的小规模扩展到上百万台的大集群,或者从易捷版(Express)扩展到高级版、企业版,都是完全平滑的过渡方式。为企业提供从基础的计算虚拟化到企业级的私有云,一条完整通畅的数字化转型路径。

跨界与融合、机遇与挑战、个人与企业、现在与未来。让各行业、企业,以及每一个向未来而努力的人,听见时代最前沿的声音,见证成长!

Posted by enmotech at 6:44 PM | Permalink | Special (40) | System (105)

遇见未来 | 对话叶毓睿:人类文明运行在软件之上

互联网及其延伸,正在导向我们走向一个新的时代,软件技术在新一轮革命技术中毫无疑问是核心竞争力之一。C++语言发明人Biarne Stroustrup说,人类文明运行在软件之上,也突出了软件技术的重要地位。

什么是软件定义?软件定义在企业的数据中心中的表现是什么?如何发展这项技术?今天我们有幸邀请到了VMware存储架构师Peter Ye(叶毓睿),分享他关于软件定义存储的深刻见解。

遇见未来
未来数据中心建设战略之软件定义专访

作者及其团队介绍

1

PeterYe(叶毓睿),现任VMware存储架构师,《软件定义存储:原理,实践与生态》作者,《VMware软件定义存储:原理剖析和设计指南》译者。曾任职于EMC、Compellent、DELL,对存储行业的历史发展和未来趋势有着深入的了解。Peter同时也是"乐生活与爱IT" 微信公众号的作者。

软件定义存储的概念提出是基于什么样的背景,主要帮助用户在数据中心建设中解决什么样的问题和痛点?

2

软件定义存储(SoftwareDefined Storage,简称SDS)的首次提出是在2012年8月VMworld大会上,此次大会同时提出了软件定义的数据中心(Software Defined Data Center,简称SDDC),SDS是SDDC的五大组成部分之一。

我在《软件定义存储:原理,实践与生态》一书中,曾指出:软件定义的存储(SDS)是一个不断进化的概念,在现阶段看来,是指存储资源由软件自动控制,通过抽象、池化和自动化,将标准服务器内置存储、直连存储,外置存储,或云存储等存储资源整合起来,实现应用感知,或者基于策略驱动的部署、变更和管理,最终达到存储即服务的目标。

用户在传统数据中心建设中,大多是烟囱或竖井架构,也就是每上一套业务应用,需要申请和采购包括服务器、网络和存储在内的IT基础架构硬件,这使得用户在数字化转型的时代,IT基础架构的资源无法共享,存储资源无法动态扩展,即刻交付。SDS是在虚拟化已经渗透到各行各业,云计算逐渐普及的大环境下,孕育而生的。

软件定义经历了哪些发展过程,目前的应用现状以及其最佳应用场,还面临哪些挑战?
3

软件定义为云而生,通过抽象、池化、自动化等步骤,实现IAAS(基础架构即服务),帮助用户共享计算网络和存储资源池,并能实现动态扩展,即刻交付和方便地变更资源,以动态地适应某一业务在不同时间段对于资源的SLA(服务等级协议)的要求。

目前SDS包括分布式存储,分布式存储有两种部署形态,一种是计算和存储相分离的,另一种是计算和存储融合在同一个物理服务器节点上,也即超融合基础架构。分离部署的方式,在大规模存储资源池化,存放非结构化数据(如文档,图片,音视频等)的场景中,应用较为广泛。而超融合架构中,较多使用的场景包含VDI、集群管理、ROBO(远程分支办公室)、开发测试、备份与灾难恢复。除此之外,由于VMware vSAN依托于vSphere ESXi这一稳定可靠的Hypervisor,并且自身拥有故障域、双活(延伸集群)、而且支持vMotion/HA/FT等功能,使得越来越多的用户将关键应用(如Oracle RAC、SAP、SQL Server等)放在了VMware vSAN上,根据2016年的数据统计,有64%的vSAN用户,将其关键应用放在vSAN上。

软件定义存储相比较传统存储理念,有哪些主要的特点和优势?

4

在数据平面层涌现出可以采用基于标准商用硬件(如X86服务器)的分布式存储或者HCI,降低了成本;控制平面层向上提供了存储自动化(如存储策略驱动)的资源部署和变更方式,使得云计算所需的存储资源即刻交付成为可能。软件定义存储中的大类:HCI使得数据靠近计算,能让SSD的性能发挥得淋漓尽致,性能更高,延时更低。

软件定义存储的技术如何解决传统存储的挑战:信息孤岛,供应商绑定,扩展性的问题的?

5
  • 第一步是抽象,也即解耦,因为如果硬件被锁定,存储资源无法被灵活调用;

  • 第二步是池化,也即虚拟化,这样才能随需分配,动态扩展;

  • 第三步是自动化,存储资源由软件(Hypervisor或云管理软件)来自动分配和管理。

经由抽象、池化和自动化,打破了信息孤岛,也不再被供应商绑定,并支持动态扩展的。

软件定义存储如何实现数据保护,高可用和数据去重等?

6

在数据平面层的分布式存储或者HCI,大多是通过类似互联网分布式计算,也即多副本的方式来提供数据冗余,另外也有通过双活(如vSAN 延伸集群)来提高可用性。为了解决存储利用率,也有采用EC(纠删码)和去重压缩的技术。

软件定义存储与存储虚拟化技术的区别?

7

软件定义存储包含了存储虚拟化,简单理解,可以认为软件定义存储=存储虚拟化+自动化,其实就是SDS的三步曲:抽象、池化和自动化。详见《什么是存储虚拟化?它与软件定义存储有何区别?》

软件定义存储与软件定义网络有哪些共性,前者受到后者哪些影响?

8

都包含了控制平面和数据平面。软件定义这个词汇最早就是来源于软件定义网络(SDN),核心是控制平面和数据平面解耦,SDS在这一部分上收到了SDN的影响。

现在软件定义的概念越来越火,在很多个领域都出现一些产品和解决方案,您如何看待软件定义技术的发展呢?软件定义网络,软件定义计算,软件定义数据中心,这真的会是数据中心的未来吗?

9

软件定义的出现,是虚拟化已经渗透,云计算逐渐普及的大环境下,对于基础架构层的迫切需求,打破了以往烟囱或竖井架构,使得资源能够池化并自动化地被部署。迄今为止,云计算,尤其是私有云的最佳实践方式就是软件定义的数据中心,而且这个过程会持续很长时间,直至用户迈向混合云。因此,毫无疑问,SDDC是数据中心的未来。

有人说,人类文明终将会运行在软件之上,那么对于硬件厂商来说,面临什么样的挑战和机遇呢?如何正确地认识软件和硬件的关系,以及硬件在未来数据中心的地位?

10

人类的文明运行在软件和硬件结合的环境之上。实际上,正是因为硬件技术的突飞猛进地发展,才使得软件定义有了腾挪的空间。早期,为了大规模生产,降低制造的复杂度和成本,许多功能都固化在硬件里,我们可以称之为硬件定义。随着日益增长的灵活性、自动化、多样化、个性化定制的需求,由软件来操控硬件资源的情况将越来越多、越来越广。然而,软件操控硬件的前提是,硬件的能力(例如性能、容量等)需要有富余。所以,硬件发展越快,软件定义的发展才会更有潜力。另外,软件的发展反过来也会影响硬件的发展,例如虚拟化软件对芯片指令集的影响,分布式存储软件对网络的影响。

软件定义技术的发展与企业IT系统的云化有什么样的关系,软件定义将会给企业的云战略,或者云战略会给软件定义数据中心带来什么影响?企业该如何正确地看待未来数据中心的变革与方向?

11

前面提到,软件定义为云而生。所有企业,在云战略上,如果考虑混合云或者私有云,都必须认真思考如何利用现有的最佳实践,也即软件定义的数据中心来使云战略落地。

VMware在软件定义存储方面有哪些主要的产品和解决方案,以后的战略方向是什么样的呢?
12

VMware的软件定义存储主要分为两大部分,如下图所示。

1)控制平面,即Storage Policy Based Management(基于存储策略的管理),简称SPBM。

数据平面,即Virtual DataServices。分别有三个子类构成:Virtual SAN,VirtualVolumes和Cloud/Object Storage。

软件定义将会给企业带来什么样的价值?
13

降低成本、提升性能、管理简单灵活、扩展方便、即刻交付符合一定SLA标准的存储资源。

在目前的市场上,软件定义存储有很多不同的解决方案,这些方案在系统架构设计和实现上有很大的不同之处,那么未来会朝着什么样的方向发展呢?
14

未来可能出现的软件定义存储,可大致分为如下六类:

1)与Hypervisor融为一体的SDS厂商,也即前述的VMware、Microsoft等。

2)与应用融为一体的超融合架构设备,通常俗称一体机。

由于针对某一类特定业务,其工作负载相对固定,也比较容易在存储曾针对这一特点进行优化,例如针对数据库的有:云和恩墨、天玑数据、沃趣(已被华胜收购)、成都文武信息等;针对VDI的一体机;针对SAP的一体机;并行数据库一体机 (如MonDb), 数据分析一体机 (Greeplum),也许未来还会有针对Exchange的、针对SQL Server的一体机;从业务应用来看,也许还会有针对视频监控,针对媒资管理等,针对某一行业的某一类应用。

3)拥有某一项或几项出色功能的新SDS厂商。虽然没有与Hypervisor或者应用融合。但靠着它的独特或先进的功能,依然赢得用户的青睐;

4)针对云平台或者Hypervisor生态链,专注某垂直领域的SDS厂商,例如针对AWS的SoftNAS,针对vSphere的Tintri;现阶段针对Hypervisor进行拓展和优化的,应该有不少生存空间;针对公有云的,可能在晚些年陆续出现更多的初创厂商。

5)传统外置磁盘阵列的转型尝试,如HP StorVirtual、EMC vVNX、NetApp OnTap Edge等。

6)云计算公司的的转型尝试,如公有云提供商青云推出超融合一体机等。

7)包括冷存储在内的对象存储。

初期,必须围绕着数据平面下功夫,提供稳定性和可靠性,甚至可能针对业务应用进行优化;将来,数据平面同质化后,应该开始向控制平面层对接,以更好的为存储自动化服务。

跨界与融合、机遇与挑战、个人与企业、现在与未来。让各行业、企业,以及每一个向未来而努力的人,听见时代最前沿的声音,见证成长!

Posted by enmotech at 6:42 PM | Permalink |

遇见未来 | 对话朱贤文:PostgreSQL是一匹即将发力的黑马

在2017年的DB-Engine的年度数据库榜单上,PostgreSQL以其超过其他341个受监控数据库管理系统的受欢迎程度居于榜首,被评为年度DBMS。其总体排名也超过MongoDB,在其流行程度上排名第四。

PostgreSQL是DB领域的一匹黑马,之前一直默默活在MySQL的阴影之下,今年随着 10.0版本的发布,Declarative Partitioning的引入,改进的查询并行性,逻辑复制和同步复制的Quorum Commit ,PostgreSQL 10 的影响力在不断的增强。

今天我们有幸邀请到了PostgreSQL的专家朱贤文老师,为我们分享PostgreSQL的核心技术、发展现状及未来方向。

遇见未来
DB舞台谁是王者之PostgreSQL专访

1、自我介绍,团队介绍

我是朱贤文,是成都文武信息技术有限公司的总经理、创始人。我入IT行业接近20年,主要熟悉数据库、存储和集群这些IT基础架构比较底层的技术;在这之前,曾在Oracle,Veritas,IBM等公司工作,做研发的经验主要在Oracle RAC和Storage和集群,涉及的技术比较底层。

我们是一个创业团队,现阶段不到20人,我们专注在PostgreSQL数据库的商业解决方案及和技术服务,产品和方案;比如集群、容灾、备份,咨询等。

我们有一套自研的专门用于数据库的高性能私有云系统,支持PostgreSQL和Oracle数据库高效可靠地运行。

2、作为PostgreSQL领域资深的专家,请您简单介绍下PostgreSQL技术的发展历程

实在不敢当专家的称号,我只是对PostgreSQL熟悉一点罢了。

PostgreSQL是一个非常先进的、有很多高级特征、企业级功能非常丰富的开源数据库,在金融、银行、电信、生产制造等行业有非常多的成功案例。

PostgreSQL的发展历程

PostgreSQL的前身是美国国防部与UC Berkeley大学合作的一个研究项目,叫Ingres,起源于1973年;1985年研究项目终止,随后开源,并且命名叫Postgre,随后又改名为Postgre95;1996年因为加入了完整的SQL92标准支持,为了强调对SQL的支持,所以更名为PostgreSQL,这个名字一直沿用到现在。到目前为止,其连续活跃的开发历史已超过32年,算上Ingres时期的开发历史,项目实际上接近45年连续开发。

PostgreSQL的发展,经历了几个重要的版本

  • 从8.0开始,逐渐增加了众多的企业功能,包括写日志,表分区,物理同步复制,物理异步复制,逻辑复制,在线热备份,并行查询。

  • 目前最新版本为10.1,完善了表分区和hash表功能。

PostgreSQL的特点

  • PostgreSQL数据库的跨平台特性非常强,支持几乎所有的操作系统和CPU硬件平台,如AIX,HPUX,Linux,BSD,Windows等。

  • PostgreSQL的开发是由社区驱动的,各种高级先进的特性主要来自于用户的反馈和需求;社区的成员来自于全球的商业公司,高校,研究机构等,开发和发行过程非常严谨,产品代码质量非常高。目前国内有很多公司基于PostgreSQL数据库开发自己的商业产品。

还有一些明显的特点包括:比如非常丰富的数据类型,丰富的开发接口和编程语言的支持,丰富的索引类型,很多的企业级高级特性等等,都能够满足绝大多数企业级应用的要求。

PostgreSQL的发展

PostgreSQL数据库的支持跟商业数据库一样,从6.3开始,每一个发行版本社区都会支持5年,这个传统从1998年开始,马上也进行了20年了。

从国内使用情况来看,现在PostgreSQL的影响力越来越强,越来越多的专业用户将PostgreSQL用在他们的业务系统中,比如中国平安,中国移动,联通,互联网包括去哪儿,腾讯,阿里。

从生态区和支持这个方面来说是越来越完善,现在有华为,腾讯,阿里以及我们成都文武信息在内的专业公司,对其提供商业支持和服务,并且基于它开发自己的高性能数据库。

3、在PostgreSQL 10版本中,您最关注的新特性和技术点包含哪些?或者您认为最重要的变化?

PostgreSQL 10版本中,新的特性比较多,下面只列出部分,详细的部分可以参考官方Wiki:https://wiki.postgresql.org/wiki/New_in_postgres_10

  • 大数据处理:原生分区,并行执行,FDW下发/push-down,更快的查询支持;

  • 复制和很横向扩张:逻辑复制,同步复制实现Quorum Commit-类Raft的部分功能,临时复制slots支持,连接层的failover和routing,加强的物理复制;

  • 系统管理:pg_receivewal支持压缩,pg_stat_activity有了专门的后台处理进程等;

  • SQL功能:Identity Columns,Crash Safe,Replicable HashIndexes,Transition Tables for Triggers;

  • XML和JSON:支持XMLTable,JSON和JSONB的全文搜索

4、PostgreSQL 的最佳应用场景是什么?有哪些比较成功的案例实践?目前市场需求如何?

个人认为PostgreSQL适合对性能、可靠性、业务连续性要求非常高的企业级OLTP应用,以及小规模OLAP应用,比如数据量小于50T的OLAP系统。

现在国内可以参考的案例还是非常多,比如平安集团有1500多个实例部署;乐友母婴用品店,核心的数据库系统是一个接近10T的PostgreSQL在线数据库支撑全国的业务;除此外,还有探探、去哪儿网、百度地图等,都有很大的PostgreSQL部署量,高效可靠地支撑业务系统;还有一些传统行业,如浙江移动,湖北移动,中国联通等。

根据我知道的信息,市场对PostgreSQL数据库的需求一直都是高速增长的,增长的量主要集中在两个方面:

  • 一方面是新建的对可靠性、业务连续性要求高的OLTP系统,越来越多的用户将PostgreSQL作为优先选择的数据库;

  • 另一方面是数据量小于50T的小型OLAP业务系统,很多用于会优先选择PostgreSQL作为分析引擎。

这种需求最近一两年表现尤为明显。

5、您是否可以简单介绍下互联网模式下,PostgreSQL 数据库的高可用架构有哪几种模式?

  • 第一种跟其它数据库的高可用架构基本上一样,就是采用共享存储模式,数据库存放在共享存储上;一台主机,一台备机;正常情况下,主机连接存储启动数据库对外提供服务;当主机故障,备机接管存储,并且启动数据库,继续对外提供服务;这种架构的好处就是数据是专门的存储提供保护,不用担心丢失,切换服务的时间需要集群管理软件决定,一般来说基本中就可以完成切换;

  • 第二种是基于流复制的高可用架构,这里面有几个发展的阶段,

(1)第一个阶段是基于对PostgreSQL WAL日志文件的复制,这个方式目前基本上很少用了;大致的工作原理是集群内一个主库一个备库,当WAL日志归档后,这个文件同时拷贝到备库;备库始终处于恢复状态,接收到主机拷贝过来的WAL日志文件,立即恢复到备机;当主机宕机,备库立即切换模式,恢复成主库对外服务;

(2)第二个阶段是物理复制----流复制,主库正常工作,所有提交的事务除了写在本地的WAL日志文件,同时还会将数据通过网络传输到备库。通过控制对网络上数据传输时间的确认,可以分为异步复制和同步复制,这两种复制方式会涉及SLA定义的RTO和RPO等指标,同时也涉及到系统性能。

(3)目前的阶段是物理流复制方式比较丰富的阶段。在以前的复制方式上,对同步复制的控制手段很少;现阶段不仅可以控制集群内有多少台同步复制,而且可以控制数据提交成功的确认方式,例如在多少个同步复制节点提交成功、以什么样的方式在同步节点上提交成功,first n, any n等比较细粒度的控制复制成功时确认信息的行为;同时也可以比较细粒度地控制复制过程中的性能,比如发送到备库的buffer确认,还是备库写入wal确认,还是备库需要replay确认等......

  • 第三种是逻辑复制。逻辑复制的好处比较多,比如可以跨平台跨操作系统,可以控制需要复制的表而不是整个库进行部分数据的复制,比如用于OLAP分析系统的数据同步;也可以用于做不停机的业务系统升级。

另外说一点就是PostgreSQL可用的高可用方案比较丰富,有开源的方案比如pgpool,也有一些商业的解决方案,比如我们公司的ECOX系统。客户在设计和选用高可用方案的时候,严谨的生产系统最好要购买专业的服务。我们是国内比较好的服务团队并且能提供完整的解决方案跟相关技术。

6、请您介绍一下PostgreSQL中目前比较成熟并且流行的存储引擎和他们的使用场景吗?

PostgreSQL不像MySQL数据库那样有很多存储引擎。PostgreSQL只有一种存储引擎,对事务处理非常严谨严肃,主要用于高性能的OLTP业务场景。同时也可以用于小型的OLAP分析型业务场景。

7、PostgreSQL数据库在向着自动化运维的方向发展的过程中,面临的最大的挑战是什么?如何克服?

PostgreSQL数据库,不像我们常用的Oracle数据库,如果参数设置得当,应用设计也比较好,这种情况下其实不需要太多的维护;

对于PostgreSQL来说,反而是需要将精力放在存储子系统的可靠性,备份等方面。

存储子系统的可靠性需要仔细地设计,因为它不仅关乎系统性能,也关乎数据本身存放的可靠性。如果是严谨的商业应用,建议优先选用可靠的存储系统和文件系统;我们作为有丰富实施经验的专业厂商,我们会推荐用户优先选用ZFS,特别是原生的ZFS,这个领域我们有完整的方案。

8、PostgreSQL数据库与其他开源数据库相比较的优势

相对于其它数据库而言,PostgreSQL的优势是非常明显的,比如:

  • 有庞大的潜在的开发群体、运维群体和完整的生态;因为Oracle的生态系统非常完善和成熟,熟悉Oracle技能的人迁移到PostgreSQL数据库上的学习曲线非常平滑,成本非常低。根据我自己的经验,基本上2周时间可成。

  • 有大量的银行、电信、保险、政府等行业的关键业务应用案例和知名客户。

  • 有丰富的开发接口和开发语言支持,丰富的数据类型,支持传统的关系型数据和非关系型数据。对GIS非常好,对JSON,JSONB,XMLTable支持非常好。

  • 非常丰富的fdw扩展,几乎可以支持所有的外部数据源和数据库。

  • 非常先进的企业级特性,比如复制,分区,在线热备份,非常丰富的索引、函数等。

  • 非常优秀的跨平台、跨操作系统支持。支持几乎所有的硬件平台和操作系统。大到mainframe,小到嵌入式系统。

  • 高品质的代码,优雅的设计,非常长时间的、持续活跃的开发历史。

  • 每个发行版本都能获得为期5年的产品支持。

当然也有需要完善的地方,比如:

  • 宣传不到位,现在还有很多用户不清楚、甚至不知道PostgreSQL是一个生么样的数据库。(这一点会导致用户选用技术线路失误,从而导致后面的应用系统开发和维护成本很高。)所以应该加强PostgreSQL数据库的培训和宣传。

  • 国内从事PostgreSQL的服务商比较少,高质量的专业服务商更少。

  • 技术上目前还不支持块级别的增量备份和恢复(这个功能已经在线路图上,很快会有)

9、可以请您谈一下对 OceanBase数据库的认识和看法吗?

OceanBase是一个非常有特点的数据库,全新的设计,也在高性能,高可靠性方面有比较好的表现,17年双11表现的每秒处理26万多笔交易的威力(性能)大家也见识过了。

OceanBase的主从数据库

在传统的数据库主从架构中,比如(Active)DataGuard,主库对外提供全功能的读写服务,从库对外提供只读服务,主库到从库通过流复制技术使数据保持同步;

在OceanBase中,也有主和从的概念,复制也是主到从,与传统数据库不一样的是这个数据库的主、从概念是建立在分区表的分区上,每个表有多个分区,所有节点都可以有全部或者部分分区,分区有多个副本,分布在集群内的其它节点上,副本可以看作是是从,只接收主上面的日志,并且回放到内存里,一个可以读写的分区就是一个主;一个主可以有多从,确保数据有多份拷贝,主到从的日志传输通过Paxos协议完成,确保数据可以正确传输到其它节点;

整个集群对外来看,所有节点都是读写的、全功能的,比传统数据库优势明显,因为多活,负载均衡可以实现比较好,可以用低廉的硬件实现高性能、高可靠的系统;

仔细观察集群内部,由很多表的不同分区及它们的副本构成非常多的主从复制,所有的日志数据复制基于Paxso协议,能够保证任何节点损坏都不会有数据丢失的危险(当然节点坏掉的个数不能大于节点总数的一半)。

OceanBase另外一个比较有意思的设计就是类似于传统数据库中的check_point的处理,传统数据库的check_point时间根据负载和SLA的一些要求,一般保持在几分钟到半个小时之间,数据库要做一次check_point,以确保数据库的数据一致性;而OceanBase数据库把传统数据库类似check_point功能的操作周期做得非常长,比如一天做一次数据整合(类似于传统数据库的check_point操作);这样做有好处,就是对SSD这种新型电子磁盘的寿命有帮助,因为对SSD的操作都是大片大片的、整块地删除、写入,尽量避免SSD内部的写放大,这个设计的前提是基于服务器有非常大的内存配置,比如256G、甚至1T,现在的机器内存配置都比较大,很容易配置大内存的集群,那么把数据库的data buffer做到足够大,数据库所有的操作都在内存里,相当于一个准内存数据库,比操作磁盘的IO要快很多;通过这些设计,非常合理地避免了全分布式、高可靠、高性能并发和mvcc之间的矛盾。

OceanBase的设计非常聪明,它的出现的确给了我耳目一新的感觉,不管是技术上的创新,架构上的创新,技术来源,都是值得大大地给一个赞,说到技术创新、架构创新,我们的鸿鹄彩云系统就是为高性能数据库业务设计的,里面也有很多可以让人感觉耳目一新的技术创新的点,希望更多的人可以尝试试用;

当然一个新事物的出现需要一个时间完善和成长/成熟的过程,对于OceanBase来说目前也需要有完善的地方,比如技术上与现有的用的广泛的Oracle的兼容性,跨库交易等,关键行业的成功的应用案例等,让我们多给它一些时间,多给一些耐心;(当然我对OceanBase的了解也比较有限,可能有很多技术特点没有讲到,请包涵)

10、近几年随着大数据时代的到来,NoSQL数据库在处理海量数据上表现出越来越多的优势,请问您如何看待数据库的未来,会朝着什么样的方向发展?

从数据本身来说,真实世界里生产的95%以上的数据都是关系型的,只有很少的数据是非关系型的。

所谓的NoSQL是Google在很多年提出来的处理大数据的一个技术方案,主要使用的思想就是Map/Reduce,学过数据库的人都应该了解,这项技术实际上在上个世纪60年代,在大型机上处理大量计算常用的技术思想。

Google最终推出了自己的Spanner数据库,结果是非常明显的,Google自己都不用NoSQL,而回到传统的SQL这个线路上面来,所以未来还会向SQL这个方向走。

11、PostgreSQL数据库未来将会如何演变,如何应对海量数据的实时处理需求?

PostgreSQL未来还是会持续、活跃地开发高品质的软件,并且根据市场需要提供满足市场的技术特性;国内的市场也会普及和成熟,用户也会接纳并且广泛地使用PostgreSQL数据库、并且从中受益。

应对海量数据的实施处理,可以选用高性能硬件,MPP架构的技术;以后也会有基于内存的MPP,甚至用GPU加速运算的数据库;但是最终还是需要看用户本身的需求和业务特点,根据这些进行有针对性的设计和实施,以满足这类需求。

跨界与融合、机遇与挑战、个人与企业、现在与未来。让各行业、企业,以及每一个向未来而努力的人,听见时代最前沿的声音,见证成长!

Posted by enmotech at 6:37 PM | Permalink | Advanced (92)

近期发表

  • 千丝万缕:Oracle扩展统计信息虚拟列引发OGG 1161错误 - November 15, 2017
  • 百花齐放:十二大亮点抢鲜看,数据技术嘉年华11.17日北京盛放 - November 7, 2017
  • 数据架构:从AT&T到青海移动的多租户数据整合实践 - October 23, 2017
  • Oracle Database 18c new features 之10大新特性一览 - October 7, 2017
  • 拉里·埃里森亲自支招,数据库自动化之后,DBA何去何从? - October 2, 2017
  • DBA将要彻底失业吗?Oracle推出Autonomous自治数据库 - September 29, 2017
  • 恩墨学院DBA实战培训全新启航 - September 4, 2017
  • Oracle中如何获取给定SQL的SQL_ID - dbms_sqltune_util0 - August 7, 2017
  • Oracle SQL和PL/SQL中字符串单引号的处理 - July 12, 2017
  • Oracle Mutex 等待事件之: cursor mutex X - July 7, 2017


  • CopyRight © 2004 ~ 2012 eygle.com, All rights reserved.