{"id":440,"date":"2014-02-27T14:08:39","date_gmt":"2014-02-27T13:08:39","guid":{"rendered":"http:\/\/e3mag.com\/?p=440"},"modified":"2022-02-06T14:40:24","modified_gmt":"2022-02-06T13:40:24","slug":"logwriter-datawriter","status":"publish","type":"post","link":"https:\/\/e3mag.com\/fr\/logwriter-datawriter\/","title":{"rendered":"Logwriter & Datawriter"},"content":{"rendered":"

Les in-memory-Technologie<\/span> exige des mod\u00e8les de programmation fondamentalement nouveaux, qui ne peuvent pas \u00eatre r\u00e9alis\u00e9s par des adaptations de logiciels existants, mais n\u00e9cessitent des approches radicalement nouvelles. Un changement de paradigme s'annonce donc non seulement dans la technologie du mat\u00e9riel, mais aussi dans celle du logiciel.<\/p>\n

Au fur et \u00e0 mesure des progr\u00e8s techniques, la vitesse d'acc\u00e8s des syst\u00e8mes de stockage n'a pas suivi l'augmentation de la vitesse des processeurs. Avec des cadences de CPU de 3 GHz, ce qui correspond \u00e0 des temps de cycle de 0,3 nanoseconde, les \u00e9tapes de traitement dans le processeur durent de l'ordre de la nanoseconde (ns), alors que les acc\u00e8s au stockage externe se situent dans la plage des millisecondes (ms). C'est une disproportion de 1 \u00e0 1.000.000 !<\/p>\n

Par cons\u00e9quent, dans les applications de traitement de l'information, les CPU attendent la plupart du temps les IO. Or, il ne suffit pas de rendre le stockage plus rapide, par exemple avec des processeurs ultra-rapides. Flash<\/span>-Les dispositifs de ce type ne sont pas tr\u00e8s efficaces, car la lumi\u00e8re, et donc les donn\u00e9es, ne peuvent parcourir qu'une distance tr\u00e8s limit\u00e9e dans le domaine des ns (< 30 cm en 1 ns).<\/p>\n

Ainsi, l'acc\u00e8s rapide aux donn\u00e9es ne peut \u00eatre obtenu que si les donn\u00e9es sont conserv\u00e9es \u00e0 proximit\u00e9 du processeur : dans l'ordinateur de bureau, dans l'ordinateur portable, dans l'ordinateur de poche et dans l'ordinateur de poche. RAM<\/span>ou, mieux encore, dans le cache.<\/p>\n

Code to Data<\/h3>\n

Une acc\u00e9l\u00e9ration suppl\u00e9mentaire de la vitesse de traitement peut \u00eatre obtenue en ex\u00e9cutant le code de l'application directement dans la base de donn\u00e9es, ce qui permet d'\u00e9viter des temps de latence comparativement \u00e9lev\u00e9s lors de la communication entre l'application et la base de donn\u00e9es.<\/p>\n

Ainsi, alors que jusqu'\u00e0 pr\u00e9sent les donn\u00e9es \u00e9taient achemin\u00e9es vers l'application via la base de donn\u00e9es, le code de l'application sera \u00e0 l'avenir amen\u00e9 aux donn\u00e9es. C'est ainsi que l'on peut d\u00e9crire le plus clairement le changement de paradigme : au lieu de \"Data to Code\", on parlera \u00e0 l'avenir de \"Code to Data\".<\/p>\n

Actuellement RAM<\/span> Les donn\u00e9es sont toutefois encore volatiles, de sorte que les op\u00e9rations d'\u00e9criture dans la m\u00e9moire principale doivent \u00eatre s\u00e9curis\u00e9es par une couche de persistance, c'est-\u00e0-dire finalement \u00e0 nouveau par le stockage. Pour l'acc\u00e8s en lecture, m\u00eame \u00e0 de tr\u00e8s grandes quantit\u00e9s de donn\u00e9es, il est n\u00e9cessaire de disposer d'une couche de stockage. RAM<\/span> Les ordinateurs \u00e0 haute densit\u00e9 de stockage et \u00e0 faible prix sont d\u00e9j\u00e0 bien \u00e9quip\u00e9s aujourd'hui. RAM<\/span>-Il est important que les capacit\u00e9s de stockage (jusqu'\u00e0 plusieurs To) soient disponibles \u00e0 des prix raisonnables.<\/p>\n

Comme la lecture \u00e0 partir de RAM<\/span> Si la gestion des donn\u00e9es est aujourd'hui possible de mani\u00e8re efficace et pertinente, SAP Hana et d'autres syst\u00e8mes de gestion de m\u00e9moire se concentrent sur la gestion des donn\u00e9es.Technologies<\/span> se concentre sur les applications de lecture telles que le reporting et la Business Intelligence (OnLine Analytic Processing), OLAP<\/span>).<\/p>\n

