Big data laden? Voor meer snelheid, voorsorteren en bulkladen
Het vinden van meer snelheid bij het laden van big data is een uitdaging in ETL, reorg en Very Large Database (VLDB) index operaties bevolken. Een manier om big data sneller te laden, is door ze vooraf te sorteren, zodat de database niet hoeft te sorteren. IBM en andere leveranciers van mainframedatabases geven dat advies al tientallen jaren, en het geldt nog steeds voor relationele databases die tegenwoordig op Unix en andere 'open systemen' worden gebruikt, waaronder Oracle, DB2, Sybase en SQL Server.
Benchmarks op dit gebied laten verbeteringen zien ten opzichte van ongesorteerde ladingen, afhankelijk van het volume, maar sorteerders zoals IRI beweren dat de laadprestaties tussen de twee en tien keer zijn verbeterd. In het TUSC Consulting-rapport "Benchmarking Index Impact on OLTP Load Rates and Online Database Block Size Rebuild in Oracle", toonde een enkelvoudige index-inserttest van 100.000 rijen alleen al aan dat voorgesorteerde gegevens 58% sneller werden geladen en 49% minder ruimte nodig hadden:
- Het laden in gesorteerde volgorde had een 42% lagere aanhoudende rijen/seconde laadsnelheid
- Ongesorteerde invoegingen in indexen dwingen meer intern databasewerk (blokbeheer en reorganisatie van de ruimte) te doen
- In op belasting gesorteerde indexen zal de clusterfactor dicht bij het aantal bladblokken liggen
- De volgorde van geladen gegevens is van cruciaal belang voor de laadprestaties.
Vele jaren later, in hoofdstuk 13 van zijn "Expert Oracle Database 11g Administration"-gids, beval Sam R. Alapati (Miro Consulting) voorsortering aan in combinatie met directe padladingen als de snelste manier om Oracle bulksgewijs te laden (versus inserts):
“Het direct-pad laden optie gebruikt de SQL INSERT-instructie niet om gegevens in tabellen te plaatsen; in plaats daarvan formatteert het Oracle-gegevensblokken en schrijft ze rechtstreeks naar de databasebestanden. Dit direct-write-proces elimineert een groot deel van de overhead die gepaard gaat met het uitvoeren van SQL-instructies om tabellen te laden. Omdat de methode voor het laden via een direct pad niet strijdt voor databasebronnen, worden gegevens veel sneller geladen dan bij een conventionele gegevensbelasting. Voor grotere gegevensbelastingen is de laadmethode via het directe pad het beste, en het kan de enige haalbare methode zijn om gegevens in tabellen te laden, om de eenvoudige reden dat een conventionele belasting meer tijd kan vergen dan beschikbaar is."
Voor beheerders van VLDB's vandaag, is dit waar CoSort van pas komt, aangezien:
"Naast de duidelijke voordelen van een kortere laadtijd, helpt direct laden u ook om indexen opnieuw op te bouwen en tabelgegevens voor te sorteren."
CoSort wordt traditioneel gebruikt in de externe voorsortering van een plat bestand dat de import zal zijn naar een lading die "direct=true" specificeert en deze optie:
"SORTED INDEXES:De SORTED_INDEXES parameter signaleert SQL*Loader dat gegevens zijn gesorteerd op een gespecificeerde index, wat de laadprestaties verbetert."
Evenzo specificeert de Microsoft SQL Server-documentatie het voorsorteren van bestanden als een van de "Methoden voor het optimaliseren van bulkimport":
Standaard gaat een bulkimportbewerking ervan uit dat een gegevensbestand ongeordend is. Als de tabel een geclusterde index heeft, is de bcp hulpprogramma, de instructie BULK INSERT en de functie OPENROWSET(BULK...) (Transact-SQL) laten u specificeren hoe gegevens in het gegevensbestand worden gesorteerd tijdens een bulkimportbewerking. Het is optioneel dat gegevens in het gegevensbestand in dezelfde volgorde als de tabel worden gesorteerd. U kunt de prestaties van de bulkimportbewerking echter verbeteren als u dezelfde volgorde voor het gegevensbestand opgeeft als voor de tabel.
Het /KEY-veld in een CoSort SortCL-script is doorgaans de langste index (primaire) sleutel in de tabel, maar dat hoeft niet. Volgens TUSC, voor soortgelijke kolommen:
- Minder langere indexen hebben de voorkeur boven meer kortere indexen
- Toonaangevende kolom drijft de kosten voor het laden van de index op
Merk ook op dat:
- Per Vertica en andere RDBMS-primers, optimaliseert het onderhouden van kolommen in gesorteerde volgorde de queryprestaties. Zelfs het oude advies in DEC's Rdb/VMS Guide to Database Maintenance and Performance is nog steeds waar:
“Sorteer de records die u in een tabel wilt opslaan vooraf op primaire sleutelwaarde voordat u ze in de database laadt. Wanneer de records worden geladen, zullen ze fysiek aangrenzend aan elkaar zijn, of geclusterd, totdat er extra records in de database worden opgeslagen. Het handhaven van deze indeling komt ten goede aan query's die rijen selecteren op basis van een reeks waarden of die veel rijen van één tabel samenvoegen met rijen in dezelfde tabel."
- Het vooraf sorteren van gegevens in tabellen kan ook tijd besparen in weergaven. Volgens "Oracle Database 10g:The Complete Reference" door Kevin Loney:
“Als de gegevens in de weergave zijn gesorteerd, kan dit de ontwikkeling van uw applicatie vereenvoudigen. Als uw code bijvoorbeeld door een reeks records loopt, kan het voorsorteren van die records uw verwerking en foutcontrole eenvoudiger maken. Bij de ontwikkeling van uw applicatie weet u dat de gegevens altijd op een geordende manier naar u worden teruggestuurd.”
- Dhr. Alapati waarschuwt DBA's voor een beperking van het laden van directe paden:
“Opmerking:bij een directe belasting kunt u geen SQL-functies gebruiken. Als u een grote gegevensbelasting moet uitvoeren en ook moet transformeren de gegevens tijdens het laden, heb je een probleem. Met de conventionele gegevensbelasting kunt u SQL-functies gebruiken om gegevens te transformeren, maar de methode is erg traag in vergelijking met de directe belasting. Voor grote gegevensbelastingen kunt u dus overwegen om een van de nieuwere laad-/transformatietechnieken te gebruiken, zoals externe tabellen of tabelfuncties."
Het SortCL-programma van CoSort kan de laadgegevens echter transformeren tijdens het voorsorteren; d.w.z. door hetzelfde type SQL-functies te combineren in hetzelfde jobscript en I/O-pass, inclusief:joins, aggregaties, kruisberekeningen, opzoekacties, select/filter, substring- en instring-functies, en tal van herformatterings- en aangepaste rapportdoelen — in diezelfde voorsorteerbewerking.
- Het nieuwe offline reorg-hulpprogramma in de IRI Workbench (Eclipse GUI) gebruikt IRI FACT (Fast Extract) om tabelgegevens snel te verwijderen via OCI, gebruikt CoSort om vooraf te sorteren op de primaire sleutel en schrijft en voert SQL*Loader direct uit padbelastingen om elk van deze stappen te optimaliseren en te combineren.