Logwriter & Datawriter

Les in-memory-Technologie exige des modèles de programmation fondamentalement nouveaux, qui ne peuvent pas être réalisés par des adaptations de logiciels existants, mais nécessitent des approches radicalement nouvelles. Un changement de paradigme s'annonce donc non seulement dans la technologie du matériel, mais aussi dans celle du logiciel.

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

Par conséquent, 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-Les dispositifs de ce type ne sont pas très efficaces, car la lumière, et donc les données, ne peuvent parcourir qu'une distance très limitée dans le domaine des ns (< 30 cm en 1 ns).

Ainsi, l'accès rapide aux données ne peut être obtenu que si les données sont conservées à proximité du processeur : dans l'ordinateur de bureau, dans l'ordinateur portable, dans l'ordinateur de poche et dans l'ordinateur de poche. RAMou, mieux encore, dans le cache.

Code to Data

Une accélération supplémentaire de la vitesse de traitement peut être obtenue en exécutant le code de l'application directement dans la base de données, ce qui permet d'éviter des temps de latence comparativement élevés lors de la communication entre l'application et la base de données.

Ainsi, alors que jusqu'à présent les données étaient acheminées vers l'application via la base de données, le code de l'application sera à l'avenir amené aux données. C'est ainsi que l'on peut décrire le plus clairement le changement de paradigme : au lieu de "Data to Code", on parlera à l'avenir de "Code to Data".

Actuellement RAM Les données sont toutefois encore volatiles, de sorte que les opérations d'écriture dans la mémoire principale doivent être sécurisées par une couche de persistance, c'est-à-dire finalement à nouveau par le stockage. Pour l'accès en lecture, même à de très grandes quantités de données, il est nécessaire de disposer d'une couche de stockage. RAM Les ordinateurs à haute densité de stockage et à faible prix sont déjà bien équipés aujourd'hui. RAM-Il est important que les capacités de stockage (jusqu'à plusieurs To) soient disponibles à des prix raisonnables.

Comme la lecture à partir de RAM Si la gestion des données est aujourd'hui possible de manière efficace et pertinente, SAP Hana et d'autres systèmes de gestion de mémoire se concentrent sur la gestion des données.Technologies se concentre sur les applications de lecture telles que le reporting et la Business Intelligence (OnLine Analytic Processing), OLAP).

Pour les systèmes transactionnels (OnLine Transaction Processing, OLTP), on peut tirer des avantages du fait que, d'une part, le reporting en ligne sur les données transactionnelles est possible sans perte de performance lors du traitement des transactions ou que, d'autre part, les sections de code avec un volume élevé de communication entre la base de données et l'application profitent déjà d'un transfert dans la base de données.

Mais que ce soit OLAP ou OLTP, la base de données en mémoire (IMDB) nécessite une PersistanceEn effet, au plus tard lorsque l'ordinateur est éteint, les données de la base de données sont effacées. RAM disparu.

Couche de persistance et performance

Dans le cas d'une IMDB, l'accès aux données s'effectue principalement dans le cadre de l'utilisation de la base de données. RAM on pourrait s'attendre à ce que le stockage, en tant que couche de persistance, ne joue qu'un rôle mineur en termes de performance et serve en premier lieu à la protection, afin qu'aucune donnée ne soit perdue. Les exigences de la SAP à la performance des Persistance étaient et sont parfois plus élevés que pour les bases de données classiques. En général, on peut distinguer deux mécanismes d'écriture dans les bases de données - Logwriter et Datawriter. Le Logwriter documente en temps réel (synchrone) dans une zone spécifique chaque modification individuelle (insert, update, delete) effectuée dans la base de données. Le Datawriter actualise de temps en temps (de manière asynchrone) les modifications des tables dans le stockage et assure une image cohérente, mais généralement pas actuelle (car asynchrone) de la base de données. Le logwriter est critique pour le traitement des transactions et pour la récupération de la base de données, si celle-ci devait s'avérer nécessaire. Une transaction n'est considérée comme terminée que lorsque le logwriter a signalé qu'elle était documentée. Ce n'est qu'alors que le traitement peut être poursuivi. Cela garantit qu'après une interruption non planifiée de la base de données, le dernier état valable peut être rétabli en mettant à jour la dernière image de données cohérente avec les entrées de journal qui n'y ont pas encore été saisies (Roll Forward).

