Как бы я сейчас объяснил молодому себе зачем существуют требования ACID для баз данных? Хабр

В этом случае CPU используется одновременно попеременно несколькими потоками или процессами, которые сменяются друг другом программным кодом, который называется планировщиком (или диспетчером) и использует алгоритм планирования выполнения задач. Он попеременно даёт каждому заданию некое окно времени (“time slice”). В этом случае мы говорим о конкурентности, но не о параллелизме, который мы получаем, когда наш CPU имеет несколько ядер, либо мы https://www.xcritical.com/ имеем несколько процессоров. Поток выполнения может выполняться параллельно на разных ядрах одного CPU, в то время, как параллельные процессы могут быть запущены на разных ядрах, процессорах и даже физических узлах (компьютерах). Если вас интересует разница между потоками и процессами, а также вы хотите узнать конкретный пример того, как использование процессов вместо потоков дало преимущество Google Chrome, можете ознакомиться вот с этим материалом).

Долговечность: защита данных от сбоев системы

Saga сложно отлаживать, особенно когда задействовано много микросервисов. Еще один недостаток шаблона Saga – в нем отсутствует изоляция чтения. То есть, если нам важны свойства, обозначенные в ACID, то Saga нам не очень подходит. И тут я снова пойду не по порядку acid test буковок, а начну с основополагающего термина – consistency. Мне придётся нивелировать ваш эффект узнавания, ибо эта согласованность имеет мало общего с согласованностью из ACID.

Почему надежность важна для транзакций базы данных?

Я же для разнообразия приведу другой пример – ограничение частоты запросов к API (“rate limiting”). Наша Lambda принимает событие с неким user_id для которого должна быть сделана проверка, не исчерпал ли пользователь с таким ID своё кол-во возможных запросов к некой нашей API. Мы могли бы хранить в DynamoDB от AWS значение совершённых вызовов, и увеличивать его с каждым вызовов нашей функции на 1. В качестве примера я нашёл одну технологию из повседневной жизни разработчика, которая использует нечто вроде оптимистичной блокировки – это протокол HTTP.

• Зато эта согласованность имеет куда более широкий контекст употребления, да и вообще это именно та согласованность, о которой идёт речь при обсуждении распределённых систем.
• Более того, команду ROLLBACK можно использовать для отмены всех изменений, внесенных в рамках транзакции, если что-то идет не так, обеспечивая атомарность транзакции.
• Еще один недостаток шаблона Saga – в нем отсутствует изоляция чтения.
• Транзакция это единая логическая операция, которая может состоять из одного или нескольких шагов.
• Если вы не знаете, как работает ETag, то вот хороший пример, с использованием библиотеки “feedparser” (которая помогает парсить RSS и прочие feeds).
• Его мощные функции включают интуитивно понятную визуальную среду для создания моделей данных , бизнес-логики, REST API и конечных точек WSS.

Почему согласованность важна для транзакций базы данных?

Внедрив эти рекомендации, вы сможете эффективно управлять транзакциями базы данных, сохраняя при этом целостность, согласованность и надежность данных в соответствии со свойствами ACID. Пессимист же исходит из того, что транзакции часто будут «встречаться» на одних и тех же данных, и чтобы упростить себе жизнь и избежать лишних race conditions, он просто блокирует необходимые ему данные. Минус пессимистичной блокировки в том, что её использование замедляет обработку транзакций в целом, но зато вы можете быть спокойны за данные и получаете настоящую изоляцию. Дополнительная опасность, правда, таится в возможной взаимной блокировке („deadlock“), при которой несколько процессов ожидают ресурсы, заблокированные друг другом.

Выбор правильной системы управления базами данных (СУБД) для соответствия требованиям ACID

Управление и выполнение транзакций базы данных играет решающую роль в поддержании стабильности и производительности системы баз данных. Транзакция — это последовательность одной или нескольких операций, таких как создание, обновление или удаление данных, объединенных вместе, чтобы гарантировать необходимую согласованность данных. Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу.

Consistency (консистентность, согласованность)

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

Свойства ACID (атомарность, согласованность, изоляция, долговечность)

Но всё же, большинстве NoSQL баз данных заложены основы целостности данных, что означает, что данные могут быть не синхронизированы какое-то время, но в конечном итоге они всё таки будут синхронизированы. Гарантирует, что все транзакции будут выполняться изолированно. Другими словами, одна транзакция не сможет прочитать данные второй транзакции, которая ещё не выполнилась. То, что в распределённых системах ответственность за атомарность и изоляцию ложится на приложение. То же самое происходит и при использовании БД, которые не предоставляют гарантии ACID. То есть, такие вещи, как разрешение конфликтов, откаты, коммиты и высвобождение места ложатся на плечи разработчика.

Кислоты могут быть идентифицированы как сильные или слабые в зависимости от того, насколько полно они диссоциируют на свои ионы в воде. Сильная кислота, например соляная кислота, в воде полностью диссоциирует на свои ионы. Слабая кислота лишь частично диссоциирует на свои ионы, поэтому раствор содержит воду, ионы и кислоту (например, уксусную). Эта ошибка может произойти из-за некорректных входных данных или любых других нарушений целостности. Она так же возникает в результате тайм-аута, либо в результате deadlock. При выполнении одной транзакции все остальные параллельные транзакции не должны оказывать на нее никакого результата.

Что означает I в ACID и как это можно использовать

Атомарность позволяет быть уверенным в том, что любая проведенная транзакция будет выполнена в полной степени. Когда пользователи обновляют лишь некие свои приватные данные.Например, пользователь оставляет комментарии или sticky notes к веб-странице. Или редактирует личные данные в личном кабинете у провайдера каких-либо услуг. Когда нельзя выдать пользователю или процессу устаревшие данные.И снова – финансовые транзакции. Когда есть большая вероятность того, что некое множество пользователей или процессов будет одновременно работать над одними и теми же данными.Простите за банальность, но типичный пример – финансовые транзакции.

Как правило, они если и нуждаются в нём, то лишь в некоторых местах. Вот тут есть хороший пример того, как поведут себя обе блокировки в одном и том же сценарии. Это два типа блокировки неких данных, к которым может возникнуть одновременный доступ. Если честно, мне понятие BASE кажется более пустой маркетинговой обёрткой, чем ACID – потому что оно не даёт ничего нового и никак не характеризует БД. А навешивание ярлыков (ACID, BASE, CAP) на те или иные БД может лишь запутать разработчиков.

Существуют различные способы решения этого вопроса – я не хочу сейчас вдаваться в детали, поэтому для начала почитайте «Википедию» , но если вкратце, то есть возможность создания иерархии блокировок. Если вы хотите познакомиться подробнее с этой концепцией, то предлагают вам поломать голову над «Задачей об обедающих философах» (“dining philosophers problem”). При реализации изоляции крайне важно сбалансировать степень изоляции и производительность системы базы данных. Достижение полной изоляции может привести к снижению производительности, поэтому крайне важно выбрать соответствующий уровень изоляции в зависимости от требований вашего приложения.

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

Не получится так, что часть запросов выполнятся успешно, а часть с ошибкой. Если хоть одна часть транзакции выполнится с ошибкой, вся транзакция не выполнится. Другими словами под атомарностью можно понимать «всё или ничего».

Проблема с термином согласованности заключается в том, что он употребляется в слишком большом кол-ве контекстов. Зато эта согласованность имеет куда более широкий контекст употребления, да и вообще это именно та согласованность, о которой идёт речь при обсуждении распределённых систем. Инженеры по данным взяли эту метафору, чтобы сравнивать базы данных относительно надёжности транзакций.” Источник. Атомарность гарантирует, что каждая транзакция будет выполнена полностью или не будет выполнена совсем.

Получите-распишитесь в испорченном состоянии, которое невозможно исправить. Кафка по сути своей вообще ничего не гарантирует и является ненадежным источником/приемником данных. У разработчика микросервисов все кроме его стейта всегда является ненадежным, а стейт в БД. Почему бы не сохранить записи об уведомлении в СУБД, а дальше уже по одному отправлять и контроллировать процесс отправки? Так не только будет видно, сколько нужно еще отправить уведомлений, но и в случае необходимости перезапустить этот процесс. Вдобавок, некоторые разработчики, такие как MarkLogic, OrientDB и Neo4j, предлагают ACID-совместимые системы управления базами данных NoSQL.