系统架构技术选型之 DB 篇

以下根据八大类别，逐一分析各个领域常用数据库的核心特点与典型使用场景，帮助你在实际项目中做出精准选型。

• 关系型数据库：MySQL、Oracle、PostgreSQL、SQL Server
• 关系型分布式数据库：TiDB、Spanner、OceanBase、CockroachDB、YugabyteDB
• 键值数据库：Redis、Memcached、RocksDB、DynamoDB、Etcd
• 文档数据库：MongoDB、CouchDB 、Elasticsearch（搜索引擎）、Couchbase
• 列式数据库：ClickHouse、Doris、StarRocks、Druid
• 宽表数据库：Cassandra、HBase、ScyllaDB
• 时序数据库：InfluxDB、Prometheus、TDengine、TimescaleDB
• 图数据库：Neo4j、JanusGraph、Dgraph、NebulaGraph

不同类别数据库的比较：

类别	核心原理	数据模型	一致性	扩展方式	典型优势	主要局限	使用场景
关系型数据库	基于关系模型 + ACID 事务，B+树索引	表（行/列） 固定 Schema	强一致性（ACID）	垂直扩展为主，分库分表复杂	事务强、SQL 标准、生态成熟	水平扩展难，Schema 变更成本高	订单系统、支付、ERP、CRM 等强一致业务
关系型分布式数据库	分布式架构 + SQL 兼容 + 分布式事务	表（逻辑） 自动分片	强一致性 （分布式 ACID）	水平扩展（自动分片）	高可用、弹性扩缩容、兼容 SQL	运维复杂，部分复杂查询性能弱	互联网高并发交易、HTAP 混合负载、替代分库分表
键值数据库	Key → Value 映射，哈希/LSM-Tree 存储	Key-Value	弱一致（Redis）强一致（etcd）	水平扩展（如 Redis Cluster）	极低延迟（μs 级）、高吞吐	无复杂查询，无法按 Value 检索	缓存、会话、分布式锁、配置中心、底层存储引擎
文档数据库	JSON/BSON 文档存储，无固定 Schema	自包含文档 （嵌套结构）	最终一致 强一致	水平扩展（按文档 ID 分片）	Schema 灵活、开发效率高、减少 JOIN	跨文档事务弱，存储冗余	CMS、用户画像、IoT 设备数据、快速迭代产品
列式数据库 (OLAP)	按列存储 + 向量化执行 + 高压缩	列族（宽表） 面向分析	最终一致 （近实时）	水平扩展（MPP 架构）	聚合查询极快（亿级秒出）	不支持高并发点查，写入成本高	实时报表、用户行为分析、BI 看板、广告效果分析
宽表数据库	行 + 动态列族，LSM-Tree 存储	RowKey + ColumnFamily （Qualifier）	CP（HBase） AP（Cassandra）	水平扩展（自动分片）	高写入吞吐、适合稀疏数据	仅支持 RowKey 查询，JOIN 困难	聊天记录、消息历史、推荐特征宽表、IoT 时序写入
时序数据库	时间分区 + 列式压缩 + 追加写	时间戳 + 指标 + 标签	最终一致	水平扩展（按时间/设备分片）	高密度写入 + 高效压缩	通用性弱，非时序场景不适用	服务器监控、IoT 指标、APM、金融行情
图数据库	节点 + 边 + 属性，邻接表存储	图结构（Vertex/Edge）	强一致（单机）最终一致（分布式）	水平扩展（部分支持）	深度关系遍历极快	不适合简单 CRUD，生态较小	社交关系、欺诈检测、知识图谱、反洗钱

需求和推荐数据库类型：

