🏆 Рейтинг ІТ-роботодавців 2018: вже зібрано більше 13 000 анкет. Оціни свою компанію!
×Закрыть

DOU Проектор: OurSQL — реплікація баз даних MySQL із використанням Blockchain

У рубриці DOU Проектор всі охочі можуть презентувати свій продукт (як стартап, так і ламповий pet-проект). Якщо вам є про що розповісти — запрошуємо взяти участь. Якщо ні — можливо, серія надихне на створення власного made in Ukraine продукту. Питання і заявки на участь надсилайте на editors@dou.ua.

Я — Роман Гелемб’юк з Івано-Франківська. Уже більше 17 років займаюся програмуванням. Основні технології — PHP та Golang. Як порядний IT-шник я маю свої pet-проекти. Наразі мене цікавлять децентралізовані бази даних та блокчейн-технології.

Хочу розповісти про свій проект OurSQL. Це, свого роду, розширення MySQL, яке дозволяє створити децентралізовану базу даних без вузлів із «особливими» правами.

Ідея

Спочатку була ідея створити децентралізовану платформу для громадянського суспільства. Щось типу соціальної мережі, але децентралізовану, без «адміна», «власника» і модераторів, із можливостями вести конструктивний діалог, водночас.

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

Огляд готових рішень для децентралізованих ДБ не дав результатів, фактично є лише BighainDB (на базі MongoDB). Насправді ж вона не виконує обіцяного, хоч і є розрекламованою та популярною. Слід відзначити проект Hyperledger.org, який у той час видався мені занадто складним для використання. Напевно, для корпорацій він буде найкращим вибором, але не для малих компаній чи одинаків.

Процес розробки

Задача була створити інструмент для реплікації баз SQL-даних повністю децентралізованим способом, без будь-яких master вузлів.

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

У результаті написав спрощений клон bitcoin на Golang із нуля. Він робочий, хоча підтримувати я його не планую.

Далі на базі коду democoin був створений OurSQL — проксі-сервер MySQL, який фільтрує SQL-запити, перевіряє можливість виконання, конвертує SQL у блокчейн-транзакції, будує блоки (для блокчейну), відправляє блоки та транзакції іншим нодам (іншим серверам OurSQL в межах однієї бази даних) і ті, в свою чергу, роблять відповідні оновлення у своїх локальних копіях MySQL-баз.

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

OurSQL = MySQL + Blockchain: як це працює

OurSQL — це окремий сервер, який має два основні компоненти: MySQL проксі-сервер та власне Blockchain-сервер.

Кожен екземпляр OurSQL («нода») працює із єдиною базою MySQL. У цій базі одночасно зберігаються дані разом зі спеціальними таблицями, у яких збережено інформацію про сам блокчейн. SQL-запити надходять через проксі-сервер і далі аналізуються. Якщо це Update запит, відбувається перевірка можливості виконання такого запиту. Ця перевірка відбудеться згідно з правилами консенсусу, які діють у цій базі даних.

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

Нова транзакція додається до «пулу» транзакцій — тимчасового місця зберігання ще не підтверджених транзакцій. Також ця транзакція буде відправлена до всіх інших відомих нодів. Ті, у свою чергу, перевірять її ще раз і виконають. Коли в пулі набереться достатня кількість транзакцій, буде побудовано блок із допомогою правила Proof of Work (так само, як у біткоін). Нода, яка першою побудує блок, надсилає його всім іншим нодам.

Із допомогою OurSQL можна створити базу даних. Проте сама по собі база даних не є дуже корисною. Як і випадку зі звичайними базами даних, потрібен «інтерфейс». Тобто якись додаток, що буде виконувати основну роботу і зберігати потрібні дані в децентралізованій базі даних.

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

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

Кожен користувач децентралізованої системи повинен отримати свою копію додатка в «пакеті». Цей пакет включає: MySQL-сервер, OurSQL-сервер, конфігураційний файл із описом правил консенсусу і, власне, сам додаток.

