选择适合自己数据的存储系统是数据工程中的一项基本工作。正如我们之前谈到的，数据有多种形式和大小，您计划如何使用它会显著影响其存储位置和方式。没有哪种存储方案是唯一的“最佳”选择；相反，目标是选择最符合您的应用或分析具体需求的方案。尽早做出正确的选择，可以节省大量后续工作和成本，影响范围从查询速度到开发复杂性。
让我们分解一下评估数据存储选项时应考虑的主要因素。
数据存储选择因素
可以将这些因素看作是指导您决策过程的核对清单。这些因素之间常有取舍，因此了解您的优先事项很重要。
-
数据结构： 您的数据看起来是怎样的？
- 结构化数据： 高度组织化，能够整齐地放入具有预定义列和数据类型的表格中（如电子表格或典型数据库表）。例子包括用户信息（ID、姓名、电子邮件、注册日期）或销售记录（订单ID、产品ID、数量、价格）。关系型数据库是此类的传统选择。数据仓库也能处理结构化数据，并针对分析进行了优化。
- 半结构化数据： 具有一定组织结构但不能完全符合严格表格格式的数据。可以将其想象成JSON或XML文件，其字段可以嵌套或缺失。例子包括具有不同属性的产品目录或事件日志。NoSQL数据库（特别是文档数据库）和对象存储通常能很好地处理此类数据。
- 非结构化数据： 没有预定义格式的数据。这包括文本文档、图像、音频文件、视频流和原始传感器读数。数据湖通常基于对象存储或分布式文件系统构建，旨在容纳海量的非结构化数据。
-
数据量与可伸缩性： 您现在有多少数据，将来预计会有多少？
- 数据量： 您处理的是千兆字节、万亿字节还是拍字节？有些系统比其他系统能更自然地处理大规模数据。
- 可伸缩性： 当数据量或使用量增加时，存储系统能多容易地扩展？垂直伸缩指增加单个服务器的计算能力（CPU、内存），这有其局限性。水平伸缩指增加更多服务器来分散负载，这在NoSQL数据库、对象存储和分布式文件系统中很常见，能提供更大的伸缩能力。
-
查询模式与性能： 您将如何访问和使用数据？
- 读写频率： 是读多写少（如产品目录），还是频繁读写（如用户会话跟踪）？有些系统针对读密集型工作负载进行了优化，另一些则针对写密集型工作负载。
- 查询复杂性： 您是否需要执行涉及多表和聚合的复杂查询（在分析中常见）？关系型数据库和数据仓库使用SQL在这方面表现优异。或者访问是否更简单，通常通过特定键检索数据（如按用户ID获取用户资料）？键值存储对此非常高效。
- 延迟要求： 您需要多快的响应速度？交互式应用程序通常要求低延迟（毫秒级），而批处理报告可能容忍更高的延迟（秒或分钟级）。内存数据库提供最低延迟，而从对象存储访问数据可能会较慢。
-
一致性需求： 每次读取操作都必须返回最新写入的数据，这有多么重要？
- 强一致性： 这确保了一旦写入成功，所有后续读取都会看到更新后的数据。这是传统关系型数据库的典型特点，对于金融交易之类的场景来说是不可或缺的 — 您总是希望看到正确的账户余额。
- 最终一致性： 这确保了如果没有新的更新发生，所有读取最终都会返回最后更新的值。然而，可能会有短暂的延迟，导致不同用户看到略微不同的数据版本。这种模型常用于高可伸缩的分布式系统（如某些NoSQL数据库）中，因为在所有节点上强制即时一致性会显著影响性能和可用性。想想社交媒体点赞 — 计数可能需要一点时间才能在各处更新。
-
成本： 存储和运营的预算是多少？
- 存储成本： 不同系统的每千兆字节成本不同。云服务提供商提供多种层级（例如，更快、更昂贵的“热”存储与更慢、更便宜的“冷”存储用于归档）。
- 计算成本： 查询数据需要多少处理能力？在大型数据集上执行复杂查询会产生可观的计算成本。
- 运营开销： 考虑设置、维护、备份和管理所需的工作量。托管云服务通常会降低这部分开销，但可能比自托管成本更高。
-
数据格式与集成： 存储系统能否轻松处理您所需的数据格式（如CSV、JSON、Parquet、Avro）？它与数据生态系统中的其他工具，例如数据处理框架（如Apache Spark）或商业智能工具，集成得如何？
存储与常见场景匹配
以下是这些因素如何映射到本章将讨论的存储类型的一个简化视图：
- 关系型数据库（例如 PostgreSQL、MySQL）： 适用于结构化数据、复杂SQL查询以及需要强一致性时（如事务处理系统）。在数据量非常大的情况下，伸缩可能会变得复杂或昂贵。
- NoSQL数据库（例如 MongoDB、Cassandra、Redis）： 能很好地处理半结构化或非结构化数据。通常为高可伸缩性（水平伸缩）和高吞吐量 (throughput)（读/写）而设计。一致性模型各不相同（有些提供强一致性，许多提供最终一致性）。存在不同类型：文档型、键值型、宽列型、图型，每种都适合不同的访问模式。
- 数据仓库（例如 Snowflake、BigQuery、Redshift）： 经过优化，用于使用SQL分析大量结构化（并日益包含半结构化）数据。专为复杂分析查询（OLAP）而非频繁事务（OLTP）而设计。
- 数据湖（通常使用S3/GCS/Azure Blob等对象存储或HDFS等文件系统）： 非常适合以经济高效的方式存储海量的各种格式（结构化、半结构化、非结构化）的原始数据。数据通常在之后处理以用于特定用途。提供高持久性和可伸缩性。
- 分布式文件系统（例如 HDFS）： 旨在将非常大的文件存储在多台机器上，为Spark或MapReduce等批处理框架提供高吞吐量。常作为本地数据湖的底层。
简易决策路径
选择存储并非总是简单明了，有时需要结合多种系统。然而，一个简单的决策过程可能如下所示：
一个基于数据结构和主要用途选择数据存储的简化指南。
"请记住，这是一个简化观点。决策需要权衡所有讨论过的因素。您可能从一个系统开始，随着需求的演变而迁移或增加其他系统。重要的是了解您数据的特点以及打算如何使用它，然后将这些需求与现有存储选项的优势结合起来。以下章节将提供每个主要存储类别的更多详细信息。"