需求	推荐数据库类型	特点
需要 ACID 事务、强一致性	关系型 / NewSQL	ACID 事务
数据结构频繁变化、半结构化	文档数据库	数据结构频繁变化
极致缓存性能、简单读写	键值数据库	数据查询性能高
实时报表、用户行为分析	列式数据库（OLAP）	实时聚合分析
海量写入、稀疏数据、RowKey 查询	宽表数据库	高并发写入 + 稀疏数据
监控、IoT、指标数据	时序数据库	时间戳 + 指标值的数据
社交、风控、知识图谱	图数据库	是“关系”而非“属性”
全文搜索、日志分析	搜索引擎（Elasticsearch）	全文搜索或日志分析

需求和推荐数据库：

需求	推荐数据库
强事务 + 高并发 OLTP	TiDB、CockroachDB、PostgreSQL
灵活 Schema + 快速迭代	MongoDB、Couchbase
全文搜索 + 日志分析	Elasticsearch
实时数仓 + 多维分析	StarRocks、Doris、ClickHouse
全球分布式 + 强一致	Spanner、CockroachDB、OceanBase
IoT / 监控时序数据	TDengine、InfluxDB、Prometheus
社交/风控图关系	Neo4j、NebulaGraph
高写入 + 高可用	Cassandra、ScyllaDB
缓存 / 会话 / 锁	Redis
K8s / 分布式协调	Etcd

• 同类选型优先看“生态匹配”：如团队熟悉 PostgreSQL → 优先考虑 TimescaleDB/YugabyteDB；

• 云上项目优先托管服务：如 AWS → DynamoDB，GCP → Spanner；

• 性能敏感场景做 PoC：如 ClickHouse vs StarRocks，需实测写入/查询负载；

• 避免过度设计：简单缓存用 Redis 足矣，无需上 Couchbase。

关系型数据库（OLTP）

OLTP（OnLine Transaction Processsing ）为联机事务处理。是与功能、业务强相关的事务查询系统，要保证高并发场景下低时延的查询和处理效率。

• 基于 关系模型（表、行、列） 和 ACID 事务；

• 使用 SQL 作为标准查询语言；

• 通过 B+树索引 支持高效点查和范围查询；

• 通常采用 主从复制 或 共享存储 实现高可用。

典型使用场景

• 需要强一致性和复杂事务的业务系统（如银行转账、订单支付）；

• 数据结构相对稳定，表间存在强关联（如用户-订单-商品）；

• 需要复杂 JOIN、子查询、窗口函数等分析能力；

• 企业核心 ERP、CRM、财务系统。

局限和不足

• 水平扩展困难（分库分表复杂）；

• 不适合半结构化或频繁变更的 Schema；

• 高并发写入时性能瓶颈明显。

MySQL

• 特点：

  • 开源、社区活跃、生态完善；
  • 支持 InnoDB（ACID）、主从复制、分库分表（ShardingSphere/Vitess）；
  • 性能均衡，适合中高并发 OLTP。

• 使用场景：

  • Web 应用后端（电商、社交、CMS）；
  • 中小企业核心业务系统；
  • 与 ORM（如 MyBatis、Hibernate）深度集成。

PostgreSQL

• 特点：

  • 功能强大：支持 JSONB、GIS、全文检索、窗口函数、逻辑复制；
  • 严格遵循 SQL 标准，扩展性强（FDW、插件）；
  • MVCC 实现优秀，读写性能均衡。

• 使用场景：

  • 复杂查询、地理信息系统（PostGIS）；
  • 金融、电信等对数据一致性要求高的系统；
  • 作为 TimescaleDB、Citus 等扩展的基础。

Oracle

• 特点：

  • 商业数据库王者，高可用（RAC）、高安全、强事务；
  • 运维复杂、成本高；
  • 支持海量数据、复杂 PL/SQL。

• 使用场景：

  • 银行、保险、政府等传统行业核心系统；
  • 需要强审计、高 SLA 的关键业务。

SQL Server

• 特点：

  • 与 Windows/.NET 生态深度集成；
  • BI 工具（SSIS/SSAS/SSRS）强大；
  • 云上 Azure SQL 提供托管服务。

• 使用场景：

  • 企业内部 ERP、CRM 系统（尤其微软技术栈）；
  • 数据仓库与报表分析一体化场景。

