А какую производительность получили? А то PG не очень удачное решение для подобных задач. А вообще получилось очень похоже на то, что я описывал в https://youtu.be/hXuyT6T3fNU?t=1471, даже код описания сценария похожий.
Нет, нет, Ричардсон при описании саг все перепутал и надавал кучу плохих советов. Я бы вообще эту книжку старался бы не читать, разве что есть уже большой опыт в работе с МСА и очевидные ошибки будут сразу заметны.
А при чем тут блокчейн? 1) В этот источник правды клиент должен свой документ поместить. И при этом достоверность документа начинает считаться как "поместил в источник правды" (что совсем не про "клиент взял и поменял данные"), но это ничем не отличается от "клиент обязан уведомить об изменениях". И это не задача про "а 2) К этому источнику у всех должен быть доступ, причем авторизованный. Вариант "у всех есть вся база" довольно дорогой и довольно сложный при реализации авторизации
В результате - проще всего реализовать схему вообще без блокчейна, с помощью обычного централизованного сервиса, где легко сделать и авторизацию доступа и единый источник данных и нотификации всех заинтересованных и так далее. И никакой ущербности в этом решении нет, оно самое простое, надежное, эффективное и защищенное.
Так это не про достоверность обмена, а про актуальность предоставленной версии, но тут блокчейн тоже не спасет, так как если клиент не отправил документ, то откуда про него кто-нибудь узнает? Это другой кейс вообще и, вообще говоря, не имеет решения вообще, нельзя клиента заставить всем отправлять актуальные данные. Единый же для всех реестр, например, клиентских документов - не требует никакого блочейна, достаточно одной клиентской подписи.
Лучше не использовать инструменты миграции данных только вокруг SQL и не использовать инструменты, порождающие код миграции. Тогда проблем при сопровождении будет гораздо меньше.
Не, лучше не стало. Тесты с записью мерят что угодно, но не скорость работы с диском. Это следует из-за отсутствия разницы запросов с fsync и без него. А про то, что в кластере Тарантул заметно снизил производительность, а Редис увеличил как-то в резюме умудрились пропустить (хотя проблемы скорее всего в настройках). Ну и по результатам кажется, что тестировали не Redis/Tarantool, а особенности сети.
А зачем типу документов поддерживать подпись? Подпись ставится сверху в любом подписанном контейнере, да хоть PGP. Если у создателя несколько подписанных документов - то они все верны, в чем проблема?
На одном узле - никак. Масштабирование только за счет множества узлов. Но пока в блокчейне нигде и не нужно масштабирование, очень низкие реальные нагрузки.
Ну, задачу описанную в конце - проще решить без блокчейна. Там достаточно один раз подписи закрытым ключем и открытый ключ у полицейского. Собственно, почти все задачи блокчейна проще решить без него.
Не, если разработчика нанимают "пилить фичи", то в компании скорее всего не очень хорошо с процессами и пониманием разработки. Вот если нанимают "приносить пользу компании" - это как-то логичнее. Обсуждение фичи с заказчиком часто (почти всегда) оказывается в разы более эффективным инженерным действием, нежели фигачить код.
Да, считать "время разработки" вполне осмысленно (если оно составляет больше трети от общих затрат). Я только против называния этого времени time-to-market, так как ttm от разработки зависит очень, очень мало )
(Нечаянно поставил минус, компенсировал плюсом на другом комментарии, извини).
Если всерьез, то ttm надо считать от появления идеи у бизнеса - и до появления фичи у клиента. И уже после этого считать время отдельных стадий на пути фичи. Считать же только время разработки - бессмысленно, оно редко является существенным относительно прочих затрат.
Платежная. А сколько там идет взаимный клиринг между банками через ЦБ - какая разница. При этом реально транзакция регулируется вообще ЦБР, а не банком.
А какого вида платеж? И сколько времени висят часики? А то по обязательства банка перед тобой меняются по факту прохождения транзакции по твоему счету, клиринг не при чем. Для карточных платежей есть еще интервал между авторизацией и подтверждением, но это вообще про другую схему и только для покупок.
Да нет вопроса. Обязательства банка перед клиентом изменяются в течении секунд. Обязательства банков перед друг другом сводятся в течении банковского дня (в РФ, в других странах может быть и дольше). Никаких "несколько дней" нет.
Хм, Лайтнинг - это тривиальная идея времен самого начала интернета. Какие-нибудь Яндекс.Деньги или PayPal в самом начале (пока не пришла регуляторка) работали примерно также - закидываешь деньги, а потом тратишь, все только на доверии к компании, никаких гарантий. Но при этом стоимость закидывания денег в лайтнинг немаленькая и небыстрая (обычная транзакция в биткойне), сами операции внутри лайтнинга нефига не безопасные и зависят от кучи промежуточных каналов (и факта их наличия). Ну и говорить про "высокую масштабируемость лайтнинга" не совсем корректно, производительность одного канала весьма небольшая, да и во всей сети сейчас довольно мало каналов и очень мало денег, все сеть меньше небольшого российского банка. Ну и еще она сейчас неокупается, нет смысла реализовывать эквайринг на лайтнинге, слишком низкая комиссия. И пока никто не знает, какая реальная пропускная способность лайтнинга.
Фондовый индекс США тоже постоянно растет, уже около ста лет. Но это не делает осмысленным инвестиции в соответствующие фонды.
А какую производительность получили? А то PG не очень удачное решение для подобных задач. А вообще получилось очень похоже на то, что я описывал в https://youtu.be/hXuyT6T3fNU?t=1471, даже код описания сценария похожий.
Нет, нет, Ричардсон при описании саг все перепутал и надавал кучу плохих советов.
Я бы вообще эту книжку старался бы не читать, разве что есть уже большой опыт в работе с МСА и очевидные ошибки будут сразу заметны.
А при чем тут блокчейн?
1) В этот источник правды клиент должен свой документ поместить. И при этом достоверность документа начинает считаться как "поместил в источник правды" (что совсем не про "клиент взял и поменял данные"), но это ничем не отличается от "клиент обязан уведомить об изменениях".
И это не задача про "а
2) К этому источнику у всех должен быть доступ, причем авторизованный. Вариант "у всех есть вся база" довольно дорогой и довольно сложный при реализации авторизации
В результате - проще всего реализовать схему вообще без блокчейна, с помощью обычного централизованного сервиса, где легко сделать и авторизацию доступа и единый источник данных и нотификации всех заинтересованных и так далее.
И никакой ущербности в этом решении нет, оно самое простое, надежное, эффективное и защищенное.
Так это не про достоверность обмена, а про актуальность предоставленной версии, но тут блокчейн тоже не спасет, так как если клиент не отправил документ, то откуда про него кто-нибудь узнает?
Это другой кейс вообще и, вообще говоря, не имеет решения вообще, нельзя клиента заставить всем отправлять актуальные данные.
Единый же для всех реестр, например, клиентских документов - не требует никакого блочейна, достаточно одной клиентской подписи.
Лучше не использовать инструменты миграции данных только вокруг SQL и не использовать инструменты, порождающие код миграции. Тогда проблем при сопровождении будет гораздо меньше.
Не, лучше не стало.
Тесты с записью мерят что угодно, но не скорость работы с диском. Это следует из-за отсутствия разницы запросов с fsync и без него.
А про то, что в кластере Тарантул заметно снизил производительность, а Редис увеличил как-то в резюме умудрились пропустить (хотя проблемы скорее всего в настройках).
Ну и по результатам кажется, что тестировали не Redis/Tarantool, а особенности сети.
А зачем типу документов поддерживать подпись? Подпись ставится сверху в любом подписанном контейнере, да хоть PGP.
Если у создателя несколько подписанных документов - то они все верны, в чем проблема?
На одном узле - никак. Масштабирование только за счет множества узлов. Но пока в блокчейне нигде и не нужно масштабирование, очень низкие реальные нагрузки.
А зачем тут блокчейн, а не просто подпись?
Ну, задачу описанную в конце - проще решить без блокчейна. Там достаточно один раз подписи закрытым ключем и открытый ключ у полицейского.
Собственно, почти все задачи блокчейна проще решить без него.
Не, если разработчика нанимают "пилить фичи", то в компании скорее всего не очень хорошо с процессами и пониманием разработки. Вот если нанимают "приносить пользу компании" - это как-то логичнее.
Обсуждение фичи с заказчиком часто (почти всегда) оказывается в разы более эффективным инженерным действием, нежели фигачить код.
Да, считать "время разработки" вполне осмысленно (если оно составляет больше трети от общих затрат). Я только против называния этого времени time-to-market, так как ttm от разработки зависит очень, очень мало )
(Нечаянно поставил минус, компенсировал плюсом на другом комментарии, извини).
Если всерьез, то ttm надо считать от появления идеи у бизнеса - и до появления фичи у клиента. И уже после этого считать время отдельных стадий на пути фичи. Считать же только время разработки - бессмысленно, оно редко является существенным относительно прочих затрат.
Ты путаешь клиринг и двухфазную карточную оплату - это разные вещи совсем.
Платежная.
А сколько там идет взаимный клиринг между банками через ЦБ - какая разница. При этом реально транзакция регулируется вообще ЦБР, а не банком.
3 дня - это не "ожидаемый", а "максимальный" срок проведения транзакции, потому и пишут. СБП - тот вообще за 30 секунд должен проходить максимум.
А какого вида платеж? И сколько времени висят часики?
А то по обязательства банка перед тобой меняются по факту прохождения транзакции по твоему счету, клиринг не при чем.
Для карточных платежей есть еще интервал между авторизацией и подтверждением, но это вообще про другую схему и только для покупок.
Да нет вопроса.
Обязательства банка перед клиентом изменяются в течении секунд. Обязательства банков перед друг другом сводятся в течении банковского дня (в РФ, в других странах может быть и дольше).
Никаких "несколько дней" нет.
Хм, Лайтнинг - это тривиальная идея времен самого начала интернета. Какие-нибудь Яндекс.Деньги или PayPal в самом начале (пока не пришла регуляторка) работали примерно также - закидываешь деньги, а потом тратишь, все только на доверии к компании, никаких гарантий.
Но при этом стоимость закидывания денег в лайтнинг немаленькая и небыстрая (обычная транзакция в биткойне), сами операции внутри лайтнинга нефига не безопасные и зависят от кучи промежуточных каналов (и факта их наличия). Ну и говорить про "высокую масштабируемость лайтнинга" не совсем корректно, производительность одного канала весьма небольшая, да и во всей сети сейчас довольно мало каналов и очень мало денег, все сеть меньше небольшого российского банка. Ну и еще она сейчас неокупается, нет смысла реализовывать эквайринг на лайтнинге, слишком низкая комиссия.
И пока никто не знает, какая реальная пропускная способность лайтнинга.