Когда дело доходит до баз данных, у моего учителя была очень классическая поговорка. Вы можете не уметь писать SQL, но вы не должны знатьACID.
В промышленной сфере SQL, возможно, является наиболее широко используемой технологией. От серверной части до алгоритма, от данных до администратора баз данных и до продукта, даже некоторые операции будут использовать базовый SQL. Поэтому, если вы не очень хорошо разбираетесь в этом сейчас, я предлагаю вам потратить полдня, чтобы найти веб-сайт и изучить его.
Первоначально я хотел написать некоторый контент, непосредственно связанный с Hbase, но обнаружил, что для ясного объяснения Hbase я должен говорить о базе данных noSQL. Если используется noSQL, он неотделим от самой традиционной реляционной базы данных. Итак, давайте пошагово, начиная с базовой реляционной базы данных. Может я не правильно говорю, потому что база данных не базовая, а наоборот очень сложная. От индексации до различных принципов оптимизации и проектирования, до различных внутренних алгоритмов и структур данных — здесь задействовано очень многое. Давайте поставим на первое место огромное море знаний и начнем с четырех основных принципов базы данных.
Четыре принципа транзакции базы данных ACID,A означает атомарность, что означает атомарность. C означает Consistency, то есть согласованность. I обозначает изоляцию, что означает изоляцию. D означает Durability, то есть настойчивость..
Эти четыре принципа должны быть знакомы тем, кто разбирается в базе данных. Однако, когда их спрашивают во время самого интервью, не так много людей могут сказать правду и ясно объяснить всю историю. Я думаю, это в основном потому, что наш перевод слишком элегантный и не такой интуитивный, как английский, поэтому трудно сделать то, что предполагает название. Другая причина в том, что мы недостаточно понимаем, когда учимся, мы знаем только причину, но не знаем точной причины. Так называемые знают свою природу, не знаю, почему.
атомарность
Начнем с самого простого из них, атомарности.
Атомарность проще всего понять и использовать чаще всего. Я не раз встречал на собеседовании, и однажды меня попросили написать передаточную функцию на Java, на самом деле, я просто хотел проверить, знаю ли я атомарность.
Слово атом кажется запутанным, но на самом деле оно относится не к элементарным частицам в физике, а кнеделимыйзначение. То есть все операции в транзакции должны бытьЕсли рассматривать как неделимое целое, либо все преуспеют, либо все потерпят неудачу.. Это наиболее подходящий пример проблемы переноса. A переводит 100 денег с банковской карты B. Очевидно, база данных должна сделать две вещи: одна — списать 100 со счета A, а другая — получить 100 со счета B. Но вот проблема: компьютерные системы не надежны на 100%, и вероятность сбоя может быть очень небольшой. Что делать, если происходит задержка в сети или отключение системы после того, как А списывает деньги, в результате чего деньги на счете Б не увеличиваются? Разве А не вычитал деньги ни за что?
Напрасно удерживать деньги — дело тривиальное, очевидно, недопустимо, чтобы финансовая система была настолько неустойчивой. Поэтому в транзакции базы данных должна быть гарантирована атомарность. Хотя вычитание денег и получение денег — это две операции, их следует рассматривать как одну. Либо вместе добьетесь успеха, либо вместе потерпите неудачу. Если вы потерпите неудачу, вы можете попробовать еще раз. Если вам удастся на полпути, вы не знаете, как это исправить.
Один из способов реализации транзакции — не обновлять окончательный результат в базе данных во время выполнения, а сначала записать его в журнал транзакций. После успешного выполнения всей транзакции содержимое журнала транзакций синхронизируется с базой данных. В случае сбоя удалите журнал транзакций и выполните откат.
Упорство
Второе, что нужно охватить, это настойчивость.
Постоянство относится к постоянству данных, ссылаясь наПосле завершения транзакции, изменения, внесенные в базу данных этой транзакцией,постоянно хранится в базе данныхСреди них на него больше не повлияет операция отката. Даже при различных авариях, таких как перебои с электричеством в машинном зале, сбои в сети и т. д., данные в базе данных не могут быть потеряны.
Но, как упоминалось ранее, компьютерным системам трудно быть надежными на 100%. Если случится ситуация, данные в базе утеряны, что делать?
Неважно, я рассказал об этом ранее, когда представил атомарность. Перед выполнением всех транзакционных операций данные будут записаны в журнал транзакций, а затем синхронизированы с базой данных. Даже если данные в базе данных потеряны, пока соответствующая операция выполняется снова в соответствии с журналом транзакций, данные в базе данных могут быть восстановлены, а надежность базы данных может быть сохранена. На самом деле, текущая база данных по умолчанию будет выполнять все операции как транзакции, так что в основном не нужно беспокоиться о потере данных.
изоляция
Потом изоляция.
После того, как мы поняли атомарность, мы хорошо поняли изоляцию. Когда у нас одновременно выполняется несколько транзакций, если изоляция не выполнена должным образом, это, вероятно, вызовет много проблем.
Наиболее распространены следующие четыре проблемы:
1. Грязные чтения
Грязные чтения — это когда одна транзакция считывает промежуточные результаты выполнения другой транзакции. Давайте также используем пример нашего перевода только что в качестве примера:
Когда транзакция, которую мы передаем, не завершена, другая транзакция считывает ее промежуточный результат, что может привести к грязным чтениям. Потому что в случае отката предыдущей транзакции вновь прочитанный результат будет неправильным и несовместимым с балансом после отката учетной записи А. Если эти данные используются в других системах, это вызовет масштабные проблемы с данными.
2. Неповторяющееся чтение
Неповторяющееся чтение означает, что если в транзакции мы читаем определенные данные дважды. Прямо посередине другая транзакция изменяет данные, что также вызовет ошибки данных, поскольку результаты двух чтений несовместимы.
Например, транзакция нашего счета А не завершилась, а ее результат в это время изменен другими транзакциями. Тогда программа запаникует, потому что читает изменения, которых не ожидала.
Решение состоит в том, чтобы изолировать изменяемые в данный момент данные и позволить только одной транзакции изменять фрагмент данных одновременно, чтобы обеспечить согласованность данных.
3. Фантомное чтение
Концепция фантомного чтения также очень проста, то есть транзакция считывается дважды, аколичество данныхнепоследовательный. Это очень похоже на неповторяемое чтение, но разница в том, что неповторяемое чтение относится к определенному фрагменту данных, а фантомное чтение относится ко всей базе данных или всей таблице.
Это также очень просто решить, потому что фантомные чтения генерируются другими транзакциями, изменяющими новые или изменяющими другие данные, поэтому, чтобы исключить эту ситуацию, недостаточно заблокировать и изолировать только те данные, которые мы модифицируем. Нам нужно изолировать всю базу данных или раздел, при этом только одна транзакция может изменить один шард или таблицу данных.
4. Обновление потеряно
Определение потери обновления интуитивно понятно, когда мы изменяем часть данных. В то же время другая транзакция изменяет тот же контент, что приводит к тому, что последний перезаписывает содержимое первого. Например, если исходный счет составляет 100 юаней, транзакция A добавляет к счету 10 юаней, а транзакция B вычитает со счета 20 юаней. Когда A изменяется на 110, он перезаписывается 80 транзакциями B, в результате чего операция A выглядит так, как если бы она не выполнялась, что приводит к потере обновления. Эта проблема также является самой классической в параллельных сценариях.
Решение также состоит в том, чтобы сделать хорошую изоляцию и запретить чтение другим транзакциям, пока запись не будет завершена. На самом деле потеря обновления является наиболее вероятной ошибкой в параллельных сценариях, и если дизайн неразумен, ошибки будет очень трудно устранить.
Решение проблемы изоляции базы данных заключается в установке разных уровней изоляции.Разные уровни изоляции соответствуют разным политикам изоляции, которые могут обеспечить изоляцию на разных уровнях. Разные уровни изоляции означают использование разных уровней блокировки.Очевидно, что более высокие уровни изоляции означают худшую производительность. Таким образом, администраторы баз данных (DBA) должны иметь очень четкое представление о текущих сценариях приложений, а также о параллелизме и рисках, связанных с данными. Уметь найти компромисс между производительностью и безопасностью. Здесь мы не будем проводить более конкретные исследования, просто посмотрим на следующий рисунок и просто поймем:
Существует четыре уровня изоляции сверху вниз. Чем выше уровень изоляции, тем больше проблем с изоляцией можно решить. Аналогично, чем больше блокировок используется, тем хуже производительность системы.
На вершиненезафиксированное чтениеЭто самый низкий уровень изоляции, при чтении не оценивается возможность чтения незафиксированных данных. так что этоИзоляция — это самое худшее, и даже простейшее грязное чтение не может быть решено..
Отправлено на чтениеограничен замкомТолько читать данные, которые уже были отправлены, общая блокировка, используемая при чтении данных, снимается сразу после завершения чтения. Этот уровень изоляции может решить только наиболее распространенные проблемы грязного чтения, а также уровень изоляции по умолчанию для баз данных SQL Server.
повторяемое чтениеПроцесс чтения такой же, как и зафиксированный уровень, но он останетсяобщий замок, до конца транзакции. То есть, пока транзакция не завершится, блокировка не будет снята. Другие транзакции не могут обновлять данные, что гарантирует отсутствие неповторяющихся чтений.
Ну наконец топоследовательное чтение, что еще больше усиливает изоляцию на основе повторяющегося чтения. Во время транзакции блокируются не только затронутые данные, но изаблокировать весь диапазон. Это предотвращает влияние других транзакций на общую ситуацию. При этом уровне изоляции гарантируется, что между транзакциями не будет перетаптывания.
На этом этапе были введены три из четырех принципов транзакций базы данных.Содержание выглядит много, но это еще не конец.Реализация изоляции будет включать использование блокировок.Если копнуть глубже, это потребует много содержания. . Однако для нас, практикующих алгоритмы, почти достаточно понимать этот слой.
Один из четырех принципов остаетсяпоследовательностьВ принципе, слово согласованность появилось во многих местах, таких как распределенные системы хранения, согласованность нескольких копий и так далее. Однако эти понятия имеют разное значение и не могут просто пониматься как одно и то же. Непротиворечивое представление базы данныхСостояние данных правильноеДа, при переходе происходит переход из одного правильного состояния в другое правильное состояние. Правильное состояние на самом деле относится к состоянию без ошибок, то есть к состоянию, которое соответствует ожиданиям программиста. Различные проблемы, упомянутые ранее при введении изоляции, можно резюмировать как противоречивые данные и ожидания программистов.То есть, если это согласуется с ожиданиями программиста, можно считать, что согласованность удовлетворена..
Несмотря на то, что согласованность является одним из четырех принципов базы данных, в системе баз данных нет ни одной части, специально посвященной согласованности. На самом деле, с точки зрения базы данных, если выполняются остальные три принципа, то согласованность будет достигнута естественным образом. Последовательность — это цель, а не средство. Для примера возьмем ситуативную дистанцию передачи только сейчас. A переводит 100 в B. Мы все знаем, что предварительным условием является то, что сумма на счете A больше или равна 100. Если сумма на счете A меньше 100, мы не проводили проверку во время разработки и принудительно переводим на преуспевать. Тогда этот результат заведомо неверен и не соответствует нашим ожиданиям, но этоПроблема возникла не из-за несогласованности базы данных, а из-за того, что разработчики проигнорировали ограничения.
Поэтому в учебнике по базе данных будет написано «Обеспечение согласованности является обязанностью пользователя, а не СУБД.», «СУБД предполагает, что согласованность сохраняется для каждой транзакции».
"За обеспечение согласованности отвечает разработка, а не база данных, которая предполагает, что каждая транзакция непротиворечива. "
На данный момент четыре принципа транзакций базы данных были введены.Я искренне желаю вам удачи каждый день.
Если вам понравилась эта статья, пожалуйста, подпишитесь на нее~