• 关于数据库，大学时候我们只知道MySQL，稍微深入点再加上Redis、MongoDB等非关系型数据库。然而，进入公司接手一个项目，发现其中用到多种数据库，每种数据库都有自身的优势和局限性，故在此梳理下日常常用数据库、对应区别以及各自的适用场景。
• mysql、postgresql、clickhouse、mongodb有什么区别，各自适合在什么场景下使用

一、常用数据库概览

1.1 关系型数据库

关系型数据库通常是业务型项目的主力数据库，原因以下：

• 方便业务建模，表的关系和业务之间的关联是类似的
• 数据一致性，关系型数据库一般支持ACID特性，可用于核心业务场景的数据持久化

关系型数据库的基本单位是表，表与表之间通过键关联，比如学生表和班级表，可以通过班级ID，把学生和班级关联起来。

关系型数据库的经典代表：MySQL、Orcle、PostgreSQL、SQLite等。

1.2 非关系型数据库

非关系型数据库其实只是一个比较笼统的叫法，实际分类下有非常多，这里只介绍键值对、文档、列式存储、图形结构等几种。

1.2.1 KV数据库

KV数据库以键值对的形式存储数据，常见底层数据结构实现是哈希表，读数据复杂度是O(1)。

key	value
name	jw
score	{chinese:90, math:99}

key-value存储的数据通常单个key-value就是一个条独立的数据，很方便水平扩展，可以根据key散列到不同的分片，且读的性能极好，因此常用于做缓存。

经典代表有Redis、Memcached和LevelDB等。

1.2.2 文档型数据库

文档型数据库的数据以文档的形式存储数据，每个文档类似一个JSON对象。

比于KV存储，文档型数据库同样对水平扩展友好，且具有更好的查询性能，支持复杂查询，而KV存储几乎只通过key来读取数据。

经典的文档型数据库有MongoDB、CouchDB和Elasticsearch等。

1.2.3 列式存储数据库

经典的列式存储数据库有HBase、Druid、ClickHouse等，不同列式数据库的底层实现差别挺大的，它们的共同点是按列存储。

比如说MySQL存一个学生信息，有学号和姓名等，这两个字段在同一行，存放也是在一起的；但是列式数据库会按列划分存储，把学号和姓名分开存储，相同的数据类型有利于进行数据压缩、聚合操作等。

下面是HBase的一条数据组成解析，一个Row Key（行键）下有多个Column Family（列族），列族下面有Column Qualifier（列限定符），最后会根据设置保存若干个版本，形成Timestamp/version: Cell Value的键值对。这里我们只需要知道不同的列族是分开存储的就行了。

1.2.4 图数据库

图数据库的基本单元是点和边，经典的图数据库包括Neo4j、OrientDB、TigerGraph等。

简单来说点表示实体，而边则表示实体间的关系，组成一个整体后，可以形成知识图谱、社交网络、金融风控网络等。

比如存储了上图关系，可以直接查询关注了豆小匠Coding的用户：

MATCH (user:User {name: '豆小匠Coding'})<-[:FOLLOWS]-(follower:User)
RETURN follower.name

上述查询使用了 Neo4j 的图查询语言 Cypher。它首先通过 MATCH 子句找到名为豆小匠的用户节点 user，然后通过 -[:FOLLOWS]-> 关系查找所有关注了该用户的节点 follower。最后，通过 RETURN 子句返回关注者的姓名。

1.3 SQL与NoSQL区别

NoSql是相对于传统关系型数据库而言，有很大差异的一种数据库。

1.3.1 结构化与非结构化

传统关系型数据库是结构化数据，每一张表都有严格的约束信息：字段名、字段数据类型、字段约束等等信息，插入的数据必须遵守这些约束：

而NoSql则对数据库格式没有严格约束，往往形式松散，自由。

可以是键值型：

也可以是文档型：

甚至可以是图格式：

1.3.2 关联和非关联

传统数据库的表与表之间往往存在关联，例如外键：

