数据库种类有哪些？他们各自对应怎样的应用场景？
数据库种类有哪些？他们各自对应怎样的应用场景？ 6大数据库，挖掘7种业务场景的存储更优解|完结无秘9章Download:
https://xmq1024.com/5779.html课程简介：
优秀的后端开发工程师，对于数据库存储方面，光会常规的CRUD已然不够，更需要懂各种数据库产品的优劣及适用场景，并能在适合的业务实践中准确选取合适的产品并应用。本课程利用一个社交新零售项目，带你学习如何基于不同的业务场景侧重的模式选择合适的数据库，并使用合适的设计形式，提升项目质量。
第1章 如何用更优的数据存储方案，打造更稳定的架构？7 节 | 27分钟
没有“万能”的存储设计形式，只有适合业务场景的解决方案。认清数据存储在系统架构中的重要性，并能在适合的业务实践中准确选取合适的产品并应用，才是真正优秀后端工程师的“必备技能”。
视频：1-1 没有“万能”的技术手段，只有适合业务场景的解决方案 (06:09)
视频：1-2 服务端架构常见的分层方案 (03:53)
视频：1-3 为什么要做服务端架构分层 (02:05)
视频：1-4 为什么存储数据库在架构分层中那么重要 (04:23)
视频：1-5 数据库存储的瓶颈与短板效应 (01:38)
视频：1-6 为什么互联网没有万能的解决方案 (04:39)
视频：1-7 数据库解决方案不仅仅是CRUD那么简单 (04:06)
第2章 社交新零售业务场景的演进与架构方案设计15 节 | 128分钟
本章中，将整体讲述课程中的社交新零售场景。从最初的基础电商能力，到新零售，再到社交元素加入的社交新零售业务场景的发展。基于满足业务场景要求下的全局视角，实现技术架构的分层支撑，并且利用Docker容器，实现高效部署数据库存储，轻松搭建基础的SpringBoot加Mybatis Plus的ORM接入方案。…
收起列表
视频：2-1 社交新零售业务场景的发展 (09:49)
视频：2-2 全局视角看问题，实现全景的技术支撑架构（上） (05:11)
视频：2-3 全局视角看问题，实现全景的技术支撑架构（中） (09:49)
视频：2-4 全局视角看问题，实现全景的技术支撑架构（下） (05:19)
视频：2-5 高效部署之容器化利器Docker (17:38)
视频：2-6 使用docker解决mysql的高效部署 (13:57)
视频：2-7 SpringBoot与Mybatis Plus组合 (10:13)
视频：2-8 Mybatis Plus基础能力搭建用户模块（上） (10:23)
视频：2-9 Mybatis Plus基础能力搭建用户模块（下） (14:03)
视频：2-10 Mybatis Plus进阶，高效的ORM代码实现（上） (09:33)
视频：2-11 Mybatis Plus进阶，高效的ORM代码实现（中） (08:50)
视频：2-12 Mybatis Plus进阶，高效的ORM代码实现（下） (12:06)
视频：2-13 本章小结 (01:02)
图文：2-14 重难点梳理
作业：2-15 【课后习题】阶段练练练
第3章 发挥Mysql选型优势，构建新零售核心门店与商品能力21 节 | 199分钟
针对电商核心的商品与门店的应用场景，支持事务ACID特性的Mysql数据库是最合适的解决方案，本章中，将会深度讲解Mysql选型的优劣势、事务实现原理、读写能力提升秘诀，并引入领域驱动建模的设计方式，完成商家，门店，商品，sku的底层数据模型构建，并能同步支持导购中搜索与商品详情的业务场景。…
收起列表
视频：3-1 本章概览 (00:58)
视频：3-2 Mysql选型优劣势 (07:47)
视频：3-3 Mysql如何提供事务_索引_读写的基础能力（1） (08:17)
视频：3-4 Mysql如何提供事务_索引_读写的基础能力（2） (10:58)
视频：3-5 Mysql如何提供事务_索引_读写的基础能力（3） (11:10)
视频：3-6 Mysql如何提供事务_索引_读写的基础能力（4） (03:34)
视频：3-7 Mysql如何提供事务_索引_读写的基础能力（5） (11:38)
视频：3-8 Mysql高性能配置-读写能力提升的秘诀（上） (15:24)
视频：3-9 Mysql高性能配置-读写能力提升的秘诀（下） (10:19)
视频：3-10 领域驱动设计-领域模型的重要性（上） (10:42)
视频：3-11 领域驱动设计-领域模型的重要性（下） (06:48)
视频：3-12 发布基石：商家与门店（上） (09:34)
视频：3-13 发布基石：商家与门店（下） (10:08)
视频：3-14 导购核心：商品-类目-品牌-属性库模型的发布（上） (08:10)
视频：3-15 导购核心：商品-类目-品牌-属性库模型的发布（下） (15:20)
视频：3-16 交易核心：SKU-库存模型的发布（上） (16:45)
视频：3-17 交易核心：SKU-库存模型的发布（下） (12:42)
视频：3-18 导购流程：搜索与详情浏览（上） (18:23)
视频：3-19 导购流程：搜索与详情浏览（下） (10:11)
图文：3-20 重难点梳理
作业：3-21 【课后习题】阶段练练练
第4章 高事务保证要求的交易核心能力15 节 | 162分钟
针对交易下单流程的重要业务场景，需要考虑各业务系统中的流程数据强一致性。本章中，将引入分布式事务的不同实现方案，针对下单交易流程做基于Seata的分布式事务应用，并设计支付成功的防重幂等处理，以及与订单操作生命周期的完整性方案，最终构建交易流程闭环的能力。…
收起列表
视频：4-1 下单交易：使用流程串联下单动作（上） (05:32)
视频：4-2 下单交易：使用流程串联下单动作（下） (19:49)
视频：4-3 如何用分布式事务保证下单流程一致性（上） (07:45)
视频：4-4 如何用分布式事务保证下单流程一致性（中） (17:02)
视频：4-5 如何用分布式事务保证下单流程一致性（下） (06:29)
视频：4-6 Seata对分布式事务的支持 (14:07)
视频：4-7 使用Seata改造下单流程（上） (12:07)
视频：4-8 使用Seata改造下单流程（中） (12:39)
视频：4-9 使用Seata改造下单流程（下） (04:59)
视频：4-10 支付成功：支付及防重流程（上） (12:41)
视频：4-11 支付成功：支付及防重流程（下） (15:50)
视频：4-12 用户操作完整性：手动取消订单流程 (12:19)
视频：4-13 保证生命周期完整性：自动取消订单流程（上） (07:45)
视频：4-14 保证生命周期完整性：自动取消订单流程（下） (12:34)
图文：4-15 重难点梳理
第5章 内存数据库Redis及读写分离解决查询性能瓶颈17 节 | 159分钟
高并发流量下的商品查询，使用KV型内存数据库做缓存能力的搭建，并配合关系型数据库实现读写分离的设计，可以轻松应对读多写少流量的场景。本章中，将会详细讲解Redis的优势及缓存防击穿等设计原理，并最大化的发挥Mysql读性能拓展的优势，针对性订制主从延迟问题的解决方案。…
收起列表
视频：5-1 Redis选型优劣势 (05:27)
视频：5-2 为什么Redis那么快（上） (10:15)
视频：5-3 为什么Redis那么快（中） (15:20)
视频：5-4 为什么Redis那么快（下） (06:15)
视频：5-5 实用的Redis分布式解决方案（1） (08:11)
视频：5-6 实用的Redis分布式解决方案（2） (09:43)
视频：5-7 实用的Redis分布式解决方案（3） (10:42)
视频：5-8 实用的Redis分布式解决方案（4） (06:03)
视频：5-9 如何规避Redis缓存的短板 (13:25)
视频：5-10 动手使用Redis (02:53)
视频：5-11 商品详情缓存化提升查询性能（上） (14:13)
视频：5-12 商品详情缓存化提升查询性能（下） (09:09)
视频：5-13 mysql读写分离的原理 (14:12)
视频：5-14 动手部署Mysql读写分离集群 (20:53)
视频：5-15 改造项目兜底住Mysql性能极限 (05:43)
视频：5-16 主从不一致我们该怎么办 (05:49)
图文：5-17 重难点梳理
第6章 搜索型存储ElasticSearch引擎实现全文搜索能力14 节 | 161分钟
针对商品搜索的场景，传统的非搜索型数据库是无法支持的。本章中，将介绍如何应用搜索引擎数据库ElasticSearch解决全文搜索的问题，使用全量索引构建Importer和增量索引，构建管道Canal异构出商品的搜索索引数据，并深入挖掘ES原理和分布式解决方案，做到高性能可扩展。…
收起列表
视频：6-1 ElasticSearch选型优劣势 (07:30)
视频：6-2 为什么ElasticSearch适合做全文搜索（1） (11:55)
视频：6-3 为什么ElasticSearch适合做全文搜索（2） (06:29)
视频：6-4 为什么ElasticSearch适合做全文搜索（3） (13:31)
视频：6-5 为什么ElasticSearch适合做全文搜索（4） (07:43)
视频：6-6 ES性能提升及高可用方案（上） (14:18)
视频：6-7 ES性能提升及高可用方案（下） (14:13)
视频：6-8 动手使用ES (16:24)
视频：6-9 全量索引构建 (12:50)
视频：6-10 全量索引构建 (13:17)
视频：6-11 增量索引构建（上） (14:58)
视频：6-12 增量索引构建（下） (18:20)
视频：6-13 改造商品搜索能力 (08:42)
图文：6-14 重难点梳理
第7章 社交图关系下的图数据库Neo4J解决方案8 节 | 80分钟
针对社交元素场景会存在大量的对象关系的问题，例如，关注粉丝的单向关系、好友的双向关系等，本章中，将介绍如何应用Neo4J的图形关系数据库解决图形的存储与查找问题。
收起列表
视频：7-1 图形数据结构存储如何支撑 (11:27)
视频：7-2 动手使用neo4j（上） (14:49)
视频：7-3 动手使用neo4j（下） (10:54)
视频：7-4 关注粉丝能力设计（上） (06:57)
视频：7-5 关注粉丝能力设计（中） (18:04)
视频：7-6 关注粉丝能力设计（下） (04:48)
视频：7-7 Neo4J分布式集群方案 (12:55)
图文：7-8 重难点梳理
第8章 Feed流时序性数据存储场景下的HBase解决方案17 节 | 175分钟
社交场景中最重要Feed流，可以借助关注粉丝关系，查看自己关注的人推荐的商品信息内容。本章中，将使用最适合时序场景存储的HBase做解决方案，帮助大家认清HBase的优劣势、RowKey设计应对场景快速查询索引的重要性、以及所有社交场景的推拉混合模式应，对Feed流的快速读取查询能力的最佳实践。…
收起列表
视频：8-1 Feed流的场景支撑难在哪里 (06:36)
视频：8-2 HBase原理及优劣势（上） (07:03)
视频：8-3 HBase原理及优劣势（中） (07:14)
视频：8-4 HBase原理及优劣势（下） (08:37)
视频：8-5 动手使用HBase (14:14)
视频：8-6 HBase中的RowKey为什么那么重要 (15:41)
视频：8-7 使用Java API接入HBase消息实体（上） (15:35)
视频：8-8 使用Java API接入HBase消息实体（中） (11:25)
视频：8-9 使用Java API接入HBase消息实体（下） (05:14)
视频：8-10 Feed流之经典推拉设计模式（1） (16:18)
视频：8-11 Feed流之经典推拉设计模式（2） (11:16)
视频：8-12 Feed流之经典推拉设计模式（3） (10:11)
视频：8-13 Feed流之经典推拉设计模式（4） (08:46)
视频：8-14 推拉混合模式的实践（上） (11:27)
视频：8-15 推拉混合模式的实践（下） (14:55)
视频：8-16 深度分页的高效解决方案 (09:55)
图文：8-17 重难点梳理
第9章 最像关系型数据库的非关系型数据库mongoDB满足点赞评论场景 9 节 | 82分钟
针对点赞和评论的查询场景，由于涉及查询条件又有性能要求，因此，在本章中，将选择最像关系型数据库的文档型数据库MongoDB应对，并针对点赞的流量峰值场景引入脉冲式的设计解决方案平滑流量能力。
收起列表
视频：9-1 点赞评论场景解析 (03:12)
视频：9-2 MongoDB原理及优劣势 (11:35)
视频：9-3 动手使用mongodb (12:19)
视频：9-4 使用Java API实现点赞评论能力（上） (05:11)
视频：9-5 使用Java API实现点赞评论能力（中） (13:09)
视频：9-6 使用Java API实现点赞评论能力（下） (10:50)
视频：9-7 削峰聚集能力的脉冲方案解决评论及点赞数量叠加问题（上） (08:20)
视频：9-8 削峰聚集能力的脉冲方案解决评论及点赞数量叠加问题（下） (11:08)
视频：9-9 MongoDB分布式扩展 (05:23)
Download:
https://xmq1024.com/5779.html 进入了一个大数据时代，数据的特征发生了的变化，规模大、数据多，使得大数据存储本身也需要面对很多的问题。 大数据技术当中，在海量数据的存储环节，高效率稳定安全的数据存储，才能为后面的计算分析环节，提供稳固的支持。
数据模型是数据库中数据的逻辑结构描述。 资料模型大致可分为两类：一类是独立于计算机而存在的，它不涉及信息在计算机中的表达方式； 另一类是直接面向计算机的资料模型，它以记录为单位，如数据库中常用的层次模型、网状模型和关系模型等概念模型。
36氪企服点评将为大家带来关于数据库的相关内容，一起来看看吧。
关于数据库的相关问题，你究竟了解多少？
一起看看这篇文章，带你快速了解关于数据库的全部问题！
[*]数据库的分类
[*]建立数据库的六个步骤
[*]学习数据库有什么用？
[*]数据库的应用有哪些？
一、数据库的分类
数据库的类型粗略来说可以分为关系型数据库和非关系型数据库，详细的分类如下：
1、关系型数据库Relational Database
关系型数据库的使用最为普遍流行，排名前十的数据库里就有6个是关系型数据库，如Oracle、MySQL、微软的SQL Server、PostgreSQL、IBM的DB2以及装机量最多的数据库SQLite以及大数据库的数据库Hive
2、文档型数据库Document Database
常见的有前端开发和爬虫的最爱MongoDB、Couchbase、Firebase、CouchDB
3、键值数据库Key-value Database
键值数据库常见的有Redis、Memcached
4、搜索引擎Search Engine
比如大厂必备的Elasticsearch、日志数据库Splunk
5、宽列数据库Wide Column
分布式数据库，常见的有Cassandra、HBase
6、图形数据库Graph
常见的有Neo4j
7、时序数据库Time Series
常见的有InfluxDB
早期较为时兴的数据库种类有三种，分别是层次式数据库、网络式数据库和关系型数据库。而在如今的互联网中，最常见的数据库种类主要有2种，即关系型数据库和非关系型数据库。
对于Web应用来说，数据库操作越来越成为一个性能瓶颈，这一点尤其明显。对于数据库的性能来说，不仅仅是DBA需要担心这个问题，程序员更需要关注这个问题。
在我们的工作中，数据出现的很频繁。但大多数人对数据库的建立还不太熟悉，设计数据库时，首先要准确理解和分析用户需求。那么应该怎么样去建立数据库呢。
二、建立数据库的六个步骤
1.需求分析
要求分析的任务是，通过对现实世界中所要处理的对象进行详细的调查，充分了解原系统的工作概况，明确用户的各种需求，然后在此基础上确定新的系统功能，还必须充分考虑未来可能进行的扩展和变化，而不只是根据目前的应用需求进行设计。研究的重点是数据和处理。满足信息、处理、安全和完整性的要求。
2.设计概念结构
概念性结构设计是整个数据库设计的关键，它通过综合、归纳和抽象，形成一个与具体DBMS无关的概念模型。通常有四种设计概念结构的方法：从上到下。先确定整体概念结构的框架，再逐步细化；自下而上吧，在此基础上，首先定义了各个局部应用的概念结构，然后对其进行集成，得到全局概念结构。逐渐扩大。先定义核心概念结构，然后向外扩展，以滚雪球的方式逐步产生其他概念结构，直到整个概念结构。综合战略。也就是自上而下和自下而上相结合。
3.逻辑结构设计（E-R图）
逻辑性的结构设计是将概念结构转化为某一DBMS支持的数据模型，然后进行优化。 这个阶段，E-R图显得非常重要。每个人都要学习每个实体定义的属性，画出总体E-R图。 各类E-R图的冲突有三种类型：属性冲突、命名冲突和结构冲突。从E-R图到关系模型的转换，要解决的问题是实体与实体之间的联系如何转化为关系模式，以及如何确定这些关系模式的属性和编码。
4.实体设计
在逻辑数据结构模型中，物理设计是选择一个最适合应用环境的物理结构(包括存储结构和访问方法)。第二，要充分理解RDBMS的内部特性，特别是存储器提供的存储器结构，以获取一个物理数据库设计所需的参数，以及所提供的存储器结构。常见的访问方法有三种：1。索引法，目前主要是B+树索引法。2.聚群方法(Clustering)。3.HASH方法。
5.执行数据库
在数据库执行阶段，设计者操作由DBMS提供的数据库语言(如sql)和主机语言，根据逻辑设计和物理设计的结果建立数据库，编制和调试应用程序，组织数据入库，并进行试运行。
6.数据库的运作和维护
资料库应用系统经过试运行，就可以正式运行了，数据库系统在运行过程中要不断的评估、调整、修改。
需求分析、概念结构设计、逻辑结构设计、物理设计、数据库实施阶段，根据逻辑设计和物理设计的结果建立数据库，编制和调试应用程序，组织数据入库，并进行试运行、数据库运行和维护。
三、学习数据库有什么用
数据库的作用很大，很多地方要用到，特别是与各种类型资料有关，更要用到。 资料库是用来储存网站的动态数据内容的，如果你的网站全部是静态的，也可以不用数据库，如果需要有很多动态交互信息，例如发帖和留言就需要数据库的支持。
IT行业实际上数据库虽然到处都能用到，但使用面比较广，但用到的频率却不高，并且正如一楼所说，数据库包含的东西太多太广泛，想要精益求精，一天不能学两天，它需要日积月累。
在传统的IT岗位当中，数据库管理员是比较常见的岗位之一，而且岗位附加值也相对比较高，但是随着云计算的发展，数据库本身的存储方式和应用方式正在发生较大的改变，传统的数据库管理员也发生了岗位升级
四、数据库的应用有哪些？
1. PingCAP
「PingCAP_PingCAP数据库软件」免费在线试用_怎么样_收费价格-36氪企服点评PingCAP 成立于 2015 年，是一家企业级开源分布式数据库厂商，提供包括开源分布式数据库产品、解决方案与咨询、技术支持与培训认证服务。由 PingCAP 创立的分布式关系型数据库 TiDB，有着分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活等企业级核心特性，帮助企业最大化发挥数据价值。目前，PingCAP 已经向包括中国、美国、欧洲、日本、东南亚等国家和地区，超过 1500 家企业提供服务，涉及金融、运营商、制造、零售、互联网、政府等多个行业。
http://pic1.zhimg.com/v2-bc965cb70d363348bcca0f79c726a737_r.jpg?source=1def8aca
2.MySQL
「MySQL_MySQL数据库软件」免费在线试用_怎么样_收费价格-36氪企服点评MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件。
http://picx.zhimg.com/v2-0c3222f000cd7d976f7218c579699239_r.jpg?source=1def8aca
3.Access
Microsoft AccessAccess 是一个易于使用的工具，可通过它从模板或从头开始创建商业应用程序。通过其丰富的直观工具，Access 为企业业务和客户量身打造自定义应用，按需轻松编辑以满足不断变化的要求。使用 Visual Basic for Applications，自定义业务流程、创建更有用的表单和报告。在 Access 和使用 Access 连接器库的业务线应用之间集成数据，以便在熟悉的 Access 界面中生成集成可视化项和见解，在 SQL Server 和 Microsoft Azure SQL也可存储数据。
http://pic1.zhimg.com/v2-1c3a724d069f128d52c5ce7fa3779062_r.jpg?source=1def8aca
4.Oracle 数据库
「Oracle 数据库_Oracle 数据库数据库软件」免费在线试用_怎么样_收费价格-36氪企服点评Oracle 数据库可在本地环境和云端提供市场领先的性能、可扩展性、可靠性和安全性。Oracle Database 21c 是全球广受欢迎的最新一代数据库，目前已在虚拟机（RAC 和单实例）和裸金属服务（单实例）两大 Oracle 云数据库服务中“云优先”一般可用。
http://picx.zhimg.com/v2-babbc3c765129a2662d0cc23d105dd65_r.jpg?source=1def8aca
5.AWS
「AWS_AWS云平台（PaaS）软件」免费在线试用_怎么样_收费价格-36氪企服点评Amazon Web Services (AWS) 是全球最全面、应用最广泛的云平台，从全球数据中心提供超过 175 项功能齐全的服务。从计算、存储和数据库等基础设施技术，到机器学习、人工智能、数据湖和分析以及物联网等新兴技术，AWS 提供的服务具备多种功能。AWS 的这些服务还具有最为多样复杂的功能。
http://picx.zhimg.com/v2-64b2cf1dec510b84393e078ac701b994_r.jpg?source=1def8aca
点击链接查看更多数据库产品：
数据库管理系统_数据库软件_数据库有哪些-36氪企服点评点击查看更多好文和问答：
36氪企服点评：数据分析带动增长，数据分析那你究竟了解多少？0 赞同 · 0 评论文章请问有哪些让人惊艳的数据可视化工具？0 赞同 · 0 评论回答欢迎您点击头像关注「36氪企服点评」知乎号，帮你发现更多高效实用的企服软件！更多精彩干货值得期待！或者将您的选型需求私信我们，我们将为您提供1V1的选型对接服务，有针对性的帮您推荐更适合的企服软件！ 数据库在将数据存入磁盘进行管理时，可以针对多样化的数据格式类型和数据使用需求而选择不同的数据组织方式——每种组织方式都有对应的数据库系统
[*]层次型数据库
早期的大型DBMS中使用，结构要求严格，数据被组织成强制的父子关系的树形结构，XML是最常用的数据库文件格式；
2. 关系型数据库
关系型数据库的底层数学模型是集合论和关系代数，数据表本质上是具有相同结构的数据集，数据的读写和修改操作依赖于SQL语言，关系型数据库的特殊类型有多维数据库和时态数据库；
3. 非关系型数据库（NoSQL,Not Only SQL)
非关系型数据库将数据存储为简单的字符串或完整的文件，根据需要可以通过不同的方式进行读取处理，与SQL相比，约束更少，可扩展性更强，常见类型包括列式数据库、 空间数据库、 对象/多媒体数据库、 平面文件数据库、 键值对、 基于三元组存储的数据库等。 虽然数据库的目的都是为了解决数据的存储，操作问题。
但不同的数据库有不同的侧重点，根据不同的侧重点数据库有很多分类方式。
最常见的一种分类方式是物理存储方式
如果是存储在内存中，称为内存数据库，存储在硬盘则称为数据库，还有些数据组织为组织的文件格式(xml/json等)称为文档型数据库。
第二种分类方式是按查询接口分类
早期数据库各家对查询接口实现不统一，为了方便用户国际标准组织对标准化查询接口进行了规范化，标准化查询语言(SQL)是这规范的产物，SQL把数据库操作分为数据操作语言(DML),数据定义语言(DDL),数据控制语言(DCL)等几个部分，对每一部分进行了详细的规范和定义。
随着时间的变化分别有对应的多种版本实现包括SQL-92版，SQL-99,SQL-2003/2008/2011/2016等。
SQL标准化虽然很方便数据操作但也产生了一些问题，最典型的问题就是SQL语言是基于关系理论的查询接口，不支持非关系的底层结构，另外还有SQL的复杂性，相当多的用户使用的查询是很有限的一些操作，由于实现标准SQL的语言的存储结构限制和复杂性使得一些数据库放弃了对标准SQL的支持，转而使用更简单的操作接口这一部分数据便称为NOSQL数据库，NOSQL基本上使用简单的命令式交互接口，较之于SQL一般解析和操作更快，但同时也失去了复杂操作的能力。
第三种是按存储结构模型分类
最常用的是关系型数据库，kv数据库(实质是一种松散结构化模型), 图数据库。
关系型数据库使用关系模型将数据表达为数学上的关系(组织上称为表)，SQL的操作是关系操作。
通过关系理论来保证数据的完备性和约束性。数据之间的关系组织对于数据一致性和约束有着非常良好的实现。
但对于从事数据开发的业务人员来说这种结构还是比较严格和复杂的，比如对于常用的树型结构组织在以表为单位的关系数据库定义相当不直观。
因此有些数据库便以便于业务为重心实现基础数据结构采用一种更为松散的数据存储结构，这便是常见的kv数据库实现，相较于关系型数据库基于key用了快事检索，value中直接存储常用的数据结构，可以很方便的和编程语言的数据结构对应，对于开发来说是方便的;但同时也由于没有理论的保证数据的一致性维护和复杂操作变得麻烦。
Kv数据库把数据松散化的存储方式仍然无法直接构建一些复杂的结构关系，比如一些图结构，而从结构上来说图结构是有能力实现一切的基础数据结构，因此为了底层存储结构的统一便产生了图数据库。
图数据库采用单一的图结构作为一切结构的基础上层只要提供图操作接口，便可以使图数据库有统一的访问能力。
相比之下，关系数据库更严格，kv数据库更松散，图数据库更统一。
也还有一些其它的模型，比如平面模型，半结构化模型，面向对象模型，网状模型这些多是上面几种模型的简化或结合的产物。
按是否商用可以分为免费和商用两种，一般免费的成本低，商用的服务有保障。
按是否开源可以分为开源和闭源两种，目前一般商用数据不开源，或社区版本开源，商业版高级功能不开源。
按网络化能力分为文件数据库，网络数据库和分布式/集群数据库。
一般文件型数据不提供网络访问能力，多用于独立系统或嵌入式设备开发。
网络数据库可以网络访问，多用于中小企业数据平台使用。
分布式或集群数据可以多台联合访问数据分布式存储，一般多用于大规模数据服务解决方案。
如果以表/关系为模型根据数据的行列存储不同可分为行式存储数据库和列式存储数据库。
如果数据库提供了上层业务分析功能还可以分为时序数据库，AI数据库等等。 一般来说，数据库按照组织式分为两大类：关系型数据库和非关系型数据库。
1.关系型数据库是把复杂的数据结构归结为简单的二元关系（即二维表格形式）。在关系型数据库中，对数据的操作几乎全部建立在一个或多个关系表格上，通过这些关联的表格分类、合并、连接或选取等运算来实现数据的管理。
2.非关系型数据库又称NoSQL，由于数据类型多种多样，关系型数据库并不适用于所有的数据，因此针对不同的数据类型，出现了不同的 NoSQL，NoSQL的产生并不是要彻底否定关系型数据库，而是作为传统数据库的有效补充。
http://pica.zhimg.com/v2-405290179e48e5a88fea3546c34904bf_r.jpg?source=1def8aca
关系型SQL与非关系型NoSQL对比表
注：关系型数据库的ACID：
A (Atomicity) 原子性：就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转5元至B账户，分为两个步骤：①从A账户取5元；②存入5元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了5元。
C (Consistency) 一致性：一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。例如现有完整性约束a+b=10，如果一个事务改变了a，那么必须得改变b，使得事务结束后依然满足a+b=10，否则事务失败。
I (Isolation) 独立性：是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。例如：现有有个交易是从A账户转5元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的5元的。
D (Durability) 持久性：指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
CAP理论的C就是一致性（Consistency），A就是可用性（availability），可以理解为是否可获取数据，以及获取数据的速度；P就是分区容忍度（partiontolerance），指的是系统中的数据分布性的大小对系统的正确性，性能的影响（一定程度上就是可扩展性）。
2.1
关系数据库
关系数据库是使用最广泛的数据库，采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。主要结构为：库+表+表之间的关系+字段。
http://picx.zhimg.com/v2-3b2b5887d1a7b3c4f48b6e288b62f3bd_r.jpg?source=1def8aca
关系数据库表示例表
关系数据库把复杂的数据结构归结为简单的二元关系（二维表），如上图所示是一个二维表的示例，通常该表第一行为字段名称，描述该字段的作用，下面是具体的数据。在定义该表时需要指定字段的名称及类型。目前主流的关系型数据库有OracleL、SQLServer、DB2、MySQL、PostgreSQL等。
2.2
非关系数据库
常见的非关系型数据库有键值数据库、列存储数据库、文档数据库、图数据库、时序数据库、搜索引擎数据库等，这些常见数据库的主要特点及应用场景如下表所示。
http://picx.zhimg.com/v2-93f51cf7d9fe6305a082008ac9e4cffb_r.jpg?source=1def8aca
几种常见非关系数据库的主要特点及应用场景
2.2.1 键值数据库
键值数据库可以被看作一个非常大的哈希表，该表在唯一的键下存储了一些值。存储的值可以通过键或者部分键高效地检索到。键值数据库使用简单的键值方法来存储数据。键值数据库将数据存储为键值对集合，其中键作为唯一标识符。键值数据库中的键可以包含多个元素，甚至可以排序以提高查询效率。一些键值数据库允许使用键的前缀进行查找，从而可以使用复合键。
例如，我们将客户ABC的订单存储在键/值数据库中，可以使用客户ID作为键的前缀，结合订单号组成键“ABC-001”来存储订单。可以使用整个键来检索特定的订单，也可以使用“ABC”前缀检索客户ABC的所有订单。
2.2.2 列存储数据库
列存储数据库又被称为面向可扩展性的分布式数据库，它反转了传统的行存储数据库，将数据存储存在列族中，一个列族存储经常被一起查询的相关数据。如下表所示为人员信息表：
http://pic1.zhimg.com/50/v2-595a2d95d2cc10e0de79e0fe9d1065b3_720w.jpg?source=1def8aca
对于行存储数据库，表中的数据是以行为单位逐行存储在磁盘上的；而对于列存储数据库，表中的数据则是以列为单位逐列存储在磁盘中。下图是传统行数据库和列数据库表中数据在磁盘上的存储形式的差异对比。
http://picx.zhimg.com/v2-69690e9d426c50ddc92588cf2a0fbda0_r.jpg?source=1def8aca
列存储解决的主要问题是数据查询问题，这部分数据库通常用来应对分布式存储的海量数据，典型的产品应用如Hbase。
2.2.3 文档数据库
文档数据库是一种非关系数据库，将半结构化数据存储为文档，其中文档包括 XML、YAML、JSON、BSON、office 文档等不同格式。文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值。
简而言之，就是将数据保存到以上类似格式的文档中，数据库中的每个记录都是以文档形式存在的，相互之间不再存在关联关系。文档数据库所存放的文档，就相当于键值数据库所存放的“值”。
2.2.4 图数据库
图数据库顾名思义，就是一种存储图形关系的数据库，而图模型是图数据库中的重要概念。图模型由两个要素组成：节点和边，每个节点代表一个实体（人、地点、事物等），每条边代表两个节点之间的连接，这种通用结构可以对各种场景进行建模，如社交网络以及由关系定义的任何其他事物。
如下所示的图模型中包含 3个节点：中国、北京、长城。其两条边分别是：长城是北京的著名景点、北京属于中国。
http://picx.zhimg.com/v2-6716dbfed006f106a414c2c7de20f8a3_r.jpg?source=1def8aca
从上面的图模型可以看出，图数据库的目标就是基于图模型以一种直观的方式模拟这些关系，可以很好地分析实体之间的关系。
2.2.5 时序数据库
在介绍时序数据库前先了解下时序数据，时序数据是按照时间顺序记录系统、设备状态变化的数据，普遍存在于IT基础设施、运维监控系统和物联网中。在有时间的坐标中将这些数据点连成线，往前看可以做成多纬度报表，揭示其趋势性、规律性、异常性；往后看可以建立数学模型、做统计分析，预测事物发展趋势。
时序数据库就是存放时序数据的数据库，并且需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。相比于传统数据库仅仅记录了数据的当前值，时序数据库则记录了所有的历史数据。同时时序数据的查询也总是会带上时间作为过滤条件。
下面对时序数据库的数学模型做下简单介绍：
[*] metric：度量的数据集，类似于关系型数据库中的table
[*] point：一个数据点，类似于关系型数据库中的row
[*] timestamp：时间戳，表征采集到数据的时间点
[*] tag：维度列，代表数据的归属、属性，表明是哪个设备/模块产生的，一般不随着时间变化，供查询使用
[*] field：指标列，代表数据的测量值，随时间平滑波动，不需要查询
http://pic1.zhimg.com/v2-eaa98c98f5e2d35b0bb31e0168fda61e_r.jpg?source=1def8aca
时序数据库基本概念图
如上表中，度量为Wind，每一个数据点都具有一个timestamp，其中有两个field：风向、速度，两个tag：设备编号、城市。根据表中第一行和第三行的数据可知，存放的都是sensor号码为95D8-791的设备，属性城市是北京。随着时间的变化，风向和风速都发生了变化，风向从24.2变成25.6，风速从3.6变成了3.3。
2.2.6 搜索引擎数据库
搜索引擎数据库通常用于搜索保存在其他存储和服务中的数据。搜索引擎数据库可以对大量的数据建立索引，并提供近实时的索引查询。搜索引擎数据库是应用在搜索引擎领域的数据存储形式，由于搜索引擎会爬取大量的数据，并以特定的格式进行存储，这样在检索的时候才能保证性能最优。
搜索引擎数据库除了搜索像网页这样的非结构化的数据，许多应用程序还使用它为其他数据库中的数据提供结构化和即时搜索功能。有一些数据库也能提供全文索引功能，但是搜索数据库还具备通过词干和泛化将单词缩减为词根的功能。
页:
[1]