小白学数据之NoSQL数据库 进阶篇

本文涉及的产品
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
简介:

写在前面


这篇是小白学数据系列的NoSQL数据库的第二篇:进阶篇。数据分析方向的从业人员可以从中获取数据仓库软件市场的现状和分析,以增加自己的知识储备,为可能的技术转型打基础。而工程师可以找到关于NoSQL主流产品的分析介绍以及选择数据库的一些准则。NoSQL不是万能药,采用技术最好不要跟风,选择适合自己数据和应用的才是最好的哟~没有看过NoSQL基础篇的读者可以在文末的历史文章回顾中找到。


◆ ◆ 


小白问:上次问了NoSQL,SQL的区别,好像有点忘了,我们可以温故而知新一下吗?

答:。。。好吧,上次我们说了他们主要有两个区别:第一就是数据建模的方式不同,SQL是采用表格的模型,虽然比较简洁整齐但是前期建模需要的投入比较大,并且之后如果想要更改这个模型是一件非常困难的事情;第二就是系统的可扩展性不同,NoSQL可以非常简单的加入新的机器进行分布式运行,而SQL数据库则需要进行复杂的分片过程,给使用数据库的应用增加复杂度。


小白问:这几天听说了一个叫做数据仓库的东西,这个和数据库有什么关系吗?

答:从技术上讲,数据仓库是数据库的一种。从功能上讲,数据库分成两种:一种是实时系统(也叫线上交易处理OLTP),另外一种就是数据仓库了(也叫线上分析处理OLAP)。


实时系统主要的功能是日常的操作处理。假设我们有一个卖煎饼的电子商务网站,那我们的电子商店应用连接的系统就是实时的OLTP系统,这个数据库中的信息永远是最新的,每次有人从我们的网站买煎饼,这个交易都要马上记录在数据库中可以进行发货客服等服务,关心和操作这些数据的人主要是公司的一线职工比如快递小哥以及一线的管理人员比如销售经理。这个系统单个的请求一般来说都比较简单,而由于买我们煎饼的人数很多,所以要保障这个系统的吞吐量。


然而公司的CEO和高层管理人员对数据有不同的诉求,他们希望可以通过分析数据来了解公司产品销售和财务的健康状况,进行分析和决策。有可能通过分析表明,煎饼中的薄脆会很快的售罄,那产品决策者可以增加薄脆原料的采购量。这个时候如果继续使用我们前面的实时OLTP系统就出现了两个问题。第一,由于实时系统中的数据建模是根据日常操作的需求来进行的,当需要大规模的复杂查询和计算的时候就比较捉急了。而数据仓库OLAP中的建模是专门为这个数据分析的需求而产生的,可以很快的进行聚集类的计算(比如平均日销售量,年销售总量等)。第二,由于实时系统对性能的要求很高,如果CEO需要的查询结果夺取了日常运营的资源,那就得不偿失了。数据仓库的解决方案就是定期将实时系统中新增的信息移到数据仓库中,也就是同样的一份信息用不同的方式存了两遍,这两个地方的数据模型并不相同,这样CEO和外卖小哥就不会互相影响了!


小白问:你说数据仓库中的信息是定时增加的,那就是说这里面的信息不是最全面的吗?

答:你说的对,数据仓库的信息会有些滞后,但是我们煎饼公司的决策人员想得到的是销售趋势而不是精细的信息,有个那么几天的延迟一般来说也没有什么关系。数据科学家的战场也是在数据仓库中哦!


小白问:那NoSQL数据库一般是作为实时的还是数据仓库呢?

答:在目前来说NoSQL更加常见的应用是实时的OLTP实时数据库,因为我们上次说了NoSQL的强项主要在于高度可扩展性和灵活的建模,这都是实时系统非常需要的东西,而对于进行聚集的查询所需要的计算能力还有待提高。新兴的大数据技术中最适合OLAP数据仓库的就是Hadoop相关的技术了,这里我们就不展开说了。


