Migracja złego systemu do naszego obecnego systemu z tonami danych

Question

Odziedziczyłem system, gdy moja firma kupiła inną firmę. Ten system jest połączeniem LAMP i .NET.

1. 1 Serwer Windows uruchomiony asp.net, który kontroluje poprawności osób trzecich używany tylko do API i usługa - (nazwijmy to Win) serwery
2. 8 lampy (internetowe, raporty, cron, repozytoria itp ...) - (nazwijmy go NEW)

Nasze obecne środowisko:

14 serwery lampy (www, poczta, repozytoria, etc ...) - (nazwijmy go prąd)

gO od nowości jest NOWY kod jest dość straigt foward. Kilka milionów linii kodu (większość z nich to apis, trzecia strona) i mogę przekonwertować go na system CURRENT. NEW i CURRENT wykorzystują oba centra, które ułatwią tranzycję, z wyjątkiem serwera Windows, którego nie mam pojęcia, co teraz zrobić.

Teraz złe wieści. NOWY systemowy schemat bazy danych nie jest wcale dobry. Nie jest znormalizowany, a zapytania są powolne (kwerendy bazy danych i kod również). Moim pierwszym pomysłem jest przeprojektowanie ich do bardziej znormalizowanej struktury, która pasuje do kodu CURRENT, ale nie działa. Tabele z systemu NEW są gigantyczne. Nowy system ma 7 baz danych, ponad 10000 tabel, najmniejsze tabele mają ponad 100 tys. Wierszy, a niektóre tabele mają ponad 500 milionów wierszy. Jedna z baz danych ma większość tabel z ponad 25 milionami wierszy.

Czy migracja jest bezpieczna, czy powinienem kontynuować działanie? Jeśli powinienem przeprowadzić migrację, chcę się dowiedzieć, jakie będzie najbezpieczniejsze rozwiązanie w celu migracji systemu Windows i NOWEGO do mojego systemu CURRENT?

Answer 1

Przede wszystkim, przenoszenie + nowy system WIN do obecnego systemu będzie wymagało czasu. więc musisz upewnić się, że po rozpoczęciu migracji/konwersji wszystkiego, wiesz dokąd zmierzasz. Migrowanie może nie być łatwym zadaniem i możesz napotkać problemy, o których nigdy nie pomyślałeś po rozpoczęciu procesu.

Twój pomysł na migrację NOWEGO systemu ma swoje wady i zalety i musisz upewnić się, że wszystko idzie gładko, aby uzyskać dobry i niezawodny produkt na końcu.

Plusy:

• tylko jeden system obsługi: nie chcesz, aby utrzymać 3 systemy;
• jeden kod/środowisko bazy danych: PHP vs ASP.NET i MSSQL vs MySQL;
• scentralizowany kod/baza danych;
• jeden standard kodowania (kod i baza danych);
• zapisać/sprzedać equiments (będzie migrować kod do serwerów 14, może nie trzeba drugi 9 (WIN + nowa), więc można sprzedać lub zachować je dla następnych projektach)

minusy:

• większe ryzyko (Crash, niezgodność, nieznana cecha trzeba zrozumieć, etc ..);
• tańsze niż migracji lub ponownego projektowania wszystkiego
• ryzyko niepowodzenia jest niższa niż migracji (skoro już wiesz zarówno system działa)
• planowanie, kontrola, realizacja, zapewnienie jakości: bardzo źle, jeśli jeden z nich nie uda;
• drogie: migracja może być droga w czasie i pieniądzach;

To jest duża baza danych, zmiana/optymalizacja zajmie znaczące inwestycje w godzinach pracy. To nie jest coś, co możesz łatwo zrobić w kilka godzin. Może to potrwać kilka tygodni, może miesięcy, aby pomyślnie przenieść dane do systemu CURRENT bez błędów. Jeśli możesz, możesz zacząć od migracji wspólnych lub podobieństw z obu schematów bazy danych, takich jak klienci lub produkty. W ten sposób importujesz dane, które system CURRENT może uruchomić bez błędów, a także Twój kod rozpozna. Użytkownicy systemu CURRENT mogą od razu zacząć zarządzać tymi przedmiotami/dokumentami bez problemu. Od nowych rekordów, których system CURRENT nie rozpoznaje, możesz po prostu przeprojektować te tabele i zmigrować je do systemu CURRENT (następnie zaktualizować bieżący kod).

