前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >分布式数据库企业级功能技术解密与最佳实践

分布式数据库企业级功能技术解密与最佳实践

作者头像
IT大咖说
发布2018-04-03 15:48:00
1.6K0
发布2018-04-03 15:48:00
举报
文章被收录于专栏:IT大咖说IT大咖说
编辑IT大咖说

阅读字数: 2739用时: 10分钟

本文内容来源于彭旸OSC源创会上海站上的主题演讲,IT大咖说为与开源中国合作的视频知识分享平台。

内容摘要

对于真正企业级应用,需要分布式NoSQL/NewSQL数据库具备什么样的能力?相比MongoDB等分布式数据库,他们的企业级应用场景挑战在哪里?SequoiaDB的技术特点又缘何适合金融、政府等用户的应用场景?本次分享,巨杉就将带来有关SequoiaDB技术解密透视具体技术点,同时我们将介绍SequoiaDB在企业级应用上的最佳实践。

视频内容

企业级功能技术解密

数据库应用范畴

我们把整个数据的本身分为三个类型。第一个类型是大家比较熟悉的交易型,传统的OLTP业务。第二个是分析型。还有一种是不太常见的连机型,或者是在线数据库。它是基于OLTP的延伸。

交易型数据库性能核心指标

传统的交易型数据库,它的核心指标是什么?

评测方式是TPC-C,就是结果测试。

它主要强调几个性能。随机的读写性能很重要。第二个是事物相关。还有数据相关的一致性和可靠性。传统的数据库要考虑的东西非常多,所以它必定会受到影响,优势变成劣势,没有一个数据库是完美的。

分析型数据库性能核心指标

分析型数据库需要考虑的点就很少,它不用考虑事物,只需要考虑读写性能和大量的吞吐量。

它的评测方式就是TPC-H或者TPC-DS,它变得很简单,考虑的细节上的东西变得比较少。但它的简单变成了其它性能上的压力。

分析型数据库主要强调的一个是高并发,一个是可靠性,还有一个是读写性能。它其实是损失了一些强事物的东西,但是强调满足了高性能高并发的要求。

SequoiaDB分布式数据库架构

今天我想主要讲的是做一个MPP对于分布式数据库需要考虑哪些。

第一个是分布式架构。分布式里包含了协调节点、编目节点、还有数据节点。

最简单的是数据节点,只要把数据全部放在这个节点就好了。编目节点是元数据。协调节点是处理请求的,所有的API请求、命令请求都是通过协调节点来的。但是协调节点还有一个工作,它是根据编目节点的元数据来判断指令的数据到底在什么地方,来决定把它的执行力下到那个点去做,这样才能把它的性能增强。

SequoiaDB物理架构

对于一个分布式数据库来说,最重要的不是CPU,而是IO。IO对所有磁盘数据的处理是极其重要的。

分布式数据库是一个X86小集群。X86最大的缺点是它的性能很容易宕机。它的优点是价格便宜,很容易处理和管理。

什么叫分布式的概念呢?我们把它分成两部分的话,会有一个主节点和两个从节点。主节点所有的写入会自动地分布到从节点去做同步。当你一主两从的时候,每一块磁盘它是百分之百相同的。它是靠一主两从多备份的方法来满足一致性和数据的完整性,也就是我们说的用空间来换取它的一致性。

分布式架构优化:数据多维分区

水平分区是对一个关键词做数据均衡的切分。因为把数据拆小了以后,当所有的层次很多的时候,它的性能会急剧增加,所以数据切片是很重要的。

水平切分的主要目的是它为了线性增长,把所有数据切分在不同的磁盘里面,并要保持数据的均匀和平衡性。

但是有的时候只是一个月的数据也有很多,还有什么办法能把数据切分得更加好一点?我们就称为叫垂直分区。垂直分区尽可能选择时间或区域相关性较高的字段。我们把这两种的分区方法结合在一起就称之为多维分区,它是整个分布式数据物理和逻辑切分的核心。

