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

A l’occasion d’Oracle Open World 2013, Larry Ellison a présenté la nouvelle fonctionnalité Oracle Database In-Memory 12c . Oracle organise le lancement en France de cette option révolutionnaire le 18 juin, à Paris, avec la participation de Gilles Knoery, Directeur Général de DIGORA. Oracle Database In-Memory constitue une rupture technologique véritablement bluffante, tout comme l'option Multi-Tenant, également disponible sous Oracle 12c !!!

Voici le lien d'inscription pour cet événement du 18 juin : http://eventreg.oracle.com/profile/web/index.cfm?PKWebId=0x86964beb5 Depuis quelques mois, Digora a eu le privilège de tester cette nouvelle option dans le cadre du programme Beta Testing organisé par Oracle. Cette opportunité, accordée un très faible nombre de partenaires, témoigne de la confiance et de la reconnaissance qu’Oracle accorde à Digora. Durant cette période, nous avons pu approfondir et tester cette approche révolutionnaire d’Oracle. Jusqu’au 18 juin, nous ne pourrons pas révéler les détails… Mais, pour vous faire patienter jusqu’au 18 juin, nous souhaitons ci-dessous retranscrire 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 12c Database. Cette keynote est disponible à l'URL suivante : http://medianetwork.oracle.com/video/player/2685494045001 Dans les copies d'écran qui suivent, nous avons choisi de laisser affiché le temps écoulé pour que vous puissiez retrouver les passages concernés sur la vidéo.

1. Contexte de cette keynote : Oracle Open World 2013

