Index insanity: comment éviter le chaos des bases de données

2024

Table des matières:

Partenaire de contenu Techopedia
Partenaire de contenu Techopedia

Par Techopedia Staff, 5 octobre 2016

À retenir: l' hôte Eric Kavanagh discute de l'indexation des bases de données avec le Dr Robin Bloor, Dez Blanchfield et Bert Scalzo d'IDERA.

Vous n'êtes actuellement pas connecté. Veuillez vous connecter ou vous inscrire pour voir la vidéo.

Partenaire de contenu Techopedia

Le personnel de Techopedia est affilié à Bloor Group et peut être contacté en utilisant les options à droite. Pour plus d'informations sur la façon dont nous travaillons avec les partenaires de l'industrie, cliquez ici.

Profil
Site Internet

Eric Kavanagh: Mesdames et messieurs, bonjour et bienvenue encore une fois. C'est un mercredi, à quatre heures de l'Est, et ceux d'entre vous qui connaissent le programme savent ce que cela signifie, il est temps pour un autre épisode de Hot Technologies. Oui en effet. Mon nom est Eric Kavanagh, je serai votre modérateur pour la session d'aujourd'hui: "Index Insanity: Comment éviter le chaos des bases de données." Ou comme je l'ai mentionné dans la dernière explosion de courrier électronique à sortir, "la dispute de la base de données." Terme chaud ces jours-ci, "la dispute". Tout le monde le fait. Il y a vraiment une diapositive sur la vôtre. Et assez parlé de moi.

Ainsi, la série Hot Technology a vraiment été conçue pour définir un espace particulier, contrairement à la salle de briefing qui n'est qu'un briefing d'analyste en direct, pour Hot Tech, nous avons deux analystes. Aujourd'hui, ce sera notre propre docteur Robin Bloor et notre data scientist Dez Blanchfield. Et nous parlons d'un sujet qui, je pense, est vraiment assez emblématique de ce qui se passe sur le marché aujourd'hui.

L'essentiel est que nous sommes dans un monde de complexité ces jours-ci. Vraiment, si vous repensez à quinze ou vingt ans, c'était un monde très différent à l'époque, surtout en ce qui concerne la technologie des bases de données. Les bases de données étaient auparavant assez simples. Il n'y en avait qu'une poignée; la plupart d'entre eux étaient relationnels. Maintenant, nous avons toute cette panoplie de technologies de base de données. Des dizaines d'options sur la table pour quiconque souhaite créer une application ou faire quelque chose avec des données. Tout change et cela affecte les personnes qui tentent de gérer ces systèmes. Nous allons parler aujourd'hui avec Bert Scalzo, qui est un vrai expert dans le domaine; il est le responsable produit senior d'IDERA, sur ce que vous pouvez faire pour maîtriser toutes ces données. Sur ce, je vais le remettre au docteur Robin Bloor pour le retirer. Robin, la parole est à vous.

Robin Bloor: D'accord, merci pour cette introduction. Je le pense - parce que c'est une chose à deux mains, je pense que je voudrais simplement parler de l'optimisation de la base de données en général comme une introduction à cette émission de Hot Tech. J'ai commencé ma vie - dans la technologie et l'analyse - j'ai commencé la vie en faisant cela parce que j'avais l'habitude d'écrire des articles sur les capacités des bases de données sur la plate-forme DEC VAX. Et pour cette raison, les utilisateurs de bases de données m'informaient. Et la chose qui me vient à l'esprit est que, pourquoi auriez-vous une base de données? Je veux dire, à cette époque, beaucoup de gens utilisaient pour créer des fichiers de valeurs clés et les utiliser pour avoir une sorte de sophisme séquentiel d'index comme nous les appelons, mais pour créer une sorte de capacité de base de données, et vous savez, pourquoi auriez-vous rien d'autre?

Et la réponse à cela, je pense que Michael Stonebraker a donné la meilleure réponse à cela, et il a dit: "Une base de données peut en savoir plus sur où se trouvent les données et à quelle vitesse les obtenir, que tout programme ne peut jamais savoir." Et je pense que c'est intéressant; c'est la nature du jeu. Mais dans le 19 - vers 1989 que j'ai commencé dans l'analyse technologique et vous savez, à ce moment-là, les bases de données étaient très simples et les bases de données relationnelles étaient super simples. Ils avaient si peu de capacités, je veux dire, ils pouvaient stocker des données, évidemment, et vous pouviez sauvegarder et ils l'avaient fait, ils étaient conformes à ACID, mais ils avaient vraiment des optimiseurs très faibles. En fait, il serait difficile de prétendre qu'ils avaient la capacité d'optimisation du tout.

Et plus tard, ils sont de mieux en mieux, mais, vous savez, quand une base de données ne fonctionne pas - comme ces kangourous semblent être d'une manière ou d'une autre indiquant - il peut y avoir énormément de raisons pour lesquelles cela ralentit. Et cela m'amène au fait: les bases de données ont de nombreuses fonctions, mais la plus importante est l'optimisation des requêtes. S'ils ne le faisaient pas, vous ne les utiliseriez pas. Il s'agit d'obtenir rapidement des informations, de pouvoir le faire quand il y a beaucoup d'utilisateurs simultanés, et c'est un problème difficile. Et quand vous regardez réellement les, appelons-les bases de données matures, si vous le souhaitez - mais certainement Oracle, dans une moindre mesure, Microsoft SQL Server, certainement Teradata et DB2 - les optimiseurs de ces bases de données ont, ont été des décennies dans le bâtiment. Vous savez, ils n'ont pas - quelqu'un ne s'est pas assis - six gars sur un projet de deux hommes, année et juste en assommer un. Ça ne marche pas comme ça. La capacité d'optimisation s'est progressivement développée et il faut beaucoup de croissance. Quoi qu'il en soit, parlons de l'arrière-plan de la base de données. Eh bien, il y a énormément de choses à dire sur la base de données NoSQL maintenant, et il y a même beaucoup d'enthousiasme pour la base de données graphique. Et l'utilisation de SQL sur Hadoop et des choses comme ça. Mais, la vérité est que si vous voulez une base de données en ce moment, si vous voulez une fonctionnalité complète, capable d'OLTP et de trafic de requêtes important, c'est une base de données relationnelle, ou ce n'est rien.

Parmi les bases de données relationnelles, Oracle domine en popularité. Microsoft SQL Server, je pense, est le deuxième. Ils sont tous les deux capables d'être utilisés pour OLTP et la charge de travail de requête, mais en réalité, vous ne pouvez vraiment pas vous passer de mélanger ces charges de travail. Vous avez besoin de différents incidents pour les charges de travail OLTP et les charges de travail de requête. Il existe des alternatives à SQL et au graphique. La plupart des entreprises standardisent sur une base de données spécifique, c'est pourquoi - je veux dire après des décennies de lutte avec tous les autres joueurs, Oracle est devenu le plus dominant. Tout simplement parce qu’ils ont fini par vendre des licences d’entreprise et que les entreprises n’utilisaient donc que des produits alternatifs dans des produits exceptionnels, Oracle ne les aurait tout simplement pas. Et les bases de données sont stratégiques dans la mesure où elles évoluent également. Et vous savez que j'ai fait un peu de recherche pour cette présentation, et c'est un peu - j'y reviendrai dans un moment, mais c'est assez intéressant de voir comment ils évoluent, en termes de regard depuis le DBA. C'est ce que j'appelle la tendance invisible. C'est la loi de Moore en cubes. C'est à peu près comme ceci: la plus grande base de données est, et les nouvelles bases de données, il n'y a pas une ancienne base de données qui a beaucoup plus de données à ingérer. Il s'agit normalement d'une base de données appliquée à un nouveau problème. Et ils augmentent en fait en termes de volumes de données. À peu près au cube de Moore loi. La loi de Moore est donc un facteur dix fois tous les six ans. Les VLDB ont tendance à augmenter d'un facteur mille tous les six ans. En 1991, 1992, les grandes bases de données sont mesurées en termes de mégaoctets. En 97 et 98, gigaoctets. 2003, '4, téraoctets. 2009, '10, vous avez commencé à voir des bases de données de pétaoctets. Je pense qu'il y avait peut-être une ou deux bases de données exaoctets en ce moment, mais la plus importante dont j'ai entendu parler était les 200 pétaoctets à temps, et vous savez, ne pas obtenir de données dans une base de données pétaoctets. Mais, c'est surtout que ce seront évidemment les nouvelles grandes sociétés du Web 2.0, peut-être que Facebook a cette direction.

Mais de toute façon, si vous regardez réellement cela, en attendant qu'une base de données passe par ce genre d'escalade de volume, cela demande beaucoup. Et remarquablement, certainement jusqu'au niveau du pétaoctet, ils semblent avoir fait assez bien. Je veux dire, je parle des produits plus anciens plutôt que de quelque chose de nouveau. Ils semblent avoir extraordinairement bien réussi. Si nous regardons les performances de la base de données, les goulots d'étranglement, cela me ramène à l'époque où je me préoccupais réellement d'eux et que je devais me soucier d'eux. Vous savez que c'est fondamentalement la panne du matériel. Il y a des goulots d'étranglement CPU, peut-être, il y a des goulots d'étranglement de mémoire, peut-être, il y a des goulots d'étranglement de disque, peut-être. Cela peut être le réseau qui vous cause du chagrin, et vous pouvez également avoir des problèmes de verrouillage, selon ce que vous faites, mais normalement c'est parce que le programme ne sait pas qui appeler lock. Donc, si vous allez régler une base de données, vous essayez en fait de la régler pour qu'elle danse entre ces cinq goulots d'étranglement possibles aussi bien qu'elle le peut. Et ce n'est pas chose facile, car la quantité de mémoire que vous pouvez configurer sur un serveur donné est considérablement augmentée. Ensuite, les processeurs sont devenus multicœurs, disque, eh bien nous pouvons maintenant le faire, je pense, même sur des serveurs de base, je pense que vous pouvez faire des centaines et des centaines de téraoctets, un quart de pétaoctet, peut-être, même sur un serveur de base. Donc, de toutes ces choses, vous pouvez jouer avec, le réseau peut bien sûr aller à des vitesses différentes, mais surtout lorsque vous traitez avec des bases de données, vous voulez vraiment avoir des câbles en fibre entre les serveurs et rien d'autre ne fonctionne sur cela, en particulier de cette façon.

