Oracle ajoute l'option « in-memory database » à Oracle Database 12c

Oracle ajoute l'option « in-memory database » à Oracle Database 12c,
pour une exécution des requêtes 100 fois plus rapide

La conférence annuelle OpenWorld d'Oracle a débuté ce dimanche à San Francisco et se tiendra jusqu'au 26 septembre au Moscone Center. Larry Ellison, fondateur et PDG de la structure, annonce l'option « in-memory database » pour Oracle Database 12c. L'objectif est d'exécuter des requêtes 100 fois plus vite mais aussi de multiplier par deux l’activité transactionnelle sans modifier le code applicatif.

Pour parvenir à ces prouesses, Oracle ajoute au stockage en ligne le stockage dans une nouvelle zone mémoire dans un format « columnar » (base de données en colonnes) qui apporte le gain de performance et réduit le temps de réponse de façon significative.

« Tout ce qui fonctionne aujourd’hui, s’enclenche lorsqu’on appuie sur on. Vous pouvez doubler la vitesse des mises à jour de toute base de données Oracle, en appuyant sur un bouton », explique Larry Ellison.

Cette initiative vise surtout son concurrent SAP, chez qui l’in-memory est déjà disponible depuis deux ans sur HANA. Rappelons qu'Oracle utilisait, jusqu'à aujourd'hui, la technologie HANA. Pour l'instant, aucune information n'a filtré quant au prix et à la disponibilité de cette solution.

Source : Forbes

Et vous ?

:fleche: Qu'en pensez-vous ?

Certains gros clients vont apprécier.

Mais c'est quoi la limitation?

Il doit y en avoir une puisque sinon, cela serait mis par défaut pour toute requête executée, non?

Ho la limitation va être bien simple.

Il faudra vider le portefeuille pour avoir accès à l'option. C'est comme ça chez Oracle.

Enfin le paramètre d'init "fast=true", hourra !

Citation:

---

Envoyé par Stéphane le calme


Pour l'instant, aucune information n'a filtré quant au prix et à la disponibilité de cette solution.

---

À en croire ce document qui date du 19 septembre, il faut débourser 23000$ par processeur pour l'option "in-memory database cache"...

Quelqu'un avait regardé Oracle TimesTen, qui est la DB in-memory d'Oracle depuis quelques années ?

Citation:

---

Envoyé par Waldar

Quelqu'un avait regardé Oracle TimesTen, qui est la DB in-memory d'Oracle depuis quelques années ?

---

Je travaille avec la machine Exalytics d'Oracle ou Timesten est installe.

C'est du decisionnel et Timesten vient plus de l'OLTP.

J'ai encore aucune connaissance des prix pour pouvoir verfiier qu'elle configuration est la meilleure (Oracle database ou Timesten)

Il a tout ce qui lui faut a part le query parallelisme. Nous attendons avec impatience cette ajout.

Apres ca reste de l'in-memory et souvent il n'est pas possible de tout charger en memoire. Il faut donc faire des choix de data a charger ce qui revient a creer des aggregations.

Citation:

---

Envoyé par chaporon

Apres ca reste de l'in-memory et souvent il n'est pas possible de tout charger en memoire. Il faut donc faire des choix de data a charger ce qui revient a creer des aggregations.

---

Sur une machine standard oui. Mais sur une appliance ou un serveur bien taillé non.
Si on prend le futur SPARC M6-32 il y a 32 To de Ram, de quoi héberger une belle petite base 8-).
C'est ce qui se passe avec Hana, où tout est en mémoire.

Citation:

---

Envoyé par doc malkovich

Sur une machine standard oui. Mais sur une appliance ou un serveur bien taillé non.

---

16Tb pour 3.1 Million (a la fin de la page)

Les entreprises qui peuvent se payer ca ne sont pas millions. C'est toujours un choix entre cout (hardware) et possibilites logiciels.

J'en ai 2T pour 100M Euro et sans rentrer dans les details:
- l'os en prend pas mal (300Mo de memoire)
- les applications aussi (300Mo aussi)
- Et lorsque tu charges des donnees en "memoire", le cout en IO augmente. 1 Mo sur ton disque, ce n'est pas un Mo en memoire (surtout du fait que les data type ne sont pas variables, il te faut donc reserver de la place). Est-ce lier au fonctionement de la memoire ? Je ne sais pas. J'ai encore pleins de choses a apprendre.

Citation:

---

Envoyé par chaporon

Les entreprises qui peuvent se payer ca ne sont pas millions. C'est toujours un choix entre cout (hardware) et possibilites logiciels.

---

C'est clair. Mais ça existe, et l'évolution "naturelle" du hardware fait que la ram devient plus accessible, et je ne parle pas du ssd.

Citation:

---

1 Mo sur ton disque, ce n'est pas un Mo en memoire (surtout du fait que les data type ne sont pas variables, il te faut donc reserver de la place). Est-ce lier au fonctionement de la memoire ?

---

Si les données sont stockées en colonnes elles sont facilement compressées. Et prennent moins de place ... C'est le principe de SAP Hana, Sybase IQ ou Qlikview (90% en moins).

