1、关系数据库
特点:数据集中控制;减少数据冗余等。
适用范围:对于结构化数据的处理更合适,如学生成绩、地址等,这样的数据一般情况下需要使用结构化的查询。
2、非关系数据库
特点:易扩展;大数据量,高性能;灵活的数据模型等。
使用范围:据模型比较简单;需要灵活性更强的IT系统;对数据库性能要求较高。
扩展资料:
非关系数据库的分类:
1、列存储数据库
这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在,但是它们的特点是指向了多个列。这些列是由列家族来安排的。如:Cassandra, HBase, Riak。
2、文档型数据库
文档型数据库的灵感是来自于Lotus Notes办公软件的,而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档,半结构化的文档以特定的格式存储,比如JSON。文档型数据库可 以看作是键值数据库的升级版,允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如:CouchDB, MongoDb 国内也有文档型数据库SequoiaDB,已经开源。
参考资料来源:百度百科-数据库
参考资料来源:百度百科-NoSQL
大数据的常见处理流程
具体的大数据处理方法其实有很多,但是根据长时间的实践,笔者总结了一个基本的大数据处理流程,并且这个流程应该能够对大家理顺大数据的处理有所帮助。整个处理流程可以概括为四步,分别是采集、导入和预处理、统计和分析,以及挖掘。
采集
大数据的采集是指利用多个数据库来接收发自客户端(Web、App或者传感器形式等)的数据,并且用户可以通过这些数据库来进行简单的查询和处理工作。比如,电商会使用传统的关系型数据库MySQL和Oracle等来存储每一笔事务数据,除此之外,Redis和MongoDB这样的NoSQL数据库也常用于数据的采集。
在大数据的采集过程中,其主要特点和挑战是并发数高,因为同时有可能会有成千上万的用户来进行访问和 *** 作,比如火车票售票网站和淘宝,它们并发的访问量在峰值时达到上百万,所以需要在采集端部署大量数据库才能支撑。并且如何在这些数据库之间进行负载均衡和分片的确是需要深入的思考和设计。
导入/预处理
虽然采集端本身会有很多数据库,但是如果要对这些海量数据进行有效的分析,还是应该将这些来自前端的数据导入到一个集中的大型分布式数据库,或者分布式存储集群,并且可以在导入基础上做一些简单的清洗和预处理工作。也有一些用户会在导入时使用来自Twitter的Storm来对数据进行流式计算,来满足部分业务的实时计算需求。
导入与预处理过程的特点和挑战主要是导入的数据量大,每秒钟的导入量经常会达到百兆,甚至千兆级别。
统计/分析
统计与分析主要利用分布式数据库,或者分布式计算集群来对存储于其内的海量数据进行普通的分析和分类汇总等,以满足大多数常见的分析需求,在这方面,一些实时性需求会用到EMC 的GreenPlum、Oracle的Exadata,以及基于MySQL的列式存储Infobright等,而一些批处理,或者基于半结构化数据的需求可以使用Hadoop。
统计与分析这部分的主要特点和挑战是分析涉及的数据量大,其对系统资源,特别是I/O会有极大的占用。
挖掘
与前面统计和分析过程不同的是,数据挖掘一般没有什么预先设定好的主题,主要是在现有数据上面进行基于各种算法的计算,从而起到预测(Predict)的效果,从而实现一些高级别数据分析的需求。比较典型算法有用于聚类的K-Means、用于统计学习的SVM和用于分类的Naive Bayes,主要使用的工具有Hadoop的Mahout等。
该过程的特点和挑战主要是用于挖掘的算法很复杂,并且计算涉及的数据量和计算量都很大,还有,常用数据挖掘算法都以单线程为主。
数据库共有3种类型,为关系数据库、非关系型数据库和键值数据库。
1、关系数据库
MySQL、MariaDB(MySQL的代替品,英文维基百科从MySQL转向MariaDB)、Percona Server(MySQL的代替品·)、PostgreSQL、Microsoft Access、Microsoft SQL Server、Google Fusion Tables、FileMaker、Oracle数据库、Sybase、dBASE、Clipper、FoxPro、foshub。
几乎所有的数据库管理系统都配备了一个开放式数据库连接(ODBC)驱动程序,令各个数据库之间得以互相集成。
2、非关系型数据库(NoSQL)
BigTable(Google)、Cassandra、MongoDB、CouchDB。
3、键值(key-value)数据库
Apache Cassandra(为Facebook所使用):高度可扩展、Dynamo、LevelDB(Google)。
扩展资料:
数据库模型:对象模型、层次模型(轻量级数据访问协议)、网状模型(大型数据储存)、关系模型、面向对象模型、半结构化模型、平面模型(表格模型,一般在形式上是一个二维数组。如表格模型数据Excel)。
数据库的架构可以大致区分为三个概括层次:内层、概念层和外层。
参考资料来源:百度百科—数据库
数据库有两种类型,分别是关系型数据库与非关系型数据库。
数据库,简而言之可视为电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据进行新增、截取、更新、删除等 *** 作。
关系型数据库主要有:
Oracle、DB2、Microsoft
SQL
Server、Microsoft
Access、MySQL等等。
非关系型数据库主要有:
NoSql、Cloudant、MongoDb、redis、HBase等等。
扩展资料:
非关系型数据库的优势:
1、性能高:NOSQL是基于键值对的,可以想象成表中的主键和值的对应关系,而且不需要经过SQL层的解析,所以性能非常高。
2、可扩展性好:同样也是因为基于键值对,数据之间没有耦合性,所以非常容易水平扩展。
关系型数据库的优势:
1、可以复杂查询:可以用SQL语句方便的在一个表以及多个表之间做非常复杂的数据查询。
2、事务支持良好:使得对于安全性能很高的数据访问要求得以实现。
参考资料来源:百度百科-数据库
数据库是存放数据的仓库。它的存储空间很大,可以存放百万条、千万条、上亿条数据。但是数据库并不是随意地将数据进行存放,是有一定的规则的,否则查询的效率会很低。当今世界是一个充满着数据的互联网世界,充斥着大量的数据。即这个互联网世界就是数据世界。数据的来源有很多,比如出行记录、消费记录、浏览的网页、发送的消息等等。除了文本类型的数据,图像、音乐、声音都是数据。
数据库是一个按数据结构来存储和管理数据的计算机软件系统。数据库的概念实际包括两层意思:
(1)数据库是一个实体,它是能够合理保管数据的“仓库”,用户在该“仓库”中存放要管理的事务数据,“数据”和“库”两个概念结合成为数据库。
(2)数据库是数据管理的新方法和技术,它能更合适的组织数据、更方便的维护数据、更严密的控制数据和更有效的利用数据。
发展现状
在数据库的发展历史上,数据库先后经历了层次数据库、网状数据库和关系数据库等各个阶段的发展,数据库技术在各个方面的快速的发展。特别是关系型数据库已经成为目前数据库产品中最重要的一员,80年代以来, 几乎所有的数据库厂商新出的数据库产品都支持关系型数据库,即使一些非关系数据库产品也几乎都有支持关系数据库的接口。这主要是传统的关系型数据库可以比较好的解决管理和存储关系型数据的问题。随着云计算的发展和大数据时代的到来,关系型数据库越来越无法满足需要,这主要是由于越来越多的半关系型和非关系型数据需要用数据库进行存储管理,以此同时,分布式技术等新技术的出现也对数据库的技术提出了新的要求,于是越来越多的非关系型数据库就开始出现,这类数据库与传统的关系型数据库在设计和数据结构有了很大的不同, 它们更强调数据库数据的高并发读写和存储大数据,这类数据库一般被称为NoSQL(Not only SQL)数据库。 而传统的关系型数据库在一些传统领域依然保持了强大的生命力。
数据库管理系统
编辑
数据库管理系统是为管理数据库而设计的电脑软件系统,一般具有存储、截取、安全保障、备份等基础功能。数据库管理系统可以依据它所支持的数据库模型来作分类,例如关系式、XML;或依据所支持的计算机类型来作分类,例如服务器群集、移动电话;或依据所用查询语言来作分类,例如SQL、XQuery;或依据性能冲量重点来作分类,例如最大规模、最高运行速度;亦或其他的分类方式。不论使用哪种分类方式,一些DBMS能够跨类别,例如,同时支持多种查询语言。
如何选择数据库
柳树
公众号:柳树的絮叨叨
关注他
30 人赞同了该文章
我们正在做一个电子书小程序。
10 层次模型数据库
用户购买,生成订单,订单详情里有用户购买的电子书:
一层一层铺开,一对多,这是「层次模型数据库」(Hierarchical Database)。
20 网状模型数据库
一笔订单可以购买多本电子书,一本电子书也可以被多笔订单购买:
这就形成了「多对多」的「网状模型数据库」(Network Database)。
上面讲的两种数据库,也许你听都没听过。
我们用的,是「关系模型」,而非上面的「层次模型」或者「网状模型」。
为什么?
你会说,这样不方便遍历所有订单。
并不会,再加一个根节点就好:
你会说,这样查找效率很低。
也不会,因为可以优化下数据结构,比如换成 B+ 树。
为什么我们从一开始就在用「关系模型数据库」?
30 关系模型数据库
无论是层次模型还是网状模型,程序员看到的,都是实实在在的物理存储结构。
查询时,你要照着里面的数据结构,用对应的算法来查;
插入时,你也要照着数据结构,用对应算法来插入,否则你就破坏了数据的组织结构,数据也就坏掉了。
因为我们都没用过前面两种数据库,所以觉得「关系模型数据库」(以下简称 RDB)的一切都理所当然,但其实,它做出了一个革命性的变革:
用逻辑结构(logical representation of data)代替物理结构(physical representation of data)
所谓「逻辑结构」,也就是我们经常看到的「表格」,User 是一张表格,Order 是一张表格,Book 又是一张表格,它们之间的关系,用 id 来关联,这些 id,可能是 number 类型,也可能是 string 类型
但你看到的,不一定就是实际的,你看到的只是让你方便理解的「逻辑结构」,真实数据自然不是这样按表格来存储,表格无异于一个数组,数组查询是很慢的。
真实的「物理结构」,也许还是像「层次模型」和「网状模型」一样,是复杂的数据结构。
但到底是怎样的数据结构,你都无需关心,你只需把它想象成一张「表」去 *** 作,就连可视化工具,都会帮你把数据可视化成表,来方便你理解。
这个观念的提出,来自于 1970 年 Codd 的一篇论文,A Relational Model of Data for Large Shared Data Banks:
Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation)
Activities of users at terminals and most application programs should remain unaffected when the internal representation of data is changed and even when some aspects of the external representation are changed
—— Codd
Codd 的这种思想,其实就是经济学里提到的:分工产生效能。
程序员们不需要直接和物理结构打交道,只负责告诉数据库,他想做什么,至于数据是如何存储、如何索引,都交给数据库,最终他们看到的就是一张张特别直观、特别好理解的 excel 表格。
而数据库则把维护物理结构的复杂逻辑,交给了自己, 对程序员屏蔽了复杂的实现细节。
开发时写的代码少了,耦合性降低了,数据也不容易损坏,也就提高了生产效率(productive)。
一切能用同样的耗能,带来更多效能的技术,都会被广泛使用。
NoSQL
那后来为什么又有了 NoSQL 呢?
在 RDB 被发明的时代,软件多用于大型企业,比如银行、金融等等,人们对数据的要求非常纯粹:准确、可靠、安全,让数据按照期望,正确的写入,不要给老子算错钱就好,于是有了具有 ACID 特性的事务:原子性、一致性、隔离性和持久性。
那时候用网络的人很少,通过终端来访问客户端的人,更少,自然的,数据库的数据量和访问量都跟现在没法比,一台机器,足矣,最多再来个一主多从:
后来,你知道的,每个人手里都有个手机,每分每秒,都有成千上万的数据,写入你的数据库、从你的数据库被查出,于是有了「分布式」,有了 BASE 和 CAP。这时候,RDB 就会发现,自己之前的那一套 ACID,竟然有点作茧自缚了:
为了保证事务的隔离性,要进行加锁,在分布式的环境下,就要对多台机器的数据进行加锁;
为了保证事务的原子性,在机器 A 的 *** 作和在机器 B 的 *** 作,要么一起成功,要么一起失败;
…
这些都要去不同节点的机器进行通讯和协调,实现起来非常复杂,而且要付出更多的网络 IO,影响性能。
ACID 在分布式系统上实现起来就会变得难以实现,即使实现了,也要付出很大的性能成本,于是才有了后来的各种「分布式一致性协议」,Paxos、Raft、2PC …… 而 Mysql 也提供了各种方案来实现分布式,当然,这些方案自然是很复杂的,比如 「NDB Cluster」 :
而 NoSQL 则没有这么多承诺,它的一致性,一般都是最终一致性,当然你可以选择强一致,那自然就要付出点性能作为代价,当然你还可以弱一致,这样会更不安全,但是更快,一切取决于你对数据的要求。
除此之外,RDB 的「数据库范式」(Database Schema),也成了限制扩展性的瓶颈。为了避免数据冗余导致的各种问题(占用空间、删除异常、更新异常等等),我们在设计关系模型时,通常都是按照最小单位来设计的。
什么叫最小单位,比如用户有地址和爱好,那么在正确设计的关系模型(比如 3NF)里,这就是三张表:
如果这三张表被分散在不同的机器,那进行关联查询时,就需要多次跨机器的通讯;
而对于 NoSQL,这三类信息,都可以利用 Json 格式的数据,将它们存放在一起:
完整的存储进去,完整的取出来,不需要额外的 *** 作。
NoSQL 比 RDB 有更强的扩展性,可以充分利用分布式系统来提升读写性能和可靠性。
这不是谁设计好坏的问题,而是跟他们要解决的问题有关:RDB 诞生于互联网萌芽的时代,那时数据的准确、可靠是最重要的,而 NoSQL 诞生于互联网快速发展普及的时代,大数据、分布式、扩展性成了数据库的另一个重要特性。
总结一下:
RDB 首先得是准确、可靠,然后才向更高的「可拓展性」发展;
而 NoSQL 生而分布式,可拓展性强,然后才向更高的「准确性」发展。
NoSQL ,not only SQL,其实就是对那种打破了 RDB 严格事务和关系模型约束的那些数据库的泛指,而随着要解决的问题的不同,又诞生了各种各样的 NoSQL。
首先是「列式数据库」(Column-oriented DBMS),数据量上去了,我们想分析网站用户的年龄分布,简单说,就是你需要对同一个特征进行大数据量的分析统计,于是把原来 RDB 的「按行存储」的范式打破,变成了「按列存储」,比如 HBase;
然后你发现有些数据变动不是很大,但是经常需要被查询, 查询时还要关联很多张表,于是你把这些来自不同表的数据,揉成一个大对象,按 key-value 的格式存起来,比如 Redis;
再后来你需要对博客内容进行相关性搜索,传统 RDB 不支持相关性搜索,最重要的,还是扩展性差,增加机器的带来边际效益有限,于是有了「全文搜索引擎」,比如 Elasticsearch;
除此之外,还有「文档数据库」、「图形数据库」……
没有一种数据库是银d。
总结
这篇文章的题目是「如何选择数据库」,这是困扰很多人的问题,那么多数据库,到底要选什么好?
可是当你问出这样一个问题时,其实你是在问一种「手段」。我现在要做这样一个需求,用什么数据库可以帮我实现它?
但其实你需要的不只是一种「手段」,因为如果对方甩给你一个冷冰冰的名字,Mysql、Elasticsearch、MongoDB,你肯定会问,凭什么?
你需要的,是一种「解决方案」。如果你需要数据十分严格准确,分毫不差,那我会推荐你采用「事务」和「关系模型」来处理数据;如果你需要数据能够被大量读取和写入,那我会推荐你扩展性强的「分布式」;如果你的数据经常是整个读取、整个更新的,那「关系模型」就没有「文档模型」适合你。
「事务」、「关系模型」、「分布式」、「文档模型」等等,这些就是「解决方案」,知道用什么「解决方案」,用哪个数据库,自然水到渠成。
正如一位大牛说的:
设计实践中,要基于需求、业务驱动架构。无论选用 RDB/NoSQL,一定是以需求为导向,最终数据存储方案必然是各种权衡的综合性设计。用户不会因为你用了 Mysql 或者 MongoDB 而使用你的软件,毕竟绝大多数用户都不知道 Mysql 和 MongoDB 是什么玩意。
随着互联网的不断发展,有时候企业需要使用不同的开源数据库来搭建自己的在线平台。下面我们就一起来了解一下,在选择数据库的时候我们都有哪些方法可以使用。
有一个明确的目标
这一点看似简单,但在和很多人聊过MySQL、MongoDB、PostgreSQL之后,我觉得这一点才是重要的。面对繁杂的开源数据库,更需要明确自己的目标。无论这个数据库是作为开发用的标准化数据库后端,抑或是用于替换遗留代码中的原有数据库,这都是一个明确的目标。目标一旦确定,就可以集中精力与开源软件的提供方商讨更多细节了。
了解你的工作负载
尽管开源数据库技术的功能越来越丰富,但这些新加入的功能都不太具有普适性。譬如MongoDB新增了事务的支持、MySQL新增了JSON存储的功能等等。目前开源数据库的普遍趋势是不断加入新的功能,但很多人的误区却在于没有选择适合的工具来完成自己的工作——这样的人或许是一个自大的开发者,又或许是一个视野狭窄的主管——终导致公司业务上的损失。致命的是,在业务初期,使用了不适合的工具往往也可以顺利地完成任务,但随着业务的增长,很快就会到达瓶颈,尽管这个时候还可以替换更合适的工具,但成本就比较高了。例如,如果你需要的是数据分析仓库,关系数据库可能不是一个适合的选择;如果你处理事务的应用要求严格的数据完整性和一致性,就不要考虑NoSQL了。
不要重新发明轮子
在过去的数十年,开源数据库技术迅速发展壮大。开源数据库从新生,到受到质疑,再到受到认可,现在已经成为很多企业生产环境的数据库。企业不再需要担心选择开源数据库技术会产生风险,因为开源数据库通常都有活跃的社区,可以为越来越多的初创公司、中型企业甚至500强公司提供开源数据库领域的支持和三方工具。
先从简单开始
你的数据库实际上需要达到多少个9的可用性对许多公司来说,“实现高可用性”仅仅只是一个模糊的目标。当然,常见的答案都会是“它是关键应用,我们无论多短的停机时间都是无法忍受的”。北京IT培训发现数据库环境越复杂,管理的难度就越大,成本也会越高。理论上你总可以将数据库的可用性提得更高,但代价将会是大大增加的管理难度和性能下降。所以,先从简单开始,直到有需要时再逐步扩展。
数据库有两种类型,分别是关系型数据库与非关系型数据库。
1、关系数据库
包括:MySQL、MariaDB(MySQL的代替品,英文维基百科从MySQL转向MariaDB)、Percona Server(MySQL的代替品)、PostgreSQL、Microsoft Access、Microsoft SQL Server、Google Fusion Tables。
FileMaker、Oracle数据库、Sybase、dBASE、Clipper、FoxPro、foshub。几乎所有的数据库管理系统都配备了一个开放式数据库连接(ODBC)驱动程序,令各个数据库之间得以互相集成。
2、非关系型数据库(NoSQL)
包括:BigTable(Google)、Cassandra、MongoDB、CouchDB、键值(key-value)数据库、Apache Cassandra(为Facebook所使用):高度可扩展、Dynamo、LevelDB(Google)。
扩展资料:
数据库的作用
数据库管理系统是为管理数据库而设计的电脑软件系统,一般具有存储、截取、安全保障、备份等基础功能。
数据库管理系统可以依据它所支持的数据库模型来作分类,例如关系式、XML;或依据所支持的计算机类型来作分类,例如服务器群集、移动电话。
或依据所用查询语言来作分类,例如SQL、XQuery;或依据性能冲量重点来作分类,例如最大规模、最高运行速度;亦或其他的分类方式。不论使用哪种分类方式,一些DBMS能够跨类别,例如,同时支持多种查询语言。
参考资料来源:百度百科--数据库
以上就是关于常用的数据库有哪几种试着阐述每种数据库的特点和使用范围全部的内容,包括:常用的数据库有哪几种试着阐述每种数据库的特点和使用范围、大数据的常见处理流程、请问数据库有哪些种类呢等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)