Проте можливим є і створення «легких клієнтів». Тобто додатків, які не містять у собі повноцінної ноди, а працюють із одною із доступних віддалених нод. У цьому випадку доведеться з’єднуватися із віддаленою базою даних. Або робити додатковий «шар» у вигляді REST API.

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

Криптовалюта

Кожна база даних створена із OurSQL отримує свою криптовалюту як «побічний ефект». За створення блоку відповідна нода отримує винагороду. Певну кількість одиниць криптовалюти. Потім цю валюту можна переслати на інші «гаманці» (чи адреси, чи публічні ключі). Кожна нода отримує гаманець при створенні, однак можна додавати необмежену кількість інших гаманців. У плані «криптовалюти» все працює, як у bitcoin.

Використання криптовалюти не є обов’язковим. Ці дані можна просто ігнорувати (у майбутньому зроблю можливість відключити взагалі). Проте внутрішня криптовалюта має певні корисні застосування. Наприклад, є можливість вказати «ціну змін» для конкретних типів SQL-запитів та конкретних таблиць. Це один із інструментів контролю над цілісністю бази даних. Оскільки ми говоримо про базу даних, яка може бути доступна для запису анонімним користувачам, завжди є спокуса все витерти або щось лишнє дописати. Один із способів контролю — плата за транзакцію із використанням внутрішньої валюти.

Як OurSQL зв’язаний із bitcoin та ethereum

Ніяк, за винятком використання такої самої технології «блокчейн». Але із конкретними відомими публічними блокчейнами OurSQL ніяк не пов’язаний.

Кожна база даних створена і підтримувана із OurSQL — це повністю окремий, новий блокчейн, що володіє власною криптовалютою, яка працює лише в межах цієї бази даних. Також вона не має відношення до «смарт-контрактів», хоча кожну базу даних та додаток, який її використовує можна розглядати як один великий «смарт-контракт» — єдиний на цьому блокчейні.

Де використовувати OurSQL

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

Приклади:

  • Децентралізована соціальна мережа, оскільки ми не довіряємо Facebook.
  • Нове покоління фінансових інструментів, які, крім криптовалюти, мають свій внутрішній «суд», «регулятор» та інші «інститути» криптодемократії, адже ми хочемо незалежну світову валюту. Однак перший досвід не дуже успішний, потрібна регуляція та спосіб вирішення конфліктів.
  • Децентралізовані платформи для меритократії.
  • Децентралізовані месенджери (в яких платформа потрібна лише для пошуку контактів, а сама комунікація вже напряму), оскільки традиційні месенджери контролюються спецслужбами.
  • Платформи для «горизонтальних» об’єднань громадян, адже створення традиційних партій чи об’єднань вимагає довіри, а її часто немає.

Blockchain consensus

Алгоритм консенсусу є центральним поняттям в технології blockchain. Наразі OurSQL підтримує лише найпопулярніший і найнадійніший підхід — Proof of Work, аналогічний bitcoin та більшості популярних криптовалют. Кожна база даних має спеціальний файл — ConsensusConfig, у якому описано параметри для Proof of Work: складність пошуку хешу блока, кількість транзакцій у блоці, винагорода «майнеру» в монетах внутрішньої криптовалюти та ін.

Також налаштування консенсусу включають правила змін в базі даних — список таблиць, які не синхронізуються, заборона оновлень певних типів для певних таблиць (наприклад: заборона видаляти рядки із певної таблиці).

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

Також у майбутньому я планую створити підтримку «модуля консенсусу» для кожної бази даних. Відтак розробник бази даних зможе описати максимально гнучкі правила консенсусу використовуючи програмування, а не лише конфігурування певного алгоритму.

Як спробувати OurSQL

Інсталяційного пакету поки що немає. Є 2 способи спробувати, як працює цей сервіс: скомпілювати програму або запустити в Docker-контейнері.

Використовуючи Docker-контейнери, ви можете легко запустити 2 ноди на одній машині та подивитися, як синхронізуються дані.

