Indlæser Big Data? For mere hastighed, Pre-Sort og Bulk Load
At finde mere hastighed ved indlæsning af big data er en udfordring i ETL, reorg og meget stor database (VLDB) indeks udfylde operationer. En måde at indlæse big data hurtigere på er ved at forhåndssortere dem, så databasen ikke skal sortere. IBM og andre mainframe-databaseudbydere har givet det råd i årtier, og det gælder stadig i relationelle databaser, der bruges på Unix og andre "åbne systemer" i dag, inklusive Oracle, DB2, Sybase og SQL Server.
Benchmarks på dette område viser forbedringer i forhold til usorterede belastninger afhængigt af volumen, men sorteringsleverandører som IRI hævder, at belastningsydelsen er blevet forbedret mellem to og ti gange. I TUSC Consulting-rapporten "Benchmarking Index Impact on OLTP Load Rates and Online Database Block Size Rebuild in Oracle" viste en 100.000 række enkelt-indeksindsætningstest alene, at forudsorterede data blev indlæst 58 % hurtigere og krævede 49 % mindre plads:
- Indlæsning i sorteret rækkefølge havde en 42 % lavere vedvarende rækker/sekund indlæsningshastighed
- Usorterede indsættelser i indekser tvinger mere internt databasearbejde (blokstyring og omorganisering af plads) til at blive udført
- I belastningssorterede indekser vil klyngefaktoren være tæt på antallet af bladblokke
- Rækkefølgen af indlæste data er afgørende for indlæsningsydelsen.
Mange år senere, i kapitel 13 i sin "Expert Oracle Database 11g Administration"-vejledning, anbefalede Sam R. Alapati (Miro Consulting) forudsortering i forbindelse med direkte vejbelastninger som den hurtigste måde at bulkloade Oracle på (versus skær):
“Den direkte sti-indlæsning option bruger ikke SQL INSERT-sætningen til at indsætte data i tabeller; snarere formaterer den Oracle-datablokke og skriver dem direkte til databasefilerne. Denne direkte skrivningsproces eliminerer meget af de overhead, der er involveret i at udføre SQL-sætninger for at indlæse tabeller. Da indlæsningsmetoden med direkte sti ikke kæmper om databaseressourcer, vil den indlæse data meget hurtigere end en konventionel dataindlæsning. For større databelastninger er den direkte sti-indlæsningsmetode bedst, og det kan være den eneste brugbare metode til at indlæse data i tabeller af den simple grund, at en konventionel belastning kan kræve mere tid, end der er tilgængelig."
For administratorer af VLDB'er i dag er det her CoSort kommer ind, da:
"Udover de åbenlyse fordele ved en kortere indlæsningstid hjælper direkte indlæsning dig også med at genopbygge indekser og forudsortere tabeldata."
CoSort bruges traditionelt i den eksterne forhåndssortering af en flad fil, der vil være importen til en belastning, der angiver "direct=true" og denne mulighed:
"SORTED INDEXES:SORTED_INDEXES-parameteren signalerer SQL*Loader, at data er sorteret på et specificeret indeks, hvilket forbedrer indlæsningsydelsen."
På samme måde specificerer Microsoft SQL Server-dokumentationen filforsortering som en af "Metoder til optimering af masseimport":
Som standard forudsætter en masseimporthandling, at en datafil er uordnet. Hvis tabellen har et klynget indeks, er bcp utility, BULK INSERT-sætning og OPENROWSET(BULK...)-funktionen (Transact-SQL) giver dig mulighed for at angive, hvordan data i datafilen sorteres under en masseimport. Det er valgfrit, at data i datafilen sorteres i samme rækkefølge som tabellen. Du kan dog forbedre ydeevnen af masseimporthandlingen, hvis du angiver den samme rækkefølge for datafilen som tabellen.
/KEY-feltet i et CoSort SortCL-script vil typisk være den længste (primære) indeksnøgle i tabellen, men det behøver det ikke at være. Ifølge TUSC, for lignende kolonner:
- Færre længere indekser er at foretrække frem for flere kortere indekser
- Leading column driver indeksindlæsningsomkostningerne
Bemærk også at:
- Per Vertica og andre RDBMS-primere optimerer vedligeholdelse af kolonner i sorterede rækkefølge forespørgselsydeevnen. Selv det gamle råd i DEC's Rdb/VMS-vejledning til databasevedligeholdelse og ydeevne er stadig sandt:
"Sorter de poster, du planlægger at gemme i en tabel, efter primærnøgleværdi, før du indlæser dem i databasen. Når posterne er indlæst, vil de være fysisk ved siden af hinanden, eller grupperet, indtil yderligere poster er gemt i databasen. Vedligeholdelse af dette arrangement gavner forespørgsler, der vælger rækker baseret på en række værdier, eller som forbinder mange rækker i en tabel med rækker i den samme tabel."
- Forudsortering af data i tabeller kan også spare tid i visninger. Ifølge "Oracle Database 10g:The Complete Reference" af Kevin Loney:
"At få dataene sorteret i visningen kan forenkle din applikationsudvikling. Hvis din kode f.eks. går gennem et sæt poster, kan det gøre din behandling og fejlkontrol lettere at have disse poster forudsorteret. I din applikationsudvikling vil du vide, at dataene altid vil blive returneret til dig på en ordnet måde."
- Hr. Alapati advarer DBA'er om en begrænsning af direkte stibelastninger:
“Bemærk:I en direkte belastning kan du ikke bruge nogen SQL-funktioner. Hvis du skal udføre en stor dataindlæsning og også transformere dataene under indlæsningen, har du et problem. Den konventionelle databelastning vil lade dig bruge SQL-funktioner til at transformere data, men metoden er meget langsom sammenlignet med den direkte belastning. For store databelastninger kan du derfor overveje at bruge en af de nyere indlæsnings-/transformationsteknikker, såsom eksterne tabeller eller tabelfunktioner."
CoSorts SortCL-program kan dog transformere indlæsningsdataene under forudsortering; ved at kombinere den samme type SQL-funktioner i det samme jobscript og I/O-pass, herunder:joinforbindelser, aggregeringer, krydsberegninger, opslag, udvælgelse/filter, understrengs- og instringsfunktioner og masser af omformatering og tilpassede rapporteringsmål — i den samme præ-sorteringsoperation.
- Det nye offline reorg-værktøj i IRI Workbench (Eclipse GUI) bruger IRI FACT (Fast Extract) til hurtigt at udlæse tabeldata via OCI, bruger CoSort til at forhåndssortere på primærnøglen og skriver og kører SQL*Loader direkte sti indlæses for at optimere og kombinere hvert af disse trin.