Hvor hurtigt er ODBC? En "belastet" sammenligning.

Et af de vedvarende rygter om ODBC er, at det i sagens natur er langsommere end en indbygget DBMS API. Dette ræsonnement er baseret på antagelsen om, at ODBC-drivere skal implementeres som et ekstra lag over en native DBMS API, der oversætter ODBC-sætningerne fra applikationen til de native DBMS API-funktioner og SQL-syntaks. Denne oversættelsesindsats tilføjer ekstra behandling sammenlignet med at få applikationskaldet direkte til den oprindelige API. Denne antagelse er sand for nogle ODBC-drivere implementeret over en indbygget DBMS API, men Microsoft SQL Server ODBC-driveren er ikke implementeret på denne måde. ... Microsofts test har vist, at ydeevnen af ​​ODBC-baserede og DB-biblioteksbaserede SQL Server-applikationer er nogenlunde ens.

Ifølge Oracle kører deres ODBC-driver i gennemsnit kun omkring 3 % langsommere end oprindelig Oracle-adgang. Men deres ODBC-driver er muligvis ikke din, og din kilometertal vil variere.

Vores brugere spørger ofte, hvornår det er bedre at bruge ODBC eller en off-line, flad-fil tilgang til datahåndtering — som IRI er bedst kendt for – under meget store databaseoperationer (VLDB) som:

• ETL (ekstraktion, transformation og indlæsning)
• offline omorganiseringer
• migrering og replikering
• datamaskering
• test datagenerering/population 

Vores generelle svar er, at datavolumen bør bestemme databevægelsesparadigmet. Vi satte os for at teste det råd med et simpelt benchmark for databasepopulation (indlæsning).

Sammenligning af to paradigmer

Bemærk, at vi her kun ser på ODBC vs. bulk, filbaseret databevægelse og ikke JDBC eller andre måder at distribuere data på, såsom Hadoop. Vi overvejede heller ikke andre muligheder for at forbedre dataindsamling, såsom NoSQL eller levering, som Teradata FastLoad.

ODBC (Open Database Connectivity)

ODBC giver klientprogrammer nem adgang til en bred vifte af databaser og datakilder der er kompatible med ODBC.

ODBC opnår DBMS-uafhængighed ved at bruge en ODBC-driver som et oversættelseslag mellem applikationen og DBMS. Applikationen bruger ODBC-funktioner gennem en ODBC-drivermanager, som den er forbundet med, og driveren sender forespørgslen eller opdateringskommandoen til DBMS.

For at udfylde en tabel via ODBC i IRI-software som CoSort SortCL-programmet, skal du angive outputprocestypen som ODBC. Et eksempel på scriptmålretningskolonner i en tabel, i stedet for en fil eller procedure kan indeholde dette layout:

/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)

Standard ODBC-populationsadfærden i SortCL inden for jobs for:IRI CoSort (massetransformationer og pre-load sortering), IRI NextForm (DB-migrering og replikering), IRI FieldShield (DB-datamaskering og kryptering), IRI RowGen (DB-testdatagenerering) , eller IRI Voracity (alle ovenstående) er /APPEND, som tilføjer rækker til en eksisterende tabel. Yderligere muligheder er /CREATE, for trunkering og fuld indsættelse, og /OPDATERING for selektiv indsættelse.

SQL*Loader 

SQL*Loader er et Oracle-databaseværktøj, der indlæser data fra en ekstern (flad) fil til en eksisterende tabel på det samme system eller på tværs af et netværk. SQL*Loader understøtter forskellige måltabelformater og kan håndtere både selektiv og multiple tabelindlæsning.

Dataene kan indlæses fra enhver tekstfil og indsættes i databasen. Man kan masseindlæse en tabel fra shellen ved at bruge kommandoen sqlldr (sqlload på nogle platforme). Kør det uden argumenter for at få en liste over tilgængelige parametre.

I IRI ETL- og reorg-scenarier, hvor de flade fildata er forhåndssorteret på den længste indeksnøgle i måltabellen, er indlæsningskommandosyntaksen:

C:\IRI\CoSort10>sqlldr scott/tiger control=ODBC_ONEMILLION_TEST.ctl DIRECT=TRUE

hvor .ctl loader-kontrolfilen indeholder:

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}")

Grafen nedenfor sammenligner den gennemsnitlige tid, det tog for Oracle XE 11gR2 på en Windows-server at blive udfyldt med fem forskellige forudsorterede filer ved hjælp af både ODBC-indsættelser og SQL*Loader:

Konklusion for IRI-brugere

Vi fandt ud af, at IRI FieldShield-brugere typisk har det fint med ODBC, fordi det er mere bekvemt og hurtigt nok til dynamisk datamaskering og statisk datamaskering af tabeller med færre end en million rækker. Det samme gælder for mindre end enorme datakortlægning, federation eller rapporteringsoperationer i IRI CoSort eller IRI NextForm.

Til bulk ETL og reorg-operationer i IRI Voracity er det, der dog fortsat fungerer bedst, disse understøttede komponenter:

1. IRI FACT (Fast Extract) til aflæsninger ved hjælp af indbyggede drivere som OCI
2. IRI CoSort til big data transformation og pre-load sortering [eller IRI RowGen til sorteret, referentielt korrekt testdatagenerering]
3. Dit DB-indlæsningsværktøj til bulk, direkte stibelastninger

Så genert over for komplekse og dyre paradigmer som NoSQL og Hadoop — den troværdige flad-fil-metode er stadig vejen at gå.