docker run --name oursql1 -p 9001:8765 -p 9002:8766  -d -it oursql/oursql-server interactiveautocreate -port 9001

Ця команда запустить новий контейнер, у якому створиться нова база даних. Наступна команда створить інший контейнер із додатковою нодою, яка приєднається до першої, утворивши кластер із двох нод.

docker run --name oursql2 -p 9003:8765 -p 9004:8766  -d -it oursql/oursql-server importfromandstart -port 9003 -nodeaddress host.local.address:9001

Використайте MySQL-клієнт, щоб приєднатися до першої ноди на порті 9002 або до другої на порті 9004. База даних має назву BC та користувача blockchain/blockchain. Вносьте зміни в базу даних, використовуючи SQL, і ви побачите, як зміни реплікуються між нодами.

mysql -h 127.0.0.1 -P 9002 -u blockchain -pblockchain BC

mysql -h 127.0.0.1 -P 9004 -u blockchain -pblockchain BC

Також можна підключитися до існуючої демонстраційної бази даних «OurSQL Demo DB».

docker run --name oursql -p 8765:8765 -p 8766:8766 -d -it oursql/oursql-server importandstart -port 8765 -nodeaddress 109.251.62.4:8765
mysql -h 127.0.0.1 -P 8766 -u blockchain -pblockchain BC

Деталі про роботу із цією базою можна знайти в блозі проекту.

Подальші кроки

Перше — додати можливість створення модуля консенсусу для децентралізованої бази. Наразі можна робити лише конфігураційний файл, у якому описано прості правила для Proof of Work консенсусу та правила для роботи із таблицями в базі.

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

Тобто для кожної конкретної децентралізованої бази даних, підтримуваної на OurSQL, можна буде запрограмувати модуль (швидше за все на мові Golang), у якому буде реалізовано логіку роботи і можливих змін у цій базі, рівнів та прав доступу для кожного користувача.

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


Веб-сайт проекту. Нещодавно почав вести блог, щоб розповідати про результати роботи та давати поради.

Контакти: roman@gelembjuk.com, oursql.project@gmail.com.

LinkedIn

56 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Если я верно понял механику работы с комментов автора, то логичнее (и корректнее с точки зрения архитектуры блокчейна) следующий вариант — запрос попадает на ноду, но не выполняеться а лишь проверяеться синтаксис (и здесь есть место крипте — например, используя парсер SQL строить оценку стоимости по плану запроса). Выполнение же запросов — только после коммита блока (а в нем они упорядочнены и, возможно, сгруппированы по записям так, чтобы не было противоречивых).

Для такого подхода, правда, PoW уже не очень ок, но раз у вас Go, надо было посмотреть на Tendermint, как раз слой консенсуса сам по себе.

P.S. О BigchainDB вы, похоже, не до конца разобрались. На самом деле они делают почти что-то схожее, только у вас mySQL, а они данные на нодах хранят в монге, что не есть плохо даже )

Спочатку про BigchainDB .
Там дійсно була проблема. Вони вирішили її тільки у версії 2.0 яка була анансована у лютому. А до того була серйозна проблема.
Тут написано www.reddit.com/...​e_of_blockchain_bullshit
І крім цього я сам побачив цю проблему десь на початку 2017 коли вперше звернув увагу на цю систему.
Суть в тому, що там реплікація даних іде через якусь стандартну утиліту для раплікації Mongodb . Тобто, коли ви працюєте із базою через bigchaindb , то будується блокчейн . Потім bigchaindb робить оновлення в базі і база реплікується. Фішка в тому, що коли ви зробите оновлення в базі напряму без bigchaindb , то це оновлення піде на всі інші ноди!
Я сосбисто перепитувув розробників про це і вони підтверджували.І казали що це нічого такого .

Зараз вони зробили повнстю іншу систему, яка якраз і використовує Tendermint.

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

Да, я так им понял, как у вас работает, и вел к тому, что это не очень соответствует идеологии блокчейна. Но вам, как автору, виднее, конечно.