全面比较

数据库	开源	高可用方案	扩展性	典型优势	主要局限	适用场景
MySQL	是	主从复制、MGR、InnoDB Cluster	垂直扩展为主，分库分表需中间件	生态成熟、社区活跃、运维简单	复杂查询优化弱，JSON 支持一般	Web 应用、中小电商、SaaS 后端
PostgreSQL	是	流复制 + Patroni、逻辑复制	垂直扩展，Citus 支持分片	功能强大（GIS、JSONB、窗口函数）、标准兼容好	运维略复杂，内存管理较重	金融系统、地理信息、复杂分析型 OLTP
Oracle	否	RAC（Real Application Clusters）	垂直扩展，Exadata 支持横向	企业级高可用、安全审计强、PL/SQL 成熟	成本极高、运维复杂	银行核心系统、政府、大型企业 ERP
SQL Server	否（有 Express 免费版）	Always On AG、Failover Cluster	垂直扩展，Azure SQL 支持弹性池	与 .NET 深度集成、BI 工具强大	仅 Windows/Linux 有限支持，云绑定强	企业内部系统（ERP/CRM）、微软技术栈

关系型分布式数据库（NewSQL）

• 在保留 SQL 兼容性 + ACID 事务 的前提下，通过 分布式架构（如 Raft/Paxos + 分片）实现水平扩展；

• 数据自动分片（Sharding），计算与存储分离；

• 支持 分布式事务（如 2PC、Percolator、TSO）。

典型使用场景

• 互联网高并发交易系统（如双11订单、支付）；

• 需要从 MySQL/Oracle 平滑迁移 且解决扩展性问题；

• HTAP 混合负载（同时支持 OLTP + 实时分析）；

• 全球多活部署（如 SaaS 服务）。

局限和不足

• 运维复杂度高于单机数据库；

• 部分 NewSQL 对复杂 JOIN 支持有限；

• 开源版功能可能弱于商业版。

TiDB

• 特点：

  • 兼容 MySQL 协议，HTAP 架构（TiKV + TiFlash）；
  • 强一致性（Raft）、弹性扩缩容；
  • 适合从 MySQL 平滑迁移。

• 使用场景：

  • 互联网高并发交易系统（如支付、订单）；
  • 需要实时分析的混合负载（HTAP）；
  • 替代 MySQL 分库分表方案。

CockroachDB

• 特点：

  • 兼容 PostgreSQL 语法；
  • 多活（Multi-Region）部署，自动故障转移；
  • 强一致性（基于 Raft + HLC）。

• 使用场景：

  • 全球分布式 SaaS 应用；
  • 对数据强一致性和高可用要求极高的系统；
  • 云原生架构（K8s 友好）。

OceanBase

• 特点：

  • 蚂蚁集团自研，Paxos 多副本强一致；
  • 高压缩比、低成本存储；
  • 支持超大规模集群（百万 QPS）。

• 使用场景：

  • 金融级核心系统（如双11交易）；
  • 国内政企、银行替换 Oracle 的首选。

Spanner（Google Cloud）

• 特点：

  • 全球分布式、TrueTime API 实现外部一致性；
  • 托管服务，无需运维；
  • 成本高，仅限 GCP。

• 使用场景：

  • 全球化业务（如 Google Ads、Play Store）；
  • 需要跨洲强一致性的 SaaS 平台。

YugabyteDB

• 特点：

  • 兼容 PostgreSQL + Cassandra API；
  • 分布式 SQL，支持多模型；
  • 开源 + 云托管（YugabyteDB Managed）。

• 使用场景：

  • 需要同时处理关系型和宽表数据的混合场景；
  • 从 Cassandra 迁移但希望获得 SQL 能力。

全面比较