En même temps, pour vous donner envie de participer à Oracle Open World 2014 (voir l'offre de Digora), voici quelques photos de cette présentation.

Pendant 35 mn environ, Larry Ellison a présenté cette option. Nous découperons cette partie de 35mn en plusieurs billets sur ce blog. Voici le premier billet sur ce sujet.

2. Larry Ellison rappelle le contexte et précise les objectifs

Lorsque vous mettez vos données en mémoire, que vous chargez vos informations en mémoire, une des raisons pour lesquelles vous le faites, c’est pour rendre votre système plus rapide. Nous avons défini une série de critères dans la conception de cette option In-Memory Database. L’un de ces critères est bien connu par la plupart des concepteurs de bases de données : rendre l’exécution des requêtes beaucoup plus rapides, et l’objectif d’Oracle a été de rendre l’exécution des requêtes cent fois plus rapides. Vous prenez une machine avec son logiciel de bases de données. Vous installez un nouveau logiciel sur la même machine exactement, et les requêtes s’exécutent 100 fois plus rapidement. C’est une bonne chose ! Lorsque vous lancez une requête analytique, les résultats sont instantanés. Nous voulions obtenir les mêmes temps de réponses excellents non seulement sur des bases de type Datawarehouse, dont les tables sont organisées spécialement pour cette usage, mais nous voulions que ce type de requêtes fonctionne aussi rapidement sur des bases de type OLTP, telle que vos ERP. Donc, les requêtes doivent pouvoir s’exécuter 100 fois plus vite, que ce soit sur des bases Datawarehouse ou sur des bases OLTP. Tout en parvenant à rendre les requêtes bien plus rapides, nous devons être très prudents afin de ne pas compromettre la performance des transactions. Vous pensez bien que si vous accélérez les requêtes, il est probable que les transactions s’exécutent plus lentement, en ce qui concerne les insertions, les mises à jour, etc… Cela va probablement être ralenti. Nous avons conçu une méthode qui, non seulement accélère l’exécution des requêtes, dans une très grande mesure, mais, dans le même temps au moins, double aussi le taux de traitement des transactions.

Une démarche de bon sens bien établie, pour ce qui est  de développer une base de données transactionnelle telle qu’IBM DB2, Oracle, SQL Server, sur la façon de concevoir la base, sur la façon de stocker les données, consiste à stocker les données dans un format « ligne ». Vous avez des tables. Et dans les tables vous avez des lignes. Et dans une ligne, vous avez par exemple l’en-tête d’une commande. Par suite, si vous avez une transaction qui consiste à ajouter une ligne dans la table des entêtes de commandes, vous ne touchez qu’une ligne, la ligne insérée. Ce format de bases de données en mode lignes, qui est utilisé depuis le début de la technologie des bases de données relationnelles, a été conçu pour exécuter des applications transactionnelles très rapidement. Lors de l’ajout d’une nouvelle commande dans la table "en-tête de commandes" de votre base ERP, c’est une transaction très rapide sur une ligne avec de très nombreuses colonnes : une seule ligne est concernée. Puis vous insérez également les lignes de détails de commande. Durant ces dernières années, les professeurs d’université et les chercheurs en bases de données se sont mis à proposer un format alternatif au format ligne pour stocker vos données. Et cette alternative ne stocke pas les données en lignes mais les stocke plutôt en colonnes. L’objectif du stockage en colonnes était de rendre les requêtes beaucoup plus rapides, pour pouvoir générer des états bien plus rapidement. Par exemple, c’est très efficace pour accéder à plusieurs colonnes et un grand nombre de lignes pour ces colonnes. Il y avait donc deux formats différents pour les bases de données. Un format en lignes qui existe depuis très longtemps, depuis le début d’Oracle. Et depuis 5 ans environ un format en colonnes conçu spécialement pour accélérer le traitement des requêtes (consultations).

3. Larry Ellison révèle l'idée géniale Bien. Nous avons eu une meilleure idée. Et si on stockait les données dans les deux formats, simultanément ? Garder les données au format ligne, car nous les avons déjà au format ligne. Et si on ajoutait à ce format ligne les mêmes données, mais réarrangées, avec une rotation en quelque sorte de 90°. Réarrangée en format colonne. Et pendant que l’on y est, mettons les lignes et les colonnes en mémoire. Ainsi, en gérant les deux formats, et quand je dis en gérant les deux formats lorsque vous ajoutez une ligne, rappelez-vous l’insertion de cette ligne dans la table des commandes, cela mettra simultanément à jour le stockage en colonne. Ainsi, vous mettrez simultanément à jour le stockage en mode lignes et en mode colonnes avec ce qu’on appelle l’intégrité transactionnelle. Lorsque vous mettez à jour l’un, vous mettez automatiquement à jour l’autre. Ils sont consistants. Les données sont consistantes entre les deux formats. Maintenant, si vous avez ces deux formats et si vous mettez à jour ces deux formats, particulièrement le stockage en mode colonnes en mémoire, vous obtenez ce gain par un facteur 100 dans l’exécution des requêtes. C’est tout simplement plus rapide de parcourir les données en mode colonne qu’en mode ligne. Mais, paradoxalement, lorsque vous faites cela, lorsque vous mettez à jour les deux formats, les transactions vont plus vite. Vous pourriez vous dire que c’est contraire à votre intuition, que cela n’a pas de sens. Si vous devez maintenant mettre à jour simultanément le format ligne et le format colonne, comment pouvez-vous aller plus vite qu’en ne mettant à jour que le format ligne qui est la méthode que nous utilisons actuellement. Je reviendrai sur cette question.

Tout d’abord laissez-moi vous parler du stockage en mode colonnes. C’est une technologie complètement de type colonne.

Les colonnes sont stockées en mémoire. Elles sont fortement compressées. Elles sont utilisées de façon très intéressantes, je vais vous le montrer dans une minute. Il n’y a pas de journalisation de transaction pour le stockage en colonnes. Bien sûr nous avons la journalisation pour le stockage en mode lignes, pour permettre la récupération en cas de crash et pour différents types de Rollback. Mais nous n’avons pas besoin de le faire pour les deux modes de stockage. Par suite, il n’existe qu’un très léger overhead pour mettre à jour le stockage en colonnes en supplément du stockage en lignes classique d’Oracle. Oui, un très petit overhead.

4. Les "instruction vecteurs" (SIMD)

Maintenant que nous avons le stockage en colonnes, nous pouvons traiter les données à une vitesse démente. Chaque cœur de CPU - supposons que vous ayez un petit serveur avec 2 processeurs octo-cœurs ce qui fait 16 cœurs - chacun de ces cœurs parcourt les colonnes à des milliards de valeurs ou milliards de lignes par seconde. Chacun. Mais nous parallélisons. Donc, nous avons une machine à 2 sockets, chaque processeur dispose de 8 cœurs, nous traitons une requête en la parallélisant sur les cœurs et ils balaient les colonnes et ils examinent les valeurs à des milliards de valeurs ou des milliards de lignes par secondes. Ils sont capables de le faire car ils utilisent ces instructions exotiques à l’intérieur de la CPU appelées « instructions vecteurs ». Elles sont aussi appelées parfois instructions SIMD. Cette simple instruction multiplie les accès aux valeurs de données. Ainsi, avec une seule instruction nous pouvons effectivement parcourir des valeurs multiples. Ainsi, vous obtenez ces vitesses inimaginables.

A nouveau, prenons un exemple ; faisons une recherche sur l’état (ou département). C’est au moins 100 fois plus rapide.

5. Le cas des requêtes complexes et des jointures

Mais ne vous imaginez pas qu’il s’agit uniquement de parcourir des colonnes individuelles.

Cette approche est capable de gérer tant les requêtes complexes que les requêtes simples. Ainsi, si vous faites une jointure entre deux tables, cette jointure sera réalisée bien plus vite également. Les jointures sont converties en balayage rapide de colonnes. Par suite, des requêtes contenant de nombreuses jointures s’exécutent dramatiquement plus vite.

Conclusion provisoire...

Ainsi se termine ce premier 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 qui est réellement bluffante . 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 Vous pouvez lire la suite de cette série de billets en cliquant sur les liens suivants : http://www.digora.com/blog/oracle-database-memory-pour-vous-faire-patienter-jusquau-18-juin-partie-2 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