无库时代 ：没有专门的数据库，数据大多以文件形式存放
层次状数据库 ：使用层次状模型进行数据库设计和存放
网状数据库 ：使用网状模型进行数据库设计和存放
关系型数据库 ：使用关系型模型进行数据库设计和存放
非关系型数据库：为适应水平扩展性和处理超大量的数据环境，近几年发展非常迅速的发展，衍生类型非常多。
原文链接：关系型数据库的发展历史(大佬牛皮,做发展史的大佬比较少)
个人而言并不是很喜欢叫他们数据库
数据库的是database的直译,而现在他们之中大部分已经不只是database(DB)，以DBMS称呼他们更为贴切
数据库排名网站
关系型:
(1 原文链接https://www.jianshu.com/p/fd7b422d5f93
指采用了关系模型来组织数据的数据库。
关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。
关系模型中常用的概念：
关系：一张二维表，每个关系都具有一个关系名，也就是表名
元组：二维表中的一行，在数据库中被称为记录
属性：二维表中的一列，在数据库中被称为字段
域：属性的取值范围，也就是数据库中某一列的取值限制
关键字：一组可以唯一标识元组的属性，数据库中常称为主键，由一个或多个列组成
关系模式：指对关系的描述。其格式为：关系名(属性1，属性2， ... ... ，属性N)，在数据库中成为表结构
关系型数据库的优点：
1.容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解
2.使用方便：通用的SQL语言使得操作关系型数据库非常方便
3.易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率
关系型数据库存在的问题
1.磁盘性能依赖:网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈。关系型数据库十分强调数据的一致性，并为此降低读写性能付出了巨大的代价，虽然关系型数据库存储数据和处理数据的可靠性很不错，但一旦面对海量数据的处理的时候效率就会变得很差，特别是遇到高并发读写的时候性能就会下降的非常厉害
2.横向扩展困难:在基于web的结构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。当需要对数据库系统进行升级和扩展时，往往需要停机维护和数据迁移。
3.存储规范复杂：关系型数据库为了避免重复、规范化数据以及充分利用好存储空间，把数据按照最小关系表的形式进行存储，这样数据管理的就可以变得很清晰、一目了然，当然这主要是一张数据表的情况。如果是多张表情况就不一样了，由于数据涉及到多张数据表，数据表之间存在着复杂的关系，随着数据表数量的增加，数据管理会越来越复杂。
4.存储结构死板：关系型数据库需要建立在完善的数据库设计之后才可以高效稳定的使用，这使得在这设计初就需要进行较为完善的构想，这对于小型公司和初级开发人员是一种巨大的挑战。当一张表数据量太大时，对其索引以及列的维护几乎是难以实时进行的。
5.性能欠佳：在关系型数据库中，导致性能欠佳的最主要原因是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的 ACID[1]特性，必须尽量按照其要求的 范式[2]进行设计，关系型数据库中的表都是存储一个格式化的数据结构。
(2 原文链接:https://blog.csdn.net/cenghaihengliu/article/details/106907941
关系型数据库属于早期的传统型数据库，它有着标准化的数据模型，以及事务和持久化的支持、例如，关系型数据库都会支持的 ACID 特性，也就是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），具体含义如下。
[1]
原子性（Atomicity）：是指一个事务中的所有操作，要么全部完成、要么全部不完成，不会存在中间的状* 态。也就是说事务在正常的情况下会执行完成；异常的情况下，比如在执行的过程中如果出现问题，会回滚成最初的状态，而非中间状态。
一致性（Consistency）：是指事务从开始执行到结束执行之间的中间状态不会被其他事务看到。
隔离性（Isolation）：是指数据库允许多个事务同时对数据进行读写或修改的能力，并且整个过程对各个事务来说是相互隔离的。
持久性（Durability）：是指每次事务提交之后都不会丢失。
关系型数据库一般遵循三范式设计思想，具体内容如下。
[2]-
第一范式（The First Normal Form，1NF）：要求对属性的原子性，也就是说要求数据库中的字段需要具备原子性，不能再被拆分。
比如，用户表中有字段：用户 ID、用户名、电话；而其中电话又可以分为：家庭电话和移动电话等。因此，此表不符合第一范式，如下图所示：
1.png -
第二范式（The Second Normal Form，2NF）：例如订单详情表有这些字段：订单 ID、产品 ID、产品名称、产品单价、折扣。其中，订单 ID 和产品 ID 为联合主键，但这个表中的产品名称和产品单价两个字段只依赖产品 ID，和订单 ID 就没有任何关系了，因此这个表也不符合第二范式。
我们可以把原来的订单表拆分为订单表和产品表，其中订单表包含：订单 ID、产品 ID、折扣等字段；而产品表包含：产品 ID、产品名称、产品单价等字段。这样就消除了产品名称和产品单价多次重复出现的情况了，从而避免了冗余数据的产生。.
2.png -
第三范式（The Third Normal Form，3NF）：想要满足第三范式必须先满足第二范式，第三范式要求所有的非主键字段必须直接依赖主键，且不存在传递依赖的情况。
例如，有一个学生表中包含了：学生 ID、姓名、所在学院 ID、学院电话、学院地址等字段。这个表的所有字段（除去主键字段）都完全依赖唯一的主键字段（学生 ID），所以符合第二范式。但它存在一个问题，学院电话、学院地址依赖非主键字段学院 ID，而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合第三范式。
我们可以把学生表分为两张表，一张是学生表包含了：学生 ID、姓名、所在学院 ID 等字段；另一张为学院表包含了：学院 ID、学院电话、学院地址等字段，这样就满足第三范式的要求了。
3.png
可以看出，使用三范式可以避免数据的冗余，而且在更新表操作时，只需要更新单张表就可以了。
文档型
从1989年起，Lotus通过其群件产品Notes提出了数据库技术的全新概念-"文档数据库"，文档数据库区别于传统的其它数据库，它是用来管理文档。在传统的数据库中，信息被分割成离散的数据段，而在文档数据库中，文档是处理信息的基本单位。一文档可以很长、很复杂、可以无结构，与字处理文档类似。一个文档相当于关系数据库中的一条记录。
文档导向的数据库是键值数据库的子类，这是继承于 NoSQL 数据库的另一概念 [1] 。它们的差别在于处理数据的方式：在键值数据库中，数据是对数据库不透明的；而面向文档的数据库系统依赖于文件的内部结构，它获取元数据以用于数据库引擎进行更深层次的优化。虽然这一差别由于系统工具而不甚明显，但在设计概念上，这种文档存储方式利用了现代程序技术来提供更丰富的体验。
文档数据库与传统的关系数据库差异显著。关系数据库通常将数据存储在相互独立的表格中，这些表格由程序开发者定义，单独一个的对象可以散布在若干表格中。 对于数据库中某单一实例中的一个给定对象，文档数据库存储其所有信息，并且每一个被存储的对象可与任一其它对象不同。这使得将对象映射入数据库简单化，并通常会消除任何类似于对象关系映射的事物。这也使得文档数据库对网络应用有较大价值，因为后者的数据处在不断变化中，而且对于后者来说，部署速度是一个重要的问题。
文档数据库也不同于关系数据库，关系数据库是高度结构化的，而Notes的文档数据库允许创建许多不同类型的非结构化的或任意格式的字段，与关系数据库的主要不同在于,它不提供对参数完整性和分布事务的支持，但和关系数据库也不是相互排斥的，它们之间可以相互交换数据,从而相互补充、扩展。
文档数据库与文件系统的区别
文档数据库与五、六十年代管理数据的文件系统不同，文档数据库仍属于数据库范畴。首先，文件系统中的文件基本上对应于某个应用程序。当不同的应用程序所需要的数据有部分相同时，也必须建立各自的文件，而不能共享数据，而文档数据库可以共享相同的数据。因此，文件系统比文档数据库数据冗余度更大，更浪费存储空间，且更难于管理维护。其次，文件系统中的文件是为某一特定应用服务的，所以，要想对现有的数据再增加一些新的应用是很困难的，系统不容易扩充。数据和程序缺乏独立性。而文档数据库具有数据的物理独立性和逻辑独立性，数据和程序分离。
文档数据库与关系型数据库的区别
文档数据库也不同于关系数据库,关系数据库是高度结构化的,而Notes的文档数据库允许创建许多不同类型的非结构化的或任意格式的字段,与关系数据库的主要不同在于,它不提供对参数完整性和分布事务的支持,但和关系数据库也不是相互排斥的,它们之间可以相互交换数据,从而相互补充、扩展。
（文档型数据库概论型的文档比较少，以上抄自百度百科）
文档型数据库储存数据结构
类比关系型数据库的二维表结构,mongo的单行记录表现为一个JSON(实际是一个mongo优化过的json结构-BJOSN[Binary JSON]),以官方工具MongoDB Compass为例
可以看到其中database、collections等，与熟知的mysql概念做类比
| mysql | mongoDB | |
|---|---|---|
| 库 | database | database |
| 表 | table | collection |
| 行 | row | documents |
| 列 | 字段 | \ |
与关系型数据库相比 一个Mongo中的一个"表"中,Mongo的单条记录并没有固定格式
mongodb与关系型数据库相比的优缺点
与关系型数据库相比，MongoDB的优点：
①弱一致性（最终一致），更能保证用户的访问速度：
举例来说，在传统的关系型数据库中，一个COUNT类型的操作会锁定数据集，这样可以保证得到“当前”情况下的较精确值。这在某些情况下，例 如通过ATM查看账户信息的时候很重要，但对于Wordnik来说，数据是不断更新和增长的，这种“较精确”的保证几乎没有任何意义，反而会产生很大的延 迟。他们需要的是一个“大约”的数字以及更快的处理速度。
但某些情况下MongoDB会锁住数据库。如果此时正有数百个请求，则它们会堆积起来，造成许多问题。我们使用了下面的优化方式来避免锁定：
每次更新前，我们会先查询记录。查询操作会将对象放入内存，于是更新则会尽可能的迅速。在主/从部署方案中，从节点可以使用“-pretouch”参数运行，这也可以得到相同的效果。
使用多个mongod进程。我们根据访问模式将数据库拆分成多个进程。
②文档结构的存储方式，能够更便捷的获取数据。
对于一个层级式的数据结构来说，如果要将这样的数据使用扁平式的，表状的结构来保存数据，这无论是在查询还是获取数据时都十分困难。
③内置GridFS，支持大容量的存储。
GridFS是一个出色的分布式文件系统，可以支持海量的数据存储。
内置了GridFS了MongoDB，能够满足对大数据集的快速范围查询。
④内置Sharding。
提供基于Range的Auto Sharding机制：一个collection可按照记录的范围，分成若干个段，切分到不同的Shard上。
Shards可以和复制结合，配合Replica sets能够实现Sharding+fail-over，不同的Shard之间可以负载均衡。查询是对 客户端是透明的。客户端执行查询，统计，MapReduce等操作，这些会被MongoDB自动路由到后端的数据节点。这让我们关注于自己的业务，适当的 时候可以无痛的升级。MongoDB的Sharding设计能力较大可支持约20 petabytes，足以支撑一般应用。
这可以保证MongoDB运行在便宜的PC服务器集群上。PC集群扩充起来非常方便并且成本很低，避免了“sharding”操作的复杂性和成本。
⑤第三方支持丰富。(这是与其他的NoSQL相比，MongoDB也具有的优势)
现在网络上的很多NoSQL开源数据库完全属于社区型的，没有官方支持，给使用者带来了很大的风险。
而开源文档数据库MongoDB背后有商业公司10gen为其提供供商业培训和支持。
而且MongoDB社区非常活跃，很多开发框架都迅速提供了对MongDB的支持。不少知名大公司和网站也在生产环境中使用MongoDB，越来越多的创新型企业转而使用MongoDB作为和Django，RoR来搭配的技术方案。
⑥性能优越：
在使用场合下，千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比mysql慢，而对非索引字段的查询，则是全面胜出。 mysql实际无法胜任大数据量下任意字段的查询，而mongodb的查询性能实在让我惊讶。写入性能同样很令人满意，同样写入百万级别的数 据，mongodb比我以前试用过的couchdb要快得多，基本10分钟以下可以解决。补上一句，观察过程中mongodb都远算不上是CPU杀手。
与关系型数据库相比，MongoDB的缺点：
①mongodb不支持事务操作。
所以事务要求严格的系统（如果银行系统）肯定不能用它。(这点和优点①是对应的)
②mongodb占用空间过大。
关于其原因，在官方的FAQ中，提到有如下几个方面：
1、空间的预分配：为避免形成过多的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64M、128M、256M那 样的指数递增，直到2G为单个文件的较大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。
2、字段名所占用的空间：为了保持每个记录内的结构信息用于查询，mongodb需要把每个字段的key-value都以BSON的形式存储，如果 value域相对于key域并不大，比如存放数值型的数据，则数据的overhead是较大的。一种减少空间占用的方法是把字段名尽量取短一些，这样占用 空间就小了，但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个index，每个字段名用一个字节表示，这样就不用担心字段名取多长 了。但作者的担忧也不无道理，这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换，再发送到客户端，这个替换也是挺耗费时间的。现在的实现算是 拿空间来换取时间吧。
3、删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记“已删除”即可，以后还可以重复利用。
4、可以定期运行db.repairDatabase()来整理记录，但这个过程会比较缓慢
③MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方。
MongoDB适合存储一些关系简单、数据量又很大的数据，比如我们的平台上虚拟机的监控信息，包括内存、IO、CPU、网络等数据，每隔几秒就采集一次数据，每周、每月，量很大，而且旧的监控数据也不会保留太长时间，就使用的mongodb来存储这些数据；
另外mongodb的集群部署相对比较简单，易于扩展；比如主从复制，在mongo.conf配置几个参数就OK了；分片集群的配置也比较简单。还支持使用命令行来进行动态地添加和删除节点；
Mongodb的优点与不足
（1）Mongodb的不足之处
1、在集群分片中的数据分布不均匀
2、单机可靠性比较差
3、大数据量持续插入，写入性能有较大波动
4、磁盘空间占用比较大
（2）Mongodb的过人之处
1、无模式
2、查询与索引方式灵活，是最像SQL的Nosql
3、支持复制集、主备、互为主备、自动分片等特性
(原文链接：https://blog.csdn.net/qq_32364939/article/details/79654377)
上面的分析都是以Mongo为例进行的Mongo特性分析,但是文档型并不只是Mongo 比如排在后面的SAP HANA
来自于爱普斯的服务
有兴趣的可以看看 https://archive.sap.com/documents/space/chinese/hana
键值型
键值型是一种古老而有效的储存方案,从Hash表到Map但是用来查找定位的字段变成了单一的一个key,就会使得负责的查询逻辑以及统计变的复杂起来,通常用来储存用户信息，比如会话、配置文件、参数、购物车等等。这些信息一般都和ID（键）挂钩，这种情景下键值数据库是个很好的选择。
而进行一些统计或者其他复杂的过程(比如事务),这类型的数据库又显得很捞,因此这类数据库通常不会作为业务的核心储存方式，而是一种补充。
- 简单举例
假设我们需要提供一个用户手机号进行登录的功能,在关系型数据库中我们只需要用户表里有这一列就可以找到这个用户。
而在键值型我们只能是把手机号本身作为一个key才会快速有效的找到这个用户，除非你愿意把所有的数据拉出来进行查找。
然而即使这样做了，也会对系统功能产生很大的限制，因为我们无法用邮箱去登录了，要用邮箱去登录我们 还需要另一个以邮箱为key的"表"来进行储存同样的东西。
键值型数据库的主要作用并不在于功能的丰富，而在于其检索效率，因此多用于高并发下的场景。因此这类数据库一般都会使用大量的内存来提升效率。缺点很多，但是优点就是快，快，快。
redis应该是这其中我们最常用的工具。这类储存方式简单而又常见,而其内部的实现方式却又多种多样,使得我无法对此做一个有效的简述。而对于redis的介绍将会放在后面的文章再做详解。
搜索引擎
这又是个让我困惑的类型，甚至不知道是否该把它放到这篇文章里,但是在最开始的那个数据库排行的网站里我看他是这么描述搜索引擎的
Search engines are NoSQL database management systems dedicated to the search for data content. In addition to general optimization for this type of application, the specialization consists in typically offering the following features:
- Support for complex search expressions
- Full text search
- Stemming (reducing inflected words to their stem)
- Ranking and grouping of search results
- Distributed search for high scalability
而百度百科却有自相矛盾的描述
1.搜索引擎是指根据一定的策略、运用特定的计算机程序从互联网上采集信息，在对信息进行组织和处理后，为用户提供检索服务，将检索的相关信息展示给用户的系统。
2.所谓搜索引擎，就是根据用户需求与一定算法，运用特定策略从互联网检索出制定信息反馈给用户的一门检索技术。
这让我个人很困惑,在我的观念里，技术是一种方法，一种方式，一套理论。而系统是对这个方法、方式的实现。
仔细阅读了百度百科的第2种解释，在这个解释里"搜索引擎"是一个涵盖了爬虫技术、检索排序技术、网页处理技术、大数据处理技术、自然语言处理技术等，为信息检索用户提供快速、高相关性的信息服务。
欸，不管他是系统服务还是理论技术了，这种解释下搜索引擎变成了一个包括数据获取以及数据查找的全流程方案，而不是我们理解中只负责数据存放的数据库。现在我们只考虑数据存放的这一块，称其为数据库。
(关于具体是技术还是服务，或许我们需要从其英语的本意去寻找,比如排名网站中写的是Search engines，可能并不能使用直译的搜索引擎来进行翻译，或者说像百度也并不是个搜索引擎，而是搜索服务这样比较靠谱)
这类数据库主要是用于对海量数据进行近实时的处理和分析处理,例如用于机器学习和数据挖掘或者是逛淘宝时的搜索框、查日志时的ELK。
而关于Elasticsearch的分析像其他的数据库一样将会放在后面的文章,毕竟搜索引擎相对与其他的更加复杂，设计到更多的东西。
列存储
这类数据库的主要特点是具有很强的可拓展性
普通的关系型数据库都是以行为单位来存储数据的，擅长以行为单位的读入处理，比如特定条件数据的获取。因此，关系型数据库也被成为面向行的数据库。相反，面向列的数据库是以列为单位来存储数据的，擅长以列为单位读入数据。
这类数据库想解决的问题就是传统数据库存在可扩展性上的缺陷，这类数据库可以适应数据量的增加以及数据结构的变化，将数据存储在记录中，能够容纳大量动态列。由于列名和记录键不是固定的，并且由于记录可能有数十亿列，因此可扩展性存储可以看作是二维键值存储。
比较典型常用的是hbase。通常用于大量数据的存储,而在查询功能型上较弱,查询速度也不像redis一样快，但是可扩展以及数据量大使其经常作为大数据的底层库使用,比如数仓、数据湖。
后面几种都是属于NoSQL,大部分情况并不能完整的替代传统DB，是建立在传统DB辉煌帝国下的部门,通常用于传统DB的补充以及完善。例如会使用redis来作为Mysql的缓存等。