大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

上个月一个刚转行做数据开发的朋友问我：“小耶，我听说有时序数据库、向量数据库、图数据库……这些和MySQL到底什么关系？我该从哪个学起？”

这个问题问到了根子上。很多人学数据库，一上来就扎进MySQL的语法里，结果学了半年发现还有个东西叫MongoDB，又学了三个月发现还有个东西叫Redis——永远在追，永远追不完。

今天不教你怎么写SQL，先画一张数据库的“家谱”，把整个数据库家族的关系搞清楚。这条路走通了，后面的学习就清晰了。

数据库的分类方式不止一种。就像人可以用性别分、可以用国籍分、可以用职业分——数据库也可以从不同角度来划分。但最核心、最常用的分类维度有三个：

按数据模型分、按业务负载分、按部署架构分

一张订单表，按数据模型它是关系型的，按业务负载它是OLTP的，按部署架构它可能是集中式的。三个维度看的是同一件事的不同侧面，组合起来才能完整描述一个数据库的“画像”。

数据长什么样、怎么组织。关系型把数据塞进二维表格，非关系型用键值对、JSON文档、图关系等各种形态。

数据存进去是用来查的，但“怎么查”决定了数据库的设计方向。OLTP扛高并发短事务，OLAP做海量数据聚合分析。

数据放在一台机器还是拆在多台机器上协同工作，决定了系统的扩展方式和运维复杂度。

二、按数据模型分类：关系型与非关系型

这是数据库最顶层的分类——就像“动物”和“植物”一样。

1970年IBM研究员E.F. Codd发表了一篇论文，提出了关系模型。数据用二维表格组织，行是记录，列是字段，表与表之间通过主键和外键关联。它的核心优势是ACID事务、复杂SQL查询、数据强一致性。

你可以把关系型数据库想象成一个档案室，每个文件柜有固定的分类标签，每份文件按编号排列在固定的抽屉里。找一份文件，你只需要知道它的编号，就能顺着索引精确定位到它所在的抽屉。新增一份文件，你必须先确定它属于哪个分类，填好所有必填字段，再放进去。如果有一份文件缺了必填信息，档案室管理员会拒绝入库——这就是关系型数据库的Schema约束。

2026年DB-Engines排行榜上，前五名有四个是关系型数据库。MySQL是互联网标配，PostgreSQL功能最全面，Oracle和SQL Server在企业核心系统里地位稳固。国产方面，金仓KingbaseES在政务、金融、能源等行业快速落地，Oracle兼容度高，迁移成本相对可控。

NoSQL的意思是“Not Only SQL”——不只是SQL。它在关系型之外开辟了多条分支，每种都有自己的适用场景。

数据存成Key-Value对，根据Key查Value极快。Redis是典型代表。

你可以把它想象成字典——你知道一个字，直接翻到那一页，不用从头看起。字典里没有复杂的目录结构，只有“字→释义”的映射。这就是Key-Value模型：一个Key对应一个Value，查询速度O(1)，但你不能问“所有Value里包含某个关键词的Key有哪些”——字典不支持这种查法。

Redis适合缓存、Session存储、计数器，读写速度是磁盘的几十倍。它把所有数据放在内存里，所以快，但也意味着成本高、容量有限。

数据存成JSON/BSON文档，每个文档的字段可以不一样。MongoDB是典型代表。

你可以把它想象成一个档案袋——每个学生一个档案袋，张三的档案袋里有成绩单、体检表、家庭情况登记表，李四的档案袋里只有成绩单和体检表，没有家庭情况登记表。档案室管理员不会要求每个档案袋里的文件种类完全一致。这就是文档型数据库“无Schema约束”的核心：同一张“表”里的不同文档，可以有不同的字段结构。

MongoDB适合内容管理、日志存储、用户配置，支持在JSON字段上建索引，也能做多文档事务。

按列族组织数据，适合海量数据写入和查询。Cassandra、HBase是典型代表。

你可以把它想象成超市货架——每一列商品放在同一排货架上，你要找某种商品，直接去那一排，不需要整层楼逛一遍。传统行存是一条记录的所有字段放在一起，列族型是把同一列的数据集中存放。在分析场景下，你只需要读少数几列时，列族型比行存少读大量无关数据。

数据存成节点和边——节点代表实体，边代表关系。Neo4j是典型代表。

你可以把它想象成一张人际关系网——每个人是一个节点，每一条“认识”“同事”“朋友”是连接节点的边。你要查“张三的朋友中谁认识李四”，在关系网里顺着边跳两下就能找到答案。传统关系型数据库做同样的事情需要递归查询，层数越多越慢。图数据库在“朋友的朋友”这类多跳查询上比关系型快几十倍甚至上百倍。

图数据库适合社交网络、风控反欺诈、知识图谱等场景。

三、按业务负载分类：OLTP与OLAP

订单、支付、用户注册、库存扣减——这类系统的核心诉求是“快”和“准”。特点是高并发、短事务、强一致。用户下单扣库存，必须保证不超卖。每秒上百笔交易，每笔只涉及几行数据，要求毫秒级响应。MySQL、PostgreSQL、Oracle是OLTP的典型代表。

你可以把它想象成便利店收银台——每个顾客买的东西不多，几样商品扫码结账，但排队的人一直不断。每一笔收据不能算错账，找零不能出错，否则顾客立刻投诉。这就是OLTP的约束：高频、快速、零差错。

