FR3103299A1

FR3103299A1 - Système informatique distribué pour délivrer des données

Info

Publication number: FR3103299A1
Application number: FR1912922A
Authority: FR
Inventors: Didier Spezia; Simon HUET; Damien PROFETA; Xavier BOURGOUIN
Original assignee: Amadeus SAS
Current assignee: Amadeus SAS
Priority date: 2019-11-20
Filing date: 2019-11-20
Publication date: 2021-05-21
Anticipated expiration: 2039-11-20
Also published as: US11663209B2; US20210149902A1; FR3103299B1; EP3825863A1

Abstract

Un système informatique distribué pour délivrer des données à une application(s) côté client est fourni. Le système inclut une base de données configurée pour stocker des blocs de données immuables, une entité de distribution de données configurée pour diviser les données-sources en blocs de données immuables et en métadonnées. L’entité de distribution de données est configurée pour répliquer et stocker les blocs de données dans des nœud(s) de stockage différents de la base de données. Les métadonnées comprennent des valeurs faisant référence aux blocs de données pour un appel de base de données de valeurs-clés. Le système comprend par ailleurs une entité de récupération/livraison de données avec un démon-fusible configuré pour former une requête de lecture de quorum pour un bloc(s) de données en dehors d’une requête côté client pour une certaine plage de données. La requête de lecture de quorum est un assemblage de requêtes parallèles aux divers nœuds de stockage. Le démon-fusible est configuré pour récupérer les blocs de données délivrés dans la réponse la plus rapide et pour rejeter le reste. Le démon-fusible génère un fichier virtuel comprenant la plage de données correspondant à partir des blocs de données récupérés.

Description

Système informatique distribué pour délivrer des données

Domaine de l’invention

La présente invention concerne de façon générale un système de stockage de données distribué, en particulier un système de stockage de données distribué pour des données pour un accès en lecture important qui sont rarement modifiées. Le système de stockage de données distribué doit délivrer des plages de données à des applications côté client distantes du réseau de stockage de données.

Contexte

EP1 364 510 porte sur un procédé de gestion de stockage efficace dans un réseau distribué ayant une pluralité de nœuds connectés comprenant les étapes de: détermination lorsqu’un certain paramètre de stockage de fichiers excède un seuil d’élagage ; et mise en œuvre d’un cycle d’élagage incluant: (a) l’identification des composants de contenu associés au stockage ; (b) l’élagage sélectif des composants de contenu basée au moins en partie sur des statistiques d’usage de sorte que le paramètre de stockage du fichier est ramené en dessous du seuil d’élagage ; et (c) mettre à jour les métadonnées associées aux composants de contenu pour refléter les paramètres de système de stockage mis à jour et comprenant par ailleurs (d) la présentation des contenus du réseau de stockage actualisé comme système de fichiers virtuels de sorte que les fichiers apparaissent accessibles localement à un nœud quelconque.

Selon un premier aspect, un système informatique distribué pour délivrer des données à au moins une application côté client est fourni. Le système informatique distribué comprend une base de données configurée pour stocker des blocs de données immuables, une entité de distribution de données configurée pour diviser les données-sources en blocs de données immuables et en métadonnées, dans lequel l’entité de distribution de données est configurée pour répliquer et stocker les blocs de données immuables sur au moins deux nœud(s) de stockage différents de la base de données, dans lequel les métadonnées comprennent des valeurs faisant référence aux blocs de données immuables dans lesdits au moins deux nœuds de stockage pour un appel de base de données de valeurs-clés. Le système informatique distribué comprend par ailleurs une entité de récupération et de livraison de données comprenant un démon-fusible configuré pour convertir une requête, pour une plage de données d’un fichier déclenchée par au moins une application côté client en un appel de lecture de quorum pour au moins un bloc de données immuable à la base de données, dans lequel la requête de lecture de quorum comprend une pluralité de requêtes parallèles individuelles à différents nœuds de stockage stockant le même bloc de données immuable, dans lequel le démon-fusible est configuré pour récupérer les blocs de données délivrés par la base de données dans la réponse la plus rapide et est configuré pour rejeter des résultats délivrés subséquemment à la réponse la plus rapide, dans lequel le démon-fusible est configuré pour générer un fichier virtuel comprenant la plage de données correspondant à partir des blocs de données récupérés,

Selon un deuxième aspect, un procédé de livraison de données à au moins une application côté client est fourni. Le procédé est exécutable sur le système informatique distribué selon le premier aspect le procédé comprenant: la division des données-sources en blocs de données immuables et en métadonnées, la réplication et le stockage desdits blocs de données sur au moins deux nœuds de stockage différents d’une base de données, dans lequel les métadonnées comprennent des valeurs faisant référence aux blocs de données immuables dans lesdits au moins deux nœuds de stockage pour un appel de base de données de valeurs-clés, la conversion d’une requête, pour une plage de données d’un fichier déclenchée par au moins une application côté client en un appel de lecture de quorum pour au moins un bloc de données immuable à la base de données, dans lequel la requête de lecture de quorum comprend une pluralité de requêtes parallèles individuelles à différents nœuds de stockage stockant le même bloc de données immuable, la récupération des blocs de données délivrés par la base de données dans la réponse la plus rapide et le rejet des résultats délivrés subséquemment à la réponse la plus rapide, la génération d’un fichier virtuel comprenant la plage de données correspondant à partir des blocs de données récupérés.

Toujours selon un troisième aspect, un produit programme d’ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en œuvre les étapes du procédé selon le deuxième aspect lorsque ledit programme fonctionne sur un ordinateur, est fourni.
Description générale, aussi d’exemples supplémentaires

Un système informatique distribué pour délivrer des données à au moins une application(s) côté client est fourni. Le système informatique est distribué de sorte que les données requises par l’application côté client sont stockées dans une base de données qui est située à distance de l’application(s) côté client et est connectée à ces applications sur un réseau informatique. Les applications côté client sont par exemple des applications de réservations de vol interrogeant des listes aéroportuaires ou similaires. Ces applications peuvent faire fonctionner leurs dorsaux sur des serveurs d’application particuliers. Le système informatique distribué peut fournir des données rapides, fiables et échelonnables qui peuvent être les mêmes pour des milliers de serveurs et ne changent pas trop souvent, c.-à-d. qu’elles restent constantes pour au moins des milliers de requêtes en lecture. Dans ce sens, le système informatique distribué comprend un système de fichiers distribué orienté lecture.