Facteurs de performance de la base de données. Je veux dire, je laisse de côté tout cela, car je sais que Dez va en parler, mais une mauvaise conception de base de données signifie une base de données peu performante. Une mauvaise conception de programmation peut éventuellement signifier lancer du SQL très stupide dans une base de données, ce qui prendra beaucoup plus de temps. Mélange de simultanéité et de charge de travail, trop de simultanéité entraînera des problèmes de goulot d'étranglement. Le mélange de la charge de travail, lorsque vous avez de grandes requêtes avec des requêtes très petites, courtes et précises, qui pose problème. Il y a un problème d'équilibrage de charge. La plupart des bases de données s'en occupent, mais si vous n'avez pas de produit sophistiqué, alors vous savez, l'ajout de quelques serveurs n'est pas tout ce que vous faites si vous voulez réellement augmenter la taille d'un cluster. Vous devez en fait équilibrer la charge avant d'obtenir les performances optimales. Vous devez planifier la capacité. Absolument. Surtout maintenant de nos jours, lorsque les volumes de données augmentent de façon plus spectaculaire qu'auparavant pour les bases de données. Et il y a des problèmes entiers de couche de données sur la façon dont vous ingérez les données, sur la façon dont vous déplacez les données. Ne pas obtenir les données dans une base de données à temps peut être un problème de performances plus tard, car nous sommes passés de bases de données fonctionnant sous Windows à vingt-quatre par sept par trois cent soixante-quinze et il n'y a pas de fenêtres où vous pouvez ralentir la base de données ou il est peu probable qu'il y en aura de nos jours.

Le problème Oracle DBA. Voilà à quoi je pensais. J'ai été dans le DBA d'Oracle avec Oracle 7, et je me souviens comment régler cela. Et si vous regardez réellement Oracle maintenant, c'est moyen, moyen - il y a moyen, bien plus de capacités. Il y a une indexation bitmap et des choses comme ça, mais j'ai pris le temps de regarder et de voir combien de paramètres de réglage il y a actuellement dans une base de données Oracle. Et il y a plus de trois cent cinquante paramètres de réglage et il y a une centaine de paramètres cachés supplémentaires, que les DBA spécialisés peuvent connaître, mais les DBA Oracle normaux ne le savent pas. Et cela signifie que régler ce type de base de données est une chose difficile. Ce n'est pas du tout une chose simple. Vous devez avoir une idée de cela, vous devez le faire depuis très, très longtemps, et vous devez savoir exactement quel est le problème que vous pensez résoudre, car le réglage commence lorsque le les performances deviennent médiocres, mais ce n'est peut-être pas la performance de tout. Ce sont peut-être les performances de requêtes spécifiques qui importent, et vous pouvez peut-être y remédier en épinglant certaines données et mémoire, ou vous devrez peut-être les corriger en indexant, ou vous devrez peut-être commencer à faire le partitionnement d'une manière différente. Il y a beaucoup de choses que vous pouvez faire, c'est le point. Par conséquent, ils ne vont pas le faire dans leur tête - les administrateurs de base de données ont besoin d'outils. Je vais maintenant passer à Dez qui va vous parler de l'indexation, je pense.

Eric Kavanagh: Très bien Dez, retirez-le.

Dez Blanchfield: Merci, Robin, et j'adore la page de couverture. Je pense que vous avez jeté le gant là-bas pour que je vienne même à distance près de quelque chose d'aussi excitant. Mais j'ai utilisé une image de notre petite galaxie, comme ma vision de ce que le défi d'aujourd'hui pour les administrateurs de base de données est devenu, car c'est l'image mentale que j'ai tendance à évoquer lorsque j'entre dans un environnement et je ne suis plus dans le monde de l'administration de bases de données ou de la conception de bases de données à ce niveau. Mais, comme vous, Robin et moi avons eu de nombreuses années d'implication dans le monde des bases de données, en tant qu'administrateur ou développeur, ou finalement architecte, puis j'ai réalisé que je pouvais faire mieux pour gagner une croûte. Mais il semble que vous regardiez cette galaxie de données, et plus encore aujourd'hui, lorsque nous passons, comme vous l'avez souligné, nous sommes passés de mégaoctets à pétaoctets et à l'échelle exo en très peu de temps, dans le grand schéma des choses. Mais la phrase que j'ai en tête est que les index de base de données sont maintenant un art noir et qu'ils ne sont pas vraiment le genre de choses que les simples mortels devraient tâtonner, pour les applications commerciales de niveau entreprise et le type de formulation que vous parlaient juste. Mais, je voulais passer en revue brièvement le type d'histoire que j'ai eu avec les mondes de base de données et mettre en contexte où nous allons tirer une conclusion, puis parcourir certains documents aujourd'hui avec nos amis de IDERA, parce que je pense qu'il y a beaucoup de pensées différentes sur la façon d'obtenir un réglage des performances de la base de données et l'un d'eux jette de l'étain à la chose. Pour de nombreux magasins que je rencontre, ils n'arrivent invariablement pas au point de régler les performances au niveau de la couche de base de données et en particulier de la couche d'index jusqu'à ce qu'ils aient traversé la voie difficile de penser qu'ils peuvent lancer un tuner dessus .

Beaucoup de gens ont une approche très ironique, dans mon esprit, et j'ai une photo de The Flash ici parce que si vous avez déjà regardé de vieux films ou certainement la dernière émission de télévision avec The Flash, comme dans Flash Gordon l'ancien personnage, et maintenant qu'il s'appelle "The Flash", il a tendance à aller très, très vite et invariablement son énergie s'épuise. Et c'est ce qui se produit lorsque vous jetez un gros coup de fouet aux performances de la base de données. Invariablement, d'après mon expérience, vous pouvez mettre de hautes performances et un travail acharné dans le jeu, vous pouvez optimiser vos systèmes d'exploitation et les régler à un certain point. Vous pouvez vous assurer que vous disposez de processeurs multicœurs et multithreads rapides pour faire fonctionner l'application plus rapidement, vous pouvez y jeter beaucoup de RAM, vous pouvez avoir des fonds de panier à haut débit, vous pouvez passer des disques durs à la mise en cache des disques durs à l'état solide et une baie de stockage hautes performances. Et même maintenant, les gens ajoutent des choses comme flash et NVMe à leurs moteurs de base de données, pensant qu'ils obtiendront cette connexion fois deux fois plus de performances. Et ils obtiennent invariablement un certain gain. Mais, tout revient aux mêmes problèmes de réglage des performances de base. Beaucoup de connexions réseau à faible latence, afin que les clusters fonctionnent rapidement. Et de l'infrastructure de base de données en cluster, vous avez donc plus d'une seule machine qui fait tout le travail. Mais vous avez tendance à revenir au même problème de performances de base, à savoir la lecture des données. L'écriture de données est, pour la plupart, un défi assez linéaire et à moins qu'il ne soit fait correctement.

Et puis nous avons le défi dans le monde d'aujourd'hui: toutes les bases de données ne sont pas créées égales. Il y a des bases de données et des «bases de données» entre guillemets. Et quand nous pensons aux moteurs de bases de données, les gens pensent souvent aux suspects traditionnels et habituels comme ils l'étaient dans le monde SQL. Vous savez, nous avons Oracle et Microsoft SQL Server, et il y en a quelques-uns dans le monde open source avec MySQL, qui appartient maintenant à Oracle, mais il est toujours open source. Et puis nous avons les suspects pas si habituels, les moteurs NoSQL, qui ont toujours un problème autour de l'indexation et de la gestion des performances, et je ne les aborderai pas en détail, mais il y en a un nombre croissant des choses surgissent chaque jour et elles ressemblent à des moteurs de base de données du point de vue des développeurs et du point de vue des performances, mais ce sont des bêtes très, très différentes et elles ont leur propre petite niche au monde pour se tailler performances en mémoire ou échelle linéaire sur le disque. Mais voici à quoi ressemble le monde dans le monde des bases de données. Ceci est le 2016, c'est la version trois de la carte de, par un éventail de personnes qui produisent cette carte du paysage en cours de ce à quoi ressemblent les bases de données, et c'est là que cela - même un architecte de base de données ou un administrateur de base de données surhumain pourrait avoir du sens de celui-ci. Littéralement des centaines, des centaines et des centaines de marques, modèles, fabricants de bases de données différents, toujours compatibles SQL. Et ce qui est intéressant, c'est qu'ils reviennent tous au même défi. Performances et optimisation des performances autour du moteur de base de données, et notamment par la manière dont les données sont indexées.

