10 种必须知道的数据库类型
选择正确的数据库是你在系统设计面试中做出的最关键的决策之一。
你选择的数据库通常决定了你的系统在负载下的表现、扩展的容易程度以及在现实场景中优雅处理复杂性的能力。
这就是为什么对不同类型数据库及其何时使用每种类型的深刻理解是通过系统设计面试的关键部分。
在本文中,我们将介绍系统设计面试中必须知道的 10 种数据库类型。对于每一种,我们将解释:
- 它是什么
- 何时使用它(带示例)
- 关键设计考虑
- 你可以在面试中提到的流行数据库
1. 关系数据库(Relational Database)
关系数据库将数据存储在具有行和列的结构化表中。它就像 Excel 电子表格,但功能更强大。
每个表代表一个实体(如 Users、Orders 或 Products),表之间的关系使用外键定义。它使用**SQL(结构化查询语言)**来查询和操作数据。
关系数据库非常适合当你的数据由具有强关系的明确定义的实体组成时。
示例 - 在电子商务平台中:
Users下订单OrderOrder可以包含多个ProductsProducts有关联的Reviews并属于某个Category
具有外键的关系模式使得建模和强制这些关系变得容易,SQL 允许通过连接进行有效查询。
关系数据库提供完整的 ACID 合规性,确保可靠的事务。
示例 - 在数字支付系统中,在账户之间转账需要原子更新。如果一个步骤失败,整个事务回滚,保持数据完整性。
这种数据完整性和事务安全性是关系数据库擅长的。
关系数据库提供SQL,一种强大且富有表现力的查询语言。SQL 支持过滤、聚合、分组和多表连接。
索引通过允许数据库快速定位行来加速读取密集型查询。
在频繁查询的列上创建索引(例如,user_id、email)。对多列过滤器使用复合索引。在写入密集型系统中避免过度索引,因为它会减慢插入和更新。
规范化以减少冗余并确保一致性。在读取密集型系统中反规范化以减少连接开销。
连接对于分析和报告很强大。然而,避免在大表上过度连接,因为它们可能成为性能瓶颈。除非绝对必要,否则永远不要设计跨分片连接。
分片实现水平扩展但引入复杂性。
选择高基数分片键(例如,user_id)以均匀分布负载。注意跨分片查询和事务难以实现。
- 垂直扩展(向单机添加更多 CPU/RAM):简单但有限。
- 水平扩展:添加读取副本、分区大表,并对频繁访问的数据使用缓存(例如,Redis)
流行数据库:
- PostgreSQL – 开源、功能丰富、ACID 合规
- MySQL – 广泛使用,特别是在 LAMP 栈应用程序中
- Oracle DB – 企业级 RDBMS
2. 内存数据库(In-Memory Database)
内存数据库直接将数据存储在 RAM 中而不是磁盘上。这使得它对于读取和写入操作非常快。
内存数据库非常适合需要近乎即时响应的应用程序。
示例:游戏应用程序中的实时排行榜,分数立即更新和排名。
内存数据库非常适合存储可以重新计算的数据(如果丢失)。
示例:缓存趋势搜索结果以减少重复计算并加快查询速度。
内存存储可以作为高速缓存层来减轻主数据库的频繁读取。
示例:在社交媒体平台中缓存用户配置文件数据以避免在主数据库中重复查找。
由于 RAM 是易失性的,除非启用持久性,否则数据会在崩溃或重新启动时丢失。
像Redis这样的工具提供可选的持久性:
- RDB(快照):定期保存数据
- AOF(仅追加文件):记录每个写入操作
RAM 很快,但有限。当内存用完时,较旧或较少使用的数据被驱逐。常见的**驱逐策略包括LRU**、LFU和TTL。
避免存储大文件或不经常访问的数据。仅存储热门和频繁访问的数据,如用户会话和最近活动。
复制可以提高读取性能并在主实例宕机时提供故障转移支持。Redis 支持副本节点和使用 Sentinel 或 Cluster 模式的自动故障转移。
然而,复制通常是异步的,所以如果主服务器在同步之前失败,存在数据丢失的风险。始终在关系数据库等持久系统中存储关键数据。
流行数据库:
- Redis – 闪电般快速,支持列表、集合、排序集合和发布 - 订阅等数据结构
- Memcached – 简单的键值存储,用于缓存
- Apache Ignite – 具有 SQL 支持的分布式内存存储
- Hazelcast – 通常用于基于 Java 的企业应用程序
3. 键值数据库(Key-Value Database)
键值数据库是最简单的数据库类型。它将数据存储为键值对的集合,其中每个键是唯一的并直接映射到一个值。把它想象成一个巨大的、分布式的
HashMap。
没有表、模式或关系——只有键和值。这使得键值存储非常快且高度可扩展。
键值存储提供**恒定时间(O(1))**读取和写入,非常适合使用唯一标识符快速访问。
示例:
- 在 Web 应用程序中将用户会话存储为
userId → sessionInfo。 - 在 URL 缩短服务中存储
shortURL → fullURL映射。
如果你的数据不需要连接、过滤或关系约束,键值存储是一个简单且可扩展的选择。
键值存储设计用于巨大吞吐量,通常用于需要每秒数百万次读取/写入且延迟最小的系统。
你只能按键检索值。它们通常不提供过滤、排序或连接。辅助索引通常不支持。
键值数据库是无模式的。值可以是字符串、JSON 或二进制 blob。
这给了你灵活性,但也把处理数据模型的序列化/反序列化和版本控制的负担放在你的应用程序上。
基于键的分区使用一致性哈希或基于范围的分区实现跨节点的无缝分布。
为了均匀分布键,选择高基数键(如果大多数用户来自一个地区,避免使用 country_code)
流行数据库:
- Redis – 也充当具有丰富数据类型的键值存储
- Amazon DynamoDB – 托管的、水平可扩展的键值存储
- Riak KV – 分布式、容错的键值系统
- Aerospike – 大规模低延迟读取/写入的高性能
本文为学习目的的个人翻译,译文仅供参考。
原文链接:10 Must-Know Database Types for System Design Interviews。
版权归原作者或原刊登方所有。本文为非官方译本;如有不妥,请联系删除。