Flux MultiChain pour l'intégration de bases de données

Extraire les données de la blockchain et les diffuser dans le monde

Avec la première version publique de MultiChain, en 2015, nous avons constaté un intérêt pour les applications blockchain dans une direction surprenante. Alors que nous avions initialement conçu MultiChain pour permettre l'émission, le transfert et la conservation d'actifs numériques, un nombre croissant d'utilisateurs étaient intéressés à l'utiliser pour des applications orientées données.

Dans ces cas d'utilisation, le but de la blockchain est de permettre le stockage et la récupération d'informations à usage général, qui n'ont pas besoin d'être de nature financière. La motivation d'utiliser une blockchain plutôt qu'une base de données ordinaire est d'éviter de compter sur un intermédiaire de confiance pour héberger et maintenir cette base de données. Pour des raisons commerciales, réglementaires ou politiques, les utilisateurs de la base de données souhaitent qu'il s'agisse d'une responsabilité distribuée plutôt que centralisée.

L'évolution des flux

En réponse à ce retour d'expérience, en 2016, nous introduit Les flux MultiChain, qui fournissent une abstraction simple pour le stockage, l'indexation et la récupération de données générales sur une blockchain. Une chaîne peut contenir n'importe quel nombre de flux, dont chacun peut être restreint à l'écriture par certaines adresses. Chaque élément de flux est balisé par l'adresse de son éditeur ainsi que par une clé facultative pour une récupération future. Chaque nœud peut décider indépendamment de s'abonner à chaque flux, en indexant ses éléments en temps réel pour une récupération rapide par clé, éditeur, heure, bloc ou position. Les flux ont été un succès instantané auprès des utilisateurs de MultiChain et l'ont fortement différencié des autres plates-formes de blockchain d'entreprise.

En 2017, les flux étaient prolongé pour prendre en charge le texte natif JSON et Unicode, plusieurs clés par élément et plusieurs éléments par transaction. Cette dernière modification permet à plus de 10,000 2018 éléments de données individuels d'être publiés par seconde sur du matériel haut de gamme. Puis en XNUMX, nous avons ajouté un support transparent pour données hors chaîne, dans lequel seul un hachage de certaines données est publié sur la chaîne, et les données elles-mêmes sont livrées hors chaîne aux nœuds qui le souhaitent. Et plus tard cette année-là, nous avons publié MultiChain 2.0 Community avec Filtres intelligents, permettant au code JavaScript personnalisé d'effectuer une validation arbitraire des éléments de flux.

En 2019, nous nous sommes concentrés sur MultiChain 2.0 Enterprise, la version commerciale de MultiChain pour les grands clients. La première Démo Entreprise exploité des données hors chaîne dans des flux pour permettre l'autorisation de lecture, la livraison de données cryptées et la récupération et la purge sélectives d'éléments individuels. Comme toujours, la complexité sous-jacente est cachée derrière un simple ensemble d'API relatives aux autorisations et aux éléments de flux. Avec les flux, notre objectif a toujours été d'aider les développeurs à se concentrer sur les données de leur application et à ne pas s'inquiéter de la blockchain fonctionnant dans les coulisses.

Le dilemme de la base de données

Alors que les flux MultiChain ont continué d'évoluer, nous avons été confrontés à un dilemme constant. Pour lire et analyser les données d'un flux, MultiChain devrait-il s'engager sur la voie de devenir une base de données à part entière? Doit-il offrir une indexation de champs JSON, des requêtes optimisées et des rapports avancés? Si tel est le cas, quel paradigme de base de données doit-il utiliser - relationnel (comme MySQL ou SQL Server), NoSQL (MongoDB ou Cassandra), recherche (Elastic ou Solr), séries temporelles (InfluxDB) ou en mémoire (SAP HANA)? Après tout, il existe des cas d'utilisation de la blockchain adaptés à chacune de ces approches.