Voyons donc rapidement l'indexation des bases de données, car c'est un sujet intéressant, et vous devez y entrer plus en détail avec la démo, je crois. Mais, je pense que c'est une pratique assez bien acceptée et standard de l'industrie que le réglage des performances des index de base de données est le point de départ et d'arrêt du monde en ce qui concerne la garantie de l'accessibilité de vos données sur un format rapide et rapide. Mais qu'est-ce que l'indexation des bases de données? Si nous pensons à l'indexation sous la forme à laquelle nous sommes habitués en tant qu'humains de tous les jours, pensez à une page d'index dans un livre. Si vous voulez trouver quelque chose dans un livre - en particulier les goûts d'une encyclopédie, ou quelque chose comme un matériau de référence d'une certaine forme - si vous recherchez quelque chose comme cette page, où je recherche des choses comme le sujet des barrages dans une encyclopédie. Je veux trouver toutes les références aux barrages, au captage d'eau et à une grande zone de construction, artificielle en général. Je vais à l'arrière, je le trouverai dans une liste alphabétique et triée, de A à Z, de gauche à droite, et je trouverai D. Je trouverai le mot «barrages» et je peux le voir sur pages 16, 38, 41 il y a une référence à eux, puis je peux aller à ces pages, je peux parcourir mes yeux et je vais trouver la référence au mot "barrage". C'est essentiellement le même concept dans une base de données, mais c'est maintenant une science à plusieurs égards. À tel point que chaque administrateur de base de données que je connais bien considère les index comme l'outil le plus critique pour l'optimisation des performances dans n'importe quel monde de base de données, quelle que soit leur expérience en matière de mise à l'étain, ou quel que soit le cas.

Généralement, lorsque nous parlons d'indexation de bases de données, il existe un certain nombre d'approches communes. Et plus les index de base de données deviennent complexes, plus l'approche de l'indexation des données est complexe. Mais essentiellement quand vous pensez à l'indexation des données - imaginez que nous avons un fichier qui a une liste de noms; ils ne peuvent pas être triés par ordre alphabétique. Imaginons qu'il y en ait vingt. Si nous allons trier - si nous allons rechercher des données dans cette liste, de haut en bas, et disons que c'est une liste de noms. Si je choisis un nom aléatoire et que je commence à faire défiler cette liste, de haut en bas, dans un format linéaire et que c'est une liste non ordonnée, il y a deux critères que je considère comme mon temps de recherche moyen et mon temps de recherche maximum - et J'ai une faute de frappe dans la deuxième ligne, cela devrait être «temps de recherche maximum», désolé - mais mon temps de recherche moyen est essentiellement N plus un, divisé par deux, et cela signifie qu'en moyenne, cela me prend cinquante pour cent du temps pour numériser du haut de la liste vers le bas de la liste pour trouver quelque chose au hasard dans cette liste. Et la deuxième ligne là-bas, sous linéaire, devrait être «temps de recherche maximum». Mais le temps de recherche maximum est essentiellement le nombre d'articles, et c'est que si j'ai une liste de vingt choses, que le plus de temps peut me prendre rechercher quelque chose dans cette base de données, c'est aller de haut en bas, c'est-à-dire 20 éléments dans cet exemple simplifié. Et c'est un processus très lent et il n'y a vraiment aucun moyen de régler les performances. Et puis, il existe d'autres types de façons de prendre ces données et de créer un index, qui est en fait une courte liste de pointeurs vers où se trouvent les données réelles, telles que binaire, arbre B, bitmap, hachage, en cluster et non en cluster, et puis il existe différents types de données telles que spatiales, filtrées, XML et texte intégral.

Le binaire est très utilisé pour les choses où les données s'y prêtent. Historiquement, le B-tree est probablement le plus courant dans un sens général, car c'est un moyen courant de structurer un index vers n'importe quelle forme de données et permet aux enregistreurs, aux sélections et aux insertions et suppressions sont relativement faciles lorsque vous déplacez des pointeurs dans le référence aux pointeurs, les points. Il existe d'autres types, comme le bitmap, où les types de données concernent comme si nous avons une plage associée d'une forme quelconque. Le hachage fonctionne très bien pour les gros objets, en particulier les blogs et les images. Et vous pouvez voir qu'il existe différents types d'approches scientifiques, d'approches mathématiques, pour l'indexation des données. Pour le simple mortel, c'est un défi intéressant à aborder à ce niveau. Lorsque vous en parlez au niveau des performances pour un administrateur de base de données, il devient vraiment un spécialiste des fusées et les gens y obtiennent des diplômes, et je sais que le docteur Robin Bloor a certainement fait cela et a écrit des livres à ce sujet pour IBM et d'autres grandes marques au cours des deux dernières décennies. Et donc, à mon avis, nous avons en fait passé un temps où, vous savez, il était une fois où je serais personnellement en mesure de m'asseoir devant un système et je pourrais le démonter et vous montrer exactement où les problèmes de performances se trouvaient sur une ligne de commande ou dans un outil de démarrage de l'interface utilisateur graphique, et commencez à fouiller dans les données et à vous dire où se trouvaient les problèmes, et créez des index, ou des sous-index, ou des index primaires et secondaires dans ce données et commencer à l'utiliser pour trouver des choses. Mais quand vous pensez à ce paysage que je vous ai montré, où nous avons des centaines et des centaines de marques, marques et modèles, fabricants et types de bases de données, nous avons bel et bien dépassé cette époque maintenant, où un être humain peut créer sens des types de moteurs de base de données que nous avons. En particulier, même si nous revenons simplement à Oracle, les marques prédominantes de nos jours dans les plateformes de bases de données relationnelles.

Le nombre de bases de données auxquelles ils doivent faire face à partir d'une plate-forme propriétaire comme un ERP ou un système RH ou financier, ou s'il s'agit d'une plate-forme maison pour diverses raisons, le nombre de bases de données et de tables et d'enregistrements de base de données que nous finissons traiter sont simplement astronomiques et vous ne pouvez physiquement pas le faire à la main. Et nous avons eu une complication supplémentaire maintenant, où il était une fois un serveur de base de données juste assis sous votre bureau. Vous savez, quand j'étais jeune après l'école, j'avais l'habitude d'aller travailler sur un logiciel de base de données sur les systèmes basés sur Apple IIes puis DOS sur PC, comme dBase II, dBase III, qui a connu une ère avec les mainframes et les mid- gamme et même VAX et PDP et fichier journal à ce sujet. Et similaire à Sabre, puis finalement lorsque certaines bases de données SQL sont arrivées. Mais de nos jours, lorsque nous pensons aux moteurs de base de données, ils ressemblent au coin inférieur gauche. Un serveur de base de données n'est plus seulement une machine assise par terre sous un bureau; ce sont des centaines de machines exécutant des copies des moteurs de base de données et des clusters, et elles évoluent jusqu'à des centaines et des centaines de téraoctets de données, sinon des pétaoctets de données, ce qui représente des milliers de téraoctets. Et même à l'extrême, comme l'a mentionné le docteur Robin Bloor, certains cas d'utilisation spécifiques - compagnies aériennes, agences gouvernementales en particulier - peuvent atteindre des exaoctets. Ils sont encore assez niches, mais des centaines de téraoctets et même des dizaines de pétaoctets ne sont plus inhabituels, en particulier depuis le boom des dotcoms jusqu'à présent, une sorte de ce que nous appelons les entreprises du Web 2.0, comme Facebook, Google, Yahoo et ainsi de suite.

Nous avons également la complication maintenant que les choses évoluent vers un service externe. Nous avons une plate-forme d'infrastructure et un logiciel en tant qu'approche de service fournissant une infrastructure. Et en particulier le service de plate-forme où nous ne pouvons pas simplement acheter pour Oracle et sa plate-forme cloud, ses bases de données et ses serveurs. Et cela nous permet donc de faire un développement d'application très rapide et de simplement rebrancher une base de données sur les serveurs. Nous n'avons pas à penser à ce qui se cache sous le capot. L'inconvénient, c'est que nous ne pensons souvent pas à la façon dont nous concevons et implémentons la base de données jusqu'à ce que cela commence à faire mal et que les performances deviennent un problème, puis nous finissons par devoir chercher le bon outil pour diagnostiquer pourquoi notre base de données fait mal et où sont les problèmes de performances. Et invariablement, cela ramène à ce problème commun de la façon dont nous avons indexé ces données et les types d'index que nous avons utilisés pour ces données et qui nous ramène ensuite à des exigences de performance surhumaines. Et quelqu'un qui a accès aux bons systèmes et aux bons outils pour régler les performances de ces moteurs, et commencer à trouver un point chaud et à regarder où se trouvent les requêtes, où les données se déplacent, les types de requêtes, la façon dont les requêtes sont structurées, qui fait les requêtes, et si les requêtes sont mises en file d'attente et doivent être mises en cache. Quelle réplication recherchez-vous?

Et donc nous sommes bel et bien - à mon avis - à un moment où même les meilleurs gourous de base de données du monde, essentiellement nos architectes de base de données et notre administrateur de base de données et nos bases de performance, à mon avis, ils ont très besoin de commencer à tirer parti des bons outils pour fournir un réglage d'index de performances optimal pour tout moteur de base de données. Parce que l'échelle à laquelle nous avons affaire et la vitesse à laquelle les choses évoluent, nous ne pouvons tout simplement pas le faire à la main, et tenter de le faire peut invariablement introduire d'autres problèmes de performance, car nous n'avons peut-être pas d'expérience dans cet espace qui nous essayons de résoudre un problème. Et je crois que c'est là que nous sommes sur le point de remettre à Bert, et nous sommes sur le point de parler de la façon dont ils ont résolu ce problème varié et du type de choses que leur outil peut faire, en particulier pour le monde Oracle. Et là-dessus, Bert, je vais vous céder la parole.