Pour les syst\u00e8mes transactionnels (OnLine Transaction Processing, OLTP<\/span>), on peut tirer des avantages du fait que, d'une part, le reporting en ligne sur les donn\u00e9es transactionnelles est possible sans perte de performance lors du traitement des transactions ou que, d'autre part, les sections de code avec un volume \u00e9lev\u00e9 de communication entre la base de donn\u00e9es et l'application profitent d\u00e9j\u00e0 d'un transfert dans la base de donn\u00e9es.<\/p>\n

Mais que ce soit OLAP<\/span> ou OLTP<\/span>, la base de donn\u00e9es en m\u00e9moire (IMDB) n\u00e9cessite une Persistance<\/span>En effet, au plus tard lorsque l'ordinateur est \u00e9teint, les donn\u00e9es de la base de donn\u00e9es sont effac\u00e9es. RAM<\/span> disparu.<\/p>\n

Couche de persistance et performance<\/h3>\n

Dans le cas d'une IMDB, l'acc\u00e8s aux donn\u00e9es s'effectue principalement dans le cadre de l'utilisation de la base de donn\u00e9es. RAM<\/span> on pourrait s'attendre \u00e0 ce que le stockage, en tant que couche de persistance, ne joue qu'un r\u00f4le mineur en termes de performance et serve en premier lieu \u00e0 la protection, afin qu'aucune donn\u00e9e ne soit perdue. Les exigences de la SAP<\/span> \u00e0 la performance des Persistance<\/span> \u00e9taient et sont parfois plus \u00e9lev\u00e9s que pour les bases de donn\u00e9es classiques. En g\u00e9n\u00e9ral, on peut distinguer deux m\u00e9canismes d'\u00e9criture dans les bases de donn\u00e9es - Logwriter et Datawriter. Le Logwriter documente en temps r\u00e9el (synchrone) dans une zone sp\u00e9cifique chaque modification individuelle (insert, update, delete) effectu\u00e9e dans la base de donn\u00e9es. Le Datawriter actualise de temps en temps (de mani\u00e8re asynchrone) les modifications des tables dans le stockage et assure une image coh\u00e9rente, mais g\u00e9n\u00e9ralement pas actuelle (car asynchrone) de la base de donn\u00e9es. Le logwriter est critique pour le traitement des transactions et pour la r\u00e9cup\u00e9ration de la base de donn\u00e9es, si celle-ci devait s'av\u00e9rer n\u00e9cessaire. Une transaction n'est consid\u00e9r\u00e9e comme termin\u00e9e que lorsque le logwriter a signal\u00e9 qu'elle \u00e9tait document\u00e9e. Ce n'est qu'alors que le traitement peut \u00eatre poursuivi. Cela garantit qu'apr\u00e8s une interruption non planifi\u00e9e de la base de donn\u00e9es, le dernier \u00e9tat valable peut \u00eatre r\u00e9tabli en mettant \u00e0 jour la derni\u00e8re image de donn\u00e9es coh\u00e9rente avec les entr\u00e9es de journal qui n'y ont pas encore \u00e9t\u00e9 saisies (Roll Forward).<\/p>\n

Logwriter & Datawriter<\/h3>\n

Dans les premi\u00e8res r\u00e9visions de Hana<\/span> le Logwriter \u00e9tait con\u00e7u pour \u00e9crire toutes les modifications en petits blocs dans la zone Log. En cas de modifications importantes dans la base de donn\u00e9es, cela entra\u00eenait un nombre consid\u00e9rable d'op\u00e9rations IO. C'est pourquoi, \u00e0 l'\u00e9poque, l'exigence de SAP<\/span>que les Persistance<\/span> devait \u00eatre en mesure d'\u00e9crire au moins 100.000 IOps (op\u00e9rations IO par seconde).<\/p>\n

