In-Memory est un ensemble de concepts permettant de stocker des données lorsqu'elles sont stockées dans la RAM de l'application et que le disque est utilisé pour la sauvegarde. Dans les approches classiques, les données sont stockées sur disque et la mémoire est stockée dans le cache. Par exemple, une application Web dotée d'un backend pour traiter les données les demande en stockage : elle les reçoit, les transforme et de nombreuses données sont transférées sur le réseau. En In-Memory, les calculs sont envoyés aux données - vers le stockage, où ils sont traités et le réseau est moins chargé.
Quelles autres possibilités sont disponibles avec In-Memory et de quel type d'approche il s'agit ? Vladimir Pligine - ingénieur chez GridGain. Ce matériel de révision sera utile aux développeurs backend d'applications Web qui n'ont pas travaillé avec In-Memory et souhaitent essayer, ou sont intéressés par les tendances modernes en matière de développement de logiciels et de conception d'architecture.
Noter. L’article est basé sur la transcription du rapport de Vladimir lors de la #GetIT Conf. Avant l'introduction de l'auto-isolement, nous organisions régulièrement des rencontres et des conférences pour les développeurs à Moscou et à Saint-Pétersbourg : nous discutions des tendances, des problèmes de développement actuels, des problèmes et de leurs solutions. Il n’est pas possible d’organiser une conférence maintenant, mais il est temps de partager des documents utiles issus des conférences passées.
Qui utilise In-Memory et comment
L'In-Memory est le plus souvent utilisé lorsqu'une interaction rapide de l'utilisateur ou le traitement de grandes quantités de données sont requis.
- Banques utilisez In-Memory, par exemple, pour réduire les délais lorsque les clients utilisent des applications ou pour analyser le client avant d'accorder un prêt.
- Fintech utilise In-Memory pour améliorer les performances des services et des applications pour les banques qui externalisent le traitement et l'analyse des données.
- Les compagnies d'assurance: pour calculer les risques, par exemple, en analysant les données clients sur plusieurs années.
- Entreprises de logistique. Ils traitent par exemple de nombreuses données pour calculer les itinéraires optimaux pour le transport de marchandises et de passagers avec des milliers de paramètres et suivre l'état des expéditions.
- Vente au détail. Les solutions In-Memory permettent de servir les clients plus rapidement et de traiter de gros volumes d'informations : expéditions, factures, transactions, présence de milliers de marchandises dans les entrepôts et de préparer des rapports analytiques.
- В IdO In-Memory remplace les bases de données traditionnelles.
- Pharmaceutique les entreprises utilisent In-Memory, par exemple, pour trier les combinaisons de compositions médicamenteuses.
Je vais vous donner quelques exemples de la façon dont nos clients utilisent les solutions In-Memory et comment vous pouvez les mettre en œuvre vous-même.
In-Memory comme stockage principal
L'un de nos clients est un important fournisseur d'équipements scientifiques médicaux en provenance des États-Unis. Ils utilisent une solution In-Memory comme principal stockage de données. Toutes les données sont stockées sur le disque et le sous-ensemble de données activement utilisé est conservé dans la RAM. Les méthodes d'accès au stockage sont standard - GDBC (Generic Database Connector) et langage de requête SQL.
Collectivement, cela s'appelle In-Memory Database (IMDB) ou Memory-Centric Storage. Cette classe de solutions porte de nombreux noms, ce ne sont pas les seuls.
Caractéristiques de la BDIM :
- Les données stockées en mémoire et accessibles via SQL sont les mêmes que dans les autres approches. Ils sont synchronisés, seule la manière de les présenter, la manière de les aborder est différente. La transactionnalité fonctionne entre les données.
- IMDB est plus rapide que les bases de données relationnelles car il est plus rapide de récupérer des informations depuis la RAM que depuis le disque.
- Les algorithmes d'optimisation internes ont moins d'instructions.
- Les IMDB conviennent à la gestion des données, des événements et des transactions dans les applications.
Les IMDB prennent partiellement en charge ACID : atomicité, cohérence et isolation. Mais ils ne prennent pas en charge la « durabilité » : lorsque l'alimentation est coupée, toutes les données sont perdues. Pour résoudre le problème, vous pouvez utiliser des instantanés - un «instantané» de la base de données, analogue à une sauvegarde de base de données sur un disque dur, ou enregistrer des transactions (journaux) pour restaurer les données après un redémarrage.
Pour créer des applications tolérantes aux pannes
Imaginons l'architecture classique d'une application Web tolérante aux pannes. Cela fonctionne comme ceci : toutes les requêtes sont distribuées par un équilibreur Web entre les serveurs. Ce système est stable car les serveurs se dupliquent et sauvegardent en cas d'incident.
L'équilibreur dirige toutes les requêtes d'une session strictement vers un seul serveur. Il s'agit d'un mécanisme de session stick : chaque session est associée à un serveur où elle est stockée et traitée localement.
Que se passe-t-il en cas de panne d'un des serveurs ?
Le service ne sera pas affecté car l'architecture est dupliquée. Mais nous perdrons un sous-ensemble des sessions du serveur mort. Et en même temps, les utilisateurs liés à ces sessions. Par exemple, un client passe une commande et le jette soudainement hors du bureau. Il sera mécontent lorsqu'il se reconnectera et constatera que tout devra être refait.
Une application Web doit prendre en charge un grand nombre d’utilisateurs et ne pas ralentir afin qu’ils puissent travailler confortablement. Mais s'il est refusé, à chaque requête ultérieure, le temps nécessaire pour communiquer avec le magasin de sessions augmentera. Cela augmente la latence moyenne pour les autres utilisateurs. Mais ils ne veulent pas attendre plus longtemps qu’ils en ont l’habitude.
Ce problème peut être résolu comme notre autre client, un grand fournisseur de PASS des États-Unis. Il utilise In-Memory pour regrouper les sessions Web. Pour ce faire, il ne les stocke pas localement, mais de manière centralisée - dans un cluster In-Memory. Dans ce cas, les sessions sont disponibles beaucoup plus rapidement car elles sont déjà en RAM.
Lorsqu'un serveur tombe en panne, l'équilibreur envoie des requêtes du serveur en panne vers d'autres serveurs, comme dans l'architecture classique. Mais il y a une différence importante : les sessions sont stockées dans un cluster In-Memory et les serveurs ont accès aux sessions du serveur tombé.
Cette architecture augmente la tolérance aux pannes de l'ensemble du système. De plus, il est possible d’abandonner complètement le mécanisme de session stick.
Traitement analytique transactionnel hybride (HTAP)
En règle générale, les systèmes transactionnels et analytiques sont séparés. Lorsqu'ils se séparent, la base principale est soumise à une charge. Pour le traitement analytique, les données sont copiées sur une réplique afin que le traitement analytique n'interfère pas avec les processus transactionnels. Mais la copie s’effectue avec un décalage : il est impossible de répliquer sans décalage. Si nous faisons cela de manière synchrone, cela ralentira également la base principale et nous n'obtiendrons aucun gain.
Dans HTAP, tout fonctionne différemment : le même magasin de données est utilisé pour la charge transactionnelle des applications et pour les requêtes analytiques dont l'exécution peut prendre beaucoup de temps. Lorsque les données sont en RAM, les requêtes analytiques sont exécutées plus rapidement et le serveur avec la base de données est moins chargé (en moyenne).
Une approche hybride fait tomber le mur entre le traitement des transactions et l’analyse. Si nous effectuons des analyses sur le même stockage, alors des requêtes analytiques sont lancées sur les données de la RAM. Ils sont beaucoup plus précis, plus interprétables et adéquats.
Intégration de solutions In-Memory
Un moyen (relativement) simple - tout développer à partir de zéro. Nous conservons les données sur disque et stockons les données chaudes en mémoire. Cela aide à survivre aux redémarrages ou aux pannes du serveur.
Deux scénarios principaux sont à l'œuvre ici lorsque les données sont stockées sur disque. Dans le premier cas, nous voulons survivre aux pannes ou aux redémarrages réguliers du cluster ou des parties - nous voulons l'utiliser comme une simple base de données. Dans le deuxième scénario, lorsqu’il y a trop de données, certaines d’entre elles sont en mémoire.
S'il n'est pas possible de tout construire à partir de zéro, il est possible d'intégrer In-Memory dans un système déjà existant. architecture existante. Mais toutes les solutions In-Memory ne sont pas adaptées à cela. Il y a trois conditions obligatoires. La solution In-Memory doit prendre en charge :
- moyen standard de se connecter à la base de données qui se trouvera en dessous (par exemple, MySQL) ;
- un langage de requête standard, afin de ne pas réécrire et modifier la logique d'interaction avec le stockage ;
- transactionnel - préserver la sémantique de l'interaction.
Si les trois conditions sont remplies, l’intégration est alors possible. Nous plaçons la grille de données en mémoire entre l'application et la base de données. Désormais, les demandes d'écriture seront déléguées à la base de données sous-jacente, et les demandes de lecture seront déléguées à la base de données sous-jacente si les données ne sont pas dans le cache.
Si un accès rapide aux données et à leur traitement est important pour vous, par exemple pour l'analyse commerciale, vous pouvez penser à implémenter In-Memory. Et pour la mise en œuvre, vous pouvez utiliser les deux méthodes lors de la conception d’une nouvelle architecture.
Source: habr.com