Bert Scalzo: Merci. Bienvenue à tous, je m'appelle Bert Scalzo, je travaille pour IDERA. Je suis le chef de produit principal pour certains de nos produits de base de données. J'en ferai la démonstration aujourd'hui. Mais je veux parler des index, car je suis d'accord avec tout ce que tout le monde a dit ici, en particulier la dernière diapositive, que les index sont si complexes maintenant que vous avez besoin d'un outil, et j'espère vous convaincre. Donc, la conception d'index Oracle, ce n'est plus aussi simple qu'autrefois. Beaucoup de gens ne seront pas sûrs d'eux-mêmes quand ils regarderont les options, et j'aime bien ce dicton que je me suis retiré de l'histoire, "dans ces domaines, la seule certitude, c'est que rien n'est certain." Et c'est comme ça que je sorte de pensez aux index ces jours-ci, car même si vous pensez connaître la réponse, vous devez indexer X, Y ou Z, vous ne pouvez vraiment pas être certain jusqu'à ce que vous l'essayiez, car ces optimiseurs se comportent parfois différemment de la façon dont vous vous attendez. Et donc il y a beaucoup d'essais et d'erreurs avec la conception d'index. Maintenant, au bon vieux temps, si vous aviez besoin d'un index, il n'y avait généralement que deux questions ou une question. Était-ce unique ou n'était-il pas unique? Et vous avez peut-être pensé à d'autres choses comme «Combien d'index puis-je avoir au maximum sur une seule table?», Car trop d'index ralentit vos insertions, mises à jour et suppressions. Vous pouvez également avoir été dans votre système de base de données, avoir des restrictions sur le nombre de colonnes dans un index multi-colonnes, car parfois il y avait des limites basées sur la page ou la taille de bloc de votre moteur de base de données, mais en réalité c'était assez simple au bon vieux temps. Soit vous l'avez indexé, soit vous ne l'avez pas fait. Et vraiment, tout était dans un arbre B. Nous pouvions autoriser les doublons ou non, et c'était à peu près tout. La vie était belle, la vie était simple.

Eh bien aujourd'hui, la vie n'est pas si bonne ou si simple. J'ai mis le signe rouge de Ghostbuster dans la façon dont nous le faisions, car maintenant nous avons B-tree contre bitmap, contre bitmap join. Et je vais expliquer ce que certains d'entre eux sont dans un instant. Clustered et non clustered, unique ou en double, ordre direct ou inverse, basé sur la fonction, partitionné ou non partitionné. S'il y a partitionnement, s'agit-il de partitionnement global ou local? Je vais également l'expliquer. Et puis il y a aussi quelque chose appelé une table organisée indexée. Et il y a en fait une demi-douzaine d'autres que j'ai laissés ici, car je pense que j'en ai assez ici maintenant qui devraient vous convaincre que les indices sont beaucoup plus difficiles que vous ne le pensiez. Dans cette diapositive particulière, je vais commencer dans la partie supérieure gauche du diagramme et j'ai un tableau. Et la première chose que je dois décider est, selon votre version de base de données et votre fournisseur de base de données, autorisent-ils les tables d'objets ou sont-ils uniquement relationnels? Je vais descendre du côté droit et dire que nous construisons une table relationnelle. Maintenant, la prochaine question que je dois me poser est, est-ce dans un cluster? Et beaucoup d'entre vous qui ont fait Oracle pendant un certain temps se souviendront que les clusters étaient de retour pour Oracle 6 jours. Ils ne sont probablement plus très utilisés aujourd'hui, mais laissez-moi d'abord descendre cette branche.

Si je devais mettre ma table dans un cluster, je devrais avoir un index cluster sur cette table. Maintenant, dans Oracle, lorsque vous regroupiez une table, vous stockiez essentiellement les lignes ou les lignes étaient proches les unes des autres où les valeurs étaient similaires. Et donc, vous devez avoir un index clusterisé et cet index clusterisé peut être non partitionné. En d'autres termes, il n'y avait pas vraiment de méthodes de partitionnement pour la façon dont vous feriez une table en cluster. Il était strictement non partitionné. Et parce qu'elle n'était pas partitionnée, elle était globale. Je vais expliquer ce qu'est le global dans une minute. Et c'était toujours B-tree. En d'autres termes, quand je suis descendu dans cette branche, c'était assez simple, je n'avais pas beaucoup de choix. Maintenant, si je faisais un index non clusterisé sur une table clusterisée, ce qui était autorisé dans certaines versions, encore une fois il n'était pas partitionné; lorsqu'il n'est pas partitionné, votre seul choix est global. Et donc, vous avez le choix entre B-tree ou bitmap. Encore une fois, cela dépendait de votre version de la base de données. Mais maintenant, revenons à la table relationnelle et recommençons à descendre du côté droit et maintenant nous allons juste avoir une table simple, ancienne, régulière et entassée: relationnelle. Ça va être dans un espace table. Je vais en quelque sorte descendre du côté droit ici en premier. C'est donc de l'organisation, du tas. La question suivante que je dois me poser est: «Est-ce que je veux partitionner cette table ou pas?» Maintenant, parfois vous partitionniez parce que vous pensiez: «Hé, l'optimiseur sera plus intelligent sur la façon dont il peut optimiser les requêtes. «Mais de nombreux administrateurs de base de données vous diront que la raison pour laquelle vous le faites est à des fins administratives. Si vous avez une table de cent milliards de lignes, si vous la divisez en partitions ou en compartiments, lorsque vous souhaitez ajouter des données au dernier compartiment, vous pouvez supprimer et indexer cela ne représente que quelques millions de lignes. Vous pouvez insérer ces données, puis vous pouvez reconstruire cet index sur ce compartiment uniquement.

Alors que c'était une bonne technique pour certains, des techniques d'optimisation comme l'élimination des partitions, sa vraie valeur était de pouvoir administrer ou effectuer des tâches administratives sur des pièces plus petites. Lorsque je vais dans le tas organisationnel, la première question était: «Est-ce que je l'ai partitionné ou non?» Allons à gauche, je ne vais pas partitionner la table. Maintenant, cela peut sembler étrange quand je vous le dis, mais vous pouvez avoir une table non partitionnée et vous ne pouvez pas partitionner l'index comme vous en avez l'habitude, ou vous pouvez partitionner l'index. Arrêtez-vous et réfléchissez. Votre table a essentiellement un compartiment, comme vous l'avez toujours pensé, et pourtant votre index va avoir plusieurs compartiments. Lorsque cela se produit, où il y a un décalage entre le nombre de compartiments et la table et le nombre de compartiments dans l'index, c'est ce que l'on entend par global. Et donc, si la table n'est pas partitionnée, et si l'index est partitionné, il est considéré comme global, car il y a un décalage. Maintenant, permettez-moi de remonter sur le tas de mon organisation et de descendre à la place du côté de la partition. Maintenant, si j'ai une table de partition, et disons que la table a quatre compartiments, quatre partitions, mon index pourrait avoir quatre compartiments afin que mon index corresponde à la conception de ma table. Et donc c'est fini, bien plus, sur le côté droit. Ce serait considéré comme local. Un index local signifie essentiellement que le partitionnement de la table et de l'index se fait de la même manière et a le même nombre de compartiments. Et puis une fois que j'ai l'index local, il peut s'agir d'un arbre B ou d'un bitmap, et cette flèche verte qui monte, vous montre que même si c'est un arbre B, il y a encore des choix à faire. Il pourrait être basé sur les fonctions. Et aussi, s'il s'agit d'un bitmap, il existe différents types de bitmaps. Il y a quelque chose appelé un index de jointure bitmap. Si vous faites de l'entreposage de données, c'est un type d'index très populaire pour le schéma en étoile ou la conception. Ce qui se passe, c'est que l'index a les ID de ligne pour ce qu'il pointe dans la table, mais il aura également des ID de ligne pour les tables parentes, de sorte que lorsque vous - vous devez observer la conception du schéma et regarder dans une table de faits, cet index sur la table de faits vous pointe vers les données qui vous intéressent et vous pointe vers chaque ligne de vos dimensions, de sorte que vous ne devez avoir qu'un seul index.

Et en fait, cela a vu le jour grâce à Red Brick, qui était une base de données il y a de nombreuses années - beaucoup de gens s'en souviennent. Et donc, si vous regardez cette image - et gardez à l'esprit que je n'ai pas tout mis dans cette image parce que l'image serait beaucoup plus grande - il y a encore des problèmes supplémentaires, que j'ai dans le texte ici en haut à droite . Est-ce un indice d'ordre inverse? Et vous pourriez dire: «Pourquoi voudrais-je un indice inverse? Cela n'a aucun sens. »Eh bien, si vous êtes dans un environnement en cluster dans Oracle, si vous faites de vrais clusters d'applications, si vous gardez vos index en ordre, donc non inversés, si vous avez beaucoup de traitement qui frappe les mêmes valeurs ou les mêmes valeurs d'index, ce qui se passerait, vous auriez des zones chaudes de votre arbre B. Cela signifie que vous auriez des conflits et éventuellement un verrouillage pour essayer d'accéder à ces informations, et que vous le feriez sur plusieurs nœuds d'un réseau. Eh bien, si vous mettez un index d'ordre inverse, vous pouvez maintenant l'annuler. Vous pouvez dire: «Eh bien, les valeurs similaires sont dans différentes parties des arbres, donc je n'ai pas mes nœuds séparés en compétition pour les zones chaudes de l'arbre.» Et puis remarquez aussi que l'unique ne fonctionne pas avec certaines des options . Si vous regardez, j'ai numéroté trois, cinq, huit et onze, donc il y a des cas où je ne peux pas avoir un index unique. De même, il y a des cas où je ne peux pas avoir d'index inversé, et puis il y a des problèmes supplémentaires comme la journalisation ou pas de journalisation, et parallèle et non parallèle. Je peux assigner des choses à une zone spécifique de la mémoire.