Logwriter & Datawriter

Dans les premières révisions de Hana le Logwriter était conçu pour écrire toutes les modifications en petits blocs dans la zone Log. En cas de modifications importantes dans la base de données, cela entraînait un nombre considérable d'opérations IO. C'est pourquoi, à l'époque, l'exigence de SAPque les Persistance devait être en mesure d'écrire au moins 100.000 IOps (opérations IO par seconde).

Cela n'est possible, à un coût raisonnable, qu'avec des Flash-(basés sur PCI). C'est pourquoi la plupart des installations mononoeuds de Hana avaient et ont toujours des systèmes basés sur PCIe. Flash-dispositifs de la gamme. Plus tard, le Hana a été étendue à une architecture ScaleOut pour le cas où l'extension maximale possible de la mémoire principale au sein d'un ordinateur ne suffisait plus à stocker entièrement une base de données plus importante.

Hana peut être réparti sur plusieurs nœuds d'ordinateurs avec cette option. Les ordinateurs peuvent être conçus de telle sorte qu'ils ne soient pas tous actifs, mais qu'un ou plusieurs nœuds soient également utilisés comme Basculement peuvent être configurés pour le cas où un nœud actif tombe en panne. Cela nécessite toutefois une Persistance qui peut être lu par tous les ordinateurs, car sinon un Basculement-Les nœuds ne peuvent pas lire les données d'un ordinateur en panne.

Le concept d'écriture très rapide des données log sur un périphérique local n'était donc plus viable. En conséquence, l'enregistreur de logs a été optimisé de manière à pouvoir écrire des blocs de taille variable. Ainsi, les taux d'E/S élevés n'étaient plus nécessaires. Dans un scénario ScaleOut, 20 000 IOps par nœud d'ordinateur étaient suffisants. Néanmoins, le SAP a maintenu les 100 000 IOps pour les nœuds uniques jusqu'à une date récente.

Outre le Logwriter, il existe également, comme nous l'avons déjà mentionné, le Datawriter. On pourrait d'abord penser qu'il n'est pas critique en termes de performances, puisqu'il écrit de manière asynchrone. En réalité, il écrit Hana à des intervalles de temps configurables - par défaut, cinq minutes - appelés points de sauvegarde. La performance du stockage doit être conçue de manière à ce que le volume modifié entre deux points de sauvegarde puisse être écrit dans l'intervalle de temps disponible, du moins en termes de débit.

Comme le Datawriter fonctionne selon le principe de la copie sur écriture, la charge d'écriture a tendance à être séquentielle, car les données modifiées ne sont pas enregistrées. Blocs ne sont pas écrasées, mais les modifications sont transférées dans des fichiers nouvellement alloués. Blocs peuvent être déposés. Cela simplifie les exigences en matière de PersistanceLa raison en est que l'IO séquentielle peut être réalisée de manière beaucoup plus efficace que l'IO aléatoire.

Comme l'architecture interne basée sur les colonnes de Hana est comparable à des bases de données indexées à cent pour cent, les résultats sont moins bons que ceux d'autres bases de données. Hana plus souvent des réorganisations internes, qui se répercutent ensuite sur les Persistance être représentés.

Les exigences du Datawriter en matière de débit d'écriture augmentent donc. En revanche, on devrait s'attendre à ce que les exigences en matière de débit d'E/S soient plutôt faibles lors de la lecture de données, car Hana données en fait dans le RAM devrait lire.

