Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, gandjustas, Вы писали:

G>>И снова на это насрать. Всем почему-то кажется что доступность и устойчивость к разделению пипец какие важные свойства. На практике исчезающе мало случаев, когда эти свойства нужны.
CK>все случаи когда данные живут более чем в одном дц
Резервное копирование и шардинг не имеют отношения к разделению и доступности если что.
Остальных случаев распределения БД в разных ДЦ исчезающе мало.

Здравствуйте, gandjustas, Вы писали:

G>Резервное копирование и шардинг не имеют отношения к разделению и доступности если что.

я не про них

G>Остальных случаев распределения БД в разных ДЦ исчезающе мало.

почти любой более или менее крупный проект сейчас живет +1 дц, как минимум amer/emea/apac, облака делают это доступным любому

Здравствуйте, gandjustas, Вы писали:

C>>Т.е. произвести кворумное чтение. Упс.
G>Способов много на самом деле, в том числе железные.

Перечисли пожалуйста несколько.

G>Но если рассматривать только возможности СУБД, то да что-то типа кворумного чтения, совмещенного с накладыванием read-lock.

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

G>В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?

Здравствуйте, Denis Ivlev, Вы писали:

DI>И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?
Точно так же можно спросить: а зачем оно надо что-то горизонтально масштабировать, если "вертикальных" ресурсов хватает мягко говоря с головой?

G>>В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.
DI>И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?

Это называется Leader election, и вполне себе масштабируется. Понятно, там всегда будут ограничения и edge cases, но надо смотреть на конкретную топологию сети, выбранные алгоритмы и т.п.

Здравствуйте, Mamut, Вы писали:

G>>>В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.
DI>>И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?

M>Это называется Leader election, и вполне себе масштабируется.

Лол, стригерился на кейворд и выдал статью из википедии, рсдн-эксперты, такие рсдн-эксперты. Будь добр, объясни, как может масштабироваться выделенное, а именно: "Все запросы физически идут в одну ноду".

Здравствуйте, gandjustas, Вы писали:

C>>Т.е. произвести кворумное чтение. Упс.
G>Способов много на самом деле, в том числе железные.
Нет. Надёжный способ ровно один — сделать кворумное чтение. Есть ненадёжные способы — попробовать обойтись избыточными интерконнектами, и молиться, что не будет координированного сбоя на всех из них. Так, например, работает Oracle RAC.

Но это не масштабируется географически ну совсем никак.

G>В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.
Без разницы куда они идут. Это будет нарушение буквы "A", если часть сети будет изолирована. Либо опять же, кворумное чтение на каждый запрос.

Здравствуйте, Denis Ivlev, Вы писали:

M>>Это называется Leader election, и вполне себе масштабируется.
DI>Лол, стригерился на кейворд и выдал статью из википедии, рсдн-эксперты, такие рсдн-эксперты. Будь добр, объясни, как может масштабироваться выделенное, а именно: "Все запросы физически идут в одну ноду".
Лидеров может быть несколько, каждый из которых отвечает за статически назначенный диапазон шардов.

Здравствуйте, Sharov, Вы писали:

G>>>Не выдумывай, репликация делается через ЛОГ, а в нем есть инфа о том, что быдло удалено и добавлено. По крайней мере во взрослых СУБД так.
C>>Все "взрослые СУБД" не являются available.
S>Это почему?
Так как обычно концентрируются на буквах "C" и "P".

Здравствуйте, Cyberax, Вы писали:

C>Лидеров может быть несколько, каждый из которых отвечает за статически назначенный диапазон шардов.

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

Здравствуйте, gandjustas, Вы писали:

C>>Все "взрослые СУБД" не являются available.
G>Конечно не являются. В терминах CAP. И всем на это насрать. Кроме маркетологов NoSQL.
Или тем, кому реально нужна availability. Например, в этом году хранилище данных для Amazon в тестах обрабатывало в пике 1 миллиард запросов в секунду. Реальная пиковая нагрузка была где-то треть от этого.

C>>Ну вот потому они и не могут быть available и partition tolerant. Поэтому все "взрослые СУБД" на практике и ограничены одним сервером (максимум, небольшим кластером с быстрыми интерконнектами между узлами).
G>И снова на это насрать. Всем почему-то кажется что доступность и устойчивость к разделению пипец какие важные свойства. На практике исчезающе мало случаев, когда эти свойства нужны.
Это тоже на практике уже не так. Достаточно много клиентов хотят иметь географическую избыточность, чтобы пережить локальный конец света в отдельном ЦОД.

Здравствуйте, Denis Ivlev, Вы писали:

C>>Лидеров может быть несколько, каждый из которых отвечает за статически назначенный диапазон шардов.
DI>1. Это мы уже сами додумываем архитектуру, написано было вполне однозначно: "Все запросы физически идут в одну ноду".
DI>2. Но и в предложенной тобой архитектуре мы не решили добились одновременно соблюдения всех трех пунктов.
Да, это чисто практическое решение, когда не нужны атомарные записи в несколько шардов.

