A pergunta inicial
ODBC tem uma má reputação por velocidade às vezes... mas deveria? Você pensaria pelo que foi publicado on-line que o ODBC é intrinsecamente lento:
A Microsoft discorda no caso do SQL Server. Em Usando ODBC com Microsoft SQL Server , Amrish Kumar e Alan Brewer dizem que o ODBC é tão bom quanto nativo:
Um dos rumores persistentes sobre o ODBC é que ele é inerentemente mais lento que uma API DBMS nativa. Esse raciocínio é baseado na suposição de que os drivers ODBC devem ser implementados como uma camada extra sobre uma API DBMS nativa, traduzindo as instruções ODBC provenientes do aplicativo para as funções nativas da API DBMS e sintaxe SQL. Esse esforço de tradução adiciona processamento extra em comparação com a chamada do aplicativo diretamente para a API nativa. Essa suposição é verdadeira para alguns drivers ODBC implementados em uma API DBMS nativa, mas o driver ODBC do Microsoft SQL Server não é implementado dessa maneira. … Os testes da Microsoft mostraram que o desempenho de aplicativos SQL Server baseados em ODBC e baseados em biblioteca de banco de dados é aproximadamente igual.
De acordo com a Oracle, seu driver ODBC, em média, roda apenas cerca de 3% mais lento que o acesso nativo da Oracle. Mas o driver ODBC deles pode não ser seu, e sua milhagem pode variar.
Nossos usuários costumam perguntar quando é melhor usar ODBC ou uma abordagem de arquivo simples off-line para manipulação de dados — pelo qual o IRI é mais conhecido — durante operações de banco de dados muito grande (VLDB), como:
- ETL (extração, transformação e carregamento)
- reorganizações off-line
- migração e replicação
- mascaramento de dados
- geração/população de dados de teste
Nossa resposta geral é que o volume de dados deve determinar o paradigma de movimentação de dados. Decidimos testar esse conselho com uma referência simples de preenchimento (carregamento) de banco de dados.
Comparando dois paradigmas
Observe que aqui estamos analisando apenas ODBC versus movimentação de dados em massa, baseada em arquivo, e não JDBC ou outros meios de distribuição de dados, como o Hadoop. Também não consideramos outros caminhos divulgados para melhorar a aquisição de dados, como NoSQL, ou entrega, como Teradata FastLoad.
ODBC (Conectividade de Banco de Dados Aberto)
O ODBC fornece uma maneira para os programas clientes acessarem convenientemente uma ampla variedade de bancos de dados e fontes de dados compatíveis com ODBC.
O ODBC realiza a independência do DBMS usando um driver ODBC como uma camada de tradução entre o aplicativo e o DBMS. O aplicativo usa funções ODBC por meio de um gerenciador de driver ODBC ao qual está vinculado, e o driver passa o comando de consulta ou atualização para o SGBD.
Para preencher uma tabela via ODBC no software IRI como o programa CoSort SortCL, especifique o tipo de processo de saída como ODBC. Um script de exemplo que segmenta colunas em uma tabela, em vez de um arquivo ou procedimento, pode conter este 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)
O comportamento de preenchimento de ODBC padrão em SortCL em jobs para:IRI CoSort (transformações em massa e classificação de pré-carregamento), IRI NextForm (migração e replicação de banco de dados), IRI FieldShield (mascaramento de dados de banco de dados e criptografia), IRI RowGen (geração de dados de teste de banco de dados) , ou IRI Voracity (todos os itens acima) é /APPEND, que adiciona linhas a uma tabela existente. As opções adicionais são /CREATE, para inserção truncada e completa, e /UPDATE para inserção seletiva.
SQL*Loader
O SQL*Loader é um utilitário de banco de dados Oracle que carrega dados de um arquivo externo (simples) em uma tabela existente no mesmo sistema ou em uma rede. O SQL*Loader é compatível com vários formatos de tabela de destino e pode lidar com carregamentos seletivos e de várias tabelas.
Os dados podem ser carregados de qualquer arquivo de texto e inseridos no banco de dados. É possível carregar uma tabela em massa do shell usando o comando sqlldr (sqlload em algumas plataformas). Execute-o sem argumentos para obter uma lista de parâmetros disponíveis.
Em cenários IRI ETL e reorganização em que os dados de arquivo simples são pré-classificados na chave de índice mais longa da tabela de destino, a sintaxe do comando de carregamento é:
C:\IRI\CoSort10>sqlldr scott/tiger control=ODBC_ONEMILLION_TEST.ctl DIRECT=TRUE
em que o arquivo de controle do carregador .ctl contém:
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}")
O gráfico abaixo compara o tempo médio que levou para o Oracle XE 11gR2 em um servidor Windows ser preenchido com cinco arquivos pré-classificados diferentes usando inserções ODBC e SQL*Loader:
Nº de registros | População de banco de dados via SQL*Loader | População de banco de dados via ODBC |
2,5 milhões | 10,25 segundos | 58,25 segundos |
2 milhões | 6,25 segundos | 24,25 segundos |
1 milhão | 5,25 segundos | 11,5 segundos |
1/2 milhão | 4 segundos | 5,5 segundos |
1/4 milhão | 2,75 segundos | 4,25 segundos |
Conclusão para usuários do IRI
Descobrimos que os usuários do IRI FieldShield normalmente aceitam o ODBC porque é mais conveniente e rápido o suficiente para mascarar dados dinâmicos e estáticos de tabelas com menos de um milhão de linhas. O mesmo vale para operações de mapeamento, federação ou relatórios de dados menos que enormes no IRI CoSort ou IRI NextForm.
No entanto, para operações de ETL e reorganização em massa no IRI Voracity, o que continua funcionando melhor são estes componentes compatíveis:
- IRI FACT (Fast Extract) para descarregamentos usando drivers nativos como OCI
- IRI CoSort para transformação de big data e classificação pré-carregada [ou IRI RowGen para geração de dados de teste classificados e referencialmente corretos]
- Seu utilitário de carregamento de banco de dados para cargas de caminho direto e em massa
Tão tímido de paradigmas complexos e caros como NoSQL e Hadoop — o método confiável de arquivo simples ainda é o caminho a seguir.