VI
почему тогда не сделать leader среди N, где N « 100500, а остальные использовать как executor под ними?
да, тоже ценная мысль
Size: a a a
2021 January 29
N
Да нет, скорее всё же один лидер нужен. Например, для задачи консистентного определения состава кластера и управлением членством.
так может, взять какой-нибудь zookeeper? или он столько нод не осилит?
VI
так может, взять какой-нибудь zookeeper? или он столько нод не осилит?
Хотелось бы не иметь зависимостей от внешних сервисов, а выдрать raft, например, из etcd и встроить себе
N
Хотелось бы не иметь зависимостей от внешних сервисов, а выдрать raft, например, из etcd и встроить себе
но зачем?
VI
легче конфигурировать, админить и т.п.
N
Да нет, скорее всё же один лидер нужен. Например, для задачи консистентного определения состава кластера и управлением членством.
не совсем понятно. А почему этого нельзя добиться используя вам zookeeper или etcd?
N
легче конфигурировать, админить и т.п.
я не очень согласен, если честно. Как раз конфигурить и админить проще сервис, про который в интернете 100500 туториалов
N
другое дело, что есть какие-то сложные бизнес-кейсы, которые он может не покрывать
N
Хотелось бы не иметь зависимостей от внешних сервисов, а выдрать raft, например, из etcd и встроить себе
можно не выдирать он идет отдельной библиотекой. например именно его использует cocroachdb
VI
То есть на практике такая задача решается обычно через zookeper и etcd?
Я вот как раз хотел привести пример современных кластерных баз типа cocroach, cassandra, rethinkdb, dynamodb, ignite - я просто не в курсе, неужели они все зависят от некоего внешнего координатора?
Я вот как раз хотел привести пример современных кластерных баз типа cocroach, cassandra, rethinkdb, dynamodb, ignite - я просто не в курсе, неужели они все зависят от некоего внешнего координатора?
N
То есть на практике такая задача решается обычно через zookeper и etcd?
Я вот как раз хотел привести пример современных кластерных баз типа cocroach, cassandra, rethinkdb, dynamodb, ignite - я просто не в курсе, неужели они все зависят от некоего внешнего координатора?
Я вот как раз хотел привести пример современных кластерных баз типа cocroach, cassandra, rethinkdb, dynamodb, ignite - я просто не в курсе, неужели они все зависят от некоего внешнего координатора?
вроде как они все переиспользуют одну-две библиотеки, которые уже написаны и реализуют консенсус
N
clickhouse зависит от zookpeer. cocoroachdb тянет малти-рафт из etcd. кафка все еще тянет ZK, но вот есть известный всем KIP-500, где хотят отказаться. в экосистеме "hadoop" почти везде zk
N
А в Кассандре нет лидера ,насколько я знаю . Там есть паксос только скажем для некого подмножество операций.т.е до определенной версии там его не было . Это leader less архитектура. Только для "лёгких" транзакций сделали
N
Dynamodb - паксос.
N
Nikolay
А в Кассандре нет лидера ,насколько я знаю . Там есть паксос только скажем для некого подмножество операций.т.е до определенной версии там его не было . Это leader less архитектура. Только для "лёгких" транзакций сделали
там даже не паксос, насколько я помню, а какое-то его подмножество. И кассандру ругают, потому что эта поделка иногда разваливается
N
с нуля реализовать полноценный паксос ох как сложно, поэтому большинство систем, которые пишут, что у них паксос, на самом деле реализуют его не полностью
N
там даже не паксос, насколько я помню, а какое-то его подмножество. И кассандру ругают, потому что эта поделка иногда разваливается
Ругают все. Может от не хотят не того , для чего она строилась
.если нужен максимальный сроупут , то тут любое решение с лидером будет медленнее , чем то, что можно добиться в leader less архитектуре
.если нужен максимальный сроупут , то тут любое решение с лидером будет медленнее , чем то, что можно добиться в leader less архитектуре
N
Nikolay
Ругают все. Может от не хотят не того , для чего она строилась
.если нужен максимальный сроупут , то тут любое решение с лидером будет медленнее , чем то, что можно добиться в leader less архитектуре
.если нужен максимальный сроупут , то тут любое решение с лидером будет медленнее , чем то, что можно добиться в leader less архитектуре
максимальный throughput обычно достигается путем отказа от гарантий полной консистентности, насколько я понимаю. Ну и задача о византийских генералах, так или иначе, все равно аналитического решения не имеет :)
N
максимальный throughput обычно достигается путем отказа от гарантий полной консистентности, насколько я понимаю. Ну и задача о византийских генералах, так или иначе, все равно аналитического решения не имеет :)
Если у нас, например 3 ноды. одна из них - лидер. то если пускать все записи через лидер, то не удастся добиться такого сроупута на запись, как когда мы можем записывая на любую из нод.
N
Nikolay
Если у нас, например 3 ноды. одна из них - лидер. то если пускать все записи через лидер, то не удастся добиться такого сроупута на запись, как когда мы можем записывая на любую из нод.
зависит от уровня изоляции же