ACID-транзакции приходят в Apache Cassandra: вот почему мы взволнованы

An extraordinary computer science breakthrough called Accord is bringing globally available, general-purpose ACID transactions to the next Cassandra release

Сначала выберем лучшую часть. Транзакции ACID переходят на Apache Cassandra.

Глобально доступные транзакции общего назначения, которые работают так же, как Cassandra. Это не какой-то трюк с мелким шрифтом или применение старых методов.

Это связано с выдающимся прорывом в области информатики под названием Accord. от команды Apple и Мичиганского университета. Это поможет Cassandra изменить наше представление о данных, открывая новые варианты использования.

Вот что это значит для тех, кто не разбирается во всех тонкостях проекта Cassandra и его особенностях. Нет ничего более важного, чем скорость запуска приложения в производство. Но разработчикам, которые хотят использовать масштабируемость, отказоустойчивость и легендарную поддержку нескольких центров обработки данных Cassandra для работы с чем-то вроде финансовых транзакций, пришлось кодировать в своих приложениях множество сложных обходных путей. Компромиссы по сравнению с использованием, скажем, Oracle были значительными.

С Аккордом? Никаких компромиссов. Cassandra теперь будет поддерживать все, что сделало ее великолепной, при этом поддержка транзакций будет переведена на базы данных, что значительно снижает сложность кода.

Взгляд наблюдателя

Система баз данных выполняет важные функции, такие как надежное хранение данных и быть доступным для запроса. Управление изменениями данных не всегда является функцией базы данных. В случае многих систем NoSQL бремя управления изменениями возлагается на пользователя. Наблюдатель за изменением данных определяет важность эксклюзивности.

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

В более чувствительных операциях наблюдатель за изменением данных должен чувствовать, что он единственный процесс, использующий базу данных. Это понятие в информатике называется «изоляция»; это «I» в ACID (атомарность, согласованность, изоляция, долговечность).

Классический пример — банковский перевод, когда деньги списываются с одного банковского счета, а затем добавляются на другой — именно в таком порядке. Процесс наблюдения требует эксклюзивности, чтобы другие процессы не вносили изменения, которые могут привести к несоответствиям или неожиданностям.

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

Изоляция гарантирует, что только один процесс может одновременно вносить изменения, и если два процесса конкурируют за одни и те же данные, одному из них придется ждать завершения другого.

Примите свою лень

Разработчикам необходимо быстро перейти к системе, которой они могут доверять. Транзакции ACID были золотым стандартом доверия в системах баз данных на протяжении почти 50 лет. Разработчики ищут компромиссы в зависимости от требований, что иногда приводит к тому, что они работают с системами, которые не поддерживают транзакции ACID.

Исторически сложилось так, что в системах NoSQL предпочтение от компромиссов склонялось к масштабированию и времени безотказной работы, при этом жертвуя транзакциями.

Приведение транзакций ACID в Cassandra было связано с сокращением компромиссов. Cassandra уже зарекомендовала себя как средство линейного масштабирования, обеспечивающее безотказную работу даже в самых неблагоприятных сценариях.

Cassandra — лучший выбор, когда вам нужна база данных, которая выдержит все возможности Интернета. Неудивительно, что потребность в транзакциях стала источником конфликта между разработчиками.

Можем ли мы прийти к консенсусу?

В распределенных системах каждый узел-член в более крупном кластере может действовать независимо или должен координировать свои действия с другими узлами. В транзакции, где «Эй, нам всем нужно кое о чем договориться», компьютерщики называют это консенсусом, а разработка этих протоколов — это непрерывная область совершенствования.

Paxos — давно известный консенсусный протокол, принятый Cassandra в 2013 году для "облегченных транзакций".

Легкий, потому что он гарантирует, что изменение данных одного раздела будет изолировано в транзакции, но более одной таблицы или раздела не является вариантом. Кроме того, Paxos требует многократных циклов для достижения консенсуса, что приводит к большим дополнительным задержкам и мелким шрифтам о том, когда использовать упрощенные транзакции в вашем приложении.

Протокол Raft был разработан в качестве следующего поколения для замены Paxos и нескольких систем, таких как Etcd, CockroachDB и DynamoDB принял его. Это сократило круговые поездки, создав избранного лидера.

Недостатком Cassandra в этом подходе является то, что лидеры не охватывают центры обработки данных, поэтому требуется несколько лидеров (см. Spanner).

Наличие избранного лидера также нарушает принципы Cassandra «ничего общего» и налагает новые требования на обработку ошибок.

Если узел выходит из строя, необходимо выбрать нового лидера.

Другие базы данных — например, FaunaDB и FoundationDB — пошли по пути решения проблемы множественных выносок, сведя их к одному глобальному лидеру, как описано в Бумага Кальвина.

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

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

Мы достигли согласия?