数据库	开源	SQL 兼容	分布式事务	多活支持	典型优势	主要局限	适用场景
TiDB	是	MySQL	支持（Percolator）	同城多活	与 MySQL 兼容，HTAP 一体	跨 AZ 延迟敏感，资源消耗大	替代 MySQL 分库分表，互联网高并发交易
CockroachD	是（BSL）	PostgreSQL	支持（Spanner-like）	全球多活	强一致性、K8s 友好、自动 rebalance	JOIN 性能一般，学习曲线陡	全球化 SaaS、云原生应用
OceanBase	是（社区版）	MySQL / Oracle	支持（Paxos）	多地多活	高压缩比、金融级高可用	生态较新，文档偏中文	银行核心系统、国产化替代 Oracle
Spanner	是（GCP 托管）	ANSI SQL	支持（TrueTime）	全球强一致多活	全球部署、外部一致性	仅 GCP，成本高	Google 级全球化业务（如 Ads）
YugabyteDB	是	PostgreSQL + Cassandra	支持	多区域部署	多 API 支持，云原生	社区较小，企业版功能强	混合负载（关系+宽表），云迁移

键值数据库（KV）

• 最简单的 NoSQL 模型：Key → Value；

• Value 可以是字符串、字节数组，或复杂结构（如 Redis 的 List/Hash）；

• 通常基于 哈希表 或 LSM-Tree 实现；

• 读写性能极高（微秒级延迟）。

典型使用场景

• 缓存（Redis 缓存热点数据）；

• 会话存储（用户登录态）；

• 分布式锁、计数器、排行榜；

• 配置中心、服务发现（etcd）；

• 底层存储引擎（RocksDB 被 Kafka、Flink 等使用）。

局限和不足

• 不支持复杂查询（无 WHERE、JOIN）；

• 无法按 Value 内容检索（除非额外建索引）；

• 通常不保证强一致性（除 etcd 等协调类 KV）。

Redis

• 特点：

  • 内存存储，支持 String/List/Hash/Set/ZSet/Stream；
  • 持久化（RDB/AOF）、主从、Cluster；
  • 低延迟（微秒级）。

• 使用场景：

  • 缓存（热点数据）；
  • 分布式锁、会话存储、排行榜、消息队列（轻量）。

Memcached

• 特点：

  • 纯 KV，无数据结构；
  • 多线程、高性能，但无持久化、无高可用。

• 使用场景：

  • 简单缓存（如页面缓存）；
  • 作为 Redis 的补充（极简场景）。

RocksDB

• 特点：

  • 嵌入式、LSM-Tree 存储引擎；
  • 高写入吞吐，用于底层存储。

• 使用场景：

  • 作为 Kafka、Flink、TiDB、Cassandra 等系统的存储引擎；
  • 自研数据库的底层组件。

DynamoDB（AWS）

• 特点：

  • 托管服务，自动扩缩容；
  • 支持文档和键值，强一致性可选；
  • 按请求计费。

• 使用场景：

  • Serverless 应用后端；
  • 高可用、免运维的云原生应用。

Etcd

• 特点：

  • 基于 Raft 的分布式 KV；
  • 强一致性、Watch 机制；
  • K8s 的核心组件。

• 使用场景：

  • 分布式系统配置中心；
  • 服务发现、Leader Election。

全面比较

数据库	存储位置	数据结构	持久化	高可用	典型优势	主要局限	适用场景
Redis	内存（可持久化）	String/List/Hash Set/ZSet/Stream	支持（RDB/AOF）	Sentinel / Cluster	丰富数据结构、低延迟（μs）	内存成本高，大 Key 风险	缓存、会话、排行榜、轻量队列
Memcached	内存	纯 KV	不支持	无（客户端分片）	多线程、极高并发	无持久化、无高可用、功能单一	简单缓存（页面/会话）
RocksDB	磁盘（嵌入式）	KV（LSM-Tree）	支持	无（依赖上层）	高写入吞吐、低资源占用	非独立服务，需集成	作为 Kafka/Flink/TiDB 底层引擎
DynamoDB	云托管	KV + 文档	支持	自动多 AZ	免运维、自动扩缩容、按需计费	云绑定、调试困难	Serverless 应用、云原生后端
etcd	磁盘	KV	支持（WAL + Snapshot）	Raft 多副本	强一致、Watch 机制、K8s 核心	不适合大 Value、吞吐有限	分布式协调、配置中心、服务发现

