клиент отправляет транзакцию секвенсеру, секвенсор подтверждает ее
Да? А так можно?
А вы понимаете, что в кальвине, в отличие от классических систем типа Oracle, исход транзакции неизвестен до тех пор, пока вся последовательность операций не будет выполнена планировщиком? То есть секвенсер может сказать, что он понял, чего от него хочет приложение, но не может гарантировать выполнение транзакции.
Да. Достаточно в момент сбоя всем оставшимся секвенсерам/планировщикам написать, какой последний пакет они видели от пропавшего секвенсера, и выбрать наименьший. Ну или пусть тот, у кого есть наибольший, поделится с остальными – можно через Zookeeper.
Секвенсоры-шарды вообще друг-другу ничего не посылают -- они шлют операции планировщикам всех шардов одной реплики.
Ну ок, я немного упростил картину. Конечно, есть отдельные узлы-планировщики. Но общую ситуацию это не меняет.
Вы же понимаете, что для репликации никакой консенсус (и zookeeper) не нужен. Репликация хоть в MS SQL, хоть в Oracle хоть где прекрасно работает без zookeeper’а. Потому что лидер жёстко зафиксирован. Поэтому гонять все операции через Zookeeper – это, конечно, хорошее быстрое решение для академического проекта, но совсем не обязательное условие для коммерческого продукта.
Секвенсоры-реплики дублируют друг друга, они на равных создают пачки операций и согласовывают их
Зачем секвенсерам их согласовывать? Это совершенно лишнее.
Вам о чём-нибудь говорит аббревиатура CRDT? Так вот, секвенсер – это примерно то же самое. Каждый секвенсер формирует пачку транзакций независимо от остальных секвенсеров. Планировщик (или, как я писал в предыдущих комментариях, секвенсер, но сути это не меняет) руководствуется двумя простыми правилами:
Транзакции упорядочиваются по номеру эпохи, а внутри эпохи – по номеру секвенсера.
Вся эпоха, сгенерированная секвенсером, выполняется подряд, без прерывания.
Этих правил достаточно, чтобы на каждом планировщике последовательность транзакций была одна и та же, не надо ничего согласовывать.
работать как ни в чем ни бывало при отказе одной из реплик
Вот как раз при отказе одной из реплик всем надо договориться, какая последняя эпоха в этой реплике. Это единственное место, где нужен консенсус.
но ZooKeeper по прежнему остается почти безальтернативным
Да в том-то и дело, что через него никто не пускает большой поток данных, поэтому никто и не переделывает. Ну посмотрите, например, много ли людей собирают свои компьютеры, когда можно купить ноутбук или моноблок?
Вот Confluent захотел избавиться от Zookeeper – и избавился. Не до конца понимаю, зачем, но внезапно выяснилось, что так можно.
функция автоматического принятия решения о failover производится некоторым внешним агентом
Давно я не работал с Oracle, забыл фирменную продуктовую линейку :) Этот внешний компонент называется Observer и тоже входит в поставку Oracle RDBMS.
ZooKeeper составляет основную сложность системы и его ничем нельзя заменить -- checked.
ZooKeeper определяет производительность выполнения транзакций -- checked.
Нет. Это ниоткуда не следует.
Ещё раз. У нас есть несколько секвенсеров. Можно назвать их по алфавиту – A, B, C... Можно также договориться, что операции сортируются по номеру эпох, а внутри эпохи – по номеру секвенсера. То есть секвенсер A отправляет свои операции секвенсерам B и C, и никакого консенсуса не нужно, потому что никто, кроме секвенсера A, не может сгенерировать операции от секвенсера A. Никакого Zookeeper’а здесь нет.
Теперь посмотрим на ситуацию глазами секвенсера B. У его есть последовательность операций A42 B42 C42 A43 B43 C43... Он может выполнять все эти операции, ни с кем не согласовывая их выполнения. Никакого Zookeeper’а здесь нет.
Теперь, допустим, у секвенсера B последовательность A666 B666 C666 B667 C667 B668 C668... Видно, что секвенсер A пропал. Вроде как последней его эпохой была 666, но вот этого секвенсер B наверняка знать не может – то ли правда секвенсер пропал, то ли канал связи лёг. Тут необходим консенсус, и вот тут как раз в игру вступает Zookeeper.
Система функционирует нормально в течение 99.9% времени (ну если это не списанные серверы в деревенском сарае). В оставшиеся 0.1% система восстанавливается после сбоев. При восстановлении Zookeeper нужен, и скорость восстановления зависит от производительности Zookeeper. Но скорость нормальной обработки транзакций от Zookeeper’а никак не зависит.
Ну и опять же, «ничем нельзя заменить» – это тоже фантазия. Raft опубликован, бери и реализуй. Другой вопрос, зачем это делать, если есть готовая реализация в виде etcd. А Zookeeper – это даже не Raft, это просто «дело привычки». Вон у Oracle, например, есть DataGuard Broker, который умеет строить консенсус. Но для кластеризации TimesTen они взяли Zookeeper – просто чтобы не возиться.
Мы точно о разных кальвинах. Какая разница, сколько шардов затрагивает транзакция? Когда идёт двухфазная фиксация, это важно, когда кальвин – никакой разницы вообще.
Или даже целая реплика пропала, потому что роут к датацентру потерялся.
Ну да, согласен, в этом случае надо всем договориться о том, какая была последняя эпоха у пропавшего секвенсера. Для этого действительно проще всего взять готовый Zookeeper. Но из-за этого считать всю систему «надстройкой над Zookeeper’ом» – явное преувеличение.
Без отказов мне ZooKeeper не нужен
Вот и я об этом. Баллонный ключ должен лежать в багажнике на случай прокола колеса, но это не повод называть весь автомобиль «надстройкой над баллонным ключом».
А что же ещё может быть в мире key-value СУБД? Особенно если учесть, что даже в мире реляционных СУБД логическая репликация основана на подходе "установить по ключу"?
получил таймаут, дальше что
Подождал, спросил ещё раз. Совершенно не вижу проблемы собрать кластер высокой доступности для секвенсера.
заранее про транзакции знает лишь один набор узлов
в наборе узлов один секвенсер. И этот секвенсер заранен знает не весь набор транзакций, а последовательность сообщений от других секвенсеров. Этого достаточно.
Мы точно про один и тот же кальвин говорим? Что такое «входной запрос»?
Кальвин – это чистый key/value, входной запрос там равен данным.
Дополнительную ценность система приобретает, когда кто-то (например, SQL engine в YandexDB) преобразует какой-то осмысленный запрос в последовательность изменения ключей, но и там реплицируется именно эта последовательность, а не SQL. Репликация запросов – это очень стрёмная штука, мне известна реализация только в MySQL. Все остальные реплицируют изменения данных с ключами (любой CDC).
К части узлов транзакции с него дошли, к другой части -- нет. Что делать?
Это проблема того секвенсера, до которого изменения не дошли. Он знает, что у него должна быть последовательность A1 B1 C1 A2 B2 C2 и т. д. Если B2 почему-то нет, можно поинтересоваться у секвенсера B, что у него там было под номером 2?
Raft и прочие ZAB'ы нужны только лишь потому, что никто заранее не знает, что будет в логах. Секвенсеры в кальвине знают это заранее, поэтому им проще. Но конечно, zookeeper туда воткнуть можно – примерно так же, как в наручные часы можно воткнуть атомный механизм. Точно, надёжно, понтово – но не нужно.
Но во-первых, журнал транзакций у Кальвина не сказать чтобы компактный – там передаётся ключ, значение и номер предыдущей версии значения, так что терабайты набираются легко.
А во-вторых я не понимаю, зачем там paxos-based (ну или zab-based) репликация, если можно заранее договориться, в какой последовательности идут транзакции от разных секвенсоров.
На счёт молодости можно поспорить, но я бы лучше поспорил на счёт Zookeeper. Не нужен там zookeeper. Тот компонент, который упорядочивает транзакции, называется секвенсер, и он может быть монолитным, т. к. не обязан быть отказоустойчивым. В референсной реализации кальвин-протокола секвенсеров много, они независимы друг от друга, а упорядоченность достигается синхронизацией часов и пакетированием транзакций по 10 мс.
Если есть zookeeper, то никакой кальвин уже не нужен.
«Эргономичная» мышь – это хорошо, но в левую руку её не возьмёшь. Мне когда-то очень нравились устройства Logitech, но последняя мышь, которая нормально работала в левой руке, – самая дешёвая M185. После покупки современного ноутбука с двумя портами мышь отправилась в чулан, теперь только Bluetooth.
«Премиальная» ультратонкая T630 при переключении в леворукий режим начинала глючить, хотя казалось бы – это функция компьютера а не мыши!
Поэтому теперь только Microsoft 3600 для поездок и R-GO HE Sport для дома. Из Логитека выбрать нечего.
Нет. Тут дело уже не в анатомии СУБД, а в семантике данных. Если вы ищете карту в базе процессинга, то с вероятностью 99.9% она там есть. И если вы что-то нашли, на этом можно остановиться. В таких случаях кеш, например, помогает.
Если вы ищете клиента в «чёрном списке», то в вероятностью 99.99% его там нет, но с полной уверенностью сказать «нет» вы можете, только просмотрев весь набор данных. B-дерево такую уверенность даёт, модель – нет.
Ну, наверно карта тут не самый удачный пример. Потому что если она прошла идентификацию на терминале, значит, в базе она точно есть. А если задача проверить, есть ли такой ключ в базе? Например, проверить владельца карты по "чёрному списку". Без полного сканирования ответить на такой вопрос с полной уверенностью невозможно.
Да? А так можно?
А вы понимаете, что в кальвине, в отличие от классических систем типа Oracle, исход транзакции неизвестен до тех пор, пока вся последовательность операций не будет выполнена планировщиком? То есть секвенсер может сказать, что он понял, чего от него хочет приложение, но не может гарантировать выполнение транзакции.
«Мой двойник робот» как минимум
Да. Достаточно в момент сбоя всем оставшимся секвенсерам/планировщикам написать, какой последний пакет они видели от пропавшего секвенсера, и выбрать наименьший. Ну или пусть тот, у кого есть наибольший, поделится с остальными – можно через Zookeeper.
Ну ок, я немного упростил картину. Конечно, есть отдельные узлы-планировщики. Но общую ситуацию это не меняет.
Вы же понимаете, что для репликации никакой консенсус (и zookeeper) не нужен. Репликация хоть в MS SQL, хоть в Oracle хоть где прекрасно работает без zookeeper’а. Потому что лидер жёстко зафиксирован. Поэтому гонять все операции через Zookeeper – это, конечно, хорошее быстрое решение для академического проекта, но совсем не обязательное условие для коммерческого продукта.
Зачем секвенсерам их согласовывать? Это совершенно лишнее.
Вам о чём-нибудь говорит аббревиатура CRDT? Так вот, секвенсер – это примерно то же самое. Каждый секвенсер формирует пачку транзакций независимо от остальных секвенсеров. Планировщик (или, как я писал в предыдущих комментариях, секвенсер, но сути это не меняет) руководствуется двумя простыми правилами:
Транзакции упорядочиваются по номеру эпохи, а внутри эпохи – по номеру секвенсера.
Вся эпоха, сгенерированная секвенсером, выполняется подряд, без прерывания.
Этих правил достаточно, чтобы на каждом планировщике последовательность транзакций была одна и та же, не надо ничего согласовывать.
Вот как раз при отказе одной из реплик всем надо договориться, какая последняя эпоха в этой реплике. Это единственное место, где нужен консенсус.
Да в том-то и дело, что через него никто не пускает большой поток данных, поэтому никто и не переделывает. Ну посмотрите, например, много ли людей собирают свои компьютеры, когда можно купить ноутбук или моноблок?
Вот Confluent захотел избавиться от Zookeeper – и избавился. Не до конца понимаю, зачем, но внезапно выяснилось, что так можно.
Давно я не работал с Oracle, забыл фирменную продуктовую линейку :) Этот внешний компонент называется Observer и тоже входит в поставку Oracle RDBMS.
https://www.doag.org/formes/pubfiles/303232/2008-K-IT-Bracher-Dataguard_Observer_ohne_Rechenzentrum.pdf
Нет. Это ниоткуда не следует.
Ещё раз. У нас есть несколько секвенсеров. Можно назвать их по алфавиту – A, B, C... Можно также договориться, что операции сортируются по номеру эпох, а внутри эпохи – по номеру секвенсера. То есть секвенсер A отправляет свои операции секвенсерам B и C, и никакого консенсуса не нужно, потому что никто, кроме секвенсера A, не может сгенерировать операции от секвенсера A. Никакого Zookeeper’а здесь нет.
Теперь посмотрим на ситуацию глазами секвенсера B. У его есть последовательность операций A42 B42 C42 A43 B43 C43... Он может выполнять все эти операции, ни с кем не согласовывая их выполнения. Никакого Zookeeper’а здесь нет.
Теперь, допустим, у секвенсера B последовательность A666 B666 C666 B667 C667 B668 C668... Видно, что секвенсер A пропал. Вроде как последней его эпохой была 666, но вот этого секвенсер B наверняка знать не может – то ли правда секвенсер пропал, то ли канал связи лёг. Тут необходим консенсус, и вот тут как раз в игру вступает Zookeeper.
Система функционирует нормально в течение 99.9% времени (ну если это не списанные серверы в деревенском сарае). В оставшиеся 0.1% система восстанавливается после сбоев. При восстановлении Zookeeper нужен, и скорость восстановления зависит от производительности Zookeeper. Но скорость нормальной обработки транзакций от Zookeeper’а никак не зависит.
Ну и опять же, «ничем нельзя заменить» – это тоже фантазия. Raft опубликован, бери и реализуй. Другой вопрос, зачем это делать, если есть готовая реализация в виде etcd. А Zookeeper – это даже не Raft, это просто «дело привычки». Вон у Oracle, например, есть DataGuard Broker, который умеет строить консенсус. Но для кластеризации TimesTen они взяли Zookeeper – просто чтобы не возиться.
[deleted]
Навальный и Кац свободны от политики?
Как говорится, you made my day.
Мы точно о разных кальвинах. Какая разница, сколько шардов затрагивает транзакция? Когда идёт двухфазная фиксация, это важно, когда кальвин – никакой разницы вообще.
Ну да, согласен, в этом случае надо всем договориться о том, какая была последняя эпоха у пропавшего секвенсера. Для этого действительно проще всего взять готовый Zookeeper. Но из-за этого считать всю систему «надстройкой над Zookeeper’ом» – явное преувеличение.
Вот и я об этом. Баллонный ключ должен лежать в багажнике на случай прокола колеса, но это не повод называть весь автомобиль «надстройкой над баллонным ключом».
А что же ещё может быть в мире key-value СУБД? Особенно если учесть, что даже в мире реляционных СУБД логическая репликация основана на подходе "установить по ключу"?
Подождал, спросил ещё раз. Совершенно не вижу проблемы собрать кластер высокой доступности для секвенсера.
в наборе узлов один секвенсер. И этот секвенсер заранен знает не весь набор транзакций, а последовательность сообщений от других секвенсеров. Этого достаточно.
Мы точно про один и тот же кальвин говорим? Что такое «входной запрос»?
Кальвин – это чистый key/value, входной запрос там равен данным.
Дополнительную ценность система приобретает, когда кто-то (например, SQL engine в YandexDB) преобразует какой-то осмысленный запрос в последовательность изменения ключей, но и там реплицируется именно эта последовательность, а не SQL. Репликация запросов – это очень стрёмная штука, мне известна реализация только в MySQL. Все остальные реплицируют изменения данных с ключами (любой CDC).
Это проблема того секвенсера, до которого изменения не дошли. Он знает, что у него должна быть последовательность A1 B1 C1 A2 B2 C2 и т. д. Если B2 почему-то нет, можно поинтересоваться у секвенсера B, что у него там было под номером 2?
Raft и прочие ZAB'ы нужны только лишь потому, что никто заранее не знает, что будет в логах. Секвенсеры в кальвине знают это заранее, поэтому им проще. Но конечно, zookeeper туда воткнуть можно – примерно так же, как в наручные часы можно воткнуть атомный механизм. Точно, надёжно, понтово – но не нужно.
Я, конечно, статью ещё раз перечитаю.
Но во-первых, журнал транзакций у Кальвина не сказать чтобы компактный – там передаётся ключ, значение и номер предыдущей версии значения, так что терабайты набираются легко.
А во-вторых я не понимаю, зачем там paxos-based (ну или zab-based) репликация, если можно заранее договориться, в какой последовательности идут транзакции от разных секвенсоров.
На счёт молодости можно поспорить, но я бы лучше поспорил на счёт Zookeeper. Не нужен там zookeeper. Тот компонент, который упорядочивает транзакции, называется секвенсер, и он может быть монолитным, т. к. не обязан быть отказоустойчивым. В референсной реализации кальвин-протокола секвенсеров много, они независимы друг от друга, а упорядоченность достигается синхронизацией часов и пакетированием транзакций по 10 мс.
Если есть zookeeper, то никакой кальвин уже не нужен.
Остаётся открытым вопрос, зачем Кальвину Zookeeper.
«Эргономичная» мышь – это хорошо, но в левую руку её не возьмёшь. Мне когда-то очень нравились устройства Logitech, но последняя мышь, которая нормально работала в левой руке, – самая дешёвая M185. После покупки современного ноутбука с двумя портами мышь отправилась в чулан, теперь только Bluetooth.
«Премиальная» ультратонкая T630 при переключении в леворукий режим начинала глючить, хотя казалось бы – это функция компьютера а не мыши!
Поэтому теперь только Microsoft 3600 для поездок и R-GO HE Sport для дома. Из Логитека выбрать нечего.
А-а, так это не ваша статья? То-то я гляжу, что обычно от имени Безумного Макса пишется какая-то дичь, а тут – такой хороший текст.
Бр-р, как сложно.
Храню конфиги на яндекс.диске, а настоящие файлы – хардлинки на них. Всё.
ватерлиния?
К сожалению, крупные российские корпорации работают по принципу «используй служебный комп – и не byod».
Нет. Тут дело уже не в анатомии СУБД, а в семантике данных. Если вы ищете карту в базе процессинга, то с вероятностью 99.9% она там есть. И если вы что-то нашли, на этом можно остановиться. В таких случаях кеш, например, помогает.
Если вы ищете клиента в «чёрном списке», то в вероятностью 99.99% его там нет, но с полной уверенностью сказать «нет» вы можете, только просмотрев весь набор данных. B-дерево такую уверенность даёт, модель – нет.
Ну, наверно карта тут не самый удачный пример. Потому что если она прошла идентификацию на терминале, значит, в базе она точно есть. А если задача проверить, есть ли такой ключ в базе? Например, проверить владельца карты по "чёрному списку". Без полного сканирования ответить на такой вопрос с полной уверенностью невозможно.