Hasura. Architecture GraphQL à SQL Server haute performance

Bonjour, Habr! Je vous présente la traduction de l'article «Architecture d'un moteur GraphQL vers SQL performant» .

Il s'agit de la traduction d'un article sur sa structure interne et sur les optimisations et les solutions architecturales apportées par Hasura - un serveur GraphQL léger hautes performances, qui agit comme une couche entre votre application Web et la base de données PostgreSQL.

Il vous permet de générer un schéma GraphQL basé sur une base de données existante ou d'en créer une nouvelle. Il prend en charge les abonnements GraphQL de la boîte basés sur les déclencheurs Postgres, le contrôle d'accès dynamique, la génération automatique de jointures, résout le problème des demandes N + 1 (traitement par lots) et bien plus encore.


Vous pouvez utiliser des contraintes de clés étrangères dans PostgreSQL pour obtenir des données hiérarchiques dans une seule requête. Par exemple, vous pouvez exécuter cette requête afin d'obtenir les albums et leurs pistes correspondantes (si une clé étrangère est créée dans la table "piste" qui pointe vers la table "album")

{ album (where: {year: {_eq: 2018}}) { title tracks { id title } } } 

Comme vous l'avez peut-être deviné, vous pouvez demander des données de n'importe quelle profondeur. Cette API, combinée au contrôle d'accès, permet aux applications Web d'interroger les données de PostgreSQL sans écrire leur propre backend. Il est conçu pour répondre aux requêtes le plus rapidement possible, avoir une bande passante élevée, tout en économisant du temps processeur et de la consommation de mémoire sur le serveur. Nous parlerons des solutions architecturales qui nous ont permis d'y parvenir.

Cycle de vie de la demande

Une demande envoyée à Hasura passe par les étapes suivantes:

1. Réception de sessions : la demande tombe dans la passerelle, qui vérifie la clé (le cas échéant) et ajoute divers en-têtes, par exemple l'identifiant et le rôle d'utilisateur.
2. Analyse des demandes : Hasura reçoit la demande, analyse les en-têtes pour obtenir des informations sur l'utilisateur, crée GraphQL AST en fonction du corps de la demande.
3. Validation des demandes : une vérification est effectuée pour voir si la demande est sémantiquement correcte, puis les droits d'accès correspondant au rôle de l'utilisateur sont appliqués.
4. Exécution de la requête : la requête est convertie en SQL et envoyée à Postgres.
5. Génération de réponse : le résultat de la requête SQL est traité et envoyé au client (la passerelle peut utiliser gzip si nécessaire ).

Buts

Les exigences sont approximativement les suivantes:

1. La pile HTTP doit ajouter une surcharge minimale et être capable de gérer de nombreuses demandes simultanées pour un débit élevé.
2. Génération SQL rapide à partir d'une requête GraphQL.
3. La requête SQL générée doit être efficace pour Postgres.
4. Le résultat de la requête SQL doit être renvoyé de Postgres.

Traitement des requêtes GraphQL

Il existe plusieurs approches pour obtenir les données requises pour une requête GraphQL:

Résolveurs conventionnels

L'exécution de requêtes GraphQL implique généralement l'appel d'un résolveur pour chaque champ.
Dans l'exemple de requête, nous obtenons les albums sortis en 2018, puis pour chacun d'eux, nous demandons les pistes qui lui correspondent - un problème classique de requêtes N + 1. Le nombre de requêtes augmente de façon exponentielle avec l'augmentation de la profondeur des requêtes.

Les demandes faites par Postgres seront:

 SELECT id,title FROM album WHERE year = 2018; 

Cette demande nous renverra tous les albums. Supposons que le nombre d'albums retournés par la demande soit égal à N. Ensuite, pour chaque album, nous exécuterions la demande suivante:

 SELECT id,title FROM tracks WHERE album_id = <album-id> 

Au total, vous obtenez N + 1 requêtes pour obtenir toutes les données nécessaires.

Demandes groupées

Des outils tels que le chargeur de données sont conçus pour résoudre le problème des demandes N + 1 en utilisant le traitement par lots. Le nombre de requêtes SQL pour les données incorporées ne dépend plus de la taille de l'échantillon initial, car Maintenant, cela affecte le nombre de nœuds dans la requête GraphQL. Dans ce cas, 2 demandes à Postgres sont nécessaires pour obtenir les données requises:

Nous obtenons des albums:

 SELECT id,title FROM album WHERE year = 2018 

Nous obtenons les pistes pour les albums que nous avons reçus dans la demande précédente:

 SELECT id, title FROM tracks WHERE album_id IN {the list of album ids} 

Au total, 2 requêtes sont reçues. Nous avons évité d'exécuter des requêtes SQL sur les pistes de chaque album individuel; à la place, nous avons utilisé l'opérateur WHERE pour obtenir toutes les pistes nécessaires en une seule requête à la fois.

Se joint

Dataloader est conçu pour fonctionner avec différentes sources de données et ne permet pas d'exploiter les capacités d'une source particulière. Dans notre cas, Postgres est la seule source de données et, comme toutes les bases de données relationnelles, il offre la possibilité de collecter des données à partir de plusieurs tables avec une seule requête à l'aide de l'opérateur JOIN. Nous pouvons déterminer toutes les tables nécessaires à une requête GraphQL et générer une seule requête SQL à l'aide de JOIN pour obtenir toutes les données. Il s'avère que les données nécessaires à toute requête GraphQL peuvent être obtenues à l'aide d'une seule requête SQL. Ces données sont converties avant d'être envoyées au client.

