Blockchain (Bitcoin) як база даних?

Я читав цю статтю News BBC і наступний уривок привернув мою увагу. Це звучить як " Завжди в групах доступності" або " Дзеркальне відображення з високою доступністю", можливо, з автоматично включеною безпекою.

Чи є blockchain потенційно життєздатним рішенням бази даних для сучасних додатків з великим обсягом транзакцій?

Це досить просто зрозуміти, що це цінно для транзакцій з низьким обсягом, як-от особисті медичні записи, але як бути з базами даних з великим обсягом?

Що таке блокчейн?

Blockchains покладаються на криптографію, щоб дозволити набору комп'ютерів внести зміни в глобальний запис, не потребуючи центрального актора.

Видалення посередника скорочує витрати майже в кожному секторі.

Блокчейн - це книга, яка записує все, що відбувається зі збором даних, відомим як "блок" у хронологічному порядку або "ланцюжок".

Як валюта, це важлива особливість, оскільки вона дозволяє користувачам бути впевненими, що їхні цифрові гроші є єдиними, тому що кожна примітка у вашому гаманці є унікальною.

"Технологія Blockchain стане способом створення активів, оскільки вона дозволяє передавати цифрову інформацію без копіювання", - говорить Адам Людвін, керівник Chain.com, який будує мережі blockchain.

Blockchain може використовуватися для відстеження історії всілякої інформації та збереження її цінності, так, наприклад, лікарі могли використовувати її для оновлення медичної документації.

Оскільки кожна зміна блокчейна здійснюється одночасно по всій мережі, інформація не втрачається, і оскільки зміни не можна скасувати, система підтримує свою прозорість. Для внесення змін до кожного блоку потрібен спеціальний ключ, щоб люди могли зберігати свої записи, захищаючи цей ключ.

Чи є blockchain потенційно життєздатним рішенням бази даних для сучасних додатків з великим обсягом транзакцій ?

Технологія blockchain в цілому має деякі характеристики, які ускладнюють роботу з великими обсягами.

Погляньте, наприклад, на біткойн. Середній показник транзакцій в день ніколи не перевищував 300 тис. Транзакцій на день (джерело blockchain.info)

Ще важливіше, що посередній час підтвердження транзакції становить близько 8 хвилин!: Середній час підтвердження транзакції (лише з гонорару ) та приємне зображення від Quandl :

Зараз скільки комп'ютерів у всьому світі відповідають за збереження бази даних біткойн? Я не знаю біткойн, але думаю, що вся історія транзакцій зберігається в ланцюзі блоків, тому всі комп'ютери, які беруть участь у мережі біткойн, по суті зберігають копію всієї бази даних (частина транзакцій, звичайно, не інформація про рахунки) та секретні ключі, вони зберігаються в особистих гаманцях).

Ми можемо лише оцінити їх кількість, але я б здогадався, що їх більше мільйона. 300 000 транзакцій за день з мільйоном комп’ютерів не здається великою гучністю. І 8 хвилин для підтвердження?

Сучасний RDBMS з пристойним обладнанням може легко досягти 1 К транзакцій в секунду. Це приблизно 86 млн транзакцій на день. Час підтвердження? Це залежить від розміру транзакції (на скільки таблиць і рядків це впливає), але для невеликої транзакції типу біткойн (вийміть 42 монети з рахунку A і додайте 42 монети на рахунок B), це буде мілісекунди.

На закінчення різниця в обсягах і часі становить від 1000 до 100000 разів сьогодні.

Якщо технологія blockchain вирішить цю проблему в майбутньому, можливо, її можна буде використовувати в додатках середнього або великого обсягу. Ми можемо читати дискусії та пропозиції щодо вирішення проблеми - багато компаній, згаданих у посиланнях, насправді працюють над цими питаннями, - але ми ще не бачили фактичного робочого рішення чи продукту, який пропонує великі обсяги та швидкість.

Я дуже знайомий з криптовалютами та базами даних, і можу сказати вам, що це зовсім не чудовий двигун БД.

Використання блокчейну як живої бази даних:

Розгляньте це як першу нормалізовану форму без будь-якої справді хорошої вбудованої можливості пошуку або індексації, наскільки йде блокчейн. В основному, лист Excel без будь-яких обчислювальних можливостей, який просто надає вам можливості "читати / писати" з великою кількістю перевірки та перевірки. Блокчейн - це чудовий спосіб перевірити ваші дані, де очищається та виправляється перед тим, як помістити їх у базу даних, яка дозволить вам по-різному запитати, індексувати і т.д.