Et cela laisse encore un peu de fonctionnalités dans Oracle. Je dirais que lorsque vous regardez Oracle 12, il y a probablement encore une demi-douzaine de choses que je pourrais ajouter à cette image. L'indexation est vraiment complexe et je suis vraiment d'accord avec l'orateur précédent, pour naviguer à travers cela et faire un bon choix, vous avez besoin d'un outil. Vous avez en quelque sorte besoin, peut-être, d'une image comme celle-ci, et d'une sorte de méthodologie sur la façon dont vous choisiriez les choses et, espérons-le, l'outil vous aiderait à y arriver. Et puis ça va être des essais et des erreurs. Je dis toujours aux gens sur l'indexation, "regardez avant de sauter." Et puis vous pouvez voir le petit chien ici, il saute sans regarder, il va se retrouver dans l'eau avec le requin, ou le gars s'apprête à sauter dans l'eau, et il va s'empaler. Vous devez penser à votre indexation, car la création d'un index ne signifie pas toujours que les choses s'améliorent. En fait, la création d'un index peut ralentir les choses. Et les performances des requêtes peuvent être d'un ordre de grandeur mieux avec un choix plutôt qu'un autre. Et je vais vous donner un bon exemple. Si vous faites un schéma en étoile de conception, et sur vos tables de dimension, vous utilisez des index bitmap dans un cas, et dans un autre cas, vous dites: «Je vais utiliser des index B-tree», vous avez bitmap contre B- arbre. Je peux vous dire qu'une solution sera un ordre de grandeur ou peut-être plusieurs ordres de grandeur plus rapide que l'autre. Mais gardez à l'esprit ce qui fonctionne dans un environnement, comme dans un environnement d'entreposage de données, n'est probablement pas un bon choix dans un environnement OLTP.

Par exemple, si vous deviez prendre une table transactionnelle et mettre des index bitmap sur une table transactionnelle, il est coûteux de calculer et de réinitialiser les bitmaps, ces longues chaînes, et ainsi dans une table OLTP, vous pouvez frapper la table si fortement que la bitmap l'index peut devenir corrompu et ralentir votre système car il n'est tout simplement pas destiné aux mises à jour. Ils sont parfaits pour un accès rapide, mais ne sont pas bons pour les mises à jour. Je pense que l'index prend des essais et des erreurs. Il n'y a vraiment plus de règle d'or - il y a trop de variables différentes dans cette équation à savoir - et finalement vous devrez regarder l'exécution ou expliquer les plans dans votre base de données pour voir si vous faites ou non de bonnes sélections. Et parfois, l'analyse du plan peut presque être une science en soi. Je ne vais pas couvrir cela aujourd'hui - c'est un autre sujet - mais ne prenez pas la conception d'index pour acquise. Il y a des raisons légitimes pour lesquelles il y a tous ces types d'index fous que je vous ai montrés, dans l'image précédente, et dont l'orateur précédent a parlé. Ceux-ci n'ont pas été créés simplement parce que c'était une fonctionnalité intéressante de mettre quelque part une liste de contrôle pour un fournisseur de base de données; il existe des cas d'utilisation ou des scénarios où ces index sont importants et feront une différence significative. Maintenant, avec cela, je vais vous montrer quelques exemples de différents types d'index dans l'un de nos outils. Permettez-moi de lever mon écran pour que vous puissiez le voir. D'accord, alors je suis assis à l'intérieur de - laissez-moi minimiser cette application. Je suis assis à l'intérieur de VMware et j'exécute une machine virtuelle Windows Server 2012.

Et vous pouvez voir que j'ai à peu près tous les outils connus de l'homme. En tant que chef de produit, je dois rester au courant de mes concurrents, donc ce ne sont pas seulement les outils dont je dispose, mais que font mes concurrents? Et nous avons ici cet outil appelé DBArtisan, que j'ai déjà en cours d'exécution, mais je vais - donc je vais le mentionner. Et ce que vous pouvez voir, c'est que c'est un très bon outil, car au lieu d'avoir à utiliser, par exemple, un gestionnaire d'entreprise pour Oracle et un SQL Management Studio pour SQL Server, et le MySQL Workbench pour MySQL, et douze autres bases de données que nous prenons en charge, eh bien j'ai toutes mes bases de données intégrées dans cet outil. Il y a DB2, il y a MySQL, Oracle, Postgres, SQL Server et Sybase, et c'est - je n'ai que six bases de données dans cette chose particulière parce que je ne peux pas - l'outil prend en charge douze bases de données mais ma pauvre machine virtuelle, exécutant six bases de données simultanément et essayant faire une démo, c'est à peu près autant que mon matériel va faciliter. Alors laissez-moi remonter dans Oracle maintenant, et si vous remarquez, toutes ces choses sont les mêmes. Si je veux mesurer mes performances dans DB2, ce sont les mêmes choix que j'aurais dans Oracle. Maintenant, sous les couvertures, nous faisons beaucoup de choses différentes pour que vous n'ayez pas à savoir ce qui se passe, mais nous vous donnons une interface cohérente afin que vous puissiez être un expert avec plusieurs plateformes de base de données. Et cela inclurait travailler avec des index, le sujet de cette discussion.

Laissez-moi entrer ici et permettez-moi de commencer par regarder des tableaux, et j'ai une base de données de films qui ne contient que quelques tableaux. Et si je regarde une table particulière, comme la table client, lorsque je la présente ici, je peux voir la conception de ma table, voici mes colonnes dans ma table et voici des informations sur chaque colonne. J'ai des propriétés pour la table, mais notez que j'ai un onglet ici pour les index et je peux voir ici les index sur la table. Notez que l'un de ces index est mon index PK, ma clé primaire. Ces autres semblent être juste des index pour améliorer l'accès aux requêtes, peut-être que nous interrogeons par prénom ou nom, ou que nous regardons les téléphones et les codes postaux. Et si je choisis un index particulier, comme ce code postal ici, et que je double-clique dessus, maintenant je peux voir que, hé, c'est un index non unique et voici quelques-uns des autres types, bitmap, non unique, unique, qu'il soit trié ou non, que cette journalisation soit ou non inversée, que ce soit une base de fonctions. Oh, voici une amusante que je n'ai pas couverte. Vous pouvez en fait avoir des index invisibles. Et vous diriez: "Eh bien, pourquoi diable voudrais-je faire un index invisible?" Eh bien, je vais vous donner un bon exemple. Vous êtes dans votre système de production et vous avez un problème de performances et vous n'êtes pas sûr que la création de l'index résoudra le problème, donc vous ne voulez pas créer l'index et ralentir la production, mais d'une manière ou d'une autre vous voulez pouvoir le tester. Vous pouvez créer l'index en production comme invisible, ce qui signifie que peu de code d'application, appelant l'optimiseur, utilisera cet index. Il a été créé, il est valide, mais il ne sera pas utilisé. Ensuite, vous pouvez prendre une requête que vous pensez que cet index pourrait aider, ou une série de requêtes, et vous pouvez coller un indice et dire: «Hé, optimiseur, il y a un index invisible que je veux que vous utilisiez et laissez je sais si j'ai amélioré les choses. »Et maintenant, j'ai testé quelque chose en production, mais je n'ai pas cassé les applications en cours de production. C'est l'utilisation d'un index invisible. Cela semble stupide lorsque vous en entendez parler pour la première fois, mais il a une utilité.

Nous pouvons également, sur les index, définir s'ils sont parallèles, ainsi que le nombre d'instances sur lesquelles ils sont parallèles. Maintenant, dans un environnement de cluster d'applications non en cluster ou non réel, donc non rack, parallèle signifierait le nombre de sous-processus que ma requête peut générer pour essayer, et les processus de travail, pour essayer de faire avancer les choses plus rapidement ou plus rapidement . Et les instances parallèles seraient, si je suis dans un vrai cluster d'applications, disons que j'ai dix nœuds, combien de nœuds suis-je autorisé à répartir le travail? C'est peut-être quatre des dix, et pour chacun d'eux, quatre sous-processus. Voilà un exemple. Et puis nous avons la compression des clés. Vous pouvez réellement compresser des index? Oui ou non. Et puis bien sûr, vous avez vos paramètres de stockage que vous pouvez spécifier sur les index. Maintenant, je ne les ai pas couverts car ils sont vraiment plus un paramètre de stockage qu'un problème d'index. Et puis finalement, nous devons décider de les rendre partitionnés ou non. Permettez-moi de déposer cela ici pendant une seconde. Je vais passer à un schéma différent. Il s'agit d'un schéma en étoile et, par exemple, ce tableau de période est un tableau de dimensions. Si vous avez déjà fait la conception de schéma en étoile, vous avez généralement une dimension pour le temps et donc dans cette base de données et ce schéma en étoile, la période est une dimension de temps. Maintenant, je sais que ça aura l'air drôle, vous direz: «Eh bien, regardez toutes ces colonnes - le gars a-t-il déjà entendu parler de normalisation?» Eh bien, lorsque vous êtes dans un entrepôt de données ou une conception de schéma en étoile, vous en général, il n'y a pas - vous avez des tables qu'une personne type regarderait et dirait: «Eh bien, elles ne sont pas très bien conçues.» Mais c'est ainsi que vous le faites dans un environnement d'entreposage de données.