文档数据库（NoSQL）

• 以 JSON/BSON 文档 为基本单元，支持嵌套结构；

• 无固定 Schema，字段可动态增减；

• 每个文档自带完整上下文，减少 JOIN；

• 通常按 文档 ID 哈希分片，支持水平扩展。

典型使用场景

• 内容管理系统（CMS）（文章、商品详情）；

• 用户画像（每个用户一个文档，属性动态）；

• IoT 设备数据（设备上报 JSON，结构不一）；

• 快速迭代的互联网产品（避免频繁改表）；

• 移动端离线同步（CouchDB 的多主复制）。

局限和不足

• 复杂跨文档 JOIN 困难（需应用层处理）；

• 事务支持有限（MongoDB 4.0+ 支持，但性能有损）；

• 存储空间通常大于关系型（冗余字段）。

MongoDB

• 特点：

  • BSON 文档模型，灵活 Schema；
  • 支持聚合管道、索引、事务（4.0+）；
  • 分片集群支持水平扩展。

• 使用场景：

  • 内容管理（CMS）、用户画像；
  • IoT 设备数据存储；
  • 快速迭代的互联网产品（避免频繁改表）。

CouchDB

• 特点：

  • HTTP/RESTful API；
  • 多主同步（Multi-Master Replication）；
  • 离线优先。

• 使用场景：

  • 移动端/边缘设备数据同步（如医疗、野外作业）；
  • 分布式协作系统。

Couchbase

• 特点：

  • 文档 + KV + SQL++ 查询；
  • 内存优先架构，低延迟；
  • 企业级安全与监控。

• 使用场景：

  • 高并发 Web 应用（如游戏、社交）；
  • 会话存储、实时推荐系统。

Elasticsearch（搜索引擎）

• 特点：

  • 倒排索引 + 全文检索；
  • 实时聚合、近实时写入；
  • 分布式原生支持。

• 使用场景：

  • 商品/文章搜索；
  • 日志分析（ELK）；
  • 监控告警、用户行为分析。

全面比较

数据库	文档格式	事务支持	查询能力	同步能力	典型优势	主要局限	适用场景
MongoDB	BSON	支持（4.0+ 多文档）	聚合管道、索引、文本搜索	副本集 + 分片	生态最强、工具链完善	事务性能有损，存储膨胀	用户画像、CMS、IoT 设备数据
CouchDB	JSON	不支持	MapReduce、Mango Query	多主双向同步	离线优先、HTTP API	查询能力弱，社区小	移动端离线应用、边缘计算
Couchbase	JSON	支持（部分）	N1QL（类 SQL）、全文搜索	XDCR（跨集群复制）	低延迟、企业级功能全	商业版贵，开源版功能有限	游戏后端、实时推荐、会话存储
Elasticsearch	JSON	不支持	全文检索、聚合、向量搜索	分片副本自动同步	搜索性能极强、近实时	不适合主库，更新成本高	商品搜索、日志分析（ELK）、监控

列式数据库（OLAP）

OLAP（OnLine Analytical Processing ）为联机分析处理。是数据仓库系统的主要应用，能够支持复杂的分析操作，与数据库需要直接直接线上业务不同，数据仓库侧重于分析决策，提供直观的数据查询结果。

• 数据按 列连续存储（而非按行），适合只读少数列的聚合查询；

• 利用 向量化执行、数据压缩（同列数据相似度高）提升性能；

• 通常采用 MPP（大规模并行处理） 架构；

• 不支持高并发点查或事务。

典型使用场景

• 实时数仓（替代 Hive + Spark）；

• 用户行为分析（PV/UV、漏斗、留存）；