Une telle demande:

 SELECT album.id as album_id, album.title as album_title, track.id as track_id, track.title as track_title FROM album LEFT OUTER JOIN track ON (album.id = track.album_id) WHERE album.year = 2018 

Nous renverra ces données:

 album_id, album_title, track_id, track_title 1, Album1, 1, track1 1, Album1, 2, track2 2, Album2, NULL, NULL 

Ensuite, il sera converti en JSON et envoyé au client:

 [ { "title" : "Album1", "tracks": [ {"id" : 1, "title": "track1"}, {"id" : 2, "title": "track2"} ] }, { "title" : "Album2", "tracks" : [] } ] 

Optimisation de la génération de réponse

Nous avons constaté que la plupart du temps dans le traitement des requêtes est consacré à la fonction de conversion du résultat d'une requête SQL en JSON.

Après plusieurs tentatives d'optimisation de cette fonction de différentes manières, nous avons décidé de la transférer vers Postgres. Postgres 9.4 ( sorti à l'époque de la première version de Hasura ) a ajouté une fonction d'agrégation JSON qui nous a aidés à faire ce que nous voulions. Après cette optimisation, les requêtes SQL ont commencé à ressembler à ceci:

 SELECT json_agg(r.*) FROM ( SELECT album.title as title, json_agg(track.*) as tracks FROM album LEFT OUTER JOIN track ON (album.id = track.album_id) WHERE album.year = 2018 GROUP BY album.id ) r 

Le résultat de cette requête aura une colonne et une ligne, et cette valeur sera envoyée au client sans autre conversion. Selon nos tests, cette approche est environ 3 à 6 fois plus rapide que la fonction de conversion Haskell.

Déclarations préparées

Les requêtes SQL générées peuvent être assez volumineuses et complexes selon le niveau d'imbrication de la requête et les conditions d'utilisation. En règle générale, les applications Web ont un ensemble de requêtes qui sont exécutées à plusieurs reprises avec différents paramètres. Par exemple, la requête précédente doit être exécutée pour 2017, au lieu de 2018. Les instructions préparées conviennent mieux aux cas où il existe une requête SQL complexe répétitive dans laquelle seuls les paramètres sont modifiés.

Disons que cette requête est exécutée pour la première fois:

 { album (where: {year: {_eq: 2018}}) { title tracks { id title } } } 

Nous créons une instruction préparée pour la requête SQL au lieu de l'exécuter:

 PREPARE prep_1 AS SELECT json_agg(r.*) FROM ( SELECT album.title as title, json_agg(track.*) as tracks FROM album LEFT OUTER JOIN track ON (album.id = track.album_id) WHERE album.year = $1 GROUP BY album. 

Après quoi nous l'exécutons immédiatement:

 EXECUTE prep_1('2018'); 

Lorsque vous devez exécuter la requête GraphQL pour 2017, nous appelons simplement la même instruction préparée avec un argument différent:

 EXECUTE prep_1('2017'); 

Cela donne une augmentation de vitesse d'environ 10 à 20% en fonction de la complexité de la requête GraphQL.

Haskell

Haskell fonctionne bien pour plusieurs raisons:

• Langage compilé avec d'excellentes performances ( plus de détails ici ).
• Pile HTTP très efficace ( warp , architecture de warp ).
• Notre expérience linguistique précédente.

En fin de compte

Toutes les optimisations mentionnées ci-dessus entraînent des avantages de performance assez sérieux:



En fait, la faible consommation de mémoire et les retards insignifiants par rapport aux appels directs à PostgreSQL permettent dans la plupart des cas de remplacer les ORM dans votre backend par des appels API GraphQL.

Repères:

Banc d'essai:

1. Ordinateur portable avec 8 Go de RAM et i7
2. Postgres s'exécutant sur le même ordinateur
3. wrk , a été utilisé comme outil de comparaison et pour divers types de demandes, nous avons essayé de "maximiser" les rps
4. Une instance de Hasura GraphQL Engine
5. Taille du pool de connexions: 50
6. Jeu de données : chinook

Demande 1: tracks_media_some

 query tracks_media_some { tracks (where: {composer: {_eq: "Kurt Cobain"}}){ id name album { id title } media_type { name } }} 

• Demandes par seconde: 1375 req / s
• Retard: 17,5 ms
• CPU: ~ 30%
• RAM: ~ 30 Mo (Hasura) + 90 Mo (Postgres)

Demande 2: tracks_media_all

 query tracks_media_all { tracks { id name media_type { name } }} 

• Demandes par seconde: 410 req / s
• Retard: 59 ms
• CPU: ~ 100%
• RAM: ~ 30 Mo (Hasura) + 130 Mo (Postgres)

Demande 3: album_tracks_genre_some

 query albums_tracks_genre_some { albums (where: {artist_id: {_eq: 127}}) { id title tracks { id name genre { name } } }} 

• Demandes par seconde: 1029 req / s
• Retard: 24 ms
• CPU: ~ 30%
• RAM: ~ 30 Mo (Hasura) + 90 Mo (Postgres)

Demande 4: album_tracks_genre_all

 query albums_tracks_genre_all { albums { id title tracks { id name genre { name } } } 

• Demandes par seconde: 328 req / s
• Retard: 73 ms
• CPU: 100%
• RAM: ~ 30 Mo (Hasura) + 130 Mo (Postgres)