1.功能分类
根据数据库侧重的功能分类，大概可以分为三种类型数据库:
OLTP:（on-line transaction processing）联机事务处理,侧重于对数据的增删改，关注数据的实时性，并且有事务管理，对于数据的一致性也有要求，数据量一般不大，典型的数据库是关系型行式数据库，例如MYSQL,POSTSQL,ORACLE等
OLAP:（on-line analytical processing）联机分析处理，侧重于数据的分析，可能只关注数据的最终一致性，对实时性要求不高，一般是海量的数据，典型的一般是分布式的列式存储数据库，例如clickhouse,hbase,hive/sparksql+hdfs等
HTAP:即同时支持 OLTP 和 OLAP 场景，需要创新的计算存储框架，在一份数据上保证事务的同时支持实时分析，省去费时的 ETL 过程，例如：TIDB,OceanBase等
2.存储方式分类
2.1RDS(关系型数据库)
2.1.1 MySQL
1.MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。
2.MySQL是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。
3.与其他的大型数据库例如 Oracle、DB2、SQL Server等相比，MySQL 自有它的不足之处，但是这丝毫也没有减少它受欢迎的程度。对于一般的个人使用者和中小型企业来说，MySQL提供的功能已经绰绰有余，而且由于 MySQL是开放源码软件，因此可以大大降低总体拥有成本。
2.1.2 MariaDB
MySQL命名的由来:Monty Widenius有一个女儿,名叫My Widenius,因此他将自己开发的数据库命名为MySQL。Monty还有一个 儿子,名为Max,因此在2003年,SAP公司与MySQL公司建立合作伙伴关系后,Monty Widenius又将与SAP合作开发的数据库命名为 MaxDB。而现在的MariaDB中的Maria便是Monty Widenius的小孙女的名字。
MariaDB和MySql区别:
1.MariaDB不仅仅是Mysql的一个替代品，它的主要目的是创新和提高Mysql的技术，经过一些测试，性能比开源的MySQL性能要好；
2.MySQL之父Widenius先生离开了Sun之后，觉得依靠Sun/Oracle来发展MySQL，实在很不靠谱，于是决定另开分支，这个分支的名字叫做MariaDB，这个项目的更多的代码都改编于 MySQL 6.0。
MariaDB跟MySQL在绝大多数方面是兼容的（标称100%兼容），对于开发者来说，几乎感觉不到任何不同。目前MariaDB是发展最快的MySQL分支版本，新版本发布速度已经超过了Oracle官方的MySQL版本。
3.LAMP（Linux+Apache+Mysql/MariaDB+Php/Perl/Python）架构盛极一时，这离不开MySQL的免费与易用，但是在Oracle收购了Sun之后，很多公司开始担忧MySQL的开源前景，而最近Oracle进一步闭源的举措更是让人难以安心，众多互联网公司纷纷开始寻求MySQL的替代方案。
不得不提的是Apple的远见，在Oracle收购Sun之初就宣布迁移到PostgreSQL。但PostgreSQL的设计初衷就不同于MySQL，并不是使用MySQL的大部分互联网公司合适的解决方案。除了Apple，Google、Facebook、Twitter也大量使用了MySQL，纷纷发布了自己的MySQL分支/补丁集，并为不少公司所采用。同时，MariaDB、Percona等MySQL分支也渐渐步入大众的视野。
MySQL不足之处
1.数据量较大时（超过千万），如果没有索引，查询速度较慢；
2.DDL操作需要锁表，如果数据量大索引较多，这个操作也比较耗时，例如对一个有千万数据的表加减字段/加减索引等，这个速度可能是分钟级别，而PostgreSQL没有这方面的限制，速度秒级；
3.提供的功能和收费的Oracle,SQLServer没法比，而且没有一个稳定的引擎。
2.1.3 PostgreSQL
PostgreSQL，也称为 Postgres，是一种开源关系数据库，因其可靠性、灵活性和对开放技术标准的支持而享有盛誉。PostgreSQL 支持非关系和关系数据类型。它被称为当今可用的最兼容、最稳定和最成熟的关系数据库之一，并且可以轻松处理复杂的查询。
PostgreSQL相对于MySQL的优势：
1.在SQL的标准实现上要比MySQL完善，而且功能实现比较严谨。
2.存储过程的功能支持要比MySQL好，具备本地缓存执行计划的能力。
3.对表连接支持较完整，优化器的功能较完整，支持的索引类型很多，复杂查询能力较强。
4.PG主表采用堆表存放，MySQL采用索引组织表，能够支持比MySQL更大的数据量。
5.PG的主备复制属于物理复制，相对于MySQL基于binlog的逻辑复制，数据的一致性更加可靠，复制性能更高，对主机性能的影响也更小。
6.MySQL的存储引擎插件化机制，存在锁机制复杂影响并发的问题，而PG不存在。
7.PG对可以实现外部数据源查询，数据源的支持类型丰富。
8.PG原生的逻辑复制可以实现表级别的订阅发布，可以实现数据通过kafka流转，而不需要其他的组件。
9.PG支持三种表连接方式，嵌套循环，哈希连接，排序合并，而MySQL只支持嵌套循环。
10.PostgreSQL源代码写的很清晰，易读性比MySQL强太多了。
11.PostgreSQL通过PostGIS扩展支持地理空间数据。地理空间数据有专用的类型和功能，可直接在数据库级别使用，使开发人员更容易进行分析和编码。
可扩展型系统，有丰富可扩展组件，作为contribute发布。
12.PostgreSQL支持JSON和其他NoSQL功能，如本机XML支持和使用HSTORE的键值对。它还支持索引JSON数据以加快访问速度，特别是10版本JSONB更是强大。
13.PostgreSQL完全免费，而且是BSD协议(https://blog.csdn.net/sh_yjm/article/details/124674690)，如果你把PostgreSQL改一改，然后再拿去卖钱，也没有人管你，这一点很重要，这表明了PostgreSQL数据库不会被其它公司控制。相反，MySQL现在主要是被Oracle公司控制。
总之：支持复杂查询，修改比较频繁，更适合写量大且并发的读写操作，可移植性比较好的场景比较适合使用PostgrepSQL。
2.1.4 SQL Server
1.SQL Server，也称为Microsoft SQL Server，比MySQL长得多。Microsoft在80年代开发了SQL Server，并承诺提供可靠且可扩展的RDBMS。这些年来，这些仍然是SQL Server的核心品质，因为它是大型企业软件的首选平台。
2.SQL Server主要面向使用.NET作为开发语言的开发人员，而MySQL可以与几乎所有其他语言配对，最常用的是PHP。
3.SQL Server过去只能在Windows上运行，但自去年微软宣布Linux支持SQL Server以来，情况发生了变化。尽管如此，Linux版本还不够成熟，这意味着如果使用SQL Server，我们仍然建议您继续使用Windows，如果使用MySQL，请切换到Linux。
SQL Server与MySQL的区别：
1.语法方面差距比较大
2.SQL Server不仅仅是一个RDBMS
Microsoft已经为SQL Server构建了其他工具，这些工具与RDBMS捆绑在一起，包括数据分析工具。它还具有报表服务器 - SQL Server Reporting Services以及ETL工具。这使得SQL Server成为RDBMS的瑞士军刀。您也可以在MySQL上获得类似的功能，但是您必须为第三方解决方案肆虐网络 。
3.查询取消
MySQL和SQL Server之间潜在的突破性差异是MySQL不允许您在执行中取消查询。这意味着一旦命令开始执行，你最好希望它可能造成的任何损害都是可逆的。另一方面，SQL Server允许您在过程中途取消查询执行。对于数据库管理员而言，这种差异尤其严重，而Web开发人员则执行脚本命令，这些命令在执行期间很少需要取消查询。
sql server + c# + iis是绝配, 适用于大中型项目.
oracle + java + tomcat是绝配, 适用于巨型项目.
mysql + php + apache是绝配, 适用于小型项目.
mysql + java + apache是绝配, 适用于中小型项目.
2.1.5 Oracle
和MySQL对比：
1.mysql开源免费的，而oracle则是收费的，并且价格非常高。
2.mysql的管理工具较少，在Linux下的管理工具的安装有时需要安装额外的包（phpmyadmin，etc），有一定复杂性。
oracle有多重成熟命令行、图形界面、web管理工具，还有很多第三方的管理工具，管理极其方便高效。oracle支持大并发，大访问量，是OLTP最好的工具。
3.mysql：默认用户是root，用户下可以创建好多数据库，每个数据库下还有好多表，一般情况下都是使用默认用户，不会创建多个用户；
oracle：创建一个数据库，数据库下有好多用户：sys、system、scott等，不同用户下有好多表，一般情况下只创建一个数据库用。
4.并发性：
mysql以表级锁为主，对资源锁定的粒度很大，如果一个session对一个表加锁时间过长，会让其他session无法更新此表中的数据。
oracle使用行级锁，对资源锁定的粒度要小很多，只是锁定sql需要的资源，并且加锁是在数据库中的数据行上，不依赖于索引，所以oracle对并发性的支持要好很多。
5.复制
mysql：复制服务器配置很简单，但主库出问题时，从库可能丢失一定的数据，且需要手工切换从库到主库；
oracle：既有堆或拉式的传统数据复制，也有dataguard的双机或多机容灾机制，主库出问题时，可以自动切换备库到主库，但配置管理较复杂。
6.性能诊断
mysql的诊断调优方法较少，主要有慢查询日志；
oracle有各种成熟的性能诊断调优工具，能实现很多自动分析、诊断功能。比如awr、addm、sqltrace、tkproof等。
.....
Oracle基本上是关系型数据库的天花板，功能强大，管理工具非常丰富，但是配置比较复杂，适用于超大型项目，但是Oracle比较耗内存，对机器的配置要求比较高，MySQL比较轻量级。
2.1.6 SQLite
SQLite是一个进程内的库，实现了自给自足的、无服务器的、零配置的、事务性的 SQL 数据库引擎。它是一个零配置的数据库，这意味着与其他数据库不一样，您不需要在系统中配置。
就像其他数据库，SQLite 引擎不是一个独立的进程，可以按应用程序需求进行静态或动态连接。SQLite 直接访问其存储文件。
2.1.7 PloarDB ---阿里云自研的云原生关系型数据库
是阿里云自研的下一代关系型云数据库，有三个独立的引擎，分别可以100%兼容MySQL/PostgreSQL、高度兼容Oracle语法，存储容量最高可达100TB，单库最多可扩展到16个节点，适用于企业多样化的数据库应用场景。（封装的MySQL,PG，100%兼容MySQL和PG,高度兼容Oracle，并且可以突破磁盘的限制，支持海量的数据，并且是分布式的，不需要自己去做分库分表）
2.2 HTAP
2.2.1 TiDB PingCAP公司自主设计、研发的开源分布式关系型数据库
目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。
解决MySQL分库分表的缺点：
- 分页查询性能不好，需求聚合多库数据，多次io，内存消耗大。
- 分布式事务问题
- 分库之后，想二次扩容，数据迁移等会更复杂
- 跨库join很难实现
四大核心场景：
对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景
1.众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。
2.对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景
随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。
3.Real-time HTAP 场景
随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。
4.数据汇聚、二次加工处理的场景
当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。
2.2.2 OceanBase 金融级分布式关系数据库
OceanBase是由蚂蚁金服、阿里巴巴完全自主研发的分布式关系型数据库，始创于2010年。
OceanBase具有数据强一致、高可用、高性能、在线扩展、高度兼容SQL标准和主流关系型数据库、低成本等特点。
2.3 NoSQL(Not Only SQL)，意即“不仅仅是SQL”，泛指非关系型的数据库
NoSQL 不依赖业务逻辑方式存储，而以简单的key-value模式存储。因此大大的增加了数据库的扩展能力。
● 不遵循SQL标准。
● 不支持ACID（sql的四个特性）。
● 远超于SQL的性能。
需要事务支持的
基于sql的结构化查询存储，处理复杂的关系，需要即席查询的。
即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的，而即席查询是由用户自定义查询条件的。
用不着sql的 和 用了 sql也不行的情况，请考虑NoSQL
2.3.1 key-value
Redis
是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。单线程，基于内存，丰富的数据结构，支持持久化，分布式锁，简单事务等是Redis的特点。使用的场景包括：
1.缓存
热点数据缓存，对象缓存、全页缓存、可以提升热点数据的访问数据。
2.分布式数据共享
String 类型，因为 Redis 是分布式的独立服务，可以在多个应用之间共享
例如：分布式Session
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-data-redis</artifactId>
</dependency>
3.分布式锁
4.全局id
int类型，incrby，利用原子性
incrby userid 1000
分库分表的场景，一次性拿一段
5.计数器
int类型，incr方法
例如：文章的阅读量、微博点赞数、允许一定的延迟，先写入Redis再定时同步到数据库
6.限流
int类型，incr方法
以访问者的ip和其他信息作为key，访问一次增加一次计数，超过次数则返回false
7.位统计
String类型的bitcount，统计在线数，访问量等
8.消息队列
9.点赞，签到，打卡
10.排行榜
等等，使用的场景还是比较多的
**Memcached **
也是基于内存的Key-Value中间件，但是不算是数据库，因为无持久化功能，要支持持久化得自己开发
与Redis不同
1.多线程，读写效率比Redis快
2.官方提供的版本不支持持久化，这就造成了它适用的场景不多，一般只是作为分布式缓存用，即进程挂了也不影响整个服务的可用性，但是Redis除了做缓存，还有其他很多场景；
3.Memcached不支持复制。而，Redis支持主从复制，允许从属Redis服务器成为主服务器的精确副本；来自任何Redis服务器的数据都可以复制到任意数量的从属服务器。
4.Redis支持字符串，散列，列表，集合，有序集，位图，超级日志和空间索引；而Memcached支持字符串和整数。
......
2.3.2 面向文档数据库
MongoDB
是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似json的bson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。mongodb的数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，这样提高查询效率，所谓内存数据映射
CouchDB
与MongoDB的比较：
与key-value对比：
在键值数据库中，我们只能通过key查找到整个value，数据库并不知道value里面存的内容到底是什么，而是通过应用程序将value里面的东西进行翻译解析；在文档数据库中，我们不仅可以通过key查找value，也可以通过document中对应的key找到具体内容，value对数据库来说是透明的。
举例： 比如用两个数据库来存储同一个JSON文件（如下图所示），键值数据库中我们只可以用通过customerid来查询到这个JSON文件，但具体里面的内容我们不能直接从数据库中查找到。使用文档数据库我们可以直接查询出该customerid下的company是什么。
2.3.3 列式存储
与行式存储的不同，举个例子说明
下图为员工信息emp表
数据在磁盘上是以行的形式存储在磁盘上，同一行的数据紧挨着存放在一起。
对于 emp 表，要查询部门 dept 为 A 的所有员工的名字。
select name from emp where dept = A
由于 dept 的值是离散地存储在磁盘中，在查询过程中，需要磁盘转动多次，才能完成数据的定位和返回结果。
列式存储的原理与特点
对于 OLAP 场景，一个典型的查询需要遍历整个表，进行分组、排序、聚合等操作，这样一来行式存储中把一整行记录存放在一起的优势就不复存在了。而且，分析型 SQL 常常不会用到所有的列，而仅仅对其中某些需要的的列做运算，那一行中无关的列也不得不参与扫描。
然而在列式存储中，由于同一列的数据被紧挨着存放在了一起，如下图所示。
那么基于需求字段查询和返回结果时，就不许对每一行数据进行扫描，按照列找到需要的数据，磁盘的转动次数少，性能也会提高。
还是上面例子中的查询，由于在列式存储中 dept 的值是按照顺序存储在磁盘上的，因此磁盘只需要顺序查询和返回结果即可。
列式存储不仅具有按需查询来提高效率的优势，由于同一列的数据属于同一种类型，如数值类型，字符串类型等，相似度很高，还可以选择使用合适的编码压缩可减少数据的存储空间，进而减少IO提高读取性能。
总的来说，行式存储和列式存储没有说谁比谁更优越，只能说谁更适合哪种应用场景。
Hbase ---CP
访问 HBase 数据的方式有三种:
● 基于 RowKey的单行查询；
● 基于RowKey的范围查询；
● 全表扫描查询。
一般会使用其他数据库作为二级查询，例如elasticsearch，将RowKey和其他字段数据作为映射关系，通过elasticsearch查询到数据的RowKey，然后根据RowKey在HBase查询出数据
Cassandra ---AP
Cassandra和HBase很像两个陌生人，您在街上遇到并认为是双胞胎。您并不是很了解它们，但是它们相似的身高，衣服和发型使您看不到它们之间的差异。但是，仔细观察后，您会发现这两个对象仅在远处看起来相同。
Cassandra非常适合“始终在线”的网络或移动应用程序以及具有复杂和/或实时分析的项目。但是，如果不急于获得分析结果（例如，进行数据湖实验或创建机器学习模型），则HBase可能是一个不错的选择。特别是如果您已经投资了Hadoop基础架构和技能。（一个实时在线的数据分析，一个是离线的数据分析）
**ClickHouse (Click Stream，Data WareHouse) **
clickhouse没有走hadoop生态，采用 Local attached storage 作为存储
ClickHouse 是俄罗斯第一大搜索引擎 Yandex 开发的列式储存数据库。令人惊喜的是，这个列式储存数据库的性能大幅超越了很多商业 MPP 数据库软件，比如 Vertica,InfiniDB.
相比传统的数据库软件，ClickHouse 要快 100-1000X:
100Million 数据集:
● ClickHouse 比 Vertica 约快 5 倍，比 Hive 快 279 倍，比 My SQL 快 801 倍
1Billion 数据集:
● ClickHouse 比 Vertica 约快 5 倍，MySQL 和 Hive 已经无法完成任务了
高性能原因：
1.列式存储
2.算法
3.分布式计算
....
缺点：
1.写入性能较低
2.对于修改/删除等数据变更场景支持较弱
.....
2.3.4 行列混存
AnalyticDB MySQL --所有字段默认都会创建索引，99%兼容MySQL（TB 甚至PB级别）
云原生数据仓库AnalyticDB MySQL版是融合数据库、大数据技术于一体的云原生企业级数据仓库服务。AnalyticDB MySQL版支持高吞吐的数据实时增删改、低延时的实时分析和复杂ETL，兼容上下游生态工具，可用于构建企业级报表系统、数据仓库和数据服务引擎。
应用场景：
云原生数据仓库AnalyticDB MySQL版为千万家企业级客户提供了数据处理ETL、实时在线分析、核心报表、大屏和监控能力，为广大商家和消费者提供稳定的离线和在线数据服务。
● 实时数仓
该场景需要在一个平台上提供统一的在线查询和离线计算的能力，简化数据架构，降低开发和运维成本。通过弹性伸缩支持更合理的资源配比，减少非高峰期的保有资源，优化成本，提高性价比。
● 精准营销
该场景通过实时的数据统计，监测不同渠道用户的增长、活跃、留存状况，让企业快速分析出投资回报率。提高营销效果数据时效性，便于改进产品体验和优化营销方案，提高整体收益。
● 商业智能报表
该场景要求支持海量数据实时入库和计算，毫秒或秒级返回结果，方便自由灵活的快速构建报表。支持丰富的可视化BI工具，开发人员容易上手，降低企业数据化建设门槛。
● 多源联合分析
该场景需要解决云上企业构建数据仓库时配置数据同步链路繁杂的问题，以及分库分表所带来的数据分析复杂性问题，让用户可以更专注于业务逻辑。
● 交互式查询
该场景要求支持实时BI报表和自定义多维查询，响应流畅，交互体验好；任意选择分析维度，无需事先建模和预计算，便于进行探索式分析。
不足：
1.有比较少量的BUG，例如夏令时等，MySQL没有这个问题；
2.很多比较耗时的功能不支持，自定义函数不支持，存储过程不支持等，阉割了MySQL的很多功能，一切为了效率；
3.价格很贵，比RDS MySQL贵很多啊
2.3.5 图数据库
GDB
图数据库GDB非常适合社交网络、欺诈检测、推荐引擎、实时图谱、网络/IT运营这类高度互连数据集的场景。例如，在一个典型的社交网络中，常常会存在“谁认识谁，上过什么学校，常住什么地方，喜欢什么餐馆”之类的查询，传统关系型数据库对于超过3张表关联的查询十分低效难以胜任，但图数据库可轻松应对社交网络的各种复杂存储和查询场景。
2.3.6 面向搜索数据内容的搜索引擎
主要是用于对海量数据进行近实时的处理和分析处理，可用于机器学习和数据挖掘
主流代表为Elasticsearch，Splunk，Solr，MarkLogic和Sphinx
2.3.7 表格存储 --大量表格数据的查询解决方案
Tablestore
详见 https://developer.aliyun.com/article/656196