• BI 报表、Dashboard（秒级响应亿级数据）；

• 广告效果分析、风控指标计算。

局限和不足

• 写入吞吐较低（需合并段文件）；

• 不适合频繁更新或点查；

• 无法作为业务主库（OLTP）。

ClickHouse

• 特点：

  • 向量化执行、极致压缩；
  • 高吞吐（十亿级数据秒级响应）；
  • 不支持事务、更新成本高。

• 使用场景：

  • 用户行为分析、广告效果分析；
  • 实时报表、BI 看板。

Doris / StarRocks

• 特点：

  • MPP 架构，支持高并发点查 + 复杂聚合；
  • 实时更新（Primary Key 模型）；
  • 兼容 MySQL 协议。

• 使用场景：

  • 实时数仓（替代 Hive + Spark）；
  • 多维分析（如 GMV、DAU 实时看板）。

Druid

• 特点：

  • 流批一体，低延迟摄入；
  • 高并发查询（数千 QPS）；
  • 时间分区 + 列式存储。

• 使用场景：

  • 实时监控（如 APM、IoT 指标）；
  • 用户行为漏斗分析。

全面比较

数据库	架构	实时写入	高并发点查	SQL 支持	典型优势	主要局限	适用场景
ClickHouse	MPP	高频追加	低并发	类 SQL	极致分析性能、高压缩	不支持事务，更新困难	用户行为分析、广告报表
StarRocks	MPP	Primary Key 模型	可	MySQL 协议	实时更新 + 高并发 + 复杂聚合	运维较新，社区成长中	实时数仓、BI 看板
Doris	MPP	支持	可	MySQL 协议	开源、易用、兼容 StarRocks	功能略少于 StarRocks	中小企业实时分析
Druid	Lambda	流批一体	高并发	Druid SQL	低延迟摄入、高 QPS 查询	架构复杂，运维成本高	实时监控、漏斗分析

宽表数据库（Wide-Column）

• 逻辑上是 “行 + 动态列族” 模型（如 HBase 的 RowKey + ColumnFamily:Qualifier）；

• 物理存储接近 稀疏矩阵，适合海量稀疏数据；

• 通常基于 LSM-Tree，写入性能极高；

• 强调 高可用 + 高写入吞吐，一致性模型可调（CP 或 AP）。

典型使用场景

• 消息历史、聊天记录（按用户 ID 查询所有消息）；

• 时序数据存储（传感器、监控指标）；

• 推荐系统特征宽表（每个用户一行，千级特征列）；

• 大数据平台底层存储（HBase + Hadoop 生态）。

局限和不足

• 查询只能基于 RowKey，二级索引需额外维护；

• 不支持复杂查询或 JOIN；

• 读取整行效率低（若列很多）。

Cassandra

• 特点：

  • AP 系统，无单点故障；
  • 高写入吞吐，最终一致性；
  • CQL 类似 SQL。

• 使用场景：

  • 消息推送、聊天记录；
  • 时序数据（如传感器日志）；
  • 高可用写入场景（如 IoT）。

HBase

• 特点：

  • CP 系统，强一致性；
  • 依赖 HDFS，适合海量存储；
  • 随机读写性能一般。

• 使用场景：

  • 大数据平台底层存储（如 Hadoop 生态）；
  • 历史数据归档、用户画像宽表。

ScyllaDB

• 特点：

  • C++ 重写 Cassandra，低延迟（微秒级）；
  • 兼容 Cassandra 协议；
  • 更高吞吐、更低资源消耗。

• 使用场景：

  • 对延迟敏感的 Cassandra 替代方案；
  • 金融、电信等高性能场景。

全面比较

数据库	一致性	写入性能	查询模型	典型优势	主要局限	适用场景
Cassandra	最终一致（可调）	很高	CQL（仅 RowKey）	无单点、高写入、多 DC	读性能一般，JOIN 不支持	消息历史、IoT 写入
HBase	强一致	高	Scan / Get（RowKey）	Hadoop 生态集成	依赖 ZooKeeper/HDFS，运维重	大数据平台底层存储
ScyllaDB	最终一致	很高	兼容 CQL	低延迟（μs）、高吞吐	社区较小，商业支持为主	高性能 Cassandra 替代

