Diversão com compressão (columnstore) em uma mesa muito grande – parte 2

• Escolhas de layout de arquivo ruins – Coloquei 8 arquivos em um grupo de arquivos, com paralelismo, mas sem particionamento (ou abaixo do ideal), espalhando E/S em vários arquivos com abandono imprudente. Para resolver isso, vou:
  • particione a tabela em 8 partições (uma por núcleo)
  • coloque o arquivo de dados de cada partição em seu próprio grupo de arquivos
  • use 8 processos separados para se afinizar com cada partição
  • usar compactação de arquivo em todas as partições, exceto a "ativa"
• muitos lotes pequenos e população de grupos de linhas abaixo do ideal – processando 10 milhões de linhas por vez, eu estava preenchendo nove rowgroups com 1.048.576 linhas, e as 562.816 linhas restantes terminariam em outro rowgroup menor. E quaisquer distribuições desiguais que deixassem um resto <102.400 linhas levariam inserções para a estrutura de armazenamento delta menos eficiente. Para distribuir as linhas de maneira mais uniforme e evitar o armazenamento delta, vou:
  • processe o máximo de dados possível em múltiplos exatos de 1.048.576 linhas
  • distribua-os em 8 partições da maneira mais uniforme possível
  • use um tamanho de lote mais próximo de 10x -> 100 milhões de linhas
• empilhamento do agendador – embora eu não tenha verificado isso, é possível que parte da lentidão tenha sido causada por um agendador assumindo muito trabalho e outro agendador insuficiente, devido ao round-robining do agendador. Agora que estarei carregando intencionalmente os dados com 8 processos maxdop 1 em vez de um processo maxdop 8, para manter todos os agendadores igualmente ocupados, vou:
  • usar um procedimento armazenado que tenta equilibrar uniformemente os agendadores (consulte as páginas 189-191 no Guia do SQLCAT para:Mecanismo Relacional para obter a inspiração por trás dessa ideia)
  • ative o sinalizador de rastreamento global 2467 e 2469, conforme alertado na documentação
• tarefa de compactação de armazenamento de colunas em segundo plano – foi um desperdício permitir que isso fosse executado durante a população, já que eu planejava reconstruir no final de qualquer maneira. Desta vez eu vou:
  • desative esta tarefa usando o sinalizador de rastreamento global 634

ALTER DATABASE OCopy ADD FILEGROUP FG_CCI_Part1;
 
ALTER DATABASE OCopy ADD FILE (name = N'CCI_Part_1', size = 250000, 
  filename = 'K:\Data\o_cci_p_1.mdf') TO FILEGROUP FG_CCI_Part1;
 
-- ... 6 more ...
 
ALTER DATABASE OCopy ADD FILEGROUP FG_CCI_Part8;
 
ALTER DATABASE OCopy ADD FILE (name = N'CCI_Part_8', size = 250000, 
  filename = 'K:\Data\o_cci_p_8.mdf') TO FILEGROUP FG_CCI_Part8;

;WITH x AS 
(
  SELECT OID, rn = ROW_NUMBER() OVER (ORDER BY OID)
    FROM dbo.tblOriginal WITH (NOLOCK)
)
SELECT OID, PartitionID = 1+(rn/((1048576*448)+1))
  INTO dbo.stage
  FROM x
  WHERE rn % (1048576*112) = 0;

;WITH x AS 
(
  SELECT OID, PartitionID FROM dbo.stage
),
y AS 
(
  SELECT PartitionID, 
    MinID = COALESCE(LAG(OID,1) OVER (ORDER BY OID),-1)+1,
    MaxID = OID 
  FROM x
  UNION ALL 
  SELECT PartitionID = 8, 
    MinID = MAX(OID)+1, 
    MaxID = 4000000000 -- easier than remembering the real max 
  FROM x
)
SELECT PartitionID, 
  BatchID = ROW_NUMBER() OVER (PARTITION BY PartitionID ORDER BY MinID),
  MinID, 
  MaxID,
  RowsInRange = CONVERT(int, NULL)
