Bei diesem Problem geht es darum, Verknüpfungen zwischen Elementen zu folgen. Dies versetzt es in den Bereich der Grafiken und der Grafikverarbeitung. Insbesondere bildet der gesamte Datensatz ein Diagramm, und wir suchen nach Komponenten dieses Diagramms. Dies kann durch eine grafische Darstellung der Beispieldaten aus der Frage veranschaulicht werden.
Die Frage besagt, dass wir GroupKey oder RecordKey folgen können, um andere Zeilen zu finden, die diesen Wert gemeinsam haben. Wir können also beide als Scheitelpunkte in einem Diagramm behandeln. In der Frage wird weiter erläutert, wie GroupKeys 1–3 denselben SupergroupKey haben. Dies kann als der Cluster auf der linken Seite gesehen werden, der durch dünne Linien verbunden ist. Das Bild zeigt auch die beiden anderen Komponenten (SupergroupKey), die aus den Originaldaten bestehen.
SQL Server verfügt über einige in T-SQL integrierte Grafikverarbeitungsfunktionen. Zu diesem Zeitpunkt ist es jedoch recht dürftig und bei diesem Problem nicht hilfreich. SQL Server kann auch R und Python sowie die umfangreiche und robuste Suite von Paketen aufrufen, die ihnen zur Verfügung stehen. Eines davon ist igraph . Es wurde für "schnelle Handhabung großer Graphen mit Millionen von Eckpunkten und Kanten ( Link )" geschrieben.
Mit R und igraph konnte ich in lokalen Tests 1 eine Million Zeilen in 2 Minuten 22 Sekunden verarbeiten . So wird es mit der derzeit besten Lösung verglichen:
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.
Bei der Verarbeitung von 1 Million Zeilen wurden 1 bis 40 Sekunden verwendet, um das Diagramm zu laden und zu verarbeiten und die Tabelle zu aktualisieren. 42s waren erforderlich, um eine SSMS-Ergebnistabelle mit der Ausgabe zu füllen.
Die Beobachtung des Task-Managers während der Verarbeitung von 1 Million Zeilen lässt darauf schließen, dass etwa 3 GB Arbeitsspeicher erforderlich sind. Dies war auf diesem System ohne Paging verfügbar.
Ich kann Ypercubes Einschätzung des rekursiven CTE-Ansatzes bestätigen. Mit ein paar hundert Aufnahmetasten verbrauchte es 100% der CPU und den gesamten verfügbaren RAM. Schließlich wuchs die Tempdb auf über 80 GB und die SPID stürzte ab.
Ich habe Pauls Tabelle mit der SupergroupKey-Spalte verwendet, damit es einen fairen Vergleich zwischen den Lösungen gibt.
Aus irgendeinem Grund lehnte R den Akzent auf Poincaré ab. Durch Ändern in ein einfaches "e" konnte es ausgeführt werden. Ich habe nicht nachgeforscht, da es für das vorliegende Problem nicht relevant ist. Ich bin sicher, es gibt eine Lösung.
Hier ist der Code
-- 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);
Dies ist, was der R-Code tut
@input_data_1 Auf diese Weise überträgt SQL Server Daten aus einer Tabelle in R-Code und übersetzt sie in einen R-Datenrahmen namens InputDataSet.
library(igraph) Importiert die Bibliothek in die R-Ausführungsumgebung.
df.g <- graph.data.frame(d = InputDataSet, directed = FALSE)Laden Sie die Daten in ein igraph-Objekt. Dies ist ein ungerichteter Graph, da wir Links von Gruppe zu Datensatz oder von Datensatz zu Gruppe folgen können. InputDataSet ist der Standardname von SQL Server für das an R gesendete Dataset.
cpts <- components(df.g, mode = c("weak")) Verarbeiten Sie das Diagramm, um diskrete Unterdiagramme (Komponenten) und andere Kennzahlen zu finden.
OutputDataSet <- data.frame(cpts$membership)SQL Server erwartet einen Datenrahmen von R. Der Standardname lautet OutputDataSet. Die Komponenten werden in einem Vektor gespeichert, der als "Mitgliedschaft" bezeichnet wird. Diese Anweisung übersetzt den Vektor in einen Datenrahmen.
OutputDataSet$VertexName <- V(df.g)$nameV () ist ein Vektor von Eckpunkten im Diagramm - eine Liste von GroupKeys und RecordKeys. Dadurch werden sie in den Ausgangsdatenrahmen kopiert und eine neue Spalte mit dem Namen VertexName erstellt. Dies ist der Schlüssel, der zum Abgleichen mit der Quelltabelle zum Aktualisieren von SupergroupKey verwendet wird.
Ich bin kein R-Experte. Wahrscheinlich könnte dies optimiert werden.
Testdaten
Die Daten des OP wurden zur Validierung verwendet. Für Skalentests habe ich das folgende Skript verwendet.
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);
Ich habe gerade festgestellt, dass ich die Verhältnisse aus der OP-Definition falsch herum ermittelt habe. Ich glaube nicht, dass dies das Timing beeinflussen wird. Datensätze und Gruppen sind für diesen Prozess symmetrisch. Für den Algorithmus sind sie alle nur Knoten in einem Diagramm.
Beim Testen bildeten die Daten immer eine einzelne Komponente. Ich glaube, das liegt an der gleichmäßigen Verteilung der Daten. Wenn ich anstelle des statischen 1: 8-Verhältnisses, das in der Generierungsroutine fest codiert ist, zugelassen hätte, dass das Verhältnis variiert, hätte es wahrscheinlich weitere Komponenten gegeben.
1 Computerspezifikation: Microsoft SQL Server 2017 (RTM-CU12), Developer Edition (64-Bit), Windows 10 Home. 16 GB RAM, SSD, 4-Kern-Hyperthread-i7, nominal 2,8 GHz. Abgesehen von der normalen Systemaktivität (ca. 4% CPU) waren die Tests die einzigen Elemente, die zu diesem Zeitpunkt ausgeführt wurden.
