Oracle Database In-Memory : pour vous faire patienter jusqu'au 18 juin - partie 2

Nous avons publié récemment un premier billet détaillant la nouvelle fonctionnalité Oracle Database In-Memory 12c, à partir de la keynote de  Larry Ellison, présentée à l'Oracle Open World 2013. Pour vous faire patienter jusqu'au lancement en France par Oracle de cette option révolutionnaire le 18 juin, à Paris, où Gilles Knoery, Directeur Général de Digora, sera interviewé, voici le deuxième billet.

Rappel : depuis quelques mois, Digora a eu le privilège de tester cette nouvelle option dans le cadre du programme Beta Testing organisé par Oracle.

1. La génération de rapports

Lorsque vous construisez  des rapports, des objets compliqués, la méthode que nous pouvons utiliser maintenant, je devrais dire la méthode utilisée avec l’option In-Memory, vous avez une série de requêtes qui, vous le savez, produisent un rapport, un objet non normalisé en quelque sorte, désolé pour l’expression car un rapport n’est pas normalisé. Cet objet est créé en mémoire et utilise ensuite le Fast Column Scan pour garnir ce rapport.  Et cela est aussi, au minimum, beaucoup plus rapide que la méthode utilisée actuellement. Ainsi, nous gérons des balayages simples, des jointures complexes, la création d’objets pour des rapports, tout cela pouvant aller 100 fois plus vite qu'actuellement.

2. Les traitements OLTP : ralentis ou pas  ?

J’espère que vous me croyez quand je dis que nous pouvons effectuer ces balayages très très rapidement. Mais, revenons à la question : comment pouvez-vous rendre les transactions plus rapides, tout en mettant à jour les données simultanément dans le format ligne et aussi dans le format colonne ? Ceci représente u travail supplémentaire. Comment pouvez-vous faire plus de choses en moins de temps ? C’est une bonne question. Examinons d’abord comment les choses se passaient avant que nous n’ayons le stockage en colonne, comment Oracle fonctionne actuellement. Lorsque vous créez une table dans Oracle aujourd’hui, et que vous organisez votre base en tant que DBA, vous ne créez pas simplement une table mais vous décidez aussi sur quelles colonnes vous allez mettre un index. Donc vous créez une table, puis vous dites : je veux aussi créer un index sur cette colonne. Et puis vous définissez la Primary Key sur cette colonne, par exemple le numéro de commande. Et vous avez certainement assez d’index pour les besoins de cette transaction. Mais il y toutes sortes d’index sur d’autres colonnes tels que nom de l’état (ou département), montant, nom de client, … Il y a un paquet de choses que vous indexez, non pas pour pouvoir exécuter cette transaction, mais plutôt pour les requêtes analytique complexes des traitements. Voyez, si vous examinez la conception d’une base typique, comme vous le faites avec Oracle aujourd’hui… Vous créez quelques index. Une  paire d’index pour le traitement de la transaction et de 10 à 20 index supplémentaires pour des traitements analytiques. Reprenons cet exemple. Vous allez insérer une nouvelle commande dans la base Oracle. OK, vous insérer l’entête de la ligne de commande dans la table des commandes.  C’est une opération simple.  Puis, vous devez mettre à jour 10, 15, 20 index. Il s’agit là-aussi de 10, 15, 20 opérations, en plus d’insérer une ligne dans une table. Ainsi, insérer une ligne dans une table aujourd’hui, ce n’est pas seulement insérer une ligne dans une table, c’est insérer une ligne dans une table et ensuite mettre à jour index après index après index. C’est très coûteux. De plus, le DBA doit être très intelligent pour imaginer ce que vous voulez indexer et ce que vous ne voulez pas indexer. En d’autres mots, vous devez anticiper les requêtes et les analyses que les utilisateurs vont lancer avant même qu’ils ne les lancent, car vous devez créer ces index à l’avance. Mettre à jour ces index, ces index analytiques, est très coûteux et cela ralentit le traitement des transactions.

3. Supprimer les index analytiques

Débarrassons-nous d’eux. Jetons tous ces index analytiques.  Et remplaçons ces index analytiques par le stockage au format colonne en mémoire (In Memory Column Store). Rappelez-vous que le but des index analytiques était d’accélérer les requêtes analytiques.

Et bien, nous avons une nouvelle technologie. Qui permet aux requêtes analytiques de s’exécuter 100 fois plus vite. Nous n’avons plus besoin des index analytiques. Nous pouvons les jeter tous,  bien loin.

La table des commandes : vous insérez une ligne dans la table des commandes et vous mettez à jour 1, 2 ou 3 index et c’est tout. Ces index analytiques ont disparu ; ils sont remplacés par le stockage en colonne et le stockage a un très faible overhead pour la mise à jour et sur la mémoire. Vous n’avez pas, rappelez vous, vous n’avez pas de journalisation pour le stockage en colonne.  Tout est en mémoire. Un très faible overhead. Par suite, les traitements OLTP vont énormément  plus vite parce que nous utilisons un stockage en colonne et en mémoire plutôt que tous ces index analytiques. Mais ce n’est pas tout. Les requêtes que vous n’aviez jamais anticipé, ce que vous n’aviez jamais imaginé indexer, va s’exécuter bien plus vite désormais. Parce que le DBA n’a pas besoin de se demander ce qu’il va indexer et ce qu’il ne va pas indexer. Si vous le voulez, le stockage en colonne couvre toutes vos données. Tout, tout va plus vite. La conception de la base devient plus facile. L’optimisation, dans ce cas, devient inutile.

4. Mise en œuvre d'In-Memory Database

