Применение блокчейна в компании, офисе?

[bizalaz]

Эту систему нельзя подменить, она может записать все самое нужное и никто не подделает результат! Вот длячего она нужна вот какая ценность

[kzv]

Лучше вообще разрешить майнить только компьютеру босса.
Ну боссу-то сотрудники доверяют?
И тогда вообще никаких проблем ни с майнингом, ни с атакой-51.

Ой. Только опять централизованное решение получилось. Смешно, да?

PS/ Если у вас закрыт алгоритм хэширования - где гарантия что в нем нет бэкдора?

Ну в принципе, даже с компьютером босса задача бэкапов (и восстановления) решается, а значит тоже хорошо. Децентрализация майнинга нужна для непрерывной работы, но если в офисе все бизнес-процессы завязаны на босса, а босса посадили в тюрьму, то работа офисной базы может быть уже и не актуальна. Опять же если на компе босса вентилятор здохнет - вся база перестанет работать? Это уже не очень приятно...

От бэкдора защитит хорошая зарплата программиста, который делал офисный блокчейн ))

[fxpc]

Лучше вообще разрешить майнить только компьютеру босса.
Ну боссу-то сотрудники доверяют?
И тогда вообще никаких проблем ни с майнингом, ни с атакой-51.

Ой. Только опять централизованное решение получилось. Смешно, да?

PS/ Если у вас закрыт алгоритм хэширования - где гарантия что в нем нет бэкдора?

Ну в принципе, даже с компьютером босса задача бэкапов (и восстановления) решается, а значит тоже хорошо. Децентрализация майнинга нужна для непрерывной работы, но если в офисе все бизнес-процессы завязаны на босса, а босса посадили в тюрьму, то работа офисной базы может быть уже и не актуальна. Опять же если на компе босса вентилятор здохнет - вся база перестанет работать? Это уже не очень приятно...

От бэкдора защитит хорошая зарплата программиста, который делал офисный блокчейн ))

Майнинг тебе зачем? Боссу нужна пачка удалённых серверов, которые все мастеры, сдохнет один из них - сеть этого даже не заметит.

[kzv]

Ну вот я не админ и туго в этом понимаю.
Расскажи по шагам, как мне бэкапить базу данных в реальном времени и как восстановиться из бэкапа если комп выключился пока я в отпуске был?
В базах данных я тоже не силен, но уверен что с склайтом такое точно невозможно. Наверное с мускулом тогда? Вот прямо по шагам:
1. установил пакет хх для линукса, yy для винды
2. запустил его с параметрами zzz
3. проделал то же самое еще на двух компах
4. подождал
5. убедился, что на всех компах база одинаковая
6. выключил комп 1
7. внес изменения в базу на компе 2
8. убедился, что изменения видны на компе 3
9. включил комп 1 подождал и убедился, что изменения видны на компе 1

При этом мы не делаем дамп всей базы, а записываем только последние изменения.
Возможно описанное мной в мускуле или еще в какой-то базе?

[amaclin1]

Расскажи по шагам, как мне бэкапить базу данных в реальном времени и как
восстановиться из бэкапа если комп выключился пока я в отпуске был?

Тут есть такая вещь https://ru.wikipedia.org/wiki/Теорема_CAP
Есть N серверов, которые работают синхронно. Если один получает "транзакцию"
(не обязательно транзакцию перевода - любую запись в базу данных) - то и он
и все остальные эту "транзакцию" вставляют. Если выключился один сервер -
ничего страшного - включится и потом синхронизирует свою базу с остальными.

Как это решается - я не знаю. Но факт в том, что нормальный админ такие задачи
щелкает не выпуская бутылку пива из левой руки пока горит сигарета.
Конечно, если у вас биткойн головного мозга, то вы не поверите, что такие
задачи успешно уже решены всеми и везде.

Хуже - если случается обрыв связи. Что делать отделению сбербанка, если
порвалась связь с остальным миром? Или вот какая-нибудь "Новая Зеландия" - там
два острова, северный и южный. Предположим, что связи между ними нет.
Как ихнему сбербанку работать если база не синхронизирируется?

Но эту задачу не решает и блокчейн тоже.

[fxpc]

Ну вот я не админ и туго в этом понимаю.
Расскажи по шагам, как мне бэкапить базу данных в реальном времени и как восстановиться из бэкапа если комп выключился пока я в отпуске был?
В базах данных я тоже не силен, но уверен что с склайтом такое точно невозможно. Наверное с мускулом тогда? Вот прямо по шагам:
1. установил пакет хх для линукса, yy для винды
2. запустил его с параметрами zzz
3. проделал то же самое еще на двух компах
4. подождал
5. убедился, что на всех компах база одинаковая
6. выключил комп 1
7. внес изменения в базу на компе 2
8. убедился, что изменения видны на компе 3
9. включил комп 1 подождал и убедился, что изменения видны на компе 1

При этом мы не делаем дамп всей базы, а записываем только последние изменения.
Возможно описанное мной в мускуле или еще в какой-то базе?

В мускуле, постгре и даже во многих nosql это не сложно. Есть репликация из коробки, есть дополнительные утилиты. Слейва можно хоть на год терять, главное чтобы мастер был жив, но можно назначить все серверы мастерами, тогда теряй любой. Тебе ни в чём не нужно убеждаться, это делает сам движок БД. У мускула ранее проскакивали проблемы с консистентностью да и то что его оракл приобрёл не очень отрадный факт, поэтому из реляционных рекомендую постгре, вот здесь можешь составить представление о глубине глубин > https://eax.me/postgresql-replication/

[kzv]

В мускуле, постгре и даже во многих nosql это не сложно. Есть репликация из коробки, есть дополнительные утилиты. Слейва можно хоть на год терять, главное чтобы мастер был жив, но можно назначить все серверы мастерами, тогда теряй любой. Тебе ни в чём не нужно убеждаться, это делает сам движок БД. У мускула ранее проскакивали проблемы с консистентностью да и то что его оракл приобрёл не очень отрадный факт, поэтому из реляционных рекомендую постгре, вот здесь можешь составить представление о глубине глубин > https://eax.me/postgresql-replication/

А точно можно все сервера мастерами делать?
Имхуется хоть один слейв должен присутствовать. Но как при этом разруливаются конфликты? Это все у постгре в коробке есть?

[amaclin1]

А точно можно все сервера мастерами делать?

С учетом CAP-теоремы можно.
Если сервер включается и обнаруживает что у него база устарела - он её подтягивает.
Если сервер обнаруживает что у него нет связи с частью (или со всеми) другими серверами -
то вы определитесь чем вы хотите пожертвовать - C или А

[fxpc]

В мускуле, постгре и даже во многих nosql это не сложно. Есть репликация из коробки, есть дополнительные утилиты. Слейва можно хоть на год терять, главное чтобы мастер был жив, но можно назначить все серверы мастерами, тогда теряй любой. Тебе ни в чём не нужно убеждаться, это делает сам движок БД. У мускула ранее проскакивали проблемы с консистентностью да и то что его оракл приобрёл не очень отрадный факт, поэтому из реляционных рекомендую постгре, вот здесь можешь составить представление о глубине глубин > https://eax.me/postgresql-replication/

А точно можно все сервера мастерами делать?
Имхуется хоть один слейв должен присутствовать. Но как при этом разруливаются конфликты? Это все у постгре в коробке есть?

Зависит от того, какого результата ты хочешь добиться. У них там распределённый транзакционный планировщик.
https://wiki.postgresql.org/wiki/Multimaster

[kzv]

В мускуле, постгре и даже во многих nosql это не сложно. Есть репликация из коробки, есть дополнительные утилиты. Слейва можно хоть на год терять, главное чтобы мастер был жив, но можно назначить все серверы мастерами, тогда теряй любой. Тебе ни в чём не нужно убеждаться, это делает сам движок БД. У мускула ранее проскакивали проблемы с консистентностью да и то что его оракл приобрёл не очень отрадный факт, поэтому из реляционных рекомендую постгре, вот здесь можешь составить представление о глубине глубин > https://eax.me/postgresql-replication/

А точно можно все сервера мастерами делать?
Имхуется хоть один слейв должен присутствовать. Но как при этом разруливаются конфликты? Это все у постгре в коробке есть?

Зависит от того, какого результата ты хочешь добиться. У них там распределённый транзакционный планировщик.
https://wiki.postgresql.org/wiki/Multimaster

Че-то я не вкурил по ссылке, где там мультимастер кроме заголовка ((
Есть русские доки с примерами?

[fxpc]

В мускуле, постгре и даже во многих nosql это не сложно. Есть репликация из коробки, есть дополнительные утилиты. Слейва можно хоть на год терять, главное чтобы мастер был жив, но можно назначить все серверы мастерами, тогда теряй любой. Тебе ни в чём не нужно убеждаться, это делает сам движок БД. У мускула ранее проскакивали проблемы с консистентностью да и то что его оракл приобрёл не очень отрадный факт, поэтому из реляционных рекомендую постгре, вот здесь можешь составить представление о глубине глубин > https://eax.me/postgresql-replication/

А точно можно все сервера мастерами делать?
Имхуется хоть один слейв должен присутствовать. Но как при этом разруливаются конфликты? Это все у постгре в коробке есть?

Зависит от того, какого результата ты хочешь добиться. У них там распределённый транзакционный планировщик.
https://wiki.postgresql.org/wiki/Multimaster

Че-то я не вкурил по ссылке, где там мультимастер кроме заголовка ((
Есть русские доки с примерами?

http://www.zaweel.ru/2016/07/postgresql_22.html#sec:bdr
http://bdr-project.org/docs/stable/index.html

Русских доков пока не попадалось.

[DevilOper]

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

С чего ты это взял? 2 сервера могут разом умереть и пи*дец ЦБ. Этих серверов просто тьма и находятся они в разных регионах. ЦБ вряд ли хранит данные заграницей, скорее всего серверы дублируются как минимум во всех региональных филиалах.

Это вряд ли. ЦБ конечно дебилы, но не настолько чтобы хранить копию своей базы в каждом зажопинском филиале

Почитайте хотя бы в той же вякипедии про двойную запись и [двойную] бухгалтерскую проводку - узнаете для себя много нового.

(Вот кстати, одно дело, когда в этих ваших интернетах(с), в общем-то, дилетанты вопят "блокчейн! блокчейн!" - но когда глава Сбера ни сном, ни духом об основах бухгалтерии... )

[kzv]

В мускуле, постгре и даже во многих nosql это не сложно. Есть репликация из коробки, есть дополнительные утилиты. Слейва можно хоть на год терять, главное чтобы мастер был жив, но можно назначить все серверы мастерами, тогда теряй любой. Тебе ни в чём не нужно убеждаться, это делает сам движок БД. У мускула ранее проскакивали проблемы с консистентностью да и то что его оракл приобрёл не очень отрадный факт, поэтому из реляционных рекомендую постгре, вот здесь можешь составить представление о глубине глубин > https://eax.me/postgresql-replication/

А точно можно все сервера мастерами делать?
Имхуется хоть один слейв должен присутствовать. Но как при этом разруливаются конфликты? Это все у постгре в коробке есть?

Зависит от того, какого результата ты хочешь добиться. У них там распределённый транзакционный планировщик.
https://wiki.postgresql.org/wiki/Multimaster

Че-то я не вкурил по ссылке, где там мультимастер кроме заголовка ((
Есть русские доки с примерами?

http://www.zaweel.ru/2016/07/postgresql_22.html#sec:bdr
http://bdr-project.org/docs/stable/index.html

Русских доков пока не попадалось.

Почитал доки официальные и не очень. Выводы
1. Про эту вундервафлю начали говорить еще в 2014, но зарелизили в ноябре 2017
2. Оно страшно сырое, разрабы даже под винду ее собрать не осилили
3. Оно звучит привлекательно и когда-нибудь может стать конкурентом блокчейна, но пока ее максимум это 48 нод
4. Конфликты разруливают метками времени... Лол, где-то я про подобное слышал? )))

Итог: до настоящего времени ничего проще, эффективнее и надежнее блокчейна для автосинхронизирующихся бд не придумано.

Касаемо того, как это решают админы без блокчейна... Я расскажу.
90% админов решают задачу бэкапов установкой галочки в панели хостинга. Остальные изобретают кривые велосипеды с передним приводом, самый лучший из которых это дамп в архив на дропбокс всей базы по таймеру.

[amaclin1]

Итог: до настоящего времени ничего проще, эффективнее и надежнее блокчейна для автосинхронизирующихся бд не придумано.

Щито, блеать? Эффективнее?
Я вам еще раз повторяю - иммутабельность блокчейна биткойна существует сегодня
потому что 100500 асиков молотят хэши. А 100500 асиков молотят хэши потому что
100500 долбоёбов мечтают заработать на этом деньги. То есть иммутабельность -
это не свойство технологии блокчейна. Это то что вы покупаете за свои деньги в дополнение
к обычной LevelDB базе данных.

Как только вы отказываетесь от невьебенного расхода электричества - вся надежность
вашего блокчейна накрывается пиздой. Появляются цепочки, переписывающие
состояние базы за любое время в прошлое. И потом хуй разберешь по такой базе
что кто кому отправлял.

[kzv]

Я говорю про технологию блокчейн, а не про конкретную реализацию этой технологии в битке.
Как эффективно майнить блоки это отдельная тема.

[fxpc]

Я говорю про технологию блокчейн, а не про конкретную реализацию этой технологии в битке.
Как эффективно майнить блоки это отдельная тема.

Блокчейн это WAL, где транзакции объединены в блоки майнерами. Никаких мастер-мастер конфигураций в крипте нет, мастер там тот, кто отправил годный блок в сеть. Блоки и майнинг в крипте используются, потому что все ноды являются недоверенными. Если ты в компании не веришь никому, включая центральный сервер с электронной подписью директора, то это не компания, а сборище анархистов, в остальных случаях репликация тривиальна и придуманной тобой проблемы не существует. Что касается используемой БД на сервере/клиенте, это вообще не относится к формату репликации, в том же битке используется LevelDB, но ничего кроме производительности особо не изменится если заменить на MySQL или PostreSQL, для синхронизации ноды по-прежнему будут обмениваться всё теми же блоками. Не надо пытаться откосить от проектирования архитектуры приложения, путём ухода на блокчейн, это не сработает и получится очередной коин для влошенцев, а не решение востребованное бизнесом.

[kzv]

Блокчейн это WAL, где транзакции объединены в блоки майнерами. Никаких мастер-мастер конфигураций в крипте нет, мастер там тот, кто отправил годный блок в сеть. Блоки и майнинг в крипте используются, потому что все ноды являются недоверенными. Если ты в компании не веришь никому, включая центральный сервер с электронной подписью директора, то это не компания, а сборище анархистов, в остальных случаях репликация тривиальна и придуманной тобой проблемы не существует. Что касается используемой БД на сервере/клиенте, это вообще не относится к формату репликации, в том же битке используется LevelDB, но ничего кроме производительности особо не изменится если заменить на MySQL или PostreSQL, для синхронизации ноды по-прежнему будут обмениваться всё теми же блоками. Не надо пытаться откосить от проектирования архитектуры приложения, путём ухода на блокчейн, это не сработает и получится очередной коин для влошенцев, а не решение востребованное бизнесом.

В любой распределенной базе все новые транзакции должны по дефолту считаться недостоверными. Электронная подпись решает проблему валидности, но не решает проблему очередности. Очередность можно узнать только из временнЫх меток. Но на распределенной системе временнЫе метки могут быть инвалидными по умыслу или без умысла. Чтобы транзакции были всегда в правильной очередности нужен алгоритм консенсуса.

[amaclin1]

В любой распределенной базе все новые транзакции должны по дефолту считаться недостоверными. Электронная подпись решает проблему валидности, но не решает проблему очередности.

Давай так рассуждать:
Проблему очередности и временных меток мы в принципе решить не можем.
Так что нет проблемы очередности. Есть проблема двойного использования.
В централизованной системе этой проблемы не существует. Как только мы
пытаемся отойти от централизованной системы, например, сделать два мастер-сервера
то система становится гетерогенной - с точки зрения юзера мы по-прежнему обращаемся
к какому-то одному серверу. Но администратор-то знает, что работает дупликация,
рейды там всякие и дублирования по дата-центрам. То есть ядро системы уже
либо децентрализовано и вступает с силу теорема CAP либо мы все-таки назначаем
в системе "самый главный сервер", который разруливает все конфликтные ситуации.

В биткойн-подобных системах мы допустили отказ от главного сервера, заменив
его на "голосование всех участников". Но это ведет к тому, что незаинтересованный
финансово участник забивает на голосование и продает свой голос потенциальному
злоумышленнику.

[fxpc]

Блокчейн это WAL, где транзакции объединены в блоки майнерами. Никаких мастер-мастер конфигураций в крипте нет, мастер там тот, кто отправил годный блок в сеть. Блоки и майнинг в крипте используются, потому что все ноды являются недоверенными. Если ты в компании не веришь никому, включая центральный сервер с электронной подписью директора, то это не компания, а сборище анархистов, в остальных случаях репликация тривиальна и придуманной тобой проблемы не существует. Что касается используемой БД на сервере/клиенте, это вообще не относится к формату репликации, в том же битке используется LevelDB, но ничего кроме производительности особо не изменится если заменить на MySQL или PostreSQL, для синхронизации ноды по-прежнему будут обмениваться всё теми же блоками. Не надо пытаться откосить от проектирования архитектуры приложения, путём ухода на блокчейн, это не сработает и получится очередной коин для влошенцев, а не решение востребованное бизнесом.

В любой распределенной базе все новые транзакции должны по дефолту считаться недостоверными. Электронная подпись решает проблему валидности, но не решает проблему очередности. Очередность можно узнать только из временнЫх меток. Но на распределенной системе временнЫе метки могут быть инвалидными по умыслу или без умысла. Чтобы транзакции были всегда в правильной очередности нужен алгоритм консенсуса.

Проверка достоверности транзакций должна быть в логике приложения, БД не обязана проверять можешь ты увеличить или уменьшить значение или нет, когда нет реляций. Проблему очерёдности решает журнал, если журналы у мастеров противоречат друг другу, то эти изменения откатятся в ту же секунду когда их пытаются внести с уведомлением пользователей об ошибке. По-моему ты не представляешь насколько быстро это происходит в централизованной архитектуре. Если цена ошибки слишком высока, то используй 1 мастер, причём мастером может быть лишь представление, за которым скрывается целый датацентр.

Объясни какую проблему бизнеса ты хочешь решить, а то совсем непонятно.

[DevilOper]

Я вам более того скажу, в известных пределах даже очерёдность не особо важна - например, два сообщения от одного участника в разных ветках этого форума.