【巨杉访谈】分布式数据库企业级功能技术解密

大数据的使用场景越来越多了，真正的企业级应用对于数据库有怎样的需求？分布式数据库的企业级场景有什么特别的技术点？在分布式架构这方面，巨杉数据库有什么特色的实现机制？巨杉数据库的解决方案总监彭旸老师，将分享有关分布式数据库企业功能的相关技术。

 

1.企业级应用下，分布式数据库的定位有哪几种？

数据库分为很多种。那么统一谈论数据库性能优化，实际上是没有意义的。不同类型的数据库，其性能关注点的指标也不一样，很多情况下各个指标甚至可能带来设计思路的完全冲突。因此，要说某一个数据库能够一家通吃我是打死也不信的，因为在不同类型的业务场景下，其设计模式是完全冲突的，不可能使用一个架构满足所有的需求。

整体来看，现在的数据库类型主要可以分为三类，包括交易型数据库、联机型数据库以及分析型数据库。

其中交易型数据库比较容易理解，像 Oracle、MySQL 这类处理在线联机交易的都属于这个范畴。

而分析型数据库则是另一个极端，主要用于企业内部做大量数据统计分析使用，其设计模式和理念与交易型数据库是背道而驰的。

第三类联机类数据库，则是近期很多企业在大数据的环境下，尝试将很多的数据提供给线上业务使用的场景。比如微博微信这种数据量很大，同时也要求对大量数据提供高并发在线访问的业务系统，都属于联机类数据库。

SequoiaDB 比较偏向于第三类数据库类型。

 

2.企业级方面的功能需要考虑的东西是否会更多，具体有哪些方面？

是的，企业级的应用场景下，大数据方面的考量和要求是比较严苛的，也是和纯互联网和移动应用很不一样的。主要的特点：

1. 数据量大：不同于一般的网站或者移动 APP（当然微信这样体量的除外）大的企业的数据量基本都会到达百 TB 以上，PB 级别也很常见。

2. 产品性能、稳定性要求高：数据量大之外，企业客户对于系统的稳定和性能要求近乎严苛，因为银行等企业的系统关乎金融安全，所以对于稳定性、性能的保证十分看重。不可能像一些互联网应用那样的粗放。

3. 传统架构和应用的沿袭与兼容：企业用户由于业务开展时间比较长，所以应用和业务层的很多技术、架构都需要兼容，就不像互联网应用大多都是从头开始或者可以推到重做。因此对于兼容性、应用迁移支持等等也很看重。

 

3.巨杉数据库对于企业级应用有什么特点？

针对刚刚所说的几点关注点，巨杉数据库都有对应的：

1. 分布式架构：海量数据存储，我们自研的分布式引擎就能实现横向的扩展，支持更多的数据存储，提升整体系统性能。

2. 性能稳定性：巨杉数据库产品设计之初就主要考虑了企业级应用场景，所以其性能和稳定性也是经得起企业应用考验的。这块也是对比像 MongoDB 这样的互联网产品，我们在中国的企业级客户市场更得到欢迎的原因。

3. 兼容性：我们虽然是分布式数据库，但是我们支持标准 SQL 的访问，因此对兼容已有的系统是很有帮助的。

4. 团队力量：我们的团队的技术实力和专业的技术支持能力，在国内也是比较领先的。能有核心研发级别的技术支持，对于企业用户也是一个很好的示范作用。

 

4.在分布式架构上，巨杉有什么特色的实现机制？

主要介绍一下数据分区的机制：

既然是分布式数据库，那么我们接下来看看数据分区方式。市面上大家常见的分区方式叫做 Partitioning，有时候也叫做 Sharding，也就是把一堆数据按照某个字段，按照范围或者散列后的范围进行切分，分别存放在不同的磁盘或物理机中，这个就是分区。

但是，在对于流水类数据，这种数据体量很大，但是按照时间或者地域进行非均匀访问的数据，我们可以在 Partitioning 的基础上，做到第二个维度的切分，也就是 Table Partitioning，表分区。

表分区的机制在传统关系型数据库里面基本都有实现，不管是 Oracle 还是 DB2 都可以在一个实例里面，把一个表按照某个时间的字段按照范围进行划分。实际上每个范围在底层是作为独立的表存在的。

这样的好处就是，每个范围里面存放的数据是有限的，那么这个范围中的数据构建的索引高度也是有限的。而对于流水数据基本上数据输入都是时间有序的，很少有说今天我还在大量输入去年或者前年某个时间段的数据。因此，这样对于索引的写操作会非常有效，不需要等到索引涨到 7、8 层，把内存填满了造成每次索引写都有无数随机 I/O，就可以按照范围简历一个新的区间，使用全新的索引树了。

这种机制对于快照类数据效果一般，但是对于流水类数据，在带索引的情况下高速写入非常有效。

 

5.对于分布式数据库的企业级场景，还有什么特别的技术点？

读写分离机制也是提升企业系统性能的重要机制：

首先，读写分离机制在分布式系统中也很常见。比如说在一个简单的 MySQL 读写分离集群中，主节点作为读写节点，从节点作为只读节点，中间通过 binlog 复制的方式将一个节点的写操作复制到下一个节点中。

这种设计的好处在于，在一个能够容忍最终一致性的应用中，写入操作和读取操作可以被分别运行在不同的物理服务器甚至不同的网络区间中，这样就算是读操作产生相当大的压力，也不会对写入操作造成影响。反之亦然。

这种设计有一个前提条件，即最终一致性是可以被接受的。如果整个应用需要强一致的系统，读写分离的效果就会大打折扣。因为所有的写操作需要确保被复制到全部节点才能完成，而如果其中某一个读分区变慢，可能会导致写操作同样变慢。在强一致性的场景中，读写分离时应用可以得到唯一的优势在于原本跑在一个机器里面的业务被平均分配到三个机器里面，但是会对写操作产生很大的性能影响。

因此，读写分离在最终一致性的场景中会带来极大的性能提升，在强一致性的场景中会起到一些作用。大家在选择架构的时候需要仔细考虑自己的业务是否适合读写分离场景。

 

6.技术方面，巨杉数据库对于将来的发展有什么规划？

另一套产品巨杉内容管理软件 SequoiaCM 也将会加大宣传力度，也会在之后源创会的活动给大家做介绍！

 

7.对从事数据库方面的开发者有什么建议？

可以先从小项目入手，数据库的用法和架构和十年二十年前已经大不一样了。

分布式体系下，很多设计和使用思路都会产生变化，因此更好理解新一代数据库的特点就对业务和应用的使用很重要了。

可以从 SequoiaDB 或者别的开源分布式数据库入手，以小项目入手培养，熟悉起来。

本文地址：https://blog.csdn.net/SequoiaDB_Official/article/details/110490763