Ця проблема стосується наступних зв’язків між елементами. Це ставить його у сферу графіків та обробки графіків. Зокрема, весь набір даних формує графік, і ми шукаємо компоненти цього графіка. Це можна проілюструвати графіком зразкових даних із запитання.
Питання говорить, що ми можемо слідувати GroupKey або RecordKey, щоб знайти інші рядки, які поділяють це значення. Тож ми можемо трактувати обидві як вершини у графі. Питання продовжує пояснювати, як GroupKeys 1–3 мають той самий SupergroupKey. Це можна побачити як кластер ліворуч, з'єднаний тонкими лініями. На малюнку також показані два інших компоненти (SupergroupKey), сформовані за вихідними даними.
SQL Server має деякі можливості обробки графіків, вбудовані в T-SQL. На даний момент це досить мізерно, але не корисно з цією проблемою. SQL Server також має можливість виклику R та Python, а також багатий та надійний набір пакетів, доступних для них. Одним із таких є іграф . Він написаний для "швидкої обробки великих графіків, з мільйонами вершин і ребер ( посилання )".
Використовуючи R і igraph, я зміг обробити один мільйон рядків за 2 хвилини 22 секунди в локальному тестуванні 1 . Ось як це порівнюється з поточним найкращим рішенням:
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.
Під час обробки 1М рядків 1m40 були використані для завантаження та обробки графіка та оновлення таблиці. 42-х потрібно було заповнити таблицю результатів SSMS результатом.
Спостереження диспетчера завдань під час обробки 1М рядків свідчить про необхідність близько 3 ГБ робочої пам'яті. Це було доступно в цій системі без підказок.
Я можу підтвердити оцінку Ypercube щодо рекурсивного підходу CTE. За допомогою декількох сотень ключів запису він спожив 100% процесора та всієї доступної оперативної пам’яті. Врешті-решт tempdb виріс до понад 80 ГБ, і SPID зазнав аварії.
Я використав таблицю Павла зі стовпцем SupergroupKey, щоб було справедливе порівняння між рішеннями.
Чомусь Р заперечив наголос на Пуанкаре. Змінення його на звичайне "е" дозволило йому працювати. Я не досліджував, оскільки це не є проблемою. Я впевнений, що є рішення.
Ось код
-- 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-код
@input_data_1 це те, як SQL Server передає дані з таблиці в R-код і переводить їх у рамку даних R, що називається InputDataSet.
library(igraph) імпортує бібліотеку в середовище виконання R.
df.g <- graph.data.frame(d = InputDataSet, directed = FALSE)завантажте дані в об’єкт igraph. Це непрямий графік, оскільки ми можемо переходити посилання з групи для запису або запису до групи. InputDataSet - це ім'я SQL Server за замовчуванням для набору даних, надісланого R.
cpts <- components(df.g, mode = c("weak")) обробити графік, щоб знайти дискретні під графіки (компоненти) та інші заходи.
OutputDataSet <- data.frame(cpts$membership)SQL Server очікує повернення кадру даних від R. Його ім'я за замовчуванням - OutputDataSet. Компоненти зберігаються у векторі, який називається "членство". Це твердження переводить вектор у кадр даних.
OutputDataSet$VertexName <- V(df.g)$nameV () - вектор вершин у графіку - список GroupKeys та RecordKeys. Це копіює їх у кадр даних про вихід, створюючи новий стовпець під назвою VertexName. Це ключ, який використовується для узгодження з вихідною таблицею для оновлення SupergroupKey.
Я не експерт з питань R Ймовірно, це можна оптимізувати.
Дані тесту
Дані ОП були використані для перевірки. Для масштабних тестів я використовував наступний сценарій.
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);
Я тільки що зрозумів, що отримав коефіцієнти неправильним шляхом із визначення ОП. Я не вірю, що це вплине на терміни. Записи та групи симетричні цьому процесу. Для алгоритму всі вони просто вузли в графіку.
При тестуванні даних незмінно формується один компонент. Я вважаю, що це пов'язано з рівномірним розподілом даних. Якби замість статичного співвідношення 1: 8, жорстко зафіксованого в режимі генерації, я дозволив би співвідношенню змінюватися там, швидше за все, були б інші компоненти.
1 Технічні характеристики: Microsoft SQL Server 2017 (RTM-CU12), версія для розробників (64-розрядні), Windows 10 Home. 16 Гб оперативної пам’яті, SSD, 4-ядерний гіпертоковий i7, номінал 2,8 ГГц. Тести були єдиними запущеними на той час елементами, крім нормальної системної активності (близько 4% процесора).