Le système informatique distribué comprend une base de données pour stocker des blocs de données immuables. Les blocs de données peuvent contenir par exemple des portions des données demandées par l’application côté client, telles que des portions de listes aéroportuaires de programmation d’horaires d’arrivée/départ pour une compagnie aérienne. Les blocs de données sont immuables dans le sens où la seule façon de changer les données contenues par le bloc(s) de données est de remplacer le bloc(s) de données dans son intégralité.

Le système informatique distribué comprend par ailleurs une entité de distribution de données configurée pour diviser les données-sources en blocs de données immuables et en métadonnées. L’entité de distribution de données peut inclure un boîtier de distribution (distribox) pour diviser les données d’un fichier en blocs de données et un stockage de fichiers persistant couplé à un distribox dorsal dans lequel les fichiers de données qui doivent être divisés en blocs de données immuables et en métadonnées sont stockés.

L’entité de distribution de données est configurée pour répliquer les blocs de données immuables et pour stocker les blocs de données immuables sur au moins deux nœuds de stockage différents de la base de données. Ainsi, si des données-sources sous la forme d’un fichier de données sont divisées en cinq blocs de données immuables, ces cinq blocs peuvent être distribués sur cinq nœuds de stockage différents. Cependant, par exemple, deux copies de ces blocs pourraient être stockées en tout sur dix nœuds de stockage supplémentaires de la base de données. Le système de fichiers qui est utilisé sur la base de données peut être un système de fichiers basé sur Redis.

Les métadonnées comprennent des valeurs faisant référence aux blocs de données immuables dans lesdits au moins deux nœuds de stockage pour un appel de base de données de valeurs-clés. Les valeurs faisant référence aux blocs de données immuables peuvent être un ensemble d’identifiants uniques pour certains blocs de données. Ces identifiants pourraient être créés à partir d’un nombre de blocs de données immuables, une valeur dérivée du contenu du bloc de données ou similaire. Dans ce sens, l’appel de base de données de valeurs-clés est, par exemple, un appel de base de données pour un bloc de données immuable correspondant à l’identifiant utilisé dans la requête d’appel de base de données. Les métadonnées pourraient par ailleurs comprendre des informations concernant le type de fichier des blocs de données afin de distinguer entre des fichiers amicaux de déduplication (p. ex. SQLite) et d’autres.

Le système informatique distribué comprend par ailleurs une entité de récupération et de livraison de données. Le but de l’entité de récupération et de livraison de données est, par exemple, de récupérer les blocs de données immuables stockés sur la base de données et de délivrer les données extraites de ces blocs de données immuables à l’application(s) côté client. Les données extraites pourraient correspondre à la plage de données d’un fichier demandé par l’application côté client.

L’entité de récupération et de livraison de données comprend un démon-fusible pour convertir une requête pour une plage de données d’un fichier déclenchée par au moins une application côté client en un appel de lecture de quorum pour au moins un bloc de données immuable à la base de données. Le démon-fusible est, par exemple, une sous-routine d’un système d’exploitation ou pourrait être une sous-routine d’un système de fichiers FUSE. Le démon-fusible convertit la requête pour une plage de données d’un fichier en requêtes pour des blocs de données immuables.

Le démon-fusible, utilise par exemple les valeurs faisant référence aux blocs de données compris par les métadonnées et un mappage d’informations de plage à bloquer pour formuler les requêtes pour un certain bloc de donnée immuable, ou une règle de calcul afin de convertir la requête pour une plage de données d’un fichier en une requête pour des blocs de données immuables particuliers comprenant cette plage afin de récupérer les blocs corrects de données immuables.

Les requêtes individuelles pour des blocs de données immuables correspondant à la plage de données d’un fichier demandé sont rattachées à la requête de lecture de quorum de la façon suivante:

La requête de lecture de quorum comprend une pluralité de requêtes parallèles individuelles à différents nœuds de stockage stockant le même bloc de données immuable. Ainsi que mentionné ci-dessus, les copies de blocs de données immuables sont stockées sur une pluralité de nœuds de stockage différents de façon redondante. Les requêtes parallèles sont dirigées vers ces nœuds de stockage différents.

Une caractéristique des blocs immuables est qu’ils ne sont pas redondants, car aucun bloc immuable ne peut jamais différer d’un bloc immuable différent de la même version de fichier. Comme ils sont redondants, une lecture de quorum donnera le même résultat exact pour chacune des interrogations parallèles de la lecture de quorum, de sorte qu’une sélection basée sur la réponse la plus rapide est possible.

Pour fournir un exemple, si le fichier à 5000 octets et que le bloc a une longueur de 1000 octets, il y aura 5 blocs. Et lorsque l’interface d’application côté client de l’application demandera à lire les données des décalages 500 à 1500, le démon-fusible effectuera une lecture de quorum deux fois, une fois pour le bloc0-1000 et une fois pour le bloc1000-2000. Les autres blocs ne seront pas récupérés. Si par la suite l’interface application demande les autres octets1500-2000, elle sera servie à partir d’une antémémoire dans laquelle les blocs de données immuables sont stockés, p. ex. une page d’antémémoire. Si cependant les octets4000-4500 sont demandés, une autre lecture de quorum sera émise par le démon-fusible.

Le démon-fusible est configuré pour récupérer les blocs de données délivrés par la base de données dans la réponse la plus rapide et il est configuré pour rejeter des résultats délivrés subséquemment à la réponse la plus rapide. Pour certaines raisons, par exemple la latence ou la charge de travail, un des nœuds de stockage pourrait être capable de répondre plus vite que les autres. Néanmoins, tous les nœuds de stockage vers lesquels une requête est dirigée traiteront les requêtes de la lecture de quorum et délivreront des résultats. Cependant, seulement les résultats les plus rapides (= les blocs de données immuables demandés) seront récupérés par le démon-fusible et délivrés, par exemple, à un répertoire de données de l’entité de récupération et de livraison de données situé à proximité de l’application(s) cliente. Dans certains exemples, lors de la réception de la réponse la plus rapide, le démon-fusible pourrait ordonner les nœuds de stockage de la base de données pour annuler le traitement des requêtes qui n’ont pas encore été servies