Cela n'est possible, \u00e0 un co\u00fbt raisonnable, qu'avec des Flash<\/span>-(bas\u00e9s sur PCI). C'est pourquoi la plupart des installations mononoeuds de Hana avaient et ont toujours des syst\u00e8mes bas\u00e9s sur PCIe. Flash<\/span>-dispositifs de la gamme. Plus tard, le Hana<\/span> a \u00e9t\u00e9 \u00e9tendue \u00e0 une architecture ScaleOut pour le cas o\u00f9 l'extension maximale possible de la m\u00e9moire principale au sein d'un ordinateur ne suffisait plus \u00e0 stocker enti\u00e8rement une base de donn\u00e9es plus importante.<\/p>\n

Hana<\/span> peut \u00eatre r\u00e9parti sur plusieurs n\u0153uds d'ordinateurs avec cette option. Les ordinateurs peuvent \u00eatre con\u00e7us de telle sorte qu'ils ne soient pas tous actifs, mais qu'un ou plusieurs n\u0153uds soient \u00e9galement utilis\u00e9s comme Basculement<\/span> peuvent \u00eatre configur\u00e9s pour le cas o\u00f9 un n\u0153ud actif tombe en panne. Cela n\u00e9cessite toutefois une Persistance<\/span> qui peut \u00eatre lu par tous les ordinateurs, car sinon un Basculement<\/span>-Les n\u0153uds ne peuvent pas lire les donn\u00e9es d'un ordinateur en panne.<\/p>\n

Le concept d'\u00e9criture tr\u00e8s rapide des donn\u00e9es log sur un p\u00e9riph\u00e9rique local n'\u00e9tait donc plus viable. En cons\u00e9quence, l'enregistreur de logs a \u00e9t\u00e9 optimis\u00e9 de mani\u00e8re \u00e0 pouvoir \u00e9crire des blocs de taille variable. Ainsi, les taux d'E\/S \u00e9lev\u00e9s n'\u00e9taient plus n\u00e9cessaires. Dans un sc\u00e9nario ScaleOut, 20 000 IOps par n\u0153ud d'ordinateur \u00e9taient suffisants. N\u00e9anmoins, le SAP<\/span> a maintenu les 100 000 IOps pour les n\u0153uds uniques jusqu'\u00e0 une date r\u00e9cente.<\/p>\n

Outre le Logwriter, il existe \u00e9galement, comme nous l'avons d\u00e9j\u00e0 mentionn\u00e9, le Datawriter. On pourrait d'abord penser qu'il n'est pas critique en termes de performances, puisqu'il \u00e9crit de mani\u00e8re asynchrone. En r\u00e9alit\u00e9, il \u00e9crit Hana<\/span> \u00e0 des intervalles de temps configurables - par d\u00e9faut, cinq minutes - appel\u00e9s points de sauvegarde. La performance du stockage doit \u00eatre con\u00e7ue de mani\u00e8re \u00e0 ce que le volume modifi\u00e9 entre deux points de sauvegarde puisse \u00eatre \u00e9crit dans l'intervalle de temps disponible, du moins en termes de d\u00e9bit.<\/p>\n

Comme le Datawriter fonctionne selon le principe de la copie sur \u00e9criture, la charge d'\u00e9criture a tendance \u00e0 \u00eatre s\u00e9quentielle, car les donn\u00e9es modifi\u00e9es ne sont pas enregistr\u00e9es. Blocs<\/span> ne sont pas \u00e9cras\u00e9es, mais les modifications sont transf\u00e9r\u00e9es dans des fichiers nouvellement allou\u00e9s. Blocs<\/span> peuvent \u00eatre d\u00e9pos\u00e9s. Cela simplifie les exigences en mati\u00e8re de Persistance<\/span>La raison en est que l'IO s\u00e9quentielle peut \u00eatre r\u00e9alis\u00e9e de mani\u00e8re beaucoup plus efficace que l'IO al\u00e9atoire.<\/p>\n

