O projekcie
mySugr to wiedeński startup, założony w 2012 roku. W czerwcu 2017 roku dołączył do rodziny Roche. W związku ze zintegrowaniem firm w 2018 roku grupa stanęła przed wieloma wyzwaniami systemowymi. Specjaliści z fireup.pro uzupełnili team dedykowany do ich efektywnego rozwiązania. Aplikacja mySugr to narzędzie zorientowane na cyfrowe rozwiązania zdrowotne, mające na celu usprawnienie życia osób cierpiących na cukrzycę. Oferuje edukację i wsparcie, aby codzienna rutyna związana z chorobą stała się prostsza. Jest to efektywny system do śledzenia i zarządzania cukrzycą, wykorzystujący wszelkie, kluczowe informacje zapisane na smartfonie, gotowe do użycia w każdej chwili.
Doświadczenie klienta
Czy kiedykolwiek widziałeś wyścig Formuły 1 lub film Disneya "Auta"? Byłeś pod wrażeniem, jak szybko potrafią zmieniać opony?
My zrobiliśmy coś podobnego! Ale lubimy wyzwania, więc zrobiliśmy to, gdy samochód wciąż był na torze wyścigowym — w ruchu!
To "my" to tak naprawdę bardzo mały zespół najbardziej utalentowanych ludzi, jakich kiedykolwiek spotkałem.
Karl Spies
Backend Developer w mySugr
Od wyzwania
Kluczowe wyzwania
Wspólna gałąź aplikacji z obsługą MySQL i PostgreSQL
Wspólna gałąź aplikacji z obsługą MySQL i PostgreSQL
Musieliśmy stawić czoła takim problemom jak fakt, iż MySQL swobodniej podchodzi do standardu SQL czy składni zapytania. Co więcej, domyślny i zalecany poziom izolacji transakcji jest inny dla obu systemów. PostgreSQL jest bardziej restrykcyjny i nie stara się myśleć za użytkownika, jak jest w przypadku MySQL.
PostgreSQL as the preferred system
PostgreSQL as the preferred system
Co przetestowaliśmy w najbardziej krytycznym przypadku: streamingu znacznej ilości danych. Wcześniej, dla użytkowników z dużą liczbą rekordów w bazie streaming danych nie działał prawidłowo. Postanowiliśmy zatem, że najlepszym rozwiązaniem będzie doprowadzenie kodu do postaci, która będzie poprawnie funkcjonować na obu, wspomnianych narzędziach.
Przewidywane korzyści procesu migracyjnego
Obniżenie całkowitych kosztów utrzymania docelowej aplikacji klienta
Elastyczność wynikająca z wirtualizacji systemów IT
Optymalizacja wykorzystania zasobów zastosowanego hardware'u
Zwiększenie wydajności systemu
Zwiększenie dostępności systemu
Zwększenie bezpieczeństwa danych
Przez rozwiązanie
Przez rozwiązanie
Weryfikacja
Teoretyczna weryfikacja koncepcji wykorzystania PostgreSQL oraz stworzenie proof of concept i wykonanie smoke testów.
- Stworzenie aplikacji, która uruchomi się zarówno z użyciem narzędzia PostgreSQL jak i MySQL.
Migracja
- Migracja schematu bazodanowego.
- Tworzenie tabel w PostgreSQL z odpowiednimi typami danych.
- Porównanie typów danych źródłowych z docelowymi.
Przenoszenie danych
- Przenoszenie danyach z proof of concept do rzeczywistej aplikacji
- Weryfikacja ryzyk związanych z różnicą między narzędziami PostgreSQL a MySQL
Proof of concept w AWS DMS
- Stworzenie infrastruktury dla migracji bazy deweloperskiej.
- Na podstawie punktu proof of concept w AWS DMS stworzenie migracji dla pozostałych środowisk.
Przełączenie środowisk deweloperskich
- 2 miesiące testów.
- Weryfikacja migracji na środowisku QA.
Faza główna
Możliwa do przeprowadzenia po pozytywnej weryfikacji i trwająca 2,5 tygodnia.
- Przełączenie QA.
- Przełączenie środowisk produkcyjnych i udostępnienie aplikacji klientowi.
Po sukces
Efekty technologiczne
Zmiana technologii – migracja z MySQL do PostgreSQL
Dostosowanie systemu do technologii stosowanej w grupie Roche.
Wdrożenie nowej wersji Amazon Aurora
Przejście na nowszą wersję bazy, oferującą lepszą wydajność i wsparcie.
Zabezpieczenie wsparcia systemowego
Uniknięcie ryzyka korzystania z niewspieranych komponentów po 2024 roku.
Uproszczony mechanizm przełączania baz danych
Możliwość przełączania poprzez zmianę jednego parametru w aplikacji.
Korzyści biznesowe
Ujednolicenie stacku technologicznego z Roche.
Znaczące obniżenie kosztów utrzymania aplikacji po wdrożeniu Aurory.
Dostarczenie spójnego i gotowego produktu w zakładanym czasie, zgodnego z wizją klienta.
Tech stack
Etap 1
Initial-load
Tworzymy kopię źródłowej bazy danych (snapshot), następnie importujemy dane z kopii do nowej bazy danych.
Etap 2
Migracja w trybie ciągłym CDC
Continuous data capture gromadzi wszystkie zmiany w danych bazy źródłowej, a następnie aplikuje je na bazie docelowej. Dzięki temu dane w obu bazach danych są identyczne.
Ryzyka baz danych mySugr i Roche
Ryzyko 1
Różnice w precyzji datetime
Typy baz danych w systemie źródłowym i docelowym, nie były takie same. Datetime w MySQL (mySugr) ma dokładność do 1s w przypadku PostgreSQL (Roche) wynosi ona mikrosekundę do 6 miejsca po przecinku. Z naszego punktu widzenia niezbędna okazała się weryfikacja czy przedstawione różnice nie będą miały znaczenia dla funkcjonalności aplikacji oraz zastosowanie zaokrąglenia danych do pełnej sekundy.
Ryzyko 2
Niezgodność w typach danych
Narzędzie PostgreSQL przy zwracaniu danych zmiennoprzecinkowych typu FLOAT double inaczej zaokrągla liczby z częścią ułamkową, niż MySQL. Mieliśmy więc do czynienia z niezgodnością w typach danych.
Ryzyko 3
Różnice w obsłudze wielkości znaków
MySQL i PostgreSQL prezentują odmienne podejście do wielkości znaków. MySQL domyślnie porównuje stringi, ignorując wielkość znaków. Niezbędnym zatem okazało się zastosowanie ręcznego wyszukiwania w tekście oraz ujednolicenie narzędzi, by aplikacja z oboma typami baz danych zachowywała się identycznie.
Ryzyko 4
Konwersja i interpretacja danych
Pojawiły się również kwestie związane z konwersją oraz interpretacją danych (na poziomie bajtów) przez różne systemy baz danych. Team zatem musiał znaleźć sposób na upewnienie się, że dane w obu przypadkach są takie same.
Twoja sukces to nasz sukces!
Zobacz, jak możemy wspólnie zbudować technologiczną przewagę dla Twojej firmy
Mamy zespół, który naprawdę zna się na rzeczy — pomożemy Ci znaleźć rozwiązanie, które działa.
