N
мне не видно такой тенденции. В пейперах скорее про CaP говорят , чем про что то другое. Если ошибаюсь, то прошу привести какие то известные пейперах или другие источники на которых можно было бы сослаться
Size: a a a
2021 January 31
2021 February 01
VI
А можно примеры систем, где так работает?
https://postgrespro.ru/docs/enterprise/9.6/multimaster#multimaster-architecture
Могу ошибаться, но выглядит как решение, подходящее под описание (CP без лидера)
Могу ошибаться, но выглядит как решение, подходящее под описание (CP без лидера)
N
Да, хорошая статья. Но он там говорит, что можно использовать, если мы говорим про C как strong consistency( Linearizability). Мы ведь так и делаем. Тут как раз все это понимают.
2021 February 15
N
Cap применима для простейших систем вроде регистра. Реальные системы сложнее.
все таки вы были бесконечно правы. например из кафки же нельзя сделать CP систему никакими настройками. Потому, что C должно быть strong consistency, а кафка это sequentional consistency. Но из ZK можно сделать CP, если перед каждым read делать sycn. Интересно про какие еще распределенные нельзя сказать, что они CAP-available?.
RS
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/
Мне статья от influxdb понравилась в плане вывода не CP и не AP - https://www.influxdata.com/blog/influxdb-clustering-design-neither-strictly-cp-or-ap/
2021 February 16
N
Лучше вместо CAP ссылаться на модели консистентности. Totally available система может быть максимум causally consistent.
Мне статья от influxdb понравилась в плане вывода не CP и не AP - https://www.influxdata.com/blog/influxdb-clustering-design-neither-strictly-cp-or-ap/
Мне статья от 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
как считаете. вот если смотреть на dropbox и тому подобные системы, которые могут работать с локальными данными и когда-то их синхронизировать с удаленным сервером. Это Multi Leader или Leader Less репликация?
VI
Nikolay
как считаете. вот если смотреть на dropbox и тому подобные системы, которые могут работать с локальными данными и когда-то их синхронизировать с удаленным сервером. Это Multi Leader или Leader Less репликация?
Если строго следовать книге Клепманна, то первое
N
Если строго следовать книге Клепманна, то первое
спасибо. а почему? как это можно доказать?
JS
потому что все клиенты являются источниками правды
VI
Nikolay
спасибо. а почему? как это можно доказать?
Если не ошибаюсь, Клепманн употребляет multi leader в основном в контексте кросс-ДЦ репликации. То есть инсталляция базы данных на несколько ДЦ, и в каждом ДЦ есть свой лидер и свои ведомые. И между лидерами асинхронная репликация. Если посмотреть с этого угла, то получится так, что оффлайн клиенты, работающие на запись - это тоже как бы кросс-ДЦ распределённая база данных с очень асинхронной репликацией.
А leaderless это паттерн, который может встречаться как при кросс-ДЦ, так и внутри ДЦ. Он используется для достижения максимальной устойчивости. Нет не только лидеров, но и ведомых узлов. Но все умеют обрабатывать запросы на запись.
А leaderless это паттерн, который может встречаться как при кросс-ДЦ, так и внутри ДЦ. Он используется для достижения максимальной устойчивости. Нет не только лидеров, но и ведомых узлов. Но все умеют обрабатывать запросы на запись.
JS
мне казалось, для логики задачи ДЦ не имеют значение
JS
внутри ДЦ связи чуть реже рвутся и чуть меньше тормозят, но всё равно рвутся и тормозят
N
Если не ошибаюсь, Клепманн употребляет multi leader в основном в контексте кросс-ДЦ репликации. То есть инсталляция базы данных на несколько ДЦ, и в каждом ДЦ есть свой лидер и свои ведомые. И между лидерами асинхронная репликация. Если посмотреть с этого угла, то получится так, что оффлайн клиенты, работающие на запись - это тоже как бы кросс-ДЦ распределённая база данных с очень асинхронной репликацией.
А leaderless это паттерн, который может встречаться как при кросс-ДЦ, так и внутри ДЦ. Он используется для достижения максимальной устойчивости. Нет не только лидеров, но и ведомых узлов. Но все умеют обрабатывать запросы на запись.
А leaderless это паттерн, который может встречаться как при кросс-ДЦ, так и внутри ДЦ. Он используется для достижения максимальной устойчивости. Нет не только лидеров, но и ведомых узлов. Но все умеют обрабатывать запросы на запись.
спасибо. у меня скорее такое понимание, что если клиент всегда работает с выделенным мастером, то это multy muster. например есть 10 клиентов. есть условно регистер X. все они пишут и читают из Х. 5 клиентов работают с мастером А , а 5 с мастером B. и с другими они работать не могут. А если есть 2 машины A and B и каждый клиент может работать с любой из них ( если A доступн, то пишет на A. Если B доступен, то пишет на B), то это Multy Leader
2021 February 20
N
Что думаете ? @vent_2
2021 February 23
S
Nikolay
Хорошая анимация https://raft.github.io/
такую же теперь бы и для тарантуловского SWIM бы кто нибудь нарисовал
VI
Nikolay
Что думаете ? @vent_2
Прошу прощения, пропустил сообщение. Да, выглядит разумно