Comme l'architecture interne bas\u00e9e sur les colonnes de Hana<\/span> est comparable \u00e0 des bases de donn\u00e9es index\u00e9es \u00e0 cent pour cent, les r\u00e9sultats sont moins bons que ceux d'autres bases de donn\u00e9es. Hana<\/span> plus souvent des r\u00e9organisations internes, qui se r\u00e9percutent ensuite sur les Persistance<\/span> \u00eatre repr\u00e9sent\u00e9s.<\/p>\n

Les exigences du Datawriter en mati\u00e8re de d\u00e9bit d'\u00e9criture augmentent donc. En revanche, on devrait s'attendre \u00e0 ce que les exigences en mati\u00e8re de d\u00e9bit d'E\/S soient plut\u00f4t faibles lors de la lecture de donn\u00e9es, car Hana<\/span> donn\u00e9es en fait dans le RAM<\/span> devrait lire.<\/p>\n

Cela peut \u00eatre vrai pour le fonctionnement normal, mais pas pour le cas o\u00f9 Hana<\/span> est d\u00e9marr\u00e9. Si l'on suppose que 1 To de donn\u00e9es doit \u00eatre lu dans la m\u00e9moire principale, cela prend tout de m\u00eame 20 minutes avec un d\u00e9bit de 1 Go\/sec. Cela ne serait pas un probl\u00e8me si les red\u00e9marrages de la base de donn\u00e9es \u00e9taient l'exception.<\/p>\n

Puisque Hana<\/span> est en constante \u00e9volution dans le but d'utiliser un jour la NVRAM de mani\u00e8re optimale, des mises \u00e0 jour doivent \u00eatre effectu\u00e9es \u00e0 intervalles r\u00e9guliers, souvent accompagn\u00e9es d'un red\u00e9marrage de la base de donn\u00e9es. C'est ce qui explique la demande de SAP<\/span>qui Persistance<\/span> de les doter \u00e9galement de d\u00e9bits \u00e9lev\u00e9s pour la lecture dans le domaine des donn\u00e9es.<\/p>\n

OLAP<\/span> versus OLTP<\/span><\/strong><\/h3>\n

M\u00eame si, comme nous l'avons mentionn\u00e9 plus haut, le domaine d'utilisation principal des IMDB a tendance \u00e0 \u00eatre le cin\u00e9ma. OLAP<\/span> se trouve, va SAP<\/span> d\u00e9j\u00e0 le chemin, m\u00eame OLTP<\/span>-applications sur Hana<\/span> (Suite on Hana<\/span>). Techniquement, il est possible d'utiliser pour OLTP<\/span>-Pour les syst\u00e8mes de gestion de l'information, il est possible d'utiliser aussi bien des n\u0153uds uniques que des architectures ScaleOut.<\/p>\n

Du point de vue de la performance, il existe toutefois une diff\u00e9rence significative. Comme nous l'avons d\u00e9j\u00e0 expliqu\u00e9, pour OLTP<\/span>-Les applications de la s\u00e9rie C offrent un avantage de performance Hana<\/span> Les probl\u00e8mes de s\u00e9curit\u00e9 peuvent survenir lorsque des parties de code sont transf\u00e9r\u00e9es dans la base de donn\u00e9es afin d'\u00e9viter une communication chronophage entre l'application et la base de donn\u00e9es.<\/p>\n

Si Hana<\/span> mais dans un environnement ScaleOut, il est tr\u00e8s difficile de r\u00e9partir le code et les tables de donn\u00e9es entre les n\u0153uds de mani\u00e8re \u00e0 ce que les lignes de code trouvent leurs tables sur le m\u00eame ordinateur que celui sur lequel elles sont ex\u00e9cut\u00e9es. En effet, si le code doit aller chercher les donn\u00e9es sur un n\u0153ud voisin, il y a \u00e0 nouveau des frais de communication entre les n\u0153uds, ce qui se produit avec une latence comparativement \u00e9lev\u00e9e, comme si le code \u00e9tait rest\u00e9 directement sur le serveur d'application.<\/p>\n

Pour cette raison, une impl\u00e9mentation mononode de Hana<\/span> pour OLTP<\/span> est en tout cas pr\u00e9f\u00e9rable \u00e0 une architecture ScaleOut.<\/p>\n