而非关系型数据库不存在关联关系，要维护关系要么靠代码中的业务逻辑，要么靠数据之间的耦合：

{
  id: 1,
  name: "张三",
  orders: [
    {
       id: 1,
       item: {
	 id: 10, title: "荣耀6", price: 4999
       }
    },
    {
       id: 2,
       item: {
	 id: 20, title: "小米11", price: 3999
       }
    }
  ]
}

此处要维护“张三”的订单与商品“荣耀”和“小米11”的关系，不得不冗余的将这两个商品保存在张三的订单文档中，不够优雅。还是建议用业务来维护关联关系。

1.3.3 查询方式

传统关系型数据库会基于Sql语句做查询，语法有统一标准；

而不同的非关系数据库查询语法差异极大，五花八门各种各样。

1.3.4 事务

传统关系型数据库能满足事务ACID的原则。

而非关系型数据库往往不支持事务，或者不能严格保证ACID的特性，只能实现基本的一致性。

1.3.5 总结

除了上述四点以外，在存储方式、扩展性、查询性能上关系型与非关系型也都有着显著差异，总结如下：

• 存储方式
  • 关系型数据库基于磁盘进行存储，会有大量的磁盘IO，对性能有一定影响
  • 非关系型数据库，他们的操作更多的是依赖于内存来操作，内存的读写速度会非常快，性能自然会好一些

• 扩展性
  • 关系型数据库集群模式一般是主从，主从数据一致，起到数据备份的作用，称为垂直扩展。
  • 非关系型数据库可以将数据拆分，存储在不同机器上，可以保存海量数据，解决内存大小有限的问题。称为水平扩展。
  • 关系型数据库因为表之间存在关联关系，如果做水平扩展会给数据查询带来很多麻烦

二、MySQL

类型：关系型数据库管理系统（RDBMS）

特点：

• 开源：广泛使用，社区支持丰富。任何人都可以获取并使用它的源代码，这为开发者提供了很大的灵活性，因为他们可以按照自己的需求定制数据库系统
• 成熟稳定：经过长时间的发展，性能和稳定性都非常好。MySQL具有优秀的性能，特别是在读取操作方面。它可以处理大量的数据，并支持高并发用户连接
• ACID事务支持：支持事务处理，保证数据的一致性和完整性。
• 索引优化：支持多种索引类型，查询性能优秀。
• 可扩展性：MySQL支持各种扩展功能，如分区、复制和分片等，这使得它能够处理大规模的数据和复杂的业务需求
• 轻量级：资源占用相对较少，适合中小型项目。
• 支持多种数据类型，如整数、浮点数、字符、日期和时间等；拥有不同的存储引擎，如InnoDB和MyISAM，分别适用于不同的应用场景；支持分区功能，可以优化大数据量的存储和访问性能

适用场景：

• Web应用：如博客、论坛、电子商务网站等。
• 中小企业：适合中小企业的数据管理和存储需求。
• OLTP系统：在线事务处理系统，需要频繁的读写操作。

MySQL 对于复杂条件查询的支持并不好。MySQL 最多使用一个条件涉及的索引来过滤，然后剩余的条件只能在遍历行过程中进行内存过滤，对这个过程不了解的同学可以先行阅读一下MySQL 复杂 where 语句分析

上述这种处理复杂条件查询的方式因为只能通过一个索引进行过滤，所以需要进行大量的 I/O 操作来读取行数据，并消耗 CPU 进行内存过滤，导致查询性能的下降。

缺点：

• 写入性能：虽然MySQL在读取操作方面表现出色，但在处理大量写入操作时可能会遇到性能瓶颈。这可能导致在高并发写入场景下性能下降。
• 复杂查询性能：对于复杂查询，MySQL可能没有一些**专门的数据库系统（如PostgreSQL）**表现得那么出色。这可能会在处理复杂的SQL查询时影响到性能。
• 功能丰富度：相比一些其他的数据库系统，MySQL的功能丰富度可能稍显不足。例如，它在全文搜索、数据完整性约束等方面可能没有一些专门的数据库系统那么强大。
• 最大连接数：MySQL的最大连接数相对较小，这可能会限制并发用户连接的数量。

