Смотреть что такое "ACID" в других словарях. Фиксация и откат транзакции. Обеспечение надёжности в рамках кластера серверов
Характеристики транзакций описываются в терминах ACID (Atomicity, Consistency, Isolation, Durability – неделимость, согласованность, изолированность, устойчивость).
· Транзакция неделима в том смысле, что представляет собой единое целое. Все ее компоненты либо имеют место, либо нет. Не бывает частичной транзакции. Если может быть выполнена лишь часть транзакции, она отклоняется.
· Транзакция является согласованной, потому что не нарушает бизнес-логику и отношения между элементами данных. Это свойство очень важно при разработке клиент-серверных систем, поскольку в хранилище данных поступает большое количество транзакций от разных систем и объектов. Если хотя бы одна из них нарушит целостность данных, то все остальные могут выдать неверные результаты.
· Транзакция всегда изолирована, поскольку ее результаты самодостаточны. Они не зависят от предыдущих или последующих транзакций – это свойство называется сериализуемостью и означает, что транзакции в последовательности независимы.
· Транзакция устойчива. После своего завершения она сохраняется в системе, которую ничто не может вернуть в исходное (до начала транзакции) состояние, т.е. происходит фиксация транзакции, означающая, что ее действие постоянно даже при сбое системы. При этом подразумевается некая форма хранения информации в постоянной памяти как часть транзакции.
Уровни изоляции транзакций
В идеале транзакции разных пользователей должны выполняться так, чтобы создавалась иллюзия, что пользователь текущей транзакции - единственный. Однако в реальности, по соображениям производительности и для выполнения некоторых специальных задач, СУБД предоставляют различные уровни изоляции транзакций. Уровни описаны в порядке увеличения изоляции транзакций и надёжности работы с данными
0 - Неподтверждённое чтение (Read Uncommited, Dirty Read, грязное чтение) - чтение незафиксированных изменений своей транзакции и конкурирующих транзакций, возможны нечистые, неповторяемые чтения и фантомы
1 - Подтверждённое чтение (Read Commited) - чтение всех изменений своей транзакции и зафиксированных изменений конкурирующих транзакций, нечистые чтения невозможны, возможны неповторяемые чтения и фантомы
2 - Повторяемое чтение (Repeatable Read ,Snapshot) - чтение всех изменений своей транзакции, любые изменения, внесённые конкурирующими транзакциями после начала своей недоступны, нечистые и неповторяемые чтения невозможны, возможны фантомы
3 - Упорядоченный - (Serializable, сериализуемый) - упорядоченные (сериализуемые) транзакции. Идентичен ситуации при которой транзакции выполняются строго последовательно одна после другой. То есть транзакции, результат действия которых не зависит от порядка выполнения шагов транзакции (запрещено чтение всех данных изменённых с начала транзакции, в том числе и своей транзакцией). Фантомы невозможны.
Чем выше уровень изоляции, тем больше требуется ресурсов, чтобы их поддерживать.
В СУБД уровень изоляции транзакций можно выбрать как для всех транзакций сразу, так и для одной конкретной транзакции. По умолчанию в большинстве баз данных используется уровень 1 (Read Commited). Уровень 0 используется в основном для отслеживания изменений длительных транзакций или для чтения редкоизменяемых данных. Уровни 2 и 3 используются при повышенных требованиях к изолированности транзакций.
Atomicity - Атомарность
Основная статья: Атомарность
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех её до сих пор произведённых действий будут отменены и система вернётся в исходное состояние.
[править]
Consistency - Согласованность
Основная статья: Консистентность данных
Одно из самых сложных и неоднозначных свойств из четвёрки ACID. В соответствии с этим требованием, система находится в согласованном состоянии до начала транзакции и должна остаться в согласованном состоянии после завершения транзакции. Не нужно путать требование согласованности с требованиями целостности (integrity). Последние правила являются более узкими и, во многом, специфичны для реляционных СУБД: есть требования целостности типов (domain integrity), целостности ссылок (referential integrity), целостности сущностей (entity integrity), которые не могут быть нарушены физически в силу особенностей реализации системы.
Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счёта, сумме, зачисляемой на другой. Это бизнес-правило и оно не может быть гарантировано только проверками целостности, его должны соблюсти программисты при написании кода транзакций. Если какая-либо транзакция произведёт списание, но не произведёт зачисление, то система останется в некорректном состоянии и свойство согласованности будет нарушено.
Наконец, ещё одно замечание касается того, что в ходе выполнения транзакции согласованность не требуется. В нашем примере, списание и зачисление будут, скорее всего, двумя разными подоперациями и между их выполнением внутри транзакции будет видно несогласованное состояние системы. Однако не нужно забывать, что при выполнении требования изоляции, никаким другим транзакциям эта несогласованность не будет видна. А атомарность гарантирует, что транзакция либо будет полностью завершена, либо ни одна из операций транзакции не будет выполнена. Тем самым эта промежуточная несогласованность является скрытой.
Isolation -Изолированность
Во время выполнения транзакции другие процессы не должны видеть данные в промежуточном состоянии. Например, если транзакция изменяет сразу несколько полей в базе данных, то другой запрос, выполненный во время выполнения транзакции, не должен вернуть одни из этих полей с новыми значениями, а другие с исходными.
Durability - Долговечность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.
Atomicity - Атомарность
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех её до сих пор произведённых действий будут отменены и система вернётся во «внешне исходное» состояние - со стороны будет казаться, что транзакции и не было. (Естественно, счётчики, индексы и другие внутренние структуры могут измениться, но, если СУБД запрограммирована без ошибок, это не повлияет на внешнее её поведение.)
Consistency - Согласованность
Транзакция, достигающая своего нормального завершения (EOT - end of transaction, завершение транзакции) и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты. Это условие является необходимым для поддержки четвёртого свойства.
Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счёта, сумме, зачисляемой на другой. Это бизнес-правило и оно не может быть гарантировано только проверками целостности, его должны соблюсти программисты при написании кода транзакций. Если какая-либо транзакция произведёт списание, но не произведёт зачисление, то система останется в некорректном состоянии и свойство согласованности будет нарушено.
Наконец, ещё одно замечание касается того, что в ходе выполнения транзакции согласованность не требуется . В нашем примере, списание и зачисление будут, скорее всего, двумя разными подоперациями и между их выполнением внутри транзакции будет видно несогласованное состояние системы. Однако не нужно забывать, что при выполнении требования изоляции, никаким другим транзакциям эта несогласованность не будет видна. А атомарность гарантирует, что транзакция либо будет полностью завершена, либо ни одна из операций транзакции не будет выполнена. Тем самым эта промежуточная несогласованность является скрытой.
Isolation - Изолированность
Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её результат. Изолированность - требование дорогое, поэтому в реальных БД существуют режимы, не полностью изолирующие транзакцию (уровни изолированности Repeatable Read и ниже).
Durability - Долговечность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.
См. также
Напишите отзыв о статье "ACID"
Литература
- P.A. Bernstein, N. Goodman, V. Hadzilacos. Concurrency Control and Recovery in Database Systems. - Addison-Wesley, 1986.
Примечания
|
||||||||||||||||||||||||||
Отрывок, характеризующий ACID
Наташа молчала, как думала Марья Дмитриевна от застенчивости, но в сущности Наташе было неприятно, что вмешивались в ее дело любви князя Андрея, которое представлялось ей таким особенным от всех людских дел, что никто, по ее понятиям, не мог понимать его. Она любила и знала одного князя Андрея, он любил ее и должен был приехать на днях и взять ее. Больше ей ничего не нужно было.– Ты видишь ли, я его давно знаю, и Машеньку, твою золовку, люблю. Золовки – колотовки, ну а уж эта мухи не обидит. Она меня просила ее с тобой свести. Ты завтра с отцом к ней поедешь, да приласкайся хорошенько: ты моложе ее. Как твой то приедет, а уж ты и с сестрой и с отцом знакома, и тебя полюбили. Так или нет? Ведь лучше будет?
– Лучше, – неохотно отвечала Наташа.
На другой день, по совету Марьи Дмитриевны, граф Илья Андреич поехал с Наташей к князю Николаю Андреичу. Граф с невеселым духом собирался на этот визит: в душе ему было страшно. Последнее свидание во время ополчения, когда граф в ответ на свое приглашение к обеду выслушал горячий выговор за недоставление людей, было памятно графу Илье Андреичу. Наташа, одевшись в свое лучшее платье, была напротив в самом веселом расположении духа. «Не может быть, чтобы они не полюбили меня, думала она: меня все всегда любили. И я так готова сделать для них всё, что они пожелают, так готова полюбить его – за то, что он отец, а ее за то, что она сестра, что не за что им не полюбить меня!»
Они подъехали к старому, мрачному дому на Вздвиженке и вошли в сени.
– Ну, Господи благослови, – проговорил граф, полу шутя, полу серьезно; но Наташа заметила, что отец ее заторопился, входя в переднюю, и робко, тихо спросил, дома ли князь и княжна. После доклада о их приезде между прислугой князя произошло смятение. Лакей, побежавший докладывать о них, был остановлен другим лакеем в зале и они шептали о чем то. В залу выбежала горничная девушка, и торопливо тоже говорила что то, упоминая о княжне. Наконец один старый, с сердитым видом лакей вышел и доложил Ростовым, что князь принять не может, а княжна просит к себе. Первая навстречу гостям вышла m lle Bourienne. Она особенно учтиво встретила отца с дочерью и проводила их к княжне. Княжна с взволнованным, испуганным и покрытым красными пятнами лицом выбежала, тяжело ступая, навстречу к гостям, и тщетно пытаясь казаться свободной и радушной. Наташа с первого взгляда не понравилась княжне Марье. Она ей показалась слишком нарядной, легкомысленно веселой и тщеславной. Княжна Марья не знала, что прежде, чем она увидала свою будущую невестку, она уже была дурно расположена к ней по невольной зависти к ее красоте, молодости и счастию и по ревности к любви своего брата. Кроме этого непреодолимого чувства антипатии к ней, княжна Марья в эту минуту была взволнована еще тем, что при докладе о приезде Ростовых, князь закричал, что ему их не нужно, что пусть княжна Марья принимает, если хочет, а чтоб к нему их не пускали. Княжна Марья решилась принять Ростовых, но всякую минуту боялась, как бы князь не сделал какую нибудь выходку, так как он казался очень взволнованным приездом Ростовых.
– Ну вот, я вам, княжна милая, привез мою певунью, – сказал граф, расшаркиваясь и беспокойно оглядываясь, как будто он боялся, не взойдет ли старый князь. – Уж как я рад, что вы познакомились… Жаль, жаль, что князь всё нездоров, – и сказав еще несколько общих фраз он встал. – Ежели позволите, княжна, на четверть часика вам прикинуть мою Наташу, я бы съездил, тут два шага, на Собачью Площадку, к Анне Семеновне, и заеду за ней.
Требования ACID
Atomicity - Атомарность
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех её до сих пор произведённых действий будут отменены и система вернётся в исходное состояние.
Consistency - Согласованность
Одно из самых сложных и неоднозначных свойств из четвёрки ACID. В соответствии с этим требованием, система находится в согласованном состоянии до начала транзакции и должна остаться в согласованном состоянии после завершения транзакции. Не нужно путать требование согласованности с требованиями целостности (integrity). Последние правила являются более узкими и, во многом, специфичны для реляционных СУБД : есть требования целостности типов (domain integrity), целостности ссылок (referential integrity), целостности сущностей (entity integrity), которые не могут быть нарушены физически в силу особенностей реализации системы.
Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счёта, сумме, зачисляемой на другой. Это бизнес-правило и оно не может быть гарантировано только проверками целостности, его должны соблюсти программисты при написании кода транзакций. Если какая-либо транзакция произведёт списание, но не произведёт зачисление, то система останется в некорректном состоянии и свойство согласованности будет нарушено.
Наконец, ещё одно замечание касается того, что в ходе выполнения транзакции согласованность не требуется . В нашем примере, списание и зачисление будут, скорее всего, двумя разными подоперациями и между их выполнением внутри транзакции будет видно несогласованное состояние системы. Однако не нужно забывать, что при выполнении требования изоляции, никаким другим транзакциям эта несогласованность не будет видна. А атомарность гарантирует, что транзакция либо будет полностью завершена, либо ни одна из операций транзакции не будет выполнена. Тем самым эта промежуточная несогласованность является скрытой.
Isolation - Изолированность
Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её результат. Это свойство не соблюдается на уровне изолированности Read Committed и ниже.
Durability - Надежность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.
Литература
- P.A. Bernstein, N. Goodman, V. Hadzilacos. Concurrency Control and Recovery in Database Systems. - Addison-Wesley, 1986.
Примечания
Wikimedia Foundation . 2010 .
Смотреть что такое "ACID" в других словарях:
acid - ACÍD, Ă, acizi, de, s.m., adj. 1. s.m. Substanţă chimică, cu gust acru şi miros înţepător, care înroşeste hârtia albastră de turnesol şi care, în combinaţie cu o bază, formează o sare. 2. adj. (Adesea fig.) Care are proprietăţile unui acid (1),… … Dicționar Român
ACiD - Productions (ACiD) ist eine Scene Artgroup welche sich, 1990 gegründet, ursprünglich auf ANSI Art für Mailboxen spezialisiert hat. In den letzten Jahren fand mit dem Niedergang der Mailbox Szene ein Wechsel zu anderen Hauptaktivitäten wie… … Deutsch Wikipedia
acid - Since the 1960s, when acid was first used to mean the hallucinogenic drug LSD, the word has developed all the connotations of a subculture. Those taking drugs came to be called acid heads or acid freaks; and their way of life came to depend on… … Modern English usage
ACiD - Productions ACiD Productions (ACiD) est un groupe artistique et numérique underground. Fondé en 1990, le groupe était à l origine spécialisé dans le graphisme ANSI pour les BBS. Plus récemment, ils ont étendu leur domaine d application vers d… … Wikipédia en Français
- (англ. «кислота»): В музыке Эйсид хаус, эйсид техно музыкальные жанры. Acid японская рок группа. Acid бельгийская спид/трэш метал группа. Acid Наркотическое вещество LSD 25. В информатике Sony ACID Pro аудиоредактор ACID набор… … Википедия
acid - bitter, sour in taste acerbic, acidulous, biting, piquant, pungent, sharp, tart, vinegarish, vinegary; concept 613 Ant. bland, sweet acid having acidic, corrosive properties acerbic, acidulous, acrid, anti alkaline, biting,… … New thesaurus
Acid - Ac id, a. 1. Sour, sharp, or biting to the taste; tart; having the taste of vinegar: as, acid fruits or liquors. Also fig.: Sour tempered. He was stern and… …
Acid - Ac id, n. 1. A sour substance. 2. (Chem.) One of a class of compounds, generally but not always distinguished by their sour taste, solubility in water, and reddening of vegetable blue or violet colors. They are also characterized… … The Collaborative International Dictionary of English
«A» Атомарность
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни однойNoSQL системы обычно выбирают высокую производительность не в угоду транзакционной семантике, так как её соблюдение вносит дополнительные затраты на обработку. Многие системы всё же обеспечивают гарантию на уровне ключа или строки(Google BigTable) или предоставляют api для атомарных операций(Amazon DynamoDB), при которой только один поток может модифицировать запись, если вы, к примеру, хотите иметь счётчик посещений пользователя, распределённый по кластеру. Большинство систем придерживаются неблокирующих read-modify-write циклов. Цикл состоит из трёх этапов - прочитать значение, модифицировать, записать. Как видно, в мультипоточной среде есть много вещей, которые могут пойти не так, к примеру, что если кто-то изменит запись между фазами чтения и записи. Основной механизм разрешения таких конфликтов - использование алгоритма Compare and Swap , - если кто-то изменил запись в процессе цикла - мы должны понять, что запись поменялась и повторить цикл до тех пор, пока не установится наше значение, такой алгоритм выглядит более предпочтительным перед полностью блокирующим на запись механизмом. Количество таких циклов может быть очень большим, поэтому нам необходим некий timeout на операцию, по истечению которого операция будет отклонена.
«C» Консистентность
Транзакция достигающая своего нормального завершения и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Учитывая специфику NoSQL к распределению информации по серверам - это означает - все ли реплики, содержащие копию данных всегда содержат одну и туже версию данныхВ силу специфики, современные NoSQL обязаны выбирать высокую доступность и способность к горизонтальному масштабированию кластера, - получается что система не может обеспечить полную согласованность данных и идёт на некоторые допущения в определении понятия согласованности. Различают два подхода:
Строгая консистентность
Такие системы гарантируют, что реплики всегда способны прийти к соглашению об одной версии данных, возвращаемых пользователю. Некоторые реплики не будут содержать это значение, но когда система будет обрабатывать запрос значения по ключу, машина всегда сможет решить, какое значение вернуть - просто оно будет не всегда последним. Как это работает - к примеру у нас есть N реплик одного и того же ключа. Когда приходит запрос на обновление значения ключа, система не отдаст результат пользователю, пока W реплик не ответят, что они получили обновление. Когда пользователь запрашивает значение, система возвращает ответ пользователю ответ тогда, когда хотя бы R реплик вернули одно и то же значение. Тогда мы считаем систему строго консистентной, если соблюдается условие R+W>N . Выбор значений R и W влияет на то, сколько машин должны ответить перед тем, как ответ вернётся пользователю, обычно выбирают условие R+W=N+1 - минимально необходимое условие по обеспечению строгой консистентности.Возможная консистентность
Некоторые системы(Voldemort, Cassandra, Riak ) позволяют выбрать R и W при которых R+WРазрешение этого конфликта различается на разных системах, Voldemort возвращает несколько копий значения, отдавая разрешение конфликта на откуп пользователю. Две версии пользовательской корзины на сайте могут быть слиты без потери информации, тогда как слияние двух версии одного редактируемого документа требует вмешательства пользователя. Cassandra, которая хранит timestamp каждой записи, возвращает самое последнее в случае определения конфликта, этот подход не позволяет слить две версии без потери информации, зато упрощает клиентскую часть.
Cassandra, начиная с версии 1.1 гарантирует, что если вы делаете обновление:
UPDATE Users
SET login="login" AND password="password"
WHERE key="key"
То никакое конкурентное чтение не увидит частичное обновление данных(login изменился, а password - нет), причём это справедливо только на уровне строк, которые находятся в рамках одного column family и имеющие общий ключ. Это может соответствовать уровню изоляции транзакции read uncommitted , при котором разрешаются конфликты lost update . Но Cassandra не предоставляет механизма отката на уровне кластера, к примеру, возможна ситуация, когда login и password, будут сохранены на каком-то количестве нод, но недостаточном W для того, чтобы отдать пользователю верный результат, при этом пользователь вынужден разрешать этот конфликт сам. Механизм обеспечения изоляции заключается в том, что для каждой изменяемой записи создаётся невидимая, изолированная для клиентов версия, которая впоследствии автоматически заменяет старую версию через механизмы Compare and Swap, описанные выше.
«D» Надёжность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.Самым прогнозируемым сценарием сбоя можно рассмотреть отключение питания или рестарт сервера. Полностью надёжная система в данном случае не должна вернуть ответ пользователю, пока не запишет все изменения из памяти на жёсткий диск. Запись на диск слишком долгая операция и многие NoSQL системы идут на компромиссы в угоду производительности.
Обеспечение надёжности в рамках одного сервера
Стандартный диск выдерживает 70-150 операций в секунду, что составляет пропускную способность до 150 Мб/c, ssd - 700 Мб/c, DDR - 6000 - 17000 Мб/c. Поэтому обеспечением надёжности в рамках одного сервера при обеспечении высокой производительности является сокращение числа записи со случайным доступом и увеличение последовательной записи. В идеале, система должна минимизировать число записей между вызовами fsync (синхронизации данных в памяти и на диске). Для этого применяются несколько техник.Контролирование частоты fsync
Redis предлагает несколько способов для настройки того, когда вызывать fsync . Можно настроить, чтобы он вызывался после каждого изменения записи, - что является самым медленным и безопасным выбором. Для улучшения производительности можно вызывать сброс на диск каждые N секунд, в худшем случае вы потеряете данные за N последних секунд, что может быть вполне приемлимо для некоторых пользователей. Если надёжность совсем не критична, то можно отключить fsync и полагаться на то, что система сама в какой-то момент синхронизирует память с диском.Увеличение последовательной записи через логирование
Для эффективного поиска данных NoSQL системы часто используют дополнительные структуры, например - B-деревья для построения индексов, - работа с ним вызывает множественные случайные доступы к диску. Для уменьшения этого некоторые системы (Cassandra, HBase, Riak ) добавляют операции обновления в последовательно-записываемый файл, называемый redo log . Пока некоторые структуры записываются на диск достаточно редко, лог пишется часто. После падения недостающие записи можно восстановить с помощью лога.Увеличение пропускной способности группировкой записей
Cassandra группирует несколько одновременных изменений в течение короткого окна, которые могут быть объединены в один fsync . Такой подход, называемый group commit , увеличивает время отклика для одного пользователя, т.к. он вынужден ждать несколько других транзакций для фиксирования своей. Преимущество здесь получается за счёт увеличения общей пропускной способности, т.к. несколько случайных записей могут быть объединены.Обеспечение надёжности в рамках кластера серверов
Из-за возможности непредвиденных выходов из строя дисков и серверов необходимо распределять информацию по нескольким машинам.Redis представляет собой классическую master-slave архитектуру для репликации данных. Все операции, связанные с мастером, спускаются до реплик в виде лога.
MongoDB представляет собой структуру, в которой заданное количество серверов хранит каждый документ, причём есть возможность задать количество серверов W
HBase достигает мультисерверной надёжности за счёт использования распределённой файловой системы HDFS .
В целом можно заметить некоторую тенденцию современных NoSQL-средств в сторону обеспечения большей консистентности данных. Но всё же пока SQL и NoSQL-средства могут существовать и развиваться параллельно и решать абсолютно разные задачи.