下面这个图是来自于高德纳咨询公司(Gartner,全球最具权威的IT研究公司)在2015年2月发布的对数据仓库OLAP的市场分析。我们可以看到,在领导者(Leaders)的这个象限中仍然只有传统的大型公司,比如大家都熟悉的甲骨文(Oracle),微软(Microsoft)和IBM。而新兴的技术进入这个名单的只有寥寥不多的几家,其中包括:亚马逊云服务 (Amazon Web Services)提供的数据分析服务,提供Hadoop相关软件的Cloudera和MapR公司以及提供文档型NoSQL数据库的MarkLogic公司。等会我们会看到,在高德纳公司提供的实时数据库的分析报告中则是百花齐放和群雄争霸的一个场面。而在数据仓库这个方面,还是传统公司占据主要的市场份额,而新兴的大数据分析系统还有待进一步的成熟。



图注:高德纳2015OLAP数据仓库系统市场分析


◆ ◆ 

深入聊聊


小白问:NoSQL的数据建模方式有哪几种呢?我记得上次提到文档和图,还有别的吗?

答:记性不错!主要有下面的四种:

1.键值型(Key-Value) 

2.列存储型 (Wide-Column)

3.文档型 

4.图型


下面我就简单介绍一下这四种数据库的建模方式,你可以参照下面高德纳的实时系统OLTP报告来对号入座,我会给一些这个图中的例子,给他们分到不同的类别中:

 

图注:高德纳2015OLTP实时数据库系统市场分析


1.键值型数据库


这是NoSQL中数据模型中最简单的一个了,主要就是用哈希表,通过对于键(Key)的查找来找到特定的数据。键值型数据库最大的优势其实就是它非常简单,很容易部署在应用中。而缺点就是这个模型过于简单,对于数据没有任何结构化的认知,只是知道返回了一坨数据,里面是什么完全没有概念。这种NoSQL数据库最典型的应用就是作为缓存,用来增加查询的性能,其实已经不能算作一个数据库了。可以在上面图中的领导象限看到Redis Lab,这个公司提供的产品Redis已经是风靡一时的缓存产品了,各大公司都用它!

 

2.列存储型数据库


这个数据模型其实和SQL的数据模型很像,都是存储在一个表格形状中的,但是有几个很重要的不同点。首先,在将数据放入列存储NoSQL数据库之前是不需要知道有那些列和列的具体信息的,而SQL是必须要这些信息才可以用的。另外每一行并不是在每一列都是有数据的,这是一个非常稀疏的表格。这种产品的可扩展性都很不错,上面表中就有在领导象限中DataStax公司所提供的产品Cassandra。

 

3.文档型数据库


我们上一篇文章中用JSON的例子就是文档型数据库,这些产品的优势在于数据建模非常的灵活,而且可以对数据的结构有所了解进行更加精确的查询。但是目前由于没有统一的查询语法,不同的产品的查询语言非常不一样。这个类型中的代表性产品有:MongoDB和MarkLogic,这两个公司都已经成为了市场的领导者之一。


 

4.图型数据库


图型数据库可以实用灵活的模型,对于社交网络方向的要求非常适合,只要是图结构的应用都是图型数据库的强项。这个类型的代表产品是Neo科技公司的Neo4j。

 


小白问:这么多不一样的NoSQL数据库我都晕了,我有选择障碍症啊,求问怎么选数据库?

答:这个当然是方方面面的了,需要考虑和公司已有的人才和技术资源的兼容性,以及产品价格和拥有产品后的支出,即使采用的是开源的产品也要考虑公司花大钱请来的程序员在这维护和建立系统方面花的时间,计算拥有系统的总支出。


如果从技术方面考虑的话就更多了,最主要就是要理解需求,下面有几个关键的点:

1. 如果你需要的是一个分析系统,而建模不需要太灵活的话,SQL数据库仍然是最好的选择。

2. 如果需要灵活的建模以及分析大规模的数据的话,可以考虑Hadoop或者Spark的解决方案。

3. 如果你需要的是一个实时系统,要考虑对已经拥有的数据,怎样建模最适合(文档,图型还是稀疏表格)。

4. 实时系统要考虑对事务的需求。所谓事务就是有一系列的数据库操作,这些操作要么都做要么都不做。比如你给小灰支付宝转账10块钱,最后要么成功了:你少10块,小灰多10块;要么你余额不足失败了,这时候两个人的余额都不变。不能出现别的可能性。SQL数据库是支持事务的,但是很遗憾很多的NoSQL是不支持事务的(比如MongoDB)。如果应用对这些方面有要求,注意选择有相关功能的数据库。

5.除此之外还要考虑如果集群中有机器宕机了会发生什么,备份是怎样进行的,如何检测系统的性能并调式性能等等等等......

