Size: a a a

Scalability Camp — чат про распределенные системы (и про HPC)

2021 January 31

N

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

RS

Rinat Shigapov in Scalability Camp — чат про распределенные системы (и про HPC)
источник
2021 February 01

VI

Vitaly Isaev in Scalability Camp — чат про распределенные системы (и про HPC)
Zlata Obukhovskaya
А можно примеры систем, где так работает?
https://postgrespro.ru/docs/enterprise/9.6/multimaster#multimaster-architecture

Могу ошибаться, но выглядит как решение, подходящее под описание (CP без лидера)
источник

VI

Vitaly Isaev in Scalability Camp — чат про распределенные системы (и про HPC)
источник

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
Да, хорошая статья. Но он там говорит, что можно использовать, если мы говорим про C как strong consistency( Linearizability). Мы ведь так и делаем. Тут как раз все это понимают.
источник
2021 February 15

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
Rinat Shigapov
Cap применима для простейших систем вроде регистра. Реальные системы сложнее.
все таки вы были бесконечно правы. например из кафки же нельзя сделать CP систему никакими настройками. Потому, что C должно быть strong consistency, а кафка это  sequentional consistency. Но из ZK можно сделать CP, если перед каждым read делать sycn. Интересно про какие еще распределенные нельзя сказать, что они CAP-available?.
источник

RS

Rinat Shigapov in Scalability Camp — чат про распределенные системы (и про HPC)
Nikolay
все таки вы были бесконечно правы. например из кафки же нельзя сделать CP систему никакими настройками. Потому, что C должно быть strong consistency, а кафка это  sequentional consistency. Но из ZK можно сделать CP, если перед каждым read делать sycn. Интересно про какие еще распределенные нельзя сказать, что они CAP-available?.
Лучше вместо CAP ссылаться на модели консистентности. Totally available система может быть максимум causally consistent.

Мне статья от influxdb понравилась в плане вывода не CP и не AP - https://www.influxdata.com/blog/influxdb-clustering-design-neither-strictly-cp-or-ap/
источник
2021 February 16

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
Rinat Shigapov
Лучше вместо CAP ссылаться на модели консистентности. Totally available система может быть максимум causally consistent.

Мне статья от influxdb понравилась в плане вывода не CP и не AP - https://www.influxdata.com/blog/influxdb-clustering-design-neither-strictly-cp-or-ap/
Но можно ли доказать то , что при total availability можно толко EC . все так-таки EC очень слабая гарантия и хотелось бы read your own writes хотя бы. так вот сразу не очевидно, что нельзя хотя бы  read your own writes достичь.
источник
2021 February 19

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
как считаете. вот если смотреть на dropbox и тому подобные системы, которые могут работать с локальными данными и когда-то их синхронизировать с удаленным сервером. Это Multi Leader или Leader Less репликация?
источник

VI

Vitaly Isaev in Scalability Camp — чат про распределенные системы (и про HPC)
Nikolay
как считаете. вот если смотреть на dropbox и тому подобные системы, которые могут работать с локальными данными и когда-то их синхронизировать с удаленным сервером. Это Multi Leader или Leader Less репликация?
Если строго следовать книге Клепманна, то первое
источник

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
Vitaly Isaev
Если строго следовать книге Клепманна, то первое
спасибо. а почему? как это можно доказать?
источник

JS

Jerzy Syrowiecki in Scalability Camp — чат про распределенные системы (и про HPC)
потому что все клиенты являются источниками правды
источник

VI

Vitaly Isaev in Scalability Camp — чат про распределенные системы (и про HPC)
Nikolay
спасибо. а почему? как это можно доказать?
Если не ошибаюсь, Клепманн употребляет multi leader в основном в контексте кросс-ДЦ репликации. То есть инсталляция базы данных на несколько ДЦ, и в каждом ДЦ есть свой лидер и свои ведомые. И между лидерами асинхронная репликация. Если посмотреть с этого угла, то получится так, что оффлайн клиенты, работающие на запись - это тоже как бы кросс-ДЦ распределённая база данных с очень асинхронной репликацией.

А leaderless это паттерн, который может встречаться как при кросс-ДЦ, так и внутри ДЦ. Он используется для достижения максимальной устойчивости. Нет не только лидеров, но и ведомых узлов. Но все умеют обрабатывать запросы на запись.
источник

JS

Jerzy Syrowiecki in Scalability Camp — чат про распределенные системы (и про HPC)
мне казалось, для логики задачи ДЦ не имеют значение
источник

JS

Jerzy Syrowiecki in Scalability Camp — чат про распределенные системы (и про HPC)
внутри ДЦ связи чуть реже рвутся и чуть меньше тормозят, но всё равно рвутся и тормозят
источник

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
Vitaly Isaev
Если не ошибаюсь, Клепманн употребляет multi leader в основном в контексте кросс-ДЦ репликации. То есть инсталляция базы данных на несколько ДЦ, и в каждом ДЦ есть свой лидер и свои ведомые. И между лидерами асинхронная репликация. Если посмотреть с этого угла, то получится так, что оффлайн клиенты, работающие на запись - это тоже как бы кросс-ДЦ распределённая база данных с очень асинхронной репликацией.

А leaderless это паттерн, который может встречаться как при кросс-ДЦ, так и внутри ДЦ. Он используется для достижения максимальной устойчивости. Нет не только лидеров, но и ведомых узлов. Но все умеют обрабатывать запросы на запись.
спасибо. у меня скорее такое понимание, что если клиент всегда работает с выделенным мастером, то это multy muster. например есть 10 клиентов. есть условно регистер X. все они пишут и читают из Х. 5 клиентов работают с мастером А , а 5 с мастером B. и с другими они работать не могут. А если есть 2 машины A and B и каждый клиент может работать с любой из них ( если A доступн, то пишет на A. Если B доступен, то пишет на B), то это Multy Leader
источник
2021 February 20

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
Что думаете ? @vent_2
источник
2021 February 23

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)
Хорошая анимация https://raft.github.io/
источник

S

Slach in Scalability Camp — чат про распределенные системы (и про HPC)
такую же теперь бы и для тарантуловского SWIM бы кто нибудь нарисовал
источник

VI

Vitaly Isaev in Scalability Camp — чат про распределенные системы (и про HPC)
Nikolay
Что думаете ? @vent_2
Прошу прощения, пропустил сообщение. Да, выглядит разумно
источник