Questo problema riguarda i seguenti collegamenti tra elementi. Questo lo mette nel regno dei grafici e dell'elaborazione dei grafici . In particolare, l'intero set di dati forma un grafico e stiamo cercando componenti di quel grafico. Questo può essere illustrato da un grafico dei dati di esempio dalla domanda.
La domanda dice che possiamo seguire GroupKey o RecordKey per trovare altre righe che condividono quel valore. Quindi possiamo trattare entrambi come vertici in un grafico. La domanda continua spiegando come GroupKeys 1–3 abbia lo stesso SupergroupKey. Questo può essere visto come il cluster a sinistra unito da linee sottili. L'immagine mostra anche gli altri due componenti (SupergroupKey) formati dai dati originali.
SQL Server ha alcune capacità di elaborazione dei grafici integrate in T-SQL. Al momento, tuttavia, è piuttosto scarso e non è utile con questo problema. SQL Server ha anche la possibilità di chiamare R e Python e la ricca e robusta suite di pacchetti disponibili. Uno di questi è igraph . È scritto per "gestione rapida di grafici di grandi dimensioni, con milioni di vertici e bordi ( link )".
Usando R ed igraph sono stato in grado di elaborare un milione di righe in 2 minuti e 22 secondi nei test locali 1 . Ecco come si confronta con l'attuale migliore soluzione:
Record Keys Paul White R
------------ ---------- --------
Per question 15ms ~220ms
100 80ms ~270ms
1,000 250ms 430ms
10,000 1.4s 1.7s
100,000 14s 14s
1M 2m29 2m22s
1M n/a 1m40 process only, no display
The first column is the number of distinct RecordKey values. The number of rows
in the table will be 8 x this number.
Durante l'elaborazione di righe 1M, sono stati utilizzati 1m40 per caricare ed elaborare il grafico e aggiornare la tabella. Sono stati necessari 42 secondi per popolare una tabella dei risultati SSMS con l'output.
L'osservazione di Task Manager mentre venivano elaborate 1M righe suggerisce che erano necessari circa 3 GB di memoria di lavoro. Questo era disponibile su questo sistema senza paging.
Posso confermare la valutazione di Ypercube dell'approccio CTE ricorsivo. Con poche centinaia di chiavi di registrazione ha consumato il 100% della CPU e tutta la RAM disponibile. Alla fine tempdb è cresciuto fino a oltre 80 GB e lo SPID si è bloccato.
Ho usato il tavolo di Paul con la colonna SupergroupKey, quindi c'è un giusto confronto tra le soluzioni.
Per qualche ragione R ha contestato l'accento su Poincaré. Modificandolo in una semplice "e" gli ha permesso di funzionare. Non ho indagato poiché non è germano del problema attuale. Sono sicuro che c'è una soluzione.
Ecco il codice
-- This captures the output from R so the base table can be updated.
drop table if exists #Results;
create table #Results
(
Component int not NULL,
Vertex varchar(12) not NULL primary key
);
truncate table #Results; -- facilitates re-execution
declare @Start time = sysdatetimeoffset(); -- for a 'total elapsed' calculation.
insert #Results(Component, Vertex)
exec sp_execute_external_script
@language = N'R',
@input_data_1 = N'select GroupKey, RecordKey from dbo.Example',
@script = N'
library(igraph)
df.g <- graph.data.frame(d = InputDataSet, directed = FALSE)
cpts <- components(df.g, mode = c("weak"))
OutputDataSet <- data.frame(cpts$membership)
OutputDataSet$VertexName <- V(df.g)$name
';
-- Write SuperGroupKey to the base table, as other solutions do
update e
set
SupergroupKey = r.Component
from dbo.Example as e
inner join #Results as r
on r.Vertex = e.RecordKey;
-- Return all rows, as other solutions do
select
e.SupergroupKey,
e.GroupKey,
e.RecordKey
from dbo.Example as e;
-- Calculate the elapsed
declare @End time = sysdatetimeoffset();
select Elapse_ms = DATEDIFF(MILLISECOND, @Start, @End);
Questo è ciò che fa il codice R.
@input_data_1 è il modo in cui SQL Server trasferisce i dati da una tabella al codice R e li traduce in un frame di dati R chiamato InputDataSet.
library(igraph) importa la libreria nell'ambiente di esecuzione R.
df.g <- graph.data.frame(d = InputDataSet, directed = FALSE)carica i dati in un oggetto igraph. Questo è un grafico non indirizzato poiché possiamo seguire i collegamenti da un gruppo per registrare o registrare per un gruppo. InputDataSet è il nome predefinito di SQL Server per il set di dati inviato a R.
cpts <- components(df.g, mode = c("weak")) elabora il grafico per trovare sotto-grafici (componenti) discreti e altre misure.
OutputDataSet <- data.frame(cpts$membership)SQL Server prevede un frame di dati da R. Il nome predefinito è OutputDataSet. I componenti sono memorizzati in un vettore chiamato "appartenenza". Questa affermazione traduce il vettore in un frame di dati.
OutputDataSet$VertexName <- V(df.g)$nameV () è un vettore di vertici nel grafico - un elenco di GroupKeys e RecordKeys. Questo li copia nel frame di dati di output, creando una nuova colonna chiamata VertexName. Questa è la chiave utilizzata per abbinare la tabella di origine per l'aggiornamento di SupergroupKey.
Non sono un esperto di R. Probabilmente questo potrebbe essere ottimizzato.
Dati di test
I dati del PO sono stati utilizzati per la convalida. Per i test di scala ho usato il seguente script.
drop table if exists Records;
drop table if exists Groups;
create table Groups(GroupKey int NOT NULL primary key);
create table Records(RecordKey varchar(12) NOT NULL primary key);
go
set nocount on;
-- Set @RecordCount to the number of distinct RecordKey values desired.
-- The number of rows in dbo.Example will be 8 * @RecordCount.
declare @RecordCount int = 1000000;
-- @Multiplier was determined by experiment.
-- It gives the OP's "8 RecordKeys per GroupKey and 4 GroupKeys per RecordKey"
-- and allows for clashes of the chosen random values.
declare @Multiplier numeric(4, 2) = 2.7;
-- The number of groups required to reproduce the OP's distribution.
declare @GroupCount int = FLOOR(@RecordCount * @Multiplier);
-- This is a poor man's numbers table.
insert Groups(GroupKey)
select top(@GroupCount)
ROW_NUMBER() over (order by (select NULL))
from sys.objects as a
cross join sys.objects as b
--cross join sys.objects as c -- include if needed
declare @c int = 0
while @c < @RecordCount
begin
-- Can't use a set-based method since RAND() gives the same value for all rows.
-- There are better ways to do this, but it works well enough.
-- RecordKeys will be 10 letters, a-z.
insert Records(RecordKey)
select
CHAR(97 + (26*RAND())) +
CHAR(97 + (26*RAND())) +
CHAR(97 + (26*RAND())) +
CHAR(97 + (26*RAND())) +
CHAR(97 + (26*RAND())) +
CHAR(97 + (26*RAND())) +
CHAR(97 + (26*RAND())) +
CHAR(97 + (26*RAND())) +
CHAR(97 + (26*RAND())) +
CHAR(97 + (26*RAND()));
set @c += 1;
end
-- Process each RecordKey in alphabetical order.
-- For each choose 8 GroupKeys to pair with it.
declare @RecordKey varchar(12) = '';
declare @Groups table (GroupKey int not null);
truncate table dbo.Example;
select top(1) @RecordKey = RecordKey
from Records
where RecordKey > @RecordKey
order by RecordKey;
while @@ROWCOUNT > 0
begin
print @Recordkey;
delete @Groups;
insert @Groups(GroupKey)
select distinct C
from
(
-- Hard-code * from OP's statistics
select FLOOR(RAND() * @GroupCount)
union all
select FLOOR(RAND() * @GroupCount)
union all
select FLOOR(RAND() * @GroupCount)
union all
select FLOOR(RAND() * @GroupCount)
union all
select FLOOR(RAND() * @GroupCount)
union all
select FLOOR(RAND() * @GroupCount)
union all
select FLOOR(RAND() * @GroupCount)
union all
select FLOOR(RAND() * @GroupCount)
) as T(C);
insert dbo.Example(GroupKey, RecordKey)
select
GroupKey, @RecordKey
from @Groups;
select top(1) @RecordKey = RecordKey
from Records
where RecordKey > @RecordKey
order by RecordKey;
end
-- Rebuild the indexes to have a consistent environment
alter index iExample on dbo.Example rebuild partition = all
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF,
ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON);
-- Check what we ended up with:
select COUNT(*) from dbo.Example; -- Should be @RecordCount * 8
-- Often a little less due to random clashes
select
ByGroup = AVG(C)
from
(
select CONVERT(float, COUNT(1) over(partition by GroupKey))
from dbo.Example
) as T(C);
select
ByRecord = AVG(C)
from
(
select CONVERT(float, COUNT(1) over(partition by RecordKey))
from dbo.Example
) as T(C);
Mi sono appena reso conto che ho ottenuto i rapporti nel modo sbagliato dalla definizione del PO. Non credo che ciò influirà sui tempi. Record e gruppi sono simmetrici a questo processo. Per l'algoritmo sono tutti solo nodi in un grafico.
Nel testare i dati formava invariabilmente un singolo componente. Credo che ciò sia dovuto alla distribuzione uniforme dei dati. Se invece del rapporto statico 1: 8 codificato nella routine di generazione avessi permesso al rapporto di variare, ci sarebbero stati probabilmente ulteriori componenti.
1 Specifiche della macchina: Microsoft SQL Server 2017 (RTM-CU12), Developer Edition (64-bit), Windows 10 Home. 16 GB di RAM, SSD, i7 hyperthreaded a 4 core, 2,8 GHz nominali. I test erano gli unici elementi in esecuzione al momento, diversi dalla normale attività del sistema (circa il 4% della CPU).
