Laddar Big Data? För högre hastighet, försortering och bulkbelastning
Att hitta snabbare när du laddar big data är en utmaning i ETL, reorg och VLDB-index (Very Large Database) befolka verksamheter. Ett sätt att ladda big data snabbare är att försortera den, så att databasen inte behöver sortera. IBM och andra stordatordatabasleverantörer har gett det rådet i årtionden, och det är fortfarande sant i relationsdatabaser som används på Unix och andra "öppna system" idag, inklusive Oracle, DB2, Sybase och SQL Server.
Benchmarks inom detta område visar förbättringar jämfört med osorterade laster beroende på volym, men sorteringsleverantörer som IRI hävdar att lastprestandan har förbättrats mellan två och tio gånger. I TUSC Consulting-rapporten "Benchmarking Index Impact on OLTP Load Rates and Online Database Block Size Rebuild in Oracle", visade enbart ett 100 000 rader enindexinsättningstest att försorterad data laddades 58 % snabbare och krävde 49 % mindre utrymme:
- Inläsning i sorterad ordning hade en 42 % lägre laddningshastighet för rader/sekund
- Osorterade inlägg i index tvingar fram mer internt databasarbete (blockhantering och omorganisation av utrymme)
- I lastsorterade index kommer klustringsfaktorn att vara nära antalet bladblock
- Orden på inlästa data är avgörande för laddningsprestanda.
Många år senare, i kapitel 13 i guiden "Expert Oracle Database 11g Administration", rekommenderade Sam R. Alapati (Miro Consulting) försortering i samband med direkta väglaster som det snabbaste sättet att bulklasta Oracle (versus insatser):
“Dendirekta sökvägen laddas option använder inte SQL INSERT-satsen för att lägga in data i tabeller; snarare formaterar den Oracle-datablock och skriver dem direkt till databasfilerna. Denna direktskrivningsprocess eliminerar mycket av omkostnaderna som är involverade i exekvering av SQL-satser för att ladda tabeller. Eftersom den direkta sökvägsladdningsmetoden inte tävlar om databasresurser, kommer den att ladda data mycket snabbare än en konventionell dataladdning. För större databelastningar, ordnas laddningsmetoden för direktväg bäst, och det kan vara den enda genomförbara metoden att ladda data i tabeller av den enkla anledningen att en konventionell belastning kan kräva mer tid än vad som är tillgängligt."
För administratörer av VLDBs idag är det här CoSort kommer in, eftersom:
"Förutom de uppenbara fördelarna med en kortare laddningstid, hjälper direktladdning dig också att bygga om index och försortera tabelldata."
CoSort används traditionellt i den externa försorteringen av en platt fil som kommer att importeras till en laddning som anger "direct=true" och detta alternativ:
“SORTED INDEXES:Parametern SORTED_INDEXES signalerar SQL*Loader att data sorteras på ett specificerat index, vilket förbättrar laddningsprestanda.”
På liknande sätt specificerar Microsoft SQL Server-dokumentationen filförsortering som en av "Metoder för att optimera massimport":
Som standard förutsätter en massimportoperation att en datafil är oordnad. Om tabellen har ett klustrat index visas bcp verktyget, BULK INSERT-satsen och OPENROWSET(BULK...)-funktionen (Transact-SQL) gör det möjligt för dig att ange hur data i datafilen sorteras under en massimportoperation. Det är valfritt att data i datafilen sorteras i samma ordning som tabellen. Du kan dock förbättra prestandan för massimporten om du anger samma ordning för datafilen som tabellen.
/KEY-fältet i ett CoSort SortCL-skript skulle vanligtvis vara den längsta indexnyckeln (primär) i tabellen, men det behöver inte vara det. Enligt TUSC, för liknande kolumner:
- Färre längre index är att föredra framför fler kortare index
- Ledande kolumn driver indexladdningskostnaden
Observera också att:
- Per Vertica och andra RDBMS-primrar optimerar frågeprestanda att underhålla kolumner i sorterade ordningsföljder. Till och med det gamla rådet i DEC:s Rdb/VMS Guide to Database Maintenance and Performance är fortfarande sant:
"Sortera i förväg de poster du planerar att lagra i en tabell efter primärnyckelvärde innan du laddar in dem i databasen. När posterna laddas kommer de att vara fysiskt intill varandra, eller klustrade, tills ytterligare poster lagras i databasen. Att bibehålla detta arrangemang gynnar frågor som väljer rader baserat på en rad värden eller som sammanfogar många rader i en tabell med rader i samma tabell.”
- Att försortera data i tabeller kan också spara tid i vyer. Enligt "Oracle Database 10g:The Complete Reference" av Kevin Loney:
"Att ha uppgifterna sorterade i vyn kan förenkla din applikationsutveckling. Om din kod t.ex. går igenom en uppsättning poster, kan det göra din bearbetning och felkontroll enklare att ha dessa försorterade. I din applikationsutveckling kommer du att veta att data alltid kommer att returneras till dig på ett ordnat sätt.”
- Mr. Alapati varnar DBA:er för en begränsning av direkta sökvägsbelastningar:
“Obs:I en direktladdning kan du inte använda några SQL-funktioner. Om du behöver utföra en stor dataladdning och även transformera informationen under laddningen har du ett problem. Den konventionella databelastningen låter dig använda SQL-funktioner för att transformera data, men metoden är mycket långsam jämfört med den direkta belastningen. För stora dataladdningar kanske du vill överväga att använda någon av de nyare laddnings-/omvandlingsteknikerna, såsom externa tabeller eller tabellfunktioner."
Emellertid kan CoSorts SortCL-program omvandla laddningsdata under försortering; d.v.s. genom att kombinera samma typ av SQL-funktioner i samma jobbskript och I/O-pass, inklusive:kopplingar, aggregationer, korsberäkningar, uppslagningar, välj/filter, delsträngs- och instringsfunktioner, och massor av omformatering och anpassade rapportmål — i samma försorteringsoperation.
- Det nya offline-reorganiseringsverktyget i IRI Workbench (Eclipse GUI) använder IRI FACT (Fast Extract) för att snabbt ladda ner tabelldata via OCI, använder CoSort för att försortera på primärnyckeln och skriver och kör SQL*Loader direkt sökvägen laddas för att optimera och kombinera vart och ett av dessa steg.