SQL和NoSQL数据库选择（nosql数据库与sql语言的关系）

系统设计就是要在构建新事物或扩展现有应用时，做出正确的权衡。

理解这些核心权衡，将有助于我们做出更好的架构决策，让我们来探讨一些与数据管理相关的基本系统设计权衡，这是每个工程师都应该理解的。

在数据存储方面，SQL和NoSQL数据库代表着根本不同的方法，具有明显的权衡。

SQL数据库提供强大的数据一致性、结构化模式和强大的查询功能，这种结构确保了数据的完整性，但也给水平扩展和修改模式带来了挑战。

NoSQL数据库颠倒了这些优先级，它们通常牺牲一些一致性和查询能力，以获得水平可扩展性和模式灵活性。

使用SQL时，我们是在用可扩展性换取一致性和结构；而使用NoSQL时，我们是在用一致性保证和查询能力换取可扩展性和灵活性。

这不仅仅是选择哪个更好，而是要理解应用程序的特定需求，我们需要坚如磐石的事务和复杂的查询功能吗？SQL可能是答案。

需要大规模扩展并处理不断发展的数据模型吗？NoSQL可能是更好的选择。

数据库设计通常从规范化开始，即将数据组织到单独的表中，以最大限度地减少冗余，并确保每条信息只存储在一个地方。

这创建了一个干净的模型，可以维护数据的完整性，但是随着应用程序规模的扩大，性能变得至关重要，规范化表之间连接的成本可能会变得过高。

这时，非规范化就派上了用场，它通过在表中刻意复制数据，来消除昂贵的连接并加快常用查询的速度。

这种权衡很明显：规范化优化了数据的完整性和存储效率，而非规范化以增加写入操作的复杂性和潜在的不一致性为代价，优化了读取性能。

大多数大型系统都是从完全规范化的设计演变为有策略的非规范化，仅在查询性能需要时才进行。

这种演变反映了随着应用程序从正确性和简单性走向性能和规模，优先级的转变。

在分布式系统中，CAP定理告诉我们不可能同时拥有所有东西。

一致性是指每次发出请求时，都能获得最新数据的保证；可用性是指即使某些部分出现问题，系统也能始终运行。

当发生网络分区时，我们必须二者择一。

银行系统可能会倾向于选择一致性，以确保账户余额始终准确，而社交媒体平台可能会倾向于选择可用性，以便用户始终可以访问服务。

这种根本的权衡决定了系统在出现故障时的行为方式，并决定了我们可以为用户提供哪些保证。

但一致性本身不是二元的，它是一个范围。

强一致性是指数据更新立即反映在系统中的所有节点上，它需要同步，这会影响性能。

最终一致性是指数据更新在节点间可用之前会延迟，这种方法速度更快、更具可扩展性，但用户可能会暂时看到过时的数据。

这种权衡是在速度和规模与更新的即时性和准确性之间做出的，业务需求决定了系统应该在这个范围内运行的位置。

我们处理数据的方式也存在另一个根本的权衡，即批处理和流处理。

批处理会累积数据并在计划的时间间隔内处理它，这提供了计算效率和更简单的错误处理，但也带来了显著的延迟，用户需要等待数小时才能获得洞察。

流处理会随着数据的到达实时处理数据，从而提供即时结果，并能够对事件做出即时反应。

然而，由于乱序数据到达和可变延迟会影响正确性，因此这引入了复杂性，需要复杂的国家管理和处理保证。

核心权衡是在效率和简单性与即时性和响应能力之间做出的。

许多现代系统最终采用混合架构，使用流处理进行时间敏感型处理，并使用批处理进行全面分析。

理解这些权衡对于设计满足我们特定需求的系统至关重要。

没有普遍正确的选择，只有更符合我们特定用例的权衡。