三、PostgreSQL

3.1 特点、适用场景

类型：关系型数据库管理系统（RDBMS）

特点：

• 高级特性：支持大部分的SQL标准，并提供了很多其他现代特性，如复杂查询、外键、触发器、视图、事务完整性、多版本并发控制等高级特性
• 扩展性强：支持多种扩展，如全文搜索、地理空间数据处理等。
• 可定制性：高度可定制，支持用户自定义数据类型和函数。
• ACID事务支持：强一致性和事务支持。
• 开源：社区活跃，文档丰富。

适用场景：

• 复杂查询：需要执行复杂查询和分析的场景。
• 大数据量：适合处理大规模数据集。如物联网和大数据场景
• 企业级应用：需要高可靠性和一致性的企业级应用。适用于金融系统，可以确保数据的一致性和完整性
• 地理信息系统：支持地理空间数据处理，适合GIS应用。

3.2 MySQL与PostgreSQL对比

MySQL和PostgreSQL是两种常见的关系型数据库管理系统（RDBMS），它们都具有强大的功能和广泛的社区支持，但在某些方面存在一些差异，包括特点、性能、扩展性、安全性以及适用场景等方面。

3.2.1 特点比较

• MySQL特点

  • MySQL 是一个基于客户端-服务器架构的开源数据库管理系统，由 Oracle 公司开发和维护。它以其简单性、易用性和高性能而闻名

  • MySQL 支持多种存储引擎，包括 InnoDB、MyISAM、MEMORY 等。每个存储引擎都具有不同的特性和优化策略，可以根据需求选择合适的引擎

  • MySQL 在处理大量读操作时表现良好，并且适用于数据存储和读取需求较高的应用场景

• PostgreSQL特点

  • PostgreSQL 是一个开源对象-关系数据库管理系统，具有强大的功能和高度可扩展性。它以其灵活性、丰富的数据类型和高级特性而受到开发者的青睐。

  • PostgreSQL 支持复杂的数据类型，如数组、JSON、XML 等，并提供了丰富的内置函数和操作符，使得数据处理更加灵活和方便。

  • PostgreSQL 采用 MVCC（多版本并发控制）技术来处理并发访问，支持高度并发的应用场景。

  • PostgreSQL 对完整性约束和事务处理提供了强大的支持，使得数据的一致性和可靠性得到保证。

3.2.2 性能比较

性能是选择数据库的关键因素之一。以下是 MySQL 和 PostgreSQL 在性能方面的比较

• MySQL性能

  • MySQL 在处理大量读操作时表现出色。其存储引擎 InnoDB 提供了行级锁定和高效的事务处理，适用于并发读取的场景
  • MySQL 通过查询缓存来提高读取性能。查询缓存可以缓存查询结果，避免重复执行相同的查询语句
  • MySQL 在处理简单查询和大量连接时表现出色，适用于 Web 应用程序和许多小型数据库的场景

• PostgreSQL特点

  • PostgreSQL 在处理复杂查询和大量写操作时表现出色。它通过优化查询执行计划和索引来提高查询性能
  • PostgreSQL 采用 MVCC 技术，使得并发访问时不会出现阻塞和冲突，从而提供了更好的并发处理性能
  • PostgreSQL 在处理复杂查询和具有复杂数据类型的操作时表现出色。它的查询优化器可以智能地选择最佳执行计划，并且支持各种索引类型和高级查询功能

需要注意的是，性能比较是一个复杂的主题，受到多个因素的影响，如硬件配置、数据量、查询类型和索引设计等。因此，具体的性能表现可能因实际情况而异。在选择数据库时，建议进行基准测试和性能优化，以确保最佳性能

3.2.3 扩展性比较

扩展性是一个重要的考虑因素，特别是在应对数据量增长和并发访问增加的情况下。以下是 MySQL 和 PostgreSQL 在扩展性方面的比较：