Maintenant, regardez ce qui va se passer parce que, d'accord, il y a toutes ces colonnes, regardez ça, j'ai un index sur chaque colonne. Maintenant, dans un environnement OLTP, ce serait un non-non. Cela ralentirait toutes mes opérations. Dans un environnement d'entreposage de données, je les laissais tomber pendant mes cycles de chargement par lots. Charger sans la surcharge ou les index, et je recréerais les index. Et si je partitionnais ma table, au lieu de devoir supprimer l'index pour chaque compartiment de la table, je pouvais simplement supprimer l'index sur le ou les compartiments dans lesquels les données allaient entrer pendant ce cycle de chargement par lots. Et puis recréez uniquement la partie d'index pour ces compartiments. Et donc cela le rend très gérable. Et si je regarde - voici donc une colonne intitulée «Holiday Flag» et, fondamentalement, c'est un oui ou un non. Notez qu'il s'agit d'un index bitmap, et pour la plupart d'entre vous, vous direz: «Eh bien, cela a du sens.» Oui ou non, Y ou N, il n'y a que deux valeurs qui ont du sens. Et parce que lorsque vous lisez la documentation des index bitmap, ils vous disent toujours de choisir quelque chose avec une faible cardinalité.

Maintenant, laissez-moi entrer dans l'une de mes tables de faits, alors voici nos commandes. Et ce sont mes commandes par jour. Et vous allez voir maintenant que j'ai encore pas mal de colonnes, et encore une fois, je vais avoir plus que quelques index. Et ici, nous avons quelque chose appelé le code de prix universel. C'était pour un magasin de détail, donc vous connaissez ces petits codes à barres lorsque vous achetez quelque chose au magasin, c'est le code de prix universel. Maintenant, il existe des millions de codes de prix universels. Maintenant, pour cette entreprise qui vendait des trucs, ils avaient probablement 1, 7 à 2 millions de codes de prix universels, donc vous allez vous attendre à ce que ce ne soit pas un index bitmap car 1, 7 million de valeurs distinctes ressemblent à une cardinalité élevée. Mais en réalité, dans un environnement d'entreposage de données, vous voulez que ce soit un bitmap. Maintenant, laissez-moi vous expliquer pourquoi. Eh bien, il peut y avoir 1, 7 million de valeurs distinctes pour ce code de prix universel, le nombre de lignes dans cette table de commande est de plusieurs centaines de millions à plusieurs milliards de lignes. Mon indice est faible cardinalité par rapport à la taille ou la cardinalité de la table. Cela rend la cardinalité faible. Cela rend l'index bitmap utile, même s'il est contre-intuitif avec 1, 7 million de valeurs distinctes que vous choisiriez ici. Maintenant, si je savais que je voulais utiliser un index de jointure bitmap, actuellement le produit ne le prend pas en charge, je le fais ajouter pour la prochaine version, mais ce serait une autre alternative ici. Et dans un schéma en étoile, rappelez-vous, l'index bitmap serait sur la table de faits et qu'un index dans l'arborescence B pointerait vers la ligne de la table de faits, puis vers chaque ligne apparente dans la table de dimension pour ce fait . Et donc, vous avez là une autre option. Et donc, voyons, je veux sortir des tableaux maintenant et je veux juste vous montrer rapidement que j'ai les mêmes informations, sous les index, et je vais faire la même chose de base.

Maintenant, la raison pour laquelle j'ai soulevé cette question est que vous remarquerez peut-être qu'il n'y a pas de clé primaire ici. Les clés primaires sont effectuées avec une contrainte de clé, elles sont donc réellement couvertes par les définitions de contrainte. Ce seraient des index qui ne font pas partie de la contrainte. Maintenant, vous pourriez dire: «Eh bien, attendez une minute, cela pourrait ressembler à une clé étrangère, et une clé étrangère est une contrainte», mais les clés étrangères et la plupart des bases de données ne créent pas automatiquement un index sur la colonne de clé étrangère, même si c'est conseillé, et voilà - j'ai encore tous les mêmes choix. Et si je veux changer juste pour être compressé, je peux le faire.

Désormais, la compression ne fonctionne que sur un index B-tree. Ce que cela permet, c'est que lorsque vous regardez les différents nœuds de l'arbre B, cela permet de compresser certaines des valeurs. Ce n'est vraiment pas une compression comme la compression de table, c'est une compression de ce qui est stocké dans l'arbre B dans les nœuds non-feuilles. Cela n'économise pas une tonne d'espace, mais cela peut faire la différence. Et avec cela, j'ai remarqué que je me rapproche du temps, donc ce que je veux faire, c'est que je veux revenir en arrière et arrêter mon partage. Et, nous avons notre produit là-bas pour un essai de quatorze jours sur idera.com. C'est un très bon produit, surtout si vous travaillez avec plusieurs plateformes de base de données. Si vous travaillez avec deux ou trois bases de données différentes, cet outil vous facilitera la vie. Nous avons des outils pour vous aider avec la conception et la sélection d'index, nous avons un outil appelé DB Optimizer. Je ne pouvais tout simplement pas couvrir cela aujourd'hui, ce serait trop. Et si vous voulez me contacter, il y a mon adresse e-mail, c'est, ou vous pouvez me rattraper à mon e-mail privé, et j'ai des blogs, j'ai un site Web et des blogs, et un profil LinkedIn là-bas. Alors n'hésitez pas à me contacter sur n'importe quoi, même si ce n'est pas lié au produit, si vous voulez juste parler de bases de données, je suis un geek dans l'âme et j'aime parler de technobabble.

Eric Kavanagh: D' accord, eh bien Dez, Robin, je suis sûr que vous avez chacun au moins quelques questions, il nous reste quelques minutes. Dez, qu'en pensez-vous?

Dez Blanchfield: J'ai une excellente question à vous poser, elle me vient à l'esprit. Quel est le scénario le plus fou que vous ayez vu? J'ai lu votre blog, je vous suis de près, le - vous êtes, vous êtes probablement l'une des rares personnes à avoir vécu dans presque tous les cas improbables, et je pense que le Dr Robin Bloor est le deuxième que j'ai rencontré ma vie. Mais, vous savez, vous avez probablement vu tous les scénarios fous, quels sont les scénarios les plus fous que vous avez vus, que vous avez rencontrés, et comme des êtres humains qui ne pouvaient tout simplement pas faire face, vous avez réussi à marcher et effectuer des tours d'esprit Jedi avec tout ce DBArtisan?

Bert Scalzo: Nous avons eu un client une fois qui, dans la conception de sa base de données, il pensait beaucoup à la façon dont il penserait dans la conception d'une mise en page de fichier, et ainsi de suite - lorsque vous normalisez une base de données, la première chose que vous essayez de faire est de vous débarrasser de groupes répétitifs. Eh bien, ils avaient une colonne et ils en faisaient une longue, ou un BLOB ou un CLOB, et dedans ils mettraient la valeur, numéro un, point-virgule, valeur numéro deux, point-virgule, numéro de valeur, point-virgule, et ils auraient des milliers de valeurs là-dedans, mais ils avaient besoin de rechercher sur cette colonne et ils sont comme, "Pourquoi cette chose fonctionne-t-elle si lentement?" Et je me dis, "Eh bien, vous ne pouvez pas créer un index sur ce que vous avez fait, c'est juste pas permis. »Nous leur avons donc montré, en utilisant les plans, que ce qu'ils devaient faire était de normaliser ce tableau. Non pas parce que la normalisation est un exercice académique qui améliore les choses, mais parce qu'ils voulaient une requête sur ce champ, ce qui signifiait qu'ils voulaient pouvoir l'indexer, et vous ne pouviez pas l'indexer sur un groupe répétitif, ou du moins pas facilement . Et c'est probablement la pire chose que j'aie jamais vue.

Dez Blanchfield: Oui, il est intéressant de voir combien de fois vous rencontrez, je pense que le défi avec les bases de données, les gens oublient que c'est une science. Et il y a des gens qui font des diplômes et des doctorats dans tout cet espace, écrivent des articles dessus, et vous avez écrit tout un butin, y compris vos manuels TOAD et d'autres choses de mémoire. La tendance vers une sorte de «big data» entre guillemets maintenant - je vois beaucoup de gens oublier les principes fondamentaux de l'architecture et de la technologie des bases de données, la science des bases de données, si vous voulez. Que voyez-vous sur le terrain en ce qui concerne l'abandon des plates-formes de base de données traditionnelles et la pensée de base de données traditionnelle que nous avons effectivement cloué au sol, et ce n'était qu'un cas de réglage et de mise à l'échelle des performances. Voyez-vous beaucoup de gens réapprendre et avoir une expérience où ils sont juste assis là et ont un moment «a-ha», comme un moment eureka, où ils se rendent compte, ce truc de big data est en fait juste une sorte de très grandes bases de données? Est-ce quelque chose là-bas et les gens vous répondent en retour et en quelque sorte: "Nous avons oublié, ce que nous savions et pouvez-vous nous ramener du côté obscur?"

Bert Scalzo: Eh bien, non, et c'est horrible de devoir l'admettre, mais les fournisseurs de bases de données relationnelles ont également bu ce Kool-Aid. Si vous vous souvenez, je ne sais pas, il y a une dizaine d'années, nous avons commencé à mettre des données non structurées dans des bases de données relationnelles, ce qui était en quelque sorte une chose étrange à faire, puis les données, les bases de données relationnelles, ajoutent maintenant le type NoSQL des trucs. En fait, dans Oracle 12, CR2 - je sais qu'il n'est pas encore sorti - mais si vous regardez la version bêta, si vous êtes dans le programme bêta, il prend en charge le partage. Et donc, maintenant vous avez une base de données relationnelle qui n'a pas ajouté le concept du partage NoSQL. Et donc, le moment «a-ha» semble être plus pour les gens du côté relationnel qui vont «a-ha». Personne ne va plus jamais le faire correctement, pas même les gestionnaires de bases de données, donc nous avons dois aller et rejoindre le côté obscur.

