Hur snabbt är ODBC? En "laddad" jämförelse.

Den inledande frågan

ODBC får en dålig rap för hastighet ibland ... men borde det? Du skulle kunna tro från det som publiceras online att ODBC är i sig långsamt:

Microsoft håller inte med i fallet med SQL Server. I Använda ODBC med Microsoft SQL Server , Amrish Kumar och Alan Brewer säger att ODBC är lika bra som ursprungligt:

Ett av de ihärdiga ryktena om ODBC är att det i sig är långsammare än ett inbyggt DBMS API. Detta resonemang är baserat på antagandet att ODBC-drivrutiner måste implementeras som ett extra lager över ett inbyggt DBMS API, vilket översätter ODBC-satserna som kommer från applikationen till de inbyggda DBMS API-funktionerna och SQL-syntaxen. Denna översättningssatsning lägger till extra bearbetning jämfört med att ha applikationsanropet direkt till det inbyggda API:et. Detta antagande är sant för vissa ODBC-drivrutiner implementerade över ett inbyggt DBMS API, men Microsoft SQL Server ODBC-drivrutinen är inte implementerad på detta sätt. … Microsofts tester har visat att prestandan för ODBC-baserade och DB-biblioteksbaserade SQL Server-applikationer är ungefär lika.

Enligt Oracle kör deras ODBC-drivrutin i genomsnitt bara cirka 3 % långsammare än den ursprungliga Oracle-åtkomsten. Men deras ODBC-drivrutin kanske inte är din, och din körsträcka kommer att variera.

Våra användare frågar ofta när det är bättre att använda ODBC eller en offline, platt-fil tillvägagångssätt för datahantering — som IRI är mest känd för – under mycket stora databasoperationer (VLDB) som:

• ETL (extraktion, transformation och laddning)
• offlinereorganisationer
• migrering och replikering
• datamaskering
• testa datagenerering/population 

Vårt generella svar är att datavolymen bör avgöra datarörelsens paradigm. Vi försökte testa det rådet med ett enkelt riktmärke för databaspopulation (laddning).

Jämföra två paradigm

Observera att vi här bara tittar på ODBC kontra bulk, filbaserad dataförflyttning, och inte JDBC eller andra sätt att distribuera data, som Hadoop. Vi övervägde inte heller andra vägar för att förbättra datainsamlingen, som NoSQL, eller leverans, som Teradata FastLoad.

ODBC (Open Database Connectivity)

ODBC tillhandahåller ett sätt för klientprogram att bekvämt komma åt ett brett utbud av databaser och datakällor som är kompatibla med ODBC.

ODBC åstadkommer DBMS-oberoende genom att använda en ODBC-drivrutin som ett översättningslager mellan applikationen och DBMS. Applikationen använder ODBC-funktioner via en ODBC-drivrutinshanterare som den är länkad till, och drivrutinen skickar frågan eller uppdateringskommandot till DBMS.

För att fylla i en tabell via ODBC i IRI-programvara som CoSort SortCL-programmet, ange utdataprocesstypen som ODBC. Ett exempel på skriptinriktningskolumner i en tabell, i stället för en fil eller procedur, kan innehålla denna 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)

Standardbeteendet för ODBC-population i SortCL inom jobb för:IRI CoSort (bulktransformationer och förladdningssortering), IRI NextForm (DB-migrering och replikering), IRI FieldShield (DB-datamaskering och kryptering), IRI RowGen (DB-testdatagenerering) , eller IRI Voracity (alla ovanstående) är /APPEND, som lägger till rader till en befintlig tabell. Ytterligare alternativ är /CREATE, för trunkering och fullständig infogning, och /UPDATE för selektiv infogning.

SQL*Loader 

SQL*Loader är ett Oracle-databasverktyg som laddar data från en extern (platt) fil till en befintlig tabell på samma system eller över ett nätverk. SQL*Loader stöder olika måltabellformat och kan hantera både selektiv och flera tabellladdningar.

Data kan laddas från vilken textfil som helst och infogas i databasen. Man kan massinläsa en tabell från skalet med kommandot sqlldr (sqlload på vissa plattformar). Kör det utan argument för att få en lista över tillgängliga parametrar.

I IRI ETL- och reorg-scenarier där plattfilsdata är försorterad på den längsta indexnyckeln i måltabellen, är syntaxen för load-kommandot:

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

där .ctl loader-kontrollfilen innehåller:

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

Diagrammet nedan jämför den genomsnittliga tid det tog för Oracle XE 11gR2 på en Windows-server att fyllas med fem olika försorterade filer med både ODBC-infogningar och SQL*Loader:

Slutsats för IRI-användare

Vi fann att IRI FieldShield-användare vanligtvis har det bra med ODBC eftersom det är bekvämare och tillräckligt snabbt för dynamisk datamaskering och statisk datamaskering av tabeller med färre än en miljon rader. Detsamma gäller för mindre än enorma datamappning, federation eller rapportering i IRI CoSort eller IRI NextForm.

För bulk ETL och reorg-operationer i IRI Voracity, men det som fortsätter att fungera bäst är dessa komponenter som stöds:

1. IRI FACT (Fast Extract) för urladdningar med inbyggda drivrutiner som OCI
2. IRI CoSort för stordatatransformation och förladdningssortering [eller IRI RowGen för sorterad, referensiellt korrekt testdatagenerering]
3. Ditt DB-laddningsverktyg för bulk, direkt sökvägsbelastning

Så blyg för komplexa och kostsamma paradigm som NoSQL och Hadoop — den pålitliga plattfilsmetoden är fortfarande vägen att gå.