Le démon-fusible est configuré pour générer un fichier virtuel comprenant la plage de données correspondant à partir des blocs de données récupérés. Le fichier virtuel est, par exemple, un fichier qui est situé à proximité de l’application cliente pour permettre une récupération rapide des données stockées dans ledit fichier virtuel à l’application côté client. Le fichier virtuel pourrait stocker uniquement les données contenues dans les blocs de données immuables qui correspondent à la plage demandée et pourrait rejeter le reste. La requête pour une plage de données d’un fichier recevra ensuite une réponse de l’entité de récupération et de livraison au moyen des données stockées dans le fichier virtuel qui correspondent à la plage de données demandées. Le fichier est désigné comme étant un fichier virtuel, car l’application cliente ne peut pas distinguer les données délivrées par le fichier virtuel des données délivrées par une base de données distante. Ainsi les modes de structure et d’accès au fichier auquel la plage de données est demandé sont libres et sous la responsabilité de l’application(s) cliente au lieu que les modes d’accès soient gérés par la base de données.

Dans certains exemples, l’entité de récupération et de livraison de données comprend un système d’exploitation ayant une page d’antémémoire de système d’exploitation dans lequel la page d’antémémoire du système d’exploitation est configurée pour stocker au moins les parties des blocs de données récupérés qui correspondent à la plage de données d’un fichier demandé par l’application côté client.

Le système d’exploitation est, par exemple, un système d’exploitation prenant en charge POSIX, tel qu’un système d’exploitation UNIX. La page d’antémémoire dudit système d’exploitation est, par exemple, une antémémoire d’un noyau UNIX, p. ex. LINUX. Cette page d’antémémoire peut être implémentée sur un nœud Openshift qui est en communication avec l’application(s) côté client comme point de livraison (POD). Le démon-fusible peut être configuré pour garder les blocs de données récupérés dans la page d’antémémoire aussi longtemps que possible, donc jusqu’à ce que le fichier et avec lui — les blocs de données — aient changé. Lorsque plus de blocs de données à jour sont disponibles, le nouveau bloc de données peut être récupéré et poussé vers la page d’antémémoire par le démon-fusible. Soit tous les blocs de données immuables récupérés contenant la plage demandée d’un fichier sont stockés dans la page antémémoire, ou seulement un contenu de données extrait du bloc de données qui correspond exactement aà ladite plage demandée.

Dans certains exemples, les données dans le fichier virtuel sont récupérables par ladite au moins une application côté client comme réponse à la requête pour une plage de données d’un fichier et comme réponse à une quelconque requête future pour la même plage de données d’un fichier. Par conséquent, la plage de données demandé est livrable directement lorsque la requête pour lesdites données est répétée. Ceci économise les ressources computationnelles nécessaires à une nouvelle interrogation (lecture de quorum) à la base de données si les données sont déjà disponibles dans la page d’antémémoire côté client.

Dans certains exemples, la base de données comprenant les nœuds de stockage est une base de données NoSQL. Une base de données NoSQL est une base de données qui ne peut pas être servie par les commandes d’appel SQL et qui, par exemple, n’est pas du tout une base de données relationnelle. Une telle base de données NoSQL pourrait être une base de données avec un mécanisme d’ajout uniquement, donc une base de données pour laquelle il est impossible d’insérer une entrée entre 2 entrées existantes préalablement dans une liste, mais de nouvelles entrées doivent être ajoutées à cette liste après les entrées existantes précédentes. La base de données peut être un groupe Redis optimisé pour des opérations de lecture importante/écriture faible avec une disponibilité de données élevées.

Dans certains exemples, les valeurs comprises par les métadonnées font référence à des valeurs faisant référence aux blocs de données immuables pour un appel de base de données de valeurs-clés, ces valeurs de référence étant générées à travers des valeurs de hachage de chaque bloc de données correspondant.

Pour fournir un exemple, chaque bloc de données immuables est haché et la valeur de hachage résultante est utilisée comme une clé pour ce bloc de données immuable et une référence est faite dans les métadonnées qui sont par exemple des métadonnées de fichiers. En tant que tel, il peut y avoir de vrais enregistrements dans le fichier de métadonnée concernant les blocs de données immuables compris par le fichier pour lequel la plage est demandée. Ces enregistrements peuvent inclure des informations indiquant quelle valeur de hachage, correspondant à ladite valeur-clé dans l’appel de base de données de valeurs-clés correspond à quel bloc de donnée immuable du fichier. Ainsi que mentionné ci-dessus, chaque bloc de donnée immuable référencé est répliqué à au moins trois nœuds. Par exemple, ces blocs de données immuables contenant des données comprises dans la plage demandée de données sont récupérés, ceux qui ne contiennent pas de données à l’intérieur de cette plage ne sont pas récupérés.

Cependant dans certains exemples, la base de données est configurée pour délivrer des données correspondant au fichier incluant des données d’un bloc de données en dehors de la plage demandée du fichier. À ce titre, par exemple, les blocs de données adjacents à ou dans une certaine portée autour du bloc de données contenant des données à l’intérieur de la plage demandée sont aussi récupérés. Par ailleurs, tous les blocs de données immuables d’un fichier pourraient simplement être récupérés.

Dans certains exemples, le fichier virtuel comprend, en plus de la plage de données demandé, les métadonnées de blocs de données correspondant aux données en dehors de la plage demandée du fichier. En général, à titre d’exemple, les métadonnées peuvent être délivrées par la base de données à la base de données de récupération et de livraison de données à la demande pour la plage de données d’un fichier ou avant une requête pour la plage de données d’un fichier.

Par conséquent dans certains exemples le démon-fusible est configuré pour générer le fichier virtuel comprenant les métadonnées. Les métadonnées pourraient être stockées dans le fichier virtuel sur l’entité de récupération et de livraison des données où les métadonnées pourraient être utilisées en formulant une interrogation pour (i) la structure de donnée du fichier et/ou (ii) certains blocs de données immuables compris dans le fichier par la lecture de quorum.