En m\u00eame temps, il y avait SAP<\/span> jusqu'\u00e0 pr\u00e9sent pour Hana<\/span> en tant que n\u0153ud unique, sur la demande de log devices (internes) rapides. Les p\u00e9riph\u00e9riques de log internes sont toutefois n\u00e9cessaires pour les applications critiques. Applications OLTP<\/span> inacceptable, car la perte de l'ordinateur ou du dispositif de journalisation s'accompagne en m\u00eame temps d'une perte de donn\u00e9es.<\/p>\n

Les donn\u00e9es critiques pour l'entreprise, en particulier les donn\u00e9es de log, devraient toujours \u00eatre \u00e9crites (miroir) \u00e0 un deuxi\u00e8me endroit, de sorte qu'en cas d'urgence, on puisse r\u00e9cup\u00e9rer la base de donn\u00e9es \u00e0 partir d'une deuxi\u00e8me source jusqu'\u00e0 la derni\u00e8re transaction achev\u00e9e.<\/p>\n

Fujitsu a tr\u00e8s t\u00f4t Hana<\/span>-L'architecture single-node a \u00e9t\u00e9 int\u00e9gr\u00e9e dans le concept d'exploitation FlexFrame et les donn\u00e9es log ont \u00e9t\u00e9 plac\u00e9es sur des unit\u00e9s de stockage externes pouvant \u00eatre mises en miroir. Certes, les 100.000 IOps exig\u00e9s jusqu'\u00e0 pr\u00e9sent ne sont pas disponibles, mais d'un point de vue technique, ils ne sont plus n\u00e9cessaires depuis longtemps. Cela permet toutefois de garantir pour Hana<\/span> le fonctionnement s\u00fbr et flexible connu de FlexFrame est garanti pour les applications critiques avec les SLA \u00e9lev\u00e9s qui les caract\u00e9risent.<\/p>\n

Entre-temps, la SAP<\/span> des exigences \u00e9lev\u00e9es en mati\u00e8re d'E\/S pour le Logwriter, afin de Hana<\/span> pr\u00e9parer pour une int\u00e9gration flexible dans l'exploitation du centre de calcul.<\/p>\n

Concept d'exploitation efficace et bases de donn\u00e9es parall\u00e8les<\/h3>\n

L'exigence d'un stockage s\u00e9curis\u00e9 des donn\u00e9es et d'un concept d'exploitation efficace est satisfaite par l'int\u00e9gration de Hana<\/span> a \u00e9t\u00e9 r\u00e9solu dans FlexFrame. Avec un stockage partag\u00e9 en miroir, la haute disponibilit\u00e9 est garantie tant au niveau local qu'\u00e0 l'\u00e9chelle du centre de calcul.<\/p>\n

Un point en suspens est encore le probl\u00e8me des temps de red\u00e9marrage. En fonction de la taille de la base de donn\u00e9es, un red\u00e9marrage complet peut prendre un temps excessivement long, m\u00eame avec des canaux d'E\/S tr\u00e8s performants.<\/p>\n

Dans le cadre du d\u00e9veloppement de Hana<\/span> travaille SAP<\/span> au concept de base de donn\u00e9es fant\u00f4me qui, dans l'id\u00e9al, minimiserait les temps de commutation, \u00e9tant donn\u00e9 que les bases de donn\u00e9es fant\u00f4me fonctionnent g\u00e9n\u00e9ralement de mani\u00e8re presque synchrone avec les donn\u00e9es primaires.<\/p>\n

Apr\u00e8s une panne de la base de donn\u00e9es primaire, l'activation et la r\u00e9cup\u00e9ration compl\u00e8te de la base de donn\u00e9es fant\u00f4me ne prendraient que quelques minutes avant que l'activit\u00e9 ne puisse reprendre.<\/p>\n

Les bases de donn\u00e9es parall\u00e8les sont en Hana<\/span> n'est pas encore disponible aujourd'hui, mais comme \u00e9tape pr\u00e9liminaire, il offre Hana<\/span> l'option de r\u00e9plication du syst\u00e8me, qui veille \u00e0 ce que les donn\u00e9es de log soient r\u00e9pliqu\u00e9es de mani\u00e8re synchrone vers une deuxi\u00e8me instance et que, \u00e0 intervalles r\u00e9guliers, le columnstore (la structure des colonnes) de Hana<\/span> est pr\u00e9charg\u00e9 dans la m\u00e9moire principale et mis \u00e0 jour.<\/p>\n