В чём вообще профит от блокчейна в контексте конкретной и далеко не новой задачи мульти-мастер репликации? Зачем нужен майниг и PoW в среде с 100% доверием между нодами? Почему не был реализован более подходящий под этот случай Raft? В чём смысл парсинга UPDATE, если есть доступ к WAL?

Ця система потрібна саме для випадку коли не всі 100% нод довіряють один одному. Саме тому і потрібен блокчейн із PoW, як підхід який реально працює.
Не знаю на рахунок WAL. Моя ідея полягає в тому, щоб розробка інтерфейсу не вимагала якихось спеціальних модулів для модифікації даних. Всі знають SQL. Підключився до хоста через станартну mysql бібліотеку і працюєш із базою. Більше нічого не потрібно в коді самого додатка. Нічого особливого, лише робота із базою із допомогою SQL. Це всі вміють робити

Решение конфликтов в блокчейне и решение конфликтов при репликации имеют по-сути разную природу. Блокчейн обеспечивает неизменность цепочек взаимосвязанных операций и решение конфликтов в среде с нулевым доверием. Репликация предназначена для поддержки данных в консистентном состоянии (по мере возможности) после применения атомарной операции модификации данных с решением возможных конфликтов как правило на основании timestamp. Разные задачи, разные проблемы, разные подходы, разные алгоритмы.

Окей, предположим мы расширяем задачу репликации и считаем, что мы не доверяем ряду нод и точно не знаем каким. Мошенническая нода в каждом апдейте увеличивает поле total_account на 10. И? Как блокчейн поможет решит задачу антифрода, если всё что мы знаем о потенциально мошеннической ноде — это то что она может как и любая другая нода кластера создавать атомарные операции, приводящие к конфликтам? В чём роль блокчейна и PoW в данной задаче (исключая тот факт, что это метод, который реально работает на своём спектре задач)? Вместо майнинга блока апдейтов, согласованность которых может быть потеряна ещё на стадии собственно майнинга, можно с не меньшим успехом использовать random().

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

Блокчейн обеспечивает неизменность цепочек взаимосвязанных операций и решение конфликтов в среде с нулевым доверием.

Саме так. У нашій системі блокчейн забезпесує «одинаковість даних» у всіх нодах. Можливий короткий розсинхрон, але з часом все стає на свої місця. Це називається Eventual consistency. При обміні даними всі ноди отримують однаковий блокчейн і відповідно однаковий вміст бази даних. Для цього блокчейн і потрібен.
Крім цього, блокчейн саме дозволяє працювати там де немає довіри до всіх нод. Але не у плані змін даних, а у плані «слідуванню» правилам консенсусу.
Саме консенсус оберігає від таких ситуацій як ви описали . Він визначає хто, коли і при яких умовах може виконувати якусь зміну.
Правила консенсуса є невідємною частиною кожної бази даних.

Можуть бути прості правила. Типу, рядок в таблиці може міняти лише той хто його додав в цю таблицю. Або, щоб виконати UPDATE для рядка в конкретній таблиці потрібно заплатити 100 монет у внутрішній киптовалюті.
Або більш складні правила (ще не підтримуються, але скоро буде) можна буде застосувати із допомогою «модуля консенсуса». Типу, якщо хтось намагається збільшити значення стовпця в таблиці, то обовязково перед цим даний користувач (ідентифікується по ключу) мав бути обраним голосуванням більшості користувачів на особливу тимчасову роль"збільшувач лічильника" . Якщо такого голосування не було, або був обраний хтось інший, то операцію не дозволити.

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

Саме так. У нашій системі блокчейн забезпесує «одинаковість даних» у всіх нодах.

Вы решаете одну задачу инструментами, предназначенными для решения другой.
Чтобы разобраться, как её на самом деле нужно решать, посмотрите как работает Zookeeper.

«ZooKeeper is a centralized service for ...»
Я працюю на інструментом для повністю децентралзованої системи. Без жодних особливих центральних вузлів.