Dans certains exemples, le démon-fusible est configuré pour effectuer l’interrogation pour l’opération de lecture de quorum au moins trois fois en parallèle et dans lequel les mêmes blocs de données sont stockés au moins trois fois sur au moins trois nœuds de stockage de base de données différents. Dans ce cas, le nombre d’interrogations effectuées dans la lecture de quorum correspond au nombre de nœuds sur lesquels des copies des blocs de données immuables sont stockées. Chacune des trois interrogations sera ensuite, par exemple, dirigée vers un nœud de stockage différent parmi ces trois. Dans cet exemple, pas plus de copies sont stockées que d’interrogations devant être effectuées, limitant la capacité de stockage utilisée au volume minimum nécessaire pour traiter chaque interrogation en concurrence les unes avec les autres.

Dans certains exemples, le démon-fusible est configuré pour effectuer l’interrogation pour l’opération de lecture de quorum trois fois en parallèle et dans lequel les mêmes blocs de données sont stockés cinq fois sur au moins cinq nœuds de stockage de base de données différents. Dans cet exemple, les blocs de données immuables sont répliqués sur plus de nœuds de stockage qu’il n’est actuellement nécessaire pour traiter les trois interrogations de la lecture de quorum. Cependant, ceux-ci augmentent la disponibilité des données, car même si deux nœuds de stockage échouent, il y a toujours suffisamment de nœuds de stockage fonctionnels pour réaliser l’opération de lecture de quorum avec succès. Par ailleurs, le nombre d’interrogations dans une opération de lecture de quorum pourrait être augmenté avec flexibilité à cinq interrogations lors du stockage de cinq copies de blocs de données immuables sur cinq nœuds de stockage.

Dans certains exemples au moins deux applications côté client utilisent une bibliothèque cliente d’intergiciels (middleware) commune pour accéder au fichier virtuel. Les intergiciels pourraient être définis, par exemple, comme une couche de logiciels qui se situe entre le système d’exploitation et les applications de chaque côté d’un système informatique distribué dans un réseau. La fourniture d’une bibliothèque cliente d’intergiciels commune pour accéder au fichier virtuel économise des ressources dans la communication entre le fichier virtuel et les applications côté client. Cette communication pourrait se faire sur des interfaces dédiées.

Dans certains exemples, l’entité de récupération et de livraison de données comprend une interface de fichiers compatible à au moins un système d’exploitation portable, l’interface de fichier étant une interface à au moins une partie dorsale d’une application cliente et l’interface de fichier prenant en charge un accès séquentiel et à lecture aléatoire. Cette interface de fichier pourrait être utilisée pour mettre en œuvre la communication sur la bibliothèque cliente d’intergiciels. Dans certains exemples, le système d’exploitation de l’entité de récupération et de livraison de données est un système d’exploitation basé sur UNIX.

Dans certains exemples, ainsi que mentionné ci-dessus, le démon-fusible est configuré pour sélectionner et pour récupérer des blocs de données basés sur la plage de données du fichier en sélectionnant et en récupérant ces blocs de données immuables qui contiennent des données à l’intérieur de la plage de données demandé.

Dans certains exemples, avant que la requête de lecture de quorum pour au moins un bloc de données immuable soit émise par l’entité de récupération et de livraison des données, une requête de l’application cliente au démon-fusible comprenant le nom du fichier de données est émise lorsqu’une requête pour ouvrir le fichier de données est émise par l’application cliente. Par conséquent, l’application cliente sait à partir de quel fichier et quelles données elle veut récupérer. Par exemple, elle émet donc une requête de fichier-ouvert à la base de données via le démon-fusible dans laquelle la requête de fichier-ouvert contient ledit nom de fichier du fichier de données demandé.

Dans certains exemples, le démon-fusible est par ailleurs configuré pour récupérer des métadonnées du fichier qui comprennent la liste des blocs avec leurs valeurs de hachage, la taille du fichier et la taille du bloc, et doit stocker les métadonnées sur l’entité de récupération et de livraison des données, dans lequel les métadonnées sont récupérées lorsqu’une requête pour ouvrir le fichier de données effectuée par l’application cliente est émise.

Les métadonnées stockées par exemple dans le fichier virtuel sur l’entité de récupération et de livraison des données sera donc compris, par exemple, d’au moins trois valeurs suivantes: (i) la taille du fichier en octets ; (ii) la taille d’un unique bloc de donnée immuable en octets ; (iii) une liste des blocs avec leurs valeurs de hachage correspondantes. Cette information dans les métadonnées est ensuite utilisée pour calculer quels blocs de donnée immuables doivent être demandés par le démon-fusible/l’entité de récupération et de livraison des données pour couvrir la portée du fichier.

Dans certains exemples, le démon-fusible doit convertir la requête pour une plage de données d’un fichier en requête de lecture de quorum en utilisant l’information contenue dans les métadonnées, la conversion comprenant un calcul qui implique la taille du fichier, la taille du bloc et la plage demandée, en utilisant une règle de calcul également obtenue à partir des métadonnées du fichier. La règle de calcul est donc, par exemple, également obtenue lors de la récupération des métadonnées du fichier.

Par exemple, la taille du bloc de données immuable pourrait varier en fonction de la taille globale du fichier. Pour une taille de fichier global plus large/plus petite en octets, les blocs de données immuables avec une taille en octets plus large/plus petite pourrait être compris par le fichier.

Dans ce qui va suivre, un exemple montrant comment déterminer quels blocs de donnée immuables doivent être récupérés pour obtenir la plage de données demandé du fichier en utilisant la règle de calcul stockée dans les métadonnées est présenté:

S’il existe une requête de lecture avec une compensation voulue dans le fichier X et une plage de données demandé de longueur L, la taille du bloc étant connue, l’entité de récupération calculera ensuite le premier bloc de données immuable devant être récupéré et le nombre de blocs devant être récupéré par: bloc
et ,
où l’opérateur « / » indique une division de nombre entier.

Elle récupérera ensuite le bloc immuable de le dernier bloc étant le dernier bloc contenant des données à l’intérieur de la plage demandée et la taille fichier étant la taille globale du fichier, en récupérant l’élément de nombre correct (valeur de hachage) dans la liste des blocs immuables et les valeurs de hachage/valeurs-clé correspondantes.

Le calcul pour déterminer quels blocs doivent être récupérés est effectué par le démon-fusible, par exemple au cours de la requête d’application pour lire le fichier ou pour récupérer les blocs de données immuables.

Dans certains exemples, au moins deux versions, préférablement trois versions du fichier de données divisé en blocs de données immuables sont conservées dans un stockage du système informatique distribué qui est capable de délivrer la version du fichier de données à l’entité de distribution de données.