Une option que nous avons envisagée consiste à utiliser une base de données externe comme magasin de données principal de MultiChain, au lieu de la combinaison actuelle de LevelDB incorporé et de fichiers binaires. Cette stratégie a été adoptée par Noyau de chaîne (abandonné), Postchain (pas encore public) et est disponible Comme une option dans Hyperledger Fabric. Mais finalement, nous avons décidé de ne pas adopter cette approche, en raison des risques de dépendre d'un processus externe. Vous ne voulez pas vraiment que votre nœud blockchain se fige parce qu'il a perdu sa connexion à la base de données ou parce que quelqu'un exécute une requête complexe sur son magasin de données.

Un autre facteur à considérer est l'agnosticisme de la technologie et de l'intégration. Dans un réseau blockchain couvrant plusieurs organisations, chaque participant aura ses propres préférences en matière de technologie de base de données. Ils disposeront déjà d'applications, d'outils et de workflows construits sur les plates-formes qui répondent à leurs besoins. Ainsi, en choisissant une base de données en particulier, ou même en offrant quelques options, nous finirions par rendre certains utilisateurs mécontents. Tout comme chaque participant à la blockchain peut exécuter son nœud sur une grande variété de saveurs Linux, il devrait pouvoir s'intégrer à la base de données de son choix.

Présentation des flux MultiChain

Aujourd'hui, nous sommes ravis de publier notre approche d'intégration de base de données - MultiChain Feeds. Un flux est un journal binaire sur disque en temps réel des événements relatifs à un ou plusieurs flux blockchain, pour lecture par des processus externes. Nous proposons également l'open source Adaptateur d'alimentation MultiChain qui peut lire un flux et répliquer automatiquement son contenu dans une base de données Postgres, MySQL ou MongoDB (ou plusieurs à la fois). L'adaptateur est écrit en Python et dispose d'une licence libérale, il peut donc être facilement modifié pour prendre en charge des bases de données supplémentaires ou pour ajouter un filtrage et une transformation de données. (Nous avons également documenté le format de fichier d'alimentation pour ceux qui veulent écrire un analyseur dans une autre langue.)

Un nœud n'a pas besoin de s'abonner à un flux pour répliquer ses événements dans un flux. Cela permet à l'indexation de flux intégrée de MultiChain d'être complètement contournée, pour gagner du temps et de l'espace disque. Les flux reflètent également la récupération et la purge des données hors chaîne, et peuvent signaler l'arrivée de nouveaux blocs sur la chaîne. Afin d'économiser de l'espace disque, vous pouvez contrôler exactement quels événements sont écrits dans un flux et quels champs sont enregistrés pour chacun de ces événements. De plus, les fichiers de flux sont tournés quotidiennement et il existe une simple commande de purge pour supprimer les fichiers après le traitement.

Pourquoi les flux MultiChain sont-ils écrits sur le disque, plutôt que diffusés entre les processus ou sur le réseau? Parce que nous voulons qu'ils servent de journal de réplication ultra-fiable qui résiste aux temps d'arrêt de la base de données, aux pannes du système, aux coupures de courant, etc. En utilisant des fichiers disque, nous pouvons garantir la durabilité et permettre à la base de données cible d'être mise à jour de manière asynchrone. Si, pour une raison quelconque, cette base de données est surchargée ou déconnectée, MultiChain peut continuer à fonctionner sans interruption, et la base de données se rattrapera une fois que les choses reviendront à la normale.

Premiers pas avec les flux

Les flux sont intégrés dans la dernière démo / bêta de MultiChain Enterprise, qui est disponible pour le téléchargement maintenant. Commencez par lire la documentation du Adaptateur d'alimentation MultiChain, ou en examinant le API liées au flux. Avec plaisir entendre vos commentaires sur cette fonctionnalité et comment nous pouvons l'étendre à l'avenir.

Avec la sortie des flux, la version 2.0 de MultiChain Enterprise est désormais complète - voir le Télécharger et installer page pour une comparaison complète entre les éditions Community et Enterprise. Au cours des prochains mois, nous terminerons ses tests et son optimisation et nous nous attendons à ce qu'il soit prêt pour la production vers la fin du premier trimestre. En attendant, pour plus d'informations sur les licences ou les tarifs MultiChain Enterprise, n'hésitez pas à entrez en contact.

Veuillez poster vos commentaires sur LinkedIn.

Source : https://www.multichain.com/blog/2020/02/multichain-feeds-for-database-integration/