Scalanie tabel bez przestoju: kiedy dwa modele mają stać się jednym

Podział tabeli to jeden kierunek. Czasem po latach chcemy zrobić odwrotnie: kilka struktur połączyć w jeden model.

Przykład

Mamy:

1
2

RetailCustomer
BusinessCustomer

i chcemy przejść do:

1

Customer

Nowy model

1
2
3
4
5
6
7

CREATE TABLE dbo.CustomerV2
(
    CustomerId bigint NOT NULL PRIMARY KEY,
    CustomerType varchar(20) NOT NULL,
    DisplayName nvarchar(200) NOT NULL,
    TaxId nvarchar(30) NULL
);

Najpierw mapowanie semantyki

Scalenie nie jest tylko UNION ALL.

Trzeba ustalić:

• jak mapują się klucze,
• które kolumny mają wspólne znaczenie,
• co zrobić z kolizjami identyfikatorów,
• jak reprezentować pola istniejące tylko w jednym modelu.

Stabilny klucz

Jeżeli stare tabele mogą mieć ten sam CustomerId, potrzebna jest warstwa mapowania.

1
2
3
4
5
6
7
8

CREATE TABLE migration.CustomerKeyMap
(
    SourceType varchar(20) NOT NULL,
    SourceId bigint NOT NULL,
    TargetId bigint NOT NULL,
    CONSTRAINT PK_CustomerKeyMap
        PRIMARY KEY (SourceType, SourceId)
);

Backfill i delta

Najpierw przenosimy stan historyczny. Potem synchronizujemy zmiany przychodzące w trakcie procesu.

CDC, kolejka zdarzeń albo dual-write mogą pełnić tę rolę.

Przełączanie konsumentów

Nie wszystkie aplikacje muszą przejść jednocześnie.

Można najpierw przełączyć:

• nowe API,
• raporty,
• wybrany moduł aplikacji,
• procesy batchowe.

Największa pułapka

Nie usuwaj starych tabel tylko dlatego, że nowa została poprawnie zasilona.

Najpierw udowodnij, że nikt już nie korzysta ze starego kontraktu.

Podsumowanie

Scalanie tabel to migracja danych, kluczy i semantyki jednocześnie.

Bez mapowania i telemetrii łatwo uzyskać nowy model, którego nie da się bezpiecznie zweryfikować.