Le modèle relationnel a perdu son exclusivité
Les exigences relatives à la fonctionnalité et à la structure des bases de données (DB), qui sont le plus complètement mises en œuvre dans les systèmes relationnels, sont désormais sous la pression de nouvelles exigences.
Le premier problème est la faible efficacité des mégadonnées. Les sources du big data sont les réseaux sociaux, les systèmes de vidéosurveillance, les capteurs spatiaux, la facturation, etc. Une base de données relationnelle (RDB) fonctionne bien si le schéma de données est précisément défini à l'avance, avant de démarrer l'application. Mais le Big Data est intrinsèquement difficile à structurer au stade de la conception de la base de données. Ce n'est que lorsque l'information est collectée, progressivement, que sa structure est plus apparente.
La seconde - recherche, calcul des requêtes dans des RDB avec d'énormes tables - est une tâche de haute complexité algorithmique. L'utilisation de l'indexation et du hachage fonctionne bien dans les BDB plus ou moins statiques, qui sont largement remplis avant la mise en service du système. Et dans les conditions de l'arrivée rapide de nouvelles matrices de données en temps réel, les avantages de ces méthodes sont nivelés, car les frais généraux augmentent fortement.
Le troisième inconvénient du RDB découle des exigences strictes pour les circuits de données dans le cadre des "formes normales" canoniques. Le besoin d'un grand nombre d'une grande variété d'applications nécessite des efforts importants pour créer des modèles de données, et le niveau de compétence inégal des programmeurs et les délais serrés conduisent à des erreurs qui nécessitent des corrections et des modifications. Mais tout changement déjà «vivant», rempli de DBD («migration») est une tâche encore plus complexe et laborieuse, qui dans certains cas n'a pas d'autre solution, comme remplacer complètement l'ancienne base de données par une nouvelle.
La «beauté» et la rigueur du modèle relationnel implémenté en SQL, depuis 3 décennies, a ravi les programmeurs. Les "anciens" modèles: réseau ou hiérarchiques ont été presque oubliés. Oui, il n'y a presque pas de tels logiciels, à l'exception peut-être des IDMS «presque immortels» [1].
Au cours de la dernière décennie, un travail actif est en cours pour créer des systèmes alternatifs de gestion de bases de données (SGBD), qui sont simplement appelés - NoSQL. Selon ce concept, des systèmes très différents tombent désormais très différents les uns des autres. Fait intéressant, le «vieux» réseau et les modèles hiérarchiques ne sont pas inclus dans le concept de NoSQL! De bonnes critiques dans ce domaine peuvent être trouvées dans [2,3,4].
La catégorie NoSQL comprend les bases de données «graph» [5], qui sont abstraitement proches du modèle de réseau canonique CODASYL [6]. Comme son nom l'indique, ces systèmes sont deux ensembles non organisés - nœuds (sommets) et arêtes (arcs). Le principal avantage des bases de données réseau - la navigation est «déterminée» non pas au moment du traitement de la demande , comme dans le RDB, mais au moment de l' ajout de nouvelles données (pour les graphes - sommets et arêtes), c'est tout à fait vrai pour les systèmes de graphes. Mais la base de données graphique n'est pas structurée avant d'être remplie, contrairement à la base de données CODASYL.
Les autres classes de base de données NoSQL les plus populaires sont la «valeur-clé» (exemple - Redis [7]) et le «stockage de documents» (exemple - MongoDB [8]). Étant donné qu'un examen détaillé de ces systèmes n'est pas l'objet de cet article, il est important de noter uniquement les points suivants.
Les systèmes NoSQL, en règle générale, fonctionnent sur la base de systèmes de fichiers distribués qui offrent évolutivité et fiabilité [9]. Mais le problème mathématiquement résolu avec rigueur dans le cadre du modèle relationnel est l' intégrité et la cohérence de la base de données (à condition, bien sûr, que la conception professionnellement compétente du schéma normalisé) ne se pose pas du tout dans la plupart des systèmes NoSQL.
Au total, aujourd'hui, la situation est approximativement la suivante: 75% des bases de données sont relationnelles, NoSQL sous sa forme pure est utilisé dans des systèmes hautement spécialisés, et des combinaisons de divers modèles de bases de données sont utilisées dans des projets de réseau mondial très chargés: Google, Facebook, Instagram, WhatsApp et autres.
Bases de données relationnelles sans SQL
Outre les problèmes pratiques décrits ci-dessus, l'utilisation des RDB a récemment connu d'autres tendances importantes.
En plus de la «rigidité» parfois excessive du modèle relationnel, son principal inconvénient pratique (non théorique) est la complexité de la manipulation des données. La première option consiste à utiliser le pipeline d'opérations sur les ensembles - unification, intersection, filtrage, etc. en pratique, il n'est quasiment jamais utilisé, car il est associé à des dépenses de ressources colossales et ne se justifie que par un traitement "batch" d'ensembles de demandes du même type. La deuxième option - l'interpréteur SQL nécessite un professionnalisme élevé, une bonne connaissance de la théorie des ensembles, de la théorie des bases de données et une expérience pratique considérable.
La programmation orientée objet (POO) est devenue la norme, mais SQL est un langage déclaratif dont la grammaire ne correspond pas aux langages POO les plus courants (C ++, Java, JavaScript, Python). En conséquence, la solution pour «incorporer» des RDB (travaillant avec des requêtes SQL) basées sur des bibliothèques de classes appelées ORM (Object-Relational Mapping - Object-Relational Mapping (Transformation) [9]) a gagné en popularité.
L'utilisation de classes ORM permet au programmeur de se passer de SQL lors de l'utilisation de RDB. ORM génère automatiquement des requêtes SQL vers les RDB pour créer des tables et manipuler des données. La plupart des ORM ont des interfaces avec divers SGBD populaires - SQLite, MySQL, PostgreSQL et autres, ce qui donne un choix sans modifier le code du programme.
Il existe de nombreuses implémentations ORM, même plusieurs pour chaque langage de programmation. Ils sont tous similaires, donc, pour être précis, à l'avenir, par ORM, nous entendons la bibliothèque (package) correspondante de modèles de la classe Model du framework Django [10] dans le langage Python [11].
ORM est très "pratique" et les programmeurs ne pensent pas vraiment qu'en utilisant cette API, ils obtiennent non seulement les avantages du modèle relationnel, mais tous ses inconvénients. Par exemple, dans le code lui-même, vous ne pouvez pas remplacer les modèles de table - ajouter ou supprimer une colonne, ajouter une nouvelle table, etc. Pour effectuer la migration de la base de données, vous devez d'abord réécrire le code, puis «monter d'un étage plus haut», puis redémarrer le programme. Par conséquent, il est impossible de créer une application qui apporte les modifications les plus simples au schéma de données pendant le fonctionnement du programme sans modifier le programme lui-même.
La récupération de données dans ORM est implémentée à l'aide de chaînes de méthodes, par exemple, "objects.all ()", "objects.get (...)", "objects.filter (...)" dans Django. Simple, beau et pratique, mais la complexité algorithmique de l'exécution des requêtes SQL générées par ORM entraînera cela n'est pas visible à l'œil nu.
Lorsqu'une personne écrit une requête SQL, on suppose qu'elle pense et comprend le coût des ressources informatiques. L'ORM voile cette tâche.
Hypertable comme base de données nouvelle génération
Nous avons développé un nouveau concept, des méthodes et des moyens pratiques pour combiner les modèles de base de données relationnelle et de réseau avec les avantages de l'idée ORM - le rejet de l'utilisation de langages de requête spéciaux, ce qui nous a permis de créer un nouveau modèle de base de données et une nouvelle technologie.
Le concept clé est l' hypertable (GT) - c'est une base de données comme un ensemble de relations (tables) dans lesquelles sont utilisés:
- Attributs «relationnels» (domaines de données), dont les valeurs, comme dans le RDB, sont des champs avec des données auto-définies pour les colonnes de table correspondantes
- Attributs «réseau» (domaines de liens). Nous les appellerons ATS - attribut de type "lien"
Les valeurs des champs PBX dans les lignes de la table sont des références explicites à toutes les lignes de toutes les tables incluses dans l'hypertable.
Le concept d'hypertable introduit par nous n'a rien à voir avec le projet [13], qui a été écourté en 2016.
Il existe un prototype fonctionnel - un ensemble d'outils en Python - le système de gestion Hyper Table (HTMS), qui comprend les niveaux suivants (de haut en bas):
- L'éditeur hypertable HTed (client) est un service de support technologique implémenté en tant que site Web sur le framework Django, qui peut se connecter à n'importe quel serveur avec une hypertable indépendamment des applications (il est fonctionnellement proche de l'utilitaire PgAdmin pour PostgeSQL dans une certaine mesure);
- bibliothèque d'utilitaires et de classes de niveau logique - API pour créer une base de données et manipuler des données au niveau de la programmation d'application (en remplacement de l'ORM);
- bibliothèque d'utilitaires et de classes du niveau physique de travail avec la base de données, sur laquelle sont basés les utilitaires et les classes du niveau logique (comment l'API peut être utilisée par des programmeurs système expérimentés);
- Classe Cage, conçue pour créer une couche «virtuelle» d'accès à distance en cache aux fichiers de base de données côté client (application);
- Serveur de fichiers CageServer - logiciel qui fonctionne en mode multi-programme et multi-thread, implémente des fonctions pour l'accès à distance multi-utilisateurs aux fichiers sur un serveur en utilisant le protocole TCP.
En principe, au lieu de Cage, il est possible d'utiliser le sous-système de fichiers local habituel du système d'exploitation pour gérer les fichiers, et également utiliser l'API Cage et le logiciel CageServer comme un outil indépendant de HTMS pour implémenter l'accès aux fichiers distribués à distance sur tous les systèmes.
Dans les prochains articles, il est prévu de présenter aux lecteurs le système HTMS plus en détail.