Quelle est la vitesse d'ODBC ? Une comparaison "chargée".

La question d'ouverture

ODBC a parfois mauvaise presse pour la vitesse… mais devrait-il le faire ? D'après ce qui est publié en ligne, on pourrait penser qu'ODBC est intrinsèquement lent :

Microsoft n'est pas d'accord dans le cas de SQL Server. Dans Utiliser ODBC avec Microsoft SQL Server , Amrish Kumar et Alan Brewer disent qu'ODBC est aussi bon que natif :

L'une des rumeurs persistantes concernant ODBC est qu'il est intrinsèquement plus lent qu'une API SGBD native. Ce raisonnement est basé sur l'hypothèse que les pilotes ODBC doivent être implémentés comme une couche supplémentaire sur une API SGBD native, traduisant les instructions ODBC provenant de l'application en fonctions API SGBD natives et en syntaxe SQL. Cet effort de traduction ajoute un traitement supplémentaire par rapport à l'appel direct de l'application à l'API native. Cette hypothèse est vraie pour certains pilotes ODBC implémentés via une API SGBD native, mais le pilote ODBC Microsoft SQL Server n'est pas implémenté de cette manière. … Les tests de Microsoft ont montré que les performances des applications SQL Server basées sur ODBC et sur DB-Library sont à peu près égales.

Selon Oracle, leur pilote ODBC, en moyenne, ne s'exécute qu'environ 3 % plus lentement que l'accès Oracle natif. Mais leur pilote ODBC peut ne pas être le vôtre, et votre kilométrage variera.

Nos utilisateurs demandent souvent s'il est préférable d'utiliser ODBC ou une approche hors ligne de fichier plat pour la gestion des données - pour laquelle l'IRI est le plus connu - lors d'opérations de très grande base de données (VLDB) telles que :

• ETL (extraction, transformation et chargement)
• Réorganisations hors ligne
• migration et réplication
• masquage des données
• tester la génération/l'alimentation des données 

Notre réponse générale est que le volume de données devrait déterminer le paradigme du mouvement des données. Nous avons décidé de tester ces conseils avec une simple analyse comparative de population de base de données (chargement).

Comparer deux paradigmes

Notez qu'ici, nous examinons uniquement ODBC par rapport au transfert de données en bloc, basé sur des fichiers, et non JDBC ou d'autres moyens de distribution de données, comme Hadoop. Nous n'avons pas non plus pris en compte d'autres avenues vantées pour améliorer l'acquisition de données, comme NoSQL, ou la livraison, comme Teradata FastLoad.

ODBC (connectivité de base de données ouverte)

ODBC permet aux programmes clients d'accéder facilement à un large éventail de bases de données et de sources de données compatibles avec ODBC.

ODBC assure l'indépendance du SGBD en utilisant un pilote ODBC comme couche de traduction entre l'application et le SGBD. L'application utilise les fonctions ODBC via un gestionnaire de pilote ODBC avec lequel elle est liée, et le pilote transmet la requête ou la commande de mise à jour au SGBD.

Pour remplir une table via ODBC dans un logiciel IRI comme le programme CoSort SortCL, spécifiez le type de processus de sortie comme ODBC. Un exemple de script ciblant les colonnes d'un tableau, plutôt qu'un fichier ou une procédure, peut contenir cette mise en page :

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

Le comportement de remplissage ODBC par défaut dans SortCL dans les tâches pour :IRI CoSort (transformations en bloc et tri de préchargement), IRI NextForm (migration et réplication de la base de données), IRI FieldShield (masquage et chiffrement des données de la base de données), IRI RowGen (génération de données de test de la base de données) , ou IRI Voracity (tout ce qui précède) est /APPEND, qui ajoute des lignes à une table existante. Les options supplémentaires sont /CREATE, pour les insertions tronquées et complètes, et /UPDATE pour les insertions sélectives.

SQL*Loader 

SQL*Loader est un utilitaire de base de données Oracle qui charge les données d'un fichier externe (plat) dans une table existante sur le même système ou sur un réseau. SQL*Loader prend en charge divers formats de table cible et peut gérer à la fois le chargement sélectif et le chargement de plusieurs tables.

Les données peuvent être chargées à partir de n'importe quel fichier texte et insérées dans la base de données. On peut charger en masse une table à partir du shell à l'aide de la commande sqlldr (sqlload sur certaines plates-formes). Exécutez-le sans arguments pour obtenir une liste des paramètres disponibles.

Dans les scénarios IRI ETL et de réorganisation dans lesquels les données du fichier plat sont pré-triées sur la clé d'index la plus longue de la table cible, la syntaxe de la commande de chargement est la suivante :

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

où le fichier de contrôle du chargeur .ctl contient :

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

Le graphique ci-dessous compare le temps moyen qu'il a fallu à Oracle XE 11gR2 sur un serveur Windows pour être rempli avec cinq fichiers pré-triés différents à l'aide d'insertions ODBC et SQL*Loader :

Conclusion pour les utilisateurs IRI

Nous avons constaté que les utilisateurs d'IRI FieldShield acceptent généralement bien ODBC, car il est plus pratique et suffisamment rapide pour le masquage dynamique des données et le masquage statique des données de tables de moins d'un million de lignes. Il en va de même pour les opérations de mappage, de fédération ou de création de rapports de données moins volumineuses dans IRI CoSort ou IRI NextForm.

Cependant, pour les opérations ETL en masse et de réorganisation dans IRI Voracity, les composants suivants continuent de fonctionner le mieux :

1. IRI FACT (Fast Extract) pour les déchargements à l'aide de pilotes natifs tels que OCI
2. IRI CoSort pour la transformation du Big Data et le tri avant chargement [ou IRI RowGen pour la génération de données de test triées et référentiellement correctes]
3. Votre utilitaire de chargement de base de données pour les chargements de chemin directs en bloc

Tellement loin des paradigmes complexes et coûteux comme NoSQL et Hadoop - la méthode fiable du fichier plat est toujours la voie à suivre.