Récemment, nous avons testé l'approche que nous appelons QDM lorsque nous travaillons avec de grandes quantités de données - des centaines de gigaoctets. Dans le cadre de cette tâche, nous avons traité 12 à 24 millions d'enregistrements et comparé les performances de la solution de quintet avec des fonctionnalités similaires dans des tableaux ordinaires.
Nous n'avons pas fait de nouvelles découvertes, mais avons confirmé les hypothèses que nous avions exprimées plus tôt: combien le concepteur universel entre les mains de la «théière» conditionnelle perd-il à une base de données configurée par des professionnels.
Nous savons également maintenant quoi faire dans une telle situation - la solution est assez simple et fiable, et nous avons de l'expérience dans l'organisation d'une solution de compromis pour des données arbitrairement volumineuses.
Lors de l'élaboration du système de rapprochement des rapports, nous avons dû télécharger les données de l'un des formulaires de déclaration, qui contiennent jusqu'à 24 millions d'enregistrements à chaque date de déclaration. Il devrait y avoir des données pour 7 ans de calculs quotidiens. Des volumes, franchement, pas pour un concepteur universel, mais pour un système hautement spécialisé, mais nous nous sommes déjà impliqués dans cette aventure et nous avons dû chercher une solution.
Les utilisateurs ne travaillent avec cet ensemble de données volumineux que dans une seule date de rapport. Par conséquent, dans le système de référence, tout cela est stocké dans un tableau partitionné par cette date. Les index des 26 champs de données restants ne sont pas utilisés pour ce formulaire.
La première chose que nous avons faite, bien sûr, a été de créer la structure de données souhaitée dans le constructeur et d'y charger plusieurs dates. Le téléchargement d'une des plus petites dates prend environ 14 heures, ce qui est inacceptablement long: 12,5 millions d'enregistrements avec 27 attributs, regroupés en un demi-milliard d'enregistrements provenant de 5 champs avec la construction de trois indices, dont deux sont composites.
La quantité totale de ces données sur le disque est légèrement supérieure à 18 Go.
Il convient de noter deux caractéristiques de ce formulaire:
- Il ne se prête presque pas à la normalisation, contrairement, par exemple, au formulaire 110, discuté dans une publication précédente
- Il n'utilise pas d'index sur les attributs des enregistrements - il est plus rentable pour l'utilisateur d'attendre une minute que de dépenser de l'argent sur des index
Cela peut être considéré comme le cas le plus radical que vous pouvez choisir pour la comparaison. Dans la plupart des cas, la différence entre le volume de données QDM et la base de données habituelle n'est pas si dramatique, ni même assez faible .
À titre de comparaison, les mêmes données chargées dans une table régulière dans une base de données relationnelle prennent 2,3 Go (8 fois moins) avec l'index par date, et leur chargement dure moins d'une demi-heure (28 fois plus rapide). Dans les deux cas, les données ont été insérées directement à partir du fichier par portions de 100 000 enregistrements, sans désactiver les index.
Gardant à l'esprit qu'il n'est pas pratique d'utiliser un constructeur pour de tels volumes de données, nous avons néanmoins effectué des tests de performances: pour différents cas, nous avons comparé le traitement en masse des enregistrements avec le constructeur et notre table non indexée. Nous devions déterminer la limite de la quantité de données pour laquelle nous utiliserons désormais une table régulière, et non notre constructeur.
Comme nous nous y attendions, travailler avec de petits ensembles de données, par exemple, sur un compte ou un client séparé, dans le constructeur semble assez confortable (temps de réponse en une seconde), contrairement à une table sans index, où vous devez attendre des minutes pour répondre. Dans le même temps, la tâche principale de l'application - l'échantillonnage de masse et l'agrégation de données dans différentes sections - peut prendre plusieurs fois plus de temps dans le concepteur.
Voici les résultats résumés des échantillons que nous avons faits pour un volume croissant de données agrégées:
Là où c'était possible, nous avons effectué plusieurs mesures, après avoir sélectionné des statistiques et sélectionné le nombre d'enregistrements par le masque de numéro de compte.
Le tableau et le graphique ci-dessous montrent que l'agrégation d'un ensemble complet de données en une journée prend beaucoup moins de temps que l'échantillonnage de plus de 5% des données à l'aide de l'indice. C'est pourquoi les optimiseurs de requêtes RDBMS ignorent l'index dans une telle situation, alors que le moteur de notre service est actuellement privé d'une telle opportunité.
Affichage graphique des mêmes résultats à l'aide d'une échelle logarithmique pour comparer le nombre d'ordres différents:
La vitesse du concepteur lors du traitement d'un ensemble de données complet est presque d'un ordre de grandeur inférieur à celui d'une table ordinaire, ce qui est tout à fait normal pour le concepteur - il est important d'éviter une dégradation des performances de type avalanche, et cet objectif a été atteint.
L'étude a montré que le nombre d'enregistrements dans la base de données n'a pratiquement aucun effet sur la vitesse de construction des pages, la navigation et les petits échantillons dans un modèle de données de quintet. Avec la quantité de données traitées jusqu'à 10000 enregistrements (et il s'agit de la sélection maximale de données associées pour une instance de toute entité commerciale dans le système d'information), vous pouvez facilement travailler avec une base de données de centaines de gigaoctets ou plus.
Ensuite, nous avons appris à notre plugin de table (décrit ici ) à appeler un connecteur vers une base de données arbitraire afin qu'il fonctionne de manière transparente avec le modèle de données de quintet et les tables traditionnelles.
Du point de vue de l'utilisateur, il ne se soucie pas de la source de données avec laquelle il travaille alors qu'il peut effectuer le travail important pour lui dans l'interface familière, en recevant ses rapports:
Nous allons maintenant retirer les énormes tables similaires restantes, qui dans notre base de données ne sont que deux douzaines sur des centaines, dans un stockage séparé afin de travailler avec elles confortablement.
Ainsi, nous pouvons utiliser le constructeur pour les petites et moyennes tables qui nécessitent une recherche intensive et une agrégation par des attributs arbitraires, et stocker de grands objets non indexés dans des tables traditionnelles plates, les appeler à partir d'un stockage tiers ou de bases de données spécialisées (Hadoop et autres NoSQL).
Le concepteur est le mieux adapté aux systèmes CRM et produits similaires, où l'utilisateur travaille avec un seul client, compte ou autre entité, et les fonctions analytiques sont déplacées vers un stockage spécialisé séparé.