Brevet FR3093574A1 — publié le 20200911

Description Titre de l'invention : TRAITEMENT DE DONNÉES DIS- TRIBUÉES [0001] La présente invention concerne la technologie de base de données et le traitement de données dans un environnement informatique distribué comprenant au moins un serveur et une pluralité de clients comprenant au moins un premier client et un deuxième client. Plus spécifiquement, elle concerne le traitement des données et la mise à disposition des données aux clients. [0002] L'évolution des technologies Web et des systèmes informatiques distribués au cours des dernières décennies ont conduit à une augmentation significative de la charge du trafic Web et dc la charge du serveur. Par conséquent, il faut s'attendre à une autre augmentation dc la charge de trafic Web et de la charge du serveur, découlant d'une augmentation des exigences matérielles et logicielles pour lesdits systèmes informatiques distribués. Ces dernières années, certaines approches ont été entreprises pour régler l'augmentation de la charge du trafic Web et dc la charge du serveur. [0003] US 2007/0005679 Al présente un procédé d'exécution d'une recherche dans un système client-serveur. Un sous-système client reçoit un ensemble de résultats de recherche initiaux provenant d'un sous-système serveur, un moteur de règles lance un balayage du sous-système client pour collecter les informations techniques associées au sous-système client, et le moteur de règles filtre l'ensemble des résultats dc recherches initiaux au niveau du sous-système client. L'étape de filtrage se base sur les informations techniques collectées. [0004] US 8,276,084 B2 présente un ajustement de performance dans un univers virtuel. Dans une approche mixte basée sur un serveur/pair à pair, les responsabilités dc transmission sont décalées vers le calcul pair à pair lorsque le nombre d'avatars dans une région augmente. Le serveur peut « décharger » le traitement ultérieur des données aux clients pour améliorer la performance du serveur. Par exemple, un utilisateur qui passe dans un univers virtuel peut recevoir des informations haute résolution sur le paysage provenant d'autres utilisateurs qui sont déjà dans la zone et qui ont auparavant obtenu des données haute résolution telles que des textures, des géométries, etc. provemun du serveur d'univers virtuel. [0005] US 8,616,976 B2 décrit la fourniture de services de jeux via des réseaux pair à pair ad hoc. Les dispositifs pairs agissant en tant que client télécharge des données de jeux provemun d'une base de données qui fonctionne comme un serveur. Les dispositifs pairs peuvent envoyer les données téléchargées et les données générées à d'autres dispositifs pairs. 2 [0006] Selon un premier aspect, un procédé de traitement des données dans un envi- ronnement informatique distribué est fourni. L'environnement informatique distribué comprend au moins un serveur et une pluralité de clients comprenant au moins un premier client et un deuxième client. Le premier client envoie une première demande au serveur pour obtenir les données de résultat. Le premier client reçoit ensuite des données brutes provenant du serveur en tant que réponse à la première demande. Ensuite, le premier client traite les données brutes pour obtenir les données de résultat et stocker les données de résultat. En réponse à la réception d'une troisième demande pour obtenir les données de résultat provenant du deuxième client, le premier client envoie les données de résultat au deuxième client. [0007] Selon un autre aspect, le serveur stocke la première demande reçue du premier client en tant qu'indication selon laquelle les données de résultat sont disponibles au niveau du premier client. [0008] Selon un autre aspect supplémentaire, le deuxième client envoie une deuxième demande au serveur pour obtenir les données de résultat et, en réponse, reçoit une indication du serveur indiquant que les données de résultat sont disponibles au niveau du premier client. Le deuxième client stocke ensuite l'indication renvoyée par le serveur selon laquelle les données de résultat sont disponibles au niveau du premier client et envoie la troisième demande au premier client pour obtenir les données de résultat. [0009] Selon un autre aspect supplémentaire, le deuxième client reçoit une quatrième demande provenant d'un troisième client pour obtenir les données de résultat et, en réponse, envoie une indication renvoyée par le serveur selon laquelle les données de résultat sont disponibles au niveau du premier client au troisième client. Le troisième client est ensuite capable de récupérer les données de résultat provenant du premier client. [0010] Encore selon un autre aspect, le premier client reçoit une indication provenant du serveur indiquant une durée de validité des données brutes. Le premier client supprime les données de résultat à un moment donné correspondant à la durée de validité indiquée par le serveur. [0011] Selon un autre aspect supplémentaire, la première demande stockée, stockée au niveau du serveur en tant qu'indication selon laquelle les données de résultat sont disponibles au niveau du premier client inclut l'indication indiquant la durée de validité des données brutes. Le serveur supprime la première demande stockée à un moment donné correspondant à la durée de validité. [0012] Selon un autre aspect, un dispositif client de traitement des données dans un envi- ronnement informatique distribué est fourni. Le dispositif client est conçu pour envoyer une première demande à un serveur pour obtenir les données de résultat, pour recevoir les données brutes provenant du serveur en tant que réponse à la première 3 demande, pour traiter les données brutes et obtenir les données de résultat et stocker les données de résultat, et pour envoyer les données de résultat à un autre dispositif client en réponse à la réception d'une troisième demande pour obtenir les données de résultat provenant de l'autre client. [0013] Selon d'autres aspects, le dispositif client est par ailleurs conçu pour exécuter les étapes du procédé au niveau du premier client, du deuxième client et/du troisième client, comme exposé ci-dessus. [0014] Selon un autre aspect supplémentaire, un serveur pour le traitement des données dans un environnement informatique distribué est fourni. Le serveur est conçu pour recevoir une première demande provenant d'un premier client pour obtenir les données de résultat ; renvoyer les données brutes au premier client en tant que réponse à la première demande ; stocker la première demande reçue du premier client en tant qu'indication selon laquelle les données de résultat sont disponibles au niveau du premier client ; recevoir une deuxième demande provenant d'un deuxième client pour obtenir les données de résultat ; et renvoyer l'indication au deuxième client indiquant que les données de résultat sont disponibles au niveau du premier client. [0015] Selon un autre aspect supplémentaire, le dispositif client est par ailleurs conçu pour exécuter les étapes du procédé au niveau du serveur, comme exposé ci-dessus. [0016] Selon un autre aspect supplémentaire, un produit de programme informatique est fourni. Le produit de programme informatique comprend des instructions de code de programme stockées dans un support lisible par ordinateur pour exécuter les étapes du procédé et/ou les fonctions du premier client, du deuxième client et/ou du troisième client et/ou du serveur exposées ci-dessus, lorsque ledit programme est exécuté sur un ordinateur. [0017] Les présents mécanismes seront décrits en référence aux dessins qui les ac- compagnent. Les numéros de référence similaires indiquent en général des éléments identiques ou fonctionnellement similaires. [0018] [fig.1] est une représentation schématique d'un environnement informatique distribué tel que décrit dans la présente invention. [0019] [fig.2] est une représentation schématique d'un processus de traitement des données basées sur un serveur dans l'état actuel de la technique antérieure. [0020] [fig.3] est une représentation schématique d'un processus de traitement des données décalé vers le client selon certains modes de réalisation. [0021] [fig.4] est un diagramme de séquence selon certains modes de réalisation. [0022] [fig.5] est un diagramme de séquence selon certains modes de réalisation. [0023] [fig.6] est un diagramme de séquence selon certains modes de réalisation. [0024] [fig.7] est une représentation schématique des composants internes d'une machine in- formatique selon certains modes de réalisation. [0025] L'augmentation de la charge du serveur dans des environnements informatiques distribués et de réseaux de distribution de contenu en raison de l'augmentation du nombre de demandes de données envoyées par des clients et la recherche, la réception et le traitement de données ultérieurs engendre l'augmentation des coûts de fonctionnement des serveurs, tels que les coûts de CPU et les coûts de stockage. De plus, les clients doivent attendre pendant plus longtemps jusqu'à ce que leurs demandes soient traitées et que les données demandées soient renvoyées. Cela peut conduire à des dispositifs et des interfaces utilisateurs moins réactifs et à d'autres demandes de suivi inutiles provenant des dispositifs utilisateurs et les utilisateurs à supposer que la demande actuelle n'est pas traitée correctement. [0026] Par ailleurs, l'augmentation du nombre de demandes de données envoyées par les clients et la recherche, la réception et le traitement des données ultérieurs engendre l'augmentation de la charge du trafic Web dans un environnement informatique distribué, diminuant ainsi la vitesse de transfert et augmentant l'utilisation de la bande passante. Les clients doivent attendre plus longtemps la livraison des données demandées et les charges du réseau augmentent. [0027] Pour citer un exemple, le taux de réussite d'une base de données de contenu ac- cessible par Internet fréquentée peut dépasser 1 milliards de transactions par jour, avec une augmentation exponentielle attendue. Les hébergeurs de bases de données répondent à ces développements en exploitant des caches et en installant des réseaux de diffusion/distribution de contenus en temps réel, en optimisant par conséquent la performance et en réduisant les coûts. Jusqu'à présent ces approches n'utilisent cependant pas la puissance de calcul croissante disponible côté client. [0028] La puissance de calcul et les capacités de stockage de données des dispositifs client tels que les téléphones portables et les ordinateurs portables ont augmenté au cours des dernières décennies en raison du matériel plus puissant tel que les unités de traitement de smartphone et les cartes graphiques. La puissance informatique des dispositifs client a également augmenté en raison des développements côté logiciel, étant donné que les systèmes d'exploitation tels que iOS® et Android®, JavaScript® dans les navigateurs et les applications pour dispositifs mobiles, communément appelées « apps » sont entrés sur le marché. Par conséquent, les systèmes clients actuels possèdent une autonomie significative concernant les capacités à faire fonctionner les outils et les plates-formes logiciels ainsi que les capacités de stockage de données qui permettent aux clients de prendre des fonctionnalités de serveur et de calcul améliorées. [0029] Selon les présents modes de réalisation, afin de traiter l'augmentation de la charge du serveur dans un environnement informatique distribué, lorsque le nombre de demandes provenant des clients et la magnitude des données demandées augmente, le traitement des données demandées est décalé, au moins dans une certaine mesure, du serveur demandé vers les clients demandeurs. [0030] La FIG. 1 illustre un système informatique distribué tel qu'utilisé dans les présentes de manière schématique composé d'un serveur 4, d'un nombre de clients 1, d'un nombre de hases de données 5 et d'un nombre d'interfaces de communication 6. [0031] Le serveur 4, les clients 1 et la hase de données 5 peuvent être constitués de plusieurs machines matérielles selon les exigences de performance. À la fois, le serveur 4 et les clients 1 sont conçus, par exemple, sous forme de machines matérielles fixes ou mobiles comprenant des machines informatiques 100 comme illustré à la FIG. 7 et/ou sous forme de systèmes spécialisés tels que des systèmes intégrés conçus pour un objectif technique particulier, et/ou sous forme de composants logiciels fonctionnant sur une machine matérielle informatique spécialisée ou générale (telle qu'un serveur Weh ou des clients Weh). [0032] Le serveur 4 et les clients 1 sont interconnectés par les interfaces de communication 6. Chacune des interfaces 6 utilise un réseau local (LAN) câblé ou sans fil ou un réseau métropolitain (MAN) câblé ou sans fil ou un réseau étendu (WAN) câblé ou sans fil tel qu'Internet ou une combinaison des techologics de réseau susmentionnées et elles sont mises en oeuvre par tout protocole de communication et réseau approprié. [0033] Dans des solutions actuelles de la technique antérieure, un client 1 envoie une demande de données au serveur 4. Le serveur 4 identifie ensuite et reçoit les données correspondant à la demande provenant d'une ou de plusieurs hases de données 5. Là où les bases de données 5 peuvent être hébergées au niveau du serveur 4 lui-même ou peuvent être situées à distance du serveur 4. Dans les deux cas, les bases de données 5 sont accessibles via une interface de communication 7 par le serveur. Les données conservées au niveau des bases de données 5 ne sont généralement pas encore complètement traitées conformément à la demande du client 1, c.-à-d. que les données disponibles sur le serveur ne sont habituellement pas encore présentes sous une forme à renvoyer directement au client 1 en réponse à la réception de la demande. Le serveur 4 traite plutôt les données disponibles dans les bases de données 5 afin d'extraire, reformater, trier, manipuler, etc., les données pour obtenir une représentation des données qui correspond aux exigences exposées dans la demande par le client. Seules les données traitées sont ensuite renvoyées au client 1, c.-à-d. que le traitement complet des données conservées au niveau des bases de données 5 est exécuté côté serveur. [0034] Par exemple, un processus de traitement de données basé sur un serveur, exécuté selon l'état de la technique antérieure est décrit et visualisé à la FIG. 2. Le serveur 4 contient une base de données SQL relationnelle (l'une des bases de données 5 à la Fig. 1) et reçoit une interrogation SQL (demande 10) provenant d'un client pour récupérer certaines données dans la base de données SQL, telles qu'une vue « tableAB » basée sur deux tables de base de données, « tableA » et « tableB ». Après réception de la 6 demande 15 du client 1 A, le serveur 4 identifie les tahles de hases de données pertinentes de la hase de données SQL. Le serveur 4 reçoit ensuite les tables de hases de données identifiées et stocke les tahles de hases de données par ex. dans le système de stockage principal du serveur 4. [0035] En référence encore à l'exemple de la FIG. 2, le serveur 4 poursuit avec le traitement des tables de hase de données récupérées et crée des sous-ensembles de tahles de hases de données provenant des tahles de bases de données en utilisant la commande SQL CREATE VIEW (CRÉER VUE). Les sous-ensembles de tables de hases de données forment à nouveau des tables de hases de données et sont communément appelées vues et ils servent de base pour la création de nouvelles tables de bases de données en utilisant des instructions SQL telles que JOIN (RELIER), LEFT OUTER JOIN (RELIER EXTERNE GAUCHE), RTGHT OUTER JOIN (RELIER EXTERNE DROIT), etc. Par la suite, en utilisant une instruction SQL telle que SELECT (SÉLECTIONNER), le serveur 4 créer ensuite les données demandées par l'un des clients 1 A. De plus, les données sont triées selon les critères identifiés dans la demande 10 du client 1 A. [0036] Pour préciser encore l'exemple, la table de base de données « tableA » peut résider sur une première hase de données 5 et la table de hase de données « tahleB » peut résider sur une deuxième base de données 5. Le serveur 4 reçoit la « tableA » et la « tahleB » et les stocke dans le système de stockage principal ou le cache du serveur 4. Après le décodage, l'élimination des erreurs et la définition d'un format commun comme décrit dans les exemples susmentionnés, le serveur 4 avec le traitement en utilisant les instructions SQL suivantes : CRÉER VUE vueA (donnéelA, donnée2A) EN TANT QUE SÉLECTIONNER donnéelA, donnée2A À PARTIR DE la tableA; CRÉER VUE vueB (donnéelB, donnée2B) EN TANT QUE SÉLECTIONNER donnéelB, donnée2B À PARTIR DE la tableB; CRÉER VUE tableAB EN TANT QUE SÉLECTIONNER donnéelC, donnée2C, donnée2A, donnée3C, donnée2B de la tableC, vueA, vueB où tableC.donnée1C = vueA.donnéelA et tableC.donnée2C = vueB.donnéelB [0037] Enfin, les données stockées dans la vue « tableAB » sont par ailleurs traitées par le serveur 4 en tant que compression de données avant d'être envoyées au client lA qui a demandé les données (vue « tableAB »). [0038] Par conséquent, comme illustré par l'exemple de la FIG. 2., le serveur 4 emploie des ressources de calcul significatives et le temps de calcul pour traiter les données stockées dans la base de données SQL 5 avant que les données traitées ne soient 7 renvoyées au client 1 A, cc qui constitue une charge significative sur le serveur 4 en particulier en période de nombre élevé de demandes dc clients à la fois auxquelles il faut répondre. [0039] Pour régler cette situation, selon les présents modes de réalisation, le serveur 4 n'exécute plus le traitement complet des données reçues d'une ou dc plusieurs hases de données 5 pour produire les données demandées par le client 1. Au moins une partie du traitement des données est plutôt relocalisé au client demandeur 1. À cette fin, un client particulier 1, appelé premier client 1 A, est considéré dans cc qui suit. Le premier client l A envoie une demande dc données 10, également appelée première demande, au serveur 4 pour obtenir les données de résultat. Le ternie « données de résultats » concerne généralement les données dans la représentation telles que requises par un client 1, c.-à-d. telles que traitées traditionnellement côté serveur, comme décrit ci-dessus en référence à la FIG. 2. [0040] Selon les présents modes de réalisation, le serveur 4 ne renvoie cependant pas les données de résultat, comme demandé par le client 1 A, mais seulement les données brutes. Le terme « données brutes » fait en général référence dans les présentes aux données conservées au niveau des hases dc données 5 et récupérées dans le serveur 4, dans un état qui n'est pas entièrement traité par le serveur 4 afin de répondre aux exigences de la demande 10 du client 1. Les données brutes sont par ex. organisées dans des tables de bases de données. Dans certains modes de réalisation, les hases de données 5 sont des bases de données relationnelles qui sont interrogées en utilisant des instructions SQL. Les données brutes ne constituent pas encore les données en termes de contenu, format, ordre, etc., qui étaient demandées par le client. Les données brutes peuvent plutôt exister dans différents formats corrélés à différentes bases de données et peuvent être décodées ou non formatées. De plus, les données brutes peuvent contenir des redondances ou un surdébit, ou peuvent ne pas être filtrées et contenir ainsi plus de contenu que demandé en réalité par le client 1. Par exemple, les données brutes sont un super ensemble de données de résultat demandées par le client 1, c.-à-d. en d'autres termes, que les données de résultat demandées sont un sous-ensemble des données brutes renvoyées par le serveur 4 en réponse à la première demande (le sous-ensemble peut être soumis à un traitement ultérieur tel que les agrégations, le décodage, le formatage, la commande, etc., comme expliqué). Les données brutes ne sont pas encore traitées de cette manière pour obtenir ces types de données de résultat que le client a en réalité demandé. De la même façon, les données de résultat sont le résultat du traitement des données brutes selon les exigences de la demande du client. [0041] Selon les présents modes de réalisation, au moins une partie du traitement pour transformer les données brutes en données de résultat est exécutée par le client demandeur 1A sur les données brutes reçues du serveur 4 en réponse à la demande 10 8 du client. Plus spécifiquement, dans certains modes de réalisation, une partie du traitement est encore effectuée par le serveur 4 tandis que les parties restantes du traitement (jusqu'ici également exécutées par le serveur 4) sont relocalisécs vers le côté client. Par exemple, le serveur 4 peut encore supprimer les ensembles de données redondantes et sélectionner les données dans les tables base de données qui sont actuellement nécessaires, tandis que d'autres tâches telles que le formatage et le tri des données sont uniquement effectuées par le client. Cela libère le serveur 4 d'au moins une partie des tâches de traitement de données pour répondre aux demandes de données et utiliser à la place les ressources de calcul distribuées des dispositifs client. [0042] Dans certains modes de réalisation et dans l'exemple illustré à la FIG. 3, les tâches de décodage des tables de bases de données reçues, l'élimination d'erreurs résidant dans les tables de bases de données en supprimant par ex. les ensembles de données redondantes des tables de bases de données ou les ensembles de données avec des entrées manquantes et l'établissement d'un format commun restent au niveau du serveur 4. De plus, le serveur 4 crée également les sous-ensembles en dehors des tables de bases de données interrogées qui dans le présent exemple sont « vueA » et « vueB ». Après cela, le traitement ultérieur survient au niveau du client lA qui a demandé les données. Les vues créées (« vueA », « vueB ») sont envoyées au client lA qui a demandé les données. Au niveau du client lA qui a demandé les données, les vues créées (« vueA », « vueB ») sont stockées dans le cache ou dans tout autre système de stockage et le traitement pour obtenir des données de résultat se poursuit. Cela signifie pour le présent exemple la création de la vue « tableAB » et le tri final des données de résultat. [0043] Dans certains modes de réalisation, le serveur 4 peut même s'abstenir d'extraire les données demandées dans la/les base(s) de données 5 mais par ex. envoie des tables de base de données en tout ou partie (par ex., des lignes ou des colonnes non traitées d'une ou de plusieurs tables de base de données) au client demandeur lA et le client lA emploie les opérations de base de données (par ex., les instructions SQL) sur les tables de base de données afin d'extraire et de traiter les données demandées. Par conséquent, dans ces modes de réalisation, les données brutes sont données par des tables de bases de données complètes ou partielles. Cela libère le serveur 4 des tâches de traitement de données pour répondre aux demandes de données et utiliser à la place les ressources de calcul distribuées des dispositifs client. [0044] En référence encore au présent exemple de la FIG. 3, dans cette variante, les tables de bases de données interrogées « tableA » et « tableB » sont envoyées directement au client lA par le serveur 4. Au niveau du client 1A, le traitement inclut également par la suite les tâches exemplaires de décodage des tables de bases de données reçues, en supprimant les ensembles de donnés redondants dans les tables de bases de données ou 9 les ensembles de données, et l'établissement d'un format commun ainsi que l'extraction des sous-ensembles hors des tables de bases de données interrogées, qui dans le présent exemple sont la « vueA » et la « vueB ». [0045] À titre d'exemple supplémentaire, le traitement de données partiel côté serveur peut inclure le formatage par ex. selon les normes des classes de fondation de l'industrie (normes IFC) pour rendre les données appropriées à l'envoi d'un client 1 et pour le traitement ultérieur par le client 1. Un autre exemple de traitement partiel de données est la mise à jour d'ensemble de données dans le cas où la hase de données demandée 5 est un cache et les données stockées dans le cache ne sont pas nécessairement mises à jour. Dans cette situation, le serveur 4 peut valider les données brutes récupérées dans la hase de données 5 avec une autre hase de données ou source de données originales avant de renvoyer les données brutes au client avec le message 16. [0046] Dans certains modes de réalisation, renvoyer 16 les données brutes provenant du serveur 4 au client 1 emploie des techniques de compression des données en utilisant comme exemple des livres de codes réutilisables pour générer les données compressées dans un format zip. Par conséquent, la charge du trafic Web est réduite par rapport au renvoi des données brutes qui est probablement plus volumineux que les données de résultat (par ex., en raison du filtrage et de l'extraction des données apparaissant uniquement coté client), d'une manière non compressée. Puisque les livres de code changent uniquement lorsqu'ils sont mis à jour, il n'est pas nécessaire d'envoyer les livres de code avec chaque lot de données. Les livres de code peuvent être envoyés séparément à partir des lots de données et seulement une fois, au début de l'envoi des données et lorsque les livres de code ont été mis à jour. [0047] De plus ou dans la variante, dans certains modes de réalisation, les données brutes à transmettre au client demandeur lA sont cryptées par le serveur 4. Par exemple, des techniques de cryptage telles que le calcul multipartite sécurisé (MPC) ou le chiffrement point à point peuvent être appliquées. [0048] Au niveau du premier client 1A, les données brutes reçues sont traitées 18 en utilisant un moteur de calcul 100 présenté à la FIG. 7 par une fonctionnalité de traitement de données 109 comprenant un code de programmes informatique résidant dans la mémoire 106 de la machine informatique 100 du premier client lA pour obtenir les données de résultat. Le traitement des données au niveau du premier client lA peut être fait en utilisant toute application logicielle native appropriée qui peut fonctionner sur le client. Le traitement des données peut également être fait avec toute application de navigateur appropriée du premier client ou avec la combinaison d'une application native et d'une application de navigateur. Le traitement des données au niveau du premier client lA pour générer les données de résultat peut être intégré dans une interface utilisateur du dispositif client. L'interface utilisateur peut afficher les données de résultat à un utilisateur. Les données de résultat peuvent être présentées à l'utilisateur en tant que lots de données ou en tant que données de diffusion en continu, la diffusion en continu pouvant être contrôlée par les mises à jour de données envoyées par le serveur 4. [0049] Après que le client l A a conclu le traitement côté client des données brutes reçues et, par conséquent, a généré les données de résultat, le client - en plus du traitement ultérieur habituel (telque l'affichage des données de résultat via l'interface utilisateur graphique du dispositif client comme mentionné auparavant), différent de US 2007/0005679 Al, le premier client lA stocke 19 également les données de résultat, afin de rendre disponible les données de résultat générées par le premier client l A aux autres clients 1 peut-être en cherchant à obtenir les mêmes données de résultat dans le futur. En particulier, en réponse à une autre demande (dénommée troisième demande dans les présentes) pour obtenir les données de résultat provenant d'un autre client (dénommé deuxième client 1B dans les présentes), le premier client lA envoie les données de résultat au deuxième client 1B. [0050] Le fait de mettre les données de résultat générées par le premier client 1 A di- rectement à la disposition d'autres clients 1B, 1C sans s'appuyer sur les capacités de traitement et de stockage du serveur 4 constitue un aspect pair à pair des présents modes de réalisation. Selon les présents modes de réalisation, une connexion pair à pair est une connexion entre des participants équitablement privilégiés de même puissance dans l'environnement informatique distribué. Les pairs sont à la fois des fournisseurs et des consommateurs de données, par rapport au modèle client - serveur traditionnel dans lequel la consommation et la fourniture de ressources est divisée entre un nombre de serveurs et un nombre de clients. Dans les présents modes de réalisation, les clients (client 1A, 1B or 1C) peuvent ainsi échanger des données directement entre eux sans utiliser le serveur 4 en tant que noeud de médiation. Le serveur 4 peut encore contribuer à la communication pair à pair en fournissant une architecture d'arrière plan, c.-à-d. les procédures qui facilitent l'interaction client. Selon les présents modes de réalisation et comme expliqué plus en détail ci-dessous, l'architecture d'arrière-plan du serveur 4 reçois la demande de données provenant d'un client 1 et renvoie une indication à ce client 1 selon laquelle les données demandées sont disponibles au niveau d'un autre client. De plus, l'architecture d'arrière-plan du serveur 4 peut également comprendre le cache du serveur 4, le cache pouvant stocker les données telles que des tables « tableA » et « tableB », vues « vueA » et « vueB » ou les indications selon lesquelles les données de résultat sont disponibles au niveau d'un certain client. [0051] Des diagrammes de séquence de messages de ce mécanisme de traitement global (traitement côté client, et disponibilité pair à pair des données de résultat générées par les clients 1) sont donnés par les FIG. 4 et 5. Le premier client 1A envoie une première 11 demande 10 de recherche des données au serveur 4. Le serveur stocke 11 la première demande 10 afin de faciliter la mise à disposition des données de résultat provenant du premier client demandeur lA au moyen de connexions pair à pair, comme expliqué en détail ci-dessous. Une recherche 16 des données demandées est exécutée par le serveur 4 dans par ex. la hase de données 5A pour les données demandées. Dans certains modes de réalisation, plus d'une hase de données 5 est interrogée par le serveur 4. Les données brutes obtenues par la recherche 12 sont reçues 14 et partiellement traitées par le serveur 4 puis envoyées 16 au premier client lA en réponse à la première demande 10 pour obtenir les données de résultat. [0052] Par ailleurs, et encore en référence à la FIG. 4, le décalage du traitement des données demandées vers le client lA inclus l'envoi des données de résultat par le premier client lA à un deuxième client 1B (message 20 à la FIG. 4). À cette fin, les données de résultat obtenues par le premier client lA à travers le traitement 18 sont stockées 19. Dans certains modes de réalisation, le premier client lA stocke 19 les données de résultat localement et est ainsi capable de renvoyer les données de résultat en réponse à toute demande provenant d'un autre client 1. Dans d'autres modes de réalisation, le premier client lA est un membre d'un réseau DHT (tables de hachage distribué, comme expliqué plus en détail ci-dessous) et stocke 19 les données de résultat dans le réseau DHT, typiquement au niveau d'un autre client du réseau DHT. [0053] Comme illustré à la FIG. 5, l'envoi des données de résultat provenant d'un premier client lA au deuxième client 1B peut survenir en réponse à une demande (la troisième demande 28) provenant du deuxième client 1B au premier client 1A demandant les données de résultat provenant du premier client lA au lieu de demander les données de résultat provenant du serveur 4 au moyen d'une première demande 10. Cela va au-delà des réseaux pair à pair habituels comme par ex. décrit par US 8,276,084 B2 et US 8,616,976 B2 où les données reçues du serveur à l'origine sont par ailleurs propagées parmi les pairs. Ces réseaux pair à pair habituels ne sont ainsi pas conçus pour mettre à la disposition d'autres clients les résultats du traitement côté client du premier client (et ainsi effectivement les ressources de calcul employées pour obtenir les données de résultat) - par rapport aux réseaux pair à pair habituels comme par ex. décrit par US 8,276,084 B2 et US 8,616,976 B2 - libérant les autres clients du traitement des données brutes à nouveau. [0054] Encore en référence à la FIG. 5, le deuxième client 1B a peut-être pris conscience du fait que les données de résultat demandées sont disponibles au niveau du premier client lA au moyen d'une deuxième demande 22 pour obtenir les données de résultat provenant du serveur 4. En réponse à la réception de la deuxième demande 22, le serveur recherche la première demande stockée (activité 11 dans les FIGS. 4 et 5) et détermine à partir de celle-ci que les données de résultat sont déjà disponibles au 12 niveau du premier client 1 A (comme le serveur 4 a précédemment renvoyé les données brutes correspondantes au premier client l A et est conscient que le premier client lA a généré puis stocké les données de résultat basées sur les données brutes renvoyées). Par conséquent, au lieu de récupérer à nouveau les données hrutes provenant d'une ou de plusieurs hases de données 5, d'exécuter le traitement partiel et de renvoyer les données hrutes au deuxième client 1B, le serveur 4 renvoie une indication 24 selon laquelle les données de résultat sont disponibles au niveau du premier client 1 A. En réponse à la réception de cette indication, le deuxième client 1B stocke 26 l'indication (afin de pouvoir encore informer les autres clients 1 du fait que les données de résultat sont disponibles au niveau du premier client 1B) et récupère les données de résultat provenant du premier client l A moyen d'une troisième demande 28 et de la réponse des données de résultat 20. [0055] Selon certains modes de réalisation, les clients 1 et le serveur 4 forment les noeuds d'un système informatique distribué en utilisant des tables de hachage distribué (DHT). Pour utiliser encore l'exemple susmentionné d'interrogation de hases de données relationnelles en utilisant les instructions SQL, des identifiants uniques constitués de chaînes de caractères alphanumériques et communément appelés clés, peuvent être calculés sur la hase des paramètres de recherche identifiant les données de résultat, par ex. les paramètres SQL à utiliser pour récupérer la vue « tableAB », comme présenté ci-dessus. Le calcul d'identifiants ou clés uniques peut être exécuté par tout client, par ex. au moyen d'une fonction de hachage sur les paramètres de la demande. Ces clés indiquent aux clients les autres clients 1 où les données de résultat correspondantes (par ex. la vue « table AB ») sont stockées (par ex. en employant un algorithme de partitionnement d'espace clé DHT), de sorte que tout autre client participant 1 puisse récupérer efficacement la vue associée à un identifiant unique donné provenant d'un autre client 1 au niveau duquel les données de résultat correspondantes sont stockées. Le client 1 au niveau duquel les données de résultat correspondantes sont stockées ne doit pas nécessairement être le même client au niveau duquel les données de résultat correspondantes ont été précédemment calculées. Les données de résultat ont peut-être été calculées par ex. au niveau du premier client 1A puis envoyées à un autre client 1 (par ex. le troisième client 1C) au niveau duquel les données de résultat ont finalement été stockées. [0056] Dans certains modes de réalisation, les indications envoyées 24 par le serveur 4 au deuxième client 1B et/ou les indications 32 envoyées par le deuxième client 1B au troisième client 1C, comme discuté plus en détail ci-dessous en référence à la FIG. 6, peuvent comprendre un ou plusieurs identifiants DHT uniques. [0057] Dans certains modes de réalisation, les clients 1 peuvent également former le système informatique distribué susmentionné en utilisant des tables de hachage distribué (DHT) 13 sans inclure le serveur. Cette configuration optionnelle supprime la charge de travail supplémentaire provenant du serveur. [0058] En faisant à nouveau référence à la transmission pair à pair de données de résultat provenant du premier client lA au deuxième client 1B comme discuté ci-dessus en référence aux FIG. 4 et 5, et en continuant à faire référence à l'exemple de mise en oeuvre de la FIG. 3 ci-dessus, le deuxième client 1B envoie la deuxième demande 22 au serveur 4 pour récupérer les mêmes données de résultat que le premier client lA qui dans le cas du présent exemple sont les données contenues dans la vue « tableAB ». Le serveur 4 informe 24 le deuxième client 1B que les données de résultat (« tableAB ») sont disponibles au niveau du premier client 1A. L'indication 24 peut comprendre une clé d'un système DHT, tandis que la clé a été calculée à partir de la vue « tableAB ». La vue « tableAB » peut être stockée dans le cache du premier client lA afin par cx. de faciliter la distribution de la vue « tableAB » parmi les clients. [0059] Le deuxième client 1B récupère ensuite les données de résultat (« tableAB ») provenant du premier client lA au moyen d'une troisième demande 28 pour obtenir les données de résultat. Ainsi, les ressources de traitement et de stockage du serveur 4 sont libérées, au-delà par cx. de US 2007/0005679 Al. La troisième demande 28 est similaire à la première demande 10 et à la deuxième demande 22, à l'exception qu'elle est dirigée vers le premier client lA par opposition au serveur 4. En d'autres termes, de la perspective du deuxième client 1B, le premier client lA agit comme un serveur répondant avec les données de résultat. Par rapport à la réponse de données de résultat de l'état de la technique antérieure présentée par la FIG. 2 comme discuté ci-dessus, cependant, le premier client 1A est capable de renvoyer les données de résultat demandées significativement plus vite et avec moins de ressources de calcul parce que les données de résultat (« tableAB ») sont disponibles et stockées au niveau du premier client lA dans un état déjà entièrement traité et aucune autre récupération ou traitement de base de données n'est requis. [0060] Comme option supplémentaire, dans certains modes de réalisation, les clients 1 parti- culièrement le premier client 1A, sont conçus non seulement pour stocker et mettre à disposition les données de résultat traitées en utilisant les données brutes reçues du serveur 4 mais également au moins une partie ou la totalité des données brutes elles-mêmes. En faisant à nouveau référence à l'exemple ci-dessus, le premier client 1A stocke les deux tables « tableA » et « tableB » en plus de la vue « tableAB ». Comme susmentionné, les données brutes sont soit stockées localement ou dans un réseau DHT (c.-à-d. typiquement au niveau d'un autre client qui est un membre du réseau DHT). En réponse à une demande de données brutes provenant d'un autre client (par ex. le deuxième client 1B), le premier client lA renvoi les données brutes demandées. Le fait que les données brutes soient stockées au niveau du premier client lA peut être 14 découvert par le deuxième client 1B de la même manière que celle déjà expliquée en détail ci-dessus pour les données de résultat. Grâce à cela, le serveur 4 est en plus libéré de la fourniture des données brutes dans des cas d'utilisation où les clients ne demandent pas les données de résultat exactes stockées au niveau d'un autre client (par ex. une vue « tahleAB-2 » étant différente de la vue « tableAB », même reproductible à partir des deux tables « tableA » et « tableB »), mais les différentes données de résultat qui peuvent être obtenues à partir des mêmes données brutes par le traitement côté client. [0061] En option, dans certains modes de réalisation, le premier client lA reçoit également une indication provenant du serveur 4 sur une durée de validité des données brutes renvoyées avec la réponse 16. Les données brutes renvoyées par le serveur 4 au premier client au moyen du message 20 (FIGS. 4 et 5) peuvent changer après un certain temps, invalidant ainsi les données de résultat générées 18 par le premier client lA basées sur les données brutes. Afin d'éviter la distribution de données de résultat périmées à d'autres clients 1 par le premier client 1 A, le serveur 4 peut fournir une indication de validité pour les données brutes. Comme illustré à titre d'exemple à la FIG. 4, cette indication de validité peut être incluse dans le message de réponse 16 transportant les données brutes en réponse à la première demande 10. En plus ou en variante, l'indication est transmise par le serveur 4 dans un message séparé au premier client lA après renvoi 16 des données brutes. Dans certains modes de réalisation, l'indication de validité peut également être mise à jour (par ex. si la validité des données brutes s'est avérée plus longue qu'indiquée par une première indication de validité au moment du renvoi 16 des données brutes). [0062] L'indication de validité indique un certain moment où les données brutes sont sus- ceptibles de changer et par conséquent aussi que les données de résultat générées par le premier client lA sur la base des données brutes ne sont plus valides. L'indication peut indiquer un moment absolu (par ex. 22 oct 2019, 15 h 00) ou un temps relatif faisant référence au moment du message de réponse 16. [0063] L'indication de validité est également stockée au niveau du serveur 4 et est facilitée à la fois par le premier client 1A et le serveur 4 afin d'éviter la distribution de données de résultat éventuellement périmées. Plus spécifiquement, comme illustré par la FIG. 4, le premier client lA supprime 36 les données de résultat à un moment donné (par ex. après réception du message de réponse 16 et le stockage des données de résultat) correspondant à la durée de validité indiquée par le serveur. Parallèlement, le serveur 4 supprime 34 la première demande stockée à un moment donné par ex. après le renvoi des données brutes correspondant à la durée de validité. De cette manière, le premier client lA est empêché de renvoyer les données de résultat à d'autres clients 1 et le serveur 4 être empêché de diriger d'autres clients 1 demandant les données de résultat au premier client lA (mais renverra les données brutes éventuellement mises à jour au prochain client demandeur 1). [0064] Dans certains modes de réalisation, les demandes de données 10 par le premier client lA sont envoyés à différents serveurs 4 en utilisant des moteurs de métarecherche. Les moteurs de métarecherche sont des outils de recherche qui utilisent les données récupérées par d'autres moteurs de recherche pour produire leurs propres résultats. Selon certains modes de réalisation, les moteurs de recherche prennent une entrée à partir d'un client et envoient simultanément des interrogations à des moteurs de recherche tiers de données brutes. Les données brutes pertinentes sont collectées, formatés par leurs rangs et présentées au client. [0065] Dans certains modes de réalisation, le premier client lA emploie un mode d'écoute et attend les mises à jour des données brutes envoyées par le serveur 4. Les mises à jour peuvent être déclenchées soit par un certain événement tel que le changement d'une quantité définie de données brutes sur le serveur 4 soit par un minuteur. En citant à nouveau l'exemple des bases de données relationnelles et les instructions SQL, le premier client lA peut être abonné à des mises à jour régulières des données de résultat telles que stockées dans la vue « tableAB », et recevra par conséquent du serveur 4 des mises à jour des vues « tableA » et « tableB ». Le premier client lA traite alors les vues mises à jour « tableA » et « tableB » pour obtenir une version mise à jour de la vue « tahleAB ». [0066] En référence à présent à la FIG. 6, dans certains modes de réalisation, le mécanisme comme discuté ci-dessus en référence aux FIGS. 4 et 5 inclut en plus, au niveau du deuxième client 1B, la réception 24 d'une quatrième demande 30 pour obtenir les données (le résultat provenant d'un troisième client 1C et, en réponse, l'envoi 32 de l'indication précédemment reçue par le serveur 4 (message 24 à la FIG. 5) selon laquelle les données de résultat sont disponibles au niveau du premier client lA au troisième client 1C. À cette fin, le deuxième client 1B a stocké 26 l'indication précédemment après la réception provenant du serveur 4. À nouveau, l'envoi de l'indication 25 peut comprendre une clé d'un système DHT, tandis que la clé a été calculée à partir de la vue « table/AB ». [0067] De manière similaire au deuxième client 1B à la FIG. 5, le troisième client IC est ensuite capable de récupérer les données de résultat provenant du premier client lA par ex. par la connexion pair à pair susmentionnée, au moyen d'une troisième demande 28 et de la réponse de données de résultat 20 (FIG. 6). [0068] Dans certains modes de réalisation, les données de résultat sont stockées dans le cache 107 de la machine informatique 100 du premier client 1A ou un autre système de stockage du premier client lA (non présenté à la FIG. 7), avant envoi 20 des données de résultat par le premier client lA au deuxième client 1B ou au troisième client 1C. 16 [0069] Dans certains modes de réalisation, de manière similaire à ce qui a déjà été exposé ci- dessus pour le serveur 4 l'envoi 20 des données brutes au premier client lA en réponse à la première demande 10, les données de résultat sont cryptées avant l'envoi 20 des données de résultat au deuxième client lA ou au troisième client 1C. Pour le processus de cryptagc, des techniques telles que le calcul multipartitc sécurisé (MPC) ou le chiffrement point à point peuvent être appliquées. [0070] Dans certains modes de réalisation, l'envoi 20 des données de résultat provenant du premier client lA au deuxième client 1B et/ou au troisième client 1C utilise des techniques de compression des données en utilisant, par exemple, des livres de codes réutilisables pour générer des données compressées dans un format zip, de manière similaire à celle expliquée ci-dessus. [0071] Il faut noter que, généralement, tout client 1 participant à un système représenté par la FIG. 1 peut être équipé des fonctions décrites ci-dessus pour le premier client lA (le traitement 18 côté client des données brutes pour générer les données de résultat, le stockage 19 des données de résultat générées, le renvoi 20 des données de résultat stockés à d'autres clients en réponse aux demandes 28 pour obtenir les données de résultat, la suppression 36 des données de résultat après expiration d'une durée de validité donnée), le deuxième client 1B (la réception 24 d'une indication du serveur 4 selon laquelle les données de résultat requises sont disponibles au niveau d'un autre client 1, le stockage 26 de l'indication 24, la demande 28 des données de résultat provenant de l'autre client, et la réponse 32 avec l'indication selon laquelle les données de résultat sont disponibles au niveau d'un autre client en réponse à la réception d'une demande 30 pour obtenir les données de résultat provenant encore d'un autre client) et pour le troisième client (la demande 30 des données de résultat provenant d'un autre client, la réception 32 de l'indication selon laquelle les données de résultat sont disponibles encore au niveau d'un autre client et la demande 28 des données de résultat provenant encore de cet autre client), en fonction de telles ou telles données de résultat disponibles au niveau de tel ou tel client à un moment donné. Pour libérer le serveur 4, les clients 1 peuvent par ex. être conçus pour demander d'abord les données de résultat provenant des autres clients 1 et le serveur 4 est requis uniquement dans le cas où aucun autre client connu n'a les données de résultat disponibles ou après un nombre donné de demandes infructueuses aux autres clients 1. [0072] Par ailleurs, les fonctions des divers rôles clients sont combinées dans certains modes de réalisation. Par exemple, un client 1 agissant comme deuxième client 1B peut également stocker 19 les données de résultat récupérés du premier client 1A, afin de rendre les données de résultat disponibles via le réseau pair à pair encore aux autres clients, en plus du stockage des données de résultat au niveau du premier client 1A. De cette manière, le deuxième client 1B agit également comme un premier client lA pour 17 ces données de résultat, et les mêmes données de résultat deviennent disponibles au niveau d'un nombre de clients 1, contribuant par ailleurs ainsi à libérer le serveur 4. [0073] La FIG. 7 est une représentation schématique du composant interne d'une machine informatique du serveur 4 ou des clients 1A, 1B, 1C. La machine informatique 100 inclut un ensemble d'instructions pour amener la machine informatique 100 à exécuter l'une quelconque des méthologies discutées dans les présentes lorsqu'elles sont exécutées par la machine informatique 100. La machine informatique 100 inclut au moins un processeur 101, une mémoire principale 106 et un dispositif d'interface réseau 103 qui communique avec chacun via un bus 104. En option, la machine informatique 100 peut par ailleurs inclure une mémoire statique 105 et une unité d'entraînement de disque. Un affichage vidéo, un dispositif d'entrée alphanumérique et un dispositif de commande de curseur peuvent être fournis comme exemples d'interface utilisateur 102. Le dispositif d'interface réseau 103 connaître la machine informatique 100 aux autres composants du système informatique distribué tels que les clients 1 A, 1B, 1C, le serveur 4 ou les bases de données 5. [0074] La machine informatique 100 héberge également le cache 107. Le cache 107 peut stocker les tables de hase de données reçues également dans un cache. Le cache 107 dans les présents modes de réalisation peut être composé de composants matériels et logiciels qui stockent les tables de hases de données, de sorte que les futures demandes de tables de hases de données peuvent être servies plus rapidement que sans mise en cache. Il peut y avoir des caches à base de matériel telles que des caches CPU, des caches GPU, des processeurs de signaux numériques et des caches associatifs de traduction d'adresse ainsi que des caches à base logicielle telles que des caches de page, des caches web (caches HTTP), etc. À la fois le serveur 4 et les clients 1 peuvent comprendre un cache 107. Le serveur 4 commence ensuite le traitement des données comme le décodage des tables de bases de données reçues, l'élimination d'erreurs résidant dans les tables de bases de données en supprimant par ex. les ensembles de données redondantes des tables de bases de données ou les ensembles de données avec des entrées manquantes. Par ailleurs, les tables de bases de données sont mises dans un format de données commun pour faciliter le traitement ultérieur. [0075] Dans l'ensemble, les présents modes de réalisation permettent une manipulation des données efficace dans des réseaux distribués avec des serveurs et des clients. Les serveurs sont libérés du traitement calcul-consommation d'énergie pour répondre aux demandes de données de clients en utilisant la puissance de calcul des clients. Les serveurs sont également libérés de la mise en mémoire cache des données de résultat étant donné que les données de résultat générées par les clients sont mises à disposition à travers un réseau pair à pair via les clients. Les serveurs conservent un journal sur telles ou telles données de résultat qui ont été demandées par tel ou tel client et, ainsi 18 sur telles ou telles données de résultat qui sont disponibles au niveau de tel ou tel client, et dirigent les clients demandant une donnée de résultat en particulier vers le client correspondant qui a les données de résultat disponibles. Les présents modes de réalisation facilitent également un mécanisme d'invalidité pour éviter la propagation de données de résultat éventuellement périmées via les clients. D'autres améliorations sont fournies en employant des mécanismes de compression et de cryptage. [0076] Un ensemble d'instructions exécutables par ordinateur (c.-à-d. un code de programme informatique), mettant en oeuvre l'une quelconque ou toutes les méthodologies décrites dans les présentes, réside entièrement, ou au moins partiellement, dans ou sur un support lisible par machine, par ex. la mémoire principale 106. La mémoire principale 106 héberge le code de programme informatique pour des entités fonctionnelles telles que le traitement de demandes de hases de données 108 qui inclut la fonctionnalité de recevoir et de traiter les demandes base de données et la fonctionnalité de traitement des données 109. Les instructions peuvent par ailleurs être transmises ou reçues comme un signal propagé via Internet par l'intermédiaire du dispositif d'interface réseau 103 ou via l'interface utilisateur 103. La communication dans la machine informatique s'exécute via le bus 104. Le fonctionnement de hase de la machine informatique 100 est contrôlé par un système d'exploitation qui se situe également dans la mémoire principale 106, le au moins un processeur 101 et/ou la mémoire statique 105. [0077] En général, les routines exécutées pour mettre en oeuvre les modes de réalisation, qu'elles soient mises en oeuvre comme partie d'un système d'exploitation ou d'une application spécifique, d'un composant, d'un programme, d'un objet, d'un module ou d'une séquence d'instructions ou même d'un sous-ensemble de ceux-ci, peuvent être désignées dans les présentes par « code de programme informatique » ou simplement code de programme ». Le code de programme comprend typiquement des instructions lisibles pal- ordinateur qui résident à divers moments dans divers dispositifs de mémoire et de stockage dans un ordinateur et qui, lorsqu'elles sont lues et exécutées par un ou plusieurs processeurs dans un ordinateur, amènent cet ordinateur à effectuer les opérations nécessaires pour exécuter les opérations et/ou les éléments mettant en oeuvre les divers aspects des modes de réalisation de l'invention. Les instructions de programme lisible par ordinateur pour effectuer les opérations des modes de réalisation de l'invention peuvent être, par exemple, un langage d'assemblage ou un code source ou un code objet écrit dans toute combinaison d'un ou de plusieurs langages de programmation. 19 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5]