当前位置:首页 > 天道酬勤 > 正文内容

nosql和mysql(hbase是nosql数据库吗)

张世龙2021年12月20日 03:56天道酬勤800

原文地址:https://mean dni.com/2020/10/04/how-to-choose -数据库/

原文作者: Joker ' s博客

虽然数据库本身功能非常单一,只能作为数据的存储介质,但由于错误的数据库选择而导致的成本是项目性能的大幅下降,对许多企业APP可能是致命的伤害。 另外,选择不同的数据库类型也将决定系统中其他模块的设计。 因此,数据库选型对整个项目非常重要,这种需求通常也被称为非功能性需求(

数据结构查询模式的数据大小目前市场上有各种各样的存储解决方案。 本文将介绍如何从这些解决方案中选择最适合自己的解决方案。

如果在

缓存

项目中经常需要调用数据库API或高延迟的远程服务,则必须首先考虑在客户端和数据库之间使用缓存来减少延迟。 目前常用的缓存解决方案有Memcached、Hazelcast、Redis,这些解决方案相似,但Redis使用最广泛、稳定,是目前国内最常用的数据库缓存

文件存储

如果需要开发嘀嗒、b站等产品,则需要存储大量的图像、视频等数据,但光靠一个数据库可能无法满足我们的需求。 在这种情况下,需要存储文件而不是一般的数据信息,因此数据库的本质仍然只能用于查询信息数据。 文件本身也不是“查询”,只需要得到整个文件。 在这种情况下,满足项目要求的解决方案是对象(Blob )存储解决方案,如Amazon S3。 通常,Blob存储解决方案还可以与CDN结合使用,以减少延迟,从而提供无地理位置差异的内容服务。

提供文本搜索功能

淘宝、京东等大型APP提供了内容检索功能,用户可以按照商品类型和品牌分类检索数据。 该功能通常使用Solr和Elasticsearch等搜索引擎服务,这种搜索服务也一般支持模糊搜索。 例如,考虑到用户的拼写错误,这次可以大幅提高用户体验。

但是,搜索引擎不是数据库,不能保证数据不会丢失,所以不能使用Elasticsearch之类的搜索引擎作为数据源。 在本例中,我们需要与这两者合作,将数据库内容加载到Elasticsearch中以减少搜索延迟,并在此基础上提供多功能性。

时序数据库(TSDB,Time series database)

时间序列数据库全部称为时间序列数据库,是关系数据库的一种,主要用于处理带时间标签(按时间顺序变化,即时间系列化)的数据,带时间标签的数据也是时间序列数据

开发股票交易和财务分析系统等对时间敏感的系统时,需要经常分析一定时间内的数据,如过去的1周、10天、1个月、1年等。 TSDB以毫秒级别的速度提供所需的数据。 传统的数据库很难实现这个。

目前市场上常用的时序数据库有OpenTSDB、InfluxDB等。

数据仓库

许多项目还需要能够存储大量数据的数据库。 例如,滴滴需要保存所有订单信息来分析哪个城市,该时间段使用率最高。 这些系统通常与普通用户可以看到的交易不同,可以使用脱机类型的数据仓库。 Hadoop是目前主流的数据仓库解决方案。

SQL OR NoSQL

开头所述,数据结构是我们用于数据库选定时的重要要素之一,在保存能够以结构化或表形式表现的数据时也可以使用关系数据库。

age/96d2288c292c4b6eaf69b41c49566907?from=pc">

同时,我们还将考虑数据库是否需要拥有 ACID ,即原子性(Atomicity),一致性(Consistency),隔离型(Isolation),持久性(Durability)四大性质。

原子性,保证所有操作要么全有要么全无一致性,保证操作前后数据库状态一致。隔离性 ,意味着多个事务单独进行,一个事务将不受另一正在进行的并行事务的影响。这能保证数据库应该能够处理并发事务而不会导致数据不一致的情况。持久性 ,保证一旦事务完成,更改将被永久写入磁盘,并且不会因系统故障而丢失。

如果我们的项目需要 ACID 属性,则需要使用关系数据库(RDBMS),如 MySQL,Oracle,Postgres 等,但是,如果不需要 ACID,那么也可以 非关系性数据库 。

例如,项目中需要为商品建立目录索引,每个商品拥通常会不同的属性和信息,如药品有保质期,冰箱有节能等级等等,再例如我们的用户表单中美味用户也可能会有不同的属性值,在这种情况家我们的数据不能够以表格形式表示,我们就需要使用 NoSQL 数据库。

另外,除了储存,我们通常还需要查询类型型数据,下面就需要考虑 查询模式 这个要素,我们会根据存储的数据类型和查询类型来决定使用哪种数据库。如果项目中会含有大量数据,包括各种各样的属性和各种各种的查询请求,就需要使用文档型数据库( Document DB ),如 Couchbase、MongoDB 。

Elasticsearch 和 Solr 也是特殊文档型数据库。

如果我们的数据并没有各种各样的属性,查询类型也很有限,简单增删改查足以,但是数据库的存储量很大,如滴滴司机的位置,这类数据每时每刻都会增加,这种情况下,我们通常会使用柱状存储模型的数据库也成 列型(Columnar DBs)数据库 ,如 Cassandra、HBase 。这类数据库每个列都有一个 column key 标识,每个 column key下对应若干 value,可以很轻松的获得包含某个列的数据。

在个人的小型项目我们通常会选择 Cassandra,因为非常轻量而且部署起来非常方便,性能也完全不亚于 HBase,而 HBase 基于 Hadoop 显得过于臃肿。因此,我们可以说在数据查询时可以直接通过 where 语句指定 key 查询时,可以选择 Cassandra。

如果我们将滴滴中与打车相关的订单数据存储在 Cassandra 后,司机的 id 可以作为每个列分区的 column key,当我们想要查询特定时间段内该司机的路程,Cassandra 就可以立即帮我们在对应列中查询到这些数据,但这时,当我们想要查询某个日期内乘客的乘车记录,由于客户 ID 并不是分区 column key,因此 Cassandra 就需要查询整个分区,这时 Cassandra 性能就会大打折扣!

这种情况下,我们可以使用不同的分区 key 将相同的数据复制到另一个表或列中,这时,当我们收到有关客户 ID 和日期的查询时,我们可以将其直接定向到分区 kay 为客户 ID 的表中,这 就是查询的种类少但数据量大 的意思,只要查询的类型相似,Cassandra(和 HBase)就可以无限扩展,但如果查询的种类非常多,那么我们就必须为每个分区键一次又一次地复制,直到达到一定的限制,如果我们不能控制查询的类型,那么就需要采用 MongoDB 之类的方案,但是,如果我们只需要针对少数几种查询的大规模扩展,那么 Cassandra 就是完美的解决方案。

现在,我们大概给出了基本的方向了,如果我们具有结构化数据并且需要 ACID 性质,则使用关系数据库(如 MySQL),如果我们拥有具有许多属性的海量数据,则可以使用文档数据库(如 Mongo DB),如果我们的数据更简单,查询种类较少,则使用列式数据库(如 Cassandra),但是实际项目中,还并不这么简单。

混合使用

我们再以淘宝为例,对于一个商品,如果我们库存中只有一件,但是很多用户想要购买,那么应该只能卖给一个用户,这就需要我们的数据库拥有 ACID 性质,因此,需要 MySql 这类关系型数据库,但是淘宝中的商品数据也在不断增加,属性也多种多样,我们也需要使用 Cassandra 这种列存储模型的 NoSQL 数据库。我们应该选择哪一种?在实际项目中,我们通常会混合使用这两种数据库,例如,将将尚未交付的订单数据存储在 MySQL 数据库中,一旦订单完成,我们就可以将其移至 Cassandra 进行永久存储。

我们的需求还会变得更复杂,加入我们需要为购买商品的客户构建一个报告系统,淘宝上的商品通常会由不同品牌、不同版本项不同的客户出售,因此,报告也不能针对单个产品,而应针对产品的子集,这类需求可以使用 Cassandra 或 MySQL 实现,但是更好的方案是使用 Mongo DB 这类文档型数据库,我们可以将订单数据的子集保存在 Mongo DB 中,这些数据可以告诉我们哪些用户在什么时候,什么日期购买了某种商品的数量。因此,如果我们要查询有多少人在上个月购买了 MacBook,我们可以从 Mongo DB 中获得订单 ID,并使用此订单 ID 来从 Cassandra 或 MySQL 中提取其他的数据。

原文地址:https://meandni.com/2020/10/04/how-to-choose-database/

原文作者:Joker's Blog

扫描二维码推送至手机访问。

版权声明:本文由花开半夏のブログ发布,如需转载请注明出处。

本文链接:https://www.zhangshilong.cn/work/25363.html

分享给朋友:

发表评论

访客

看不清,换一张

◎欢迎参与讨论,请在这里发表您的看法和观点。