MultiChain-feeder for integrering av databaser

Få data ut av blokkjeden og ut i den store verden

Med den første offentlige utgivelsen av MultiChain, helt tilbake i 2015, så vi interesse for blokkjedeapplikasjoner fra en overraskende retning. Mens vi opprinnelig hadde designet MultiChain for å muliggjøre utstedelse, overføring og lagring av digitale eiendeler, var et økende antall brukere interessert i å bruke den til dataorienterte applikasjoner.

I disse brukstilfellene er blokkjedens formål å muliggjøre lagring og gjenfinning av generell informasjon, som ikke trenger å være økonomisk. Motivasjonen for å bruke en blokkjede i stedet for en vanlig database er å unngå å stole på en pålitelig mellommann for å være vert for og vedlikeholde databasen. Av kommersielle, regulatoriske eller politiske årsaker ønsker databasens brukere at dette skal være et distribuert snarere enn et sentralisert ansvar.

Utviklingen av strømmer

Som svar på denne tilbakemeldingen har vi i 2016 introdusert MultiChain-strømmer, som gir en enkel abstraksjon for lagring, indeksering og gjenfinning av generelle data på en blokkjede. En kjede kan inneholde et hvilket som helst antall strømmer, som hver kan være begrenset for skriving av bestemte adresser. Hvert strømelement er merket med adressen til utgiveren i tillegg til en valgfri nøkkel for fremtidig henting. Hver node kan uavhengig bestemme om den skal abonnere på hver strøm, og indeksere elementene i sanntid for rask henting etter nøkkel, utgiver, tid, blokk eller posisjon. Strømmer var en umiddelbar hit blant MultiChains brukere og differensierte den sterkt fra andre blockchain-plattformer for bedrifter.

I 2017 ble strømmer utvidet for å støtte innfødt JSON- og Unicode-tekst, flere nøkler per vare og flere elementer per transaksjon. Denne siste endringen gjør at over 10,000 2018 individuelle dataelementer kan publiseres per sekund på avansert maskinvare. Så i XNUMX la vi sømløs støtte for data utenfor kjeden, der bare en hash av enkelte data publiseres på kjeden, og selve dataene leveres utenfor kjeden til noder som ønsker det. Og senere samme år ga vi ut MultiChain 2.0 Community med Smarte filtre, som lar tilpasset JavaScript-kode utføre vilkårlig validering av strømelementer.

I løpet av 2019 ble fokuset rettet mot MultiChain 2.0 Enterprise, den kommersielle versjonen av MultiChain for større kunder. Den første Enterprise-demo utnyttet data utenfor kjeden i strømmer for å tillate lesetillatelse, kryptert datalevering og selektiv henting og tømming av individuelle elementer. Som alltid er den underliggende kompleksiteten skjult bak et enkelt sett med APIer knyttet til tillatelser og strømelementer. Med strømmer har vårt mål konsekvent vært å hjelpe utviklere med å fokusere på applikasjonens data, og ikke bekymre deg for blokkjeden som kjører bak kulissene.

Databasedilemmaet

Ettersom MultiChain-strømmer har fortsatt å utvikle seg, har vi blitt møtt med et konstant dilemma. For å lese og analysere dataene i en strøm, bør MultiChain gå nedover veien til å bli en fullverdig database? Bør det tilby JSON-feltindeksering, optimalisert spørring og avansert rapportering? I så fall, hvilket databaseparadigme skal den bruke – relasjons (som MySQL eller SQL Server), NoSQL (MongoDB eller Cassandra), søk (Elastic eller Solr), tidsserier (InfluxDB) eller i minnet (SAP HANA)? Tross alt er det blockchain-brukstilfeller som passer til hver av disse tilnærmingene.