俗话说的好,欲善其事必先利其器。选好了数据库系统可以让你的应用开发和数据分析事半功倍哟!


小白问:NoSQL是一个新兴的科技,你觉得在未来的一段时间会朝怎样的方向发展呢?

答:这个问题好,我觉得这几个发展方向是值得关注的:

1.对于数据仓库的应用会出现性能更加好的解决方案,毕竟是CEO时常需要的东西呢。比如和BI工具的连接也会加强的。

2.目前采用NoSQL系统的企业主要分布在金融和电信等行业,应该会出现针对于这些行业特定应用(比如CRM和金融中的风控)的整体解决方案打包产品。

3.技术方面更加成熟,更多的产品会支持事务等其他企业需要的功能。


◆ ◆ 


这是小白学数据系列第一次写进阶篇的文章,意在给读过基础篇并对NoSQL有进一步兴趣的读者提供更多的信息。其他的话题,我们的设想也是基础篇+进阶篇的结构。便于我们更好地给读者提供有帮助的文章,请帮我们填写一下。谢谢!


原文发布时间为:2016-05-03

本文来自云栖社区合作伙伴“大数据文摘”,了解相关信息可以关注“BigDataDigest”微信公众号

相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
17天前
|
存储 缓存 数据库
数据库数据删除策略:硬删除vs软删除的最佳实践指南
在项目开发中,“删除”操作常见但方式多样,主要分为硬删除与软删除。硬删除直接从数据库移除数据,操作简单、高效,但不可恢复;适用于临时或敏感数据。软删除通过标记字段保留数据,支持恢复和审计,但增加查询复杂度与数据量;适合需追踪历史或可恢复的场景。两者各有优劣,实际开发中常结合使用以满足不同需求。
65 4
|
1月前
|
数据库 Python
【YashanDB知识库】python驱动查询gbk字符集崖山数据库CLOB字段,数据被驱动截断
【YashanDB知识库】python驱动查询gbk字符集崖山数据库CLOB字段,数据被驱动截断
|
17天前
|
人工智能 关系型数据库 分布式数据库
让数据与AI贴得更近,阿里云瑶池数据库系列产品焕新升级
4月9日阿里云AI势能大会上,阿里云瑶池数据库发布重磅新品及一系列产品能力升级。「推理加速服务」Tair KVCache全新上线,实现KVCache动态分层存储,显著提高内存资源利用率,为大模型推理降本提速。
|
2月前
|
SQL 数据建模 BI
【YashanDB 知识库】用 yasldr 配置 Bulkload 模式作单线程迁移 300G 的业务数据到分布式数据库,迁移任务频繁出错
问题描述 详细版本:YashanDB Server Enterprise Edition Release 23.2.4.100 x86_64 6db1237 影响范围: 离线数据迁移场景,影响业务数据入库。 外场将部分 NewCIS 的报表业务放到分布式数据库,验证 SQL 性能水平。 操作系统环境配置: 125G 内存 32C CPU 2T 的 HDD 磁盘 问题出现的步骤/操作: 1、部署崖山分布式数据库 1mm 1cn 3dn 单线启动 yasldr 数据迁移任务,设置 32 线程的 bulk load 模式 2、观察 yasldr.log 是否出现如下错
|
2月前
|
JSON Java 关系型数据库
Hutool创建数据源工厂动态查询不同数据库不同数据表的数据
Hutool创建数据源工厂动态查询不同数据库不同数据表的数据
55 2
|
1月前
|
SQL Java 数据库连接
【YashanDB数据库】由于网络带宽不足导致的jdbc向yashandb插入数据慢
由于网络带宽不足导致的jdbc向yashandb插入数据慢
|
1月前
|
关系型数据库 MySQL Java
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
|
1月前
|
关系型数据库 MySQL 数据库连接
docker拉取MySQL后数据库连接失败解决方案
通过以上方法,可以解决Docker中拉取MySQL镜像后数据库连接失败的常见问题。关键步骤包括确保容器正确启动、配置正确的环境变量、合理设置网络和权限,以及检查主机防火墙设置等。通过逐步排查,可以快速定位并解决连接问题,确保MySQL服务的正常使用。
330 82
|
3天前
|
负载均衡 算法 关系型数据库
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。

热门文章

最新文章

下一篇
oss创建bucket