О, боги... А прочитать чуть дальше первой строчки?
«The Apache ZooKeeper system for distributed coordination is a high-performance service for building distributed applications.»

Чи можна на ZooKeeper побудувати криптовалюту, так щоб кожен бажаючий міс поставити свою і всі ноди були повністю рівноправними?

Вы какую задачу решаете? Натянуть сову на глобус через создание очередного коина или реальную задачу надёжной мульти-мастер репликации в гетерогенной среде? При чём тут вообще криптовалюты?

не буду спорити. Не використовував цей інструмент раніше. Чи можна із ним синхронізувати базу даних між нодами де немає довіри до всіх нод? Можливо, я не знаю

Идея интересная, но меня всегда интересовал в блокчейне тот факт, как клиенту подключится к сети если его ip находится за NAT’ом. Кто у вас является централизованным сервером для оповещения новых клиентов о списке доступных на данный момент серверов. Новый клиент все равно должен знать хотя бы один открытый сервак, к которому он может поключится для того чтобы войти в сеть.

Я цю проблему реалізував наступний чином.
Кожна нода посилає повідомлення із змінами (блок, транзакція) до всіх нод які вона знає. Частина цих нод буде недоступна (ті хто за NAT’ом, або в оффлайні). Вони просто ігноруються.
З іншого боку, кожна нода має thread який регулярно чекає всі інші ноди (які він знає) щоб отримати що нового. При цьому, нода знає «чи були в мене вхідні конекти недавно». Якщо вхідні конекти були, це значить нода є доступною для інших. Тоді ця нода буде звірятися із цншими рідко. Якщо вхідних конектів не було, то буде звірятися із іними часто.
Центральної ноди немає. Кожна нода доступна в мережі може бути використана для перевірки. Тобто, щоб максимально зробити мережу стабільною потрібно побільше таких нод, постійно доступних

Тобто, щоб максимально зробити мережу стабільною потрібно побільше таких нод, постійно доступних

то то и оно

Сам думал про идею децентрализованной соц сети, но уперся в проблему, описанную мной выше. В итоге, если все таки нужен сервак, то его легко можно будет заблокировать. Любые способы решения, которые приходили мне в голову получались либо не надежными, либо слишком сложными. Я в свое время написал библиотеку, позволяющую соединяться клиентам за NAT’ом напрямую github.com/volok-aleksej/twainet.

Мы берём тупую но шуструю СУБД, цепляем к ней самую медленную РСУБД и получаем тупой и медленный кластер, не поддерживающий сложные транзакции.

Браво! А как называется Шнобелевская премия для IT?

заодно дайте шнобелівську премію винахіднику біткоіна :)

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

Децентрализованные СУБД были задолго до блокчейна. Причем с поддержкой оффлайн репликации на запись и сложных транзакций с кворумом.
Правда криптовату они майнить неумели.

Так. Це все є. Крім видку коли в кластері можуть бути ноди до яких немає довіри. АБо по іншому, якщо «жулік» має можливість додати свою ноду в кластер і почати щось «хімічити». Всі ті способи не спрацюють в цьому випадку.

Самое грустное в такой модели репликации то, что если вы делаете на одном узле update, который по каким-то причинам выполняется 5 часов, то это означает, что и на всех остальных узлах он будет выполняться те же самые 5 часов.

Так. Тільки такі апдейти не повинні мати місце. ПОтрібно будувати логіку свого DApp так, щоб було поменше таких операцій.
Треба зауважити, що ця система не підійде для «великих баз даних». Це для чогось малого. Якщо є потреба зробити велику децентралізовану базу, то в процесі дизайну краще оразу розбивати її на декілька менших , одна із яких буде лише для координації роботи менших баз.
Замість одного блокчейну краще багато малих, які координуються якимось «базовим» блокчейном

Как распределение личных данных в открытом или закрытом виде среди многих пользователей решает проблему продажи этих личных данных «злой» корпорацией/пользователем?