• MySQL扩展性

  • MySQL 在水平扩展方面表现良好。它支持主从复制和分片技术，可以将数据分布在多个服务器上，以提高读写性能和容量
  • MySQL 还支持基于触发器和存储过程的复杂业务逻辑，可以将一些计算任务和业务逻辑转移到数据库服务器上进行处理

• PostgreSQL扩展性

  • PostgreSQL 在水平扩展方面也表现良好。它支持流复制和逻辑复制，可以将数据复制到多个节点上，以实现负载均衡和高可用性
  • PostgreSQL 还支持分区表和并行查询，可以更好地处理大型数据集和复杂查询

需要注意的是，扩展性是一个综合问题，还需要考虑硬件资源、网络拓扑、负载均衡等因素。选择适当的扩展策略和架构设计对于实现高性能和可扩展的数据库系统至关重要。

3.2.4 安全性比较

安全性是数据库管理的重要方面。以下是 MySQL 和 PostgreSQL 在安全性方面的比较：

• MySQL安全性

  • MySQL 提供了基本的安全功能，如用户认证、访问控制和加密传输。可以使用用户名和密码进行身份验证，并根据用户的权限控制数据库和表的访问
  • MySQL 支持 SSL/TLS 加密协议，可以通过配置 SSL 证书来保护数据传输的安全性

• PostgreSQL安全性

  • PostgreSQL 提供了丰富的安全功能，如强大的身份认证和访问控制机制。它支持基于角色的访问控制 (RBAC) 和细粒度的权限管理，可以为用户和组分配不同的权限级别
  • PostgreSQL 提供了行级别的安全性，可以在表的行级别上定义访问控制规则，以实现更细粒度的数据保护
  • PostgreSQL 支持加密存储和传输，可以使用 SSL/TLS 加密协议来保护数据的安全性
  • PostgreSQL 提供了高级的审计功能，可以记录用户操作和数据库变更的日志，以实现安全审计和故障排除

需要注意的是，无论是 MySQL 还是 PostgreSQL，在安全性方面都需要合理配置和管理。这包括设置强密码、定期更新软件补丁、限制网络访问和备份数据等措施，以保护数据库免受潜在的安全威胁。

3.2.5 适用场景比较

MySQL 和 PostgreSQL 在功能和性能上的差异使得它们在不同的场景下具有不同的优势。以下是它们的适用场景比较

• MySQL适用场景

  • MySQL 适用于需要处理大量读操作的应用，如 Web 应用程序、电子商务网站和博客平台等。它的简单性和高性能使得它成为许多小型和中型项目的首选
  • MySQL 还适用于需要大规模水平扩展和高可用性的应用场景。它的主从复制和分片技术可以提供更好的性能和容量

• PostgreSQL适用场景

  • PostgreSQL 适用于需要复杂数据类型和高级特性的应用，如地理信息系统 (GIS)、大数据分析和科学研究等。它的灵活性和丰富的功能使得它成为处理复杂数据和查询的首选
  • PostgreSQL 还适用于需要高度并发和可扩展性的应用场景，如金融交易系统、物联网应用和大型企业解决方案

需要根据具体的业务需求和项目规模来选择适合的数据库。如果对数据库的简单性和性能要求较高，可以选择 MySQL。如果需要更复杂的数据类型和功能，以及高度并发和可扩展性，可以选择 PostgreSQL。

3.2.6 补充

1、数据模型和特性：

MySQL：MySQL是一种基于客户端-服务器架构的数据库系统，它采用了主要使用SQL的关系型数据模型。支持ACID（原子性、一致性、隔离性、持久性）事务，并提供了多种存储引擎，如InnoDB、MyISAM等，可以根据需求选择适当的存储引擎。MySQL也具有较好的可扩展性和性能。

PostgreSQL：PostgreSQL也是一种关系型数据库管理系统，支持SQL语言和ACID事务。与MySQL相比，PostgreSQL提供了更丰富的数据类型、更强大的功能和更高效的扩展性。它支持复杂的查询、触发器、视图、存储过程、自定义函数、地理空间数据和全文搜索等。