Dez Blanchfield: D'accord, vous dites donc que l'on passe à beaucoup de données en désordre, si je comprends bien, dans ce que nous appelons maintenant des plates-formes de Big Data, ce qui est assez drôle, car elles sont pas si vieux, mais cela ne signifie-t-il pas alors qu'ils se recentrent sur ce qu'ils font avec leur base de données relationnelle pour en avoir plus pour leur argent?

Bert Scalzo: Non, généralement, s'ils ont un besoin dans le - cela aurait été de citer un «besoin de type big data», ils constatent qu'au lieu d'avoir à aller sur l'autre plateforme de base de données et faire quelque chose de manière non -de manière relationnelle, les fournisseurs de bases de données leur donnent maintenant les mêmes techniques non relationnelles à l'intérieur de leur base de données relationnelle, pour faire ces choses. Je veux dire, un bon exemple serait, si vous avez des données non structurées, comme un type de données JSON ou un autre type de données complexe qui a une signification intégrée dans les données elles-mêmes, les fournisseurs de bases de données non seulement prennent en charge cela, mais ils vous donneront ACID conformité sur les données non structurées. Les bases de données relationnelles ont adopté les nouvelles techniques et technologies et donc, encore une fois, le «a-ha» semble ne pas être plus que «Hé nous, les développeurs d'applications, avons désappris quelque chose et nous devons l'apprendre à nouveau», c'est «Hé, nous le faisons de cette façon maintenant, comment puis-je le faire de cette façon dans votre base de données relationnelle traditionnelle et le faire comme je le fais ici? »et cela devient de plus en plus répandu, et comme je l'ai dit, les fournisseurs de bases de données eux-mêmes permettent cette.

Dez Blanchfield: D'accord, qui sont les suspects traditionnels dans cet espace pour l'outil DBArtisan et ça? J'ai fait mes devoirs sur ce que vous aviez écrit récemment, et de mémoire vous avez écrit quelque chose, je pense que c'était l'un de vos blogs, sur les performances extrêmes des bases de données dans le monde Oracle. Je ne me souviens pas quand c'était, je pense que c'était quelque part cette année de mémoire, ou à la fin de l'année dernière, vous aviez écrit cette chose. Et il me semblait que c'était le suspect traditionnel et habituel pour le type de sujet dont nous parlons aujourd'hui, où les gens iront dans un environnement de base de données à très grande échelle et chercheront ce que vous appelez des gains extrêmes. Quels sont les suspects habituels que vous voyez là-bas qui adoptent DBArtisan et l'utilisent à bon escient?

Bert Scalzo: Eh bien, nous avons beaucoup de clients, en fait, aujourd'hui j'étais avec une très grande agence gouvernementale qui - et ils ont littéralement probablement près de 1000 copies de notre logiciel, car cela permet aux gens de se concentrer sur ce qu'ils '' re faire, et non comment le faire. Et ça va, je veux dire, tout le monde devrait savoir comment faire quelque chose, mais la productivité, c'est faire le «quoi». Si l'entreprise me demande de faire une tâche, c'est tout ce qui l'intéresse. Quand ai-je reçu une coche pour dire quand la tâche a été effectuée? Pas quelle technique ou quelle technobabble ai-je utilisé pour y arriver. Et donc, notre outil leur permet de se concentrer sur le quoi, et leur permet d'être beaucoup plus productifs, et c'est vraiment l'énorme avantage, et comme je l'ai dit, certaines bases de données offrent un outil uniquement pour leur plate-forme de base de données. Nous le proposons pour douze plateformes de bases de données. J'ai le même workflow, la même interface utilisateur graphique, les mêmes navigations. Si vous savez comment accorder un privilège à un utilisateur ou comment créer une table ou créer un index dans une base de données, vous pouvez le faire dans les douze parce que c'est la même apparence et le même flux de travail. Cela a une valeur énorme pour nos clients.

Dez Blanchfield: Oui, je suppose que les gens veulent en avoir beaucoup plus pour leur argent grâce à leurs ressources humaines. Et l'époque où un spécialiste individuel d'Oracle, d'Ingres et de DB2 était révolu. Les gens devraient être le Jack de tous les métiers, donc je pense que cette chose leur a absolument sauvé la vie.

Juste une dernière petite chose avant de la remettre au docteur Robin Bloor. Vous avez mentionné qu'il y a un téléchargement gratuit pendant quatorze jours, qu'est-ce que - si je vais aller de l'avant et je vais le faire, au fait, je vais le mettre dans le laboratoire technique de Bloor et faire tourner cette chose et mettre la main dessus - je n'avais pas eu la chance de le faire avant aujourd'hui. Vous avez mentionné un essai de quatorze jours, vous avez dit que vous l'exécutiez sur une machine virtuelle sur votre ordinateur, je suppose que c'est un ordinateur portable. Quelle est la configuration d'entrée de gamme pour que quelqu'un puisse mettre la main à la pâte et utiliser le test de quatorze jours, juste avant de remettre à Robin ses questions?

Bert Scalzo: Tout environnement Windows, donc Windows 7, machine virtuelle avec un processeur et quatre Go de mémoire. Nous ne sommes pas un outil vraiment gros ou cher. Maintenant, si vous vouliez exécuter votre serveur de base de données sur cette même machine virtuelle sous ce même Windows, oui, vous auriez besoin d'en ajouter plus, mais si vous exécutez votre base de données sur un serveur de base de données ou sur une machine virtuelle distincte, la machine virtuelle à charger et exécuter notre produit est très léger: un processeur, quatre Go de mémoire, à peu près n'importe quelle version de Windows - et nous prenons en charge les installations à trente-deux et soixante-quatre bits. Mais vous devez installer le client de votre fournisseur de base de données. Donc, si vous voulez vous connecter à Oracle, vous devez installer le client SQL net, car c'est ce dont Oracle a besoin pour que vous puissiez parler à une base de données.

Dez Blanchfield: Cela semble assez simple. Je pense qu'une chose de cela plus que tout ce que j'espère que les gens vont emporter, à part la prise de conscience que cet outil va leur sauver la vie, c'est qu'ils devraient aller le télécharger et jouer avec, étant donné que vous offrez un essai gratuit de quatorze jours. Et il peut fonctionner sur leur ordinateur portable actuel sans rien installer de plus, car s'ils font déjà l'administration de bases de données, ils travaillent déjà avec des bases de données, ils ont tous ces outils en place et que ce soit sur une machine virtuelle locale ou sur leur bureau local, il semble que ce soit facile à installer et à jouer. Je recommande donc fortement aux gens de faire cela.

Robin, je suis sûr que vous avez des questions et Eric, vous en avez probablement parmi le public, alors Robin, que diriez-vous de vous passer la parole, puis de revenir à Eric?

Robin Bloor: Oui, d'accord, et bien j'ai des choses à dire, je veux dire, j'ai toujours trouvé ce domaine fascinant parce que c'était - je me suis coupé les dents. Mais la vérité est, probablement depuis environ 1998, 1999, que je suis à la dérive de ce dont Oracle est réellement capable. Et, je connaissais Sybase et Microsoft SQL Server, les deux sont assez simples par rapport à ce qu'Oracle pourrait faire. Tu m'as fait rire quand tu - je veux dire, j'ai couvert ma bouche, quand tu as commencé à parler de sharding. Oracle a fait cela auparavant. Oracle a introduit à un moment donné, ils sont devenus nerveux de l'idée relationnelle à l'objet, ils ont donc introduit la possibilité de créer une sorte de notation d'objet et de stockage d'objets dans Oracle, et j'ai parlé à l'un de leurs ingénieurs, quelque chose comme quelques des années après l'avoir introduit et j'ai demandé combien de personnes l'utilisaient, et il a dit que je pense que deux clients l'avaient essayé et c'était tout. Et je pense que la même chose va se produire s'ils commencent à essayer de faire des choses NoSQL de tendance. Vous savez, je pense que c'est une erreur, je veux dire, je suis un peu intéressé par ce que sont vos pensées. Certainement, les - ils boivent le Kool-Aid. Ils ont l'impression qu'ils doivent pouvoir faire des réclamations similaires aux grandes bases de données NoSQL comme Cassandra, mais vous savez, cela a-t-il un sens pour vous?

Bert Scalzo: Non, vous avez frappé le clou directement sur la tête. Pour moi, je le ferais, si je vais faire du relationnel, je choisirai un fournisseur relationnel comme un Oracle ou un SQL Server ou un DB2 ou un Postgres, mais si je vais faire quelque chose qui n'est pas relationnel, dans l'espace big data, ou l'espace NoSQL, je vais choisir le bon outil pour le bon travail. Et je ne pense pas que ce serait naturellement aller d'abord à mon fournisseur de base de données relationnelle. Et puis, vous y ajoutez l'autre ride, qui est, qu'est-ce qui est disponible dans le cloud? Tant de gens qui veulent sortir leurs bases de données du local. Ensuite, vous devez regarder votre fournisseur de cloud et dire: «D'accord, que proposez-vous, quelles bases de données avez-vous à ma disposition qui correspondent à mes besoins et à quel point sont-elles vendables, et franchement quel est le taux ou les frais d'utilisation de cette base de données dans le cloud par heure ou par jour. Et par gigaoctet ou téraoctet? "Et ce que vous trouverez peut-être certaines des bases de données relativement récentes comme Mongo ou Cassandra, peut-être que leurs taux sont moins chers, donc si vous allez faire des mégadonnées de type multi-pétaoctets, vous pourriez doivent - juste du point de vue des coûts - doivent considérer les bases de données NoSQL dans le cloud, car elles peuvent être le moyen le plus rentable de le faire.

