您是否意识到遗留架构和传统SQL数据库的根本缺陷?您是否知道SQL 数据库不是为扩展读写而设计的?想知道您的传统SQL数据库是否会为在线分析处理带来问题?不幸的是，答案是肯定的。尽管您的DBA通过劳动密集型干预来扩展数据库以满足现有企业需求，但业务数据的巨大数量和速度使得很难适应动态需求，同时避免停机和延误。这些挑战并不意味着无法扩展SQL数据库。这只意味着这个过程充满了各方面的挑战。让我们来了解原因。

单片机数据库管理系统的缺点

在静态环境中部署软件的相对集中化时代，遗留数据库体系结构无法支持日益移动的世界，随时随地访问应用程序。如今，软件用户希望在可用性方面实现持续改进，并期望SaaS供应商提供实现其业务目标所需的新功能和新功能。

但是，由于以下原因，遗留数据库技术无法满足当今分布式和云环境的需求：

故障转移功能不足

延迟问题

高峰需求期间的准备金不足

始终缺乏高可用性

增加运营成本

无法满足全球市场的需求

由于所有这些原因，传统数据库无法在快速增长的环境中提供结果，在这种环境中，工作负载在地理上分布在异构数据中心。升级到更分散的数据模型既昂贵又复杂。但是你的DBA不能只是坐下来放弃这种情况。以下是三种常用的解决方案，用于解决可伸缩性问题及其业务优势和局限性。

常见变通方法的优缺点

拆分

垂直缩放

水平缩放

有两种不同类型的分片 - 水平和垂直。虽然水平分片需要沿多个实例划分数据，但垂直分片会将所有表移动到其他实例，以最大限度地缩短查询的响应时间。分片有助于跨多个服务器存储数据，但水平和垂直分片都很复杂且耗时。除了冗余数据之外，这两个流程都需要在应用级别进行更改，以避免交叉查询。

通过分片，您可以存储大量数据，跨地点共享数据，在任何设备上轻松访问信息，消除重复并减少存储空间，但并非没有限制。不幸的是，分片容易出错，需要手动故障转移，并且在容量分区方面受到限制。联接是非常不可靠和低效的，并且采取一致的备份可能变得非常困难。分片数据库无法在服务中断后继续存在，并且不支持外键。缺乏参照完整性会导致数据不一致，最终可能成为公司的重大开发成本。

实际上，很少有组织真正需要分片。像实体的Facebook，与PB的每天新增的数据，是罕见的。对于大多数公司而言，通过扩展读取容量来卸载主写入服务器将解决整体可扩展性挑战。

扩大规模的手段移动到有更多更大更好的服务器内存，带宽和I / O。当现有解决方案开始减速时，按比例放大可以轻松处理重负载。那解决方案有什么问题呢?

随着更昂贵的硬件成本上升。数据库许可变得更加昂贵，维护成本也会增加。无论你走多远，最终你所有的服务器肯定会失去动力。在某些时候，不再可能进行额外的扩展。

向外扩展意味着通过添加更多可以协同工作以提供流量的单个服务器来增加容量。这种向外扩展还可以增加正常运行时间，因为任何单个服务器故障都不会影响整个系统的可用性。挑战在于您的软件不知道如何与多个数据库服务器通信。为了有效且经济高效地实现数据库扩展，您需要数据库负载平衡软件，以避免与复制的辅助节点进行通信所需的应用程序返工。

数据库负载平衡如何有效地解决可伸缩性缺陷

数据库负载平衡软件可以有效地扩展数据库的读取，卸载主服务器，从而缩放写入，从而保护您的基础架构免受停机和延迟的影响。该软件使您的应用程序可以利用扩展的数据库，而无需更改代码。它通过以下方式确保高可用性和高性能：

自动向主服务器发送写入并读取辅助服务器

通过在队列中保留写入，直到辅助节点成为新的主节点，避免数据库故障转移期间的应用程序错误

跟踪复制时间以确保不会将读取发送到复制中滞后的辅助服务器

在所有可用的辅助服务器之间分配读取，并将工作负载指向性能最佳的服务器

提供对应用程序性能瓶颈的根本原因的端到端可视性

毫无疑问，数据库负载平衡是确保正常运行时间和高性能的最简单方法，同时降低服务成本并改善客户体验。