阅读字数: 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这部分。每一个企业它都有它的强项，巨杉的数据库就非常适合于互联网、政府大企业的大数据处理。
今天就介绍到这里，谢谢！
