Интересно, как при свободной смене сервера обеспечить Read-Your-Writes? Пишем в x=x+1 (=9+1=10 ) в SRV1, репликация асиннхронная(?), после записи SRV1 выпадает из сети, репликация не завершена. Идем на SRV2 и там читаем x==9.
Каждый пир пишет синхронно в локальную базу, и отложенно происходит синхронизация с другими пирами.
Это случай "Clients only talk to the same servers, instead of switching to new ones". В таком сценарии обеспечиваются уровни изоляции и согласованности, обозначенные синим и желтым цветами.
Конкретно с определением Snapshot дело обстоит так - можно обеспечить все требования кроме First-committer-wins. Это требование, в случае использования CRDTs, является излишним (так как нацелено на Lost Update, каковой невозможен с такими типами) тем не менее, оно есть в приводимых формулировках.
Можно как-то по другому назвать, например, Snapshot-CRDTs.
Это следующий этап, КМК. Сначала определяем понятие Consistency, а затем уже можно его связывать с другими, например с Availability и Partition tolerance.
Тут надо на архитектуру смотреть. Мы сейчас "пилим" вот такое:
База распределенная (две копии), репликация асимметрична и асинхронна.
Snapshot Isolation
На клонированной из облака копии Strong Partition Serializable для пишущих транзакций, Eventual Consistency для транзакций на чтение.
Total Available
В нашем случае нет (хотя, видимо, зависит от определений), в "облако" писать нельзя пока активен Local Box (aka Edge Node)
Causal Consistency, Strong Eventual Consistency
Пожалуй, но, в нашем случае, только с применением оргмер. Без них, например, можно получить split brain - в облаке отметить что Local Box "умер", соответственно, с облачной копией теперь можно работать, но и с Local Box технически можно продолжать работать, и тогда, конечно, настанет время удивительных чудес с перемещениями во времени.
А давайте попробуем определить, что значит «нельзя»?
Давайте попробуем. Если уровень изоляции исключает P1, в формулировке "критиков", то движок БД не должен допускать вот таких историй: w1[x]...r2[x]...(c1 or a1)
Выгода в уменьшении на порядок бюджетов на разработку ну и в разы на сопровождение. Наши рестораны мы бы запустили за пару месяцев на hetzner с нуля, ну а так несколько человеко-лет ушло бы (как у извеcтных мне коллег на Azure). Сейчас, конечно, уйдет несколько больше - ввиду глобальности целей.
Касательно Redis - нет, пока не поддерживаем даже в планах, только Cassandra/Scylla/FoundationDB/bbolt. Поправил в статье.
Кластер будет ставиться "прозрачно" для пользователя, просто даете IP-адреса, и все. В случае выхода из строя узла нужен IP адрес нового узла, произойдет горячая замена, без простоев.
От разработчиков будет требоваться уметь в командную строку Linux и проектировать БД на уровне схем. Знание Cassandra и проч. приветствуется, но не требуется.
Таков план. Реальность, возможно, внесет некоторые коррективы, но пока все в допустимых рамках.
Интересный опыт, однако ж, должен признаться, процесс выглядит как "водопад". Т.е. вот, есть пожелания бизнеса, анализируем их, получаем BRD, далее из BRD получаем Vision, ну и так далее по цепочке Анализ - Проектирование - Кодинг.
Опять же, PO не пишет и не приоретизирует истории, эта функция возложена на целую группу Product Team, "истории" нельзя сразу давать команде разработки, предварительно надо пройти еще одну проектную стадию и получить Specs.
Развитие технологий разработки ПО идет по спирали, Водопад -> Agile -> Водопад2.0 ? :)
Крайне желательно раз в несколько месяцев делать руками полный цикл изменения кода. Обычно это выглядит так:
Взять в спринте маленькую задачу на час-другой работы...
Вы не могли бы привести пример использования такого подхода, в котором были выявлены и идентифицированы пробелы в дизайне?
Этот пункт был выведен эмпирическим путем, когда мы поняли, что инсталляция Kafka больше, чем на 12 Тб на единицу кластера драматически рушит производительность.
ISO 81346-12:2018 — Part 12: Construction works and building services
Из этого стандарта я выше привел цитату. Цитата ссылается на 81346‑1:2009 и по смыслу соответствует отечественной верии. Т.е. на 2018 год ничего не изменилось.
Хотя есть четкие стандарты (например ISO 81346) которые определяют их. Если вы будете гуглить, то зачастую схема компонентов может называться схема модулей, а схема модулей — схемой компонентов.
Поискав, я обнаружил отечественный ГОСТ Р 58908.1-2020, который видимо, аналог IEC 81346-1:2009. Там пишут так:
3.6 продукт (product): Предполагаемый или достигнутый результат труда, естественного или искусственного процесса.
3.7 компонент (component): Продукт (изделие), используемый в качестве составной части собранного продукта (изделия), системы или установки.
WASM-модули относительно легко контролировать по использованию CPU и памяти, чего не скажешь про Java. Варианты есть, но они, будем так говорить, не для всех и experimental.
НО разработчики используют TinyGo, в котором сборщик мусора попроще и запускается когда недостаточно места в куче. Если между вызовом proxy_on_memory_allocate и моментом возврата владения в Go нет выделения памяти, то это условно безопасно.
Можно пример, как конкретно выглядит опасный сценарий при использовании go-pointer?
У клиента для этого еще одна база должна быть и именно в нее он и должен всегда писать First.
Интересно, как при свободной смене сервера обеспечить Read-Your-Writes? Пишем в x=x+1 (=9+1=10 ) в SRV1, репликация асиннхронная(?), после записи SRV1 выпадает из сети, репликация не завершена. Идем на SRV2 и там читаем x==9.
Как избежать такой ситуации?
У Вас все-таки такая архитектура:
Это случай "Clients only talk to the same servers, instead of switching to new ones". В таком сценарии обеспечиваются уровни изоляции и согласованности, обозначенные синим и желтым цветами.
Конкретно с определением Snapshot дело обстоит так - можно обеспечить все требования кроме First-committer-wins. Это требование, в случае использования CRDTs, является излишним (так как нацелено на Lost Update, каковой невозможен с такими типами) тем не менее, оно есть в приводимых формулировках.
Можно как-то по другому назвать, например, Snapshot-CRDTs.
Согласно jepsen.io Cursor Stability и выше а также Snapshot Isolation и выше не могут быть Total Available.
Подозреваю, имеет место разница в формулировках либо какие-то особенности работы с данными, типа каждый пир только вставляет данные.
Это следующий этап, КМК. Сначала определяем понятие Consistency, а затем уже можно его связывать с другими, например с Availability и Partition tolerance.
Тут надо на архитектуру смотреть. Мы сейчас "пилим" вот такое:
База распределенная (две копии), репликация асимметрична и асинхронна.
На клонированной из облака копии Strong Partition Serializable для пишущих транзакций, Eventual Consistency для транзакций на чтение.
В нашем случае нет (хотя, видимо, зависит от определений), в "облако" писать нельзя пока активен Local Box (aka Edge Node)
Пожалуй, но, в нашем случае, только с применением оргмер. Без них, например, можно получить split brain - в облаке отметить что Local Box "умер", соответственно, с облачной копией теперь можно работать, но и с Local Box технически можно продолжать работать, и тогда, конечно, настанет время удивительных чудес с перемещениями во времени.
Давайте попробуем. Если уровень изоляции исключает P1, в формулировке "критиков", то движок БД не должен допускать вот таких историй:
w1[x]...r2[x]...(c1 or a1)Выгода в уменьшении на порядок бюджетов на разработку ну и в разы на сопровождение. Наши рестораны мы бы запустили за пару месяцев на hetzner с нуля, ну а так несколько человеко-лет ушло бы (как у извеcтных мне коллег на Azure). Сейчас, конечно, уйдет несколько больше - ввиду глобальности целей.
Касательно Redis - нет, пока не поддерживаем даже в планах, только Cassandra/Scylla/FoundationDB/bbolt. Поправил в статье.
Кластер будет ставиться "прозрачно" для пользователя, просто даете IP-адреса, и все. В случае выхода из строя узла нужен IP адрес нового узла, произойдет горячая замена, без простоев.
От разработчиков будет требоваться уметь в командную строку Linux и проектировать БД на уровне схем. Знание Cassandra и проч. приветствуется, но не требуется.
Таков план. Реальность, возможно, внесет некоторые коррективы, но пока все в допустимых рамках.
Интересный опыт, однако ж, должен признаться, процесс выглядит как "водопад". Т.е. вот, есть пожелания бизнеса, анализируем их, получаем BRD, далее из BRD получаем Vision, ну и так далее по цепочке Анализ - Проектирование - Кодинг.
Опять же, PO не пишет и не приоретизирует истории, эта функция возложена на целую группу Product Team, "истории" нельзя сразу давать команде разработки, предварительно надо пройти еще одну проектную стадию и получить Specs.
Развитие технологий разработки ПО идет по спирали, Водопад -> Agile -> Водопад2.0 ? :)
Спасибо за статью, поучительно. А как API описывается, например, вот это?
Тоже через Hugo?
Вы не могли бы привести пример использования такого подхода, в котором были выявлены и идентифицированы пробелы в дизайне?
Да, Вы правы
В условиях первой задачи вместо "только один вопрос только одному из них" следовало бы написать «только по одному вопросу каждому из них»
А какое "железо" используется, на котором "реляционные БД" и Rabbit не способны обеспечить 15 тысяч RPS?
Можно пояснить, что такое "единица кластера"?
Из этого стандарта я выше привел цитату. Цитата ссылается на 81346‑1:2009 и по смыслу соответствует отечественной верии. Т.е. на 2018 год ничего не изменилось.
Хорошо, вот на "языке оригинала":
Интересная статья, спасибо. Вот такой момент:
Поискав, я обнаружил отечественный ГОСТ Р 58908.1-2020, который видимо, аналог IEC 81346-1:2009. Там пишут так:
WASM-модули относительно легко контролировать по использованию CPU и памяти, чего не скажешь про Java. Варианты есть, но они, будем так говорить, не для всех и experimental.
Можно пример, как конкретно выглядит опасный сценарий при использовании go-pointer?