Jeśli chodzi o migrację kodu, jeśli kod z systemu NEW jest wystarczająco dobry i zgodny z normą, można go zachować. Pozwoli to zaoszczędzić czas potrzebny na rozwój, wystarczy zaktualizować połączenia zapytań i serwerów. Z drugiej strony, jeśli jest to kod spaghetti, musisz zrozumieć, co robi kod. Może to również wymagać znacznych inwestycji w godziny pracy. Mogę tutaj polecić, aby to ujednolicić i zorganizować swój kod w taki sam sposób, jak zorganizujesz go na bieżącym. Możesz scentralizować swój kod w jednym wspólnym folderze, używając wspólnej struktury plików i folderów. Możesz umieścić wszystkie swoje wspólne biblioteki, strony trzecie itd., Więc kiedy wywołasz CURRENT i NEW, załadujesz tę samą klasę PHP. Ułatwi to przejście z systemu NOWOŚĆ do CURRENT. W ten sposób znasz wszystkie wymagane pliki w tym samym miejscu i bardzo łatwe w utrzymaniu. Zwłaszcza jeśli twój kod wymaga wymaganych plików, które wymagają plików. Jeśli kodujesz wszystko wokół serwerów, możesz utworzyć NFS, jeśli podoba Ci się ten pomysł.

Teraz mogę zasugerować rozpoczęcie od Parallel Adoption. W ten sposób upewnisz się, że wszystkie systemy działają prawidłowo i są zdrowe. Następnie wolno migruj dane/kod do systemu CURRENT, aż wszystko zostanie ukończone. To nie będzie łatwe i musisz najpierw określić, która część systemów NEW + WIN musisz migrować. Moją rekomendacją będzie migracja systemu WIN. Ponieważ jest to niezależne od systemów CURRENT i NEW, jeśli wyświetlasz tę samą wydajność, powinieneś być w porządku. Wyszukaj open source lub podobne sprawdzenia poprawności w PHP lub jeśli nie możesz ich znaleźć, skompiluj je.W ten sposób ten system WIN można łatwo przenieść do obecnej struktury organizacyjnej i standardów kodowania. Przeprowadzanie testów i zapewnianie jakości będzie łatwe i można je wykonać bardzo szybko.

Po przeprowadzeniu migracji WIN należy określić, co należy najpierw przekazać do systemu CURRENT. Na przykład, jeśli system NEW i CURRENT ma "klientów", zebrać wszystkie informacje z systemu NEW i przenieść je do systemu CURRENT przy użyciu skryptu (ręcznie lub skryptowo). Następnie można migrować elementy klientów, takie jak produkty, wyciągi z rachunków lub inne rekordy powiązane z tymi klientami). Powtarzaj te kroki, aż wszystkie dane zostaną zmigrowane. W ten sposób nie trzeba przeprojektowywać żadnych tabel ani zmieniać kodów z systemu NEW, wszystko jest zapisywane w systemie CURRENT i wszystko działa poprawnie.

Nie polecam big bang adoption w tej sprawie.

Answer 2

Konieczna migracja nie jest tak naprawdę twoją decyzją, ale bardziej jest decyzją szefa.

Sposób, w jaki sposób to zależy od ilości danych, które należy wykonać. Oczywiście zalecałbym pracę z danymi z SQL do SQL za pomocą instrukcji między bazami danych, ale nie zawsze jest to wykonalne.

Pierwszy powód jest taki, że może zajść potrzeba przekształcenia naprawdę złożonych danych w inną formę i nie można tego zrobić przy użyciu czystego kodu SQL.

Po drugie, jeśli kodowanie skryptu transferu w PHP lub jakimkolwiek innym języku wymagałoby tyle samo wysiłku, niż wykonanie go w czystym SQL, lepiej jest zrobić to w PHP, żeby mieć coś do zmiany jesteś pewien, że będzie to możliwe i nie utkniesz w tym, że jesteś w SQL i musisz przekodować wszystko.

Ogólnie rzecz biorąc, masz do zrobienia ogromną analizę, aby zrozumieć wszystkie dane, z którymi masz do czynienia i zaplanować transfert. Biorąc pod uwagę liczbę stołów i rzędów, o których mówisz, masz przed sobą piekielną wycieczkę, myślę, że tylenol będzie twoim najlepszym przyjacielem.

Powodzenia