嘉宾介绍：郝大为，巨杉数据库技术总监，曾任职IBM DB2数据库部门以及亚信大数据部门，资深的数据库专家。拥有丰富的数据库开发、应用经验。熟悉金融、电信、互联网行业的数据库、大数据技术与应用。目前在巨杉数据库任职技术总监，主要负责SequoiaDB巨杉数据库功能与业务结合的设计与开发，同时负责企业用户的平台设计搭建。

今天的主题主要有四个部分：

一、公司简介

二、JSON/BSON 记录存储

三、文件存储与 LOB 机制

四、灵活存储机制商业应用的案例

一、公司简介

SequoiaDB 巨杉数据库，是一款面向企业级的分布式 NewSQL 数据库，自主研发并拥有完全自主知识产权，后又选择开源的商业数据库产品，没有基于任何其他外部的开源数据库源代码。这是一个现在比较成熟的商业化的自主研发数据库，用户涉及金融、政府、交通等领域。

下面这张图在大数据领域很著名，2016年发布，囊括了在大数据领域的大部分的著名的公司和产品，它也划分了一些大数据领域的域，巨杉数据库成为这张图唯一一家中国厂商，在基础平台这个领域得到硅谷的认可。

二、JSON/BSON 记录存储

JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，它基于ECMAScript的一个子集，为纯文本格式，支持嵌套结构与数组。巨杉数据库用JSON作为数据表达，跟传统的数据库有比较大的差异，但大部分开发人员对JSON数据库比较熟悉，所以会比较好理解，数据的类型主要是string，number等等，数据表达方式非常简单，在数据库存在的就可以简单理解为一条一条的文档。

JSON表达的有很大的灵活性。个人所有的信息和数据：联系方式、邮件以及点击过的广告和其他的行为（商品等），在数据库每个对象的表达之间都有关联关系，用JSON表达，就会变成一条文档，以ID为核心，对应属性以及对应的数据变化一个列表（邮件列表、广告列表等）。这种表达在JSON里很容易理解，其嵌套的关系更贴近于一个人的各个角度。这是程序员比较熟悉的，上面写的是层次化的嵌套形式实现一对多的模型。

这是更加具体的，能够通过一个JSON的形式表达左边的数据，左边第一张表是以Customer  ID为中心，第二个是对应的每个数据，可以看到名字、账号等信息的对应关系，这就是JSON文档数据的结构。

同样的数据在不同的历史时期会有变化，这个时候可以增加一些字段，增加它的信息，它在2012-2014年数据结构不一样，这个是库表字段的变化，在数据里头就在旧的历史数据里面是空的字段内容，那么在数据里头，这张表会不断增加字段，不断变化。

在JSON里面不涉及到数据结构变化这个层次，因为每条数据的插入，都是自表达的数据结构，每一年的数据有哪些字段内容就会出现哪些内容，它是非常灵活的，再极端一些，所有字段内容都不一样，也没有问题，2012、2014年可以在同样的集合里面出现多条不同结构的文档记录。

另外，在 SequoiaDB 数据库里，并不是单纯把JSON数据文档进行简单存储，实际上还针对数字型的字段和日期都进行数值的转换。同时在相对新的一些版本里头，也会增加一些具体的实现，今后的扩展将是BSON存储格式。

三、文件存储与 LOB 机制

LOB（Large OBject，大对象）是存储大对象的数据类型，其核心机制是将内容文件打散成多个数据块，每个数据块被分别发送到不同分区独立存放。刚才提到的BSON是简单的时间，也许是一个日期，日期的表达会比这个略有区别，在存储层面是转型的数。

BSON和LOB按需搭配使用

一个文件，不管是word，还是PDF，都可以简单判断是否是二进制数据，它在比较短（16兆以下）的时候，可以存储成二进制数据，可以是文档当中其中的一个进制，Binary是字段的类型，以行形式的存储，用这个简单的图表达，就是一个collection，里面是一条一条文档型的记录，这就是一个行存储的方式。对于数据库来说，就是一条普通的记录。

