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

Question

假设我有一张表(让我们称之为BigTable),每天可以体验5,000,000个INSERTS(可能只有SELECT).插入的每行约为50kb.

这些每日INSERT分为5个客户端(该表有一个FK调用ClientID).无需跨多个客户端选择或加入数据.

随着这个表的增长,我担心数据库性能,所以我提出了两个解决方案.

解决方案1:

• 分区BigTable由ClientID
• 将每个分区存储在服务器上的单独硬盘上(使用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(以天为单位的DB年龄) - (30,000,000).这仍然是一个巨大的表,但只会用于绘制奇怪的报告.

SQL Server将托管在14GB,8core Azure VM上.

解决方案2:

另一种选择是为每个客户端托管单独的数据库.这意味着每个人都拥有自己专用的SQL Server机器.归档数据仍将进行分区.

由于数据的物理分离,此选项不是最佳选项.必须管理多个数据库的更新可能非常有问题.为每个客户端建立单独的数据库连接也是开发人员的考虑因素.

任何人都可以就这些选择提出建议吗？

Answer 1

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

在构建可扩展的体系结构时,分区策略不应该基于像"客户端"这样的特定内容,而应该更加随意.原因很简单 - 除非客户端有理由分开,例如不希望他们的数据与其他人混合,或者每个客户端都有不同的SLA,那么选择"客户端"作为分区可能无法呈现最佳结果.如果80%的业务是由单个客户生成的,那么您还没有解决问题,仍然需要为边际负载维护n个单独的数据库.

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

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

• 在某些时候,SQL是一些很好的存储数据.
• 大部分处理可以异步完成,因此插入物的峰值性能几乎没有问题(在24小时内进行5密耳插入不是问题).
• SQL可能不适合长期存储.
• 使用map-reduce而不是SQL查询可以有效地查询旧数据.

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

这个答案可能有点长,但是您可以更仔细地考虑您的数据模型,而不是仅仅考虑如何使用SQL来解决问题.有关更多详细信息,请查看CALM中的数据模型.