Сама децентралізована база даних не підходить для таких задач. В такій системі не може бути приватних даних.
Проте, можливі гібридні рішення. Distributed Ledger + private storage . Distributed Ledger координує роботу мережі, якщо це «соціальна мережа CryptoBook» , то у відкритій базі знаходиться коротка ублічна нформація, а все «приватне» в таємному місці, досьуп до якого можливий лише «друзям» і тому кому дозволено. І це «приватне» місце вибирається на свій розсуд. Тобто, можуть бути тисячі компаній які пропонують полугу «збереження приватних даних» в межах соціальної мережі CryptoBook.
Це все ще вимагає передачі комусь своїх даних , але дає вибір. В тому числі , можна налаштувати свй домашній сервер і там все тримати, і надавати доступ на ситання лише тому кого я додав у другі в мережі і запис про це міститься в основні базі даних.

Т.е. в блокчейне хранится некая зашифрованная БД, ключи от которой есть только у некоторых пользователей. Я все еще не понимаю как это решает проблему когда один владельцев ключей открывает базу и продает все данные из неё?

База не є зашифрованою. Всі дані відкриті.
Ця система на підходить для випадків коли якісь дані мають бути сховані. Тільки повністю відкриті дані тут можуть зберігатися.

Для «приватних» даних нічого винаходити не потрібно. Там вже все винайдено

Приклади:

Децентралізована соціальна мережа, оскільки ми не довіряємо Facebook.

Децентралізовані месенджери (в яких платформа потрібна лише для пошуку контактів, а сама комунікація вже напряму), оскільки традиційні месенджери контролюються спецслужбами.

Тогда при чем тут эти примеры?

То це реплікація якого типу? Або запитаю краще так — на всіх нодах дозволяється змінювати дані чи тільки на одній?

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

А як серіалізуються транзакції? Або як оновлюються дані в базах в процесі «прийняття»?

Транзакція це SQL команда, а також деяка інформація про попередній стан запису який ця команда міняє, ІД транзакції де цей запис мінявся попередній раз та ін. При отриманні транзакції (окремої чи як частини блока), іде перевірка чи ці дані ще актуальні , тобто яи якась інша транзакція ще не міняла той запис. Якщо все ок то виконується SQL . якщо ні то транзакція відкинетья. або і весь блок. Але у випаку блоку, є приоритет на транзакціями які ще у пулі. ТОбто, ви можете щось змінити, але в цей часй прийшов блок від іншої ноди де цей же рядок також зінений, то ваша транзакція відкотиться, тому що вона ще не додана в жоний блок.

Якщо транзакція міняє багато записів, або є пов’язані зміни (тригери, наприклад), або взагалі логіка змін схована в процедурі, то як відбувається відслідковування змін?

Для цього ще немає рішення.
Я передбачив можливість додати більше ніж одну SQL команду в транзакцію. Тобто, зараз це масив, але завжди із одного елемента. З розрахунку ощб пізніше додати підтримку декількох команд. Це буде трохи пізніше. Це не важко додати.
Потім , ще буде можливість контролювати це на рівні побудови блоків. Коли механізм консунсусу буде програмуватися як «модуль», тоді можна буде додати перевірку типу «якщо є зміна такої то таблиці, то в цій же транзакції має бути вставка в таку то таблицю». Якщо умова не виконується то транзакція не пройде.

Це буде трохи пізніше.
В даний момент лише індивідуальні SQL запити

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

Можливо і так. Ще до цього не дійшов.
Напевно, це буде працювати коли є правила групових транзакцій, коли якась операція над таблицею завжди має бути в супроводі контретної операції над іншою таблицею. Тоді можна щось думати. А так, поки що неясно.
Я це уявляю як набір «операцій» описаних в модулі консенсуса . наприклад, операція «запрошення користувача в мережах». Ця операція передбачає перелік змін в конкретних таблицях. В процесі консенсусу ми можемо перевірити чи всі SQL запити є присутні для цієї операції, чи всі вони валідні і чи всі можна виконати. Якщо всі умови виконані то пропускаємо операцію. і вся операція має бути в межах одного блоку.
щось можна думати тут. ще не знаю

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

