在 PlanetScale，我们与处于数据库旅程各个阶段的开发者交流。当今市场上数据库产品的多样性使得为你的需求选择合适的产品变得极其困难。这篇博文的目的不是将复杂的数据库格局简化为一个简单的观点，而是为开发者提供一个框架，供他们在开始考虑构建生产应用程序时参考。
在本文中，我们将探讨如何为你的工作负载识别数据处理方法，以便你在为现代应用程序选择数据库时优化性能、可扩展性和安全性。
数据库格局简要概述：OLAP 与 OLTP
OLTP（在线事务处理）和 OLAP（在线分析处理）是两种不同类型的数据处理系统，在传统架构中经常一起使用。
OLTP 用于处理大量小型事务性数据。它通常用于电子商务、银行和社交媒体等应用程序。
OLAP 数据库旨在处理需要分析大量数据的复杂查询。它们通常用于商业智能和数据挖掘等应用程序。
OLTP 和 OLAP 系统的结合为企业提供了管理和分析数据的强大工具。OLTP 系统处理日常事务，而 OLAP 系统提供对数据的洞察，可用于做出更好的业务决策。
近年来，HTAP（混合事务与分析处理）数据库兴起，以针对同时需要分析和事务的新应用程序。要理解 HTAP，我们需要了解 OLTP 和 OLAP 系统的历史。
关系数据库一直被用于事务处理和分析，但 OLTP 和 OLAP 系统具有不同的特征。OLTP 系统专为单条记录插入/删除/更新语句和受益于索引的点查询而设计。OLAP 系统专为批量更新和表扫描而设计。向 OLAP 系统的批量插入通常通过 ETL（提取、转换、加载）系统完成，这些系统将来自 OLTP 系统的事务数据整合并转换到 OLAP 环境中进行分析。
HTAP：优势与分类
通过大量的营销努力，HTAP 被定位为一种有前景的新计算范式，将解决因管理两种独立工作负载而产生的性能、成本和复杂性挑战。HTAP 系统大致可分为三类：
| 全共享架构 | 无共享架构 | 混合架构 | | --- | --- | --- | | 所有数据存储在单一共享存储系统中 | 集群中的每个节点存储自己的数据 | 结合了两种架构的元素，通常将事务数据存储在全共享系统中，将分析数据存储在无共享系统中 | | 实现和确保数据一致性最简单；可扩展性可能受限 | 更具可扩展性，可水平扩展；实现和管理可能更困难 | 确保数据一致性可能困难，尤其是在存在并发事务和分析操作时；可扩展性可能受限 |
构建这些 HTAP 系统有许多不同的方法：
内存 HTAP 数据库：在这种架构中，集群中的每个节点将数据存储在内存中。这使得系统可以水平扩展，但也可能使确保数据一致性变得更加困难。同时由于需要大量内存，成本也会更高。
列式 HTAP 数据库：这些系统以列式格式存储数据，针对分析查询进行了优化。列式系统可以为分析查询提供良好的性能，但对于事务查询可能较慢。
存储与计算分离数据库：将数据的存储与数据的处理分离。
混合 HTAP 系统：将事务数据存储在磁盘上，将分析数据存储在内存中。
HTAP 面临的挑战
HTAP 系统存在固有挑战，这些挑战可能阻碍其为现代应用在大规模下优化高效数据处理的能力。尽管每个用例各不相同，但有一些因素需要考虑，在这些方面 HTAP 系统可能变得不可行。
混合工作负载复杂性：HTAP 数据库旨在在单一系统中同时满足事务和分析任务。然而，这导致了一个复杂的环境，数据库必须兼顾高速事务处理和资源密集型分析查询的需求。这种需求上的固有冲突可能导致性能妥协。
性能权衡：在 HTAP 设置中，针对一种工作负载进行优化往往以另一种为代价。例如，在追求快速事务处理时，分析查询可能因共享资源而变慢。反之，如果分配资源以增强分析性能，事务操作可能受到影响，导致延迟增加和吞吐量降低。
数据模型不匹配：OLTP 和 OLAP 工作负载通常涉及不同的数据模型。OLTP 事务侧重于更新单个记录并维护数据完整性和一致性，而 OLAP 操作涉及复杂的聚合和扫描。试图将两种类型的工作负载适配到同一数据模型中，可能导致次优的设计妥协，从而阻碍任一工作负载的高效处理。
可扩展性挑战：大规模现代应用通常需要水平扩展以适应不断增长的数据量和用户负载。HTAP 数据库可能难以保持与专门为某一类型工作负载量身定制的专用解决方案相同水平的性能和可扩展性。随着系统增长，平衡事务和分析组件的扩展需求变得越来越复杂。
资源争用：在 HTAP 系统中，当事务和分析工作负载争夺相同的资源（如 CPU、内存和 I/O 带宽）时，就会产生争用。这种争用可能导致资源瓶颈、不可预测的性能波动以及整体系统不稳定。
维护和管理复杂性：与独立的 OLTP 或 OLAP 系统相比，HTAP 数据库需要更复杂的管理和维护。数据库管理员必须管理系统配置、调优和优化，以确保事务和分析工作负载都能充分运行。这种复杂性可能导致运营开销增加和潜在的人为错误。
分析处理的局限性：虽然 HTAP 数据库可以近实时地从运营数据中提供洞察，但其分析能力可能无法与专为复杂分析查询和报告设计的专用数据仓库解决方案相匹配。专用分析数据库可以为复杂分析操作采用更复杂的优化技术，提供更优越的性能和更丰富的洞察。
数据处理架构的演进：现代应用通常包含分布式计算、微服务和无服务器架构。这些架构旨在优化特定类型的工作负载，可能使混合数据库难以融入更大的应用生态系统并充分利用新兴技术趋势。
PlanetScale 的方法
PlanetScale 并不声称自己是 HTAP 数据库，也不是为纯分析工作负载构建的 OLAP 数据库。相反，PlanetScale 提供唯一的托管 Vitess 解决方案，我们针对 OLTP 工作负载进行了优化。
作为曾在世界上一些最大的企业中从事生产数据库工作的开发者，我们理解每个应用都是不同的，寻找一个提供一刀切方法的单一数据库往往意味着做出妥协。
如果您的复杂应用具有可以分离的、不同的事务和分析工作负载，那么为每种工作负载使用单独的数据库可能更为合适。这种方法允许每个数据库针对其特定工作负载进行优化，并提供更好的性能和可扩展性。
物理资源隔离是保证事务查询性能的有效方法。分析查询通常会消耗大量资源，如 CPU、内存和 I/O 带宽。如果这些查询与事务查询一起运行，后者可能会被严重延迟。
对于大型 ETL 工作负载，我们支持并推荐 Airbyte、Fivetran 和 Stitch 等数据集成引擎，借助这些引擎，你可以将这些流程卸载到更专注于 OLAP 工作负载的其他平台。
注册以自行试用，或者如果你希望了解 PlanetScale 如何融入你的数据管道，请联系我们进行交流。
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文来源：PlanetScale Blog
原文作者：PlanetScale Blog；如有侵权，请联系管理员删除。