下图是LOB类型数据存储方式，它具有以下特点：

• 单独的分布式块存储模式。不同分区是存储在不同服务器上不同的词场中，每个分区对应一个数据结合。下图这些部分组成了一个数据集合，里面存储了比较多的LOB记录，一个集合存储多个分区，每个分区分化成不同的数据块。

• 文件按照LOB处理。对于比较大的文件，按照LOB的格式存储。

• 自动按照64/128KB的数据块进行切分，放在不同分区存储。在LOB存储上，最关注的是性能，因为它的数据访问量高峰期的时候，需要读取的量很大，这样做的好处是，在写的时候实际上向多块子盘同时写入，性能会远远高于单块子盘。

• 使用DIO避免二进制数据占用文件系统缓存。元数据其实也是这种分散的结构，也是分片结构，提高了性能。真实数据存储是分页结构，16兆不是特意限制，因为存放文档型记录都要做分页，这样就要设计一个相对合适的分界线，存储不同的文档型记录和LOB记录，每个LOB记录有一个OID分配给它，快速定位到在哪些地方存在，可以快速访问。

• 并行处理：与GridFS相比不占用内存，与HDFS相比不存在Namenode限制。

对比一下过去的文档存储，LOB对象存储的解决方案，过去会用关系数据库存储LOB对象的属性，比如说名字、大小、时间，然后用文件系统存具体的LOB对象，但是这种关系数据库+文件系统地址的方案会导致以下问题：

• 文件条目受关系型数据库的性能限制， 比如超过3亿条后性能急剧下降
• 现在把LOB数据直接放到HBASE上，但受 Namenode限制无法处理大量的小文件，分配64MB存储浪费空间；小文件不定期后台自动聚合，影响系统的使用稳定性。
• 做Merge的过程造成I/O飙高，无法满足在线ECM服务场景

与其他解决方案相比，由于不存在独立中控元数据节点，SequoiaDB提供的LOB存储机制理论上可以存放近乎无限数量的对象文件，并且不会由于元数据堆积而造成性能下降。同时，由于数据块被散列分布到所有数据节点，整个系统的吞吐量随集群磁盘数量的增加近乎线性提升。

LOB 块存储机制

大对象（LOB）功能旨在突破 SequoiaDB 的单条记录最大长度为 16MB 的限制，为用户写入和读取更大型记录提供便利。LOB 记录的大小目前不受限制。

每一个 LOB 记录拥有一个 OID，通过指定集合及 OID 可以访问一条 LOB 记录。在非分区集合及哈 希分区集合中均可使用 LOB 功能。集合间不共享 LOB 记录。当一个集合被删除时，其拥有的 LOB 记录自动删除。

LOB 记录的存储格式：

开发者最关注的是数据结构，因为它决定了我们的行为特征，以及它的性能特征，在设计这个虚拟结构的时候，有几个出发点：第一，能够存得特别大的数据；第二，保证大数据存储后性能要高，比如批量的多媒体的数据，文件的快速写入和读取；还有高可用性等其他一些目的，在设计的时候，会考虑到数据的同步，包括在有硬件损坏的场景下，它是否具有高可用的特征。

SequoiaDB的LOB存储结构分为元数据文件（LOBM）与数据文件 （LOBD）。 其中，元数据文件存储整个LOB数据文件的元数据模型，包括每个页的空闲状况、散列桶、以及数据映射表等一系列数据结构。

而数据文件则存储用户真实数据，数据头之后所有数据页按照page size进行切分，每个数据页不包含任何元数据信息。在建立集合的过程当中，大对象存储必须依附于普通集合存在，一个集合中的大对象仅归属于 该集合，不能被另外一个集合管理。

在建立集合的过程当中，大对象存储必须依附于普通集合存在，一个集合中的大对象仅归属于该集合，不能被另外一个集合管理。

当用户上传一个大对象时，会经历几次散列操作。

