De openingsvraag
ODBC krijgt soms een slechte reputatie voor snelheid ... maar zou dat ook moeten? Op basis van wat er online is gepost, zou je denken dat ODBC intrinsiek traag is:
Microsoft is het niet eens in het geval van SQL Server. In ODBC gebruiken met Microsoft SQL Server , Amrish Kumar en Alan Brewer zeggen dat ODBC zo goed als native is:
Een van de hardnekkige geruchten over ODBC is dat het inherent langzamer is dan een native DBMS API. Deze redenering is gebaseerd op de veronderstelling dat ODBC-stuurprogramma's moeten worden geïmplementeerd als een extra laag over een native DBMS API, waarbij de ODBC-statements die uit de toepassing komen, worden vertaald naar de native DBMS API-functies en SQL-syntaxis. Deze vertaalinspanning voegt extra verwerking toe in vergelijking met het rechtstreeks aanroepen van de applicatie naar de native API. Deze veronderstelling geldt voor sommige ODBC-stuurprogramma's die zijn geïmplementeerd via een systeemeigen DBMS-API, maar het ODBC-stuurprogramma van Microsoft SQL Server is niet op deze manier geïmplementeerd. ... Uit tests van Microsoft is gebleken dat de prestaties van op ODBC gebaseerde en op DB-bibliotheek gebaseerde SQL Server-applicaties ongeveer gelijk zijn.
Volgens Oracle werkt hun ODBC-stuurprogramma gemiddeld slechts ongeveer 3% langzamer dan native Oracle-toegang. Maar hun ODBC-stuurprogramma is mogelijk niet van u, en uw kilometerstand zal variëren.
Onze gebruikers vragen vaak wanneer het beter is om ODBC te gebruiken of een offline, platte benadering voor gegevensverwerking - waarvoor IRI het meest bekend is - tijdens zeer grote databasebewerkingen (VLDB), zoals:
- ETL (extractie, transformatie en laden)
- offline reorganisatie
- migratie en replicatie
- gegevensmaskering
- generatie/populatie van testgegevens
Ons algemene antwoord is dat gegevensvolume het paradigma van gegevensverplaatsing moet bepalen. We wilden dat advies testen met een eenvoudige benchmark voor het laden van databases.
Twee paradigma's vergelijken
Houd er rekening mee dat we hier alleen kijken naar ODBC versus bulk, op bestanden gebaseerde gegevensverplaatsing, en niet naar JDBC of andere manieren om gegevens te distribueren, zoals Hadoop. We hebben ook geen rekening gehouden met andere manieren die worden aangeprezen om de gegevensverzameling te verbeteren, zoals NoSQL, of levering, zoals Teradata FastLoad.
ODBC (Open Database Connectivity)
ODBC biedt clientprogramma's een manier om gemakkelijk toegang te krijgen tot een breed scala aan databases en gegevensbronnen die compatibel zijn met ODBC.
ODBC bereikt DBMS-onafhankelijkheid door een ODBC-stuurprogramma te gebruiken als vertaallaag tussen de toepassing en het DBMS. De applicatie gebruikt ODBC-functies via een ODBC-stuurprogrammamanager waarmee het is gekoppeld, en het stuurprogramma geeft de query- of updateopdracht door aan het DBMS.
Als u een tabel wilt vullen via ODBC in IRI-software zoals het CoSort SortCL-programma, geeft u het type uitvoerproces op als ODBC. Een voorbeeldscript dat kolommen in een tabel target, in plaats van een bestand of procedure, kan deze lay-out bevatten:
/OUTFILE="QA.MILLION_TEST_NEW_ROW;DSN=OracleTwisterQA" /PROCESS=ODBC /ALIAS=QA_MILLION_TEST_NEW_ROW /FIELD=(ACCTNUM, POSITION=1, SEPARATOR="|", TYPE=ASCII) /FIELD=(DEPTNO, POSITION=2, SEPARATOR="|", TYPE=ASCII) /FIELD=(QUANTITY, POSITION=3, SEPARATOR="|", TYPE=NUMERIC) /FIELD=(TRANSTYPE, POSITION=4, SEPARATOR="|", TYPE=ASCII) /FIELD=(TRANSDATE, POSITION=5, SEPARATOR="|", TYPE=ISODATE) /FIELD=(NAME, POSITION=6, SEPARATOR="|", TYPE=ASCII) /FIELD=(STREETADDRESS, POSITION=7, SEPARATOR="|", TYPE=ASCII) /FIELD=(STATE, POSITION=8, SEPARATOR="|", TYPE=ASCII) /FIELD=(CITY, POSITION=9, SEPARATOR="|", TYPE=ASCII)
Het standaard ODBC-populatiegedrag in SortCL binnen taken voor:IRI CoSort (bulktransformaties en sortering vooraf laden), IRI NextForm (DB-migratie en -replicatie), IRI FieldShield (DB-gegevensmaskering en encryptie), IRI RowGen (generatie van DB-testgegevens) , of IRI Voracity (al het bovenstaande) is /APPEND, waarmee rijen worden toegevoegd aan een bestaande tabel. Extra opties zijn /CREATE, voor afkappen en volledig invoegen, en /UPDATE voor selectief invoegen.
SQL*Loader
SQL*Loader is een Oracle-databasehulpprogramma dat gegevens uit een extern (plat) bestand laadt in een bestaande tabel op hetzelfde systeem of via een netwerk. SQL*Loader ondersteunt verschillende doeltabelindelingen en kan zowel selectieve als meerdere tabellen laden.
De gegevens kunnen vanuit elk tekstbestand worden geladen en in de database worden ingevoegd. Men kan een tabel bulksgewijs laden vanuit de shell met behulp van de opdracht sqlldr (sqlload op sommige platforms). Voer het uit zonder argumenten om een lijst met beschikbare parameters te krijgen.
In IRI ETL- en reorg-scenario's waarin de flat-file-gegevens zijn voorgesorteerd op de langste indexsleutel van de doeltabel, is de syntaxis van de laadopdracht:
C:\IRI\CoSort10>sqlldr scott/tiger control=ODBC_ONEMILLION_TEST.ctl DIRECT=TRUE
waar het .ctl loader-besturingsbestand het volgende bevat:
INFILE 'C:\IRI\CoSort10\workbench\workspace\CM\twofiftym ilfinalcm.out' APPEND INTO TABLE ODBC_ONEMILLION_TEST REENABLE FIELDS TERMINATED BY "|" ( ACCTNUM NULLIF(ACCTNUM="{NULL}") , DEPTNO NULLIF(DEPTNO="{NULL}") , QUANTITY NULLIF(QUANTITY="{NULL}") , TRANSTYPE NULLIF(TRANSTYPE="{NULL}") , TRANSDATE NULLIF(TRANSDATE="{NULL}") , NAME NULLIF(NAME="{NULL}") , STREETADDRESS NULLIF(STREETADDRESS="{NULL}") , STATE NULLIF(STATE="{NULL}") , CITY NULLIF(CITY="{NULL}")
In de onderstaande grafiek wordt de gemiddelde tijd vergeleken die nodig was voordat Oracle XE 11gR2 op een Windows-server werd gevuld met vijf verschillende voorgesorteerde bestanden met zowel ODBC-invoegingen als SQL*Loader:
Aantal records | DB-populatie via SQL*Loader | DB-populatie via ODBC |
2,5 miljoen | 10,25 seconden | 58,25 seconden |
2 miljoen | 6,25 seconden | 24,25 seconden |
1 miljoen | 5,25 seconden | 11,5 seconden |
1/2 miljoen | 4 seconden | 5,5 seconden |
1/4 miljoen | 2,75 seconden | 4,25 seconden |
Conclusie voor IRI-gebruikers
We ontdekten dat IRI-FieldShield-gebruikers doorgaans geen probleem hebben met ODBC omdat het handiger en snel genoeg is voor dynamische gegevensmaskering en statische gegevensmaskering van tabellen met minder dan een miljoen rijen. Hetzelfde geldt voor minder-dan-enorme datamapping-, federatie- of rapportagebewerkingen in IRI CoSort of IRI NextForm.
Voor bulk-ETL- en reorganisatie-bewerkingen in IRI Voracity blijven deze ondersteunde componenten echter het beste werken:
- IRI FACT (Fast Extract) voor uitladen met native stuurprogramma's zoals OCI
- IRI CoSort voor big data-transformatie en pre-load sortering [of IRI RowGen voor gesorteerde, referentieel correcte generatie van testgegevens]
- Uw hulpprogramma voor het laden van databases voor bulkladingen met direct pad
Zo verlegen voor complexe en dure paradigma's zoals NoSQL en Hadoop - de vertrouwde flat-file-methode is nog steeds de juiste keuze.