您是否了解遗留架构和传统 SQL 数据库的根本缺陷？ 您是否知道 SQL 数据库不是为扩展读写而设计的？ 想知道您的传统 SQL 数据库是否会给在线分析处理带来问题？ 不幸的是，答案是肯定的。 尽管 DBA 进行了劳动密集型干预以扩展数据库以超出现有企业需求，但业务数据的巨大数量和速度使其很难适应动态需求，同时避免停机和延迟。 这些挑战并不意味着扩展 SQL 数据库是不可能的。 这只是意味着这个过程在各个方面都充满了挑战。 让我们了解原因。 （有关 SQL 的更多信息，请参阅 Hadoop 上的 SQL 如何帮助进行大数据分析？）
单一数据库管理系统的缺点
在软件部署在静态环境中的相对集中的时代，遗留数据库架构无法支持随时随地访问应用程序的日益移动的世界。 如今，软件用户希望持续改进可用性，并期望 SaaS 供应商提供实现其业务目标所需的新特性和功能。
然而，由于以下原因，遗留数据库技术无法满足当今分布式和云环境的需求：
故障转移能力不足
延迟问题
需求高峰期间供应不足
始终缺乏高可用性
运营成本增加
无法满足全球市场的需求
由于所有这些原因，传统数据库无法在工作负载在地理上分布在异构数据中心的快速增长的环境中提供结果。 升级到更分布式的数据模型既昂贵又复杂。 但是您的 DBA 不能就此坐视不理。 以下是解决可扩展性问题的三种常用变通方法及其业务优势和局限性。
常见解决方法的优缺点
分片
垂直缩放
水平缩放
有两种不同类型的分片——水平分片和垂直分片。 水平分片需要沿多个实例划分数据，而垂直分片会将所有表移动到其他实例，以最大限度地减少查询的响应时间。 分片有助于跨多个服务器存储数据，但水平和垂直分片都很复杂且耗时。 除了冗余数据之外，这两个过程都需要在应用程序级别进行更改，以避免交叉查询。
分片使您能够存储大量数据、跨位置共享数据、在任何设备上轻松访问信息、消除重复并减少存储空间，但它并非没有限制。 不幸的是，分片容易出错，需要手动故障转移，并且在容量分区方面受到限制。 联接非常不可靠且效率低下，并且进行一致的备份会变得非常困难。 分片数据库无法在服务中断后继续存在，并且不支持外键。 缺乏参照完整性会导致数据不一致，最终可能成为公司的重大开发成本。
实际上，很少有组织真正需要分片。 像 Facebook 这样每天添加 PB 级数据的实体很少见。 对于大多数公司而言，通过扩展读取容量来卸载主写入服务器将解决整体可扩展性挑战。
向上扩展意味着迁移到更大更好的服务器，它具有更多的内存、带宽和 I/O。 当现有解决方案开始变慢时，扩大规模可以轻松处理重负载。 那么解决方案有什么问题呢？
成本随着更昂贵的硬件而增加。 数据库许可变得更加昂贵，维护成本也随之增加。 无论您的规模有多大，最终您所有的服务器都肯定会耗尽。 在某些时候，不再可能进行额外的扩展。
横向扩展意味着通过添加更多协同工作以服务流量的单独服务器来增加容量。 这种横向扩展还可以增加正常运行时间，因为任何单个服务器故障都不会影响整个系统的可用性。 挑战在于您的软件不知道如何与多个数据库服务器通信。 为了高效且经济地实现数据库横向扩展，您需要数据库负载平衡软件来避免与复制的辅助数据库通信所需的应用程序返工。 （要了解有关数据库趋势的更多信息，请参阅软件定义的数据中心：什么是真实的，什么不是。）
数据库负载平衡如何有效解决可扩展性缺陷
数据库负载平衡软件通过有效地扩展数据库的读取、卸载主服务器并因此扩展写入来保护您的基础架构免受停机和延迟的影响。 该软件使您的应用程序无需更改代码即可利用横向扩展的数据库。 它通过以下方式确保高可用性和高性能：
自动将写入发送到主服务器并读取到辅助服务器
通过将写入保存在队列中直到辅助节点成为新的主要节点，避免数据库故障转移期间的应用程序错误
跟踪复制时间以确保读取不会发送到复制落后的辅助服务器
在所有可用的辅助服务器之间分配读取，并将工作负载定向到性能最佳的服务器
提供对应用程序性能瓶颈根本原因的端到端可见性
毫无疑问，数据库负载平衡是确保正常运行时间和高性能同时降低服务成本和改善客户体验的最简单方法。