首先，协调节点或客户端会生成（或者用户指定）一个全局唯一的描述符，同时将传入的数据按照用户指定的pagesize大小切片，最后针对每一个切片按照（描述符+切片id）进行散列，用于决定该切片存在哪个数据分区中。注意，集合的分区键设定并不作用于大对象。

在每个分区中，当接收到数据分片后会根据（描述符+切片id）进行再一次散列，决定元数据桶的位置。而真实数据则通过查找元数据信息，在数据文件中找到一个最近的空闲页写入，然后将该页的ID写入元数据桶中，代表该桶指向这个数据页。如果散列后数据桶已经被占用，则使用常规散列冲突的解决方式找到下一个空闲桶。

当用户读取大对象时，协调节点按照其（描述符+偏移+长度）计算出需要读取多少个切片，以及每个切片所在的数据分区，最后将数据节点返回的数据按顺序排列返回客户端。

由于SequoiaDB将文件切片存储，一个大文件可能存在有非常多个分片，所以在访问的时候协调节点还需要进行请求合并，尽可能使用最小的报文一次性请求多个连续的数据页，以防止访问一个对象时协调节点需要向数据节点发送成千上万的此类请求，同时对数据节点做到I/O合并，一次性读入尽可能多的连续页面。

四、记录/文件 双存储引擎的应用实践

由于LOB数据快速存取的特征，因此在一些领域应用广泛，比如企业建立自身的文档存储平台等，本部分将分析各种相关的LOB应用场景下的一些实践案例，开发人员这方面可能了解得比较少。

金融行业

基于这些存储特征，有一些其他行业应用明显的案例，可以给大家一些借鉴。这是金融行业的影像平台，这方面需求越来越多，在柜台办理的时候，早年有一个摄像头，会拍摄签署的文件，身份证件扫描，以及面对摄像头说一句话等，这个数量量很大，都需要有LOB存储强大势力支撑。

金融行业这些存储量就越来越大，访问的性能和历史存档的文件能力都很重要，还有可能需要马上调取两个月之前的一些文件甚至是更久远的数据，下图就是用分布式影像平台替代 documentum 和 filenet 这些传统解决方案后明显的性能和成本优势。

地方政府

政府有各种各样的LOB对象的存储，会，LOB存储有插件能力，还有数据库的能力，把各个数据通过LOB文件存储，可以很方便查询，同样一个文件查询次数比金融行业还要多。

医疗行业

医疗行业的主要需求：

• 海量非结构化半结构化数据：处方，药方， 病历，X光片等
• 数据结构多样化：每个医生、患者对应的数 据结构都不同，难以统一
• 数据量大，历史数据需要实时在线查询：诊 断历史数据的实时查询，病情跟踪

同样是存储的能力和性能的优势，它的JSON数据表达能力也是满足他需求的一个特征。

OTA旅游 /电商

互联网应用的特点，带来了几项重要的挑战：

• 数据量大
• 业务增长快
• 数据类型多样

有大量图片，混合式存储，天生比较适用于JSON的数据表达。

360度用户视图

这个是分析型的应用场景，比如说360度用户视图。通过大数据对用户行为进行分析，已经成为各行各业对大数据应用场景的基本认知。不论是金融、政府、 运营商、制造、甚至互联网等行业，都在考虑如何使用大数据技术，借助用户行为分析、第三方数据分析等方式，进一步完善已有的CRM体系，将传统的静态数据向360度用户视图转移。

交通领域

在交通领域也是影像方面的应用。在公安与交通行业，针对视频卡口的大数据存储、分析与应用一直以来是最受关注的主题。借助 SequoiaDB半结构化对象存储、分布式横向扩展能力以及非结构化影像存储引擎，交通部门可以从卡口视频文件中提取出的车牌信息、位置信息、以及时间信息按照三个维度汇总，进行道路拥堵预测、车辆轨迹跟踪、套牌车监控、尾随车辆监控等多种安防措施。