时序数据库（TSDB）

• 专为 时间戳 + 指标值 数据优化；

• 数据按 时间分区 + 列式压缩；

• 支持 降采样、连续查询、窗口函数；

• 写入模型为 追加写（Append-only），极少更新。

典型使用场景

• 服务器/应用监控（CPU、内存、QPS）；

• IoT 设备指标采集（温度、位置、电量）；

• 金融行情数据（股票价格、交易量）；

• APM（应用性能监控）。

局限和不足

• 不适合非时序业务数据；

• 通用性弱，无法替代关系型或文档库；

• 部分 TSDB 不支持复杂标签查询。

InfluxDB

• 特点：

  • 专用时序数据模型（measurement, tag, field）；
  • Flux 查询语言；
  • 云托管（InfluxDB Cloud）。

• 使用场景：

  • DevOps 监控、IoT 设备指标；
  • 自定义指标采集与告警。

Prometheus

• 特点：

  • Pull 模型，服务发现；
  • PromQL 强大；
  • 生态丰富（Alertmanager, Grafana）。

• 使用场景：

  • K8s 监控、微服务指标；
  • 云原生监控标准。

TDengine

• 特点：

  • 国产，高性能（10x InfluxDB）；
  • 一个设备一张表，自动分片；
  • 支持 SQL。

• 使用场景：

  • 工业 IoT、车联网；
  • 高密度时序数据写入（如百万设备）。

TimescaleDB

• 特点：

  • 基于 PostgreSQL，完全兼容 SQL；
  • 支持关系表 + 时序表 JOIN；
  • 支持连续聚合。

• 使用场景：

  • 已有 PostgreSQL 生态的团队；
  • 需要时序 + 业务数据联合分析（如订单 + 监控）。

全面比较

数据库	数据模型	写入性能	查询语言	特色功能	适用场景
InfluxDB	measurement, tag, field	高	Flux / InfluxQL	连续查询、降采样	DevOps 监控、IoT 指标
Prometheus	metric + labels	中高	PromQL	服务发现、Alertmanager	K8s 监控、微服务指标
TDengine	超表（每个设备一张子表）	很高	类 SQL	高压缩、自动分片	工业 IoT、车联网
TimescaleDB	关系表 + 时序超表	高	标准 SQL	与 PG 生态无缝集成	已有 PostgreSQL 的团队，需时序+业务联合分析

图数据库

• 以 节点（Vertex） + 边（Edge） + 属性 为核心模型；

• 使用 原生图存储（邻接表）或 索引优化；

• 查询语言如 Cypher、Gremlin，支持 深度遍历（如“6度人脉”）；

• 遍历性能远超关系型数据库（JOIN 多层效率极低）。

典型使用场景

• 社交网络关系（好友推荐、影响力分析）；

• 欺诈检测（识别异常资金环路）；

• 知识图谱（实体关系推理）；

• 供应链、物流路径优化；

• 反洗钱（AML）、风控网络。

局限和不足

• 不适合简单 CRUD 或聚合分析；

• 大规模图的存储和计算成本高；

• 生态和工具链不如关系型成熟。

Neo4j

• 特点：

  • 原生图存储，Cypher 查询语言；
  • 单机性能强，集群版需企业许可；
  • 可视化工具优秀。

• 使用场景：

  • 社交关系、欺诈检测；
  • 知识图谱、推荐系统（“好友的好友”）。

JanusGraph

• 特点：

  • 开源，依赖 HBase/Cassandra + Elasticsearch；
  • 支持 Gremlin 查询；
  • 可扩展性强。

• 使用场景：

  • 超大规模图（百亿边）；
  • 与 Hadoop 生态集成的大数据图分析。