Laissez-moi vous montrer comme il est facile d’activer l’option In-Memory. Pour la base Oracle, c’est tout simple… Vous précisez combien de mémoire vous voulez utiliser dans le serveur.  Dites-moi combien de mémoire vous voulez utiliser. Dites-moi quelles partitions de quelles tables vous voulez rendre résidentes en mémoire. Puis, débarrassez-vous de tous ces index. Cliquez sur DELETE, DELETE, DELETE, DROP, DROP, DROP, DROP est le terme correct en SQL. DROP, DROP, DROP, DROP. Et tout fonctionne. Les requêtes vont 100 fois plus vite. Tout va plus vite. Considérez, considérez ce que vous auriez à faire si vous décidiez de garder Oracle pour votre application OLTP et que vous choisissiez de partir sur une base en mode colonne pour exécuter de grosses requêtes. Que devez-vous faire alors ? Et bien, c’est vraiment très simple. Vous gardez Oracle pour les traitements OLTP. Puis, vous faites une copie de la base. Vous déchargez vos données, rechargez vos données, réécrivez vos applications, réécrivez vos requêtes, tester à nouveau le tout, former à nouveau vos utilisateurs, et vous y êtes. En espérant que cela marche...

5. Compatibilité avec vos applications

Voici l’alternative.  Activez un switch, et toutes vos applications existantes fonctionnent bien plus vite.

Tout fonctionne. Il n’y a aucun changement dans le SQL. Il n’y a aucun changement dans vos applications. Il n’y aucune fonction non supportée. Tout ce qui fonctionne aujourd’hui fonctionne avec l’option In-Memory activée. Pas besoin de décharger/recharger les données.  Juste activer un switch. Il n’y a pas de migration de données. Chacune de vos applications, chaque application que vous avez écrit, chaque application que vous avez achetée, tout fonctionne sans  changer quoi que ce soit dans l’application. Et l’option In-Memory fonctionne parfaitement avec l’option Multi-Tenant d’Oracle 12c. Ainsi, toute cette technologie est prête pour le Cloud, idéale pour le Cloud. Il s’agit d’une proposition unique : pour chaque base que vous avez, les requêtes fonctionneront 100 fois plus vite, les mises à jour iront deux fois plus vite, simplement en activant un switch. La base sera plus facile à optimiser, elle fonctionnera plus vite, elle sera également aussi fiable et aussi sécurisée qu’elle l'est aujourd’hui.

6. In-Memory et Haute Disponibilité

Tous les avantages d’Oracle RAC, fiabilité, disponibilité, facilité de maintenance, toutes ces fonctionnalités continueront de fonctionner avec l’option In-Memory. Oracle fournit le même niveau de fiabilité qu’aujourd’hui lorsque  vous activez l’option In-Memory. Rien en change, rien ne change.  Oracle RAC fonctionne. Lorsque vous voulez une scalabilité verticale, lorsque vous voulez une scalabilité horizontale pour la mémoire, RAC continue de fonctionner.  Si un des nœuds  du Cluster RAC tombe en panne, le système continue de fonctionner.  Vous êtes protégés contre la panne d’un nœud du cluster Oracle RAC.  La perte d’un site, une corruption de données, une erreur humaine. Vous pouvez faire un « Point In Time Recovery », tout cela, tout ce que vous utilisez aujourd’hui fonctionne exactement de la même façon avec l’option In-Memory activée. C’est seulement vos requêtes qui vont aller bien plus vite et de même pour vos transactions.

7. Compatibilité avec les progiciels et témoignage de Yahoo

A nouveau, que ce soit une application développée à l’extérieur ou une application développée en interne, elle s’exécute sans changement. La seule différence est qu’elle prendra moins de temps pour s’exécuter.

Voici une citation intéressante, car, vous le savez, nous avons eu des gens qui ont essayé cette option. Et beaucoup de monde dit : In-Memory, In-Memory. Pourquoi ne pas stocker, je veux dire, si j’avais un serveur avec une mémoire suffisamment grande, la base ne rentrerait-elle pas en entier dans la mémoire maintenant ? La réponse est oui, bien sûr. Mais elle serait en mode ligne.

Alors, que dit notre client Yahoo ? « J’ai la base entière en mémoire, en mode ligne. Et j’active l’option de stockage en colonne. Et maintenant la base fonctionne plus de 100 fois plus vite. » Toutes les lignes étaient en mémoire avant. L’option In-Memory a été activée.  Le balayage de données fonctionne plus de 100 fois plus vite. C’est réel.

A suivre...

Dans la suite de la Keynote, Larry Ellison va inviter Juan Loueza, d'Oracle,  à venir sur le podium, pour présenter quelques démonstrations impressionnantes... Ainsi se termine ce deuxième billet sur la keynote présentée par Larry Ellison à Oracle Open World 2013 le 22/9/2013, keynote durant laquelle il a annoncé et décrit l’option Oracle InMemory Database 12c. Etes-vous aussi enthousiaste que DIGORA sur cette nouvelle technologie Oracle InMemory Database 12c ? Venez à la présentation Oracle du 18 juin pour en savoir beaucoup plus et bénéficier d'un retour client et de l'interview de Gilles Knoery, Directeur Général de Digora, sur les tests déjà réalisés sur cette option. Lien d’inscription pour cet événement : http://eventreg.oracle.com/profile/web/index.cfm?PKWebId=0x86964beb5 Le troisième et dernier billet sur ce thème est accessible au lien suivant : http://www.digora.com/blog/oracle-database-memory-pour-vous-faire-patienter-jusquau-18-juin-partie-3 Vous souhaitez mettre en oeuvre Oracle InMemory Database 12c rapidement ? Contactez-nous ici. Nous pouvons  prendre RDV pour le 19 juin… Index thématique du Blog Digora