Cela peut être vrai pour le fonctionnement normal, mais pas pour le cas où Hana est démarré. Si l'on suppose que 1 To de données doit être lu dans la mémoire principale, cela prend tout de même 20 minutes avec un débit de 1 Go/sec. Cela ne serait pas un problème si les redémarrages de la base de données étaient l'exception.

Puisque Hana est en constante évolution dans le but d'utiliser un jour la NVRAM de manière optimale, des mises à jour doivent être effectuées à intervalles réguliers, souvent accompagnées d'un redémarrage de la base de données. C'est ce qui explique la demande de SAPqui Persistance de les doter également de débits élevés pour la lecture dans le domaine des données.

OLAP versus OLTP

Même si, comme nous l'avons mentionné plus haut, le domaine d'utilisation principal des IMDB a tendance à être le cinéma. OLAP se trouve, va SAP déjà le chemin, même OLTP-applications sur Hana (Suite on Hana). Techniquement, il est possible d'utiliser pour OLTP-Pour les systèmes de gestion de l'information, il est possible d'utiliser aussi bien des nœuds uniques que des architectures ScaleOut.

Du point de vue de la performance, il existe toutefois une différence significative. Comme nous l'avons déjà expliqué, pour OLTP-Les applications de la série C offrent un avantage de performance Hana Les problèmes de sécurité peuvent survenir lorsque des parties de code sont transférées dans la base de données afin d'éviter une communication chronophage entre l'application et la base de données.

Si Hana mais dans un environnement ScaleOut, il est très difficile de répartir le code et les tables de données entre les nœuds de manière à ce que les lignes de code trouvent leurs tables sur le même ordinateur que celui sur lequel elles sont exécutées. En effet, si le code doit aller chercher les données sur un nœud voisin, il y a à nouveau des frais de communication entre les nœuds, ce qui se produit avec une latence comparativement élevée, comme si le code était resté directement sur le serveur d'application.

Pour cette raison, une implémentation mononode de Hana pour OLTP est en tout cas préférable à une architecture ScaleOut.

En même temps, il y avait SAP jusqu'à présent pour Hana en tant que nœud unique, sur la demande de log devices (internes) rapides. Les périphériques de log internes sont toutefois nécessaires pour les applications critiques. Applications OLTP inacceptable, car la perte de l'ordinateur ou du dispositif de journalisation s'accompagne en même temps d'une perte de données.

Les données critiques pour l'entreprise, en particulier les données de log, devraient toujours être écrites (miroir) à un deuxième endroit, de sorte qu'en cas d'urgence, on puisse récupérer la base de données à partir d'une deuxième source jusqu'à la dernière transaction achevée.

Fujitsu a très tôt Hana-L'architecture single-node a été intégrée dans le concept d'exploitation FlexFrame et les données log ont été placées sur des unités de stockage externes pouvant être mises en miroir. Certes, les 100.000 IOps exigés jusqu'à présent ne sont pas disponibles, mais d'un point de vue technique, ils ne sont plus nécessaires depuis longtemps. Cela permet toutefois de garantir pour Hana le fonctionnement sûr et flexible connu de FlexFrame est garanti pour les applications critiques avec les SLA élevés qui les caractérisent.

Entre-temps, la SAP des exigences élevées en matière d'E/S pour le Logwriter, afin de Hana préparer pour une intégration flexible dans l'exploitation du centre de calcul.

Concept d'exploitation efficace et bases de données parallèles

L'exigence d'un stockage sécurisé des données et d'un concept d'exploitation efficace est satisfaite par l'intégration de Hana a été résolu dans FlexFrame. Avec un stockage partagé en miroir, la haute disponibilité est garantie tant au niveau local qu'à l'échelle du centre de calcul.

Un point en suspens est encore le problème des temps de redémarrage. En fonction de la taille de la base de données, un redémarrage complet peut prendre un temps excessivement long, même avec des canaux d'E/S très performants.

Dans le cadre du développement de Hana travaille SAP au concept de base de données fantôme qui, dans l'idéal, minimiserait les temps de commutation, étant donné que les bases de données fantôme fonctionnent généralement de manière presque synchrone avec les données primaires.

