Мастер acid что это
Краткое описание программы ACID
Если вы занимаетесь созданием музыки на домашнем компьютере, то наверняка слышали об одной из самых лучших программ-трекеров – ACID.
Когда вы приготовите сэмплы, то чтобы из них получилась готовая композиция, их надо соединить воедино. Для этого и существует такой класс программ, как трекеры. Мы же в этой статье рассмотрим самую лучшую, на мой взгляд, программу в этом роде – это Sonic Foundry ACID v1.0d.
Ладно, перейдём к описанию программы. На рис. 1 вы видите внешний вид программы. Под цифрами обозначено следующее: 1. В этом поле задаётся темп микшируемой музыки; 2. Здесь находится список сэмплов, который вы имеете у себя на компьютере; 3. Так выглядят сэмплы, вставленные в трек; 4. А это очень интересная “фишка”, которая заключается в том, что, если вам надо прослушать какой то кусочек трека, например, для выяснения ошибки в микшировании или для регулировки громкости. Бывает такое, когда в одном месте у трека имеется сильное переусиление и для того, чтобы его устранить надо убавлять громкость у одного или нескольких сэмплов. Ещё функцию, как она говорится в народе, “залупливания” (от слова loop) можно использовать для того, чтобы посмотреть, как будет смотреться тот или иной сэмпл с другим (и). Делается это так: видите на рисунке обведена полоска, а чуть левее и выше значок овала со стрелкой. Если вы нажмёте на этот овал со стрелочкой, то активируется режим петли (loop) и загорится полоска. Полоска – это есть ограничение лупа. Ну и 5-й пункт – это индикатор используемой сэмплами памяти. Чем меньше занимает сэмпл и больше оперативки, тем больше сэмплов поместится в программу для микширования одной композиции.
Как происходит вставка сэмплов в дорожки? После того, как вы запустили программу, у вас на экране будет пустой экран. Слева, под регулятором темпа, находится дерево папок вашего диска, а правее отображаются сами файлы. При одном щелчке, на выбранный файл, вы можете послушать его, а при двойном щелчке, вставить на одну из дорожек. Далее, при наведении мышки на, так называемое, рабочее поле, которое обозначено 3-м пунктом на рис. 1, появляется курсор в виде карандаша. Этим карандашом вы “рисуете” сэмплы на дорожках. К этой теме я вернусь позже. Правее окна с файлами находится регулятор громкости. Кстати, если у вас будет несколько звуковых карт, то там будет несколько таких регуляторов.
Чуть подробнее о вкладках, которые находятся на нижней панели. На рис. 2 изображены вкладки нижней панели: Explorer, Properties, Mixer, Fx1, Fx2. То что отмечено цифрой 1 – это активная вкладка, как видно на рисунке, это explorer. Далее идёт вкладка – properties. Эта вкладка изображена на рис. 3. Справа, там, где во вкладке explorer были файлы, здесь отображаются “внутренности” wav файла. Так выглядит файл звукового формата в любом редакторе, предназначенном для работы со звуком. Слева находится краткая информация о файле, вставленном на одну из звуковых дорожек. Там можно посмотреть формат файла, размер и место расположения на диске. В поле, которое называется “Number of beats”, что переводится как – количество ударов, вводится количество ударов. Стандартный луп ударников состоит из 4-х ударов. Эта опция нужна для того, чтобы настроить темп сэмпла в ручную. Хоть ACID и сам хорошо справляется с этой задачей, но всё же иногда сэмплы получаются такие, что рассматриваемая программа неправильно рассчитывает темп. Но! Знайте, что темп в ACID’е неправильно рассчитывается лишь из-за того, что сэмпл был неправильно нарезан. Например, если в loop’е ударников будет не 4 или 8 beat’ов, т.е. ударов, а 3 или 7. Если вы ещё не знаете, то запомните, сэмпл всегда должен содержать количество ударов кратное 4-м, но бывают исключения, когда сэмпл может содержать 1 или 2 удара. Далее, в опции “Root note for transposing” настраивается, на сколько нот поднять или опустить звучание этого сэмпла. Извините, если я немного не грамотно описал эту опцию, т.к. у меня нет никакого музыкального образования. В опции “Track type”, т.е. тип трека, можно выбрать тип трека. Есть 3 типа, которые можно там выбрать: loop, One shot, Disk-based. Первый тип понятен. Второй тип – это ограничение в “рисовании” сэмплов на дорожке, т.е. обычно вы можете “нарисовать” один сэмпл как единое целое, например, повторив его 4 раза, а при выборе этого типа вам надо будет рисовать сэмплы по одиночке. Не знаю, зачем это понадобилось. Третий тип применяется лишь тогда, когда используемый сэмпл очень большой. Длина, которого, ограничивается лишь количеством оперативной памяти. Хоть я и говорил, что не надо использовать большие сэмплы, но иногда приходится оперировать и такими. Это получается из-за того, что иногда сэмпл нельзя разделить на равные кусочки (ек), а иногда этот сэмпл может и вовсе являться целой композицией. Например, вы делаете ремикс на какую то песню. Далее, во вкладке mixer, находятся те же регуляторы громкости, что и во вкладке explorer справа. Ну, а во вкладках Fx1 и Fx2 находятся настройки спецэффектов, которые можно накладывать на сэмплы. Обычно, у ACID’а нет своих стандартных спецэффектов, но они добавляются туда при установке очередного plug-in’а для звукового редактора Sonic Foundry Sound Forge. Но, например, у меня, во вкладку спецэффектов добавились оные после того, когда я установил программу n-track Studio. Всех особенностей добавления спецэффектов в ACID я не знаю, т.к. редко ими пользуюсь. Все спецэффекты я накладываю в Sound Forge. На рис. 1 выше панельки, на которой регулируется темп, находится панель с настройкой воспроизведения каждого сэмпла отдельно. Там можно настроить следующее: громкость сэмпла, которая будет применена на всю дорожку, на которой находится данный sample; выбрать звуковую карту, с помощью которой будет воспроизводиться данная дорожка (для этого то и сделана вкладка mixer в нижней панели); отключить данную дорожку (mute (значок красного перечёркнутого круга)) и последнее – это solo, т.е. при нажатии на кнопку play, будет играть только эта дорожка (значок жёлтого восклицательного знака).
А сейчас пару пунктов из меню options. Options=>Snap to – здесь настраивается часть сэмпла, до которой при рисовании будет происходить “округление”, т.е. если у вас сэмпл темпом 140 и длинной в 4 удара, то вам будет удобнее рисовать такой сэмпл целыми частями. Провёл мышкой чуть правее и нарисовался первый loop, ещё провёл – ещё нарисовался loop, а если бы не было такого округления, то вам бы пришлось каждый раз делать увеличение рабочего поля и сидеть заниматься “дрессировкой блох”. По умолчанию там стоит авто определение, т.е. размер целого loop’а зависит от масштаба рабочего поля. Ручная же настройка полезна только тогда, когда вам требуется вставить какую то часть сэмпла или вообще из какого то сэмпла сделать новую мелодию, что можно сделать при почти максимальном увеличении, выборе в вышеописанной опции округления до, например, 1/32 части loop’а и “залупливания”. Но делать мелодию в ACID’е вы будете сами, без моих подсказок. Для начала лучше освоить программу в своём основном предназначении, а потом уже издеваться над ней! Далее, options=>time ruler format – здесь выбирается формат представления времени в треке. Я всегда ставлю time, т.е. время (мм:сс), а остальные форматы времени – это уже для “ботаников”.
Как написано в оглавлении, эта статья лишь краткое описание программы ACID, так что, все нюансы вы, надеюсь, постигните сами, но, я думаю, кроме изложенного здесь, вам знать больше особенно ничего и не надо. С этими знаниями вы вполне можете сделать первый шаг в создании собственной музыки, но для этого ведь нужны сэмплы, скажете вы. Да! Нужны сэмплы. Если вы новичок и не умеете делать свои сэмплы, то для начала, чисто для тренировки, можете воспользоваться чужими. Можете, например, вырезать их из готовых песен. Желаю вам удачи в освоении ACID!
Требования ACID на простом языке
Мне нравятся книги из серии Head First O`Reilly — они рассказывают просто о сложном. И я стараюсь делать также.
Когда речь идёт о базах данных, могут всплыть магические слова «Требования ACID». На собеседовании или в разговоре разработчиков — не суть. В этой статье я расскажу о том, что это такое, как расшифровывается ACID и что означает каждая буква.
Требования ACID — набор требований, которые обеспечивают сохранность ваших данных. Что особенно важно для финансовых операций. Мы же не хотим остаться без денег из-за разрыва соединения или ошибки в ПО, не так ли?
Давайте пройдемся по каждой букве ACID и посмотрим на примерах, чем архив лучше 10 разных файлов. И чем транзакция лучше 10 отдельных запросов.
Atomicity — Атомарность
Атомарность гарантирует, что каждая транзакция будет выполнена полностью или не будет выполнена совсем. Не допускаются промежуточные состояния.
Друг познается в беде, а база данных — в работе с ошибками. О, если бы всё всегда было хорошо и без ошибок! Тогда бы никакие ACID были бы не нужны. Но как только возникает ошибка, атомарность становится очень важна.
Допустим, вы решили отправить маме деньги. Когда вы делаете перевод внутри банка, что происходит:
У вас деньги списались
И допустим, что у нас 2 отдельных запроса. А теперь посмотрим, что будет при возникновении ошибок:
1. У вас на балансе нет нужной суммы — система вывела сообщение об ошибке, но катастрофы не произошло, атомарность тут не нужна.
2. У мамы заблокирована карточка, истек срок годности — деньги ей не поступили. Запрос отменен. Но минуточку. У вас то они уже списались!
Ошибка на первом этапе никаких проблем в себе не таит. А вот ошибка на втором. Приводит к потере денег, что явно недопустимо.
Если мы отправляем отдельные запросы, система не может связать их между собой. Запрос упал с ошибкой? Система его отменяет. Но только его, ведь она не знает о том, что запрос «у меня деньги спиши» связан с упавшим «сюда положи»!
Транзакция же позволяет сгруппировать запросы, то есть фактически показывает базе на взаимосвязи между ними. База сама о связях ничего не знает! Это знаете только вы =)
И если падает запрос внутри транзакции, база откатывает всю транзакцию. И приходит в состояние «как было до начала транзакции». Даже если там внутри было 10 запросов, вы можете спать спокойно — сломался один, откатятся все.
Consistency — Согласованность
Транзакция, достигающая своего нормального завершения (EOT — end of transaction, завершение транзакции) и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты wikipedia
Это свойство вытекает из предыдущего. Благодаря тому, что транзакция не допускает промежуточных результатов, база остается консистентной. Есть такое определение транзакции: «Упорядоченное множество операций, переводящих базу данных из одного согласованного состояния в другое». То есть до выполнения операции и после база остается консистентной (в переводе на русский — согласованной).
Например, пользователь в системе заполняет карточку:
Телефон — отдельно код страны, города и номер
Что такое ACID в базах данных?
В частности, ACID имеет отношение к тому, как БД может восстанавливаться после ошибок, возникающих в процессе выполнения транзакции.
В базах данных, следующих принципу ACID, данные остаются целостными и консистентными, несмотря на любые ошибки.
Определение ACID
Atomicity (атомарность)
Атомарность гарантирует, что каждый запрос в транзакции будет выполнен успешно, либо вообще никакой, в случае ошибки одного. Не получится так, что часть запросов выполнятся успешно, а часть с ошибкой. Если хоть одна часть транзакции выполнится с ошибкой, вся транзакция не выполнится. Другими словами под атомарностью можно понимать «всё или ничего».
Consistency (консистентность, согласованность)
Это свойство даёт гарантию того, что все данные будут целостны. Данные будут корректны в соотвествии со всеми предопределёнными правилами, ограничениями, каскадами и триггерами, применёнными к БД.
Isolation (изолированность)
Гарантирует, что все транзакции будут выполняться изолированно. Ни одна транзакция не зааффектит на другую транзакцию. Другими словами, одна транзакция не сможет прочитать данные второй транзакции, которая ещё не выполнилась.
Durability (стойкость)
Durability означает, что когда транзакция будет применена, она останется в системе, даже если БД упала сразу после выполнения этой транзакции. Любые изменения, внесённые транзакцией, должны оставаться навсегда. Если БД сообщила об успешном выполнении транзакции, то она должна быть действительно применена.
Когда пригодится ACID?
Свойства ACID спроектированы для transaction-ориентированные баз данных.
ACID предлагает принципы, которым должны придерживаться базы данных, чтобы быть уверенным в том, что данные не будут повреждены в результате какой нибудь ошибки.
Транзакция это единая логическая операция, которая может состоять из одного или нескольких шагов. Например, транзакцией может быть перевод денежных средств между банковскими аккаунтами (снятие денег из одного и пополнение другого). Если в середине такой транзакции возникнет ошибка, может возникнуть большая неконсистентность в данных. Деньги будут вычтены с одного счёта, но не зачислены в другой.
Вот тут и должны быть применены принципы ACID.
Следуя принципу ACID, база данных будет целостна тогда и только тогда, когда она будет содержать все результаты успешно выполненных запросов, выполненных в транзакции. Любая ACID совместимая БД гарантирует, что будут применены изменения только успешных транзакций. В случае ошибки в транзакции, данные не будут изменены.
Таким образом, СУБД, совместимые с ACID, дают организациям уверенность в том, что данные в их базе данных будут целостны, даже если произойдёт какой-либо сбой в середине выполнения транзакции.
Типы сбоев
Ошибка транзакции
Эта ошибка может произойти из-за некорректных входных данных или любых других нарушений целостности. Она так же возникает в результате тайм-аута, либо в результате deadlock.
Системный сбой
Системный сбой может быть из-за ошибки в коде СУБД, либо аппаратного сбоя.
Медийные сбои
Эти сбои случаются, когда запись или чтение из хранилища невозможны (например сбой в работе жёсткого диска, либо ошибки в работе операционной системе). Эти ошибки возникают намного реже, чем первые 2 типа.
Следование ACID принципам
Все популярные реляционные базы данных следуют принципам ACID. Все они имеют инструменты, обеспечивающие целостность данных при сбоях программного и аппаратного обеспечения, а также при любых неудачных транзакциях.
Но с NoSQL базами данных ситуация обстоит немного по-другому. Эти базы данных часто предназначены для обеспечения высокой доступности в кластере, а обычно это означает, что в некоторой степени жертвуют консистентностью и/или стойкостью. Однако большинство NoSQL баз данных в некоторой степени могут обеспечить атомарность.
Но всё же, большинстве NoSQL баз данных заложены основы целостности данных, что означает, что данные могут быть не синхронизированы какое-то время, но в конечном итоге они всё таки будут синхронизированы.
Вдобавок, некоторые разработчики, такие как MarkLogic, OrientDB и Neo4j, предлагают ACID-совместимые системы управления базами данных NoSQL.
Консистентность и ACID-гарантии в распределенных системах хранения данных
Распределенные системы используют, когда возникает необходимость в горизонтальном масштабировании, чтобы обеспечить повышенные показатели производительности, которые не способна обеспечить за адекватные деньги вертикально масштабированная система.
Как и переход с однопоточной парадигмы на многопоточную, миграция на распределенную систему требует своего рода погружения и понимания того, как это работает внутри, на что нужно обращать внимание.
Одна из проблем, которая встает перед человеком, который хочет мигрировать проект на распределенную систему или начать на ней проект, — какой продукт выбрать.
Мы, как компания, которая «собаку сьела» в разработке систем такого рода, помогаем нашим клиентам взвешенно принимать такие решения применительно к распределенным системам хранения. Также мы выпускаем серию вебинаров для более широкой аудитории, которые посвящены базовым принципам, рассказанным простым языком, и безотносительно каких-то конкретных продуктовых предпочтений помогают составить карту значимых характеристик, чтобы облегчить выбор.
Эта статья основана на наших материалах по консистентности и ACID-гарантиям в распределенных системах.
Что это такое и зачем это нужно?
«Согласованность данных (иногда консистентность данных, англ. data consistency) — согласованность данных друг с другом, целостность данных, а также внутренняя непротиворечивость.» (Wikipedia)
Согласованность подразумевает, что в любой момент времени приложения могут быть уверены, что работают с корректной, технически актуальной версией данных, и могут расчитывать на нее при принятии решений.
В распределенных системах обеспечивать согласованность становится сложнее и дороже, потому что появляется целый ряд новых вызовов, связанных с сетевым обменом между различными узлами, возможностью отказа отдельных узлов и — зачастую — отсутствием единой памяти, которая может служить для верификации.
Например, если у меня есть система из 4 узлов: A, B, C и D, которая обслуживает банковские транзакции, и узлы C и D отделились от A и B (скажем, из-за сетевых проблем), вполне возможно, я теперь не имею доступа к части транзакций. Как мне действовать в этой ситуации? Разные системы принимают разные подходы.
На верхнем уровне есть 2 ключевых направления, которые выражены в CAP-теореме.
«Теорема CAP (известная также как теорема Брюера) — эвристическое утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств:
Когда CAP-теорема говорит о консистентности, она подразумевает достаточно строгое определение, включающее линеаризацию записей и чтений, и оговаривает только консистетность при записи отдельных значений. (Martin Kleppman)
CAP-теорема говорит о том, что если мы хотим быть устойчивы к сетевым проблемам, то мы в целом должны выбрать, чем жертвовать: консистентностью или доступностью. Есть также расширенная версия этой теоремы — PACELC (Wikipedia), которая дополнительно рассказывает о том, что даже в отсутствии сетевых проблем мы должны выбирать между скоростью отклика и консистетностью.
И хотя, на первый взгляд выходца из мира классических СУБД, кажется, что выбор очевиден, и консистетность — самое главное, что у нас есть, это далеко не всегда так, что ярко иллюстрирует взрывной рост целого ряда NoSQL СУБД, которые сделали другой выбор и, несмотря на это, получили огромную пользовательскую базу. Apache Cassandra с ее знаменитой eventual consistency является хорошим примером.
Все из-за того, что это выбор, который подразумевает, что мы чем-то жертвуем, и далеко не всегда мы этим жертвовать готовы.
Часто проблема консистентности в распределенных системах решается просто отказом от этой консистентности.
Но нужно и важно понимать, когда отказ от этой консистентности допустим, а когда она является бизнес-критичным требованием.
Например, если я проектирую компонент, который отвечает за хранение пользовательских сессий, здесь мне, скорее всего, консистентность не так важна, да и потеря данных некритична, если она происходит только в проблемных случаях — очень редко. Худшее, что случится, — пользователю нужно будет перелогиниться, и для многих бизнесов это практически никак не повлияет на их финансовые показатели.
Если я делаю аналитику на потоке данных с датчиков, во многих случаях мне совсем некритично потерять часть данных и получить на небольшом промежутке времени пониженную дискретизацию, особенно, если «eventually» данные я все-таки увижу.
Но если я делаю банковскую систему, консистентность денежных проводок критична для моего бизнеса. Если я начислил пеню на кредит клиента из-за того, что просто не увидел в срок внесенный платеж, хотя он был в системе — это очень-очень плохо. Как и если клиент может несколько раз снять все деньги с моей кредитной карты, потому что у меня в момент проведения транзакции возникли сетевые проблемы, и на часть моего кластера информация о снятии не дошла.
Если вы оформляете дорогостоящую покупку в интернет-магазине, вы не хотите, чтобы о вашем заказе забыли, несмотря на рапортующую об успехе веб-страницу.
Но если вы делаете выбор в пользу консистентности, вы жертвуете доступностью. И зачастую это ожидается, скорее всего, вы не раз сталкивались с этим лично.
Лучше, если корзина интернет-магазина скажет «попробуйте позднее, распределенная СУБД недоступна», чем если отрапортует об успехе и забудет заказ. Лучше получить отказ в транзакции из-за недоступности сервисов банка, чем отбивку об успехе и потом разбирательства с банком из-за того, что он забыл, что вы внесли платеж по кредиту.
Наконец, если мы смотрим на расширенную, PACELC теорему, то мы понимаем, что даже в случае штатной работы системы, выбирая консистентность, мы можем жертвовать низкими задержками, получая потенциально более низкий уровень максимальной производительности.
Поэтому, отвечая на вопрос «зачем это нужно?»: это нужно, если для вашей задачи критично иметь актуальные, целостные данные, и альтернатива принесет вам существенные потери, большие, чем временная недоступность сервиса на период инцидента или его более низкая производительность.
Как это обеспечить?
Соответственно, первое решение, которое вам нужно принять — где вы находитесь в CAP-теореме, вы хотите консистентность или доступность в случае инцидента.
Далее нужно понять, на каком уровне вы хотите проводить изменения. Возможно, вам хватит обычных атомарных записей, затрагивающих единственный объект, как умела и умеет MongoDB (сейчас она расширяет это дополнительно поддержкой полноценных транзакций). Напомню, что CAP-теорема ничего не говорит о консистентности операций записи, затрагивающих множественные объекты: система вполне может быть CP (т.е. предпочитать консистентность доступности) и при этом предоставлять только атомарные одиночные записи.
Если вам этого не хватает, мы начинаем подходить к концепции полноценных распределенных ACID-транзакций.
Замечу, что даже переходя в дивный новый мир распределенных ACID-транзакций, мы зачастую вынуждены чем-то жертвовать. Так например, ряд распределенных систем хранения имеет распределенные транзакции, но только в рамках одной партиции. Или, например, система может не поддерживать «I»-часть на нужном вам уровне, не имея изоляции, либо имея недостаточное количество уровней изоляции.
Эти ограничения зачастую были сделаны по какой-то причине: либо для упрощения реализации, либо, например, для повышения производительности, либо для чего-то еще. Они достаточны для большого количества кейсов, поэтому не стоит рассматривать их как минусы сами по себе.
Нужно понять, являются ли эти ограничения проблемой для вашего конкретного сценария. Если нет, — у вас есть более широкий выбор, и вы можете больший вес дать, например, показателям производительности или способности системы обеспечивать катастрофоустойчивость и т.д. Наконец, нужно не забывать, что у ряда систем эти параметры могут настраиваться вплоть до того, что система может быть CP или AP в зависимости от конфигурации.
Если наш продукт стремится быть CP, то обычно у него есть либо кворумный подход к выбору данных, либо выделенные узлы, которые являются основными владельцами записей, через них проходят все изменения данных, и в случае сетевых проблем, если эти мастер-узлы не могут дать ответ, считается, что данные в принципе, невозможно получить, либо арбитраж, когда внешний высокодоступный компонент (например, кластер ZooKeeper) может говорить, какой из сегментов кластера является основным, содержит актуальную версию данных и может эффективно обслуживать запросы.
Наконец, если нас интересует не просто CP, но поддержка полноценных распределенных ACID-транзакций, то зачастую или используется все же единый источник истины, например, централизованное дисковое хранилище, где наши узлы, по сути, выступают лишь кешами к нему, которые можно инвалидировать в момент коммита, или применяется протокол многофазового коммита.
Первый подход с единым диском также упрощает реализацию, дает низкие задержки на распределенных транзакциях, но торгует взамен очень ограниченной масштабируемостью на нагрузках с большими объемами записи.
Второй подход дает намного больше свободы в масштабировании, и, в свою очередь, делится на двухфазный (Wikipedia) и трехфазный (Wikipedia) протоколы коммита.
Рассмотрим на примере двухфазного коммита, который использует, например, Apache Ignite.

Процедура коммита делится на 2 фазы: prepare и commit.
На фазе prepare рассылается сообщение о подготовке к коммиту, и каждый участник при необходимости делает блокировку, выполняет все операции вплоть до фактического commit не включительно, рассылает prepare на свои реплики, если это предполагается продуктом. Если хотя бы один из участников ответил по какой-то причине отказом или оказался недоступен — данные фактически не поменялись, коммита не было. Участники откатывают изменения, снимают блокировки и возвращаются на исходное состояние.
На фазе commit отправляется фактическое выполнение commit на узлах кластера. Если по какой-то причине часть узлов была недоступна или ответила ошибкой, то к этому времени данные занесены в их redo-лог (поскольку prepare был выполнен успешно), и коммит в любом случае может быть завершен хотя бы в отложенном состоянии.
Наконец, если отказывает координатор, то на prepare-этапе коммит будет отменен, на commit-этапе может быть выбран новый координатор, и, если все узлы выполнили prepare, он может проверить и обеспечить выполнение этапа commit.
Разные продукты имеют свои особенности реализации и оптимизации. Так, например, некоторые продукты умеют в отдельных случаях сводить 2-х фазный коммит к 1-фазному, значительно выигрывая по производительности.
Выводы
Ключевой вывод: распределенные системы хранения данных — это достаточно развитый рынок, и продукты на нем могут обеспечивать высокую консистентность данных.
При этом продукты этой категории находятся на разных точках шкалы консистентности, от полностью AP-продуктов без какой-либо транзкционности, до CP-продуктов, которые дополнительно дают еще и полноценные ACID-транзакции. Часть продуктов может быть настроена в одну или в другую сторону.
Когда вы выбираете, что нужно вам, нужно учитывать потребности вашего кейса и хорошо понимать, на какие жертвы и компромиссы вы готовы пойти, потому что ничего не бывает бесплатно, и выбирая одно, вы, скорее всего, откажетесь от чего-то другого.
Оценивая продукты с этой стороны, стоит обращать внимание на то: