标签: partitioning

我在 MS SQL Server 中有一个表。

• 表大小：806 GB
• 行数：12亿
• 索引空间：1.2 GB

表使用方法：记录从Web Service调用99.9％的使用率从伐木，开发商很少看这个表在正式版（仅当报告或研究的问题）。

主键：基于“INT”数据类型的“ID”。有一个基于“ID”列的聚集索引。

我对此更改的意图：想要管理此表（因为它有 10 年的数据）并继续前进（由于新要求），开发人员/分析师有可能进一步深入研究此表（仅几个月）我不想为同样的目的创建一个新表。

我的问题：

1. [主要问题]我可以根据“DateCreated”（DATETIME，NOT NULL 列）对这个表进行分区，而不会引起问题（逻辑上/性能方面）。

2. [很高兴知道] 需要多少时间（我知道这取决于数据库空间/服务器内存和其他细节，但大概# 会很好）对这个巨大的表进行分区（如果可以根据日期进行分区） . 问这个问题，因为这是一个生产表，行被频繁插入（现在大约 350 条记录/分钟）。

3. 【不完全是问题，求推荐】有没有更好的方案来管理这个表（不想在Production中保留3年以上的数据，方案在下面提到）？

当前计划（我是 MS SQL 的新手，所以这就是我想出的）：

• 在每个分区中保留 3 个月的数据。
• 系统在每个季度前自动创建分区。
• 在活动表中仅保留 3 年的分区。
• 将其他分区移动到 OLD/ARCHIEVE 表（需要创建这个）。真正要清除的旧数据。

我有一个非常频繁更新的表，其中包含 2.4 亿行（并且还在增长）。每三小时插入 150 万行，删除 150 万行。当我将集群移动到 SSD 时，批量插入（使用复制）时间从 22 分钟减少到 2.3 分钟。删除时间也得到改善。我计划每两小时或每小时进行一次批量更新。

虽然现在的性能（在 SSD 之后）与更频繁的更新兼容，但我读过一些关于 SSD 死亡的恐怖故事，因为 NAND 耐久性有限加上写放大。由于 SSD 价格昂贵，我想尽可能地将它的消亡推迟到未来。因此我的问题是：在删除和随后的真空中磁盘文件到底发生了什么？我猜有两个磁盘写入，一个将行标记为已删除，另一个在清理时将其标记为可覆盖。如果不是删除和清空，而是在每次批量插入/删除时对表进行分区创建和删除表，我会尽量减少 SSD 的磨损吗？

设想：

• 两个数据库：DB_A 和 DB_Archive，有一个非常大的表叫做 tableA。
• 每天，超过 60 天的记录从 DB_A 中删除并移动到 DB_Archive 主要是为了让事物“分离”，因为 tableA 在 DB_A 上被大量查询过去 2 个月的记录。

我想摆脱这个过程，因为它很慢并且消耗大量资源。我正在考虑使用日期列上的分区函数在 DB_A 上实现表分区，并在一个分区上存储 < 2 个月的所有记录，在另一个分区上存储 > 2 个月的所有记录。我的问题：

• 如果我有 2 个不同的数据库，这种情况是否会表现得像？如果我查询 tableA 中的记录 > getdate() - 30，它会读取归档分区吗？
• 我想我也必须对索引进行分区，对吗？
• 我如何处理明天我的分区函数将“更改”的事实，我的意思是，如果我今天创建该函数（7 月 2 日，其范围将是 5 月 2 日，但明天将是 5 月 3 日）。我可以创建动态分区函数吗？

我有大量的天气模型数据被放入 PostgreSQL 数据库。该机器具有 8 个内核和 16 GB 的 RAM。我正在使用 PostGIS 2.1 运行 PostgreSQL 9.3。每个表都有不同种类的天气数据（温度、露点、风等）。每个表将有 6-7 列：纬度、经度、点几何、高程、模型相关的日期时间以及 1-2 个感兴趣的数据值。数据将主要按时间和高程查询边界框。每个表将有大约 145,757,360 行（早于现在不再相关的数据将被删除）。我粗略估计每个表的大小约为 10 GB，没有索引。（这是 52 字节的数据加上每行 23 字节的开销）。随着新模型数据可用，数据将定期更新/插入。笔记：

所以我正在研究这两个计划：

1. 简单地按（日期时间，高程）索引和聚类，并为点几何添加一个额外的索引。运行一个常规的 cron 作业来删除旧行、运行vacuum/analyze 和重新集群。
2. 按日期时间分区，然后按每个表的高程进行聚类和索引，并在几何上有索引。运行常规的 cron 作业以添加新表并删除旧表。

更远，

• 所以，我知道删除表和删除和清空表的效率要高得多。但是，否则我会看到性能提升吗？
• 当所有表将被均匀更新和选择直到删除不相关时，分区是否合适（文档表明分区在只选择其中几个时效果最佳）？

传递数据时，选择会比聚集索引更快吗？如果同时发出多个请求，答案是否会改变？

谢谢你。我希望我提供了所有需要的数据。如果没有让我知道，我会添加它。

版本：SQL Server 2008 R2 企业版。(10.50.4000)

为了评估我们的分区策略，我编写了这个查询来获取针对分区索引的访问方法（从广义上讲，虽然我正在消除堆）。当我缩小我的重点，分区表，我相信我需要看的range_scan_count和singleton_lookup_count，但我有一个很难概念化。

SELECT 
    t.name AS table_name,
    i.name AS index_name,
    ios.partition_number, 
    leaf_insert_count,
    leaf_delete_count,
    leaf_update_count,
    leaf_ghost_count,
    range_scan_count,
    singleton_lookup_count,
    page_latch_wait_count ,
    page_latch_wait_in_ms,
    row_lock_count ,
    page_lock_count,
    row_lock_wait_in_ms ,
    page_lock_wait_in_ms,
    page_io_latch_wait_count ,
    page_io_latch_wait_in_ms
FROM sys.dm_db_partition_stats ps
    JOIN sys.tables t 
        ON ps.object_id = t.object_id
    JOIN sys.schemas s 
        ON t.schema_id = s.schema_id
    JOIN sys.indexes i 
        ON t.object_id = i.object_id
    AND ps.index_id = i.index_id
OUTER APPLY sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) ios                            
WHERE   
    ps.object_id = ios.object_id
    AND ps.index_id = ios.index_id
    AND …

鉴于以下

-- table ddl
create table dbo.f_word(
    sentence_id int NULL,
    sentence_word_id int NULL,
    word_id int NULL,
    lemma_id int NULL,
    source_id int NULL,
    part_of_speech_id int NULL,
    person_id int NULL,
    gender_id int NULL,
    number_id int NULL,
    tense_id int NULL,
    voice_id int NULL,
    mood_id int NULL,
    case_id int NULL,
    degree_id int NULL,
    citation nvarchar(100) NULL
);
-- create partition function
create partition function pf_f_word_source_id (int)
as range left for values 
(
    1,2,3,4,5,6,7,8,9,10,11,12,13,14,
    15,16,17,18,19,20,21,22,23
);

-- create the partition scheme
create partition scheme ps_f_word …

提高多达 1 亿行的表的读/写性能的常用方法是什么？

表有 column SEGMENT_ID INT NOT NULL，其中每个段有大约 100.000-1.000.000 行。写入 -SEGMENT_ID一次插入所有行，SEGMENT_ID之后不更新。读取 - 非常频繁，我需要良好的SELECT * FROM table WERE SEGMENT_ID = ?.

最明显的方法是SEGMENT_ID动态创建新表，但动态表意味着使用 ORM 甚至本机 SQL 查询框架进行黑客攻击。换句话说，你完成了有味道的代码。

您也可以使用分片，对吗？数据库是否在幕后创建新表？

我可以通过SEGMENT_ID. 但是，如果我一次插入所有与段相关的数据，我的插入是否会聚集在一起？

Postgres 还建议使用分区来处理非常大的表。

也许有某种神奇的索引可以帮助我避免动态创建新表或配置分片？

还有其他选择吗？

我从来没有使用过 SQL Server 分区，但我目前面临着设计一个卷可能需要它的数据库。该系统用于优惠券。优惠券将定期发行，通常每六周发行一次，但也会有临时发行——例如特殊活动。有1500万客户，每一次发行活动，每个客户将获得6种不同的优惠券类型，共计9000万张优惠券实例。我们需要跟踪优惠券实例兑换数据并将其保持 6 个月，尽管通常优惠券的有效期仅为 6 周。任何对无效优惠券的兑换请求都不会到达数据库，因为它将由 POS 直到验证。

在六个月的时间里，我们需要在 Coupon Instance 表中存储 3.6 亿行，在 Redemption 表中存储多达 7200 万行（假设最高 20% 的赎回率）。我觉得这些数字对于单个分区来说太大了？

我的问题是 - 使用什么作为分区键？一个明显的候选者是发行事件，给出大约 6 个分区。但是我认为即使这样也会导致分区大小太大而无法实现最佳性能？是否可以通过两个键进行分区，例如通过发行事件 + 客户 ID 的最后一位数字？所以逻辑是：

If issuance event = 1 and last digit of customer id < 5 then
    Store in partition 1
Else if issuance event = 1 and last digit of customer id >4 then
    Store in partition 2
Else if issuance event =2 and last digit of customer id <5 then …

我有一个分区表结构，如：

CREATE TABLE measurements (
    sensor_id bigint,
    tx timestamp,
    measurement int
);

CREATE TABLE measurements_201201(
    CHECK (tx >= '2012-01-01 00:00:00'::timestamp without time zone 
       AND tx < ('2012-01-01 00:00:00'::timestamp without time zone + '1 mon'::interval))    
)INHERITS (measurements);
CREATE INDEX ON measurements_201201(sensor_id);
CREATE INDEX ON measurements_201201(tx);
CREATE INDEX ON measurements_201201(sensor_id, tx);
....

等等。每个表有大约 20M 行。

如果我在WHERE子句中查询传感器样本和时间戳样本，查询计划会显示选择的正确表和使用的索引，例如：

SELECT *
FROM measurements
INNER JOIN sensors TABLESAMPLE BERNOULLI (0.01) USING (sensor_id)
WHERE tx BETWEEN '2015-01-04 05:00' AND '2015-01-04 06:00' 
    OR tx BETWEEN '2015-02-04 …

我有一个大表（几亿行），我想对其进行有效分区。我的问题是分区大小和分区数之间是否存在权衡。据我所知，分区中使用的列上的大多数查询会更快，因为查询（对于大多数查询）只需要在适用于查询的分区内进行搜索。因此，为了最大限度地提高效率，您应该将大表划分为最大数量的分区，从而使每个分区尽可能小是有道理的。对于 MySQL，这意味着 1024 个分区。但是，拥有大量分区是否有任何性能缺陷？是这样，如何找到最佳分区数？

注意：在 stackoverflow 上已经有一个有点类似的问题，但只有一个答案，（从我的角度来看）没有达到目标。所以我会用我自己的方式陈述这个问题......希望它更清楚