Le but de conserver au moins deux versions, préférablement trois versions du fichier est un critère pour avoir une collecte régulière de déchets qui retirera les données qui ne sont plus nécessaires. Un autre critère pour ceci peut être par exemple de ne pas retirer un fichier qui est toujours utilisé par quelqu’un. Une option pour assurer ceci est par exemple de demander au client de s’enregistrer comme un utilisateur du fichier pour un certain temps ce qui est désigné par la suite comme étant une location. En raison de la possibilité d’une panne de réseau ou d’une panne de partition, la location peut ne pas être illimitée parce qu’autrement un nœud mort pourrait empêcher la suppression des données pour toujours.

Par exemple, chaque fois qu’un client ouvre un fichier il devra d’abord établir une location du fichier et devra nettoyer la location ou rétablir la location lorsque c’est nécessaire. Ensuite lorsque le démon collecteur de déchets par exemple scannera le fichier pour le purger il vérifiera s’il existe une location sur le fichier ou non. Ceci est par exemple implémenté en plaçant un élément (nom de fichier: p. ex. TTL) avec l’heure d’expiration. Si beaucoup de clients ouvrent le fichier, ils écriront au même élément. Si cet élément expire, cela signifie que plus personne n’a besoin du fichier et l’élément peut être supprimé.

Dans certains exemples, le procédé étant exécutable sur le système informatique distribué ainsi que décrit ci-dessus, le procédé comprenant:

la division des données-sources en blocs de données immuables et en métadonnées,
la réplication et le stockage desdits blocs de données sur au moins deux nœuds de stockage différents d’une base de données, dans lequel les métadonnées comprennent des valeurs faisant référence aux blocs de données immuables dans lesdits au moins deux nœuds de stockage pour un appel de base de données de valeurs-clés,

la conversion d’une requête, pour une plage de données d’un fichier, déclenchée par au moins une application côté client en une requête de lecture de quorum pour au moins un bloc de données immuable à la base de données, dans lequel la requête de lecture de quorum comprend une pluralité de requêtes parallèles individuelles à différents nœuds de stockage stockant le même bloc de données immuable,
la récupération des blocs de données délivrés par la base de données dans la réponse la plus rapide et le rejet des résultats délivrés subséquemment à la réponse la plus rapide,
la génération d’un fichier virtuel comprenant la plage de données correspondant à partir des blocs de données récupérés.

En outre, un produit-programme d’ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur est fourni pour mettre en œuvre les étapes du procédé mentionnées ci-dessus lorsque ledit programme fonctionne sur un ordinateur.

Des exemples de l’invention sont maintenant décrits également par référence aux dessins qui les accompagnent, dans lesquels

montre un exemple d’un système informatique distribué avec une entité de distribution de données, une base de données et une entité de récupération et de livraison des données ainsi que des applications clientes et un démon-fusible avec des blocs de données immuables qui sont répliqués et stockés par l’entité de distribution de données sur la base de données et interrogés via une lecture de quorum par l’entité de récupération et de livraison des données.

montre un exemple de base de données No SQL sur laquelle des blocs de données d’un fichier versionné et des métadonnées concernant ce fichier sont stockés.

montre un exemple de l’entité de récupération et de livraison des données en communication avec la base de données pour récupérer les blocs de données et les métadonnées un fichier virtuel stocké sur l’entité de récupération et de livraison des données.

montre un exemple d’un organigramme illustre en un procédé de livraison des données à partir d’une base de données a au moins une application côté client dans un environnement informatique distribué.

Les dessins et la description des dessins sont des exemples de l’invention et ne représentent pas l’invention en elle-même. Des signes de référence similaires font référence à des éléments similaires tout au long de la description suivante de modes de réalisation.

Description des exemples

Un exemple d’un système informatique distribué 100, avec une entité de distribution de données3, une base de données30 et une entité de récupération et de livraison des données50 ainsi que les applications clientes 1, 1' et un démon-fusible 51, avec des blocs de données immuables20 en cours de réplication et stockés par l’entité de distribution de données sur la base de données30 et interrogés via une lecture de quorum65 par l’entité de récupération et de livraison des données50, est montré dans laFig.1.

Une application fournisseuse de données23 est configurée pour produire un fichier de données5, par exemple, une liste aéroportuaire exportée à partir d’une plage de données aéroportuaire. L’application fournisseuse de données23 est configurée pour renvoyer le fichier de données générées5 à l’entité de distribution de données3. L’entité de distribution de données3 comprend un boîtier de distribution 3' (également dénommé « distribox ») et une partie dorsale du distribox3 '' avec la fonction d’un stockage de fichier persistant pour le fichier de données5. Le distribox 3' doit importer le fichier5 à partir de la partie dorsale du distribox3 ''. Le fichier de données5 comprend des données qui sont par exemple segmentées en blocs de donnée immuables20. Le distribox 3' est configuré pour répliquer tout ou au moins une partie substantielle des blocs de données immuables20 compris par le fichier de données5 et pour stocker les blocs de données immuables répliqués 20 aux nœuds de stockage32 d’une base de données30.

Dans l’exemple illustré par la Fig.1, les blocs de données immuables sont répliqués cinq fois et sont stockés sur cinq nœuds de stockage différents 32. Par conséquent, au total vingt-cinq blocs de données32 sont stockés sur la base de données. Lorsque le fichier de données5 est segmenté en cinq blocs de données immuables différents20, chaque nœud de stockage32 peut contenir une copie de chaque bloc de données immuable différent20.

Les applications côté client1, 1' pourrait fonctionner sur des serveurs d’applications respectifs indiqués par les boites en pointillés comprenant les applications côté client1,1'. Ces données consommant des applications pourraient être connectées à une entité de récupération et de livraison de données50 qui est par exemple un nœud Openshift. Les applications côté client1, 1' pourraient envoyer une requête pour une plage de données d’un fichier60 via un intergiciel qui est commun aux deux applications côté client1,1' et une interface dorsale d’applications51 '' à l’entité de récupération et de livraison de données50. Du côté des entités de récupération et de livraison de données, cette communication peut se faire via une interface de fichiers91. L’interface de fichiers91 prend en charge des accès de lecture séquentiels et aléatoires.