Robin Bloor: Oui, c'est ça. Je veux dire, mon genre de - la chose à propos des bases de données relationnelles dans mon expérience - qui est assez longue pour avoir des cicatrices, c'est sûr - il y a beaucoup de bon sens que si vous commencez à l'appliquer et - vous comprenez ce qu'est réellement le relationnel, que Je veux dire, je me souviens avoir fait du conseil avec un client une fois, et ils m'ont conduit dans une pièce et ils ont fait une sorte de diagramme d'entité et créé une troisième forme normale, un modèle de ce à quoi ressemblaient les principaux systèmes de l'entreprise. Il y avait environ deux cent quarante tables et ils ont dit: «Eh bien, qu'en pensez-vous? Nous allons construire une base de données pour cela », et a dit« Que pensez-vous de cela? »J'ai dit:« Je ne pense pas que ça va fonctionner. »Et c'est tout à fait vrai, vous savez, parce qu'ils se terminaient afin de créer une structure particulière au sein de jointures à onze voies. Et c'est la chose à comprendre au sujet du relationnel. Je suis donc un peu intéressé par la quantité de mauvais design que vous rencontrez. Je veux dire, je n'ai aucun problème avec DBArtisan - il fait des choses très sensées et le fait que vous pouvez réellement afficher sur plusieurs plates-formes, je pense, est merveilleux - mais combien rencontrez-vous là-bas où la conception est un problème où les gens auraient pu résoudre eux-mêmes toutes sortes de chagrins d'amour s'ils se résumaient à un schéma en étoile plutôt que de s'attaquer à ce flocon de neige, vous savez?

Bert Scalzo: Eh bien, je ne veux pas avoir l'air présomptueux ou arrogant, mais je dirais plus souvent qu'autrement. De toute évidence, la majorité des bases de données avec lesquelles je m'implique, ont des problèmes ou des problèmes. Ce qui est bien, car nos outils, comme notre outil d'optimisation de base de données, peuvent les aider à résoudre ces problèmes, et, mais ce qui est vraiment drôle pour moi, c'est que beaucoup de problèmes sont les mêmes problèmes simples encore et encore. L'autre jour, je travaillais avec un client qui avait une requête de jointure à onze voies, et je me dis: «D'accord, pourquoi n'avez-vous pas utilisé une clause with?» Et ils disent: «Eh bien, je n'ai pas Je ne sais pas ce que c'est. "Et puis j'ai dit:" Et regardez vos sous-sélections ici sur votre corrélé et votre non corrélé ", j'ai dit:" Dans certains cas, vous avez dans votre clause where au niveau le plus profond, une table de référence forme l'extérieur. "J'ai dit:" C'est, déplacez-le vers le bon niveau, ne pas l'intégrer plus profondément qu'il ne doit l'être, vous confondrez l'optimiseur. "Et avec quelques ajustements nous a pris quelque chose qui fonctionnait environ deux heures et l'a réduit à dix minutes et c'était juste - dans ce cas, nous n'avons rien fait d'autre que d'améliorer le SQL qu'ils avaient écrit. Je pense que le problème est que beaucoup d'universités et beaucoup de gens qui apprennent la programmation dans un environnement non académique, ils l'apprennent comme des processus à temps enregistré ou des processus orientés sur les lignes et le relationnel est un ensemble orienté par nature, et donc vous avoir à penser en ensembles pour écrire un bon SQL.

Robin Bloor: Oui, je pense que c'est exactement ça. Et vous devez comprendre, ce sont des choses comme, les gens devraient connaître l'ABC de choses comme ça. Ça n'a pas d'importance. Vous ne pourrez pas faire des choses rationnelles si vous ne réalisez pas que même une base de données bien conçue et bien modélisée, les jointures prendront du temps, les sortes prendront du temps. Ils le font parce que le monde n'a jamais trouvé un moyen de les faire accélérer. Ils ont trouvé des moyens d'organiser les données pour aller plus vite que dans le cas contraire, et beaucoup d'enthousiasme que j'ai à dire pour les bases de données NoSQL est simplement qu'ils évitent de faire des jointures. Ils commencent juste à construire les bases de données avec la même diffusion de données, parce que si vous vous joignez à l'une des bases de données NoSQL, ils sont extrêmement puissants. Tu ne crois pas?

Bert Scalzo: Oh absolument. Et je dois rire parce que, j'ai commencé bien avant les bases de données relationnelles et quand Ingres était RTI, Relational Technology Institute, et nous n'avions pas SQL, nous avions des langages relationnels pré-SQL. Je pense qu'à Ingres, à l'époque, ça s'appelait Quel. Donc, vous avez obtenu de ces anciens paradigmes de base de données comme le réseau et un graphique supérieur, ou hiérarchique, et vous passez par les paradigmes relationnels après quelques décennies et maintenant, pour moi, j'ai l'impression que nous revenons presque à une hiérarchie. C'est presque comme si nous étions revenus.

Robin Bloor: Oui, c'est ça. Tu ferais mieux de passer la main à Eric, je consomme trop de temps, mais avons-nous des questions du public, Eric?

Eric Kavanagh: Oui, nous en avons quelques-uns. Nous allons un peu ici, mais je vais vous en jeter quelques-uns. Nous avions quelques questions sur les index invisibles. Une question était: «Est-ce que quelqu'un a besoin d'utiliser votre outil pour les voir?» Une autre question était: «Et si vous êtes aveugle?»

Bert Scalzo: C'est une bonne chose.

Eric Kavanagh: Question curieuse aussi, donc juste pour info.

Bert Scalzo: Non, vous n'avez pas besoin d'avoir nos outils. C'est une fonctionnalité Oracle, l'indice invisibles. Fondamentalement, dans le dictionnaire de données, Oracle conserve simplement un morceau de métadonnées qui dit: «Optimiseur, ignorez cet index. C'est ici, mais à moins que vous ne soyez physiquement informé via un indice dans le, un indice d'optimiseur dans la commande SQL, n'utilisez pas cela. »Et donc, non, vous n'avez pas besoin d'avoir nos outils, et à tous égards, est un vieil index simple, vous pouvez le voir dans n'importe quel outil, c'est juste l'optimiseur qui dira: "Nous l'ignorerons dans le traitement normal des requêtes". Vous devez le diriger si vous voulez qu'il soit utilisé. C'est vraiment pratique pour le scénario que j'ai décrit qui est, si vous vouliez construire un index en production mais ne risquiez pas de casser les rapports, ou les choses qui sont déjà en cours d'exécution, mais vous vouliez les tester, vous pourriez le faire. C'est pour cela que c'est le plus utile.

Eric Kavanagh: C'est une bonne chose et puis il y avait une autre bonne question ici. «Qu'en est-il de certaines de ces nouvelles bases de données en mémoire? Comment la technologie des bases de données en mémoire change-t-elle le jeu en matière d'indexation? »

Bert Scalzo: Eh bien, nous - maintenant c'est bien, je suis content que quelqu'un ait posé cette question, nous allons devoir encore une demi-heure. Non, en mémoire, cela dépend du fournisseur de la base de données. Maintenant, normalement, je le suis, je ne parle que d'éloge de tout ce qu'Oracle fait parce que c'est incroyable la technologie qu'ils ont construite, mais quand vous déchirez sous les couvertures et que vous regardez ce qui est en mémoire dans Oracle, dans l'Oracle base de données, ce qu'il est en réalité, c'est qu'il conserve toujours le magasin de lignes sur le disque, et il obtiendra le magasin de colonnes en mémoire, et s'il n'y a pas assez de mémoire pour contenir la table entière, il reviendra aux parties; il ne rentrera pas en mémoire, pour le faire stocker en ligne, et donc vous pourriez réellement faire une sélection par rapport à la table et pour la moitié de la table, vous utilisez une indexation frappant les lignes traditionnelles à la table, et pour l'autre moitié de la sélection est en train de sortir et de tout récupérer à partir d'une recherche en mémoire, et donc, c'est différent dans la façon dont SQL Server, par exemple, l'a implémenté avec leur technologie Hekaton, vous savez, et SQL 2014, et il a été amélioré dans SQL 2016, mais à certains égards, la leur est une version plus vraie de la mémoire, et, mais chaque implémentation a ses avantages et ses inconvénients, mais vous devez en quelque sorte regarder sous les couvertures et vous rendre compte. Parce que, un client m'a dit: "Oh, cette table est en mémoire - je vais simplement établir tous les index", et je me dis: "La table est plus grande que la mémoire que vous avez sur le serveur, donc à un moment donné, certaines requêtes doivent arriver sur le disque. "

Eric Kavanagh: C'est une bonne description; ce sont de bonnes choses. Eh bien, les amis, nous allons avoir quelques webdiffusions supplémentaires avec ces gars-là au cours du reste de cette année, revenez chaque fois que vous entendrez que Bert est sur une présentation parce que nous savons qu'il connaît son affaire. C'est toujours amusant de parler aux experts. Nous archivons toutes ces webémissions pour une visualisation ultérieure. Voici les informations de contact de Bert une fois de plus, et nous essaierons de trouver ce lien pour le télécharger et de l'envoyer également par e-mail, mais vous pouvez toujours envoyer les vôtres vraiment: nous avons un tas de webémissions en ligne pour cela année et nous faisons la rédaction en ce moment, alors, les gens, s'il y a des sujets que vous voulez vraiment entendre l'année prochaine, ne soyez pas timides: faites attention, les gens, nous vous parlerons la prochaine fois. Bye Bye.