Ainsi, dans le cas d'un Basculement<\/span> le rechargement complet du Columnstore, puisque la plus grande partie est d\u00e9j\u00e0 pr\u00e9charg\u00e9e. Cela permet de r\u00e9duire les temps de red\u00e9marrage \u00e0 un niveau raisonnable dans les environnements critiques.<\/p>\n

La recommandation pour les applications qui n'autorisent qu'un temps d'arr\u00eat minimal serait d'utiliser localement le syst\u00e8me d'exploitation pour la production. Hana<\/span>-Il est \u00e9galement possible d'exploiter une deuxi\u00e8me instance avec r\u00e9plication du syst\u00e8me et, en cas de catastrophe, d'utiliser l'instance de production. Persistance<\/span> de faire un miroir dans un deuxi\u00e8me RZ.<\/p>\n

Comme l'instance avec la r\u00e9plication du syst\u00e8me n'utilise qu'une petite partie des ressources de l'ordinateur, d'autres syst\u00e8mes non productifs pourraient \u00eatre exploit\u00e9s en parall\u00e8le sur le n\u0153ud de l'ordinateur.<\/p>\n

ScaleOut<\/h3>\n

Il reste \u00e0 discuter de la mani\u00e8re dont une architecture ScaleOut doit \u00eatre \u00e9valu\u00e9e par rapport \u00e0 un n\u0153ud unique. En principe, tant pour OLTP<\/span> que pour OLAP<\/span>que, pour une m\u00eame taille de base de donn\u00e9es, le n\u0153ud unique, s'il est utilis\u00e9 par les RAM<\/span>-La solution la plus appropri\u00e9e est d'utiliser les capacit\u00e9s de stockage de l'ordinateur.<\/p>\n

Il y a essentiellement deux raisons \u00e0 cela. La premi\u00e8re a d\u00e9j\u00e0 \u00e9t\u00e9 \u00e9voqu\u00e9e lors de la discussion en rapport avec OLTP<\/span> est discut\u00e9e. La communication entre les n\u0153uds de la base de donn\u00e9es prend comparativement beaucoup de temps et a une influence n\u00e9gative sur les performances.<\/p>\n

Sp\u00e9cialement pour Applications OLAP<\/span> le probl\u00e8me de l'association habile des lignes de code aux donn\u00e9es n'est pas aussi pertinent que pour les OLTP<\/span>En effet, la structure math\u00e9matique des requ\u00eates permet en g\u00e9n\u00e9ral de les traiter de mani\u00e8re bien r\u00e9partie. Il n'en reste pas moins que le probl\u00e8me de la latence demeure, car les r\u00e9sultats partiels d'une requ\u00eate doivent finalement \u00eatre r\u00e9unis sur un n\u0153ud et consolid\u00e9s en un r\u00e9sultat final.<\/p>\n

Un deuxi\u00e8me probl\u00e8me se pose par exemple pour les jointures qui passent par des tables r\u00e9parties sur plusieurs n\u0153uds. Avant que la jointure puisse \u00eatre ex\u00e9cut\u00e9e, les donn\u00e9es des tables concern\u00e9es doivent \u00eatre transf\u00e9r\u00e9es et stock\u00e9es temporairement sur le n\u0153ud sur lequel la jointure est ex\u00e9cut\u00e9e. Cela prend d'une part du temps et d'autre part de la m\u00e9moire principale suppl\u00e9mentaire.<\/p>\n

Dans le cas d'un n\u0153ud unique, la transmission des donn\u00e9es et le stockage interm\u00e9diaire ne sont pas n\u00e9cessaires, puisque toutes les donn\u00e9es sont locales. Il est donc recommand\u00e9 d'utiliser le plus longtemps possible une instance \u00e0 n\u0153ud unique pour les applications.<\/p>\n

