大数据存储与管理(三)|学习笔记

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介: 快速学习大数据存储与管理(三)

开发者学堂课程【高校精品课-北京理工大学-大数据技术导论:大数据存储与管理(三)】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/857/detail/15615


大数据存储与管理(三)

 

内容介绍:

一、No SQL的兴起

二、典型的 No SQL 数据库

三、No SQL  VS 关系型数据库

四、小结

 

一、No SQL 的兴起

No SQL 非关系型数据库对应的是传统的关系型数据库,传统关系型数据库的技术非常成熟,有着非常完备的关系理论基础,有着非常强大的事务管理机制的支持,同时有着高效的查询优化的机制。这使得传统关系型数据库,曾经一度在市场上占据着主流的位置

 图片172.png

随着大数据时代的到来,以及互联网应用的兴起,身边的数据呈现爆炸式的增长。图里面我们列举了一些数据。

图片171.png

例如说,在每60秒的时间,可以产生近10万的 Twitter Tweets 以及近70万的 Facebook 的状态的更新,110万的信息的交互,以及近70万的 Google searches 的请求。我们可以看到,传统的关系型数据库,在面对这些业务的时候呈现一些不足,无法满足海量数据的管理需求,无法满足数据高并发的需求。无法满足高可扩展性以及高可用性的需求。

No SQL 在最初被理解为一味的用新型数据库代替传统的关键性数据库。但随着人们对 No SQL 的理解,发现两种数据库各有优缺点,并不可以互相取代。现在提到 No SQL 的时候,并不是说 No SQL,而是说 not only icecream。

图片170.png

也就是不仅仅是关系型数据库,No SQL 相对于传统的关系型数据库有着很多优势,比如它有更灵活的可扩展性,更加灵活的数据模型,同时它可以更好的融入云环境中,与云计算紧密的融合,提供 No SQL 的云服务。

 

二、典型的 No SQL 数据库

包括以下四种,键值数据库,Key value store 列存储数据库。Column store 文档数据库,基于 document 的数据存储以及图数据库基于 graph 的数据存储,

图片169.png

键值数据库

键值数据库中,将数据存储为 key value pair 一些键值对儿的集合,其中键作为唯一的标识符来唯一的确定值。在键值数据库中值对于数据库而言是不可见的。不能对值进行索引和查询。其中键是一个字符串的对象,而值可以是任意的数据类型,比如整型、字符型、数组或是更加复杂的列表集合等数据类型。键值数据库可以进一步的分为内存键值数据库和持久化的键值数据库,内存键值数据库,也就是说把数据保存在内存里面,典型的系统,如map cash和reads 持久化的键值数据库,也就是把数据保存在磁盘上,比如 work a DB。Oracle DB 键值数据库是一个高度可分区的数据库,有着非常好的可扩展性。

列存储数据库

列存储数据库主要是面向海量数据的分布式的存储。h base 就是一个典型的列存储数据库。列存储数据库通常采用列足的数据库,模型由多行构成,每行包括多个列。不同的行可以具有不同数量的列。在列组数据库中通过行键来进行定位,行键对应着多个列列,又以列组作为单位来组织数据。典型的列组数据库除了 h base 还有 concentrate等等。

图片168.png

文档数据库

文档数据库主要用来存储检索和管理面向文档的信息。文档是文档数据库中处理信息的一个基本单位,相当于关于数据库中的一条数据。那通常文档数据库用来存储半结构化数据。

图片167.png

在文档数据库中通常采用 XML 或者 Jason 的形式来存储文档的数据信息。

 

图片166.png

在文档数据库中通过键来唯一定位一个文档,因此也可以把文档数据库。看成键值数据库,例如在 mango DB里面,有一个 ID 字段作为文档的键值文档数据库与键值数据库不同的是,在文档数据库中值也是可以被用来建立索引的。可以基于文档的内容来进行检索,在键值数据库中值数据对于数据库来说是透明不可见的,典型的文档数据库包括coach DB mango DB 等等。

在文档数据库中,一个文档可以对它包含的数据类型和内容进行自我描述。通过下面这个事例来具体看一下。

 图片165.png

在这个事例中,对比了传统惯性数据库和文档数据库存储数据的一个方式。在关系型数据库中通过两张表格存储了人以及电话号码的信息。要去检索一个人的电话的时候,需要通过 ID 将两张表关联起来做检索。同样的信息在文档数据库中会把一个人所关联的所有信息存储在同一个文档中。所以在检索这个人的相关信息的时候,只要访问一个文档就足够了,不再需要去关联外部的数据

文档数据库中的一个文档可以包含非常复杂的数据结构,比如嵌套对象。下面这个事例里面一个文档中的某一个属性,

图片164.png

同时可以包含其他的属性,同时在每个文档中,可以拥有完全不同的数据结构,在这个事例中 bike。Paddle和Jersey都有不一样的属性,所以说文档数据库相比较于传统的数据库,有着更加灵活的数据存储模型。

图数据库