Si la requête pour une plage de données du fichier60 est déclenchée pour la première fois, aucune donnée correspondant à la plage de données demandé ne peut être délivrée directement à partir du fichier virtuel72. Par conséquent, les blocs de données20 correspondant auxdites plages de données73, 74 (voir Figs. 2 et 3) doivent être récupérés à partir de la base de données30. Dans ce but, l’entité de récupération et de livraison des données50 utilise un démon-fusible51. Le démon-fusible et configurée pour convertir la requête pour une plage de données du fichier60 en une requête de lecture de quorum65 pour au moins un bloc de données immuable 20 à la base de données30. Après avoir effectué cette conversion en requête de lecture de quorum65 (voir l’exemple de conversion expliqué dans la section antérieure), le démon-fusible51 émet cette requête vers la base de données30.

Dans la présente, la requête de lecture de quorum65 comprend une pluralité de requêtes parallèles individuelles66 à différents nœuds de stockage32 stockant le même bloc de données immuable20. Les requêtes parallèles66 sont identiques par rapport au bloc de données immuable20 vers lequel elles sont dirigées. De ce fait, toutes les requêtes parallèles66 sont, par exemple, dirigées vers les deux premiers blocs de données immuables 20 d’un fichier5 comprenant en tout dix blocs de données immuables20.

La requête de lecture de quorum65 est ensuite traitée par chaque nœud de stockage32 auquel une des requêtes individuelles66 est envoyée et envoie des réponses sous la forme de blocs de données demandés20 vers l’entité de récupération et de livraison de données50. Cependant, l’entité de récupération et de livraison des données50 peut recevoir chaque réponse, mais rejette chaque réponse sauf la réponse la plus rapide 70. Autrement, l’entité de récupération et de livraison de données50 peut recevoir la réponse la plus rapide 70 et amener les nœuds de stockage32 à arrêter le traitement de ces requêtes qui n’ont pas encore reçu de réponse.

Le démon-fusible51 peut recevoir le bloc(s) de données20 contenu dans la réponse la plus rapide 70 et stocker ces blocs de données dans un fichier virtuel72. Le fichier virtuel72 est stocké dans une page d’antémémoire52 d’un système d’exploitation51, par exemple un système d’exploitation LINUX. Le démon-fusible 51 peut être configuré pour garder les blocs de données récupérés dans la page d’antémémoire52 aussi longtemps que possible, donc jusqu’à ce que le fichier 5 et avec lui — les blocs de données — aient changé. La plage de données 73, 74 demandé à l’origine peut être retiré des blocs de données immuables récupérés20 résidant dans le fichier virtuel72 de la page d’antémémoire52.

À partir du fichier virtuel72 dans la page d’antémémoire52, la plage de données demandé 73, 74 est livré dans une réponse à l’application(s) côté client1,1' dans une réponse69 à la requête initiale. Du fait que les blocs de données récupérés 20 soient conservés dans le fichier virtuel72, ces blocs de données immuables20 pourraient être utilisés pour toute requête future pour une plage de données73, 74 compris par les blocs de données récupérés précédemment. Ceci réduit substantiellement les temps de traitement pour les futures requêtes pour la même plage de données ou pour une plage de données73, 74 également compris par les blocs de données immuables20 récupérés précédemment.

Un exemple de base de données No SQL sur laquelle des blocs de données d’un fichier versionné et des métadonnées concernant ce fichier sont stockés est montré dans laFig.2.

Trois versions d’un fichier de données, notamment les trois versions de fichiers de données les plus récentes, notamment le fichier de données5, le fichier de données 5' et le fichier de données5 '' sont conservées dans un stockage externe, tel que le stockage de fichiers persistant de la partie dorsale d’un distribox 3" montré dans la Fig.1. Du fait que ces fichiers de données5, 5', 5 '' soient externes au contenu illustré de la base de données NoSQL 30', ils sont illustrés dans la Fig.2 par des formes en pointillés. La base de données NoSQL 30' est une implémentation possible de la base de données30, montrée dans la Fig.1.

Le nœud de stockage32 de la base de données NoSQL 30', illustré de façon plus détaillée dans la Fig.2, peut stocker trois blocs de données immuables différents 20, 20', 20 ''. Ces blocs de données immuables20, 20', 20 '' sont compris par la version la plus récente du fichier de données, notamment le fichier de données5 et sont répliqués, entre autres, audit nœud de stockage32. Ces blocs de données immuables couvrent deux plages de données73, 74. La première plage de données73 est comprise par le bloc de données20 et le bloc de données 20' alors que la deuxième plage de données74 est comprise par le bloc de données 20' et le bloc de données20 ''. La première plage de données73 pourrait être une plage de données correspondant à une requête actuelle pour une plage de données d’un fichier60 alors que la deuxième plage de données74 peut correspondre aux données restantes d’un fichier74, en dehors de la plage demandée73.

La base de données NoSQL 30' stocke des métadonnées4 qui sont liées aux blocs de données immuables20, 20', 20 ''. Les métadonnées4 comprennent des valeurs42 faisant référence aux blocs de données immuables20, 20', 20 '' pour un appel de base de données de valeurs-clés. Dans l’exemple illustré par la Fig.2, ces valeurs de référencement42 sont les valeurs de hachage 42'. Par exemple, chaque bloc de données immuable 20, 20', 20 '' est associé à une valeur de hachage unique différente 42'.

Les métadonnées4 du fichier de données5 comprennent une liste de blocs avec leurs valeurs de hachage 42', la taille du fichier43 et la taille du bloc44. Les métadonnées4 du fichier de données5 comprennent par ailleurs une règle de calcul45 aisément exposée pour récupération par l’entité de récupération et de livraison de données50 (voir Fig.1). La règle de calcul45 implique une règle pour convertir une requête pour une certaine plage d’un fichier73 avec un certain décalage en une requête pour certains blocs de données immuables20, 20', 20". Cette règle de calcul45 utilise la taille du fichier43 et la taille du bloc44 stockées dans la liste des blocs pour produire les valeurs de hachage pour lesquelles l’entité de récupération et de livraison des données50 doit interroger afin d’obtenir les blocs de données immuables20, 20' correspondant à ces deux blocs de données20, 20' qui comprennent la plage de données du fichier73. Pour un exemple d’une telle règle de calcul et l’application de cette règle afin de récupérer les blocs de données immuables particuliers 20, 20', 20 '' il faut se référer à la description générale.

