我们有一个非常大规模的企业级数据库。作为我们业务模型的一部分，所有 Web 用户每个月都会在同一时间访问我们的 Web 服务器，这反过来又会影响我们的 sql 框。流量非常大，并且随着公司规模的扩大，流量会继续增长。sql proc优化已经完成，硬件已经扩展到一个非常高的水平。
我们现在正在寻求对数据库进行分片，以确保我们能够处理公司的增长和未来的负载。
我们已经决定应该对哪些特定数据进行分片。它是我们数据库的一个子集，使用率很高。
但是，我的问题是关于常见/通用的非分片数据。像这样的数据示例可能是库存表，也可能是员工表、用户表等。
我看到两个选项来处理这个通用/通用数据：
1) 设计 1 - 将通用/通用数据放在外部数据库中。所有写入都将发生在这里。然后，此数据将被复制到每个分片，允许每个分片读取此数据并在 t-sql procs 中对这些数据进行内部连接。
2) 设计 2 - 为每个分片提供所有通用/通用数据的副本。让每个分片本地写入这些表，并利用 sql 合并复制在所有其他分片上更新/同步此数据。
对设计的担忧 #1
1) 事务性问题：例如，如果您必须在分片中写入或更新数据，然后在 1 个存储过程中写入/更新公共/通用表，您将无法再轻松地做到这一点。数据现在存在于单独的 sql 实例和数据库中。您可能需要使用 MS DTS 来查看是否可以将这些写入包装到事务中，因为它们位于单独的数据库中。性能是这里的一个问题，并且可能涉及写入分片和公共数据的过程的重写。
2) 参照完整性的丧失。无法实现跨数据库参照完整性。
3) 重新编码系统的大面积区域，使其知道将公共数据写入新的通用数据库但从分片读取公共数据。
4）。增加了数据库行程。像上面的#1 一样，当您遇到必须更新分片数据和公共数据的情况时，您将进行多次往返来完成此操作，因为数据现在位于不同的数据库中。这里有一些网络延迟，但我并不像上述 3 那样担心这个问题。
对设计的担忧 #2
在设计#2 中，每个分片都有自己的所有公共/通用数据的实例。这意味着连接到或更新公共数据的所有代码继续像今天一样工作/运行。开发团队几乎不需要重新编码/重写。然而，这种设计完全依赖于合并复制来保持所有分片之间的数据同步。数据库管理员技术精湛，非常担心合并复制可能无法处理这个问题，如果合并复制失败，从这个失败中恢复不是很好，可能会对我们产生非常负面的影响。
我很想知道是否有人选择了设计选项 #2。我也很想知道我是否忽略了我没有看到的第三个或第四个设计选项。
先感谢您。
sql-server ×1