jak ładować dane szybciej dzięki serwerowi talend i sql

Question

Używam Talend do ładowania danych do bazy danych serwera sql.

Wygląda na to, że najsłabszym punktem mojej pracy nie jest przetwarzanie danych, ale efektywne obciążenie w mojej bazie danych, które nie jest szybsze niż 17 wierszy/sek.

Śmieszne jest to, że mogę uruchomić 5 zadań w tym samym czasie, a wszystkie będą ładowane z szybkością 17 rzutów/sek.

Co może wyjaśnić tę powolność i jak poprawić prędkość?

Dzięki

Nowe informacje:

Prędkość transferu między moim pulpicie a serwerem jest o 1MByte

Moja praca zobowiązuje każde 10 000

Używam serwera sql 2008 R2

An d schematu używam do moich zadań jest tak:

Answer 1

Znalazłem gdzie ten problem wydajność przyjść formularza.

Wykonuję INSERT OR UPDATE, jeśli zastąpię go prostym INSERT, prędkość wzrasta do 4000 wierszy/s.

Czy wydaje się, że jest to dopuszczalne tempo?

W każdym razie potrzebuję mojego INSERT OR UPDATE, więc chyba utknąłem.

Answer 2

Baza danych INSERT OR UPDATE metody są niewiarygodnie kosztowne, ponieważ baza danych nie może grupować wszystkich zatwierdzeń do zrobienia wszystkiego naraz i musi wykonywać je wiersz po wierszu (transakcje ACID wymuszają to, ponieważ jeśli próbują wykonać wstawkę, a następnie zawiodą, wszystkie inne zapisy w tym zatwierdzeniu również zawiedzie).

Zamiast tego w przypadku dużych operacji zbiorczych zawsze najlepiej jest ustalić, czy rekord zostanie wstawiony lub zaktualizowany przed przekazaniem zatwierdzenia do bazy danych, a następnie wysłaniem 2 transakcji do bazy danych.

Typowe zadanie, które wymagało tej funkcji, mogłoby zmontować dane, które mają być INSERT OR UPDATEd, a następnie przeszukać tabelę bazy danych dla istniejących kluczy podstawowych. Jeśli klucz podstawowy już istnieje, możesz wysłać go jako UPDATE, w przeciwnym razie jest to INSERT. Logika do tego może być łatwo wykonana w komponencie tMap.

W tej pracy mamy pewne dane, które chcemy INSERT OR UPDATE do tabeli bazy danych, która zawiera pewne istniejące wcześniej dane:

I chcemy dodać następujące dane aby go:

Zadanie działa poprzez wrzucenie nowych danych do komponentu tHashOutput, dzięki czemu można go używać wielokrotnie w tym samym zadaniu (po prostu umieszcza je w pamięci lub w dużych instancjach można je buforować na dysk).

Po tej jednej partii danych odczytuje się komponent tHashInput i bezpośrednio do tMap. Innym tHashInput komponent jest wykorzystywany do uruchamiania parametryzowany zapytanie do stołu:

można znaleźć this guide to Talend and parameterised queries pożytecznego. Odtąd zwrócone rekordy (czyli tylko te wewnątrz bazy danych) są używane jako odnośniki do tMap.

ta jest konfigurowane jako INNER JOIN znaleźć zapisy, które muszą być UPDATED z odrzuceń z INNER JOIN być włożona:

Wyjścia te następnie tylko przepływ oddzielić tMySQLOutput elementom UPDATE lub INSERT w razie potrzeby. I w końcu, gdy główne subjob jest kompletne, my commit zmian.

Answer 3

Na podstawie Twojej notatki wkładki są o rząd wielkości szybsze niż aktualizacje (4000 vs 17/s) - Wygląda na to, że musisz spojrzeć na swoje indeksy DB. Dodanie indeksu zgodnego z parametrami aktualizacji może znacznie przyspieszyć aktualizacje. Oczywiście ten indeks może spowolnić nieco wstawianie.

Możesz także sprawdzić plan wykonania kwerendy dla swojego zapytania o aktualizację, aby sprawdzić, czy używa on jakichkolwiek indeksów. How do I obtain a Query Execution Plan?

Answer 4

Powinieneś wykonać stół pomostowy, w którym wstawiasz wiersze.

Na podstawie tej tabeli pomostowej wykonywane jest zapytanie DELETE z t * SQLrow.

DELETE FROM target_table 
WHERE target_table.id IN (SELECT id FROM staging_table); 

Tak więc wiersze, które chcesz zaktualizować, już nie istnieją.

INSERT INTO target_table 
SELECT * FROM staging_table; 

Spowoduje to przeniesienie wszystkich nowych/zmodyfikowanych wierszy.

Answer 5

Myślę, że odpowiedź @ydaetskcoR jest idealna na teorycznym punkcie widzenia (dzielenie wierszy, które wymagają wstawiania od tych do Aktualizacji) i daje działające rozwiązanie ETL przydatne dla małego zestawu danych (kilka tysięcy wierszy).

Wykonywanie wyszukiwania, aby móc zdecydować, czy wiersz musi zostać zaktualizowany, jest kosztowne w ETL, ponieważ wszystkie dane przechodzą tam iz powrotem między urządzeniem Talend a serwerem DB.

Po przejściu setek tysięcy lub nawet milionów rekordów musisz przejść z ETL do ELT: po prostu wczytujesz swoje dane do tabeli tymczasowej (zgodnie z propozycją z @Balazs Gunics), a następnie używasz SQL do manipulować nim.

W tym przypadku po wczytaniu danych (tylko WSTAW = szybka, jeszcze szybciej przy użyciu komponentów OBCIĄŻENIE BULKOWE) wyda się POŁĄCZENIE ZEWNĘTRZNE między tabelą tymczasową a tabelą docelową, aby podzielić wiersze, które już tam są (potrzeba aktualizacji) i inni.

To zapytanie daje wiersze musisz wstawić:

SELECT staging.* FROM staging 
LEFT OUTER JOIN destination ON (destination.PK = staging.PK) 
WHERE destination.PK IS NULL 

Ten drugi wiersze musisz aktualizować:

SELECT staging.* FROM staging 
LEFT OUTER JOIN destination ON (destination.PK = staging.PK) 
WHERE destination.PK IS NOT NULL 

To będzie rzędy wielkości szybciej niż ETL, ALE będziesz musiał użyć SQL do operowania na swoich danych, podczas gdy w ETL możesz używać Javy, ponieważ WSZYSTKIE dane są przesyłane do serwera Talend, więc często pierwszy krok na lokalnym komputerze jest wstępny do przetworzenia danych w java (aby wyczyścić i zweryfikować), a następnie uruchom go w DB, gdzie używasz łączyć, aby go załadować właściwą drogę.

Oto zrzuty ekranowe ELT JOB.

Answer 6

miałem te same dane ładowanie problem w serwerze DB2. Również ustawiłem zatwierdzenie na 10000, ale gdy wybrałem opcję wsadową (na tym samym ekranie opcji komponentu) wydajność znacznie się poprawiła. Kiedy przeniosłem commit i wsad do 20000, zadanie trwało od 5 godzin do poniżej 2 minut.