Bu sorun, öğeler arasındaki bağlantıları izlemekle ilgilidir. Bu onu grafikler ve grafik işleme alanına sokar . Özellikle, tüm veri kümesi bir grafik oluşturur ve biz bu grafiğin bileşenlerini arıyoruz . Bu, sorudan alınan örnek verilerin bir grafiği ile gösterilebilir.
Soru, bu değeri paylaşan diğer satırları bulmak için GroupKey veya RecordKey'i izleyebileceğimizi söylüyor. Böylece her ikisini de bir grafikte tepe noktası olarak ele alabiliriz. Soru, Grup Tuşları 1–3'ün aynı Üst GrupKey'e nasıl sahip olduğunu açıklamaya devam eder. Bu, soldaki kümenin ince çizgilerle birleştiği görülebilir. Resim ayrıca orijinal veriler tarafından oluşturulan diğer iki bileşeni (SupergroupKey) göstermektedir.
SQL Server, T-SQL'de yerleşik bazı grafik işleme yeteneğine sahiptir. Ancak şu anda oldukça yetersiz ve bu sorunla yardımcı değil. SQL Server ayrıca R ve Python ve zengin ve sağlam paketler için çağrı yapabilir. Bunlardan biri igraph . Bu için yazılmıştır "hızlı köşeler ve kenarlar (milyonlarca, büyük grafikler taşıma bağlantı )."
R ve igraph I kullanarak lokal testlerde 2 dakika 22 saniyede bir milyon satırı işleyebildim 1 . Mevcut en iyi çözümle şu şekilde karşılaştırır:
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.
1M satırları işlerken, grafiği yüklemek ve işlemek ve tabloyu güncellemek için 1m40'lar kullanıldı. Bir SSMS sonuç tablosunu çıktı ile doldurmak için 42'ler gerekiyordu.
Görev Yöneticisi'nin 1M satırları işlenirken gözlemlenmesi yaklaşık 3GB çalışma belleği gerektiğini gösterir. Bu, disk belleği olmadan bu sistemde mevcuttu.
Ypercube'un özyinelemeli CTE yaklaşımı hakkındaki değerlendirmesini doğrulayabilirim. Birkaç yüz kayıt tuşu ile CPU'nun% 100'ünü ve mevcut tüm RAM'i tüketiyordu. Sonunda tempdb 80GB'ın üzerine çıktı ve SPID çöktü.
Paul'ün masasını SupergroupKey sütunuyla kullandım, böylece çözümler arasında adil bir karşılaştırma var.
Nedense R Poincaré aksanına itiraz etti. Düz bir "e" olarak değiştirilmesine izin verdi. Eldeki probleme almanca olmadığı için araştırmadım. Eminim bir çözüm var.
İşte kod
-- 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);
R kodunun yaptığı budur
@input_data_1 SQL Server'ın verileri tablodan R koduna nasıl aktardığı ve InputDataSet adı verilen bir R veri çerçevesine nasıl çevirdiği.
library(igraph) kütüphaneyi R yürütme ortamına aktarır.
df.g <- graph.data.frame(d = InputDataSet, directed = FALSE)verileri bir igraph nesnesine yükleyin. Bu, yönlendirilmemiş bir grafiktir, çünkü gruptan kayda veya gruba kayıt bağlantılarını takip edebiliriz. InputDataSet, SQL Server'ın R'ye gönderilen veri kümesi için varsayılan adıdır.
cpts <- components(df.g, mode = c("weak")) ayrık alt grafikler (bileşenler) ve diğer ölçümleri bulmak için grafiği işleyin.
OutputDataSet <- data.frame(cpts$membership)SQL Server, R'den bir veri çerçevesi bekler. Varsayılan adı OutputDataSet'dir. Bileşenler "üyelik" adı verilen bir vektörde saklanır. Bu ifade vektörü bir veri çerçevesine çevirir.
OutputDataSet$VertexName <- V(df.g)$nameV (), grafikteki köşe noktalarının bir vektörüdür - GroupKeys ve RecordKeys listesi. Bu, onları çıkış veri çerçevesine kopyalayarak VertexName adlı yeni bir sütun oluşturur. Bu, SupergroupKey'i güncellemek için kaynak tabloyla eşleştirmek için kullanılan anahtardır.
Ben bir R uzmanı değilim. Muhtemelen bu optimize edilebilir.
Test verisi
Doğrulama için OP verileri kullanıldı. Ölçek testleri için aşağıdaki betiği kullandım.
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);
Şimdilik oranları OP'nin tanımından yanlış bir şekilde aldığımı fark ettim. Bunun zamanlamaları etkileyeceğine inanmıyorum. Kayıtlar ve Gruplar bu işlem için simetriktir. Algoritmaya hepsi bir grafikteki düğümlerdir.
Verilerin testinde her zaman tek bir bileşen oluştu. Bunun verilerin eşit dağılımından kaynaklandığına inanıyorum. Eğer üretim rutinine sabit olarak kodlanmış statik 1: 8 oranı yerine oranın değişmesine izin vermiş olsaydı, daha fazla bileşen olabilirdi.
1 Makine özellikleri: Microsoft SQL Server 2017 (RTM-CU12), Geliştirici Sürümü (64 bit), Windows 10 Home. 16 GB RAM, SSD, 4 çekirdekli hiper iş parçacıklı i7, 2,8 GHz nominal. Testler, normal sistem etkinliği (yaklaşık% 4 CPU) dışında, o sırada çalışan tek öğelerdi.