2、适用场景

MySQL：MySQL通常用于web应用程序、小型到中型规模的数据存储需求，以及需要快速读取和写入的场景。它在处理大量事务和高并发方面表现良好，也适合用于数据驱动型应用程序。

PostgreSQL：PostgreSQL 适用于需要高级功能、复杂查询和更严格数据完整性的场景。它在数据分析、地理信息系统、科学研究和大型企业应用程序等领域广泛使用。

3、扩容成本

MySQL ：在MySQL中，扩容的成本相对较低。可以通过水平扩展（例如，使用主从复制或分片）来增加系统的处理能力和存储容量。MySQL的生态系统非常丰富，有许多工具和解决方案可供选择，支持高可用性和负载均衡。

PostgreSQL：PostgreSQL的扩容成本相对较高。由于其高级功能和复杂性，需要更多的配置和管理工作。扩展PostgreSQL可能涉及到分区、复制、并行查询等技术，需要更多的资源和专业知识。

3.3 小节

MySQL 和 PostgreSQL 都是强大的关系型数据库管理系统，具有各自的特点和优势。MySQL 简单易用、性能优越，适用于处理大量读操作和小型项目；而 PostgreSQL 强大灵活、具备丰富的数据类型和高级特性，适用于处理复杂数据和大型项目。

四、ClickHouse

4.1 特点、适用场景

类型：列式存储数据库

特点：

• 高性能：专为OLAP（在线分析处理）设计，查询速度非常快。
• 列式存储：数据按列存储，适合大规模数据分析。
• 支持水平扩展和分布式部署：支持分布式部署，水平扩展能力强。
• 实时分析：支持实时数据处理和分析。
• 开源：社区活跃，文档丰富。
• 支持快速处理大规模数据并支持高并发查询；具有数据冗余和自动故障转移功能，保证数据的安全性和可靠性

适用场景：

• 大数据分析、日志分析、实时数据处理和数据仓库等场景

  • 大数据分析：适合处理大规模数据集，进行实时分析和报表生成
  • 日志分析：适合处理日志数据，进行监控和分析

• BI系统：商业智能系统，需要快速响应复杂的分析查询。

• 物联网：处理大量传感器数据，进行实时监控和分析。

• 适用于需要高性能、高可靠性和低延迟查询的数据处理任务

优异的性能和实时分析能力

• ClickHouse的性能特点：

  • 列式存储：ClickHouse采用了列式存储，对于聚合查询和数据分析非常有效。

  • 数据压缩：ClickHouse具有高效的数据压缩机制，可以显著减少存储空间和I/O开销。

  • 分布式处理：ClickHouse支持分布式部署，能够处理大规模数据集。

• ClickHouse的数据分析

  • ClickHouse则专注于数据分析场景，特别是对于在线分析处理（OLAP）任务。它支持SQL查询，具有高效的列式存储和压缩机制，适用于执行复杂的聚合查询

4.2 ClickHouse与MySQL的适用场景对比

ClickHouse和MySQL是两种完全不同的数据库系统。

• MySQL的适用场景：MySQL适用于事务处理，如网站后台、订单处理、用户管理等场景。它支持ACID事务、一致性以及丰富的SQL功能。

• ClickHouse的适用场景：ClickHouse则更适合于数据分析、报表生成、实时监控等场景。它支持高速的数据导入和查询，适用于处理大规模数据集。

clickhouse 不支持事务、不存在隔离级别，其定位是分析性数据库 OLAP系列，count()有天然优势；MongoDB最初不支持，4.0支持事务 ACID。

五、MongoDB

5.1 特点、适用场景

类型：NoSQL文档数据库（数据模式不固定、结构可以不同）

特点：