Les d\u00e9veloppements actuels en mati\u00e8re de technologie mat\u00e9rielle vont dans le sens de cette approche. Avec le mat\u00e9riel officiellement disponible en f\u00e9vrier 2014, il sera possible de stocker jusqu'\u00e0 12 TB RAM<\/span> dans une machine.<\/p>\n

SAP<\/span> fait savoir qu'avec le nouveau mat\u00e9riel, elle prendra en charge jusqu'\u00e0 6 To sur un ordinateur pour les applications OLTP dans les syst\u00e8mes de production, et qu'elle sera en mesure de prendre en charge jusqu'\u00e0 6 To sur un ordinateur pour les applications OLTP dans les syst\u00e8mes de production. OLAP<\/span> jusqu'\u00e0 2 To pour huit sockets \u00e9quip\u00e9s, contre 1 To par le pass\u00e9.<\/p>\n

Cela semble plausible, car la puissance du processeur de la nouvelle g\u00e9n\u00e9ration de processeurs a environ doubl\u00e9. Toutefois, la performance des Hana<\/span>-Technologie<\/span> Ces derni\u00e8res ann\u00e9es, la technologie s'est constamment et significativement am\u00e9lior\u00e9e, ce qui permet d'envisager l'avenir avec plus de confiance. RAM<\/span>-Il est possible d'imaginer une extension de la capacit\u00e9 de stockage de 2 To pour un n\u0153ud dans une architecture ScaleOut.<\/p>\n

\"https:\/\/e3mag.com\/partners\/fujitsu\/\"<\/a><\/p>","protected":false},"excerpt":{"rendered":"

Avec Hana, SAP d\u00e9veloppe depuis quelques ann\u00e9es une nouvelle base technique pour ses applications. La motivation est peut-\u00eatre li\u00e9e au fait qu'un changement de paradigme technologique est en train de se produire avec la m\u00e9moire principale non volatile (NVRAM - non volatile RAM).<\/p>","protected":false},"author":46,"featured_media":1125,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"pmpro_default_level":"","footnotes":""},"categories":[5],"tags":[424,428,430],"coauthors":[24296],"class_list":["post-440","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it-management","tag-in-memory-technologie","tag-olap","tag-oltp","pmpro-has-access"],"acf":[],"featured_image_urls_v2":{"full":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"thumbnail":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-150x150.jpg",150,150,true],"medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",400,267,false],"medium_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-768x512.jpg",768,512,true],"large":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"image-100":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-100x67.jpg",100,67,true],"image-480":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-480x320.jpg",480,320,true],"image-640":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-640x427.jpg",640,427,true],"image-720":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-720x480.jpg",720,480,true],"image-960":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-960x640.jpg",960,640,true],"image-1168":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"image-1440":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"image-1920":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"1536x1536":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"2048x2048":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"trp-custom-language-flag":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",18,12,false],"bricks_large_16x9":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"bricks_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"bricks_large_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"bricks_medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",600,400,false],"bricks_medium_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",600,400,false],"profile_24":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-24x24.jpg",24,24,true],"profile_48":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-48x48.jpg",48,48,true],"profile_96":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-96x96.jpg",96,96,true],"profile_150":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-150x150.jpg",150,150,true],"profile_300":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-300x300.jpg",300,300,true]},"post_excerpt_stackable_v2":"

SAP entwickelt mit Hana seit einigen Jahren eine neue technische Basis f\u00fcr ihre Anwendungen. Die Motivation daf\u00fcr mag darin begr\u00fcndet sein, dass mit nicht fl\u00fcchtigem Hauptspeicher (NVRAM \u2013 non volatile RAM) ein technologischer Paradigmenwechsel bevorsteht.<\/p>\n","category_list_v2":"IT-Management<\/a>","author_info_v2":{"name":"J\u00fcrgen Meynert, Fujitsu","url":"https:\/\/e3mag.com\/fr\/author\/juergen-meynert\/"},"comments_num_v2":"0 commentaire","_links":{"self":[{"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/posts\/440","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/users\/46"}],"replies":[{"embeddable":true,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/comments?post=440"}],"version-history":[{"count":0,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/posts\/440\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/media\/1125"}],"wp:attachment":[{"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/media?parent=440"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/categories?post=440"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/tags?post=440"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/coauthors?post=440"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}