Outre le nœud de stockage32, la base de données NoSQL 30' comprend d’autres nœuds de stockage tels que le nœud de stockage 32' sur lequel, par exemple, les blocs de données20, 20', 20 '' sont stockés également.

Un exemple de l’entité de récupération et de livraison des données en communication avec la base de données pour récupérer les blocs de données et les métadonnées à un fichier virtuel stocké sur l’entité de récupération et de livraison des données, est montré dans laFig.3.

L’application consommatrice de données1 émet une requête pour ouvrir le fichier de données 61' pour être lu au démon-fusible 61'. Concomitamment à cette requête61 ou subséquemment à cette requête, une requête 62' comprenant le nom du fichier de données est envoyée de l’application cliente1 au démon-fusible51. Le démon-fusible51 émet les requêtes61, 62 qui correspondent aux requêtes susmentionnées 61', 62' à la base de données. Les requêtes 61' et 62' ainsi que les requêtes61 et 62 peuvent aussi être réalisées sous forme d’une requête unique.

Subséquemment ou concomitamment à la requête pour les fichiers61, 61' le démon-fusible51 doit récupérer les métadonnées4 du fichier de données5 (voir les Figs. 1 et 2). Ainsi que décrit par rapport à la Fig.2, ces métadonnées4 comprennent une liste de blocs avec leurs valeurs de hachage, une taille du fichier et une taille de bloc, ainsi qu’une règle computationnelle régissant comment convertir la requête pour une plage de données du fichier en une requête pour certains blocs. Les métadonnées4 sont stockées à l’entité de récupération et de livraison des données50, par exemple, dans le fichier virtuel72.

Lorsque la règle de calcul est reçue, le démon-fusible51 effectue une conversion de la requête pour une plage de données d’un fichier60 à ladite requête de lecture de quorum65 qui est envoyée à la base de données30.

Une première de cette lecture de quorum65 pourrait être envoyée pour récupérer une plage de données73 inclus dans les blocs de données immuables20, 20'. Ces blocs de données immuables20, 20' sont récupérés et stockés dans le fichier virtuel72. Les données des blocs de données immuables20, 20' correspondant à la plage de données73 peuvent être isolées de ces blocs de données immuables récupérés 20, 20' et les données de la plage73 sont, par exemple, également stockées dans le fichier virtuel72.

De ce fait, les blocs de données immuables20, 20' peuvent rester stockés en plus de la plage de données73 demandé à l’origine par l’application cliente 1 dans la requête60 pour une plage de données. Cependant, les blocs de données immuables20, 20' peuvent aussi être supprimés du fichier virtuel72 après avoir isolé et stocké la plage de données73 dans le fichier virtuel72.

De la même façon, les données d’une plage de données74 correspondant aux données restantes du fichier5 peuvent être récupérées. Cette plage de données74 représente des données comprises par les blocs de données immuables 20', 20 '' qui sont à nouveau récupérées par le démon-fusible et stockées dans le fichier de données virtuel 72 sur l’entité de récupération et de livraison des données50. Ici aussi, la plage de données74 peut être isolé des blocs de données immuables 20', 20 ''.

Un exemple d’un organigramme illustrant un procédé de livraison de données à partir d’une base de données à au moins une application côté client dans un environnement informatique distribué est montré dans laFig.4.

Dans l’activitéS1, les données-sources sous la forme d’un fichier de données sont divisées en blocs de données immuables et en métadonnées.

Dans l’activitéS2, les blocs de données sont répliqués et stockés sur au moins deux nœuds de stockage différents d’une base de données dans lesquels les métadonnées crées à l’activité S1 comprennent des valeurs faisant référence aux blocs de données immuables dans lesdits au moins deux nœuds de stockage pour un appel de base de données de valeurs-clés.

Dans l’activitéS3, une requête pour une plage de données d’un fichier déclenchée par au moins une application côté client est convertie en une requête de lecture de quorum pour au moins un bloc de données immuable à la base de données, où la requête de lecture de quorum comprend une pluralité de requêtes parallèles individuelles à différents nœuds de stockage stockant le même bloc de données immuable.

Dans l’activitéS4, les blocs de données délivrés par la base de données dans la réponse la plus rapide sont récupérés et ces résultats délivrés subséquemment à la réponse la plus rapide sont rejetés.

Dans l’activitéS5, un fichier virtuel comprenant la plage de données correspondant à partir des blocs de données récupérés est créé.

Claims

Un système informatique distribué pour délivrer des données à au moins une application côté client, le système informatique distribué comprenant:
une base de données configurée pour stocker des blocs de données immuables,

une entité de distribution de données configurée pour diviser les données-sources sous la forme d’un fichier de données en blocs de données immuables et en métadonnées,

dans lequel l’entité de distribution de données est configurée pour répliquer les blocs de données immuables et pour stocker les blocs de données immuables sur au moins deux nœud(s) de stockage différents de la base de données.

dans lequel les métadonnées comprennent des valeurs faisant référence aux blocs de données immuables dans lesdits au moins deux nœuds de stockage pour un appel de base de données de valeurs-clés,

une entité de récupération et de livraison de données comprenant:

un démon-fusible configuré pour convertir une requête pour une plage de données d’un fichier déclenchée par au moins une application côté client en une demande de lecture de quorum pour au moins un bloc de données immuable à la base de données,

dans lequel la requête de lecture de quorum comprend une pluralité de requêtes parallèles individuelles à différents nœuds de stockage stockant le même bloc de données immuable,

dans lequel le démon-fusible est configuré pour récupérer les blocs de données délivrés par la base de données dans la réponse la plus rapide et est configuré pour rejeter des résultats délivrés subséquemment à la réponse la plus rapide,

dans lequel le démon-fusible est configuré pour générer un fichier virtuel comprenant la plage de données correspondant à partir des blocs de données récupérés,

