Toute la technologie des consentements eKee consiste à être capable de partager des sous ensembles de données avec une granulartié infinie tout en laissant la requête dicter la structure. En bref, utiliser un langage de requêtage zero config.
\nCe qui signifie qu'eKee est constamment en train de compiler une requête JSON vers du SQL puis de re-traduire le résultat SQL vers la structure JSON. Or cette opération doit se faire en temps réel, rendant ses performances critiques.
\nRécemment, nous avons été confronté à un problème lors du passage Résultat SQL vers JSON : À partir d'environ 50Mo de donnée, la réponse pouvait mettre plus de 30 secondes à arriver.
\nDans cet article, nous allons vous présenter comment un changement d'algorithme a pu nous faire passer de 30s de traitement à moins de 200ms.
\nLe but de la transformation est de reconstruire des objets JSON à partir des résultats d'une requête SQL. Dans notre syntaxe, un objet JSON représente une entrée d'une table. Tous ses champs représentent soit des colonnes, soit des entrées de table en relation avec l'objet (la nouvelle table est un sous-objet)
\nDeux problématiques majeures sont rencontrées durant la transformation de résultats SQL en JSON :
\nUne première approche est de traiter ces points les uns après les autres. En commençant par construire une arborescence d'objet JSON pour chaque ligne du résultat puis en fusionnant les arborescences entre elles.
\nL'avantage de cette solution est sa simplicité, un algorithme récursif parcourant les arborescences permet de réduire le problème à la fusion d'un seul noeud de l'arbre. Il suffit alors de détecter les conflits de valeur entre deux objets et de définir une méthode de résolution de ces conflits (i.e. génération de tableaux contenant les deux valeurs).
\nMais, cette solution implique de construire un nombre incalculable d'objets intermédiaires qui seront supprimés pendant la fusion. Cette utilisation de la mémoire est très néfaste aux performances d'un programme écrit en go. Go reposant sur un garbage collector, allouer puis libérer des objets en grande quantité force le garbage collector à faire des poses plus longues et plus fréquentes.
\nDe plus, même si l'algorithme récursif est assez simple, son optimisation est limitée. Chaque fois qu'une arborescence est fusionnée avec le résultat, une détection de conflit doit être faite entre chaque noeud des deux arborescences. Ainsi, si un conflit génère un branchement dans l'arbre (un tableau), les futures comparaisons doivent être faites avec les deux branches de l'arbre.
\nCette solution a rapidement montré ses limites lors du traitement de résultat contenant de nombreux tableaux. Transformer plusieurs dixaines de Mo de lignes SQL peut prendre bien plus de 30 secondes. Il nous a donc fallut trouver une autre approche.
\nL'algorithme précédent passait la quasi totalité de son temps sur le parcours et la comparaison des objets issus des lignes SQL. Toute la problématique est donc de réussir à supprimer les parcours du JSON final et limiter au maximum la comparaison nécessaire lors de l'ajout d'éléments.
\nLa nouvelle solution explorée consiste à construire tous les objets dans un premier temps puis à les rattacher à leur parent. Plus aucun parcours d'arborescence n'est nécessaire. Par contre, cette solution repose sur la génération de clefs d'identification uniques pour chaque objet JSON. Cette solution n'est applicable que si les différents objets à fusionner sont constitués des mêmes colonnes. Dans le cas d'une réponse SQL, l'ensemble et l'ordre des colonnes sont fixés pour toutes les lignes résultantes. La deuxième solution est donc applicable.
\nL'ensemble du processus est réalisé en trois passages. Le premier construit les objets et leurs identifiants. Le deuxième itère sur les identifiants pour supprimer les duplicatas et enregistre les liens entre les objets (au moyen de leurs identifiants). Le dernier relie les objets finaux grâce aux métadonnées générées pendant la deuxième étape.
\ntype Route = string\ntype RowElement = {\n object: Object\n hash: Hash\n parentRoute: Route\n}\n\nobjects := map[Route]RowElement\n\n// Format SQL rows into JSON object\nfor col, value := range SQLrows {\n path := unalias(col)\n // path = "country.city.street.name"\n // Route: "country.city.street"\n // TableName: "street"\n // Column: "name"\n // ParentRoute: "country.city"\n // ParentName: "city"\n route, key := strings.splitLast(path,".")\n\n // build hash + add RowElement/field if needed\n objects.AddKeyToObject(route, key, val)\n}Pour rendre la construction du JSON réalisable, toutes les colonnes de la requête SQL ont été préalablement remplacées par un chemin vers l'endroit où les valeurs devront être utilisées dans le JSON final. Il est ainsi possible de tracer la position d'un champ mais également celle de l'objet possédant le champ, son objet parent, etc. Par contre le nombre de colonnes dans chaque objet est inconnu avant la fin du traitement. Les identifiants des objets générés pour une ligne ne peuvent être utilisés qu'après le traitement de toutes les colonnes de la ligne.
\nL'identifiant d'un objet est enrichi au fur et à mesure que des colonnes lui sont ajoutées. Les noms des champs sont omis durant la génération de l'identifiant pour limiter la taille de la donnée à traiter. L'association du chemin menant à l'objet et à ses valeurs garantit que deux objets provenant de tables différentes ne peuvent pas être confondus même s'ils sont constitués des mêmes valeurs. Comme certaines tables n'ont pas forcément de colonne sélectionnée, les appels à AddKeyToObject vont garantir que tous les objets sur la route du champ sont créés. Dans notre exemple (country.city.street.name), ajouter le champ name va créer des objets vides pour les routes country.city et country en plus d'ajouter un champ name à l'objet country.city.street Le point important de cette deuxième étape est la manière dont est gérée la table de hash. L'ordre d'arrivée des éléments doit être conservé pour que, en cas d'utilisation de ORDER BY dans la requête SQL, l'ordre des éléments dans le JSON soient bien triés. Les objets sont groupés en fonction de leur parentHash et parentTable puis l'ordre d'arrivée est utilisé. Le hash est donc uniquement utilisé pour vérifier l'égalité entre deux objets. ObjectsMap contient tous les objets JSON générés et AllElements les liens entre ces objets. Pendant cette dernière étape, il ne reste plus de calculs ou d'algorithmes complexes à appliquer. L'insertion des nouveaux éléments est peu intéressante mais néanmoins verbeuse, c'est pourquoi le code d'insertion est omis. Il faut créer ou non des tableaux si un élément est déjà présent dans le champ tableName. Passer de la première solution à la seconde nous a permis de considérablement réduire le temps d'exécution de certaines de nos requêtes. Précédemment, le traitement d'environ 50Mo de résultat SQL pouvait prendre plus de 30 secondes. Désormais, ce même traitement s'exécute constamment en moins de 200 millisecondes. Pour autant, l'implémentation présentée aujourd'hui reste naïve et largement optimisable. Parmis les optimisations les plus impactantes on peut penser à : Toutes ces optimisations et bien d'autres arriveront lorsque le besoin s'en fera sentir. Bien entendu, nous ne manquerons pas de vous les présenter ici !Suppression des duplicatas et création des liens entre les objets
\n
\ntype AllElements = map[TableName]HashList\n\n// Use generated hash to reduce the number of JSON objects\n// and link objects\nfor objRoute, obj := range objects {\n // Append to known json objects\n // permitting to use the same memory\n // for all equal objects (same structure & values)\n jsonObj, has := objectsMap.get(objRoute, obj.hash)\n if !has {\n objectsMap.put(objRoute, obj.hash, obj.object)\n }\n\n parent := objects[obj.parentRoute]\n\n // Inserting in the hash list, to remove duplicat objects\n // (Behaves like a hashset)\n // One hashset per table\n objHashList := allElements[objRoute]\n objHashList.Insert(Table{\n parentHash: parent.hash,\n parentTable: obj.parentRoute,\n hash: obj.hash,\n })\n}Construction de la représentation final
\n
\ntype ObjectsMap = map[Route][Hash]Object\n\n// Prepare the destination object for all the Table which\n// do not have a parent\nres = {}\nObjectsMap[""][""] = res\n\n// Link final objects together\nfor objectRoute, hashList := range allElements {\n hashMap := ObjectsMap[objectRoute]\n for _, el := range hashList {\n currentObj := hashMap[el.hash]\n parent := ObjectsMap[el.parentTable][el.parentHash]\n _, tableName := strings.splitLast(path,".")\n // Insert Or Append field if already present\n parent[tableName] = currentObj\n }\n}\n\n// return the only object whose route is ""\nfor _, res := range ObjectMap[""] {\n return []Object{res}\n}\n\n// return an empty array representing nothing found\nreturn []Object{}Résultats
\n\n
\n