INTO dbo.BatchQueue
FROM y;
 
-- let's not leave this as a heap:
CREATE UNIQUE CLUSTERED INDEX PK_bq ON dbo.BatchQueue(PartitionID, BatchID);

DECLARE @sql nvarchar(max) = N'';
 
SELECT @sql += 'UPDATE dbo.BatchQueue SET RowsInRange = (
  SELECT COUNT(*)
    FROM dbo.tblOriginal WITH (NOLOCK)
    WHERE CostID BETWEEN ' + RTRIM(MinID) + ' AND ' + RTRIM(MaxID) + '
) WHERE MinID = ' + RTRIM(MinID) + ' AND MaxID = ' + RTRIM(MaxID) + ';'
FROM dbo.BatchQueue;
 
EXEC sys.sp_executesql @sql;

ALTER TABLE dbo.BatchQueue ADD DeltaStore AS (RowsInRange % 1048576);

DECLARE @sql nvarchar(max) = N'';
 
SELECT @sql = N'CREATE PARTITION FUNCTION PF_OID([bigint])
AS RANGE LEFT FOR VALUES 
(
  ' + STRING_AGG(MaxID, ',
  ') + '
);' FROM dbo.BatchQueue
   WHERE PartitionID < 8 
     AND BatchID = 4;
 
PRINT @sql;
-- EXEC sys.sp_executesql @sql;

CREATE PARTITION FUNCTION PF_OID([bigint])
AS RANGE LEFT FOR VALUES 
(
   489542824,
   965961973,
  1436859196,
  1909084364,
  2380757248,
  2851969364,
  3322791542
);

CREATE PARTITION SCHEME PS_OID AS PARTITION PF_OID TO 
(
  CCI_Part1, CCI_Part2, CCI_Part3, CCI_Part4, 
  CCI_Part5, CCI_Part6, CCI_Part7, CCI_Part8
);

CREATE TABLE dbo.tblPartitionedCCI
(
	OID bigint          NOT NULL,
	IN1 int             NOT NULL,
	IN2 int             NOT NULL,
	VC1 varchar(3)      NULL,
	BI1 bigint          NULL,
	IN3 int             NULL,
	VC2 varchar(128)    NOT NULL,
	VC3 varchar(128)    NOT NULL,
	VC4 varchar(128)    NULL,
	NM1 numeric(24,12)  NULL,
	NM2 numeric(24,12)  NULL,
	NM3 numeric(24,12)  NULL,
	BI2 bigint          NULL,
	IN4 int             NULL,
	BI3 bigint          NULL,
	NM4 numeric(24,12)  NULL,
	IN5 int             NULL,
	NM5 numeric(24,12)  NULL,
	DT1 date            NULL,
	VC5 varchar(128)    NULL,
	BI4 bigint          NULL,
	BI5 bigint          NULL,
	BI6 bigint          NULL,
	BT1 bit             NOT NULL,
	NV1 nvarchar(512)   NULL,
	VB1 varbinary(8000) NULL,
	IN6 int             NULL,
	IN7 int             NULL,
	IN8 int             NULL,
 	-- need to create a PK constraint on the partition scheme...
 	CONSTRAINT PK_CCI_Part PRIMARY KEY CLUSTERED (OID) ON PS_OID(OID)
);
 
-- ... only to drop it immediately...
ALTER TABLE dbo.tblPartitionedCCI DROP CONSTRAINT PK_CCI_Part;
GO
 
-- ... so we can replace it with the CCI:
CREATE CLUSTERED COLUMNSTORE INDEX CCI_Part
  ON dbo.tblPartitionedCCI 
  ON PS_OID(OID);
GO
 
-- now rebuild with the compression we want:
ALTER TABLE dbo.tblPartitionedCCI  
REBUILD PARTITION = ALL WITH 
(  
  DATA_COMPRESSION = COLUMNSTORE_ARCHIVE ON PARTITIONS (1 TO 7), 
  DATA_COMPRESSION = COLUMNSTORE ON PARTITIONS (8)
);