Kanały MultiChain do integracji bazy danych

Wydobywanie danych z łańcucha bloków w szerszy świat

Wraz z pierwszym publicznym wydaniem MultiChain, już w 2015 roku, zauważyliśmy zainteresowanie aplikacjami blockchain z zaskakującego kierunku. Chociaż pierwotnie zaprojektowaliśmy MultiChain, aby umożliwić wydawanie, przekazywanie i przechowywanie zasobów cyfrowych, coraz większa liczba użytkowników była zainteresowana wykorzystaniem go w aplikacjach zorientowanych na dane.

W takich przypadkach celem łańcucha bloków jest umożliwienie przechowywania i wyszukiwania informacji ogólnego przeznaczenia, które nie muszą mieć charakteru finansowego. Motywacją do korzystania z łańcucha bloków zamiast zwykłej bazy danych jest unikanie polegania na zaufanym pośredniku w zakresie hostowania i utrzymywania tej bazy danych. Ze względów handlowych, regulacyjnych lub politycznych użytkownicy bazy danych chcą, aby była to odpowiedzialność rozproszona, a nie scentralizowana.

Ewolucja strumieni

W odpowiedzi na tę informację zwrotną w 2016 r wprowadzono Strumienie MultiChain, które zapewniają prostą abstrakcję do przechowywania, indeksowania i pobierania ogólnych danych w łańcuchu bloków. Łańcuch może zawierać dowolną liczbę strumieni, z których każdy może być ograniczony do zapisu przez określone adresy. Każdy element strumienia jest oznaczony adresem swojego wydawcy, a także opcjonalnym kluczem do pobrania w przyszłości. Każdy węzeł może niezależnie zdecydować, czy subskrybować każdy strumień, indeksując jego elementy w czasie rzeczywistym w celu szybkiego wyszukiwania według klucza, wydawcy, czasu, bloku lub pozycji. Strumienie od razu stały się hitem wśród użytkowników MultiChain i mocno odróżniały go od innych platform blockchain dla przedsiębiorstw.

W 2017 roku strumienie były dużym do obsługi natywnego tekstu JSON i Unicode, wielu kluczy na element i wielu elementów na transakcję. Ta ostatnia zmiana umożliwia publikowanie ponad 10,000 2018 pojedynczych elementów danych na sekundę na zaawansowanym sprzęcie. Następnie w XNUMX roku dodaliśmy bezproblemową obsługę dane spoza łańcucha, w którym tylko skrót niektórych danych jest publikowany w łańcuchu, a same dane są dostarczane poza łańcuchem do węzłów, które tego chcą. A później tego samego roku wydaliśmy Społeczność MultiChain 2.0 z Inteligentne filtry, umożliwiając niestandardowemu kodowi JavaScript przeprowadzanie arbitralnej weryfikacji elementów strumienia.

W 2019 roku skupiliśmy się na MultiChain 2.0 Enterprise, komercyjnej wersji MultiChain dla większych klientów. Pierwszy Wersja demonstracyjna dla przedsiębiorstw wykorzystywał dane spoza łańcucha w strumieniach, aby umożliwić uprawnienie do odczytu, przesyłanie zaszyfrowanych danych oraz selektywne pobieranie i czyszczenie poszczególnych elementów. Jak zawsze, podstawowa złożoność jest ukryta za prostym zestawem interfejsów API związanych z uprawnieniami i elementami strumienia. W przypadku strumieni naszym celem jest konsekwentnie pomaganie programistom w skupieniu się na danych ich aplikacji i nie martwieniu się o blockchain działający za kulisami.

Dylemat bazy danych

Ponieważ strumienie MultiChain nadal ewoluowały, stanęliśmy przed ciągłym dylematem. Czy do odczytywania i analizowania danych w strumieniu, czy MultiChain powinien podążać ścieżką stania się pełnoprawną bazą danych? Czy powinien oferować indeksowanie pól JSON, zoptymalizowane zapytania i zaawansowane raportowanie? Jeśli tak, jakiego paradygmatu bazy danych powinien użyć - relacyjnego (jak MySQL lub SQL Server), NoSQL (MongoDB lub Cassandra), wyszukiwania (Elastic lub Solr), szeregów czasowych (InfluxDB) czy w pamięci (SAP HANA)? W końcu istnieją przypadki użycia blockchain dostosowane do każdego z tych podejść.

Jedną z opcji, którą rozważaliśmy, jest użycie zewnętrznej bazy danych jako podstawowego magazynu danych MultiChain, zamiast bieżącej kombinacji osadzonych plików LevelDB i plików binarnych. Ta strategia została przyjęta przez Rdzeń łańcucha (wycofane), Łańcuch pocztowy (jeszcze niepubliczne) i jest dostępne jako opcja z tkaniny Hyperledger. Ostatecznie jednak zdecydowaliśmy się odrzucić to podejście ze względu na ryzyko uzależnienia od procesu zewnętrznego. Naprawdę nie chcesz, aby węzeł łańcucha bloków zamarzł, ponieważ utracił połączenie z bazą danych lub ponieważ ktoś uruchamia złożone zapytanie w jego magazynie danych.

Innym czynnikiem, który należy wziąć pod uwagę, jest agnostycyzm w zakresie technologii i integracji. W sieci blockchain obejmującej wiele organizacji każdy uczestnik będzie miał własne preferencje dotyczące technologii baz danych. Będą już mieć aplikacje, narzędzia i przepływy pracy zbudowane na platformach dostosowanych do ich potrzeb. Tak więc wybierając jakąkolwiek konkretną bazę danych, a nawet oferując kilka opcji, sprawilibyśmy, że niektórzy użytkownicy byliby niezadowoleni. Tak jak każdy uczestnik blockchain może uruchomić swój węzeł w szerokiej gamie wersji Linuksa, powinien mieć możliwość integracji z wybraną bazą danych.

Przedstawiamy kanały MultiChain

Dziś z przyjemnością prezentujemy nasze podejście do integracji baz danych - MultiChain Feeds. Kanał informacyjny to zapisywany na dysku binarny dziennik w czasie rzeczywistym, zawierający zdarzenia związane z jednym lub większą liczbą strumieni łańcucha bloków, do odczytu przez procesy zewnętrzne. Oferujemy również oprogramowanie typu open source Adapter MultiChain Feed który może czytać kanał i automatycznie replikować jego zawartość do bazy danych Postgres, MySQL lub MongoDB (lub kilku na raz). Adapter jest napisany w języku Python i posiada liberalną licencję, dzięki czemu można go łatwo zmodyfikować w celu obsługi dodatkowych baz danych lub dodania filtrowania i transformacji danych. (Udokumentowaliśmy również format pliku danych dla tych, którzy chcą napisać parser w innym języku).

Węzeł nie musi subskrybować strumienia, aby replikować swoje zdarzenia do źródła. Pozwala to na całkowite ominięcie wbudowanego indeksowania strumienia MultiChain, aby zaoszczędzić czas i miejsce na dysku. Kanały odzwierciedlają również pobieranie i usuwanie danych spoza łańcucha i mogą informować o pojawieniu się nowych bloków w łańcuchu. Aby zaoszczędzić miejsce na dysku, możesz dokładnie kontrolować, które zdarzenia są zapisywane w źródle treści i które pola są rejestrowane dla każdego z tych zdarzeń. Ponadto pliki danych są zmieniane codziennie i istnieje proste polecenie czyszczenia, aby usunąć pliki po przetworzeniu.

Dlaczego źródła MultiChain są zapisywane na dysku, a nie przesyłane strumieniowo między procesami lub przez sieć? Ponieważ chcemy, aby służyły jako niezawodny dziennik replikacji, który jest odporny na przestoje bazy danych, awarie systemu, utratę zasilania i tym podobne. Korzystając z plików dyskowych, możemy zagwarantować trwałość i umożliwić asynchroniczną aktualizację docelowej bazy danych. Jeśli z jakiegoś powodu ta baza danych zostanie przeciążona lub odłączona, MultiChain może kontynuować działanie bez zakłóceń, a baza danych nadrobi zaległości, gdy wszystko wróci do normy.

Pierwsze kroki z kanałami

Kanały są zintegrowane z najnowszą wersją demo / beta MultiChain Enterprise, czyli dostępny do pobrania teraz. Zacznij od przeczytania dokumentacji dla Adapter MultiChain Feedlub przeglądając API związane z kanałem. Chcielibyśmy usłyszeć swoją opinię na temat tej funkcji i jak możemy ją rozszerzyć w przyszłości.

Wraz z wydaniem kanałów wersja 2.0 MultiChain Enterprise jest teraz kompletna - zobacz Pobierz i zainstaluj pełne porównanie wersji Community i Enterprise. W ciągu następnych kilku miesięcy zakończymy jego testy i optymalizację i spodziewamy się, że będzie gotowy do produkcji pod koniec pierwszego kwartału. W międzyczasie, aby uzyskać informacje na temat licencji MultiChain Enterprise lub cennika, nie wahaj się skontaktuj się z nami.

Prosimy o umieszczanie komentarzy na LinkedIn.

Źródło: https://www.multichain.com/blog/2020/02/multichain-feeds-for-database-integration/