Oxla

Mapowanie danych wspierane przez różne systemy baz danych

Proces migracji ogromnych ilości danych może być czasochłonny, skomplikowany, podatny na błędy i zazwyczaj wymaga nadzoru użytkownika. Stworzone przez nas migratory sprawiają, że cały proces staje się bardziej przyjazny dla użytkownika, umożliwiając skonfigurowanie ustawień migracji w pierwszych krokach, a następnie automatyczne przeprowadzenie procesu za Ciebie. 

Migracja różnych typów danych, od liczb czy ciągów tekstowych po bardziej skomplikowane, takie jak JSON, pochodzące z różnych systemów baz danych, wymaga dokładnej analizy przypadków brzegowych, które mogą powodować problemy. Nieobsługiwane typy danych lub różne zakresy wartości obsługiwane przez różne systemy baz danych to tylko niektóre z przykładów, z którymi migratory Oxla musiały sobie poradzić w sposób, który nie utraci wartości ani znaczenia danych.

Dane logów i metryk w zasięgu ręki

Każde narzędzie może napotkać przypadki, których nie przewidziano wcześniej, szczególnie w długoterminowych procesach, które mogą trwać dni, a w niektórych przypadkach nawet tygodnie. Migratory Oxla mają sposób, aby wspierać użytkownika w rozwiązywaniu tych problemów.  

Każda uruchomiona migracja zbiera logi i metryki na każdym etapie procesu, aby użytkownik mógł wykryć i zidentyfikować problemy z migracją danych. Są one zapisywane w plikach SQLite, zarówno po zakończeniu migracji, jak i w momencie, gdy zostanie ona zatrzymana przez system, więc żadne dane nie zostaną utracone, niezależnie od tego, jak duży jest proces.

Wsparcie dużych rozwiązań do przechowywania w chmurze – AWS, Google Storage, Azure Blob Storage

Oxla, jako rozproszona baza danych, działa dobrze w środowisku chmurowym. Przede wszystkim, trudno jest przechować ogromną ilość danych na własnym komputerze podczas migracji. Aby rozwiązać ten problem, migratory dobrze współpracują z rozwiązaniami do przechowywania w chmurze, takimi jak AWS S3, Google Storage i Azure Blob Storage. Migratory przechowują dane w wybranym magazynie chmurowym przez cały proces w oddzielnych ścieżkach dla każdej migracji, razem z logami i metrykami. W ten sposób, po zakończeniu procesu migracji, niezależnie od tego, czy zakończył się on niepowodzeniem, czy sukcesem, nadal mamy dostęp do artefaktów procesu – danych, logów i plików metrycznych.

Poprawa procesu migracji dzięki przetwarzaniu równoległemu i strumieniowemu

Przetwarzanie ogromnych ilości danych zajmuje czas, zasoby pamięci i generuje koszty. Aby zmniejszyć zasoby potrzebne do migracji, usprawniliśmy przetwarzanie danych poprzez wdrożenie przetwarzania równoległego i strumieniowego. Migratory przetwarzają kilka tabel lub plików jednocześnie, korzystając z wielu rdzeni na maszynie. Dodatkowo, używając strumieni do transferu danych do i z migratora, pamięć wymagana do całego procesu jest na najniższym poziomie, jaki może być.

Testowanie wydajności migratorów na Big Data

Testowanie aplikacji, która działa bezpośrednio z różnymi typami baz danych, nie jest łatwym zadaniem. Aby uczynić to bardziej zarządzalnym, przygotowaliśmy generator zbiorów danych, który generuje różne rodzaje danych w postaci plików CSV, które mogą być załadowane do wybranej bazy danych i użyte do testowania procesu migracji. Wybrani dostawcy baz danych, tacy jak Snowflake czy Clickhouse, oferują przykładowe zbiory danych, które również wykorzystaliśmy do testowania wydajności i jakości migratorów. Aby symulować rzeczywiste środowisko użytkownika z perspektywy API HTTP, opracowaliśmy Proof of Concept (POC) aplikacji internetowej, która przedstawia migratory jako aplikację SaaS do procesu migracji z wybranego źródła bazy danych do Oxla jako bazy docelowej.

Dystrybucja i dostępność

Dystrybucja i dostępność tego typu aplikacji nie są takie same jak w przypadku aplikacji webowych. Migratory mogą być używane jako samodzielne aplikacje CLI, które można uruchamiać w terminalu w środowisku Linux, macOS, Windows oraz jako usługi dostępne przez warstwę HTTP API. 

Każda baza danych powinna mieć własny migrator dostępny dla użytkowników. Aby osiągnąć obie formy dystrybucji, zbudowaliśmy aplikację, która działa w środowisku NodeJs i organizuje kod w pakiety. W ten sposób możemy zapakować każdy migrator jako aplikację z wbudowanym środowiskiem NodeJs oraz kodem migratora i dystrybuować go jako jeden plik wykonywalny binarny do użycia jako samodzielna aplikacja CLI. 

Dodatkowo, ten sam kod jest zorganizowany w moduły i pakiety dzięki PNPM Workspaces, a Nx może być używane podczas implementacji warstwy HTTP API bez potrzeby pisania czegokolwiek od podstaw lub utrzymywania oddzielnego kodu dla obu form dystrybucji. Co więcej, migratory są również dystrybuowane przy użyciu obrazów Docker z plikami binarnymi wewnątrz obrazu, dzięki czemu mogą być używane w izolowanym środowisku Docker w ten sam sposób, co aplikacja CLI. Wszystko odbywa się automatycznie dzięki skonfigurowanym akcjom Github, które działają jako rozwiązanie CI/CD wspierające procesy budowania, testowania i dostarczania.