图数据库 graph database 是以图作为一个基本的数据存储模型,通过节点边和属性来表示和存储数据的。图数据库专门用于管理具有高度相互关联关系的数据,例如社交网络分析推荐系统以及路径寻找等问题。典型的图数据库包括new4j infinite graph 以及 graph DB 等等。下面这张图展示了在 new for j 系统中,我们如何用属性图模型来存储和组织数据。

图片163.png 

在属性图模型里面,有节点和边,在节点中存储了节点相关的一些属性信息以 name value pair 的形式进行存储,节点之间的边是有向边,表示节点之间的关联关系,例如公司坐落在哪一个城市,同时也具有一些属性,同样的用name和 value 的形式进行存储。

 

三、No SQL  VS 关系型数据库

两种数据库各有优缺点,无法用一种数据库去完全取代另一种传统的关系型数据库的优势在于它可以以完善的关系,代数理论作为基础,有严格的标准支持事物的 acid property 借助于索引机制可以实现高效的查询,技术更加成熟,有专业的公司做技术支持。它的劣势在于可扩展性比较差,无法较好的支持海量数据的存储,数据模型也不够灵活,无法较好的支持,WEB2.0的应用事物的机制,影响了系统的整体的性能。相灵活的数据模型,可以更好的支持,WEB2.0的应用,同时具有非常强大的横向可扩展性。它的劣势在于缺乏数学理论基础,复杂查询性能不高,大多不能实现事物的强一致性,很难实现数据完整性,同时缺乏专业的团队做技术支持,维护困难。

 

四、小结

这一章中介绍了分布式文件系统以及主流技术 HDFSHDFS 开源实现了 Google file system 可以利用廉价的硬件设备构成的计算机集群来实现海量数据的分布式存储。

分布式数据库 h base h base 是 Google 的 big table 的开源实现,支持大规模海量数据的分布式存储。

No SQL 数据库。比较来讲,No SQL 数据库可以更好的支持超大规模数据的存储。No SQL 数据库主要包括键值数据库、列图数据库、文档数据库以及图数据库四种类型,更好的满足了大数据时代,各种非结构化数据的存储需求,得到了越来越广泛的应用。

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
2月前
|
存储 算法 固态存储
大数据分区优化存储成本
大数据分区优化存储成本
38 4
|
3月前
|
存储 消息中间件 大数据
大数据-69 Kafka 高级特性 物理存储 实机查看分析 日志存储一篇详解
大数据-69 Kafka 高级特性 物理存储 实机查看分析 日志存储一篇详解
53 4
|
3月前
|
消息中间件 存储 缓存
大数据-71 Kafka 高级特性 物理存储 磁盘存储特性 如零拷贝、页缓存、mmp、sendfile
大数据-71 Kafka 高级特性 物理存储 磁盘存储特性 如零拷贝、页缓存、mmp、sendfile
80 3
|
3月前
|
存储 消息中间件 大数据
大数据-70 Kafka 高级特性 物理存储 日志存储 日志清理: 日志删除与日志压缩
大数据-70 Kafka 高级特性 物理存储 日志存储 日志清理: 日志删除与日志压缩
53 1
|
3月前
|
存储 消息中间件 大数据
大数据-68 Kafka 高级特性 物理存储 日志存储概述
大数据-68 Kafka 高级特性 物理存储 日志存储概述
34 1
|
3月前
|
存储 算法 NoSQL
大数据-138 - ClickHouse 集群 表引擎详解3 - MergeTree 存储结构 数据标记 分区 索引 标记 压缩协同
大数据-138 - ClickHouse 集群 表引擎详解3 - MergeTree 存储结构 数据标记 分区 索引 标记 压缩协同
48 0
|
3月前
|
存储 消息中间件 分布式计算
大数据-137 - ClickHouse 集群 表引擎详解2 - MergeTree 存储结构 一级索引 跳数索引
大数据-137 - ClickHouse 集群 表引擎详解2 - MergeTree 存储结构 一级索引 跳数索引
49 0
|
3月前
|
存储 SQL 分布式计算
大数据-127 - Flink State 04篇 状态原理和原理剖析:状态存储 Part2
大数据-127 - Flink State 04篇 状态原理和原理剖析:状态存储 Part2
25 0
|
3月前
|
存储 消息中间件 大数据
大数据-126 - Flink State 03篇 状态原理和原理剖析:状态存储 Part1
大数据-126 - Flink State 03篇 状态原理和原理剖析:状态存储 Part1
78 0
|
5月前
|
存储 分布式计算 算法
"揭秘!MapReduce如何玩转压缩文件,让大数据处理秒变‘瘦身达人’,效率飙升,存储不再是烦恼!"
【8月更文挑战第17天】MapReduce作为Hadoop的核心组件,在处理大规模数据集时展现出卓越效能。通过压缩技术减少I/O操作和网络传输的数据量,不仅提升数据处理速度,还节省存储空间。支持Gzip等多种压缩算法,可根据需求选择。示例代码展示了如何配置Map输出压缩,并使用GzipCodec进行压缩。尽管压缩带来CPU负担,但在多数情况下收益大于成本,特别是Hadoop能够自动处理压缩文件,简化开发流程。
82 0