Переваги блокчейна:

У цьому випадку блокчейн - це суто книга і API для запитів PUT та GET. Ось про це. Блокчейн цікавий тим, що вам потрібна більшість вузлів, щоб передати транзакцію як дійсну, і немає жодних зворотних зворотів, як тільки це буде здійснено. Таким чином, якщо хтось намагається здійснити фальшиву транзакцію, він буде спійманий, якщо особа, яка це робить, не має пулу, який має частку більшості. Потім вони можуть перевірити його у своєму пулі, перш ніж хтось може відхилити його. Це є сильною стороною блокчейна. Перевірка достовірності даних. Це, як правило, досить повільно. Ви переглядаєте приблизно 10 хвилин при нормальному навантаженні, щоб отримати перевірку. Під великим навантаженням час йде зовсім небагато.

Після того, як ви підтвердили, що транзакції є дійсними та не є шахрайськими за допомогою блокчейн, ви зможете імпортувати ці дані в базу даних та працювати з нею, як завгодно. У мене є певний досвід цього, але зауважте, що кожна транзакція в поточній архітектурі біткойна буде записана таким чином, вона має цікаву інформацію для аналізу.

Запит даних із схеми blockchain в СУБД:

Ось біткойн-схема, яку ви можете використовувати для створення схеми в PostgreSQL. Використовуючи це, ви можете розмістити його у реляційній СУБД: https://bitcointalk.org/index.php?topic=38246

Цей репо-код також корисний, якщо ви хочете імпортувати дані в справжні RDBMS: https://github.com/bitcoin-abe/bitcoin-abe

Що стосується того, до якої СУБД ви повинні це вкласти, це залежить від вашого випадку використання. Якщо ви хочете проаналізувати ідентифікатори транзакцій / гаманця, щоб побачити деякі шаблони чи виконати роботу BI, я рекомендую реляційний БД. Якщо ви хочете налаштувати функцію прийому в реальному часі з декількома криптовалютами, я б рекомендував щось, що не потребує журналу транзакцій, тому рішення MongoDB було б добре. Я не думаю, що вам потрібно не турбуватися про Elastic Search, якщо ви не хочете одночасно починати робити прямі записи всіх криптовалют і використовуватимете їх для автоматичної торгівлі чи чогось такого ж божевільного. :)

У 2014 році ми створили ascribe.io з можливістю використання Bitcoin як бази даних для претензій на інтелектуальну власність. Після випуску ми підключили мережу, оскільки вона не могла обробити пропускну здатність, затримка була не менше 10 хвилин, і нас обмежило те, що ми могли вкласти в OP_RETURN, змусивши нас зберігати фактичний цифровий файл, що стосується претензії, в Amazon S3 . Ми зрозуміли, що Bitcoin в його нинішньому вигляді ніколи не може бути високою базою транзакцій.

Але ідея про те, чи можемо ми мати базу даних стилю blockchain - децентралізований контроль, незмінність (стійкість до несанкціонованого захисту) та живі активи в мережі, що залишилися у нас. Тож у середині 2014 року ми почали працювати над BigchainDB

Короткий короткий опис - ми можемо обробляти 100kps із затримкою 100mS та матимемо петабайт. Код нашої BigchainDB Github, технічна документація тут і основне мислення в нашому офіційному документі .

Якщо у вас є випадок використання децентралізованої бази даних з високими транзакціями - ми створили BigchainDB саме для цього.

Blockchain, похідний від Bitcoin, повільний і дорогий; обсяг даних, який може зберігатися в блоці, дуже скромний. Механізми, що стоять за блок-ланцюгами (розподіляють книги), мають на меті забезпечити нетлінне, дуже тиражне сховище даних; одноліткові - це менш важлива особливість, ніж "політична вимога", щоб уникнути появи центрального контролю. Я працюю вже дещо 18 місяців, щоб створити високопродуктивну розподілену книгу (див. Metrognomo.com для однієї інстанції), яка забирає якомога менше біткойна. Зрештою, розподілена книга схожа приблизно на послідовний файл, який можна додавати, але не редагувати після додавання. Це цінна річ для деяких додатків, але не те, що більшість людей вважають базою даних.