报表、大屏、数据仓库——这类系统的核心诉求是“全”和“深”。特点是数据量大、查询复杂、对响应时间容忍度高。业务方要“上个月各品类销售额TOP10”，OLAP数据库几秒钟就能算出来。ClickHouse、Doris是OLAP的典型代表。

你可以把它想象成超市月底盘点——不着急出结果，但数据量大，要把所有货架都数一遍，还要按品类汇总、按时间段对比。这种查询不需要秒级响应，几十秒甚至几分钟都能接受，但它要求数据库能快速扫描几千万行数据做聚合运算。

四、按部署架构分类：集中式、分布式与云原生

数据全部放在一台服务器上（或主从集群里），架构简单、运维成熟。适合数据量可控、事务复杂度高的场景。金仓KingbaseES、MySQL都是集中式的典型代表。

你可以把它想象成一家小卖部——一个老板、一个收银台、一个货架，忙得过来就够用。生意扩大之前，这套系统足够支撑。

数据自动分片到多台服务器，水平扩展能力强。适合数据量巨大（50TB以上）、写入并发极高的场景。OceanBase、TiDB是典型代表。你可以把它想象成连锁超市——每个分店负责一部分区域的顾客，数据分散存储，总部统一调度。

存算分离，计算节点无状态可独立扩缩容。适合云上弹性业务。PolarDB、GaussDB是典型代表。

五、专项数据库：为特定场景而生的“特种部队”

2026年的数据库家族还有一批“特种部队”，它们不在传统的关系型/非关系型分类框架里，而是为特定数据形态和查询模式独立发展出来的专用产品线。

专门处理带时间戳的数据——设备传感器读数、服务器监控指标、股票行情。数据每秒钟都在产生，查询永远围绕时间窗口展开，“过去24小时的平均温度”“最近7天的峰值流量”是典型查询。InfluxDB、TDengine是代表产品。

你可以把它想象成工厂里的温度记录仪——每隔几秒自动记录一次温度，记录仪上只写时间和数值，不问“这条记录属于哪个批次、哪个班组”。查询时只关心“昨天下午3点到5点之间温度有没有超过警戒线”。时序数据库就是为了这种“只关心时间序列值”的场景而设计的，专门优化了高频写入和按时间范围的聚合查询。

存储AI模型生成的向量数据，做相似度搜索。RAG应用、以图搜图、推荐系统都在用。Milvus是典型代表。

你可以把它想象成指纹库——每个指纹是一串特征点（向量），你要找“和这个指纹最相似的人”，不需要精确匹配，而是找出特征点最接近的那几个。传统数据库的精确匹配在这里派不上用场，向量数据库专门解决这个问题：在海量高维向量中快速找到“最相似”的那一批。

六、2026年的新趋势：多模数据库

搞清楚上面所有分类之后，你会发现一个有意思的问题：如果业务同时需要关系型存订单、文档型存日志、向量型做AI检索，是不是要维护三套数据库？

正在从概念走向规模化落地。一套数据库内核原生支持关系、文档、向量、图等多种数据模型。比如金仓KingbaseES V9在多模融合方面走得比较靠前，原生支持关系数据、JSON文档、向量数据、时序数据及GIS空间数据。跨模型查询在同一个SQL里完成，不再需要多套系统拼接。

传统方案需要为每种数据类型部署独立的数据库系统，数据孤岛林立、运维成本翻倍。多模数据库正在改变这个局面。

七、一张图看懂数据库“家谱”

数据库的“家谱”看起来复杂，但理清楚之后就是一个三层的树形结构：

2026年还有一个正在加速的趋势：多模融合。关系型、文档型、时序型、向量型正在被集成到同一个数据库内核中。传统上需要为每种数据类型部署独立数据库的做法，正在被“一库多模”取代。

每种数据库类型都有自己的适用边界和不可替代的理由。核心交易要准，缓存要快，图要查关系，向量要找相似——没有哪一种能通吃所有场景。选型的起点不是“哪个产品最好”，而是“你的业务数据长什么样、怎么查”。这个判断做对了，后面的选型才不会跑偏。

以后我们会逐个深入每一种数据库类型——从背景、原理到产品选型，一次讲透。

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~

零基础入门数据库分类：MySQL/MongoDB/Redis/Neo4j/InfluxDB之间到底是什么关系？

本文从按数据模型、按业务负载、按部署架构三个维度，完整拆解了数据库家族的分类体系：关系型与非关系型的本质差异、OLTP与OLAP的业务边界、集中式/分布式/云原生的架构取舍，以及时序、向量等专项数据库的适用场景。一张“家谱”帮你理清整个数据库家族的关系，为后续选型和深入学习建立清晰的认知框架。

数据库

架构设计

大数据

数据库家族三大分类维度：数据模型（关系型/非关系型）、业务负载（OLTP/OLAP）、部署架构（集中式/分布式/云原生）。2026年趋势是多模数据库融合关系、文档、向量、时序等模型，实现一库多模。选型关键是明确业务数据形态与查询方式，而非追逐产品热度。

关系型数据库

向量数据库

数据仓库

知识图谱

PostgreSQL

服务器

云原生

MongoDB

HBase

Redis

MySQL

腾讯云数据库特惠，新用户首单0.5折起


2026上云采购 | AI焕新·智启新局

ctsdb

tchousec

腾讯云BI特惠9.9元起！


tchoused

tchousep

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

零基础入门数据库分类：MySQL/MongoDB/Redis/Neo4j/InfluxDB之间到底是什么关系？

零基础入门数据库分类：MySQL/MongoDB/Redis/Neo4j/InfluxDB之间到底是什么关系？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