每个现代应用，从叫车服务到电商平台，都依赖数据，在数据背后是数据库。无论是存储客户资料、跟踪库存还是记录用户操作，数据库不仅仅是存储引擎。它是将应用状态凝聚在一起的核心系统。当数据库失败时，其他一切（API、前端、业务逻辑）都会崩溃。

因此，选择正确类型的数据库至关重要，但这不是一刀切的决定。

关系数据库，如 MySQL 和 PostgreSQL，几十年来一直是默认选择。它们提供强一致性、 хорошо 理解的查询语言和久经考验的可靠性。然而，随着系统扩展和用例多样化，传统 SQL 开始出现问题。

这就是 NoSQL 登场的地方，提供灵活的模式设计、水平可扩展性和针对特定访问模式定制的模型。承诺是快速扩展和自由迭代。然而，在一致性、结构和操作方面有权衡。

然后还有第三个新兴类别：NewSQL 系统，如 Google Spanner 和 CockroachDB。这些试图通过保留 SQL 语义和 ACID 保证，同时像 NoSQL 一样跨区域和节点扩展来弥合差距。还有专用数据库在特定方向推动性能。像 Redis 这样的内存存储模糊了缓存和持久化之间的界限。像 Elasticsearch 这样的搜索引擎提供关系数据库从未构建过的闪电般快速文本搜索和分析功能。

错误的数据库选择可能扼杀性能、减慢开发或在规模下崩溃。正确的选择可以解锁速度、敏捷性和可靠性。

在本文中，我们分解核心数据库范式，如 SQL 和 NoSQL，以及专用数据库类型和开发者如何为他们的需求选择适当的数据库。

SQL vs. NoSQL vs. NewSQL

关系数据库（SQL）

  • 优势：强一致性、ACID 事务、成熟生态
  • 劣势：水平扩展困难、模式固定
  • 适用：金融系统、需要事务的场景

NoSQL

  • 优势：灵活模式、水平扩展、高性能
  • 劣势：弱一致性、查询能力有限
  • 适用：大规模数据、快速迭代

NewSQL

  • 优势：SQL 语义 + NoSQL 扩展
  • 劣势：相对年轻、生态较小
  • 适用：需要 ACID + 大规模扩展

专用数据库

  • 内存存储（Redis）：缓存、实时数据
  • 搜索引擎（Elasticsearch）：全文搜索、分析
  • 图数据库：关系密集型数据

选择指南

选择 SQL 当：

  • 需要强一致性
  • 复杂查询需求
  • 事务至关重要
  • 数据结构稳定

选择 NoSQL 当：

  • 需要水平扩展
  • 快速迭代
  • 灵活模式
  • 简单查询模式

考虑 NewSQL 当：

  • 需要 ACID 保证
  • 需要大规模扩展
  • 想要 SQL 查询能力

本文为学习目的的个人翻译，译文仅供参考。

原文链接：SQL vs NoSQL: Choosing the Right Database for An Application。

版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。