Моя мета саме повністю децентралізована система. КОли всі вузли є рівнозначними і немає ніяких особливих вузлів.
Якщо ми робимо особливий вузол де робимо всі записи то немає нікого сенсу використовувати локчейн. Є набагато ефективніші підходи.
Блокчейн тільки там де всі рівноправні.

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

Транзакция на обновление в БД висит открытая без финального коммита пока где-то не будет подтверждён блок, в котором находится мета-информация об этой транзакции?

Так. Транзакція бууде виконана при попаданні в пул. Але остаточно її можна вважати завершеної, кола вона попала в блок і цей блок прийнятий більшістю вузлів.

Т.е. клиент будет ждать, пока его транзакция не пройдёт логическое подтверждение и не будет физически закомичена?

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

Грубо кажучи.

Ви виконали

UPDATE posts SET text="My text" WHERE postid=100;

то для вас все спрацює швидко.

Але в цей час інший юзер виконав.
UPDATE posts SET text="My text is better" WHERE postid=100;

до вас прийшла ця транзакція але ваша нода сказала «конфлікт, не буду виконувати». все лишилося по вашому.

але його транзакція попала на ноду яка згенерувала блок і цей блок прийшов на вашу ноду то в результаті у вас виконається цей запит і ваша попередня зміна буде затерта. ваш конкурент по змінах виграв.

Т.е. по-сути изменение будет не отменено, а перезатёрто другим апдейтом, который прилетит позже из мета-информации подтверждённого блока. Это принципиальная разница.

Будет ли считаться конфликтом если в таблице 10 полей, я для какой-то записи апдейчу одно из них, в другой БД апдейтят другое?

Не буде. Конфлікти можуть бути лише відносно одного і того ж запису (ідентифікованого по primary key)

Ясно. В такому випадку буде конфлікт.
насправді, є можливість автоматичного вирішення цього конфлукту. Але лише у випадку моделі — «одна нода — один користувач». ТобтоЮ коли приватний ключ доступний на самій ноді.

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

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

1. Я так понимаю, тип репликации асинхронный?
2. При потери связанности между узлами, OurSQL берёт на себя заботу доставить все изменения на другие узлы?
3. Ясно что производительность не может быть коньком по сравнению с «голым» mysql. Но для себя какие-то тесты производительности делали, сколько update или insert запросов, допустим на aws ec2 инстансе (любом, просто чтоб понимать).
4. Планируется ли режим переключения OurSQL для работы с другой mysql-нодой, если вдруг с текущей что-то сталось.

Так. Реплікація асинхронна
Якщо немає зв’язку із іншими нодами, локальна копія блокчейна буде продовжувати розвиватися. Проте, при відновленні зв’язку відбудеться синхронізація блокчейну , і можливо, декі локальні зміни можуть бути вдкочені , якщо є конфлкти із змінами на інших нодах , і їхній блокчейн «довший».
В цьому плані, все працює так я к і у криптовалютах на Proof of Work блокчейні. При оффлайн роботі будуєтьяся власне відгалуженння блоків, яке на факт, що буде прийнято мережею пізніше

Стосовно продуктивності. Якщо робити зміни на одній ноді, то немає різниці із звичайним mysql сервером.
Але у випадку кластера, можуть бути зміни на інших нодах, які будуть конфлікьувати із вашими, всі ваші швидкі зміни можуть бути відкинуті мережею.
Іншими словами, тут важко робити якісь розрахунки. Консунсус вимагає часу.
Однознайно можна сказати, у випадку блокчейн-реплікації про швидкість оновлень бази не йдеться. Вона буде повільною. Також є ліміт об’єму даних. Блокчейн росте , це завжди треба мати на увазі.

А як у OurSQL з CAP теоремою?

У цьому відношенні поведінка має бути така ж я к і в загалному для blockchain систем.
Бачу в мережі є статті про це. наприклад, тут www.mangoresearch.co/...​ckchain-tech-cap-theorem

Подписаться на комментарии