Et alternativ vi vurderte er å bruke en ekstern database som MultiChains primære datalager, i stedet for den nåværende kombinasjonen av innebygde LevelDB og binære filer. Denne strategien ble vedtatt av Kjedekjerne (avviklet), Postkjede (ikke offentlig ennå) og er tilgjengelig som et alternativ i Hyperledger Fabric. Men til slutt bestemte vi oss for denne tilnærmingen, på grunn av risikoen ved å være avhengig av en ekstern prosess. Du vil egentlig ikke at blokkjedenoden din skal fryse fordi den mistet databaseforbindelsen, eller fordi noen kjører en kompleks spørring på datalageret.

En annen faktor å vurdere er teknologi og integrasjonsagnostisisme. I et blokkjedenettverk som spenner over flere organisasjoner, vil hver deltaker ha sine egne preferanser angående databaseteknologi. De vil allerede ha applikasjoner, verktøy og arbeidsflyter bygget på plattformene som passer deres behov. Så ved å velge en bestemt database, eller til og med å tilby noen få alternativer, ville vi ende opp med å gjøre noen brukere misfornøyde. Akkurat som hver blockchain-deltaker kan kjøre noden sin på et bredt utvalg av Linux-smaker, bør de kunne integreres med sin valgte database.

Vi introduserer MultiChain Feeds

I dag er vi glade for å lansere vår tilnærming til databaseintegrasjon – MultiChain Feeds. En feed er en sanntids binær logg på disken over hendelsene knyttet til en eller flere blokkjedestrømmer, for lesing av eksterne prosesser. Vi tilbyr også åpen kildekode Multikjede mateadapter som kan lese en feed og automatisk replikere innholdet til en Postgres-, MySQL- eller MongoDB-database (eller flere samtidig). Adapteren er skrevet i Python og har en liberal lisens, slik at den enkelt kan modifiseres for å støtte flere databaser eller for å legge til datafiltrering og transformasjon. (Vi har også dokumentert feed filformat for de som ønsker å skrive en parser på et annet språk.)

En node trenger ikke abonnere på en strøm for å replikere hendelsene til en feed. Dette gjør at MultiChains innebygde strømindeksering kan omgås fullstendig, for å spare tid og diskplass. Feeder gjenspeiler også innhenting og rensing av data utenfor kjeden, og kan rapportere om ankomsten av nye blokker på kjeden. For å spare diskplass kan du kontrollere nøyaktig hvilke hendelser som skrives til en feed, og hvilke felt som registreres for hver av disse hendelsene. I tillegg roteres feedfiler daglig, og det er en enkel rensekommando for å fjerne filer etter behandling.

Hvorfor skrives MultiChain-feeder til disk, i stedet for å streames mellom prosesser eller over nettverket? Fordi vi vil at de skal fungere som en ultra-pålitelig replikeringslogg som er motstandsdyktig mot databasenedetid, systemkrasj, strømtap og lignende. Ved å bruke diskfiler kan vi garantere holdbarhet, og la måldatabasen oppdateres asynkront. Hvis denne databasen av en eller annen grunn blir overbelastet eller koblet fra, kan MultiChain fortsette å operere uten avbrudd, og databasen vil ta igjen når ting går tilbake til det normale.

Komme i gang med innmatinger

Innmatinger er integrert i den nyeste demoen/betaen til MultiChain Enterprise, som er tilgjengelig for nedlasting nå. Kom i gang ved å lese dokumentasjonen for Multikjede mateadapter, eller gjennomgå feed-relaterte APIer. Vi vil gjerne hør din tilbakemelding om denne funksjonen og hvordan vi kan utvide den i fremtiden.

Med utgivelsen av feeds er versjon 2.0 av MultiChain Enterprise nå fullført – se Last ned og installer side for en fullstendig sammenligning mellom Community- og Enterprise-utgavene. I løpet av de neste par månedene vil vi fullføre testingen og optimaliseringen, og forventer at den er klar for produksjon rundt slutten av Q1. I mellomtiden, for informasjon om MultiChain Enterprise-lisensiering eller priser, ikke nøl med komme i kontakt.

Legg inn kommentarer på Linkedin.

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