• 文档存储：以JSON-like的二进制文档格式（BSON格式）存储数据，灵活性高。数据模式不固定、结构可以不同
• 水平扩展：支持分片，容易水平扩展。
• 高性能：读写性能优秀，适合高并发场景。
• 动态模式：支持动态模式，无需预先定义表结构。
• 丰富的查询语言：支持复杂的查询操作，如聚合、排序、分组等。
• 具备灵活的文档模型、强大的查询能力和水平扩展性；支持数据分片、高可用性和地理空间索引等功能

适用场景：

• 适用于需要灵活的数据模型、快速开发迭代、大规模数据处理和高可用性需求的应用场景

• 如内容管理系统（CMS）、大数据应用、实时分析与日志数据处理、电子商务系统、物联网（IoT）应用、社交网络平台和云计算等

  • 内容管理系统：如博客、新闻网站等，需要存储和检索大量非结构化数据。

  • 实时分析：适合处理实时数据流，进行实时分析。

  • 物联网：处理大量传感器数据，存储和检索非结构化数据。

  • 社交媒体：适合存储和检索用户生成的内容，如帖子、评论等。

  • 缓存层：作为缓存层，提高应用性能。

使用 MongoDB 时，数据模式不是固定的。在一个集合内部删除或修改文档的某些属性是可行的，这就提供了很大的灵活性。而且，同一集合内的文档，其结构可以是完全不同的。

在 MongoDB 中，数据是以类似于 JSON 文件的名值对形式存在的，因其模式设计，它对数据的约束条件较少。因此如果数据是快速变化的，MongoDB 就很有优势。另外，MongoDB 还提供了预定义的结构，如果需要也可以使用

5.2 MySQL与MongoDB对比

• MongoDB 是一种文档型数据库，由于它不限制数据量和数据类型，它是高容量环境下最合适的解决方案。由于 MongoDB 具备云服务需要的水平可伸缩性和灵活性，它非常适合云计算服务的开发。另外，它降低了负载，简化了业务或项目内部的扩展，实现了高可用和数据的快速恢复。

• 尽管 MongoDB 有那么多优点，但 MySQL 也在某些方面优于 MongoDB，例如可靠性和数据一致性。另外，如果优先考虑安全性，MySQL 就是安全性最高的 DBMS 之一。

• 而且，当应用程序需要把多个操作视为一个事务（比如会计或银行系统）时，关系数据库是最合适的选择。除了安全性，MySQL 的事务率也很高。实际上，MongoDB 支持快速插入数据，而 MySQL 相反，它支持事务操作，并关注事务安全性。

六、总结

6.1 四种数据库适用场景

• MySQL：适合中小型企业、Web应用、OLTP系统（事务处理，可靠、数据一致性、安全性；复杂条件查询较差）
• PostgreSQL：适合复杂查询、大数据量、企业级应用、地理信息系统
• ClickHouse：适合大数据分析、日志分析、BI系统、物联网（实时分析、高并发查询）
• MongoDB：适合内容管理系统、实时分析、物联网、社交媒体、缓存层（数据模型灵活，大规模数据处理）

选择哪种数据库取决于你的具体需求，包括数据规模、查询复杂度、性能要求、扩展性等因素。

6.2 场景专用数据库

随着业务的复杂，我们会发现不同场景下对数据库的要求差异会很大：

1. 一致性优先，选用关系型数据库。
2. 高性能全文搜索，使用Elasticsearch。
3. 非关键数据，读多写少，量大，选用列式存储。
4. 离线数据分析，Hive。

6.3 补充——MySQL遇到瓶颈

如果是单机MySQL遭遇性能瓶颈，可以通过主从架构读写分离，堆机器的方式解决，另一个方向是增加缓存，如Redis等，减少打到物理存储的请求量。

如果是数据量太大，单表查询性能下降，可以考虑分库分表，但是分库分表在开发时需要考虑更多分布式事务、水平扩展等因素，对研发效率有影响。因此，这个时候可以考虑使用分布式数据库，如TiDB等。

参考 一个项目，用十款数据库？、MySQL 和 PostgreSQL，我到底选择哪个