dans lequel l’entité de récupération et de livraison de données comprend un système d’exploitation ayant une page d’antémémoire de système d’exploitation, dans laquelle la page d’antémémoire de système d’exploitation est configurée pour stocker au moins les parties des blocs de données récupérés correspondant à la plage de données d’un fichier demandé par l’application côté client, dans lequel le démon-fusible est configuré pour conserver les blocs de données récupérés dans le cache de pages jusqu'à ce que le fichier, et avec lui le bloc de données, ait changé, et où chaque fois que des blocs de données plus à jour sont disponibles, le nouveau bloc de données est récupéré et poussé vers le cache de page par le démon-fusible.
Le système informatique distribué des revendication1, dans lequel les données dans le fichier virtuel sont récupérables par ladite au moins une application côté client comme réponse à la requête pour une plage de données d’un fichier et comme réponse à une quelconque requête future pour la même plage de données d’un fichier.
Le système informatique distribué de l’une quelconque des revendications1 à 2, dans lequel la base de données comprenant les nœuds de stockage est une base de données NoSQL.
Le système informatique distribué de l’une quelconque des revendications1 à 3, dans lequel les valeurs comprises par les métadonnées font référence à des valeurs qui font référence aux blocs de données immuables pour un appel de base de données de valeurs-clés, ces valeurs de référence étant générées à travers des valeurs de hachage de chaque bloc de données correspondant.
Le système informatique distribué de l’une quelconque des revendications1 à 4, dans lequel la base de données est configurée pour délivrer des données correspondant au fichier incluant les données d’un bloc de données en dehors de la plage demandée du fichier.
Le système informatique distribué de la revendication5, dans lequel le fichier virtuel comprend, en plus de la plage de données demandé, les métadonnées de blocs de données correspondant aux données en dehors de la plage demandée du fichier.
Le système informatique distribué des revendication6, dans lequel le démon-fusible est configuré pour générer le fichier virtuel comprenant les métadonnées.
Le système informatique distribué de l’une quelconque des revendications1 à 7, dans lequel au moins deux applications côté client utilisent une bibliothèque cliente d’intergiciels commune pour accéder au fichier virtuel.
Le système informatique distribué de l’une quelconque des revendications1 à 8, dans lequel le démon-fusible est configuré pour effectuer l’interrogation pour l’opération de lecture de quorum au moins trois fois en parallèle et dans lequel les mêmes blocs de données sont stockés au moins trois fois sur au moins trois nœuds différents de stockage de base de données.
Le système informatique distribué de la revendication9, dans lequel le démon-fusible est configuré pour effectuer l’interrogation pour l’opération de lecture de quorum trois fois en parallèle et dans lequel les mêmes blocs de données sont stockés cinq fois sur au moins cinq nœuds différents de stockage de base de données.
Le système informatique distribué de l’une quelconque des revendications1 à 10, dans lequel le système d’exploitation de l’entité de récupération et de livraison des données est un système d’exploitation basé sur UNIX.
Le système informatique distribué de l’une quelconque des revendications1 à 11, dans lequel le démon-fusible est configuré pour sélectionner et pour récupérer des blocs de données basés sur la plage de données du fichier en sélectionnant et en récupérant ces blocs de données immuables qui contiennent des données à l’intérieur de la plage de données demandée.
Le système informatique distribué de la revendication12, dans lequel avant que la requête de lecture de quorum pour au moins un bloc de données immuable soit émise par l’entité de récupération et de livraison de données, une requête de l’application cliente au démon-fusible comprenant le nom du fichier de données est émise lorsqu’une requête pour ouvrir le fichier de données est émise par l’application cliente.
Le système informatique distribué de la revendication13, dans lequel le démon-fusible est par ailleurs configuré pour récupérer des métadonnées du fichier qui comprennent la liste des blocs avec leurs valeurs de hachage, la taille du fichier et la taille du bloc et doit stocker les métadonnées sur l’entité de récupération et de livraison des données, dans lequel les métadonnées sont récupérées lorsqu’une requête pour ouvrir le fichier de données effectuée par l’application cliente est émise.
Le système informatique distribué de la revendication14, dans lequel le démon-fusible doit convertir la requête pour une plage de données d’un fichier en requête de lecture de quorum en utilisant les informations contenues dans les métadonnées, la conversion comprenant un calcul qui implique la taille du fichier, la taille du bloc et la plage demandée, en utilisant une règle de calcul également obtenue à partir des métadonnées du fichier.
Le procédé de l’une quelconque des revendications1 à 15, dans lequel au moins deux versions, préférablement trois versions du fichier de données divisé en blocs de données immuables sont conservées dans un stockage du système informatique distribué qui est capable de délivrer la version du fichier de données à l’entité de distribution de données.
Un procédé de livraison de données à au moins une application côté client, le procédé étant exécutable sur le système informatique distribué de l’une quelconque des revendications1 à 16, le procédé comprenant:
la division des données-sources sous la forme d’un fichier de données en blocs de données immuables et en métadonnées,

la réplication et le stockage desdits blocs de données sur au moins deux nœuds de stockage différents d’une base de données dans lequel les métadonnées comprennent des valeurs faisant référence aux blocs de données immuables dans lesdits au moins deux nœuds de stockage pour un appel de base de données de valeurs-clés,

la conversion d’une requête, pour une plage de données d’un fichier, déclenchée par au moins une application côté client en une requête de lecture de quorum pour au moins un bloc de données immuable à la base de données, dans lequel la requête de lecture de quorum comprend une pluralité de requêtes parallèles individuelles à différents nœuds de stockage stockant le même bloc de données immuable,

la récupération des blocs de données délivrés par la base de données dans la réponse la plus rapide et le rejet des résultats délivrés subséquemment à la réponse la plus rapide,

la génération d’un fichier virtuel comprenant la plage de données correspondant à partir des blocs de données récupérés,
dans lequel l’entité de récupération et de livraison de données comprend un système d’exploitation ayant une page d’antémémoire de système d’exploitation, dans laquelle la page d’antémémoire de système d’exploitation est configurée pour stocker au moins les parties des blocs de données récupérés correspondant à la plage de données d’un fichier demandé par l’application côté client, dans lequel le démon-fusible conserve les blocs de données récupérés dans le cache de pages jusqu'à ce que le fichier, et avec lui le bloc de données, ait changé, et où chaque fois que des blocs de données plus à jour sont disponibles, le nouveau bloc de données est récupéré et poussé vers le cache de page par le démon-fusible.
Un produit programme d’ordinateur comprenant des instructions de code de programme enregistrées sur un support lisible par ordinateur pour mettre en œuvre les étapes du procédé selon la revendication17 lorsque ledit programme fonctionne sur un ordinateur.