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

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

编辑:IT大咖说

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

内容摘要

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

嘉宾演讲视频回顾及PPT:http://suo.im/4ONtwE

企业级功能技术解密

数据库应用范畴

我们把整个数据的本身分为三个类型。第一个类型是大家比较熟悉的交易型,传统的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这部分。每一个企业它都有它的强项,巨杉的数据库就非常适合于互联网、政府大企业的大数据处理。

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

你可能感兴趣的:(分布式数据库企业级功能技术解密与最佳实践)