Úvodní otázka
ODBC má někdy špatný rap kvůli rychlosti… ale mělo by? Z toho, co je zveřejněno online, byste si mysleli, že ODBC je skutečně pomalé:
Microsoft nesouhlasí v případě SQL Server. V Použití ODBC s Microsoft SQL Server , Amrish Kumar a Alan Brewer říkají, že ODBC je stejně dobré jako nativní:
Jednou z přetrvávajících fám o ODBC je, že je ze své podstaty pomalejší než nativní API DBMS. Tato úvaha je založena na předpokladu, že ovladače ODBC musí být implementovány jako další vrstva přes nativní DBMS API, převádějící příkazy ODBC přicházející z aplikace do nativních funkcí DBMS API a syntaxe SQL. Toto úsilí o překlad přidává další zpracování ve srovnání s voláním aplikace přímo do nativního rozhraní API. Tento předpoklad platí pro některé ovladače ODBC implementované přes nativní API DBMS, ale ovladač ODBC pro Microsoft SQL Server tímto způsobem implementován není. … Testování společnosti Microsoft ukázalo, že výkon aplikací SQL Server založených na ODBC a DB-Library je zhruba stejný.
Podle společnosti Oracle běží jejich ovladač ODBC v průměru jen o 3 % pomaleji než nativní přístup Oracle. Jejich ovladač ODBC však nemusí být váš a váš počet najetých kilometrů se bude lišit.
Naši uživatelé se často ptají, kdy je lepší použít ODBC nebo offline, plochý přístup ke zpracování dat – kterým je IRI nejznámější – během operací s velkými databázemi (VLDB), jako jsou:
- ETL (extrakce, transformace a načítání)
- offline reorganizace
- migrace a replikace
- maskování dat
- generování testovacích dat/vyplnění
Naší obecnou odpovědí je, že objem dat by měl určovat paradigma pohybu dat. Rozhodli jsme se tuto radu otestovat pomocí jednoduchého benchmarku populace (načítání) databáze.
Porovnání dvou paradigmat
Všimněte si, že zde se zabýváme pouze ODBC vs. hromadný, přesun dat založených na souborech, nikoli JDBC nebo jiné způsoby distribuce dat, jako je Hadoop. Také jsme nezvažovali jiné cesty nabízené ke zlepšení získávání dat, jako je NoSQL, nebo doručování, jako je Teradata FastLoad.
ODBC (Open Database Connectivity)
ODBC poskytuje klientským programům způsob, jak pohodlně přistupovat k široké škále databází a zdrojů dat, které jsou kompatibilní s ODBC.
ODBC dosahuje nezávislosti DBMS pomocí ovladače ODBC jako vrstvy překladu mezi aplikací a DBMS. Aplikace využívá funkce ODBC prostřednictvím správce ovladačů ODBC, se kterým je propojena, a ovladač předává příkaz dotazu nebo aktualizace systému DBMS.
Chcete-li naplnit tabulku prostřednictvím ODBC v softwaru IRI, jako je program CoSort SortCL, zadejte typ výstupního procesu jako ODBC. Ukázkový skript, který cílí na sloupce v tabulce, spíše než soubor nebo proceduru může obsahovat toto rozvržení:
/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)
Výchozí chování populace ODBC v SortCL v rámci úloh pro:IRI CoSort (hromadné transformace a třídění před načtením), IRI NextForm (migrace a replikace DB), IRI FieldShield (maskování a šifrování dat DB), IRI RowGen (generování testovacích dat DB) , nebo IRI Voracity (vše výše uvedené) je /APPEND, což přidává řádky do existující tabulky. Další možnosti jsou /CREATE pro zkrácení a úplné vložení a /UPDATE pro selektivní vložení.
SQL*Loader
SQL*Loader je databázový nástroj Oracle, který načítá data z externího (prostého) souboru do existující tabulky ve stejném systému nebo přes síť. SQL*Loader podporuje různé formáty cílových tabulek a zvládne selektivní i vícenásobné načítání tabulek.
Data lze načíst z libovolného textového souboru a vložit do databáze. Tabulku lze hromadně načíst ze shellu pomocí příkazu sqlldr (sqlload na některých platformách). Spusťte jej bez argumentů, abyste získali seznam dostupných parametrů.
Ve scénářích IRI ETL a reorg, ve kterých jsou data plochého souboru předtříděna podle nejdelšího indexového klíče cílové tabulky, je syntaxe příkazu load:
C:\IRI\CoSort10>sqlldr scott/tiger control=ODBC_ONEMILLION_TEST.ctl DIRECT=TRUE
kde ovládací soubor zavaděče .ctl obsahuje:
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}")
Níže uvedený graf porovnává průměrnou dobu, za kterou se Oracle XE 11gR2 na serveru Windows naplnil pěti různými předem seřazenými soubory pomocí vkládání ODBC a SQL*Loader:
# záznamů | Populace DB přes SQL*Loader | Populace DB přes ODBC |
2,5 milionu | 10,25 sekund | 58,25 sekund |
2 miliony | 6,25 sekund | 24,25 sekund |
1 milion | 5,25 sekundy | 11,5 sekundy |
1/2 milionu | 4 sekundy | 5,5 sekundy |
1/4 milionu | 2,75 sekundy | 4,25 sekundy |
Závěr pro uživatele IRI
Zjistili jsme, že uživatelům IRI FieldShield obvykle vyhovuje ODBC, protože je pohodlnější a dostatečně rychlé pro dynamické maskování dat a maskování statických dat tabulek s méně než milionem řádků. Totéž platí pro méně než velké operace mapování dat, federace nebo vykazování v IRI CoSort nebo IRI NextForm.
Pro hromadné ETL a reorg operace v IRI Voracity však nadále nejlépe fungují tyto podporované komponenty:
- IRI FACT (Fast Extract) pro uvolnění pomocí nativních ovladačů, jako je OCI
- IRI CoSort pro transformaci velkých dat a třídění před načtením [nebo IRI RowGen pro tříděné, referenčně správné generování testovacích dat]
- Nástroj pro načítání databáze pro hromadné načítání přímých cest
Tak se vyhýbám složitým a nákladným vzorům, jako jsou NoSQL a Hadoop – spolehlivá metoda plochých souborů je stále správná cesta.