Oracle présente sa solution « in-memory » pour concurrencer SAP et Microsoft
l’option sera disponible avec Oracle Database 12c dans un mois

Dans le secteur des bases de données, la tendance est à la course aux performances avec la nouvelle option « in-Memory », un concept qui consiste à mettre en cache les données traitées par les applications plutôt que, par exemple, de faire des appels à un serveur.

SAP a été le pionnier des solutions in-memory avec sa solution « SAP in-memory » incluse dans la plateforme HANA lancée en 2010. Cette offre permettrait le traitement de volumes massifs de données en temps réel, en mémoire vive, avec à la clé une division par 1200 du temps de traitement dans certains scénarios.

Microsoft avait suivi en intégrant « Hekaton » à SQL Server 2012. La solution « In-Memory » de la société offrirait des performances jusqu’à 10 fois supérieures pour des applications existantes et jusqu’à 50 fois supérieures pour de nouvelles applications optimisées pour l’in-memory. IBM avait également fait le pas vers le concept « In-memory ».

Oracle, le géant des bases de données, n’est pas resté les bras croisés à regarder ses concurrents le distancer. La société a également travaillé sur une solution in-memory qui sera incluse à Oracle Database 12c. L'objectif d’Oracle est d'exécuter des requêtes 100 fois plus vite, mais aussi de multiplier par deux l’activité transactionnelle sans modifier le code applicatif.

Larry Ellison, PDG de la société, a annoncé lors d’un événement en ligne que l’option in-memory sera disponible dans son gestionnaire de base de données à partir du mois prochain, soit en avance sur le calendrier de la firme. L’option permettra aux administrateurs de stocker les données dans la mémoire du serveur, plutôt que sur le disque, afin de gagner en temps d’exécution.

Contrairement aux offres de la concurrence, notamment HANA de SAP, la solution d’Oracle sera compatible avec toutes les applications existantes. Les administrateurs n’auront pas à modifier leurs applications pour tirer parti de cette évolution d’Oracle Database 12c.

Les démonstrations lors du webcast d’Oracle ont montré une accélération de 100 à 1000 fois des performances des applications d’entreprise, notamment pour les applications Oracle E-Business Suite, Oracle JD Edwards, Oracle PeopleSoft, Oracle Siebel et Oracle Fusion Applications.

Source : Oracle

Intéressant ... Mais le nombre de données pouvant être stockées en mémoire doit être relativement faible non ? De plus cela pourra impacter les performances globales du serveur ... Je reste sceptique sur cette solution.

SAP n'était pas vraiment le premier, il y avait déjà un certain nombre de solutions avant eux:


VMware Gemfire (Java)
Oracle Coherence (Java)
Alachisoft NCache (.Net)
Gigaspaces XAP Elastic Caching Edition (Java)
Hazelcast (Java)
Scaleout StateServer (.Net)
IBM eXtreme Scale
Terracotta Enterprise Suite
Jboss (Redhat) Infinispan

Excellente nouvelle :)
Les SGBD ne sont que trop pénalisés par les performances des disques...

Sinon, sauf erreur de ma part, "Hekaton" a été intégré à SQL Server 2014 et non 2012 ;)

Pour information le lancement officiel aura lieu le 18 dans l'après midi dans un grand Hotel Parisien.
L'occasion de se faire une idée et de poser des questions pour les plus anglophones

Pour s'inscrire c'est ici : http://www.oracle.com/us/dm/sev10031...2905MPP001C001

L'architecture hybride de L'exadata fait déjà des merveilles, alors si en plus on peut choisir de mettre certaines données spécifiquement en mémoire c'est parfait.
Et si c'est compatible avec HCC ça ne devrait même pas couter si cher que ça.

Quelqu'un a une idée de la license? Est-ce encore un extra ou c'est intégré dans la license qui comprend le partioning?

Impatient de tester ça sur mes Data Warehouses.

Citation:

---

Envoyé par *Serval

Quelqu'un a une idée de la license? Est-ce encore un extra ou c'est intégré dans la license qui comprend le partioning?

Impatient de tester ça sur mes Data Warehouses.

---

Bonjour ,
un extra cost est à prévoir pour l'option in-memory.
rien à voir avec celui du partitionnement.

Oracle est très en retard sur ce sujet.

SQL Server 2014 qui est sortit en avril 2014, possède la fonctionnalité "In memory" incluse dans la version Enterprise (il n'existe pas d'add-on payant dans SQL Server pour les fonctionnalités, qui sont juste présentes ou pas dans telle ou telle version).
En sus du "in memory" avec des tables organisées de manière verticales et destinées à l'OLTP, MS Propose des procédures compilées en natif (langage C), ce qu'Oracle a déjà fournit par le passé.

Oracle qui avait perdu en sécurité par rapport à SQL Server depuis la version 2005, puis en fiabilité avec la sortie de SQL Server 2008 (mirroring) puis 2012 (AlwaysOn) a aujourd'hui perdu le seul avantage qui lui restait, les performances...