Dgraph / NebulaGraph

• 特点：

  • 原生分布式，支持 GraphQL± / nGQL；
  • 高性能、水平扩展；
  • 开源 + 云服务。

• 使用场景：

  • 实时图查询（如风控、反洗钱）；
  • 互联网级图应用（如社交网络）。

全面比较

数据库	存储模型	查询语言	分布式	典型优势	适用场景
Neo4j	原生图（单机强）	Cypher	企业版支持	可视化好、生态成熟	社交关系、知识图谱（中小规模）
NebulaGraph	原生分布式图	nGQL	支持	高性能、开源、云原生	互联网级图应用（风控、推荐）
JanusGraph	基于 HBase/Cassandra	Gremlin	支持	与大数据生态集成	超大规模图（百亿边）
Dgraph	原生分布式	GraphQL±	支持	低延迟、易用	实时图查询、SaaS 应用

DB 选型建议

最好的数据库，是团队能驾驭、业务能受益、未来能演进。

选型流程

选型执行流程（6 步法）

1. PoC（概念验证）

   • 模拟真实流量压测（写入/查询/故障恢复）
   • 测试备份恢复流程（如 pg_dump vs mongodump）

2. 监控与可观测性验证

   • 是否支持 Prometheus/Grafana？
   • 能否看到慢查询、连接池、磁盘 IO？

3. 灾难恢复演练

   • 模拟节点宕机，观察自动 failover 时间
   • 验证跨 AZ/Region 容灾能力

技术vs成本

不要只看技术指标，更要评估“全生命周期成本”

维度	说明
学习成本	团队是否熟悉？是否有成熟开发/ORM 支持？（如用 Cassandra 但团队只会 SQL，风险极高）
运维成本	是否需要专职 DBA？监控、备份、扩缩容是否自动化？（如 HBase 运维复杂度远高于 Redis）
人力成本	招聘难度？社区活跃度？（如 Oracle DBA 贵且少，PostgreSQL 人才更易得）
迁移成本	未来能否平滑迁移到其他系统？数据导出是否方便？（避免被云厂商锁定）

在 PoC（概念验证）阶段，让开发和运维共同参与评估，而不仅是架构师拍板。

成本类型	自建	云托管
硬件成本	服务器、存储、网络	按需付费（CPU/内存/存储/IOPS）
人力成本	DBA + 运维 + 开发适配	接近 0（但需云平台技能）
许可成本	开源免费 or 商业授权（Oracle）	按小时/请求计费
隐性成本	故障损失、迁移成本、学习曲线	厂商锁定、调试黑盒

分层存储

根据系统性质决定分层存储 + 多数据库协同

• 主库：强一致、事务 → 关系型/NewSQL

• 缓存：低延迟 → Redis

• 搜索：全文检索 → Elasticsearch

• 分析：聚合查询 → 列式数据库

• 日志/指标：时序写入 → Prometheus/TDengine

优先考虑“生态兼容性”，而非单纯性能

场景	推荐选择
团队已用 Spring Boot + JPA	→ PostgreSQL / MySQL（而非 MongoDB）
已有 Hadoop 大数据平台	→ HBase / Hive（而非 ClickHouse）
全栈 TypeScript + Firebase	→ Firestore（而非自建 CouchDB）
云上 AWS 环境	→ Aurora / DynamoDB（而非自建 TiDB）

明确“数据 SLA”：一致性、延迟、持久性、可用性

使用 CAP / PACELC 模型 明确需求：

• 银行转账 → CP（强一致） → 选 PostgreSQL / TiDB

• 社交点赞 → AP（高可用） → 选 Cassandra / DynamoDB

• 监控告警 → 低延迟 + 高写入 → 选 TDengine / InfluxDB

• 能容忍多少秒的数据延迟？

• 数据丢失是否可接受？（如日志可丢，订单不可丢）

• 系统宕机时，优先保可用还是保一致？

特性比较

根据需求特性和技术特性选择，以符合业务所需。