Après une panne de la base de données primaire, l'activation et la récupération complète de la base de données fantôme ne prendraient que quelques minutes avant que l'activité ne puisse reprendre.

Les bases de données parallèles sont en Hana n'est pas encore disponible aujourd'hui, mais comme étape préliminaire, il offre Hana l'option de réplication du système, qui veille à ce que les données de log soient répliquées de manière synchrone vers une deuxième instance et que, à intervalles réguliers, le columnstore (la structure des colonnes) de Hana est préchargé dans la mémoire principale et mis à jour.

Ainsi, dans le cas d'un Basculement le rechargement complet du Columnstore, puisque la plus grande partie est déjà préchargée. Cela permet de réduire les temps de redémarrage à un niveau raisonnable dans les environnements critiques.

La recommandation pour les applications qui n'autorisent qu'un temps d'arrêt minimal serait d'utiliser localement le système d'exploitation pour la production. Hana-Il est également possible d'exploiter une deuxième instance avec réplication du système et, en cas de catastrophe, d'utiliser l'instance de production. Persistance de faire un miroir dans un deuxième RZ.

Comme l'instance avec la réplication du système n'utilise qu'une petite partie des ressources de l'ordinateur, d'autres systèmes non productifs pourraient être exploités en parallèle sur le nœud de l'ordinateur.

ScaleOut

Il reste à discuter de la manière dont une architecture ScaleOut doit être évaluée par rapport à un nœud unique. En principe, tant pour OLTP que pour OLAPque, pour une même taille de base de données, le nœud unique, s'il est utilisé par les RAM-La solution la plus appropriée est d'utiliser les capacités de stockage de l'ordinateur.

Il y a essentiellement deux raisons à cela. La première a déjà été évoquée lors de la discussion en rapport avec OLTP est discutée. La communication entre les nœuds de la base de données prend comparativement beaucoup de temps et a une influence négative sur les performances.

Spécialement pour Applications OLAP le problème de l'association habile des lignes de code aux données n'est pas aussi pertinent que pour les OLTPEn effet, la structure mathématique des requêtes permet en général de les traiter de manière bien répartie. Il n'en reste pas moins que le problème de la latence demeure, car les résultats partiels d'une requête doivent finalement être réunis sur un nœud et consolidés en un résultat final.

Un deuxième problème se pose par exemple pour les jointures qui passent par des tables réparties sur plusieurs nœuds. Avant que la jointure puisse être exécutée, les données des tables concernées doivent être transférées et stockées temporairement sur le nœud sur lequel la jointure est exécutée. Cela prend d'une part du temps et d'autre part de la mémoire principale supplémentaire.

Dans le cas d'un nœud unique, la transmission des données et le stockage intermédiaire ne sont pas nécessaires, puisque toutes les données sont locales. Il est donc recommandé d'utiliser le plus longtemps possible une instance à nœud unique pour les applications.

Les développements actuels en matière de technologie matérielle vont dans le sens de cette approche. Avec le matériel officiellement disponible en février 2014, il sera possible de stocker jusqu'à 12 TB RAM dans une machine.

SAP fait savoir qu'avec le nouveau matériel, elle prendra en charge jusqu'à 6 To sur un ordinateur pour les applications OLTP dans les systèmes de production, et qu'elle sera en mesure de prendre en charge jusqu'à 6 To sur un ordinateur pour les applications OLTP dans les systèmes de production. OLAP jusqu'à 2 To pour huit sockets équipés, contre 1 To par le passé.

Cela semble plausible, car la puissance du processeur de la nouvelle génération de processeurs a environ doublé. Toutefois, la performance des Hana–Technologie Ces dernières années, la technologie s'est constamment et significativement améliorée, ce qui permet d'envisager l'avenir avec plus de confiance. RAM-Il est possible d'imaginer une extension de la capacité de stockage de 2 To pour un nœud dans une architecture ScaleOut.