这是前一个问题的接续.
我从未处理过Server分区,但我目前面临的问题是设计一个可能需要卷的数据库。这个系统是用来购买优惠券的。优惠券将定期发行,通常每六周发行一次,不过也会有特别发行(如特别活动的优惠券)。有1500万客户,每一次发行活动,每个客户将收到6种不同的优惠券类型,总共9000万的优惠券实例。我们需要跟踪优惠券实例赎回数据,并维持6个月,尽管通常一张优惠券只有效六个星期。任何无效优惠券的赎回请求将不会到达数据库,因为它将由POS验证直到。
在六个月的时间里,我们需要在优惠券实例表中存储10亿行,在救赎表中存储多达2亿行(假设最高20%的赎回率)。
对这些表有两个主要查询: 1.从优惠券实例中选择优惠券条形码=x(用于赎回);2从优惠券实例中选择忠诚卡号=x(通过打印机发出优惠券)
为了帮助进行第一个查询,我可以通过发布事件对实例表进行分区,然后将发布事件嵌入条形码中。因此,如果我们有一个在实例表中创建50m条记录的发布事件,那么我们为这些记录有一个单独的分区--然后SQL就能够为给定的条形码子字符串(一个2位数的发布事件号)找到正确的分区。
第二个问题呢?我想把两种方式分开是不可能的?如果我要使用数据库切分来实现这一点,那么我的切分算法将要求我需要将相同的记录存储在50%的记录中的多个碎片上。这是可行的,但它在存储空间中是昂贵的,我想避免切分,因为添加添加碎片时需要“再平衡”。
是否有任何特殊的方法,分区可以帮助这里,还是我应该简单地分区,以帮助第一个查询和辞职自己寻找一个完整的表高索引为第二个?
谢谢
抢夺
发布于 2011-12-09 13:16:08
如果您有数十亿行,那么确实不需要分区才能有效地工作,这也是我在你最后一个问题上告诉你的...even。
如果您在BarcodeID上集群(我假设它是唯一的),并在LoyaltyCardID上放置一个非聚集索引,那么它应该工作得很好。这些并不是复杂的查询,有许多来自事物声音的附加逻辑,简单的搜索操作本身是非常高效的。
你是受到了分割的压力,还是仅仅是你决定要做的事情?
https://dba.stackexchange.com/questions/8989
复制相似问题