Import danych - niestandardowy

System YetiForce posiada wbudowane narzędzia importu i eksportu danych. W większości przypadków, narzędzia takie są wystarczające, jednakże w przypadku importu dużych baz zaleca się przygotowanie własnego rozwiązania, które będzie dane importować, a nad którym będziemy posiadać pełną kontrolę. Jeżeli mówimy o dużych bazach, to mamy na myśli bazy, które zawierają co najmniej kilkadziesiąt tysięcy rekordów.

Zbiór podstawowych porad

  1. Przygotuj środowisko serwerowe
  2. Planuj / Testuj / Weryfikuj
  3. Nie używaj wbudowanego importu
  4. Przewaga dedykowanego skryptu nad wbudowanym importem
  5. Optymalizacja
  6. Efekt końcowy

1. Przygotuj środowisko serwerowe

Większość serwerów produkcyjnych a tym bardziej hostingi są skonfigurowane tak, aby działały stabilnie, a więc ich konfiguracja jest domyślnie "bezpieczna". Jeżeli jednak import musi się wykonać szybko, musisz odejść od bezpiecznych parametrów i skonfigurować serwer tak, aby import trwał nieprzerwanie aż do momentu jego zakończenia. Jeżeli importujesz dużą ilość danych, to zawsze napotkasz problemy związane z czasem/pamięcią/wydajnością. Błędy mogą być różne, związane z czasem wykonywania, niewystarczającą konfiguracją, włączonymi mechanizmami, które powinny być wyłączone np. rejestrowanie logów serwera, replikacja danych, replikacja sprzętowa itd.  Jeżeli nie wiesz jakie parametry należy zwiększyć, to podczas testowania skryptu serwer niejednokrotnie wskaże z jakich przyczyn przerwał działanie skryptu, należy wówczas zwiększyć te parametry, które wskazał serwer.

2. Planuj / Testuj / Weryfikuj

Import dużej bazy sprawia wiele problemów, przynajmniej na początku drogi. Głównym problemem jest czas i przygotowanie sobie środowiska pracy. Należy pamiętać, że import wykonuje się wielokrotnie [czasem nawet kilkadziesiąt razy], a więc powinniśmy posiadać tak przygotowane środowisko, że w prosty sposób możemy usunąć poprzedni import i rozpocząć nowy a przede wszystkim sprawdzić jego poprawność [np. porównując ilość danych].

3. Nie używaj wbudowanego importu

Dla wielu osób nietechnicznych, opcja importu danych wbudowanymi narzędziami jest jedyną dostępną opcją. Niestety przy dużych bazach danych odradzamy z korzystania z tego narzędzia. Nie wynika to z niedoskonałości samej aplikacji, lecz tego, że niestandardowe importy wymagają niestandardowych narzędzi i niestandardowego podejścia. Przyczyny dla których warto stworzyć dedykowane rozwiązanie dla konkretnego importu, zostały opisane w punktach poniżej. 

4. Przewaga dedykowanego skryptu nad wbudowanym importem

4.1 Prędkość działania

Wbudowany mechanizm importu uruchamia wiele zadań pobocznych tj. workflows, handlers itd. Zadania poboczne powodują, że sam import spowalnia w sposób znaczący. Importowanie rekordów narzędziem wbudowanym może być nawet 100x wolniejsze od dedykowanego skryptu, na ten fakt przekłada się wiele czynników, należy jednak pamiętać, że sam skrypt dedykowany należy uzupełnić o mechanizmy, które są realizowane domyślnie w workflow czy też handlerach [na przykład: aktualizacja nazw {labels} po których się wyszukuje jest wykonywana każdorazowo na handlerze, a najlepiej ją wykonać raz po zakończeniu importu].

4.2 Pełna kontrola

Gdy tworzysz własny skrypt, masz pełną kontrolę nad includowanymi bibliotekami, zapytaniami, metodą importu i innymi elementami, które w sposób znaczący wpływają na prędkość działania. Pełna kontrola okaże się bardzo przydatna gdy:
  • będziesz szukał "wąskiego gardła" - gdy samo tworzenie rekordu trwa zbyt długo, możesz rejestrować czas pomiędzy wykonywanymi metodami, aby określić co zajmuje najwięcej czasu i móc wykonać odpowiednią optymalizacje,
  • będziesz chciał poprawić niewielką część danych - w przypadku gdy import się powiedzie, a w między czasie znajdzie się małą niedoskonałość, to mając własny dobrze napisany skrypt, możemy uaktualniać niewielkie fragmenty danych, w przypadku zwykłego importu jest to niemożliwe,
  • będziesz potrzebował określić warunki importu - gdy importujesz dane złożone [np. wartość w polu jest zależna od kilku elementów], to należy w czasie rzeczywistym weryfikować elementy i ustawiać odpowiednią wartość, w przypadku importu wbudowanego, dane są wprowadzane w taki sposób w jaki został określony przed importem [np. w pliku tekstowym jest ustawiony odpowiedni status, a nie jest on sprawdzany dynamicznie]. 

4.3 Elastyczność

Najważniejszą zaletą własnego skryptu jest jego elastyczność, dobrym przykładem takiej elastyczności jest pobieranie danych w czasie rzeczywistym z kopii systemu produkcyjnego, z którego dane importujemy. Gdy korzystamy z wbudowanego mechanizmu, dane muszą być w sposób odpowiedni przygotowane wcześniej i wyeksportowane do plików, w przypadku własnego skryptu nic nie trzeba eksportować, system sam pobierze najnowsze dane i zacznie je importować. 

5. Optymalizacja

Gdy importujesz duże ilości danych, to każdy najmniejszy element jest istotny, poniżej kilka ważnych zagadnień na które należy zwrócić uwagę: 
  1. Baza danych
    • Czy ustawiłeś indeksy dla wszystkich kombinacji warunków, po których wyszukujesz dane?
    • Czy w odpowiedni sposób budujesz zapytania do bazy danych? [gdy optymalizujesz zapytania, które trwają zbyt długo, często znajdujesz lepsze rozwiązanie].
  2. Skrypt
    • Czy importujesz dane w odpowiedniej kolejności?
    • Czy uruchamiasz skrypt wielokrotnie aby wykorzystać całe zasoby serwera? [skrypt musi być odpowiednio zbudowany, aby nie powodowało to duplikatów].
  3. Serwer
    • Czy wiesz co stanowi "wąskie gardło" dla serwera i w jaki sposób to zmienić?
    • Czy serwer został zoptymalizowany [Apache, PHP, MySQL oraz Dyski/Procesor/Pamięć]?

6. Efekt końcowy

Dobrze przygotowany skrypt jest wstanie importować 100-200 rekordów na sekundę, czyli w przeciągu jednej godziny powinien nam zaimportować 360.000 - 720.000 rekordów [mam na myśli tu skrypt, który wyszukuje/pobiera dane z Systemu A i wyszukuje/dodaje dane do systemu B].
  • poniedziałek, 07 sierpień 2017