MultiChain feedek az adatbázis-integrációhoz

Adatok kijuttatása a blokkláncból a nagyvilágba

A MultiChain első nyilvános kiadásával, jóval 2015-ben, meglepő irányból láttuk az érdeklődést a blokklánc-alkalmazások iránt. Míg eredetileg a MultiChaint úgy terveztük, hogy lehetővé tegye a digitális eszközök kibocsátását, átvitelét és őrzését, egyre több felhasználó érdeklődött az adatorientált alkalmazások iránt.

Ezekben a felhasználási esetekben a blokklánc célja általános célú információk tárolásának és visszakeresésének lehetővé tétele, amelyeknek nem kell pénzügyi természetűeknek lenniük. A rendszeres adatbázis helyett a blokklánc használatának motivációja az, hogy elkerüljük, hogy megbízható közvetítőre támaszkodjunk az adatbázis hosztolására és karbantartására. Kereskedelmi, szabályozási vagy politikai okokból az adatbázis felhasználói azt akarják, hogy ez inkább elosztott, mintsem központosított felelősség legyen.

A folyamok evolúciója

Erre a visszajelzésre reagálva 2016 Bevezetett MultiChain folyamok, amelyek egyszerű absztrakciót biztosítanak a blokkláncon lévő általános adatok tárolására, indexelésére és lekérésére. Egy lánc tetszőleges számú adatfolyamot tartalmazhat, amelyek mindegyike korlátozható bizonyos címekkel. Minden adatfolyam-elem meg van címkézve a kiadójának címével, valamint egy opcionális kulccsal a jövőbeni visszakereséshez. Mindegyik csomópont önállóan dönthet arról, hogy előfizet-e az egyes adatfolyamokra, valós időben indexelve elemeit a kulcs, kiadó, idő, blokk vagy pozíció szerinti gyors visszakeresés érdekében. A streamek azonnali sikert arattak a MultiChain felhasználói körében, és erősen megkülönböztették a többi vállalati blokklánc platformtól.

2017-ben streamek voltak kiterjedt a natív JSON és Unicode szöveg támogatásához, tételenként több kulcs és tranzakciónként több elem. Ez az utolsó változtatás több mint 10,000 2018 egyedi adatelem közzétételét teszi lehetővé másodpercenként csúcskategóriás hardveren. Aztán XNUMX-ban zökkenőmentes támogatást adtunk hozzá láncon kívüli adatok, amelyben bizonyos adatoknak csak egy hash-je kerül közzétételre a láncon, és magát az adatot a láncon kívül szállítják a csomópontokhoz, akik ezt szeretnék. Még abban az évben kiadtuk a MultiChain 2.0 Community-t Intelligens szűrők, lehetővé téve az egyéni JavaScript-kódnak az adatfolyamelemek tetszőleges érvényesítését.

2019-ben fókuszunk a MultiChain 2.0 Enterprise, a MultiChain nagyobb ügyfelek számára készült kereskedelmi verziója felé fordult. Az első Vállalati bemutató a láncon kívüli adatokat folyamokban kihasználva lehetővé teszi az olvasási engedélyt, a titkosított adatszolgáltatást, valamint az egyes elemek szelektív visszakeresését és törlését. Mint mindig, a mögöttes összetettség az engedélyekhez és adatfolyamelemekhez kapcsolódó API-k egyszerű halmaza mögött rejtőzik. A streamekkel folyamatosan az volt a célunk, hogy segítsük a fejlesztőket, hogy az alkalmazásuk adataira összpontosítsanak, és ne aggódjanak a színfalak mögött futó blokklánc miatt.

Az adatbázis dilemma

Ahogy a MultiChain adatfolyamok tovább fejlődtek, állandó dilemmával kellett szembenéznünk. Az adatok adatfolyamban történő olvasásához és elemzéséhez a MultiChainnek meg kell-e mennie a teljes értékű adatbázissá válás útján? JSON-mezőindexelést, optimalizált lekérdezést és speciális jelentéskészítést kell kínálnia? Ha igen, melyik adatbázis-paradigmát kell használnia – relációs (mint például MySQL vagy SQL Server), NoSQL (MongoDB vagy Cassandra), keresési (Elastic vagy Solr), idősoros (InfluxDB) vagy memórián belüli (SAP HANA)? Végül is vannak blokklánc-használati esetek, amelyek megfelelnek ezeknek a megközelítéseknek.

Az egyik lehetőség, hogy egy külső adatbázist használjunk a MultiChain elsődleges adattárolójaként a beágyazott LevelDB és bináris fájlok jelenlegi kombinációja helyett. Ezt a stratégiát fogadta el Láncmag (megszakított), Postchain (még nem publikus), és elérhető opcióként Hyperledger Fabric-ben. De végül úgy döntöttünk, hogy nem ezt a megközelítést, mert fennáll annak a kockázata, hogy egy külső folyamattól függünk. Nem igazán szeretné, hogy a blokklánc csomópont lefagyjon, mert elvesztette az adatbázis-kapcsolatát, vagy mert valaki összetett lekérdezést futtat az adattárában.

Egy másik figyelembe veendő tényező a technológia és az integrációs agnoszticizmus. Egy több szervezetet átfogó blokklánc-hálózatban minden résztvevőnek megvannak a saját preferenciái az adatbázis-technológiát illetően. A platformokra már az igényeiknek megfelelő alkalmazásokkal, eszközökkel és munkafolyamatokkal rendelkeznek. Így egy adott adatbázis kiválasztásával vagy akár néhány lehetőség felajánlásával néhány felhasználót boldogtalanná tennénk. Ahogyan a blokklánc minden résztvevője számos Linux-változaton futtathatja a csomópontját, képesnek kell lennie arra, hogy integrálódjon a választott adatbázisába.

Bemutatjuk a MultiChain feedeket

A mai napon nagy örömünkre kiadjuk az adatbázis-integrációs megközelítésünket – a MultiChain Feeds-et. A feed az egy vagy több blokklánc-folyamhoz kapcsolódó események valós idejű bináris naplója, amelyet külső folyamatok olvasnak. Nyílt forráskódot is kínálunk MultiChain Feed Adapter amely képes beolvasni egy hírfolyamot és automatikusan replikálni a tartalmát egy Postgres, MySQL vagy MongoDB adatbázisba (vagy több egyszerre). Az adapter Python nyelven íródott, és liberális licenccel rendelkezik, így könnyen módosítható további adatbázisok támogatására vagy adatszűrés és -átalakítás hozzáadására. (Azt is dokumentáltuk feed fájlformátum azoknak, akik más nyelven szeretnének elemzőt írni.)

A csomópontnak nem kell előfizetnie egy adatfolyamra ahhoz, hogy eseményeit egy hírfolyamban replikálja. Ez lehetővé teszi a MultiChain beépített adatfolyam-indexelésének teljes megkerülését, így időt és lemezterületet takarít meg. A hírcsatornák a láncon kívüli adatok lekérését és törlését is tükrözik, és jelentést készíthetnek az új blokkok érkezéséről a láncon. A lemezterület megtakarítása érdekében pontosan szabályozhatja, hogy mely eseményeket írjon egy feedbe, és mely mezőket rögzíti az egyes eseményekhez. Ezenkívül a feedfájlokat naponta forgatják, és van egy egyszerű törlési parancs a fájlok eltávolításához a feldolgozás után.

Miért írják a MultiChain feedeket lemezre, nem pedig a folyamatok között vagy a hálózaton keresztül? Mert azt akarjuk, hogy rendkívül megbízható replikációs naplóként szolgáljanak, amely ellenáll az adatbázis-leállásoknak, a rendszer összeomlásának, az áramkimaradásnak és hasonlóknak. A lemezfájlok használatával garantálhatjuk a tartósságot, és lehetővé tesszük a céladatbázis aszinkron frissítését. Ha ez az adatbázis valamilyen okból túlterhelődik vagy megszakad, a MultiChain megszakítás nélkül folytathatja a működését, és az adatbázis utoléri, amint a dolgok rendbe jönnek.

Ismerkedés a hírcsatornákkal

A hírcsatornák a MultiChain Enterprise legújabb demó-/bétaverziójába vannak integrálva letölthető Most. Kezdje azzal, hogy elolvassa a dokumentációt MultiChain Feed Adapter, vagy felülvizsgálja a feedhez kapcsolódó API-k. Szeretnénk hallgassa meg visszajelzését erről a funkcióról, és arról, hogyan bővíthetjük azt a jövőben.

A hírcsatornák megjelenésével a MultiChain Enterprise 2.0-s verziója immár teljessé vált – lásd a Letöltése és telepítése oldal a közösségi és a vállalati kiadások teljes összehasonlításához. A következő néhány hónapban befejezzük a tesztelést és az optimalizálást, és várhatóan az első negyedév végén lesz gyártásra kész. Addig is, ha többet szeretne megtudni a MultiChain Enterprise licencelésével vagy árképzésével kapcsolatban, kérjük, ne habozzon vegye fel a kapcsolatot.

Kérjük, tegye meg észrevételeit a LinkedIn.

Forrás: https://www.multichain.com/blog/2020/02/multichain-feeds-for-database-integration/