Skip to content

Les bases de données OLAP doivent-elles être dénormalisées pour les performances de lecture ?

Enfin, après beaucoup de travail, nous avons déjà trouvé le résultat de ce bourrage que certains de nos utilisateurs de notre site Web ont eu. Si vous souhaitez apporter des informations, n'arrêtez pas d'apporter vos connaissances.

Solution :

Mythologie

J'ai toujours pensé que les bases de données devraient être dénormalisées pour la lecture, comme cela est fait pour la conception de bases de données OLAP, et ne pas exagérer beaucoup plus loin 3NF pour la conception OLTP.

Il y a un mythe à cet effet. Dans le contexte des bases de données relationnelles, j'ai réimplémenté six très grandes "bases de données" dites "dé-normalisées" ; et exécuté plus de quatre-vingts missions de correction de problèmes sur d'autres, simplement en les normalisant, en appliquant les normes et les principes d'ingénierie. Je n'ai jamais vu la moindre preuve de ce mythe. Seulement des gens qui répètent le mantra comme si c'était une sorte de prière magique.

Normalisation contre non normalisation

("Dé-normalisation" est un terme frauduleux que je refuse d'utiliser).

Il s'agit d'une industrie scientifique (du moins la partie qui fournit des logiciels qui ne se cassent pas ; qui a mis des gens sur la Lune ; qui fait fonctionner des systèmes bancaires ; etc). Elle est régie par les lois de la physique, pas par la magie. Les ordinateurs et les logiciels sont tous des objets finis, tangibles, physiques, soumis aux lois de la physique. Selon l'enseignement secondaire et tertiaire que j'ai reçu :

  • il n'est pas possible qu'un objet plus gros, plus gras et moins organisé soit plus performant qu'un objet plus petit, plus fin et plus organisé.

  • La normalisation donne plus de tables, oui, mais chaque table est beaucoup plus petite. Et même s'il y a plus de tables, il y a en fait (a) moins de jointures et (b) les jointures sont plus rapides car les ensembles sont plus petits. Moins d'index sont nécessaires dans l'ensemble, car chaque table plus petite nécessite moins d'index. Les tables normalisées ont également des tailles de lignes beaucoup plus courtes.

  • pour tout ensemble donné de ressources, tables normalisées :

    • font tenir plus de rangées dans la même taille de page
    • donc plus de lignes dans le même espace de cache, donc augmentation du débit global)
    • donc plus de lignes dans le même espace disque, donc le nombre d'entrées/sorties est réduit.ced; et lorsque des E/S sont demandées, chaque E/S est plus efficace.
      .
  • il n'est pas possible qu'un objet fortement dupliqué ait de meilleures performances qu'un objet stocké comme une seule version de la vérité. Par exemple, lorsque j'ai supprimé la duplication 5 x au niveau des tables et des colonnes, toutes les transactions ont été réduites en taille...e; le verrouillage a été réduitced; les anomalies de mise à jour ont disparu. Cela a considérablement réduit la contention et donc augmenté l'utilisation simultanée.

Le résultat global était donc des performances beaucoup, beaucoup plus élevées.

Dans mon expérience, qui fournit à la fois OLTP et OLAP à partir de la même base de données, il n'y a jamais eu besoin de "dé-normaliser" mes structures normalisées, pour obtenir une vitesse plus élevée pour les requêtes en lecture seule (OLAP). C'est également un mythe.

  • Non, la "dé-normalisation" demandée par d'autres réduisait la vitesse, et elle a été éliminée. Pas de surprise pour moi, mais là encore, les demandeurs ont été surpris.

De nombreux livres ont été écrits par des personnes, vendant le mythe. Il faut reconnaître qu'il s'agit de personnes non techniques.e; puisqu'ils vendent de la magie, la magie qu'ils vendent n'a aucune base scientifique, et ils évitent commodément les lois de la physique dans leur discours de vente.