У нас могут быть очень разные мнения о том, что приемлемо для проекта Cassandra. Наши критерии заключаются в том, чтобы придерживаться основных убеждений о том, как должны работать распределенные системы. Производительность и масштабирование всегда должны сохраняться при работе с несколькими узлами в одном или нескольких центрах обработки данных. Мы можем быть довольно требовательны, но именно поэтому Cassandra выбирают многие организации.

Предыдущие итерации протоколов консенсуса решали разные части проблемы, но каждый из них представлял собой компромисс, который нарушал бы некоторые ценности Cassandra. Говорят, что следующий большой прорыв находится в двух статьях от предыдущего. В данном случае документ был Accord, и потребовалось большое количество усилий, чтобы устранить компромиссы.

Accord решает две проблемы, которые не были решены в предыдущих протоколах консенсуса: как мы можем получить глобально доступный консенсус и достичь его за один цикл? Первый новый механизм — это буфер переупорядочивания.

Предполагая, что используется общедоступное оборудование, различия в тактовых частотах между узлами неизбежны. Буфер переупорядочивания измеряет разницу между узлами в дополнение к задержке между ними. Каждая реплика может использовать эту информацию для правильного упорядочивания данных от каждого узла и учета различий, гарантируя одностороннее согласование с протоколом меток времени.

Другой механизм — электорат быстрого пути. Режимы сбоя могут создать задержку при выборе нового лидера перед возобновлением работы. Электораты быстрого пути используют ранее существовавшие функции в Cassandra с некоторыми новыми реализациями, чтобы поддерживать быстрый путь к кворуму без лидера при том же уровне отказов, который допускает Cassandra. Более подробную информацию можно прочитать в предложении.

Как это работает?

Самое большое влияние будет на продуктивность разработчиков, поэтому давайте посмотрим, как это выглядит на практике. Рассмотрим следующий пример банковского перевода, о котором мы упоминали ранее:

Во-первых, это новый синтаксис, который вы увидите в языке запросов Cassandra (CQL). Транзакции содержатся в объявлениях BEGIN TRANSACTION и COMMIT TRANSACTION. Все внутри маркеров транзакций будет происходить атомарно, независимо от других процессов. В этом примере мы переведем 20 долларов со счета Алисы Бобу. Ничего более классического, чем это, быть не может!

В разделе A мы можем выбрать данные из существующей записи и присвоить результат кортежу (несколько элементов, хранящихся в одной переменной). В зависимости от того, сколько столбцов содержится в предложении SELECT, в кортеже можно сохранить одно или несколько значений. Эти значения будут использоваться в разделе B для проверки условий перед внесением изменений в данные.

В этом случае мы проверим, есть ли на счету Алисы 20 долларов, прежде чем переводить деньги Бобу. Если это так, то UPDATE уменьшает баланс счета Алисы на 20 долларов, а затем увеличивает баланс Боба на 20 долларов. Если бы у Алисы было меньше 20 долларов США, изменений бы не произошло.

За кулисами находится сериализованный набор команд базы данных, которые выполняются исключительно, как видно из процесса наблюдения. В одном или нескольких центрах обработки данных для достижения консенсуса транзакция требовала только одного кругового обхода, и даже если какие-либо узлы были отключены, действие все равно выполнялось бы, если бы был доступен хотя бы кворум реплик.

Именно так Cassandra любит работать, но мы только что улучшили нашу игру с помощью глобально доступной транзакции.

Что дальше

Accord и вся работа, которая с ним связана, еще не завершена и будет включена в следующий выпуск Cassandra. Поскольку все это с открытым исходным кодом, те из вас, кто не может ждать, могут клонировать копию ветки cep-15-accord из репозитория Cassandra и создать свою собственную копию.

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

Мне очень интересно услышать от сообщества о том, какие варианты использования вы найдете с глобально доступной транзакцией, работающей с той скоростью и надежностью, которые вы ожидаете от Cassandra. Не пора ли наконец избавиться от этих последних рабочих нагрузок реляционных баз данных?

Мы также с нетерпением ждем ваших отзывов по всем нашим каналам, включая список рассылки Slack или проектного фонда Apache Software Foundation. Функции в проекте с открытым исходным кодом постоянно развиваются для удовлетворения потребностей пользователей. Вот почему вы должны сыграть решающую роль в формировании Apache Cassandra будущего.

И следите за обновлениями, чтобы узнать больше о вариантах использования и информации по мере того, как мы развиваем эту замечательную новую функцию. Вы можете ожидать, что об этом будет несколько разговоров на цифровом саммите Cassandra Forward, который состоится 14 марта. Вы не захотите пропустить те.

Автор Патрик Макфадин, DataStax

Патрик Макфадин — соавтор книги О'Рейли "Управление облачными данными в Kubernetes". В настоящее время он работает в DataStax по связям с разработчиками и в качестве участника проекта Apache Cassandra. Патрик работал главным пропагандистом Apache Cassandra (он также новоиспеченный коммиттер Cassandra!) и консультантом DataStax, где он прекрасно провел время, разрабатывая одни из крупнейших развертываний в производственной среде.