Modélisation des données graphiques en fonction du temps

Question

J'ai une question sur la modélisation des données. Les données que j'ai sont essentiellement des nœuds avec des relations avec d'autres nœuds. Les nœuds ont des propriétés. Les arêtes sont directionnelles et ont des propriétés. Je cherche à savoir si une BD graphique comme Neo4j serait appropriée ou non.

Le doute vient du fait que : Les données que j'ai sont basées sur le temps. Elles changent en fonction du temps, et j'ai besoin de garder la trace des données historiques également. Par exemple, je devrais être capable de faire une requête :

1. Comment était le graphique à une date donnée ?
2. De qui dépendait un nœud donné à un moment donné ?
3. Quelles étaient les propriétés de l'arête entre deux nœuds donnés à un moment donné ?

J'ai cherché mais je n'ai pas trouvé de ressource satisfaisante où je pourrais comprendre comment le temps peut être pris en compte dans une BD graphique. Pensez-vous que mon besoin puisse être satisfait de manière inhérente en utilisant une BD graphique ? Existe-t-il un exemple/ressource/article qui décrit cela pour Neo4j ou tout autre BD graphique ?

Je veux m'assurer que la base de données est extensible à environ 100 000 nœuds et à des millions d'arêtes. J'optimise le temps par rapport à l'espace.

Answer 1

Existe-t-il un exemple/une ressource/un article qui décrit cela pour Neo4j ou tout autre base de données de graphes ?

Voici un excellent article du blog de Ian Robinson sur les graphiques versionnés dans le temps.

En gros, l'article décrit une façon de représenter un graphe versionné basé sur le temps en ajoutant quelques nœuds supplémentaires et des relations horodatées pour représenter l'état du graphe dans un horodatage donné.

L'image suivante, tirée de l'article référencé, le montre :

1. Le prix de produc_id : 1 est passé de 1,00 à 2,00. Il s'agit d'un changement d'état.
2. En product_id : 1 est maintenant vendu par shop_id : 2 (et non par shop_id : 1 ). Il s'agit d'un changement structurel.

Pensez-vous que mon besoin puisse être satisfait de manière inhérente en utilisant une BD graphique ?

Oui, mais pas d'une manière facile ou "naturelle". Le versionnement d'un modèle temporel avec une base de données qui n'offre pas cette fonctionnalité de manière native peut être difficile et coûteux. Extrait de l'article :

Neo4j ne fournit pas de support intrinsèque, que ce soit au niveau de son module modèle de graphe de propriétés étiquetées ou dans son langage de requête Cypher pour les versionnement. Par conséquent, pour versionner un graphe, nous devons faire de notre modèle de données du graphe de l'application et des requêtes.

et

le versioning crée nécessairement beaucoup plus de données - à la fois plus de nœuds et plus de relations. En outre, les requêtes auront tendance à être plus complexes, et plus lentes, car chaque MATCH doit tenir compte d'une ou plusieurs éléments versionnés. Compte tenu de ces frais généraux, il convient d'appliquer le versioning avec précaution. Peut-être que tout votre graphe n'a pas besoin d'être versionné. Si c'est le cas Si c'est le cas, ne versionnez que les parties du graphe qui le nécessitent.

EDITAR:

Quelques mots tirés du livre Graph Databases (de Ian Robinson, Jim Webber et Emil Eifrem) sur le versioning dans les bases de données graphiques. Ce livre est disponible pour le téléchargement à la page Neo4J :

Versioning : Un graphe versionné nous permet de récupérer l'état de la du graphe à un moment particulier dans le temps. La plupart des bases de données de graphes ne supportent pas le versioning comme un concept de première classe. C'est pourtant possible, de créer un schéma de versionnement à l'intérieur du modèle de graphe. Avec ce schéma les nœuds et les relations sont horodatés et archivés chaque fois qu'ils sont modifiés. modifiés. L'inconvénient de tels schémas de versionnement est qu'ils fuient dans toutes les requêtes écrites sur le graphe, ce qui ajoute une couche de complexité à la requête la plus simple.

Ce paragraphe fait le lien avec l'article indiqué au début de cette réponse.