DI>Лол, стригерился на кейворд и выдал статью из википедии, рсдн-эксперты, такие рсдн-эксперты. Будь добр, объясни, как может масштабироваться выделенное, а именно: "Все запросы физически идут в одну ноду".

Какие у тебя проблемы с «запросы идут в одну ноду»?

Цитирую специально для тебя еще раз, выделено:

Понятно, там всегда будут ограничения и edge cases, но надо смотреть на конкретную топологию сети, выбранные алгоритмы и т.п.

Смешно, когда про теоретиков говорят люди, которые готовы обсуждать некое сферовакуумное масштабирование в полном отрыве от реальности.

Здравствуйте, Mamut, Вы писали:

DI>>Лол, стригерился на кейворд и выдал статью из википедии, рсдн-эксперты, такие рсдн-эксперты. Будь добр, объясни, как может масштабироваться выделенное, а именно: "Все запросы физически идут в одну ноду".

M>Какие у тебя проблемы с «запросы идут в одну ноду»?

M>Цитирую специально для тебя еще раз, выделено:

M>

M>Понятно, там всегда будут ограничения и edge cases, но надо смотреть на конкретную топологию сети, выбранные алгоритмы и т.п.

M>Смешно, когда про теоретиков говорят люди, которые готовы обсуждать некое сферовакуумное масштабирование в полном отрыве от реальности.

чувак, сосредоточся. тебя макнули в конкретную майкрософтскую технологию failover cluster. пойди и почитай как оно работает что бы не попадать вот так в просак. нихрена там не масштабируется, потому как требуется полноценная консистентность и никакие Leader election в плане масштабирования не помогут.

Gt_>чувак, сосредоточся. тебя макнули в конкретную майкрософтскую технологию failover cluster.

В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

По этому описанию это leader election

Gt_> пойди и почитай как оно работает что бы не попадать вот так в просак.

Читаю: https://docs.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview

Описан consensus protocol. Про единый физический мастер ничего не написано (или лень искать). Возможно, раньше был единый мастер, теперь заменили.

Gt_> нихрена там не масштабируется, потому как требуется полноценная консистентность и никакие Leader election в плане масштабирования не помогут.

Опять же какие-то сферовакуумные требования.

Здравствуйте, Mamut, Вы писали:

Gt_>>чувак, сосредоточся. тебя макнули в конкретную майкрософтскую технологию failover cluster.

M>

M>В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

M>По этому описанию это leader election

Gt_>> пойди и почитай как оно работает что бы не попадать вот так в просак.

M>Читаю: https://docs.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview

M>Описан consensus protocol. Про единый физический мастер ничего не написано (или лень искать). Возможно, раньше был единый мастер, теперь заменили.

Gt_>> нихрена там не масштабируется, потому как требуется полноценная консистентность и никакие Leader election в плане масштабирования не помогут.

M>Опять же какие-то сферовакуумные требования.

смеются над твоими верованиями буд-то это масштабируется.

Это называется Leader election, и вполне себе масштабируется.

конкретно майкрософт failover cluster не масштабируется, потому как настоящая консистентность требуется.

Здравствуйте, Cyberax, Вы писали:

C>Лидеров может быть несколько, каждый из которых отвечает за статически назначенный диапазон шардов.

Лидеры отвечают только за маршрутизацию\балансировку в шарды или сами могут сохранять у себя данные?

Здравствуйте, Cyberax, Вы писали:

C>>>Все "взрослые СУБД" не являются available.
S>>Это почему?
C>Так как обычно концентрируются на буквах "C" и "P".

C "C" понятно, а для одной "взрослой" "Р" зачем? Или речь о кластере из "взрослых" идет?

Здравствуйте, Mamut, Вы писали:

DI>>Лол, стригерился на кейворд и выдал статью из википедии, рсдн-эксперты, такие рсдн-эксперты. Будь добр, объясни, как может масштабироваться выделенное, а именно: "Все запросы физически идут в одну ноду".

M>Какие у тебя проблемы с «запросы идут в одну ноду»?

Как это может горизонтально масштабироваться? Ты так и не ответил. Нечего сказать — гуляй мимо.

M>Цитирую специально для тебя еще раз, выделено:

M>

M>Понятно, там всегда будут ограничения и edge cases, но надо смотреть на конкретную топологию сети, выбранные алгоритмы и т.п.

И? Ну родишь хоть что-то или так и будешь ломать комедию?

M>Смешно, когда про теоретиков говорят люди, которые готовы обсуждать некое

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

M>сферовакуумное масштабирование в полном отрыве от реальности.

Почему это оно сферовакуумное? Если ты никогда не имел данных или запросов столько, что не один сервер не справится, то это не значит, что у других таких задач нет.

Здравствуйте, Cyberax, Вы писали:

C>Неверно. Например, для DynamoDB в AWS есть формальное доказательство availability и partition tolerance.
availability в формальных терминах CAP или в каких-то своих?
Если в CAP — рад за них, но в практическом смысле применимость CAP это не увеличивает ни как.