Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre éprouvé
    Homme Profil pro
    Architecte Décisionnel
    Inscrit en
    février 2008
    Messages
    816
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte Décisionnel

    Informations forums :
    Inscription : février 2008
    Messages : 816
    Points : 1 191
    Points
    1 191

    Par défaut Bonnes pratiques sur la modélisation de grosses tables

    Bonjour,

    Dans le cadre d'un système décisionnel, je vais avoir à gérer quelques grosses tables avec plusieurs millions de lignes et plusieurs centaines de champs.

    Je me pose la question de l'opportunité de répartir les champs de ces tables en plusieurs table contenant un sous-ensemble des colonnes, ces tables étant reliées par une relation 1-1. Du point de vue alimentation, ça aurait du sens car les champs sont alimentés par plusieurs traitements successifs.

    Votre avis sur la question ?
    Est-ce qu'il peut y avoir un gain sur les performances ? Est-ce que la facilitation sur l'exploitation des tables (plus petites) peut valoir le coup par rapport à la charge supplémentaire de gestion des nouvelles tables ?

    Pour info, je n'ai pas l'option de partitionnement sur la base Oracle.

    Par avance merci,
    Nicolas

  2. #2
    Membre éprouvé
    Homme Profil pro
    DBA Oracle
    Inscrit en
    avril 2013
    Messages
    935
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : DBA Oracle
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : avril 2013
    Messages : 935
    Points : 1 019
    Points
    1 019

    Par défaut

    N'étant pas un expert de la modélisation, je te conseillerai juste ce que j'ai lu plusieurs fois : plus le nombre de tables est important et plus ton modèle est résistant.
    En clair : il faut éviter au maximum les tables avec trop de colonnes.

    Oracle permet maintenant de créer des tables de 1000 colonnes mais cela peut avoir les inconvénients suivants :
    1) redondance des enregistrements alors que seule la valeur d'un champ est différente
    2) un lock est posé sur toutes les colonnes de l’enregistrement lors d'un UPDATE et cela bloque les sessions concurrentes qui voudraient updater d'autres champs du même enresgitrement
    3) row chainage intra-bloc si plus de 246 colonnes
    etc etc
    DBA Oracle
    Rédacteur du blog : dbaoraclesql.canalblog.com

  3. #3
    Modérateur

    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    7 701
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Teradata

    Informations forums :
    Inscription : septembre 2008
    Messages : 7 701
    Points : 16 055
    Points
    16 055

    Par défaut

    Je crois que ça fait assez longtemps qu'Oracle permet des tables à 1000 colonnes, et effectivement c'est une fausse bonne idée.
    Ça dépanne, mais côté perf on reste sur sa faim.

    @DevNico, ce que vous décrivez s'appelle du partitionnement vertical, abordé ici. Je l'avais essayé il y a quelques années ça fonctionne plutôt bien. Apparemment les liens sont assez morts, mais je dois pouvoir retrouver mes bouts de code si ça vous intéresse.

    Il faut découper par exemple en trois les groupes de colonnes en fonction de leur fréquence d'appel.
    Par contre, comme l'indique pachot dans le sujet en lien, le gain peut être nul en fonction de l'utilisation de votre table.

    Maintenant... sur des bases décisionnelles on combine plutôt du partitionning horizontal (celui de l'option que vous n'avez pas) et des index bitmaps (a priori vous n'avez pas non plus) pour avoir des bonnes performances sur un sous-ensemble de données, et de bons I/O disques avec des blocks de 32k et du multiblockread a gogo (512) pour des scans complets.

    Le partitionning horizontal, même sans l'option, vous pouvez toujours le faire à la main en créant les tables une à une et en posant une vue dessus qui fait l'union.
    Avec un peu de PL/SQL, vous pouvez automatiser la création des nouvelles partitions et la mise à jour de la vue.

    Est-ce que vous en savez un peu plus sur ce que vous attendez en volume ?
    Le nombre de lignes c'est bien, mais la taille en Go c'est au moins aussi important.

  4. #4
    Membre éprouvé
    Homme Profil pro
    Architecte Décisionnel
    Inscrit en
    février 2008
    Messages
    816
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte Décisionnel

    Informations forums :
    Inscription : février 2008
    Messages : 816
    Points : 1 191
    Points
    1 191

    Par défaut

    Bonjour Waldar,

    Merci pour toutes ces infos sur le partitionnement vertical.
    Donc en synthèse je retiens que ça peut avoir du sens suivant l'utilisation qu'on fait des tables. Je pense qu'on va partir là dessus.

    Sinon j'ai bien la possibilité de créer des indexes bitmaps.
    (Je viens même de remarquer que contrairement à ce que je disais, j'ai également la possibilité de créer des tables partitionnées -> il faut que je check les infos sur la licence qu'on a achetée...)

    On estime la plus grosse table à 30Go pour l'instant.
    Et on aura 4 ou 5 autres tables qui dépasseront les 10Go.

    Merci,
    Nicolas

  5. #5
    Modérateur

    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    7 701
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Teradata

    Informations forums :
    Inscription : septembre 2008
    Messages : 7 701
    Points : 16 055
    Points
    16 055

    Par défaut

    30 Go ce n'est pas énorme non plus mais le partitionnement - si vous avez en effet l'option - c'est toujours intéressant à mettre en place.
    Moins d'I/O, moins de ressources consommées inutilement, une machine plus disponible.

Discussions similaires

  1. Bonne pratique sur les variables
    Par cetteame dans le forum Général JavaScript
    Réponses: 13
    Dernier message: 07/09/2012, 10h59
  2. JSF et bonnes pratiques sur le scope des beans
    Par RiiiDD dans le forum JSF
    Réponses: 2
    Dernier message: 22/03/2011, 11h16
  3. [Nexus] Bonne pratique sur les repos ?
    Par ZeKiD dans le forum Maven
    Réponses: 0
    Dernier message: 08/03/2011, 16h29
  4. Réponses: 1
    Dernier message: 18/02/2009, 18h40
  5. Bonnes pratiques sur les versions de Java et JDK
    Par JPDMJC dans le forum Général Java
    Réponses: 4
    Dernier message: 20/12/2007, 15h52

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo