La domanda di apertura
ODBC ottiene un brutto colpo per la velocità a volte ... ma dovrebbe? Penseresti da ciò che viene pubblicato online che ODBC è intrinsecamente lento:
Microsoft non è d'accordo nel caso di SQL Server. In Utilizzo di ODBC con Microsoft SQL Server , Amrish Kumar e Alan Brewer affermano che ODBC è buono come nativo:
Una delle voci insistenti su ODBC è che è intrinsecamente più lento di un'API DBMS nativa. Questo ragionamento si basa sul presupposto che i driver ODBC debbano essere implementati come un livello aggiuntivo su un'API DBMS nativa, traducendo le istruzioni ODBC provenienti dall'applicazione nelle funzioni API DBMS native e nella sintassi SQL. Questo sforzo di traduzione aggiunge ulteriore elaborazione rispetto alla chiamata dell'applicazione direttamente all'API nativa. Questa ipotesi è vera per alcuni driver ODBC implementati su un'API DBMS nativa, ma il driver ODBC di Microsoft SQL Server non è implementato in questo modo. ... I test di Microsoft hanno dimostrato che le prestazioni delle applicazioni SQL Server basate su ODBC e su DB-Library sono più o meno uguali.
Secondo Oracle, il loro driver ODBC, in media, è solo circa il 3% più lento dell'accesso Oracle nativo. Ma il loro autista ODBC potrebbe non essere tuo e il tuo chilometraggio varierà.
I nostri utenti spesso chiedono quando è meglio utilizzare ODBC o un approccio off-line flat-file alla gestione dei dati, per il quale IRI è meglio conosciuto, durante operazioni di database molto grandi (VLDB) come:
- ETL (estrazione, trasformazione e caricamento)
- Riorganizzazioni offline
- migrazione e replica
- mascheramento dei dati
- testare la generazione/popolazione dei dati
La nostra risposta generale è che il volume dei dati dovrebbe determinare il paradigma del movimento dei dati. Abbiamo deciso di testare questo consiglio con un semplice benchmark (caricamento) della popolazione del database.
Confronto tra due paradigmi
Tieni presente che qui stiamo solo esaminando ODBC rispetto allo spostamento di dati in blocco basato su file e non JDBC o altri mezzi di distribuzione dei dati, come Hadoop. Inoltre, non abbiamo preso in considerazione altre strade propagandate per migliorare l'acquisizione dei dati, come NoSQL, o la distribuzione, come Teradata FastLoad.
ODBC (Open Database Connectivity)
ODBC consente ai programmi client di accedere comodamente a un'ampia gamma di database e origini dati compatibili con ODBC.
ODBC realizza l'indipendenza del DBMS utilizzando un driver ODBC come livello di traduzione tra l'applicazione e il DBMS. L'applicazione utilizza le funzioni ODBC tramite un gestore di driver ODBC con cui è collegata e il driver passa la query o il comando di aggiornamento al DBMS.
Per popolare una tabella tramite ODBC nel software IRI come il programma CoSort SortCL, specifica il tipo di processo di output come ODBC. Uno script di esempio che ha come target colonne in una tabella, anziché un file o una procedura, potrebbe contenere questo 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)
Il comportamento della popolazione ODBC predefinito in SortCL all'interno dei lavori per:IRI CoSort (trasformazioni in blocco e ordinamento precaricato), IRI NextForm (migrazione e replica database), IRI FieldShield (mascheramento dati DB e crittografia), IRI RowGen (generazione dati di test DB) o IRI Voracity (tutto quanto sopra) è /APPEND, che aggiunge righe a una tabella esistente. Opzioni aggiuntive sono /CREATE, per tronca e inserimento completo, e /UPDATE per inserimento selettivo.
SQL*Loader
SQL*Loader è un'utilità di database Oracle che carica i dati da un file esterno (flat) in una tabella esistente sullo stesso sistema o su una rete. SQL*Loader supporta vari formati di tabelle di destinazione e può gestire sia il caricamento selettivo che multiplo di tabelle.
I dati possono essere caricati da qualsiasi file di testo e inseriti nel database. È possibile caricare in blocco una tabella dalla shell utilizzando il comando sqlldr (sqlload su alcune piattaforme). Eseguilo senza argomenti per ottenere un elenco dei parametri disponibili.
Negli scenari IRI ETL e riorganizzazione in cui i dati del file flat sono preordinati sulla chiave di indice più lunga della tabella di destinazione, la sintassi del comando di caricamento è:
C:\IRI\CoSort10>sqlldr scott/tiger control=ODBC_ONEMILLION_TEST.ctl DIRECT=TRUE
dove il file di controllo del caricatore .ctl contiene:
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}")
Il grafico seguente confronta il tempo medio impiegato da Oracle XE 11gR2 su un server Windows per essere popolato con cinque diversi file preordinati utilizzando sia inserimenti ODBC che SQL*Loader:
Numero di record | Popolazione DB tramite SQL*Loader | Popolazione DB tramite ODBC |
2,5 milioni | 10,25 secondi | 58,25 secondi |
2 milioni | 6,25 secondi | 24,25 secondi |
1 milione | 5,25 secondi | 11,5 secondi |
1/2 milione | 4 secondi | 5,5 secondi |
1/4 di milione | 2,75 secondi | 4,25 secondi |
Conclusione per gli utenti IRI
Abbiamo scoperto che gli utenti di IRI FieldShield in genere stanno bene con ODBC perché è più conveniente e sufficientemente veloce per il mascheramento dei dati dinamici e il mascheramento dei dati statici di tabelle con meno di un milione di righe. Lo stesso vale per operazioni di mappatura, federazione o reporting di dati non enormi in IRI CoSort o IRI NextForm.
Per le operazioni ETL in blocco e riorganizzazione in IRI Voracity, tuttavia, ciò che continua a funzionare meglio sono questi componenti supportati:
- IRI FACT (Fast Extract) per gli scarichi utilizzando driver nativi come OCI
- IRI CoSort per la trasformazione dei big data e l'ordinamento precaricato [o IRI RowGen per la generazione di dati di test ordinati e referenzialmente corretti]
- Il tuo programma di utilità di caricamento del database per carichi di massa e di percorsi diretti
Molto timido di paradigmi complessi e costosi come NoSQL e Hadoop - il metodo affidabile dei file flat è ancora la strada da percorrere.