En matière de coût, que ce soit en licences ou en coût d'exploitation, SQL Server a toujours été bien moins cher à fonctionnalités équivalentes.

Bref, c'est l'inexorable déclin d'Oracle, ce que confirme de nombreuses études, comme par exemple la toute dernière de Tesora.


A +

Références :
http://www.computerweekly.com/featur...erver-security
http://itic-corp.com/blog/2010/09/sq...se-since-2002/
http://public.dhe.ibm.com/common/ssi...L14396USEN.PDF
http://resources.tesora.com/site/whi...-private-cloud

Oracle propose du "In memory" avec times ten depuis des années.

La nouvelle option "In memory" à sortir propose du stockage colonne en mémoire avec plus ou moins de compression.

L'argument commercial qu'il y a derrière est la simplicité de mise en place

Code:

---

alter table toto in memory

---

C'est fini ça fonctionne, non seulement les DBAs vont trouver ça 'trop simple' mais les développeurs n'auront rien à faire et tout est là : pas d'adaptation de code et des gains de performance annoncés pouvant aller jusqu'à 99,9% ...

Ca c'est la brochure publicitaire.

Forcément les tests révèlent des limites à l'outil. La première est évidente : pour faire du in memory, il faut avoir de la mémoire : beaucoup de mémoire. Mais j'ai aussi vu des requêtes d’agrégation sur des tables de quelques GigasOctets passer de quelques dizaines de secondes avec la table pourtant déjà en cache à quelques centièmes de secondes avec la table en zône de stockage colonne sans changer le code et surtout sans avoir besoin de faire appel à des procédures spécifiques (d'où l'inutilité, du point de vue oracle, d'en développer).

Alors certes Oracle décline ... mais en fait c'est plus, de mon point de vue, le paradigme de base de données relationnelles qui est en perte de vitesse face à l'arrivée des bases de données non structurées, en mémoire, en colonne, partitionnées sur n serveurs, hiérarchiques ... bref toutes ces choses regroupées sous les noms de NoSQL et de big Data que la montée de telle ou telle base concurrente

Juste pour ma curiosité puisque je ne suis pas un grand expert Oracle mais c'est quoi la différence avec le "Row cache" ?

Citation:

---

Envoyé par Nemek

Juste pour ma curiosité puisque je ne suis pas un grand expert Oracle mais c'est quoi la différence avec le "Row cache" ?

---

Bonjour,

Le 'row cache' cache des lignes un peu comme une table de hachage clé->valeur. C'est une techno d'il y a au moins 20 ans.
Le storage In-Memory qui va sortir stocke des colonnes, dans le but de les scanner rapidement avec des opérations CPU qui travaillent sur des vecteurs de données.
Il n'y a pas vraiment de point communs. In-Memory n'est pas un cache d'ailleurs. C'est un stockage redondant.

On ne peut pas encore trop parler de l'option In-Memory car elle est encore en beta. Elle devrait sortir d'ici quelques jours. Voici ce que j'avais écrit dessus avant d'avoir la beta: http://www.dbi-services.com/index.ph...ting-for-12102 (in english...)

Cordialement,
Franck.

Merci pour cet article, je prends beaucoup mieux ;-)
Effectivement le stockage en colonne est très important. Je ne pensais pas qu'il ferait un retour arrière sur le "fixed size" qui était pour moi l'élément le plus déterminant pour optimiser les accès (l'âge d'or des fichiers séquentiels indexés).

Article intéressant

Citation:

---

Envoyé par pachot

In-Memory n'est pas un cache d'ailleurs. C'est un stockage redondant.

---

Merci de préciser. Par nature un cache est un stockage redondant non ?

Citation:

---

Envoyé par doc malkovich

Merci de préciser. Par nature un cache est un stockage redondant non ?

---

Disons que le cache c'est une structure dont on a besoin de toute façon pour accéder aux données, mais qu'on garde un peu plus longtemps que nécessaire au cas où on ait besoin d'accéder aux même données peu de temps après. Par exemple, pour lire un bloc d'un datafile, et encore plus pour le mettre à jour, il faudra de toute façon un buffer. Le buffer cache, c'est seulement le fait que ces buffers sont partagés et gardés même lorsque l'écriture sur disque est faite.
Par contre, l'option In-Memory c'est un stockage supplémentaire, dont la mise à jour se fait en parallèle. C'est un nouveau segment, redondant car il peut être reconstruit à partir de la table, un peu comme un index ou une vue matérialisée. Sauf qu'il est en mémoire, et qu'il a un format 'colonne'. Ca ressemble plus à de la réplication qu'à un cache. et l'optimiseur choisit d'aller lire l'un ou l'autre.
Alors qu'avec le buffer cache, l'optimiseur n'a pas le choix. Il y aura toujours un buffer get, qu'il faille faire un disk read ou non pour alimenter ce buffer.

Citation:

---

Envoyé par Nemek

(l'âge d'or des fichiers séquentiels indexés).

---

Oui... Bitmap Index avait déjà un peu évolué vers le columnar.