Смотреть что такое "ACID" в других словарях. Увеличение пропускной способности группировкой записей. Контролирование частоты fsync
Характеристики транзакций описываются в терминах 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 - Долговечность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.
Возможно вы уже слышали такой термин как транзакция . Если нет или же подзабыли, то напомним, что под транзакцией подразумевается некоторая последовательность операций (действий вставки, обновления или удаления) в базе данных, которые должны быть выполнены в рамках единого целого.
Все мы пользуемся услугами банков и проводим различные операции с денежными средствами. Как в этом случае добиться надежности? Требования к безопасности выполнения операций в таких системы повышенные. А теперь представьте, что вы выполняете перевод средств кому-то из своих знакомых. Вы хотите, чтобы средства были списаны с вашего счета и поступили на счет получателя. Но что произойдет в случае сбоя, например, электропитания или другой аварийной ситуации? Кто гарантирует вам, что вы не окажетесь в ситуации, когда деньги с вашего счета ушли, но перечисления на счет получателя не произошло. Предотвратить такие ситуации и помогают транзакции .
Фиксация и откат транзакции.
Транзакция объединяет в себе несколько операторов SQL . Если в результате выполнения хотя бы одного из запросов произошел какой-то сбой, то транзакция тут же откатывается (rollback ). Если все хорошо и все действия в рамках одной транзакции выполнились успешно, то выполняется фиксация (commit ) транзакции и только в этом случае соответствующие изменения записываются в базу данных.
А теперь давайте продемонстрируем пример использования транзакций в СУБД MySQL (в большинстве популярных СУБД этот механизм кардинально ничем не отличается):
Пусть у нас есть тестовая таблица accounts , хранящая сведения о счетах пользователей. И одно поле, которое нас интересует называется balance . При переводе с одного счета на другой должно произойти списание средств на одном счете и зачисление на другом (в целях практики вы можете самостоятельно создать небольшую базу данных).
Транзакция начинается с ключевого слова BEGIN . Два оператора UPDATE внутри транзакции являются часть одной транзакции и могут быть выполнены либо оба одновременно либо ни один из них (должен произойти откат). Команда COMMIT служит для указания окончания транзакции и о фиксации изменений. Если фиксация прошла успешна, то все изменения в исходной БД будут отображены.
Чтобы выполнить откат транзакции можно явно записать команду ROLLBACK .
Свойства ACID.
Итак, мы познакомились с понятием транзакции, фиксации и отката. Теперь давайте рассмотрим четыре очень важных свойства транзакции, о которых частенько любят спрашивать на собеседованиях. Требования ACID в конце 70-х годов сформулировал Джим Грей(лауреат Премии Тьюринга за вклад в развитие баз данных). И вот как они звучат:
- Atomicity — атомарность. То, о чем мы говорили выше. транзакция атомарна, то есть все действия, выполняемые в рамках одной транзакции, это единое целое.
- Consistency — согласованность. Каждая новая транзакция переводит базу данных из одного согласованного состояния в другое. Если ваша БД распредленная, то все ее реплики должны содержать одну и ту же версию данных для обеспечения доступности. Это правило часто нарушается многими NoSQL базами данных.
- Isolation — изолированность. Транзакции не влияют друг на друга. В случае параллельного выполнения не должно происходить частичного обновления данных.
- Durability — надежность. Вы же хотите чтобы в случае сбоев все изменения, внесенные данной транзакцией все же сохранились? Именно поэтому в данном списке есть свойство надежности.
Это тоже база данных, но ручная
Здравствуйте!
Поговорим об базах данных. Сегодня транзакции, ACID и CAP-теорема — теория, которая важна для следующих статей.
Транзакции
Транзакция — это набор действий с данными, объединенный в логическую единицу. Она либо выполняется целиком, либо нет. Классический пример с операцией перевода денег со счета на счет:
Начать транзакцию прочесть баланс на счету номер 5 уменьшить баланс на 10 денежных единиц сохранить новый баланс счёта номер 5 прочесть баланс на счету номер 7 увеличить баланс на 10 денежных единиц сохранить новый баланс счёта номер 7 Окончить транзакцию
Если эти операции выполнять вне транзакции, то ошибка в любой из них оставит оба счета в несогласованном состоянии: например, выйдет так, что деньги снимутся с одного счета, а на другой не придут. С транзакцией таких проблем нет — при ошибке откатятся все операции и для пользователя ничего не изменится.
Все звучит просто, когда с базой данных работает один пользователь: он выполняет транзакции одна за другой и не имеет никаких проблем с тем, что одна транзакция помешает другой. Все меняется, когда пользователей становится много.
Вот что может случиться при параллельном выполнении неизолированных транзакций.
Потерянное обновление
Когда две транзакции записывают разные значения в одну и ту же ячейку, одно из изменений теряется.
Грязное чтение
Когда читаются данные, которые в этот момент изменяются транзакцией, а потом транзакция откатывается и данные исчезают.
Неповторяющееся чтение
Когда несколько раз читаются данные, которые в этот момент изменяются транзакцией — каждый раз данные могут отказаться другими.
Фантомное чтение
Одна транзакция в ходе своего выполнения несколько раз выбирает множество строк по одним и тем же критериям. Другая транзакция в интервалах между этими выборками добавляет или удаляет строки или изменяет столбцы некоторых строк, используемых в критериях выборки первой транзакции, и успешно заканчивается. В результате получится, что одни и те же выборки в первой транзакции дают разные множества строк.
Изоляция транзакций
Чтобы параллельные транзакции могли выполняться, не мешая друг другу, придумали концепцию изоляции транзакций. Всего есть четыре уровня изоляции, но некоторые базы данных вводят свои уровни.
Чтение неподтверждённых данных (read uncommitted)
Самый низкий уровень изоляции. Можно свободно читать незафиксированные изменения других транзакций, но запись идет строго последовательно. Таким образом, исключается только проблема потерянных обновлений: гарантируется, что в итоге в ячейку запишут нужное значение все транзакции по очереди.
Обычно для этого используют блокировку на запись ячеек, предназначенных для изменения в рамках текущей транзакции. На чтение блокировки не ставятся.
Чтение подтверждённых данных (read committed)
Можно свободно читать все изменения своей транзакции и зафиксированные изменения чужих транзакций. Исключаются потерянные обновления и грязное чтение, остаются проблемы неповторяемых чтений и фантомов.
Повторяемое чтение (repeatable read)
Можно читать все изменения только своей транзации. Данные, измененные другими транзакциями, недоступны. Остается только проблема фантомных чтений.
Сериализуемый (serializable)
Транзакции полностью изолируются друг от друга, каждая выполняется так, как будто параллельных транзакций не существует.
ACID
Это набор из четырех требований к транзакционной системе, обеспечивающих максимально надежную и предсказуемую работу. Не все базы данных полностью реализуют ACID.
Атомарность (atomicity)
Атомарность гарантирует, что каждая транзакция будет выполнена полностью или не будет выполнена совсем. Не допускаются промежуточные состояния.
Согласованность (consistency)
Согласованность — это требование, подразумевающее, что в результате работы транзакции данные будут допустимыми. Это вопрос не технологии, а бизнес-логики: например, если количество денег на счете не может быть отрицательным, логика транзакции должна проверять, не выйдет ли в результате отрицательных значений.
Изолированность (isolation)
Гарантия того, что параллельные транзакции не будут оказывать влияния на результат других транзакций. Мы разобрались с изоляцией выше.
Долговечность (durability)
Изменения, получившиеся в результате транзакции, должны оставаться сохраненными вне зависимости от каких-либо сбоев. Иначе говоря, если пользователь получил сигнал о завершении транзакции, он может быть уверен, что данные сохранены.
CAP-теорема
Она гласит, что в распределенной системе можно обеспечить только два свойства из трех: согласованность, доступность и устойчивость к разделению. Помогает понимать, как конкретная распределенная система будет работать и чего от нее ожидать.
Согласованность данных (consistency)
Когда во всех узлах в каждый момент времени данные согласованы друг с другом, то есть не противоречат друг другу. Если в одном из узлов в ячейке базы данных есть данные, такие же данные есть на всех остальных узлах.
Доступность (availability)
Когда любой запрос может быть обработан системой, вне зависимости от ее состояния.
Устойчивость к разделению (partition tolerance)
Когда расщепление системы на несколько изолированных секций не приводит к некорректному отклику от каждой из секций: отвалилась сеть между двумя узлами, но каждый из них может корректно отвечать своим клиентам.
Все распределенные базы данных так или иначе в лучшем случае реализуют два свойства из трех, жертвуя оставшимся.
В следующей статье — о редких базах данных, которых вы не увидите в обычных проектах. Там нам и пригодится вся эта теория.
Требования 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-средства могут существовать и развиваться параллельно и решать абсолютно разные задачи.