Как бы там нибыло, эта штука для нас решила безумное количество задач и наши коллеги, очень активно запрашивали эти фичи на стороне aws.
Если вам это так нужно было, то почему вы сразу не перешли на B2, в котором read-after-write было из коробки как минимум с 2015 года?
Но мне кажется, что вы изначально использует не тот инструмент для не той задачи. Собственные сервера под 10 петабайт на Storage Pod 6.0 обойдутся порядка $1M, при этом на них можно крутить свои собственные приложения. Не говоря уже о том, что у меня есть сомнения, что вам на самом деле нужны эти 10 петабайт при том, что какой-нибудь Facebook хранит 300 петабайт.
Вопиющее переворачивание верх-ногами причинно следственных связей -- это DynamoDB позаимствовало архитектуру со многих современников своего времени. Изначальная статья по Dynamo (не путать с DynamoDB) вполне явно упоминает Oceanstore и PAST, а также протоколы Pastry и Chord, не говоря уже о том, что школьники качали порно через Kademlia DHT и основанный на нем Mainline DHT у BitTorrent за несколько лет до формирования теоретической модели Dynamo, и тем более практической реализации, DynamoDB, которая задержалась еще на 5 лет. Ну и конечно же статья Dynamo упоминает Google FS, как ближайшего "энтерпрайзного" аналога-конкурента, выполняющего те же задачи.
Потом, когда Amazon начал продавать DynamoDB, внезапно развился хайп в духе "мама, хочу БД как у Амазона". И пошли Cassandra, Riak, и другие менее известные. Примерно как Git никому не нужен был 10 лет, а потом внезапно взлетел GitHub и все резко помешались на Git. И все резко забыли про недостатки Dynamo, которые очень серьезны, и из-за которых гугловый BigTable/FS не пошел по аналогичному пути, а именно -- проблема согласованности данных. Как переместить значение из одного ключа в другой? Как гарантировать инвартианты суммы-количества? Не говоря уже про более сложные связи.
Да куда там несколько записей -- как гарантировать для одной-единственной записи атомарность обновлений? Да, есть решение для неглобальных таблиц через условное обновление по атрибуту-версии, но для глобальных (реплицированных) оно не работает. Лучшее, что пока что смогли придумать по этой проблеме в Амазоне -- это поставить сверху дополнительный координатор транзакций с очень серьезными ограничениями на 25 элементов в транзакции, и, опять-таки, это не работает с глобальными таблицами.
Да, разрабатывать системы с распределенными БД сложно. Многие люди "влипают" в касандру не понимая, что все их данные спокойно влезут в SQLite или BerkleyDB -- у последней даже есть встроенная репликация еще с начала нулевых годов.
Почему я назвал Вернера манагером? Ну не почувствовал я в нем программиста-архитектора, извиняйте. Я увидел ученого-наперсточника, который пишет исследовательские работы, выбивает гранты, который имеет богатый опыт демонстрации сильных сторон и тщательного сокрытия слабых сторон, который, самое главное, умеет это продемонстрировать перед некомпетентным слушателем, вроде чиновников или нетехнических менеджеров. Не поймите меня неправильно -- это очень важный тип характера, именно потому Microsoft и Google сегодня руководят индусы. Но это не программист-архитектор.
Слышал когда-нибудь про такое словосочетание, как "скрытая реклама". Так вот, примерно 95% ВСЕЙ информации, которую ты получаешь из СМИ и популярных интернет площадок -- это то или иное искажение информации, скрытое или чуть боле явное, производимое с целью приобретения власти-денег.
Давайте лучше подумаем как эффективно закодировать промежуточное представление в SSA форме.
SSA в виде своего подмножества "логические связи между данными" является очень крутой штукой в плане свободы оптимизации и натягивания на самые разные исполнители. Проблема в том, что это же и наиболее ограниченная форма представления, потому SSA в прикладном программировании неизбежно скатывается в операции над переиспользуемыми ячейками и таким образом в рекуррентность, которую уже намного сложнее понимать. Как расширить SSA таким образом, чтобы скатывание в переиспользование и рекуррентность наступало как можно позже, или как наделить SSA такими промежуточными выразительными средствами, чтобы они были и предсказуемы и достаточно мощны -- это и есть хорошие сложные вопросы.
Конечно, если автор оригинальной цитаты не имел банальное "как оттранслировать исходники в хороший SSA" -- потому что лично я не вижу никакой перспективы в старых императивных языках, попытки их вытянуть на современный уровень приводят к тому, что с каждым годом эффект от этих усилий становится меньше и меньше.
Вы не объяснили откуда взялись прерывания в классической машине Тьюринга.
Естественно, никто не программирует на самой машине Тьюринга -- я имел в виду Тьюринг-эквивалентную штуку, алгоритмы с которой могут быть выполнены на машине Тьюринга, и наоборот, алгоритмы с машины Тьюринга могут быть выполнены на той "машине Тьюринга", которую я имел в виду. В этом как бы и был смысл создания определения "машина Тьюринга" - на этой машине никто не программирует ведь, программируют на ее аналогах.
Приведите пример хоть одного полулярного компилятора из SSA в код машины Тьюринга.
LLVM.
С чего бы регистровой машине быть высокоуровневее стековой? Вообще-то это абстракции одного уровня.
Регистровая машина -- да, того же уровня. SSA -- нет, не того же уровня, а выше. SSA с натяжкой можно назвать функциональной формой записи, то есть, описание взаимоотношений аргументов и результата без побочных эффектов. Конечно, с натяжкой потому, что на самом деле эти условия далеко не всегда выполняются, но иногда все-таки выполняются.
Погодите, откуда взялись прерывания в классической машине Тьюринга?
Потому что классическая машина Тюринга -- это бесполезный конь в вакууме, потому на самом деле ни одно современное бытовое вычислительное устройство не может быть смоделировано машиной Тьюринга. Даже контроллер стиральной машинки или микроволновки.
Откуда взялось SSA в машите Тьюринга?
SSA -- это популярная абстракция для компиляторов в код машины Тьюринга, чуть повысокоуровневее, чем стэк-машина. Так или иначе, SSA намного ближе к Тьюрингу, чем к FPGA логике.
Как ни странно, этот коммент сильно понятнее, чем исходная статья. Я так и не понял, что автор хочет сверх "давайте представим алгоритмы деревьям", что, как упомянул Kroleg, уже давно интенсивно применяется, и тем более при чем тут Erlang. Да, акторная модель Erlang значительно опередила свое время, но это не отменяется того факта, что распределенную систему на Erlang может быть очень сложно писать.
Дерево операций (из AST) разворачивается в промежуточное представление SSA-Form, проходит ряд анализов, оптимизаций, раскрасок и SSA превращается в код целевой машины, который может быть чем угодно, от машинного кода процессора до параллельно работающей сети на FPGA
Проблема в том, что традиционные машины Тьюринга сильно ограничены в доступных инструкциях. Например, в логических схемах очень часто реагируют на изменение состояния. Изменение состояния -- это точно такая же информация, но классическая машина Тьюринга абсолютно слепа к изменению состояния, и по этой причине очень много теряет. Как правило, передачу сигналов от одного агента приходится делать через прерывания, спинлоки, функции кооперативной многозадачности ОС, то есть, через кривые костыли и то же состояние.
Еще одна похожая проблема машинки Тьюринга -- это опора на строго фиксированные состояния входных параметров, то есть, упомянутое SSA. Команда должна для неизменяемых входных параметров выдавать по строгому алгоритму результат -- но что делать, если параметры изменились? Если результат уже не нужен? Большинство lock-free алгоритмов в современных C/C++/Pascal/etc строятся примерно по одному принципу:
while not целевое_состояние_достигнуто() do
идти_к_целевому_состоянию();
Причем, при выполнении сложных вложенных операций используется внешний цикл:
while not целевое_состояние_достигнуто() do
if not идти_к_целевому_состоянию1() then
continue;
if not идти_еще_дальше() then
continue;
И даже процессоры внутри используют похожие механизмы, но на уровне ЯП и их компиляторов у нас почему-то одно сплошное SSA и стэк-машина.
Настоящая история и мотивация создания языка Си практически не отражена, приведена книжно-википедийная версия пересказа кума подруги тёлки брата. Даже языки B и BCPL не упомянуты.
Абстрактная машина должна была решить две проблемы одновременно
И создать новую проблему -- проблему "что такое абстрактная машина и как она работает?". Во всем стандарте нет ни малейшего намека, как работает абстрактная машина, но при этом весь стандарт построен вокруг неё, в частности, многие вещи подразумевают некий "доступ". Например, "a = &b->field" -- я делаю "доступ" к b? Отсутствие определения абстрактной машины -- это причина, по которой компиляторы ломают ранее работавшие программы. Отмаза одна и та же -- "стандарт не запрещает". Да, он и не разрешает. Абстрактная машина -- это одно сплошное undefined behaviour.
Эта свобода интерпретации стандарта привела к тому, что отдельные неадекватные вахтеры из команды разработки GCC забаррикадировались от здравого смысла и отстреливаются лишь дежурными "я так увидел стандарт". Что их фичи превращают написание и отладку программ в кошмар -- их не волнует. Слава богу, что у нас есть ключи "-fwrapv -fno-strict-aliasing"
Зачем «глобальная атомарность»? Что это за фетиш такой?
Хорошо, локальная для реплицированного шарда. Одна эта задача по факту неподъемна для подавляющей части контор в IT индустрии.
Даже не знаю, как это комментировать.
Эта тема столько раз разжёвана и переварена, что – – –
Какая разница, сколько раз она пережевана -- это не уменьшает сложности реализации саг, и конкретно большого ручного труда по анализу и реализации.
если вдруг с лидером что-то случится, то Zookeeper сам принимает решение, кто станет новым лидером (собственно, весь zab/raft/paxos – об этом)
Нет. Выбрать лидера случайной задержкой ожидания -- это довольно просто. Не побить хранимые данные в результате этого процесса и при этом иметь приемлимую производительность -- это задача, которую удалось решить лишь нескольким разработчиком во всем мире. Ты повторяешь ту же самую ошибку "с данными как-нибудь разберемся". Как нибудь разберемся и что-то на выходе получим -- вот потому сохранности данных при отказах никто не может обеспечить, если не применяет ZooKeeper/etcd.
Я не понимаю, что вы вкладываете в понятие «отказоустойчивость» в данном случае. Он обеспечивает корректный выбор лидера в случае сбоя в HA-кластере Oracle – и этого достаточно.
Я имел в виду, что сам Observer -- это один узел, и с его отказом заканчивается вся отказоустойчивость системы. Но в целом у БД с Observer-ом некая отказоустойчивость есть, бесспорно, это лучше, чем ничего.
Чувствуется, у вас что-то глубоко личное с корнями, уходящими в далёкое детство. В разных банках всё очень по-разному.
С радостью изменю свое мнение, если узнаю про хотя бы один банк, где это не так.
Сразу видно человека с богатым практическим опытом. Вот объясните – а зачем быстрее?
Можно вывернуться мехом внутрь и сделать быстрее, но зачем? Банк – это про зарабатывание денег, а не про компаративную фаллометрию.
Я сразу написал, что это играет мало значения, но ты решил придраться. Я просто иронично вскользь упомянул забавный феномен IT индустрии "софт будет выполнен настолько плохо, насколько это возможно". То есть, пока этого хватает -- никто не пошевелит и пальцем. И не надо мне рассказывать, что бедный региональный банк с чистой прибылью в $1 млрд в год не может себе позволить потратить пару миллионов на разработку софта. Не говоря уже про крупняк. Проблема не в том, что у них нет денег -- проблема в том, что у них нет исполнителей и они не смогут их найти ни за какие миллиарды. Потому что дворник не сможет организовать конвеерное производство автомобилей.
>что при отказе транзакция зависает в лимбо
Не зависает. Прочтите ещё раз, как работает сага.
Спасибо, я читаю то, что ты мне пишешь. На живой системе не так-то просто вернуть взад сагу по моему хотению, по щучьему велению. Данные меняются, негодники такие. В этом как бы и вся сложность реализации глобально атомарных операций в распределенных системах, и от того, что у этой функции поменялась форма, сложность ее никуда не испарилась -- грамотная реализация саг по прежнему является крайне сложной задачей. Которую, к тому же, придется заново решать под каждую новую операцию -- именно потому возникло желание решить проблему атомарности раз и навсегда, чтобы потом можно было делать любые транзакции и получать атомарность добавлением одной опции.
Если регламентные работы на БД, включая мажорные обновления, и накат новых версий ПО, подразумевающих изменение модели данных, то тут – логическая репликация. С одним, заметьте, лидером.
Я не смог распарсить эту фразу. Лидер -- он на то и лидер, чтобы быть единственным.
Расскажите это разработчикам Oracle Observer и etcd.
Etcd я уже упомянул. Я так понимаю, что и его, и Google Chubby разработали в гугле. То есть, две из 3 существующих в индустрии strong consistency баз данных разработаны в гугле. Oracle Observer сам по себе не является отказоустойчивым, потому сравнивать его с etcd смешно.
Как человек, последние 15 лет работающий в банковском секторе, а до этого 6 лет в телекоме, я несколько удивлён приведёнными примерами.
Я не знаю про телеком, мой скромный опыт говорит про то, что там немало годных спецов, но банковский сектор, именно сами банки -- это помойка, ржавая и загнившая с концами, с зависшими банкоматами, с зарезервированными средствами, для пользования которыми нужно ждать окончания операционного дня, говно-SPA на jQuery и React одновременно с кучей ошибок, через которые регулярно не получается то одно оплатить, то другой услугой воспользоваться. Вот чего там точно нет -- так это надежности и отказоустойчивости. Пока всё работает, каналы связи исправны, сервера стоят на ИБП -- вроде бы всё "отказоустойчиво". Как что-то падает -- начинается вой "у меня деньги со счетам списались, а никуда не пришли. Я в поддержку звоню-пишу, меня пускают по кругу".
Достаточно поместить все счета клиента на один монолитный сервер – и никакого воя не будет. А то, что Вася деньги отправил, а Маша получила их только через 5 секунд вообще никого никогда не парило.
Не в этом проблема. Хотя, нет никакого оправдания для того, чтобы транзакция проходила дольше секунды -- все просто привыкли, а разрабам в банке тем боеле пофигу, как работает их система. Проблема в том, что при отказе транзакция зависает в лимбо. Ту проблема, которую решил ZooKeeper, в банках предпочли просто не замечать, будто ее не существует. То есть, проще поставить помощнее UPS, бензиновый электрогенератор, чем париться отказоустойчивостью и распределенностью.
Как в этой системе обновлять сервера без остановки обработки транзакций? Да никак. Просто останавливают всё к чертям и вешают табличку на переднем веб-сервере "ведутся технические работы".
А вот любая другая монолитная БД – MS SQL, Oracle, PostgreSQL, DB2 – вполне. Ну и да, над ними маленький raft для автоматизации переключения
Может быть в лабораториях рейха такая БД и есть, но из публичных софтин ни одно решение не смогло показать отказоустойчивость. Да, реализации рафта и multi-paxos есть -- только они не работают. Ну то есть либо бьют данные при отказе, либо, как упомянутый выше Galera Cluster, портят данные даже при полном отсутствии отказов. Это не "маленький Raft" -- трудоемкость реализации отказоустойчивой БД на Raft сравнима с реализацией чего-то вроде InnoDB с нуля. И очень тяжело пояснить технически неграмотному заказчику/инвестору (а это 95% оных), почему вы пилите реализацию "маленького Raft" уже два года, а не сделали даже половины.
Не могу придумать «производственную потребность» под распределённую базу (ещё раз подчеркну, речь не об аналитической СУБД). Не поделитесь?
Поделюсь. 24/7 сервис, в котором нужно выводить из эксплуатации реплики и вводит в эксплуатацию другие, при этом есть ограничения на корректность информации. То есть, грубо говоря, баланс на счету пользователя, где недопустимо, чтобы он временно приобрел непонятное значение, мол "ща засинхронизируемся и всё норм будет" -- потому что начнется вой от пользователей "у вас тут система сломалась". Или пользователи участвуют в редактировании общего документа -- здесь я подчеркну, что достаточно поддерживать согласованность на уровне мелкого общего сервера, который используется для этих пользователей и этого документа, не обязательно иметь глобальную согласованность. Масштабирование через шардирование, короче говоря. И чтоб отдельный шард не выдавал непонятные результаты во время сбоя -- нужна строгая согласованность между репликами шарда. Никакими MySQL и сагами этого не сделать.
При необходимости межшардовых транзакций организуется сага. На мой взгляд, такой подход намного более отказоустойчивый и масштабируемый, чем единая распределённая БД.
Масштабируем -- да, отказоустойчив -- да. Но согласованности данных не будет даже при полном отсутствии отказов. То есть, то что поломано, не может сломаться.
Я вообще противник любых распределённых БД, поскольку убеждённость в том, что «распределённая БД ничем не отличается от монолитной, кроме размера» – крайне опасное заблуждение
Распределенные БД прекрасно дают гарантии, strong consistency, eventual consistency, да, их сложно делать, да, только несколько распределенных БД умеют в strong consistency, но это не повод говорить "давайте избегать распределенных БД" -- особенно если есть производственная потребность иметь таковую. Прототип Calvin потому и использовал ZooKeeper -- это был для них единственный способ сделать прототип отказоустойчивым.
Если хочется строить большую распределённую систему, за образец надо брать Facebook.
В каком смысле "брать за образец"? Лепить из чего попало?
А вы понимаете, что в кальвине, в отличие от классических систем типа Oracle, исход транзакции неизвестен до тех пор, пока вся последовательность операций не будет выполнена планировщиком? То есть секвенсер может сказать, что он понял, чего от него хочет приложение, но не может гарантировать выполнение транзакции.
Так или иначе, это значит одно -- клиент отослал запрос, но не знает, как этот запрос был обработан. Что я могу сказать -- удачи писать клиентский код под это дело.
Тогда вопрос (по самому первому примеру) насчет независимого выполнения: в обоих потоках используются одни и те же переменные = уже как бы намек,. что жди беды, т.е. что рано или поздно возникнут коллизии (кроме того, насколько это из реальной жизни я имею в виду такое использование переменных)? Кроме того, второй поток - бесконечный цикл. Насколько это корректно, один из потоков делать таковым и насколько эта ситуация из реальной жизни
Этот пример неявно подразумевает, что операция инкремента-декремента атомарна, то есть, это по сути lock-free алгоритм. Даже достаточно простые прикладные lock-free алгоритмы весьма мозгодробильны, потому я постарался не приводить никаких примеров из жизни.
Вообще, насколько грамотнее бы было тогда всю программу оформить в виде бесконечного цикла, а внутри него уже потоки организовывать?
Это очень распространенный прием в асинхронном и многопоточном программировании. Например, браузер, через который ты мне пишешь, в фундаменте своей работы имеет бесконечный цикл обработки событий. Сервер, с которого ты эту страницу получаешь, тоже работает на основе бесконечного цикла опроса соединений.
Достаточно в момент сбоя всем оставшимся секвенсерам/планировщикам написать, какой последний пакет они видели от пропавшего секвенсера, и выбрать наименьший.
Спешу огорчить, что это даже не eventual consistency. Это "может быть подтвержденная транзакция останется в базе, а может быть нет", то есть, никаких гарантий персистентности. Например, клиент отправляет транзакцию секвенсеру, секвенсор подтверждает ее, ставит ее в очередь на отправку через сеть, и в этот момент весело пропадает из сети. Транзакция подтверждена, но про транзакцию никто в оставшейся сети никогда не слышал.
Конечно, можно решить проблему "в лоб" сделав синхронную репликацию. Правда, здесь внезапно возникает проблема -- как засчитывать успешность транзакции? Если по успешному ответу ото всех ведомых узлов, то система умрет при отказе одного ведомого узла. Если делать это через кворум, то по сути повторяешь всю логику подтверждения репликации Zab/Raft/MultiPaxos. И при отказе тебе придется решать, какой из узлов содержит корректные подтвержденные данные на основе данных, содержащихся в узлах. То есть, это копия логики ZooKeeper. Со всеми вытекающими, вроде долгого подтверждения транзакции и необходимостью гонять кучу данных о транзакциях по сети.
Вы же понимаете, что для репликации никакой консенсус (и zookeeper) не нужен. Репликация хоть в MS SQL, хоть в Oracle хоть где прекрасно работает без zookeeper’а. Потому что лидер жёстко зафиксирован
Это что-то вроде "как попаду в аварию -- так обязательно пристегну ремень". Да, для репликации доступность распределенного консенсуса не обязателена и отказоустойчивость тоже не обязательна, но если нужно при отказе одного узла сохранять работоспособность без потери подтвержденных данных и без публикации неподтвержденных, то придётся "пристёгиваться" заранее. ZooKeeper, для справки, при нормальной работе тоже никаким распределенным консенсусом не занимается -- он работает именно в режиме синхронной репликации с одним стабильным лидером. Вся огромная сложность реализации ZooKeeper заключалась в том, чтобы идеально совместить эту высокопроизводительную репликацию с обработкой отказа. Именно при отказах вся архитектура БД и проверяется на прочность, а без отказов можно хоть SQLite реплицировать.
Транзакции упорядочиваются по номеру эпохи, а внутри эпохи – по номеру секвенсера...
Этих правил достаточно, чтобы на каждом планировщике последовательность транзакций была одна и та же, не надо ничего согласовывать.
Да, я уже понял этот аргумент, и уже ответил, что такая архитектура не дает отказоустойчивости. А отказоустойчивость -- это весь смысл создания Calvin. Масштабируемость у него так-себе, поскольку для достижения оной придется серьезно переосмыслять принципы записи в БД.
Вот как раз при отказе одной из реплик всем надо договориться, какая последняя эпоха в этой реплике. Это единственное место, где нужен консенсус.
Ну, и кто его будет делать? ZooKeeper, в БД которого пусто?
То есть секвенсер A отправляет свои операции секвенсерам B и C, и никакого консенсуса не нужно, потому что никто, кроме секвенсера A, не может сгенерировать операции от секвенсера A. Никакого Zookeeper’а здесь нет.
У меня тоже складывается ощущение, что мы говорим про какие-то разные Кальвины. Но я перечитываю статью, и вижу подтверждение именно своего кальвина. Узлы в системе имеют два типа взаимоотношений: реплика и шард. То есть, вся БД разделена на несколько шардов с уникальными данными, а потом эти шарды реплицированы. Обычно реплики сидят в разных датацентрах, а шарды -- в одном.
Так вот, ни в каком из двух вариантов взаимоотношений нет ситуации "секвенсер A отправляет операции B, и никто кроме A не может их сгенерировать". Секвенсоры-шарды вообще друг-другу ничего не посылают -- они шлют операции планировщикам всех шардов одной реплики. Секвенсоры-реплики дублируют друг друга, они на равных создают пачки операций и согласовывают их -- весь раздел 2 был уделен обоснованию этого приема, то есть, система продолжает работать как ни в чем ни бывало при отказе одной из реплик. На самом деле такой бесшовный failover невозможен, это тот же "горячий пирожок", который превращается в очередную хитромудрую обертку над ZooKeeper, но я сейчас не об этом -- я о том, что всё создание системы было обосновано только отказоустойчивостью.
Конечно, можно взять модель "асинхронной репликации" с назначением единственного лидера, где, действительно, только один секвенсор будет главным и рассылать пачки операций всем остальным репликам, и тогда потерять всю отказоустойчивость и весь смысл создания системы -- смотри раздел 2.
Система функционирует нормально в течение 99.9% времени (ну если это не списанные серверы в деревенском сарае). В оставшиеся 0.1% система восстанавливается после сбоев. При восстановлении Zookeeper нужен, и скорость восстановления зависит от производительности Zookeeper.
Я не могу придумать архитектуры, при которой через ZooKeeper не будут идти ключевые данные и при отказе не будет теряться случайное количество подтвержденных операций. При отказе будет потеряны именно данные, которые не прошли через ZooKeeper. Это не просто "библиотека для восстановления после отказов", ZooKeeper для каждой своей входящей операции производит сложный алгоритм репликации-сохранения и выдает подтверждение с гарантиями -- без это сложной процедуры гарантий сохранности при отказе нет.
Единственная реально значимая фича Calvin по сравнению с ZooKeeper -- это наличие независимых секвенсоров в шардах, которые реплицируются независимо, за счет чего производительность упирается не в один ZooKeeper, а в несколько ZooKeeper-ов. Правда, преимуществом этим можно воспользоваться ровно настолько, насколько независимы эти шарды. Собственно, с таким же успехом можно было шардировать данные по нескольким экземплярам ZooKeeper безо всяких Cavin.
Ну и опять же, «ничем нельзя заменить» – это тоже фантазия. Raft опубликован, бери и реализуй. Другой вопрос, зачем это делать, если есть готовая реализация в виде etcd
Ха, "реализуй" -- легко сказать, но реализовать сильно сложней. По этой причине столько систем уже наклепали на базе ZooKeeper, но ZooKeeper по прежнему остается почти безальтернативным -- потому что он и составляет самую большую сложность разработки.
Вон у Oracle, например, есть DataGuard Broker, который умеет строить консенсус
Я не могу найти подтверждение того, что сам Data Guard Broker устойчив к отказам.
Здесь указывается, что функция автоматического принятия решения о fail-over производится некоторым внешним агентом. То есть, сам Data Guard Broker этого делать не умеет -- он может только выполнять команды извне. Причем, судя по инструкциям для ручной синхронизации ролей
Если вам это так нужно было, то почему вы сразу не перешли на B2, в котором read-after-write было из коробки как минимум с 2015 года?
Но мне кажется, что вы изначально использует не тот инструмент для не той задачи. Собственные сервера под 10 петабайт на Storage Pod 6.0 обойдутся порядка $1M, при этом на них можно крутить свои собственные приложения. Не говоря уже о том, что у меня есть сомнения, что вам на самом деле нужны эти 10 петабайт при том, что какой-нибудь Facebook хранит 300 петабайт.
Вопиющее переворачивание верх-ногами причинно следственных связей -- это DynamoDB позаимствовало архитектуру со многих современников своего времени. Изначальная статья по Dynamo (не путать с DynamoDB) вполне явно упоминает Oceanstore и PAST, а также протоколы Pastry и Chord, не говоря уже о том, что школьники качали порно через Kademlia DHT и основанный на нем Mainline DHT у BitTorrent за несколько лет до формирования теоретической модели Dynamo, и тем более практической реализации, DynamoDB, которая задержалась еще на 5 лет. Ну и конечно же статья Dynamo упоминает Google FS, как ближайшего "энтерпрайзного" аналога-конкурента, выполняющего те же задачи.
Потом, когда Amazon начал продавать DynamoDB, внезапно развился хайп в духе "мама, хочу БД как у Амазона". И пошли Cassandra, Riak, и другие менее известные. Примерно как Git никому не нужен был 10 лет, а потом внезапно взлетел GitHub и все резко помешались на Git. И все резко забыли про недостатки Dynamo, которые очень серьезны, и из-за которых гугловый BigTable/FS не пошел по аналогичному пути, а именно -- проблема согласованности данных. Как переместить значение из одного ключа в другой? Как гарантировать инвартианты суммы-количества? Не говоря уже про более сложные связи.
Да куда там несколько записей -- как гарантировать для одной-единственной записи атомарность обновлений? Да, есть решение для неглобальных таблиц через условное обновление по атрибуту-версии, но для глобальных (реплицированных) оно не работает. Лучшее, что пока что смогли придумать по этой проблеме в Амазоне -- это поставить сверху дополнительный координатор транзакций с очень серьезными ограничениями на 25 элементов в транзакции, и, опять-таки, это не работает с глобальными таблицами.
Да, разрабатывать системы с распределенными БД сложно. Многие люди "влипают" в касандру не понимая, что все их данные спокойно влезут в SQLite или BerkleyDB -- у последней даже есть встроенная репликация еще с начала нулевых годов.
Почему я назвал Вернера манагером? Ну не почувствовал я в нем программиста-архитектора, извиняйте. Я увидел ученого-наперсточника, который пишет исследовательские работы, выбивает гранты, который имеет богатый опыт демонстрации сильных сторон и тщательного сокрытия слабых сторон, который, самое главное, умеет это продемонстрировать перед некомпетентным слушателем, вроде чиновников или нетехнических менеджеров. Не поймите меня неправильно -- это очень важный тип характера, именно потому Microsoft и Google сегодня руководят индусы. Но это не программист-архитектор.
Слышал когда-нибудь про такое словосочетание, как "скрытая реклама". Так вот, примерно 95% ВСЕЙ информации, которую ты получаешь из СМИ и популярных интернет площадок -- это то или иное искажение информации, скрытое или чуть боле явное, производимое с целью приобретения власти-денег.
Зачем? Я могу придумать, зачем это разработчику компилятора или стандартной библиотеки, но зачем остальным людям - не могу придумать.
Так я ж не спорю. Но для большинства бытовых процов -- вполне имеет.
SSA в виде своего подмножества "логические связи между данными" является очень крутой штукой в плане свободы оптимизации и натягивания на самые разные исполнители. Проблема в том, что это же и наиболее ограниченная форма представления, потому SSA в прикладном программировании неизбежно скатывается в операции над переиспользуемыми ячейками и таким образом в рекуррентность, которую уже намного сложнее понимать. Как расширить SSA таким образом, чтобы скатывание в переиспользование и рекуррентность наступало как можно позже, или как наделить SSA такими промежуточными выразительными средствами, чтобы они были и предсказуемы и достаточно мощны -- это и есть хорошие сложные вопросы.
Конечно, если автор оригинальной цитаты не имел банальное "как оттранслировать исходники в хороший SSA" -- потому что лично я не вижу никакой перспективы в старых императивных языках, попытки их вытянуть на современный уровень приводят к тому, что с каждым годом эффект от этих усилий становится меньше и меньше.
Естественно, никто не программирует на самой машине Тьюринга -- я имел в виду Тьюринг-эквивалентную штуку, алгоритмы с которой могут быть выполнены на машине Тьюринга, и наоборот, алгоритмы с машины Тьюринга могут быть выполнены на той "машине Тьюринга", которую я имел в виду. В этом как бы и был смысл создания определения "машина Тьюринга" - на этой машине никто не программирует ведь, программируют на ее аналогах.
LLVM.
Регистровая машина -- да, того же уровня. SSA -- нет, не того же уровня, а выше. SSA с натяжкой можно назвать функциональной формой записи, то есть, описание взаимоотношений аргументов и результата без побочных эффектов. Конечно, с натяжкой потому, что на самом деле эти условия далеко не всегда выполняются, но иногда все-таки выполняются.
Потому что классическая машина Тюринга -- это бесполезный конь в вакууме, потому на самом деле ни одно современное бытовое вычислительное устройство не может быть смоделировано машиной Тьюринга. Даже контроллер стиральной машинки или микроволновки.
SSA -- это популярная абстракция для компиляторов в код машины Тьюринга, чуть повысокоуровневее, чем стэк-машина. Так или иначе, SSA намного ближе к Тьюрингу, чем к FPGA логике.
Как ни странно, этот коммент сильно понятнее, чем исходная статья. Я так и не понял, что автор хочет сверх "давайте представим алгоритмы деревьям", что, как упомянул Kroleg, уже давно интенсивно применяется, и тем более при чем тут Erlang. Да, акторная модель Erlang значительно опередила свое время, но это не отменяется того факта, что распределенную систему на Erlang может быть очень сложно писать.
Проблема в том, что традиционные машины Тьюринга сильно ограничены в доступных инструкциях. Например, в логических схемах очень часто реагируют на изменение состояния. Изменение состояния -- это точно такая же информация, но классическая машина Тьюринга абсолютно слепа к изменению состояния, и по этой причине очень много теряет. Как правило, передачу сигналов от одного агента приходится делать через прерывания, спинлоки, функции кооперативной многозадачности ОС, то есть, через кривые костыли и то же состояние.
Еще одна похожая проблема машинки Тьюринга -- это опора на строго фиксированные состояния входных параметров, то есть, упомянутое SSA. Команда должна для неизменяемых входных параметров выдавать по строгому алгоритму результат -- но что делать, если параметры изменились? Если результат уже не нужен? Большинство lock-free алгоритмов в современных C/C++/Pascal/etc строятся примерно по одному принципу:
Причем, при выполнении сложных вложенных операций используется внешний цикл:
И даже процессоры внутри используют похожие механизмы, но на уровне ЯП и их компиляторов у нас почему-то одно сплошное SSA и стэк-машина.
Настоящая история и мотивация создания языка Си практически не отражена, приведена книжно-википедийная версия пересказа кума подруги тёлки брата. Даже языки B и BCPL не упомянуты.
И создать новую проблему -- проблему "что такое абстрактная машина и как она работает?". Во всем стандарте нет ни малейшего намека, как работает абстрактная машина, но при этом весь стандарт построен вокруг неё, в частности, многие вещи подразумевают некий "доступ". Например, "a = &b->field" -- я делаю "доступ" к b? Отсутствие определения абстрактной машины -- это причина, по которой компиляторы ломают ранее работавшие программы. Отмаза одна и та же -- "стандарт не запрещает". Да, он и не разрешает. Абстрактная машина -- это одно сплошное undefined behaviour.
Эта свобода интерпретации стандарта привела к тому, что отдельные неадекватные вахтеры из команды разработки GCC забаррикадировались от здравого смысла и отстреливаются лишь дежурными "я так увидел стандарт". Что их фичи превращают написание и отладку программ в кошмар -- их не волнует. Слава богу, что у нас есть ключи "
-fwrapv -fno-strict-aliasing"Хорошо, локальная для реплицированного шарда. Одна эта задача по факту неподъемна для подавляющей части контор в IT индустрии.
Какая разница, сколько раз она пережевана -- это не уменьшает сложности реализации саг, и конкретно большого ручного труда по анализу и реализации.
Нет. Выбрать лидера случайной задержкой ожидания -- это довольно просто. Не побить хранимые данные в результате этого процесса и при этом иметь приемлимую производительность -- это задача, которую удалось решить лишь нескольким разработчиком во всем мире. Ты повторяешь ту же самую ошибку "с данными как-нибудь разберемся". Как нибудь разберемся и что-то на выходе получим -- вот потому сохранности данных при отказах никто не может обеспечить, если не применяет ZooKeeper/etcd.
Я имел в виду, что сам Observer -- это один узел, и с его отказом заканчивается вся отказоустойчивость системы. Но в целом у БД с Observer-ом некая отказоустойчивость есть, бесспорно, это лучше, чем ничего.
С радостью изменю свое мнение, если узнаю про хотя бы один банк, где это не так.
Я сразу написал, что это играет мало значения, но ты решил придраться. Я просто иронично вскользь упомянул забавный феномен IT индустрии "софт будет выполнен настолько плохо, насколько это возможно". То есть, пока этого хватает -- никто не пошевелит и пальцем. И не надо мне рассказывать, что бедный региональный банк с чистой прибылью в $1 млрд в год не может себе позволить потратить пару миллионов на разработку софта. Не говоря уже про крупняк. Проблема не в том, что у них нет денег -- проблема в том, что у них нет исполнителей и они не смогут их найти ни за какие миллиарды. Потому что дворник не сможет организовать конвеерное производство автомобилей.
Спасибо, я читаю то, что ты мне пишешь. На живой системе не так-то просто вернуть взад сагу по моему хотению, по щучьему велению. Данные меняются, негодники такие. В этом как бы и вся сложность реализации глобально атомарных операций в распределенных системах, и от того, что у этой функции поменялась форма, сложность ее никуда не испарилась -- грамотная реализация саг по прежнему является крайне сложной задачей. Которую, к тому же, придется заново решать под каждую новую операцию -- именно потому возникло желание решить проблему атомарности раз и навсегда, чтобы потом можно было делать любые транзакции и получать атомарность добавлением одной опции.
Я не смог распарсить эту фразу. Лидер -- он на то и лидер, чтобы быть единственным.
Etcd я уже упомянул. Я так понимаю, что и его, и Google Chubby разработали в гугле. То есть, две из 3 существующих в индустрии strong consistency баз данных разработаны в гугле. Oracle Observer сам по себе не является отказоустойчивым, потому сравнивать его с etcd смешно.
Я не знаю про телеком, мой скромный опыт говорит про то, что там немало годных спецов, но банковский сектор, именно сами банки -- это помойка, ржавая и загнившая с концами, с зависшими банкоматами, с зарезервированными средствами, для пользования которыми нужно ждать окончания операционного дня, говно-SPA на jQuery и React одновременно с кучей ошибок, через которые регулярно не получается то одно оплатить, то другой услугой воспользоваться. Вот чего там точно нет -- так это надежности и отказоустойчивости. Пока всё работает, каналы связи исправны, сервера стоят на ИБП -- вроде бы всё "отказоустойчиво". Как что-то падает -- начинается вой "у меня деньги со счетам списались, а никуда не пришли. Я в поддержку звоню-пишу, меня пускают по кругу".
Не в этом проблема. Хотя, нет никакого оправдания для того, чтобы транзакция проходила дольше секунды -- все просто привыкли, а разрабам в банке тем боеле пофигу, как работает их система. Проблема в том, что при отказе транзакция зависает в лимбо. Ту проблема, которую решил ZooKeeper, в банках предпочли просто не замечать, будто ее не существует. То есть, проще поставить помощнее UPS, бензиновый электрогенератор, чем париться отказоустойчивостью и распределенностью.
Как в этой системе обновлять сервера без остановки обработки транзакций? Да никак. Просто останавливают всё к чертям и вешают табличку на переднем веб-сервере "ведутся технические работы".
Может быть в лабораториях рейха такая БД и есть, но из публичных софтин ни одно решение не смогло показать отказоустойчивость. Да, реализации рафта и multi-paxos есть -- только они не работают. Ну то есть либо бьют данные при отказе, либо, как упомянутый выше Galera Cluster, портят данные даже при полном отсутствии отказов. Это не "маленький Raft" -- трудоемкость реализации отказоустойчивой БД на Raft сравнима с реализацией чего-то вроде InnoDB с нуля. И очень тяжело пояснить технически неграмотному заказчику/инвестору (а это 95% оных), почему вы пилите реализацию "маленького Raft" уже два года, а не сделали даже половины.
Поделюсь. 24/7 сервис, в котором нужно выводить из эксплуатации реплики и вводит в эксплуатацию другие, при этом есть ограничения на корректность информации. То есть, грубо говоря, баланс на счету пользователя, где недопустимо, чтобы он временно приобрел непонятное значение, мол "ща засинхронизируемся и всё норм будет" -- потому что начнется вой от пользователей "у вас тут система сломалась". Или пользователи участвуют в редактировании общего документа -- здесь я подчеркну, что достаточно поддерживать согласованность на уровне мелкого общего сервера, который используется для этих пользователей и этого документа, не обязательно иметь глобальную согласованность. Масштабирование через шардирование, короче говоря. И чтоб отдельный шард не выдавал непонятные результаты во время сбоя -- нужна строгая согласованность между репликами шарда. Никакими MySQL и сагами этого не сделать.
Масштабируем -- да, отказоустойчив -- да. Но согласованности данных не будет даже при полном отсутствии отказов. То есть, то что поломано, не может сломаться.
Распределенные БД прекрасно дают гарантии, strong consistency, eventual consistency, да, их сложно делать, да, только несколько распределенных БД умеют в strong consistency, но это не повод говорить "давайте избегать распределенных БД" -- особенно если есть производственная потребность иметь таковую. Прототип Calvin потому и использовал ZooKeeper -- это был для них единственный способ сделать прототип отказоустойчивым.
В каком смысле "брать за образец"? Лепить из чего попало?
Так или иначе, это значит одно -- клиент отослал запрос, но не знает, как этот запрос был обработан. Что я могу сказать -- удачи писать клиентский код под это дело.
Этот пример неявно подразумевает, что операция инкремента-декремента атомарна, то есть, это по сути lock-free алгоритм. Даже достаточно простые прикладные lock-free алгоритмы весьма мозгодробильны, потому я постарался не приводить никаких примеров из жизни.
Это очень распространенный прием в асинхронном и многопоточном программировании. Например, браузер, через который ты мне пишешь, в фундаменте своей работы имеет бесконечный цикл обработки событий. Сервер, с которого ты эту страницу получаешь, тоже работает на основе бесконечного цикла опроса соединений.
Спешу огорчить, что это даже не eventual consistency. Это "может быть подтвержденная транзакция останется в базе, а может быть нет", то есть, никаких гарантий персистентности. Например, клиент отправляет транзакцию секвенсеру, секвенсор подтверждает ее, ставит ее в очередь на отправку через сеть, и в этот момент весело пропадает из сети. Транзакция подтверждена, но про транзакцию никто в оставшейся сети никогда не слышал.
Конечно, можно решить проблему "в лоб" сделав синхронную репликацию. Правда, здесь внезапно возникает проблема -- как засчитывать успешность транзакции? Если по успешному ответу ото всех ведомых узлов, то система умрет при отказе одного ведомого узла. Если делать это через кворум, то по сути повторяешь всю логику подтверждения репликации Zab/Raft/MultiPaxos. И при отказе тебе придется решать, какой из узлов содержит корректные подтвержденные данные на основе данных, содержащихся в узлах. То есть, это копия логики ZooKeeper. Со всеми вытекающими, вроде долгого подтверждения транзакции и необходимостью гонять кучу данных о транзакциях по сети.
Это что-то вроде "как попаду в аварию -- так обязательно пристегну ремень". Да, для репликации доступность распределенного консенсуса не обязателена и отказоустойчивость тоже не обязательна, но если нужно при отказе одного узла сохранять работоспособность без потери подтвержденных данных и без публикации неподтвержденных, то придётся "пристёгиваться" заранее. ZooKeeper, для справки, при нормальной работе тоже никаким распределенным консенсусом не занимается -- он работает именно в режиме синхронной репликации с одним стабильным лидером. Вся огромная сложность реализации ZooKeeper заключалась в том, чтобы идеально совместить эту высокопроизводительную репликацию с обработкой отказа. Именно при отказах вся архитектура БД и проверяется на прочность, а без отказов можно хоть SQLite реплицировать.
Да, я уже понял этот аргумент, и уже ответил, что такая архитектура не дает отказоустойчивости. А отказоустойчивость -- это весь смысл создания Calvin. Масштабируемость у него так-себе, поскольку для достижения оной придется серьезно переосмыслять принципы записи в БД.
Ну, и кто его будет делать? ZooKeeper, в БД которого пусто?
У меня тоже складывается ощущение, что мы говорим про какие-то разные Кальвины. Но я перечитываю статью, и вижу подтверждение именно своего кальвина. Узлы в системе имеют два типа взаимоотношений: реплика и шард. То есть, вся БД разделена на несколько шардов с уникальными данными, а потом эти шарды реплицированы. Обычно реплики сидят в разных датацентрах, а шарды -- в одном.
Так вот, ни в каком из двух вариантов взаимоотношений нет ситуации "секвенсер A отправляет операции B, и никто кроме A не может их сгенерировать". Секвенсоры-шарды вообще друг-другу ничего не посылают -- они шлют операции планировщикам всех шардов одной реплики. Секвенсоры-реплики дублируют друг друга, они на равных создают пачки операций и согласовывают их -- весь раздел 2 был уделен обоснованию этого приема, то есть, система продолжает работать как ни в чем ни бывало при отказе одной из реплик. На самом деле такой бесшовный failover невозможен, это тот же "горячий пирожок", который превращается в очередную хитромудрую обертку над ZooKeeper, но я сейчас не об этом -- я о том, что всё создание системы было обосновано только отказоустойчивостью.
Конечно, можно взять модель "асинхронной репликации" с назначением единственного лидера, где, действительно, только один секвенсор будет главным и рассылать пачки операций всем остальным репликам, и тогда потерять всю отказоустойчивость и весь смысл создания системы -- смотри раздел 2.
Я не могу придумать архитектуры, при которой через ZooKeeper не будут идти ключевые данные и при отказе не будет теряться случайное количество подтвержденных операций. При отказе будет потеряны именно данные, которые не прошли через ZooKeeper. Это не просто "библиотека для восстановления после отказов", ZooKeeper для каждой своей входящей операции производит сложный алгоритм репликации-сохранения и выдает подтверждение с гарантиями -- без это сложной процедуры гарантий сохранности при отказе нет.
Единственная реально значимая фича Calvin по сравнению с ZooKeeper -- это наличие независимых секвенсоров в шардах, которые реплицируются независимо, за счет чего производительность упирается не в один ZooKeeper, а в несколько ZooKeeper-ов. Правда, преимуществом этим можно воспользоваться ровно настолько, насколько независимы эти шарды. Собственно, с таким же успехом можно было шардировать данные по нескольким экземплярам ZooKeeper безо всяких Cavin.
Ха, "реализуй" -- легко сказать, но реализовать сильно сложней. По этой причине столько систем уже наклепали на базе ZooKeeper, но ZooKeeper по прежнему остается почти безальтернативным -- потому что он и составляет самую большую сложность разработки.
Я не могу найти подтверждение того, что сам Data Guard Broker устойчив к отказам.
https://www.oracle.com/technical-resources/articles/smiley-fsfo.html
Здесь указывается, что функция автоматического принятия решения о fail-over производится некоторым внешним агентом. То есть, сам Data Guard Broker этого делать не умеет -- он может только выполнять команды извне. Причем, судя по инструкциям для ручной синхронизации ролей
https://docs.oracle.com/cd/E69294_01/html/E71432/gpxvm.html
я могу предположить, что рассинхронизированные конфиги Data Guard являются нормой.