Stratégie de stockage des données
L'état actuel de la technologie informatique est qu'il est possible de stocker des quantités presque infinies de données. En conséquence, la nécessité de supprimer des données afin de libérer de l'espace pour de nouvelles est pratiquement éliminée.
Cela donne beaucoup d'avantages, à partir de la relation naturelle des données et des objets qu'ils décrivent, car il existe des lois de conservation dans la nature, la même chose devrait s'appliquer aux données qui reflètent des objets naturels, et se terminant à l'exception des problèmes purement technologiques liés à l'intégrité des données dans le temps.
Ainsi, la stratégie de stockage doit être basée sur le paradigme de suppression «douce», qui consiste à marquer les données comme ayant perdu leur pertinence à partir d'un certain moment.
La même chose s'applique exactement aux changements de données. Les mises à jour ne doivent pas écraser les données précédentes, mais indiquent que, à partir d'un certain moment, les données ont des significations différentes.
Si vous voulez vraiment libérer de l'espace en effaçant les stockages des données inutilisées, vous pouvez appliquer la stratégie de compression des stockages en en faisant une copie en écrasant uniquement les données pertinentes à un moment donné dans le passé.
Ces considérations ne sont pas nouvelles, car elles sont déjà implémentées dans des entrepôts de Big Data comme Hadoop.
Format de stockage des données
Les données reflétant certaines entités sont, en règle générale, un ensemble d'attributs dont la composition reflète les caractéristiques nécessaires de l'entité. Pour simplifier, nous supposons que nous parlons d'un modèle relationnel composé de tuples.
Ainsi, les données sont stockées sous la forme de tuples d'un certain type, qui au fil du temps peuvent changer et perdre de leur pertinence.
Nous voulons également dire que les magasins de Big Data modernes ont souvent une structure clé-valeur avec un index primaire sur la clé et des index facultatifs possibles sur d'autres attributs.
Compte tenu de ces considérations, le format de stockage de données suivant est proposé.
Je voudrais tout de suite noter que ce format n'est pas unique, mais inspiré par la structure de stockage des données dans les objets 1C sous le nom de «Register». Mais dans cette évolution, il est proposé de rendre le format universel et d'y stocker toutes les données.
Nous proposons donc un format d'enregistrement des données sur les entités et leurs attributs, basé sur le concept d'un workflow basé sur les définitions suivantes:
- Une opération est un changement atomique dans une entité de données.
- Une entité se compose d'attributs.
- Une entité a un type qui détermine la composition de ses attributs.
- Les entités du même type sont stockées dans un seul thread.
- Workflow - un objet de stockage de la table de types où se trouvent les opérations liées aux entités du même type et modifiant leur état.
En conséquence, chaque opération se compose d'un en-tête d'opération et d'un ensemble d'attributs qui dépendent du type d'entité:
- OpID - identifiant unique de l'opération
- OpTS - horodatage de l'opération
- OpType - type d'opération
- OpClass - nom du flux
- OpUser - utilisateur du système qui a émis la commande
- OpDoc - document d'opération, c'est-à-dire que le document qui l'a créé peut ne pas être installé
- OpComment - commentaire d'opération
- ID - identifiant de l'entité à laquelle l'opération se rapporte
- Paramètres - attributs d'opération dépendant du flux
Les OpID et ID peuvent être n'importe quoi, mais pour l'instant, il peut être judicieux d'utiliser un UID.
OpTS devrait très probablement être de type horodatage, mais complété par un index ordinal, si plusieurs opérations se situent dans la même période pour garantir un ordre de fonctionnement unique.
OpType peut être de n'importe quel type, par exemple, un / plusieurs caractères ou un nombre.
OpClass, OpUser et OpComment peuvent être soit une chaîne soit une référence à un répertoire.
OpDoc fournit un lien vers le document, mais peut être absent. Ceci est une connexion avec le niveau supérieur.
Les opérations sont divisées en services de base et services.
Opérations de base
Opérations de base 3 - ajouter, mettre à jour, supprimer:
- L'opération «A» add - indique l'instanciation d'une nouvelle entité d'un certain type et définit un ensemble d'attributs.
- Mise à jour de l'opération "U" - détecte un changement dans une entité d'un certain type et définit de nouvelles valeurs pour un ensemble spécifique d'attributs.
- Suppression de l'opération «D» - indique la fin de la réalité d'une entité d'un certain type.
Les opérations A et U peuvent définir non pas tous les attributs, mais seulement certains. Les attributs qui ne sont pas définis par cette opération peuvent avoir une valeur de type NULL, ou une autre valeur spéciale, qui pour le moment n'est pas encore disponible, mais ce serait bien de les créer.
Par conséquent, la valeur réelle des attributs de l'entité à un moment donné nécessite leur calcul en effectuant une recherche en arrière, en sélectionnant tous les attributs qui diffèrent de la valeur spéciale (non définie).
Lors de l'émission de l'opération U, le système doit vérifier la présence de l'opération A pour cette entité et, s'il est absent, changer le type d'opération en A.
L'opération D ferme l'existence d'une certaine entité, et lors de la demande de valeurs d'attribut pour cette entité avec un point de pertinence après cette opération, les valeurs «non définies» doivent être renvoyées pour tous les attributs de cette entité. Lors de l'émission de l'opération D, le système doit vérifier la présence de l'opération A pour cette entité et, s'il est absent, refuser de sauvegarder la commande D.
En tant que fonctionnalité supplémentaire, cette structure d'opérations vous permet d'organiser le stockage d'une entité avec le même ID avec différents attributs à différents moments dans le temps, non seulement en fonction des attributs, mais également sur l'entité entière. Autrement dit, nous pouvons avoir plusieurs blocs AN * UD dans lesquels l'entité existe, et entre D et A, elle n'existe pas.
Opérations de service
Les opérations de service peuvent être nombreuses et leur composition peut être reconstituée. À titre d'exemple, plusieurs considérations peuvent être faites:
- L'opération "N" est une opération non valide - cette opération doit être ignorée par le système. Vous pouvez remplacer d'autres types d'opérations par N pour les exclure du travail.
- Cache "C" de l'opération - cette opération peut être créée avec une certaine fréquence et stocker les valeurs d'attribut à un moment précis afin de réduire le coût de la recherche approfondie des valeurs d'attribut. Les détails des paramètres d'opération peuvent être stockés, par exemple, dans un commentaire ou dans le code d'opération lui-même. Bien sûr, lors de l'application des opérations de base, les opérations de type C doivent être recalculées ou remplacées par N.
- Opérations Opérations de groupe «S» - cette opération peut être créée avec une certaine fréquence et stocker des valeurs de groupe (par exemple, sommes, moyennes, etc.) d'attributs de types numériques pendant une certaine période. Les détails des paramètres d'opération peuvent être stockés, par exemple, dans un commentaire ou dans le code d'opération lui-même. Bien sûr, lors de l'application des opérations de base, les opérations de type S doivent être recalculées ou remplacées par N.
- Attributs de groupe de l'opération «G» - cette opération peut être similaire à U, mais en même temps, certaines commandes système émettront non pas une ou plusieurs valeurs d'attribut, mais plusieurs. Une valeur d'attribut par opération A / U, les valeurs restantes - sur l'opération G, qui sont situées entre des A / U adjacentes.
Les opérations de service sont facultatives, mais elles peuvent fournir un service supplémentaire au système de stockage et améliorer ses performances. Leur composition peut être différente pour différents systèmes.