sql-server - 使用分区或单独的数据库进行表扩展？

Question

假设我有一个表(我们称之为 BigTable)，每天可能会经历5,000,000 次插入(可能还有同样多的 SELECT)。每插入行约 50kb。

这些每日插入平均分配给 5 个客户端(该表有一个名为 ClientID 的 FK)。永远不需要跨多个客户端选择或连接数据。

我担心随着该表的增长，数据库性能会受到影响，因此我想出了两种解决方案。

解决方案 1:

• 按 ClientID 对 BigTable 进行分区
• 将每个分区存储在服务器上的单独硬盘上(使用 Azure 博客存储)。
• 将 1 个月前的所有数据(归档数据，但仍需要可查询)分区到另一组 READONLY 分区中。

本质上，这意味着它们自己的存储设备上的以下分区:

• 主要(除 BigTable 之外的所有数据)
• ClientA 的 BigTable(每天 5,000,000 行/5 个客户端 x 30 天 = 30,000,000 行)
• ClientB 的 BigTable(30,000,000 行)
• ClientC 的 BigTable(30,000,000 行)
• ClientD 的 BigTable(30,000,000 行)
• ClientE 的 BigTable(30,000,000 行)
• ClientA 的 BigTable 存档
• ClientB 的 BigTable 存档
• ClientC 的 BigTable 存档
• ClientD 的 BigTable 存档
• ClientE 的 BigTable 存档

存档表中的行数将为 (5,000,000) x(数据库生命周期，以天为单位)- (30,000,000)。这仍然是一个巨大的表，但只会用于起草奇怪的报告。

SQL Server 将托管在 14GB、8 核 Azure VM 上。

解决方案 2:

另一个选项是为每个客户端托管单独的数据库。这意味着每个服务器都将拥有自己专用的 SQL Server 计算机。归档数据仍然会发生分区。

由于数据的物理分离，此选项不是最佳选择。必须管理多个数据库的更新可能会带来很大的问题。为每个客户端提供单独的数据库连接也是开发人员的一个考虑因素。

有人可以就这些选项提出建议吗？

Answer 1

由于您已使用 [azure] 和 [sql-server] 标记此操作，因此我假设您正在尝试在 Windows Azure 中执行此操作。如果是这种情况，那么 a) 按客户端分区不一定是个好主意，并且 b) SQL 可能不是最(完整)适合您的问题的。

在构建可扩展架构时，分区策略不应基于“客户端”等特定内容，而应基于更任意的内容。原因很简单 - 除非客户端有理由分开，例如不希望其数据与其他数据混合，或者每个客户端有不同的 SLA，否则选择“客户端”作为分区可能不会呈现最佳结果。如果您 80% 的业务是由单个客户产生的，那么您还没有解决问题，并且仍然需要维护n 个单独的数据库来承受边际负载。

每天 500 万次数据库插入并不是一个大数字，但对于 Azure IaaS 或 Azure SQL 数据库中托管的 SQL Server 来说可能是一个大数字 - 由于底层商用硬件的性能。在确定如何对 SQL 进行分区之前，先问自己两个问题。首先，您希望从数据中获得哪些用途和性能特征？ (它必须立即一致吗？您可以异步处理数据吗？)其次，您是否将这些特征与其他数据存储技术进行了映射？您是否考虑过表存储(或 Redis 等非 MS 解决方案)？

在尝试了几个选项后，您可能会发现:

• 在某些时候，SQL 可以很好地存储某些数据。
• 大部分处理可以异步完成，因此插入的峰值性能并不重要(并且在 24 小时内执行 500 万次插入也不是问题)。
• SQL 可能不适合长期存储。
• 可以使用 Map-Reduce(而不是 SQL 查询)有效地查询旧数据。

例如，我有一个以一秒为间隔跟踪车辆的应用程序。它的目标是 100,000 辆汽车，但其架构设计方式是能够在不更改任何代码或数据库的情况下扩展到数百万辆汽车。但从中期来看，它每天必须处理 7200 万次插入。所有这些都运行在一个小于 10GB 的 Windows Azure SQL 数据库和一大堆表存储上。这样做的原因是，虽然我想归档所有数据(7200 万行)，但我不需要对其进行复杂的 SQL 查询访问，因此它可以轻松地存放在表存储中。我在 SQL 中存储的是数据的摘要。因此，在我的示例中，我只对车辆的行程(起点和终点位置、行驶距离等)感兴趣，这意味着我每天在 SQL 中只需要每辆车两到三行 — 大大减少了负载数据库。另外，我的瓶颈在于数据收集，因此我立即将数据添加到 (Windows Azure) 队列 - 并担心在单独的工作负载中汇总数据。

这个答案可能有点长，但目的是让你更仔细地思考你的数据模型，而不是仅仅试图思考如何用 SQL 解决问题。有关更多详细信息，请查看 CALM 中的数据模型。 .