Ładowanie Big Data? Aby uzyskać większą szybkość, sortowanie wstępne i ładowanie zbiorcze
Znalezienie większej szybkości podczas ładowania dużych zbiorów danych jest wyzwaniem w indeksach ETL, reorg i bardzo dużych baz danych (VLDB) wypełniać operacje. Jednym ze sposobów szybszego ładowania dużych zbiorów danych jest ich wstępne sortowanie, dzięki czemu baza danych nie musi być sortowana. IBM i inni dostawcy baz danych na komputerach mainframe udzielali takich porad od dziesięcioleci i nadal są one prawdziwe w przypadku relacyjnych baz danych używanych obecnie w systemie Unix i innych „otwartych systemach”, w tym Oracle, DB2, Sybase i SQL Server.
Testy porównawcze w tym obszarze pokazują poprawę w stosunku do ładunków nieposortowanych w zależności od objętości, ale dostawcy sortowania, tacy jak IRI, twierdzą, że wydajność ładowania poprawiła się od dwóch do dziesięciu razy. W raporcie TUSC Consulting „Benchmarking Index Impact on OLTP Load Rates and Online Database Block Size Rebuild in Oracle” sam test wstawiania 100 000 wierszy z pojedynczym indeksem wykazał, że wstępnie posortowane dane ładowały się o 58% szybciej i wymagały o 49% mniej miejsca:
- Ładowanie w posortowanej kolejności miało o 42% niższy wskaźnik podtrzymania liczby wierszy/sekundę ładowania
- Nieposortowane wstawki do indeksów wymuszają więcej pracy w wewnętrznej bazie danych (zarządzanie blokami i reorganizacja przestrzeni)
- W indeksach posortowanych według obciążenia współczynnik klastrowania będzie zbliżony do liczby bloków liści
- Kolejność ładowanych danych ma kluczowe znaczenie dla wydajności ładowania.
Wiele lat później, w rozdziale 13 swojego przewodnika „Expert Oracle Database 11g Administration”, Sam R. Alapati (Miro Consulting) zalecił wstępne sortowanie w połączeniu z bezpośrednim ładowaniem ścieżek jako najszybszy sposób zbiorczego ładowania danych Oracle (w porównaniu z insertami):
„ Ładowanie ze ścieżką bezpośrednią opcja nie używa instrukcji SQL INSERT do umieszczania danych w tabelach; raczej formatuje bloki danych Oracle i zapisuje je bezpośrednio w plikach bazy danych. Ten proces bezpośredniego zapisu eliminuje większość kosztów związanych z wykonywaniem instrukcji SQL w celu załadowania tabel. Ponieważ metoda ładowania ze ścieżką bezpośrednią nie rywalizuje o zasoby bazy danych, ładuje dane znacznie szybciej niż konwencjonalne ładowanie danych. W przypadku większych ładunków danych najlepsze są słowa metody ładowania ze ścieżką bezpośrednią i może to być jedyna realna metoda ładowania danych do tabel z tego prostego powodu, że konwencjonalne ładowanie może wymagać więcej czasu niż jest dostępne”.
Dla administratorów VLDB w dzisiejszych czasach jest to miejsce, w którym pojawia się CoSort, ponieważ:
„Oprócz oczywistych zalet krótszego czasu ładowania, bezpośrednie ładowanie pomaga również odbudować indeksy i wstępnie posortować dane tabeli.”
CoSort jest tradycyjnie używany w zewnętrznym sortowaniu wstępnym płaskiego pliku, który będzie importowany do obciążenia określającego „direct=true” i tę opcję:
„SORTED INDEXES:Parametr SORTED_INDEXES sygnalizuje SQL*Loaderowi, że dane są sortowane według określonego indeksu, co poprawia wydajność ładowania”.
Podobnie, dokumentacja Microsoft SQL Server określa sortowanie wstępne plików jako jedną z „Metod optymalizacji importu zbiorczego”:
Domyślnie operacja importu zbiorczego zakłada, że plik danych jest nieuporządkowany. Jeśli tabela ma indeks klastrowy, bcp Narzędzie, instrukcja BULK INSERT i funkcja OPENROWSET(BULK…) (Transact-SQL) umożliwiają określenie sposobu sortowania danych w pliku danych podczas operacji importu zbiorczego. Opcjonalne jest sortowanie danych w pliku danych w tej samej kolejności co tabela. Możesz jednak poprawić wydajność operacji importu zbiorczego, jeśli określisz taką samą kolejność pliku danych jak w tabeli.
Pole /KEY w skrypcie CoSort SortCL byłoby zazwyczaj najdłuższym kluczem indeksu (podstawowym) w tabeli, ale nie musi nim być. Według TUSC, dla podobnych kolumn:
- Mniej dłuższych indeksów jest lepszych niż więcej krótszych indeksów
- Kolumna wiodąca określa koszt ładowania indeksu
Zwróć też uwagę, że:
- Per Vertica i inne startery RDBMS, utrzymywanie kolumn w posortowanej kolejności optymalizuje wydajność zapytań. Nawet stara rada w przewodniku DEC po Rdb/VMS po konserwacji i wydajności bazy danych jest nadal aktualna:
„Posortuj wstępnie rekordy, które planujesz przechowywać w tabeli, według wartości klucza podstawowego przed załadowaniem ich do bazy danych. Po załadowaniu rekordów będą one fizycznie przylegać do siebie lub zgrupowane, dopóki w bazie danych nie zostaną zapisane dodatkowe rekordy. Utrzymanie takiego układu przynosi korzyści zapytaniom, które wybierają wiersze na podstawie zakresu wartości lub łączą wiele wierszy jednej tabeli z wierszami w tej samej tabeli”.
- Wstępne sortowanie danych w tabelach może również zaoszczędzić czas w widokach. Według „Oracle Database 10g:The Complete Reference” Kevina Loneya:
„Posortowanie danych w widoku może uprościć tworzenie aplikacji. Na przykład, jeśli kod przechodzi przez zestaw rekordów, ich wstępne sortowanie może uprościć przetwarzanie i sprawdzanie błędów. Podczas tworzenia aplikacji będziesz wiedział, że dane będą zawsze zwracane w uporządkowany sposób”.
- Pan. Alapati ostrzega administratorów baz danych o ograniczeniu bezpośredniego ładowania ścieżek:
„Uwaga:przy bezpośrednim ładowaniu nie można używać żadnych funkcji SQL. Jeśli potrzebujesz wykonać duże ładowanie danych, a także dane podczas ładowania, masz problem. Konwencjonalne ładowanie danych pozwala używać funkcji SQL do przekształcania danych, ale metoda jest bardzo powolna w porównaniu z ładowaniem bezpośrednim. Dlatego w przypadku dużych obciążeń danych możesz rozważyć użycie jednej z nowszych technik ładowania/transformacji, takich jak tabele zewnętrzne lub funkcje tabel”.
Jednak program SortCL firmy CoSort może przekształcić dane ładowania podczas wstępnego sortowania; tj. łącząc ten sam typ funkcji SQL w tym samym skrypcie zadania i przejściu we/wy, w tym:złączenia, agregacje, obliczenia krzyżowe, wyszukiwania, funkcje select/filter, substring i instring oraz wiele celów ponownego formatowania i niestandardowych raportów — w tej samej operacji wstępnego sortowania.
- Nowe narzędzie reorg offline w IRI Workbench (Eclipse GUI) wykorzystuje IRI FACT (Fast Extract) do szybkiego rozładowywania danych z tabeli przez OCI, używa CoSort do wstępnego sortowania według klucza podstawowego oraz zapisuje i uruchamia bezpośrednio SQL*Loader wczytuje ścieżki, aby zoptymalizować i połączyć każdy z tych kroków.
