扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
如今,随着业务“互联网化”和“智能化”的发展以及架构 “微服务”和“云化”的发展,应用系统对数据的存储管理提出了新的标准和要求,数据的多样性成为了数据库平台面临的一大挑战,数据库领域也催生了一种新的主流方向。
创新互联服务项目包括叶县网站建设、叶县网站制作、叶县网页制作以及叶县网络营销策划等。多年来,我们专注于互联网行业,利用自身积累的技术优势、行业经验、深度合作伙伴关系等,向广大中小型企业、政府机构等提供互联网行业的解决方案,叶县网站推广取得了明显的社会效益与经济效益。目前,我们服务的客户以成都为中心已经辐射到叶县省份的部分城市,未来相信会继续扩大服务区域并继续获得客户的支持与信任!数据库多模Multi-Model是指同一个数据库支持多个存储引擎,可以同时满足应用程序对于结构化、半结构化、非结构化数据的统一管理需求。
1.数据库云化需求催生Multi-Model多模
企业使用云数据库对接的应用越来越多,需求多种多样,传统的做法是在dbPaaS里面提供十几个不同的数据库产品分别应对各种需求,这样的方法在系统增加后,整体维护性和数据一致性管理成本很高,会影响到整个系统的使用。
云数据库的“多模”示意图
为了实现业务数据的统一管理和数据融合,新型数据库需要具备多模式(Multi-Model)数据管理和存储的能力。通常来说,结构化数据特指表单类型的数据存储结构,典型应用包括银行核心交易等传统业务; 而半结构化数据则在用户画像、物联网设备日志采集、应用点击流分析等场景中得到大规模使用;非结构化数据则对应着海量的的图片、视频、和文档处理等业务,在金融科技的发展下增长迅速。
多模式数据管理能力,使得数据库能够进行跨部门、跨业务的数据统一存储与管理,实现多业务数据融合,支撑多样化的应用服务。在架构上,多模Multi-model也是针对云数据库需求的,则使得数据库使用一套数据管理体系可以支撑多种数据类型,因此支持多种业务模式,大大降低使用和运维的成本。
2.Multi-Model存储引擎架构
数据库是现有许多业务系统的核心。随着数据生成与采集技术的飞速发展,数据量不断爆炸式增长,数据的结构也越来越灵活多样。传统基于关系型理论构建起来的数据库管理系统,面对大数据、人工智能的真正到来,在成本、性能、扩展性、容错能力等方面遭遇到了不小的挑战。
面对多类型的的结构化数据、半结构化数据、非结构化数据,现代应用程序对不同的数据提出了不同的存储要求,数据库因此也需要适应这种多类型数据管理的需求。
比较流行的两种解决思路分别是:混合持久化(Polyglot Persistence)与多模数据库(Multi-Model Database)。
1)混合持久化 Polyglot Persistence
混合持久化的思路是指,用户根据工作的不同需求分别选择使用合适的数据库,这样在一个完整的系统中,可能同时运行着多种不同的数据库。
图1 Polyglot Persistence示意图
混合持久化一个显著的优点就是单一流程的性能提升,但缺点也同样的显而易见:以增加复杂性和学习成本为代价,在部署、使用及维护上带来了挑战。
2)多模Multi-Model
Multi-model多模数据库则是另一种解决思路,在同一个数据库内有多个数据引擎,将各种类型的数据进行集中存储和使用。多个不同类型的应用,同时接入一个数据库,并在同一个分布式数据库内进行管理,大大简化应用程序的开发及后期维护成本。
图2:多模数据库引擎架构示意图
图为多模Multi-Model数据库的示意图,我们可以看到在同一个存储引擎里面同时具备 关系型数据、JSON半结构化数据、对象数据以及全文检索引擎等等多个数据引擎,统一提供给应。这一架构大大降低开发和运维的难度,应用统一连接到数据库,数据库内部进行数据的划分、隔离和管理,对应用来说只需要连接到数据库即可,无需为了每个应用搭建对应的数据后台。
3.存储数据结构
针对多模数据库的需求,分布式数据库的存储数据结构也会有新的创新。以下就是SequoiaDB在Multi-model方面,进行的数据存储结构和访问的设计和实现,可以作为Multimodel数据库的一个很好的参考。
3.1 结构化、半结构化数据存储
结构化数据的特点是结构固定,每一行的属性是相同的,如传统关系型数据库表中的数据。半结构化数据是一种自描述结构,它包含相关标记用来分隔语义元素及对记录和字段进行分层,如 XML,JSON 等。
存储结构
如何在数据引擎中同时管理结构化和半结构化数据呢?SequoiaDB 使用JSON 数据模型,在数据库内部使用BSON 格式来将结构化及非结构化数据以文档的形式存储在集合中。
BSON(Binary JSON)是对 JSON 的一种二进制编码数据格式,和 JSON 一样,BSON支持嵌入式的文档和数组。BSON 由若干个键值对存储为单个实体,这种实体称为文档。BSON 包含了 JSON 中的数据类型,并扩展了一些 JSON 中没有的数据类型,如Date,BinData 等。BSON 结构的一个简单示例如下图所示。
图3: BSON 结构示例
BSON 具有以下几个特性:轻量级(Lightweight),可遍历性(Traversable),高效性(Efficient)。由于BSON结构包含足够的自描述信息,因此它是一种 schema-less 的存储形式。
SequoiaDB将 BSON作为记录的存储结构,由于其良好的灵活性,不需要事先对集合的结构进行定义,每一个记录中包含的字段信息可以相同,也可以不同,并可随时进行修改,这样对结构及半结构化的数据都能以一致的方式统一存储和访问。
SequoiaDB中的数据管理模型如图4所示。
图4: SequoiaDB 数据管理模型架构图
数据最终都是要在磁盘文件中进行持久存储,与之相关的三个概念如下:
文件(File):磁盘上的物理文件,用于持久存储集合数据、索引及 LOB 数据。
页(Page):页是数据库文件中用于组织数据的一种基本结构,SequoiaDB中使用页来对文件中的空间进行管理与分配。
数据块(Extent):由若干个页组成,用于存放记录。
在该模型中,与结构/半结构化数据存储相关的三个核心逻辑概念包括:
集合空间(Collection Space):用于存储集合的对象,物理上对应于一组磁盘上的文件。
集合(Collection):存放文档的逻辑对象。
文档(Document):存储在集合中的记录,以 BSON 结构存储。
一个集合会包含若干个 extent,所有这些 extent使用链表串联起来。当向集合中插入文档时,需要从 extent 中分配空间。如果当前 extent 没有足够空间,则分配新的 extent(必要时对文件进行扩展),挂到该集合的 extent 链表上,然后向其中插入文档。每个 extent 内的记录也通过链表的形式组织起来,这样在进行表扫描时,可顺序读取块内的所有记录。
数据访问
1)SQL
当前大量基于数据库的应用使用 SQL 来进行数据库访问,因此对的 SQL 支持是数据库必不可少的能力。SequoiaDB支持标准 SQL 接口,完全兼容 PostgreSQL 及 MySQL语法和协议,现有的应用可平滑地将存储系统切换为 SequoiaDB,以获得分布式存储系统所带来的扩展性、性能及可靠性等立面的巨大提升。
2)API
SequoiaDB 在结构化数据提供了丰富的 API 接口用于管理整个集群及操作数据,提供了各种主流编译语言的驱动。
数据压缩
对于JSON/BSON数据结构,因为其嵌套结构,在拥有灵活的存储结构同时,也会造成数据的膨胀。JSON数据存储的膨胀问题,也是早期如MongoDB等JSON数据库性能瓶颈的一个重要原因。
SequoiaDB在使用JSON/BSON作为数据存储结构时,为了避免过度的膨胀问题,在数据引擎中加入了数据压缩的机制。目前SequoiaDB引擎提供了两类压缩方式:行压缩与表压缩。行压缩使用Snappy算法,是一种不需要字典的快速压缩机制。表压缩则使用LZW算法,是一种基于字典的压缩机制。
数据压缩机制,一方面从存储上节省空间和成本,另一方面提升单位I/O的效率。在IO吞吐量非常高的查询场景下,基于数据字典的深度压缩机制能够大幅降低IO开销,有效提高查询效率。
3.2非结构化数据存储
存储结构
非结构化数据即没有固定结构的数据,如文档、图片、音频/视频等,这种类型的数据在现在的很多业务中所占的比重越来越大。在SequoiaDB中,使用大对象(LOB,Large Object)来对这种类型的数据进行管理。
大对象依附于普通集合存在,当用户上传一个大对象时,系统为它分配一个唯一的 OID 值,后续对该大对象的操作可通过该值来进行指定。
大对象在存储时会进行分片,并使用hash算法将分片分散存储在相应的分区组中,其哈希空间与所属集合的哈希空间一致。分片大小为 LOB 页大小,在创建集合空间时指定,默认为 512KB。
为了对 LOB 数据进行有效的存储和管理,SequoiaDB内部将 LOB 数据抽象为元数据和数据本身,并使用两种文件来存储这些数据: LOBM 文件用于存储 LOB 分片的元数据,LOBD 文件用于存储真正的 LOB 数据分片。它们的逻辑结构如下图所示。
图5: LOB 文件逻辑结构
其中LOBM 文件主要包括:
文件头:包含该文件的一些元数据信息。
空间管理段(SME):用来标记页的使用情况。
桶管理段(BME):hash 值相同的分片所占用的页以双向链表的形式挂在一个桶上。
页:与 LOBD 中的页一一对应,记录该页所属的集合信息,OID及sequence 值等。
LOBD 文件主要包括:
文件头:包含该文件的一些元数据信息。
真正的数据页:用于存储 LOB 分片。LOB 还有一些自身的元数据,保存在 sequence 为0的分片中,包括该 LOB 数据的大小、创建时间、版本号等。
数据访问
1)写入LOB
当需要写入 LOB 数据时,LOB 数据会在协调节点上进行分片,每一个分片分配了一个 sequence 值,它表示这些分片在原始 LOB 数据中的顺序。因此,LOB 的OID与分片的 sequence 值唯一地标识了这个分片。
在存储一个 LOB 分片时,使用其 OID + sequence 计算 hash 值。先使用集合的分区 hash函数来计算出该分片要存储到哪个分区组上,然后使用 LOB 分片的 hash 函数来计算出其挂接到哪个桶上,之后在 LOBD 及 LOBM 文件中分配数据页,完成数据写入,LOBM 中的页挂到对应的桶上。
2)读取LOB
在获取 LOB 数据时,需要指定其 OID值。引擎根据OID值获取 sequence 值为0的分片,从中读出 LOB 的元数据信息,然后进行分片计算,确定所有分片信息,向所有包含分片的分区组发送请求。
当协调节点接收到各级返回的分片数据后,按 sequence 的顺序对 LOB 数据进行合并还原,以获取完整的 LOB 数据。
3)标准 Posix文件系统接口
除了LOB的API之外,目前提供SequoiaFS文件系统,它是基于FUSE在Linux系统下实现的一套文件系统,支持通用的文件操作API。SequoiaFS利用SequoiaDB的集合存储文件和目录的属性信息,LOB对象存储文件的数据内容,从而实现了类似NFS分布式网络文件系统。用户可以将远程SequoiaDB的某个集合通过映射的方式挂载到本地节点,从而在挂载节点的目标目录下可以通过通用文件系统API对文件和目录进行操作。
4.小结
根据Gartner的报告,Multi-Model多模是数据库领域近年兴起的一个主要的技术方向之一,其代表了在云化架构下,多类型数据管理的一种新理念,也是简化运维、节省开发成本的一个新选择。
SequoiaDB的Multi-Model数据库产品,目前已经在许多行业的到了应用,这也证明市场正在慢慢接受这一新的数据库架构。我们也看到MySQL,PostgreSQL等数据库也在开始支持JSON等多类型格式,也在朝着Multi-model的方向发展。未来相信各产品也会持续保持创新,出现更多Multi-model的数据库产品。
另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流