Migracja danych Valhalla.pl

Na początku jest wycena.

Ale jak wycenić coś, czego wycenić się nie da? Taka praca, która nie do końca wiadomo jak będzie przebiegać. Zupełnie inaczej niż z grafiką, którą po prostu trzeba zmienić w motyw. Tam widać. Choć czasem są ukryte kruczki, to jednak praca na obcej bazie danych jest jednym wielkim kruczkiem. Oczywiście wycena na podstawie dostarczonej bazy, ale … nie było schematu, baza bardzo prosta, bez kluczy obcych, więc moja obawa, że coś „zgubię” bardzo mocna.

No to wycena.

Pierwsza reakcja klienta: obawa. Widełki tak otwarte, na ile uważałem, że może być coś źle. Że może się posypać. Różnica między dołem, a górą 200%. Sporo. Wiem.

Celem pracy była migracja danych z autorskiego CMS’a do WordPressa. Niestety nie posiadamy żadnego opisu modelu danych, a w pierwszej wersji otrzymuję od klienta tylko zrzut bazy danych valhalla_arch.sql – wielkość 538M nie jest źle, zgodnie z definicją „duża baza zaczyna się wtedy, kiedy nie możesz jej w całości do ramu załadować” – ta baza nie jest duża.

Pierwsza analiza bazy polegała na przejrzeniu pliku SQL, na tym etapie potrzebuję mieć dostęp do danych, więc naturalnie trzeba je zaimportować. Pierwszym zgrzytem jest kodowanie. Baza jest sprzed kilku lat, więc jej główne kodowanie to latin2 – w efekcie pobierane z niej dane są zaśmiecone. Kasuję bazę i zakładam ją ponownie, tym razem uwzględniając kodowanie danych. Import i pierwsze selecty – dane są w porządku, choć nadal widzę krzaczki. Całe szczęście, tym razem to są krzaczki, których się spodziewam. MySQL od kilku wersji nie ma już kłopotów z przekodowywaniem znaków na dowolny inny zestaw, więc pozostawiam dane w latin2 i ustawiem tylko kodowanie klienta oraz wyjścia na utf-8 – to wystarcza, wszystkie dane widzę poprawnie, a ponieważ nie zamierzam danych wkładać, to nie martwię się innymi ustawieniami.

Zaczynam pracę od ponownej analizy bazy danych, tym razem skupiając się już na nazwach tabel i możliwych powiązaniach. Od klienta wiem, że wpisu posiadają kategorie oraz kilka rodzajów tagów. W trakcie tej analizy najważniejszym narzędziem pozostaje MySQL Workbench oraz spisywany schemat zależności.

Potem następuje kilka godzin żmudnego wybierania danych i ich łączenia. Próbne, krótkie eksporty oraz importy w celu wyeliminowania błędów lub uzupełnienia braków.

W międzyczasie dostaję od klienta paczkę z kodem serwisu – bardzo dobra wiadomość, że to też mamy, ponieważ stawiam sobie lokalną kopię serwisu i mogę sprawdzić czy przeniesione artykuły mają wszystkie dane oraz wszystkie komentarze. Zresztą komentarze to był ciekawy przypadek, bo w tym serwisie komentarze zostały rozwiązane bardzo sprytnie. Oprócz serwisu istniało obok forum, a komentarze były po prostu odpowiednio podpiętymi wątkami z forum. I choć samego forum nie przenosiłem, to część wątków, używanych w formie komentarzy jak najbardziej.

Korekta danych, powtarzana iteracyjnie, aż do uzyskania poprawnych wyników. Potem wystawienie danych testowych do akceptacji. Po akceptacji import. Ale import to nie jest proste słowo. Wpisy były podzielone (z grubsza) na 3 tabele – główne działy: teksty, nowości i recenzje.

Efekt finalny to 3 pliki xml (wxr) z danymi tych wpisów. Troszkę ciężkie, żeby wysyłać je przez www i importować za pomocą wtyczki WordPress Importer – to po prostu nie może się udać.

Ale od czego jest tryb CLI? Ten, teoretycznie zniesie „wszystko”, a na pewno o kilka rzędów wielkości więcej niż tryb „webowy”. Jednym z braków ograniczeń jest czas wykonywania takiego skryptu, który w zależności od ustawień, jest albo bardzo duży, albo nie ma limitu – domyślnie chyba nie ma. Sam import trwał oczywiście najmniej czasu ze wszystkich zadań.

A to efekt:

23 465 wpisów
107 911 komentarzy
21 955 obrazków

I można go obejrzeć tutaj: http://www.valhalla.pl/