有选择地分发数据的可能性是什么?
我用一个例子来解释我的问题。考虑一个包含所有数据的中央数据库。该数据库位于某个地理位置。
应用程序 A 需要中央数据库中存在的信息子集。此外,应用程序 A 可能位于与中央数据库所在的地理位置不同(并且可能很远)的地理位置。
因此,我考虑在应用程序 A 的同一位置创建一个新数据库,该数据库将包含中央数据库的信息子集。
哪种技术/产品允许我部署这样的配置?
谢谢
有选择地分发数据的可能性是什么?
我用一个例子来解释我的问题。考虑一个包含所有数据的中央数据库。该数据库位于某个地理位置。
应用程序 A 需要中央数据库中存在的信息子集。此外,应用程序 A 可能位于与中央数据库所在的地理位置不同(并且可能很远)的地理位置。
因此,我考虑在应用程序 A 的同一位置创建一个新数据库,该数据库将包含中央数据库的信息子集。
哪种技术/产品允许我部署这样的配置?
谢谢
寻找数据库复制。SQL Server肯定可以做到这一点,其他人(Oracle、MySQL等)也应该拥有它。
这个想法是另一个位置维护一个(子集)副本。更新是增量交换的。处理冲突的方式取决于您的应用程序。
大多数主流数据库软件,如 MySql 和 SQL server 都可以完成这项工作,但它不是一个好的模型。随着应用程序(流量和用户)的增长,您不仅会在中央数据库服务器(可能正在为其他应用程序提供服务)上创建负载,而且还会滥用网络带宽在远程数据库之间传输数据和应用服务器。
一个更好的模型是让你的数据靠近应用服务器,而使用远距离的数据库仅用于备份和恢复目的。您可以根据应用程序的需要,使用 FC\IP SAN(或任何其他存储网络架构)作为存储网络模型。
您没有解决的一个大问题是应用程序 A 是否需要对数据进行只读访问,或者是否需要进行读写。
阅读需求时想到的直接概念是sharding。在 MySQL 中,这可以通过partitioning来完成。话虽如此,在您跳入分区之前,请确保您阅读了它们的优缺点。在某些情况下,如果您的索引选择不当,或者您的分区方案没有经过深思熟虑,分区可能会减慢速度。
如果您的需求是只读的,那么这应该是一个相当简单的解决方案。您可以在主从上下文中使用 MySQL,并在从属环境中使用 App A。如果您需要读写,那么这将变得更加复杂。
根据您的写入需求,您可以将读取拆分到从站,将写入拆分到主站,但这会显着增加代码结构的复杂性(需要处理与多个数据库的多个连接)。这种布局的优点是您不需要复杂的数据库基础设施。
另一方面,您可以保持代码不变,并在 MySQL 中使用 Master-Master 复制。虽然没有得到甲骨文的官方支持,但很多人已经在这方面取得了成功。快速的 Google 搜索会为您找到大量博客、howtos 等列表。请记住,您的代码必须正确编写以支持这一点(例如:您不能对 PK 使用自动增量字段等)。
如果你有现金可以花钱,那么你可以看看一些更商业化的产品。Oracle DB 和 SQL Server 都支持这一点。
您还可以使用基于块的数据复制,例如DRDB (和 Mysql DRDB)来处理节点之间的复制,但是您总是会遇到的问题是如果两个节点之间的链接发生故障会发生什么情况。
您将遇到的最大问题是如何在 2 个单独的数据库节点中处理冲突更新。如果您的数据与地理相关,那么这对您来说可能不是问题。
长话短说,这不是一个容易(或廉价)解决的问题。
每当您谈论复制数据库时,在设计阶段解决冲突的可能性非常重要。
在此基础上,SAP 的 Sybase Replication Server 将允许您使用 Sybase 数据库或第 3 方数据库来做到这一点。
在 Sybase 的世界中,这通常被称为企业汇总环境。可能有多个地理上独立的数据库,每个数据库都有一个他们主要控制的数据子集。在总部,有一台服务器在一个存储库中包含所有不同的子集。您可以选择复制整个表,或根据单个行/列中的值进行复制。
这使数据库保持松散一致的状态。交易率、地理隔离和网络固有的延迟将影响更新从一个数据库移动到另一个数据库的速度。如果网络连接暂时中断,Sybase Replication Server 会将事务排队,并在链路恢复后立即发送,但复制系统的可靠性和稳定性会受到网络连接稳定性的影响。
同样,正如其他人所说,它并不便宜,但实施和维护相对简单。
免责声明:我曾在 Sybase 工作过,现在仍然是 SAP 公司家族的一员。