Bonjour, Habr!
Cette petite note est née lors de la discussion de l'article
«Monolithes distribués ...» , et comme le sujet nécessite une réflexion plus approfondie, j'ai décidé de la poster sur mon blog. L'auteur de l'article décrit en fait une base de données distribuée, prouvant que le journal des événements est la seule structure de stockage correcte qu'il contient. Les arguments sont approximativement les suivants:
- Étant donné que l'événement est toujours localisé dans l'espace / temps, il peut stocker toutes les données en lui-même (parfois sous la forme de liens vers des événements antérieurs), ce qui rend l'événement sérialisable, augmente la localité, réduit la connectivité, etc.
- Une fois qu'un événement se produit, il ne change plus (toutes les améliorations sont documentées par d'autres événements), ce qui réduit le trafic de réplication.
- Le format de stockage des événements peut être plus ou moins unifié et non lié à un domaine spécifique.
- Les journaux d'événements peuvent être relativement facilement divisés / fusionnés, vous pouvez stocker différents types d'événements sur différents nœuds, c'est-à-dire, essentiellement, nous parlons d'une base de données distribuée.
- Les événements sont ordonnés par le temps, et cette séquence reflète également une relation causale (l'événement actuel ne peut pas être référencé plus tard).
- Lors de l'enregistrement d'un événement, il n'est pas nécessaire de mettre à jour de manière transactionnelle d'autres données (en fait, c'est obligatoire, mais dans un nombre limité de cas, par exemple, le solde de l'abonné dans le système de facturation doit être instantanément pertinent, il est nécessaire de mettre à jour les compteurs de liens, etc.).
- Les rapports peuvent être créés directement à partir du journal des événements, sans avoir besoin de convertir les données sous une forme normalisée.
En ce qui concerne le dernier point, de nombreux tests de performances (y compris sur mon blog) montrent que sur du matériel moderne, le traitement d'un milliard d'événements (faits) avec un algorithme à passage unique avec une mémoire à court terme prend quelques minutes, ce qui est tout à fait acceptable pour les rapports. Et comme le traitement des événements de différents types qui ne sont pas connectés par des liens est facile à paralléliser - le temps de rapport peut être réduit à des dizaines de secondes, sans avoir à surcharger la normalisation des données / l'indexation / la collecte des statistiques / le débogage et les requêtes d'indication - comme c'est le cas dans les SGBDR classiques. Par conséquent, la création de rapports basés sur de telles données ne me fait pas peur. Cependant, considérez le problème plus largement.
Une application métier typique peut être représentée comme une chaîne de transformation de données:
"Entrée => modèle => sortie". Tout schéma de stockage est un compromis entre trois extrêmes:
- Nous stockons les données dans le format de sortie. C'est ainsi que fonctionnent différentes vitrines et OLAP, où le temps de réponse est important. Les inconvénients sont connus - demande de mémoire excessive et faible taux de mise à jour (généralement par lots).
- Nous stockons les données au format du modèle de domaine, simplifiant ainsi les algorithmes de calcul. Il y a beaucoup d'inconvénients - une double transformation des données est nécessaire (de l'entrée au modèle et du modèle à la sortie), les coûts de transaction augmentent, il est difficile de fournir un stockage distribué, changer le schéma coûte cher, etc. Cependant, c'est l'option la plus populaire.
- Nous stockons les données dans le format d'entrée (en fait, ce que l'auteur de l'article propose est un journal des événements). Dans ce cas, les coûts de transaction sont minimes, les données sont facilement divisées et fusionnées, un schéma de stockage simple, clair et stable. Profit! Certes, vous devez réapprendre à programmer.
En ce qui concerne mon domaine d'intérêt (systèmes d'information d'entreprise), un événement est un document principal et le livre de référence peut être considéré comme un événement antérieur. J'ai déjà décrit la structure des tableaux d'un ERP occidental typique dans l'article
«NoERP ou un nouveau look ...» , où j'ai proposé d'abolir une normalisation excessive des données (à l'exception des registres de résidus instantanés), et de réécrire la plupart des calculs / rapports en cycles à un seul passage dans lesquels les principaux seront directement traités. documents. Je ne répéterai pas les arguments, tout est énoncé dans l'article, mais le schéma que j'ai proposé a pratiquement coïncidé avec la thèse de l'auteur du premier article, à savoir que le journal des événements est les données. C'est bien quand quelqu'un d'autre pense dans ce sens.
Il est clair que cette approche semble être un pas en arrière par rapport aux SGBD intelligents modernes, mais dans le monde des highloid, vous devez parfois abandonner les outils populaires / abstraits / universels - au profit d'une programmation impérative brutale et efficace, qui, de plus, ne nécessite pas de licence coûteuse pour les nœuds. / kernels / users.
Je voudrais dire séparément sur la méthode d'organisation des relations dans le journal des événements - cela doit être bidirectionnel, c'est-à-dire que chaque événement doit stocker un compteur de référence pour lui-même. Cela est nécessaire pour la mise en œuvre d'algorithmes à passage unique - nous passons des anciens événements aux nouveaux, en même temps, mettons en cache chaque événement avec un nombre non nul de liens entrants en mémoire, et ne le supprimons du cache qu'après avoir traité tous les référents. La présence du compteur de référence réduit désagréablement les performances transactionnelles - par exemple, si le répertoire de contrepartie est utilisé dans chaque document, le compteur de référence dans la contrepartie doit être mis à jour chaque fois qu'un document est ajouté, parfois sur un nœud différent. Cependant, cet endroit peut être universellement optimisé, en évitant les transactions distribuées dans tous les autres cas.
En fait, au niveau de l'idée, c'est tout pour le moment, j'espère toujours un projet spécifique (par exemple, sur la base de reçus de caisse ou de factures), et, si cette opportunité se présente, je rendrai compte des résultats.