Oszacowanie zakresu migracji bazy danych

„Dodaj kolumnę” to migracja składająca się z jednej linii kodu. Szacowana liczba wierszy nie dotyczy tej kolumny.

Migracje schematów przebiegają według dwóch harmonogramów. Pierwszy to SQL: zazwyczaj szybki, zazwyczaj mechaniczny. Drugi to zegar operacyjny: jak długo blokuje tabelę, jak zachowuje się w przypadku równoczesnych operacji zapisu, w jaki sposób można cofnąć zmiany, jeśli coś pójdzie nie tak, oraz jakie są działania awaryjne, jeśli proces potrwa dłużej niż przewiduje to okno wdrożeniowe. Zespół podejmuje decyzję w sprawie kodu SQL, ponieważ to właśnie jest przedmiotem zgłoszenia. Praca dotyczy natomiast drugiego zegara.

Na niewielkim stole oba zegary są identyczne, a sprawa ma naprawdę niewielkie znaczenie. Na każdym stole, który ma znaczenie, tak nie jest. W kosztorysie należy uwzględnić wypełnienie luki, strategię wdrażania oraz procedurę wycofania, które ktoś musi przećwiczyć, zanim wdrożenie zbliży się choćby w najmniejszym stopniu do środowiska produkcyjnego.

O czym się mówi w tym pomieszczeniu

Backend: „To tylko polecenie ALTER, migracja potrwa zaledwie sekundę”.

SRE: „W tabeli zamówień? Z zablokowanymi pozycjami? O godz. 15:00?”

DBA: „W jaki sposób uzupełniamy istniejące wiersze?”

SRE: „Jak wygląda proces przywracania stanu poprzedniego, jeśli wdrożenie nie powiedzie się w połowie?”

Wstęp: „Czy ścieżka odczytu pozwala na to, by wartość w kolumnie pozostawała zerowa przez godzinę?”

Pytania, które warto zadać przed oddaniem głosu

• Jak duża jest ta tabela: czy zawiera tysiące, miliony czy setki milionów wierszy?
• Narzędzie do migracji online czy polecenie ALTER z zachowaniem istniejących danych?
• Strategia uzupełniania danych: synchroniczna, przetwarzanie partiami, podwójny zapis?
• Jakie działania podejmuje ścieżka odczytu w okresie wdrażania?
• Cofnięcie zmian: czy jest to operacja jednokierunkowa, czy też możliwe jest przywrócenie schematu?
• Czy ktoś zastosował się do procedury postępowania w sytuacjach awaryjnych dotyczącej tej migracji?

Jeśli połowa zgromadzonych opowiada się za „SQL”, a druga połowa za „wdrożeniem”, nie jest to problem związany z liczbą; mamy tu do czynienia z dwoma zadaniami udającymi jedno. Należy je rozdzielić: zmiana schematu to jedno zadanie, a uzupełnienie danych i plan wdrożenia to drugie.

Proszę oszacować czas wdrożenia i cofnięcia zmian, a nie czas operacji ALTER. To właśnie w tym drugim etapie tkwi ryzyko.

Proszę zapoznać się z oszacowaniem migracji danych w wariancie między systemami oraz z innymi przykładami praktycznych oszacowań. Po nakreśleniu planu wdrożenia proszę zorganizować bezpłatną sesję „planning poker”.