(Pour toute personne qui souhaite contester la science physique ci-dessus, la simple répétition du mantra n'aura aucun effet, veuillez fournir des preuves spécifiques soutenant le mantra).

Pourquoi ce mythe est-il répandu ?

Eh bien, tout d'abord, il n'est pas répandu parmi les types scientifiques, qui ne cherchent pas de moyens de surmonter les lois de la physique.

D'après mon expérience, j'ai identifié trois raisons majeures à cette prévalence :

  1. Pour les personnes qui ne peuvent pas normaliser leurs données, c'est une justification pratique pour ne pas le faire. Ils peuvent se référer au livre magique et sans aucune preuve de la magie, ils peuvent dire avec révérence "voyez un écrivain célèbre valide ce que j'ai fait". Pas fait, le plus exactement du monde.

  2. Beaucoup de codeurs SQL ne peuvent écrire que du SQL simple, à un seul niveau. Les structures normalisées nécessitent un peu de capacité SQL. S'ils ne l'ont pas ; s'ils ne peuvent pas produire des SELECT sans utiliser des tables temporaires ; s'ils ne peuvent pas écrire des Sous-requêtes, ils seront psychologiquement collés à la hanche aux fichiers plats (ce que sont les structures "dé-normalisées"), qu'ils... peuvent traiter.

  3. Personnes aiment lire des livres, et discuter de théories. Sans expérience. Surtout en matière de magie. C'est un tonique, un substitut à l'expérience réelle. Quiconque a réellement normalisé une base de données correctement n'a jamais déclaré que "la dé-normalisation est plus rapide que la normalisation". A quiconque énonce ce mantra, je dis simplement "montrez-moi les preuves", et ils n'en ont jamais produit. Donc la réalité est que les gens répètent la mythologie pour ces raisons, sans aucune expérience de la normalisation. Nous sommes des animaux de troupeau, et l'inconnu est l'une de nos plus grandes peurs.

    C'est pourquoi j'inclus toujours du SQL "avancé" et du mentorat dans tout projet.

Ma réponse

Cette réponse va être ridiculement longue si je réponds à chaque partie de votre question ou si je réponds aux éléments incorrects dans certaines des autres réponses. Ex : ce qui précède n'a répondu qu'à un seul élément. Par conséquent, je vais répondre à votre question dans son ensemble, sans aborder les éléments spécifiques, et adopter une approche différente. Je ne traiterai que de la science liée à votre question, pour laquelle je suis qualifié et très expérimenté.

Laissez-moi vous présenter la science en segments gérables.
Première génération typique
Le modèle typique des six missions de mise en œuvre complète à grande échelle.

  • Il s'agissait des "bases de données" fermées que l'on trouve généralement dans les petites entreprises, et les organisations étaient de grandes banques...
  • très bien pour une première génération, un état d'esprit de mise en route, mais un échec complet en termes de performance, d'intégrité et de qualité.
  • ils ont été conçus pour chaque application, séparément
  • le reporting n'était pas possible, ils ne pouvaient le faire que via chaque app.
  • comme "dé-normalisé" est un mythe, la définition technique exacte est, ils étaient non normalisés
    • pour "dé-normaliser", il faut d'abord normaliser ; puis inverser un peu le processus
      dans tous les cas où les gens m'ont montré leurs modèles de données "dé-normalisés", le simple fait était qu'ils n'avaient pas du tout normalisé ; donc la "dé-normalisation" n'était pas possible.e; c'était simplement non normalisé
  • puisqu'ils n'avaient pas beaucoup de technologie relationnelle, ou les structures et le contrôle des bases de données, mais ils passaient pour des "bases de données", j'ai mis ces mots entre guillemets...
  • comme c'est scientifiquement garanti pour les structures non normalisées, elles souffraient de multiples versions de la vérité (duplication des données) et donc d'une forte contention et d'une faible concurrence, à l'intérieur de chacune d'entre elles.
  • ils avaient un problème supplémentaire de duplication de données à travers les "bases de données"
  • l'organisation essayait de garder tous ces doublons synchronisés, donc ils ont implémenté la réplication ; ce qui bien sûr signifiait un serveur supplémentaire ; ETL et des scripts de synchronisation à développer.ed; et à maintenired; etc
  • Inutile de dire que la synchronisation n'était jamais suffisante et qu'ils la modifiaient constamment.
  • avec toute cette contention et ce faible débit, ce n'était pas du tout un problème de justifier un serveur séparé pour chaque "base de données". Cela n'a pas beaucoup aidé.

Alors nous avons contemplé les lois de la physique, et nous avons appliqué un peu de science.
Base de données d'entreprise 5NF
Nous avons mis en œuvre le concept standard selon lequel les données appartiennent à la société (pas aux départements) et la société voulait une seule version de la vérité. La base de données était purement relationnelle, normalisée en 5NF. Architecture ouverte pure, afin que n'importe quelle application ou outil de rapport puisse y accéder. Toutes les transactions étaient stockées dans des procs (par opposition à des chaînes de SQL incontrôlées sur tout le réseau). Les mêmes développeurs pour chaque app codaient les nouvelles apps, après notre formation "avancée".

De toute évidence, la science a fonctionné. Eh bien, ce n'était pas ma science privée ou ma magie, c'était de l'ingénierie ordinaire et les lois de la physique. Tout cela fonctionnait sur une plateforme de serveur de base de données ; deux paires (production & DR) de serveurs ont été mises hors service et données à un autre département. Les 5 "bases de données" totalisant 720 Go ont été normalisées en une seule base de données de 450 Go. Environ 700 tables (beaucoup de doublons et de colonnes dupliquées) ont été normalisées en 500 tables non dupliquées. Les performances ont été beaucoup plus rapides, 10 fois plus rapides dans l'ensemble, et plus de 100 fois plus rapides dans certaines fonctions. Cela ne m'a pas surpris, car c'était mon intention, et la science l'avait prédit, mais cela a surpris les gens avec le mantra.

Plus de normalisation

Eh bien, ayant eu du succès avec la normalisation dans chaque projet, et la confiance avec la science impliquée, cela a été une progression naturelle de normaliser... plus et non moins. Dans le passé, 3NF était suffisant, et les NF ultérieures n'étaient pas encore identifiées. Au cours des 20 dernières années, je n'ai livré que des bases de données qui n'avaient aucune anomalie de mise à jour, donc il s'avère que selon les définitions actuelles des NFs, j'ai toujours livré 5NF.

De même, 5NF est génial mais il a ses limites. Par exemple, le pivotement de grandes tables (et non de petits ensembles de résultats comme dans l'extension PIVOT de MS) était lent. J'ai donc (et d'autres) développé un moyen de fournir des tableaux normalisés de sorte que le pivotement soit (a) facile et (b) très rapide. Il s'avère, maintenant que la 6NF a été définie, que ces tables sont 6NF.

Depuis que je fournis des OLAP et des OLTP à partir de la même base de données, j'ai constaté que, conformément à la science, plus les structures sont normalisées :

  • plus elles sont rapides

  • et elles peuvent être utilisées de plus de façons (ex : Pivots).

Donc oui, j'ai une expérience cohérente et invariable, que non seulement Normalisé est beaucoup, beaucoup plus rapide que non normalisé ou "dé-normalisé" ; plus Normalisé est même plus rapide que moins normalisé.

Un signe de réussite est la croissance des fonctionnalités (le signe d'échec est la croissance de la taille sans croissance des fonctionnalités). Ce qui signifie qu'ils nous ont immédiatement demandé plus de fonctionnalités de reporting, ce qui signifie que nous... Normalisé encore plus et fourni plus de ces tableaux spécialisés (qui se sont avérés des années plus tard, être 6NF).

En progressant sur ce thème. J'ai toujours été un spécialiste des bases de données, pas un spécialiste des entrepôts de données, donc mes quelques premiers projets avec des entrepôts n'étaient pas des implémentations complètes, mais plutôt des missions substantielles d'optimisation des performances. Ils étaient dans mon ambit, sur des produits dont j'étais spécialiste.
Entrepôt de données typique
Ne nous préoccupons pas du niveau exact de normalisation, etc, car nous examinons le cas typique. Nous pouvons considérer que la base de données OLTP était raisonnablement normalisée, mais qu'elle n'était pas capable d'OLAP, et que l'organisation avait acheté une plateforme OLAP complètement séparée, hardwar...e; investi dans le développement et la maintenance de masses de coentreprises ETL.de; etc. Et après la mise en œuvre, ils ont ensuite passé la moitié de leur vie à gérer les doublons qu'ils avaient créés. Ici, les auteurs de livres et les vendeurs doivent être blâmés pour le gaspillage massif de matériel et de ressources. séparés de licences de logiciels de plates-formes séparées qu'ils font acheter aux organisations.

  • Si vous ne l'avez pas encore observé, je vous demande de remarquer les similitudes entre les "base de données" typique de première génération et la entrepôt de données typique

Pendant ce temps, de retour à la ferme (la Bases de données 5NF ci-dessus), nous avons juste continué à ajouter de plus en plus de fonctionnalités OLAP. Bien sûr, la fonctionnalité de l'application a augmenté, mais c'était peu, le business n'avait pas changé. Ils demandaient plus de 6NF et c'était facile à fournir (5NF à 6NF est un petit pas ; 0NF à quoi que ce soit, sans parler de 5NF, est un grand pas ; une architecture organisée est facile à étendre).

Une différence majeure entre l'OLTP et l'OLAP, la justification de base de l'OLTP. séparé logiciel de plateforme OLAP, est que l'OLTP est orienté lignes, il a besoin de lignes transactionnellement sécurisées, et rapides ; et l'OLAP ne se soucie pas des questions transactionnelles, il a besoin de colonnes, et rapides. C'est la raison pour laquelle tous les logiciels haut de gamme de BI ou OLAP haut de gamme sont orientées colonnes, et c'est pourquoi l'OLAP modèles (Star Schema, Dimension-Fact) sont orientés colonnes.

Mais avec les tables 6NF :

  • il n'y a pas de lignes, seulement des colonnes ; on sert des lignes et des colonnes à la même vitesse aveuglante.

  • les tables (c'est-à-dire la vue 5NF des structures 6NF) sont déjà organisées en Dimensions-Faits. En fait, elles sont organisées en plus de Dimensions que tout modèle OLAP ne pourra jamais identifier, parce qu'elles sont tous Dimensions.

  • Le pivotement de tableaux entiers avec agrégation à la volée (par opposition au PIVOT d'un petit nombre de colonnes dérivées) est (a) sans effort, de code simple et (b) très rapide.
    Entrepôt de données typique

Ce que nous fournissons depuis de nombreuses années, par définition, ce sont des bases de données relationnelles avec au moins 5NF pour une utilisation OLTP, et 6NF pour les besoins OLAP.

  • Remarquez que c'est la même science que nous avons utilisée depuis le début ; pour passer de... Des "bases de données" typiques non normalisées. à Base de données d'entreprise 5NF. Nous appliquons simplement plus de de la science éprouvée, et d'obtenir des ordres supérieurs de fonctionnalité et de performance.

  • Remarquez la similitude entre la base de données d'entreprise 5NF et Base de données d'entreprise 6NF

  • Tout le coût du matériel OLAP séparé, du logiciel de la plateforme, de l'ETL, de l'administration, de la maintenance, sont éliminés.

  • Il n'y a qu'une seule version des données, pas d'anomalies de mise à jour ou de maintenance de celles-ci.f; les mêmes données servies pour OLTP en lignes, et pour OLAP en colonnes.

La seule chose que nous n'avons pas faite, c'est de commencer un nouveau projet, et de déclarer du 6NF pur dès le départ. C'est ce que j'ai prévu pour la suite.

Qu'est-ce que la Sixième Forme Normale ?

En supposant que vous ayez une poignée sur la normalisation (je ne vais pas ne pas la définir ici), les définitions non académiques pertinentes pour ce fil sont les suivantes. Notez que cela s'applique au niveau de la table, donc vous pouvez avoir un mélange de tables 5NF et 6NF dans la même base de données :

  • Cinquième forme normale: toutes les dépendances fonctionnelles résolues dans la base de données.
    • en plus de 4NF/BCNF
    • chaque colonne non-PK est 1::1 avec sa PK
    • et avec aucun autre PK
    • Aucune anomalie de mise à jour
      .
  • Sixième forme normale
    • : est le NF irréductible, le point auquel les données ne peuvent plus être réduites ou normalisées (il n'y aura pas de 7NF)
      • en plus de 5NF
      • la ligne est constituée d'une clé primaire, et au plus, d'une colonne non clé.
      • élimine le problème des nuls

    A quoi ressemble la 6NF ?

    Les modèles de données appartiennent aux clients, et notre propriété intellectuelle n'est pas disponible pour une publication gratuite. Mais je suis présent sur ce site web, et je fournis des réponses spécifiques aux questions. Vous avez besoin d'un exemple concret, je vais donc publier le modèle de données d'un de nos utilitaires internes.

    Celui-ci est destiné à la collecte de données de surveillance de serveurs (serveur de base de données et OS de classe entreprise) pour n'importe quel nombre de clients, pour n'importe quelle période. Nous utilisons ces données pour analyser les problèmes de performance à distance et pour vérifier les réglages de performance que nous effectuons. La structure n'a pas changé depuis plus de dix ans (ajouts, sans modification des structures existantes), elle est typique de la 5NF spécialisée qui, plusieurs années plus tard, a été identifiée comme 6NF. Permet un pivotement complet ; n'importe quel diagramme ou graphique à dessiner, sur n'importe quelle Dimension (22 Pivots sont fournis mais ce n'est pas une limite) ; slice and di...ce; mélanger et assortir. Remarquez qu'ils sont tous Dimensions.

    Les données de surveillance ou les Métriques ou les vecteurs peuvent changer (la version du serveur change ; nous voulons capter quelque chose de plus) sans affecter le modèle (vous vous souvenez peut-être que dans un autre post j'ai déclaré que l'EAV est le fils bâtard de la 6NF ; et bien ceci est de la 6NF complète, le père non dilué, et fournit donc toutes les fonctionnalités de l'EAV, sans sacrifier aucune norme, intégrité ou puissance relationnelle) ; vous ajoutez simplement des lignes.

    ▶Moniteur de statistiques Modèle de données◀. (trop grand pour l'inline; certains navigateurs ne peuvent pas charger inline; cliquez sur le lien)

    Il me permet de produire ces ▶Chartes comme ça◀ six frappes après avoir reçu un fichier de statistiques de surveillance brut du client. Remarquez le mélange des genres ; le système d'exploitation et le serveur sur le même graphique ; une variété de points pivots. (Utilisé avec permission.)

    Les lecteurs qui ne sont pas familiers avec la norme pour la modélisation des bases de données relationnelles peuvent trouver les ▶IDEF1X Notation◀ utile.

    6NF Data Warehouse

    Ceci a été récemment validé par Anchor Modeling, dans la mesure où ils présentent maintenant 6NF comme le modèle OLAP "nouvelle génération" pour les entrepôts de données. (Ils ne fournissent pas l'OLTP et l'OLAP à partir de la version unique des données, cela n'appartient qu'à nous).

    Expérience des entrepôts de données (uniquement)

    Mon expérience avec les entrepôts de données seulement (pas les bases de données OLTP-OLAP 6NF ci-dessus), a été plusieurs missions importantes, par opposition à des projets de mise en œuvre complète. Les résultats ont été, sans surprise :

    • Conformément à la science, les structures normalisées sont beaucoup plus rapides, plus faciles à maintenir et nécessitent moins de synchronisation des données. Inmon, pas Kimball.

    • cohérent avec la magie, après que j'ai normalisé un tas de tables, et fourni des performances substantiellement améliorées via l'application des lois de la physique, les seules personnes surprises sont les magiciens avec leurs mantras.

    Les gens à l'esprit scientifique ne font pas cela ; ils ne croient pas en, ou ne comptent pas sur, les balles d'argent et les magi...c; ils utilisent et travaillent dur la science pour résoudre leurs problèmes.

    Justification valide d'un entrepôt de données

    C'est pourquoi j'ai déclaré dans d'autres posts, la seule... valide justification pour une plateforme d'entrepôt de données séparée, le matériel, l'ETL, la maintenance, etc, est lorsqu'il y a de nombreuses bases de données ou "bases de données", toutes fusionnées dans un entrepôt central, pour le reporting et l'OLAP.

    Kimball

    Un mot sur Kimball est nécessaire, car il est le principal partisan de la "dé-normalisation pour la performance" dans les entrepôts de données. Selon mes définitions ci-dessus, il fait partie de ces personnes qui ont... de toute évidence jamais normalisé de leur vie ; son point de départ était non normalisé (camouflé en "dé-normalisé") et il a simplement implémenté cela dans un modèle Dimension-Fact.

    • Bien sûr, pour obtenir une quelconque performance, il a dû "dé-normaliser" encore plus, et créer d'autres doublons, et justifier tout cela.

      • Il est donc vrai, de façon un peu schizophrénique, que "dé-normaliser" des structures non normalisées, en faisant des copies plus spécialisées, "améliore les performances de lecture". Ce n'est pas vrai lorsque l'ensemble est pris en compte ; ce n'est vrai qu'à l'intérieur de ce petit asile, pas à l'extérieur.

      • De même, il est vrai, de cette façon folle, que là où toutes les "tables" sont des monstres, que "les jointures sont coûteuses" et quelque chose à éviter. Ils n'ont jamais eu l'expérience de joindre des tables et des ensembles plus petits, donc ils ne peuvent pas croire le fait scientifique que des tables plus nombreuses et plus petites sont plus rapides.

      • ils ont l'expérience que créer des "tables" en double est plus rapide, donc ils ne peuvent pas croire que en éliminant duplicata est encore plus rapide que cela.

    • ses Dimensions sont ajouté aux données non normalisées. Eh bien les données ne sont pas Normalisées, donc aucune Dimensions n'est exposée. Alors que dans un modèle normalisé, les Dimensions sont déjà exposées, en tant que partie intégrante des données, pas de ajout n'est nécessaire.

    • ce chemin bien pavé de Kimball mène à la falaise, où plus de lemmings tombent vers leur mort, plus rapidement. Les lemmings sont des animaux de troupeau, tant qu'ils marchent ensemble sur le chemin, et meurent ensemble, ils meurent heureux. Les lemmings ne cherchent pas d'autres chemins.

    Tout n'est que des histoires, des parties de la même mythologie qui traînent ensemble et se soutiennent mutuellement.

    Votre mission

    Si vous choisissez de l'accepter. Je vous demande de penser par vous-même, et d'arrêter d'entretenir toute pensée qui contredit la science et les lois de la physique. Peu importe qu'elles soient communes, mystiques ou mythologiques. Cherchez des preuves de tout ce que vous croyez avant de vous y fier. Soyez scientifique, vérifiez les nouvelles croyances par vous-même. Répéter le mantra "dé-normalisé pour la performance" ne rendra pas votre base de données plus rapide, cela vous fera juste vous sentir mieux. Comme le gros gamin assis sur la touche qui se dit qu'il peut courir plus vite que tous les enfants de la course.

    • sur cette base, même le concept "normaliser pour OLTP" mais faire le contraire, "dé-normaliser pour OLAP" est une contradiction. Comment les lois de la physique peuvent-elles fonctionner comme indiqué sur un ordinateur, mais fonctionner en sens inverse sur un autre ordinateur ? C'est à n'y rien comprendre. Ce n'est tout simplement pas possible, les fonctionnent de la même façon sur chaque ordinateur.

    Questions ?

    La dénormalisation et l'agrégation sont les deux principales stratégies utilisées pour obtenir des performances dans un entrepôt de données. C'est juste idiot de suggérer que cela n'améliore pas les performances de lecture ! Je dois certainement avoir mal compris quelque chose ici ?

    Agrégation :
    Considérons une table contenant 1 milliard d'achats.
    Comparez-la avec une table contenant une ligne avec la somme des achats.
    Maintenant, lequel est le plus rapide ? Sélectionner sum(amount) à partir de la table contenant un milliard de lignes ou sélectionner amount à partir de la table contenant une seule ligne ? C'est un exemple stupide bien sûr, mais il illustre très clairement le principe de l'agrégation. Pourquoi est-ce plus rapide ? Parce que, quel que soit le modèle magique, le matériel, le logiciel ou la religion que nous utilisons, lire 100 octets est plus rapide que lire 100 gigaoctets. C'est aussi simple que cela.

    Dénormalisation :
    Une dimension produit typique dans un entrepôt de données de vente au détail a des charges de merde de colonnes. Certaines colonnes sont des trucs faciles comme "Nom" ou "Couleur", mais elle a aussi des trucs compliqués, comme des hiérarchies. Des hiérarchies multiples (la gamme de produits (5 niveaux), l'acheteur prévu (3 niveaux), les matières premières (8 niveaux), le mode de production (8 niveaux) ainsi que plusieurs nombres calculés tels que le délai de livraison moyen (depuis le début de l'année), les mesures de poids/emballage, etc. etc. J'ai tenu à jour un tableau de dimensions de produit avec 200+ colonnes qui a été construit à partir de ~70 tableaux provenant de 5 systèmes sources différents. Il est tout simplement stupide de débattre si une requête sur le modèle normalisé (ci-dessous)

    select product_id
      from table1
      join table2 on(keys)
      join (select average(..)
              from one_billion_row_table 
             where lastyear = ...) on(keys)
      join ...table70
     where function_with_fuzzy_matching(table1.cola, table37.colb) > 0.7
       and exists(select ... from )
       and not exists(select ...)
       and table20.version_id = (select max(v_id from product_ver where ...)
       and average_price between 10 and 20
       and product_range = 'High-Profile'
    

    ...est plus rapide que la requête équivalente sur le modèle dénormalisé :

    select product_id
      from product_denormalized
     where average_price between 10 and 20
       and product_range = 'High-Profile';
    

    Pourquoi ? En partie pour la même raison que le scénario agrégé. Mais aussi parce que les requêtes sont juste "compliquées". Elles sont si dégoûtamment compliquées que l'optimiseur (et maintenant je vais les spécificités d'Oracle) s'embrouille et fout en l'air les plans d'exécution. Les plans d'exécution sous-optimaux ne sont peut-être pas si importants si la requête porte sur de petites quantités de données. Mais dès que nous commençons à joindre les grandes tables, c'est... crucial que la base de données obtienne le bon plan d'exécution. Après avoir dénormalisé les données dans une table avec une seule clé syntaxique (pourquoi ne pas ajouter plus de combustible à ce feu continu), les filtres deviennent de simples filtres de plage/égalité sur des colonnes précuites. Le fait d'avoir dupliqué les données dans de nouvelles colonnes nous permet de rassembler des statistiques sur les colonnes qui aideront l'optimiseur à estimer les sélectivités et donc à nous fournir un plan d'exécution adéquat (enfin, ...).

    Évidemment, l'utilisation de la dénormalisation et de l'agrégation rend plus difficile l'adaptation aux changements de schéma, ce qui est une mauvaise chose. D'autre part, ils fournit des performances de lecture, ce qui est une bonne chose.

    Donc, devez-vous dénormaliser votre base de données afin d'obtenir des performances de lecture ?
    Bien sûr que non ! Cela ajoute tellement de complexités à votre système qu'il n'y a pas de fin au nombre de façons dont il va vous entuber avant que vous ayez livré. Cela en vaut-il la peine ? Oui, parfois vous devez le faire pour répondre à une exigence de performance spécifique.

    Mise à jour 1

    PerformanceDBA : 1 ligne serait mise à jour un milliard de fois par jour.

    Cela impliquerait une exigence de temps (presque) réel (qui à son tour générerait un ensemble complètement différent d'exigences techniques). De nombreux entrepôts de données (si ce n'est la plupart) n'ont pas cette exigence. J'ai choisi un exemple d'agrégation irréaliste afin de montrer clairement pourquoi l'agrégation fonctionne. Je ne voulais pas avoir à expliquer les stratégies de rollup aussi :).

    En outre, il faut opposer les besoins de l'utilisateur typique d'un entrepôt de données et l'utilisateur typique du système OLTP sous-jacent. Un utilisateur qui cherche à comprendre quels sont les facteurs qui déterminent les coûts de transport, ne pourrait pas se soucier moins de savoir si 50% des données du jour sont manquantes ou si 10 camions ont explosé et tué les conducteurs. En effectuant l'analyse sur des données de deux ans, il arriverait toujours à la même conclusion, même s'il disposait d'informations actualisées à la seconde près.

    Comparez cela aux besoins des conducteurs de ce camion (ceux qui ont survécu). Ils ne peuvent pas attendre 5 heures à un point de transit juste parce qu'un stupide processus d'agrégation doit se terminer. Avoir deux copies séparées des données résout les deux besoins.

    Un autre obstacle majeur au partage du même ensemble de données pour les systèmes opérationnels et les systèmes de reporting est que les cycles de publication, les Q&A, le déploiement, les SLA et quoi encore, sont très différents. Encore une fois, avoir deux copies séparées rend cela plus facile à gérer.

    Par "OLAP", je comprends que vous voulez dire une base de données relationnelle / SQL orientée sujet utilisée pour l'aide à la décision - AKA un entrepôt de données.

    La forme normale (typiquement la 5e / 6e forme normale) est généralement le meilleur modèle pour un Data Warehouse. Les raisons de normaliser un Data Warehouse sont exactement les mêmes que pour toute autre base de données : cela réduit la redondance et évite les anomalies potentielles de mise à jour ; cela évite les biais intégrés et c'est donc le moyen le plus facile de supporter les changements de schéma et les nouvelles exigences. L'utilisation de la forme normale dans un entrepôt de données permet également de garder le processus de chargement des données simple et cohérent.

    Il n'y a pas d'approche de dénormalisation " traditionnelle ". Les bons entrepôts de données ont toujours été normalisés.

    Si vous acceptez, vous avez la possibilité de laisser un message sur ce qui vous a impressionné dans cette division.



    Utilisez notre moteur de recherche

    Ricerca
    Generic filters

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée.