עדכוני MultiChain לשילוב בסיס נתונים

הוצאת נתונים מה- blockchain ואל העולם הרחב

עם ההוצאה הפומבית הראשונה של MultiChain, כבר ב-2015, ראינו עניין ביישומי בלוקצ'יין מכיוון מפתיע. בעוד שתכננו במקור את MultiChain כדי לאפשר הנפקה, העברה ומשמורת של נכסים דיגיטליים, מספר הולך וגדל של משתמשים היו מעוניינים להשתמש בו עבור יישומים מוכווני נתונים.

במקרים של שימוש אלו, מטרת הבלוקצ'יין היא לאפשר אחסון ושליפה של מידע למטרות כלליות, שאינן חייבות להיות כספיות באופיו. המניע לשימוש בבלוקצ'יין ולא במסד נתונים רגיל הוא להימנע מהסתמכות על מתווך מהימן שיארח ותחזק את מסד הנתונים. מסיבות מסחריות, רגולטוריות או פוליטיות, המשתמשים במאגר רוצים שזו תהיה אחריות מבוזרת ולא ריכוזית.

האבולוציה של הזרמים

בתגובה למשוב זה, בשנת 2016 אנו הציג זרמי MultiChain, המספקים הפשטה פשוטה לאחסון, אינדקס ושליפה של נתונים כלליים בבלוקצ'יין. שרשרת יכולה להכיל כל מספר של זרמים, שכל אחד מהם יכול להיות מוגבל לכתיבה לפי כתובות מסוימות. כל פריט זרם מתויג על ידי הכתובת של המפרסם שלו וכן מפתח אופציונלי לאחזור עתידי. כל צומת יכול להחליט באופן עצמאי אם להירשם לכל זרם, ולהוסיף את הפריטים שלו בזמן אמת לאחזור מהיר לפי מפתח, מפרסם, זמן, בלוק או מיקום. זרמים היו להיט מיידי בקרב משתמשי MultiChain והבדיל אותו מאוד מפלטפורמות בלוקצ'יין ארגוניות אחרות.

בשנת 2017, זרמים היו מוּרחָב לתמיכה בטקסט מקורי של JSON ו-Unicode, מספר מפתחות לכל פריט ופריטים מרובים לכל עסקה. שינוי אחרון זה מאפשר לפרסם למעלה מ-10,000 פריטי נתונים בודדים בשנייה בחומרה מתקדמת. ואז בשנת 2018, הוספנו תמיכה חלקה עבור נתונים מחוץ לרשת, שבו רק hash של חלק מהנתונים מתפרסם על השרשרת, והנתונים עצמם נמסרים מחוץ לשרשרת לצמתים שרוצים זאת. ומאוחר יותר באותה שנה שחררנו את MultiChain 2.0 Community עם מסננים חכמים, המאפשר לקוד JavaScript מותאם אישית לבצע אימות שרירותי של פריטי זרם.

במהלך 2019 ההתמקדות שלנו פנתה ל-MultiChain 2.0 Enterprise, הגרסה המסחרית של MultiChain ללקוחות גדולים יותר. הראשון הדגמה ארגונית מינוף נתונים מחוץ לשרשרת בזרמים כדי לאפשר הרשאת קריאה, אספקת נתונים מוצפנים ושליפה סלקטיבית וטיהור של פריטים בודדים. כמו תמיד, המורכבות הבסיסית מוסתרת מאחורי קבוצה פשוטה של ​​ממשקי API הקשורים להרשאות ופריטי זרימה. עם זרמים, המטרה שלנו הייתה בעקביות לעזור למפתחים להתמקד בנתוני האפליקציה שלהם, ולא לדאוג מה-blockchain שרץ מאחורי הקלעים.

דילמת מסד הנתונים

ככל שזרמי MultiChain המשיכו להתפתח, עמדנו בפני דילמה מתמדת. לצורך קריאה וניתוח של הנתונים בזרם, האם MultiChain צריכה ללכת בדרך של הפיכה למסד נתונים מלא? האם זה צריך להציע אינדקס שדות JSON, שאילתות אופטימליות ודיווח מתקדם? אם כן, באיזו פרדיגמת מסד נתונים עליו להשתמש - רלציונלי (כמו MySQL או SQL Server), NoSQL (MongoDB או Cassandra), חיפוש (Elastic או Solr), סדרות זמן (InfluxDB) או בזיכרון (SAP HANA)? אחרי הכל, ישנם מקרי שימוש בבלוקצ'יין המתאימים לכל אחת מהגישות הללו.

אפשרות אחת ששקלנו היא שימוש במסד נתונים חיצוני כמאגר הנתונים העיקרי של MultiChain, במקום השילוב הנוכחי של קבצים משובצים LevelDB ובינאריים. אסטרטגיה זו אומצה על ידי ליבת שרשרת (הופסק), מחזיק פוסט (עדיין לא פומבי) והוא זמין כאופציה ב-Hyperledger Fabric. אבל בסופו של דבר החלטנו נגד גישה זו, בגלל הסיכונים של התלות בתהליך חיצוני. אתה לא באמת רוצה שצומת הבלוקצ'יין שלך יקפא בגלל שהוא איבד את החיבור למסד הנתונים שלו, או בגלל שמישהו מפעיל שאילתה מורכבת במאגר הנתונים שלו.

גורם נוסף שיש לקחת בחשבון הוא אגנוסטיזם של טכנולוגיה ואינטגרציה. ברשת בלוקצ'יין המשתרעת על מספר ארגונים, לכל משתתף יהיו העדפות משלו לגבי טכנולוגיית מסד הנתונים. כבר יהיו להם יישומים, כלים וזרימות עבודה שנבנו על הפלטפורמות שמתאימות לצרכים שלהם. אז בבחירת מסד נתונים מסוים, או אפילו בהצעת מספר אפשרויות, בסופו של דבר נגרום לחלק מהמשתמשים להיות לא מרוצים. בדיוק כפי שכל משתתף בלוקצ'יין יכול להפעיל את הצומת שלו על מגוון רחב של טעמי לינוקס, הם צריכים להיות מסוגלים להשתלב עם מסד הנתונים המועדף עליו.

היכרות עם הזנות MultiChain

היום אנו שמחים לפרסם את הגישה שלנו לאינטגרציה של מסדי נתונים - MultiChain Feeds. הזנה היא יומן בינארי בזמן אמת בדיסק של האירועים הקשורים לזרם blockchain אחד או יותר, לקריאה על ידי תהליכים חיצוניים. אנו מציעים גם את הקוד הפתוח מתאם הזנה מרובה שרשרת שיכול לקרוא עדכון ולשכפל אוטומטית את התוכן שלו למסד נתונים Postgres, MySQL או MongoDB (או כמה בבת אחת). המתאם כתוב ב-Python ויש לו רישיון ליברלי, כך שניתן לשנות אותו בקלות כדי לתמוך במסדי נתונים נוספים או להוסיף סינון ושינוי נתונים. (תיעדנו גם את פורמט קובץ הזנה למי שרוצה לכתוב מנתח בשפה אחרת.)

צומת לא צריך להירשם לזרם כדי לשכפל את האירועים שלו לעדכון. זה מאפשר לעקוף לחלוטין את אינדקס הזרם המובנה של MultiChain, כדי לחסוך זמן ושטח דיסק. הזנות משקפות גם שליפה וטיהור של נתונים מחוץ לשרשרת, ויכולים לדווח על הגעת בלוקים חדשים בשרשרת. על מנת לחסוך בשטח הדיסק, אתה יכול לשלוט בדיוק אילו אירועים נכתבים לפיד, ואילו שדות נרשמים עבור כל אחד מאותם אירועים. בנוסף, קבצי הזנה מסובבים מדי יום וישנה פקודת טיהור פשוטה להסרת קבצים לאחר עיבוד.

מדוע הזנות MultiChain נכתבות לדיסק, במקום זורמות בין תהליכים או דרך הרשת? כי אנחנו רוצים שהם ישמשו כיומן שכפול אמין במיוחד שעמיד בפני השבתה של מסד נתונים, קריסות מערכת, אובדן חשמל וכדומה. על ידי שימוש בקבצי דיסק, אנו יכולים להבטיח עמידות, ולאפשר לבסיס הנתונים היעד להתעדכן באופן אסינכרוני. אם מסד הנתונים הזה מסיבה כלשהי הופך לעומס יתר או מנותק, MultiChain יכול להמשיך לפעול ללא הפרעה, ומסד הנתונים יתעדכן ברגע שהדברים יחזרו לקדמותם.

תחילת העבודה עם עדכונים

עדכונים משולבים בהדגמה/בטא העדכנית ביותר של MultiChain Enterprise, כלומר זמין להורדה עַכשָׁיו. התחל על ידי קריאת התיעוד עבור מתאם הזנה מרובה שרשרת, או סקירת ה ממשקי API הקשורים לפיד. נשמח שמע את המשוב שלך על תכונה זו וכיצד נוכל להרחיב אותה בעתיד.

עם שחרור העדכונים, גרסה 2.0 של MultiChain Enterprise הושלמה כעת - ראה את הורד והתקן דף להשוואה מלאה בין מהדורת הקהילה והארגונית. במהלך החודשיים הקרובים נשלים את הבדיקות והאופטימיזציה שלו, ונצפה שהוא יהיה מוכן לייצור לקראת סוף הרבעון הראשון. בינתיים, למידע על רישוי MultiChain Enterprise או תמחור, אנא אל תהסס להתקשר.

אנא פרסם הערות ב LinkedIn.

מקור: https://www.multichain.com/blog/2020/02/multichain-feeds-for-database-integration/