引擎内部优化:B树多维度索引

对于一个数据库来说,如果是做查询类的话,索引是它的核心。很重要的一点就是对数据的切分要确保索引层不能太高。我们还支持反向排序的一个全能索引。

分布式架构优化:读写分离机制

分布式架构有一个主节点,两个从节点。一般来说主节点是为了写的。如果一个系统中已经有了三个副本,可以让其中的一个副本变成专门做高并发的查询,甚至可以让另一个节点做批量的数据。这样就会变成读写分离的状态。一套体系可以用在三种模式上来做,这是它的强项。

分布式架构优化:数据域逻辑与物理隔离

传统上来说,为了在不同的业务中,会建不同的表进行处理,为了保障业务之间是隔离的。但是现在的企业或者互联网,很多的业务需要跨不同的业务去产生。

我们在实施业务中还有很多是需要跨业务群的。

在巨杉分布式里可以做数据融合,不同的业务既能隔离又能融合在一起进行操作。

分布式架构优化:SQL与存储引擎隔离

传统的数据库SQL和存储是放在一起的,但是我们认为SQL和存储是可以隔离的。因为SQL完全没有状态,只是做了SQL的引擎分析,然后把它变成指令下压到每一个节点上做计算。如果为了让SQL的性能提高,可以额外增加很多SQL的节点来提升它的性能。

分布式架构优化:一致性散列机制

如果数据量已经很大了,那数据迁移该怎么做,是不是会很麻烦?我们在在这个部分做了一些优化。我们是把hash落在一个范围内,这样的话就容易在这个范围内再进行小切分,它的迁移速度和效率会更高,它会在后面比较透明地迁移,不会引起很大的阻塞。

引擎内部优化:快存储支持大小文件

我们的块存储是有两个引擎,一个是数据的引擎,还有一个是块结构化的引擎。这个引擎跟HDFS有点差异,HDFS是64兆的大块,我们是最大到256K的小块。这是为了处理到行级别的数据。

比如我要查一张图片,如果是大块的话,吞吐量是很大但不适合做实时交易。我们把一个数据块拆成很多碎片扔到分布式数据库里,这样它同时读取的性能会非常快。

高效压缩机制

对于数据库来说,IO是核心中的核心。一般来讲我们会把数据进行压缩。我们有两种压缩,一种是Snappy的行压缩,还有一种是基于LZW的表压缩。Snappy压缩基本上能做到数据的50%行压缩,但表压缩可以做到快80%,效率非常高的。

对一个联机型高并发的业务场景来说,CPU一般不会有压力,但是IO换取的性能增长那是巨大的,所以从这个角度来说,损失1%到5%的CPU压力却换取50%到80%IO存储的性能是值得。

企业级应用最佳实践

证券行业高并发查询

例如某证券类交易信息管理系统,通过搭建基于SequoiaDB的数据库存储,该机构将所有历史数据实现在线化,同时保证每天增量的及时写入。它在峰值超过两亿条记录写入,并发量超过10000。高峰时段同时有超过百亿级别的数据需要被检索、调用,查询返回时间小于100ms,实际测试性能10倍于原有MySQL。在PD的数据做到毫秒级的精准查询和数据返回,这是巨杉最大的一个优势。

银行历史数据平台

在历史平台上,比如像银行要的数据量特别大,以巨杉的方式就是把所有的数据全量存储,它的好处一是可以随时查询,第二个好处是为了做大数据的准备。

交通/安防 监控视频影像管理

在实时处理中,巨杉非常适合做监控型的方法,但它不是合作怎么说机器学习和深度分析,因为它的吞吐量和磁盘存储的碎片化不适合做深度分析或者做AI这部分。每一个企业它都有它的强项,巨杉的数据库就非常适合于互联网、政府大企业的大数据处理。

今天就介绍到这里,谢谢!

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-06-16,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 IT大咖说 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档