Подумайте дважды, прежде чем отказываться от КИСЛОТЫ и выбросить крышку

Большинству разработчиков программного обеспечения базы данных скучны, вернее - должны быть скучными. Вы кладете данные, вы их вынимаете, и все работает как сытый немец. Настоящая магия происходит во внешнем интерфейсе или на среднем уровне API. К сожалению для большинства разработчиков и, к счастью, для тех, кто специализируется на базах данных, это не всегда так просто.

В информатике ACID - довольно древняя концепция, которая практически исчезла из модных технических статей, в то время как теорема CAP по-прежнему считается «свежей» и заслуживающей ссылок из-за ее теоретической основы для продуктов NoSQL. Но что они означают и важны ли они для нас?

Давайте оставим этот вопрос в покое и отправимся в живописное путешествие во времени, чтобы понять контекст.

История уровней изоляции ACID и транзакций

Нет, не 1965 год, не кислота Битлз. Начнем немного позже - 1983 год, когда Триллер Майкла Джексона сошел с ума в хит-парадах, Возвращение джедая вышло на большие экраны, Рональд Рейган отправил войска на Гренаду, Apple выпустила Лизу, IBM выпустила PC XT, а Microsoft выпустила первую версию Word. В том же году два немецких профессора объявили 4 основных свойства транзакции базы данных, доступность которых значительно облегчит боль программистов, создающих надежные системы:

  • A tomicity - гарантия записи "все или ничего" (подумайте о COMMITs)
  • C onsistency - целостность (подумайте об ограничениях первичного ключа, ограничениях внешних ключей и т. д.)
  • Решение I - контроль параллелизма (подумайте об этом достаточно долго, и ваша голова взорвется)
  • D надежность - НЕ потеря данных (подумайте о противоположности MongoDB 2010 года)

Хотя A, C и D якобы были встроены в старую иерархическую базу данных IMS еще в 1973 году, эта статья оказала большое влияние на современные реляционные базы данных, поддерживающие эти свойства, а также на развитие ANSI SQL.

Перенесемся в 1992 год, когда Nirvana выпустила Nevermind, Курт Кобейн женился на Кортни Лав, Radiohead выпустили Creep, Билл Клинтон был избран президентом США, был изобретен формат файлов MP3 и Бешеные псы открыли новую эру экранного насилия. Самым большим событием в мире баз данных был SQL-92, серьезное расширение и модернизация тогда еще относительно незрелого стандарта SQL-89. В нашей истории самым важным дополнением было определение уровней изоляции транзакций - это I в ACID. Некоторые фанатики осознали, что из-за одновременных операций чтения и записи данных могут возникнуть различные сложности, которые были классифицированы как отдельные явления: грязное чтение, неповторяющееся чтение и фантомы.

Я не буду вдаваться в подробности, так как в Интернете есть множество материалов, посвященных именно этому. Я настоятельно рекомендую начать с блога Влада Михалчи и его практического введения. Чтобы полностью разобраться в этом, вам действительно нужно согреться, открыть два окна терминала SQL и пройтись по примерам. Кстати, ознакомьтесь с его сообщениями о Hibernate, особенно если вам не повезло, что вы загнали себя в угол, пытаясь элегантно кодировать что-то с Hibernate.

В 1995 году Radiohead выпустили The Bends, Клинтон бомбил сербов в Боснии и ту же самую толпу, которая теперь выстраивалась в очередь за продуктами Apple, стояла в очереди, чтобы купить Windows 95. Что до бедного оле Кобейна - он не дожил до 95-го. Что еще более важно для нас, несколько исследователей Microsoft решили, что Win95 - это недостаточно для червей, и опубликовали исследовательский документ под названием Критика уровней изоляции ANSI SQL. Выявлено еще 4 явления и 2 новых уровня изоляции. Любопытно, что ответ команды ANSI SQL был безмолвным: до сих пор действует оригинальная классификация 1992 года. Что еще больше раздражает тех, кто занимается разветвлением волос, таких как ваш покорный слуга, можно утверждать, что это позволило некоторым крупным поставщикам избежать неправильной классификации поддержки их уровня изоляции (например, СУБД Oracle Serializable на самом деле Snapshot Isolation ).

Мы заканчиваем 2013 год, обещаю, но не без дальнейших отклонений. Вся популярная новая музыка и фильмы были отстойными и были отстойными в течение многих лет, Хиллари Клинтон была на пике своей популярности (вскоре после того, как она разбомбила Каддафи в Ливии), и Билл Гейтс наконец признал, что Ctrl-Alt-Del был ошибка"". Как бы то ни было, мы сосредоточились на академической статье, опубликованной несколькими греческими профессорами с безобидным названием Обзор условий согласованности. Остерегайтесь греков с исследовательскими работами; в данном случае они собрали несколько тонн червей, запихнули их в гигантскую банку и затем открыли ее. Кайл Кингсбери из Jepsen.io аккуратно резюмирует все новые уровни изоляции следующим наброском:

Мы скоро вернемся к этой диаграмме. А теперь поговорим о

Теорема CAP

Впервые опубликованная в 2000 году, а затем доказанная в 2002 году (больше никаких воспоминаний - ура!), Теорема Брюера, также известная как CAP, утверждает следующее: вы можете выбрать любые 2 из следующих 3:

  • C onsistency - как в I [solation] в ACID
  • A доступности - на каждый запрос приходит ответ; каждые означает 100% каждые!
  • P artitioning - система продолжает работать, даже если сообщения отбрасываются или задерживаются между узлами. Обратите внимание, что в основе теоремы лежит массовое оборудование в кластерной конфигурации.

Другими словами, можно классифицировать системы как C-P, CA- или -AP.

Почему теорема хорошо известна? Есть небольшая компания под названием Amazon, которая до конца 90-х годов запускала полную базу данных на одном экземпляре / одном сервере СУБД Oracle. В то время база данных электронной коммерции Amazon была крупнейшим развертыванием Oracle в мире, и неудивительно, что возникли серьезные проблемы с параллелизмом - сливки тогдашних экспертов по базам данных Oracle почесали головы, наблюдая за странными явлениями, с которыми они никогда раньше не сталкивались. Проще говоря, система достигла ограничений масштабируемости односерверной архитектуры.

Затем инженеры Amazon поняли, что можно избавиться от оков КИСЛОТЫ, и перешли в область –AP. Кого действительно заботит последовательность кликов по товарам, поиска и т. Д.? В конце концов они даже перенесли управление запасами на конечную согласованность, полностью осознавая возможность невыполненных заказов из-за отсутствия запасов - ужасная проблема с балансом меньше нуля, которая в конечном итоге сопровождается согласованностью. В случае Amazon этот сценарий действительно тщательно отслеживается, но оказывается, что это крошечная часть заказов, которые обрабатываются в процессе исключения. В общем, для Amazon это сработало безупречно, и это также придало большое значение теореме CAP.

Так в чем же тогда моя претензия к теореме CAP? Насколько это полезно на практике. Обратите внимание, что:

  • Он распространяется только на обычное оборудование (без SAN, без Infiniband)… Хорошо, это не важно, если вы не фанат Oracle RAC.
  • Он был основан на уровне изоляции Linearizable. Я знаю, что всего одна коммерческая СУБД (Azure Cosmos DB) поддерживает эту точную модель, хотя, честно говоря, теорема распространяется на всю красную область на скетче Джепсена выше, который включает более распространенную изоляцию. уровни.
  • Он вообще не учитывает задержку. Для любых практических целей задержка чрезвычайно важна - в реальном мире запоздалый ответ часто означает отсутствие ответа.
  • Здесь говорится о 100% доступности, чего просто нет в реальном мире.

Давайте посмотрим на реальный случай, если вы не доверяете мне слепо (никогда не доверяете). Есть еще одна небольшая компания под названием Google. Одной из больших проблемных областей Google является назначение ставок в режиме реального времени для интернет-рекламы. Это серьезная проблема из-за масштаба, а также из-за требований согласованности - это касается одновременных заявок и денег. Действительно, серьезный материал. Инженеры Google, естественно, попытались решить эту проблему способом Amazon - при этом многие разработчики пытались решить отдельные проблемы согласованности по частям. И это вроде отстой. Так что какой-то супер-пупер (а не супер-умный) инженер Google понял, что лучше решить проблему раз и навсегда, чем иметь сотни просто супер-умных инженеров, пытающихся решить их индивидуально (и часто плохо). Итак, господа, прямо из уст Google:

F1: масштабируемая распределенная база данных SQL

Для экосистемы продуктов AdWords требуется хранилище данных, поддерживающее транзакции ACID. Мы храним финансовые данные и предъявляем жесткие требования к целостности и согласованности данных. У нас также есть большой опыт работы с системами конечной согласованности в Google. Во всех таких системах разработчики тратят значительную часть своего времени на создание чрезвычайно сложных и подверженных ошибкам механизмов для обеспечения согласованности и обработки данных, которые могут быть устаревшими. Мы считаем, что это недопустимое бремя для разработчиков и что проблемы согласованности следует решать на уровне базы данных.

Позже F1 превратился в Spanner - глобально распределенную базу данных, которая поддерживает максимально возможный уровень изоляции строгая согласованность. А доступность, я слышал, вы спросите? 99,999%. Да, это уже 5 девяток прямо в лицо. Смею вас, попробуйте создать и запустить платформу с такой доступностью. В Spanner есть серьезные проблемы - высокая задержка записи, отсутствие ссылочной целостности, проблемы с онлайн-обновлением схемы и т.д.

И последнее замечание по теореме CAP: посмотрите назад на зеленую область на эскизе, и вы увидите RC - Read Committed. Оказывается, RC - это уровень изоляции по умолчанию в старой Oracle BDMS, который, как правило, достаточно хорош для многих бизнес-приложений. Любопытно, что я не могу найти ни одного продукта NewSQL, такого как Google Spanner, который использует эту конкретную лазейку - факт, что вы можете получить теоретический cAP (позвольте позвонить это строчная «согласованность», все же намного лучше, чем «конечная согласованность»). Подмигнуть продавцам…

Это просто чушь. Мне чертовски скучно. Есть ли у вас что-нибудь полезное сказать?

Верно, просто проверю ваше терпение. И вам стоит попробовать медитацию, вам будет меньше скучно (и скучно). Без дальнейших церемоний -

Как свести к минимуму выгорание из-за вашей ACID-базы данных

Контрольный список всех вопросов, которые вы должны задать себе при запуске проекта, который включает выбор базы данных. К сожалению, вы не получаете ответов, только вопросы (вы серьезно думали, что получите бесплатные и простые ответы?)

КИСЛОТА

  • Нужна атомарность?
  • Как я буду обрабатывать данные / ссылочную целостность? Хочу ли я найти компромисс между проблемами целостности производства и производительностью?
  • Какой уровень изоляции мне действительно нужен? Если мне нужно идти на компромисс, сколько работы мне нужно приложить, чтобы измерить побочные эффекты?
  • Могу ли я потерять данные, и если да, то сколько?

Доступность / задержка

  • Каковы мои требования к доступности? Каковы компромиссы между доступностью, задержкой и согласованностью?
  • В какой момент высокая задержка означает, что система де-факто недоступна?

Производительность / масштабируемость

  • Каковы мои требования к производительности за 1–3 года? Максимальные теоретические требования к производительности?
  • Насколько хорошо я ожидаю, что система будет масштабироваться (задержка, производительность, доступность) с дополнительным оборудованием?
  • Каковы все различные рабочие нагрузки производительности, которые я могу ожидать (например, полное сканирование таблицы, сканирование разделов, небольшие записи, массовые записи, смешанные чтения и записи, чтения индекса PK, чтения вторичного индекса, небольшие объединения, большие объединения , текстовый / нечеткий поиск, пространственные функции, оконные функции)

Гибкость

  • Будет ли развиваться моя схема базы данных? (НЕТ, НЕТ такой вещи, как «база данных без схемы»! Повторите это еще раз, и я заставлю вас перечитать эту болезненную статью)
  • Будет ли у меня много разных способов доступа к данным (например, присоединения)?
  • Ожидаю ли я иметь сложный оптимизатор запросов для сложных запросов или я могу написать их вручную?

Восстановление данных и отказоустойчивость

  • Если что-то пойдет не так, нужно ли мне восстанавливать момент времени? Если да, то как быстро?
  • Что я готов вытерпеть при выходе из строя некоторых аппаратных компонентов?

Стандарты

  • Если я решу позже перейти на другую СУБД, готов ли я вложить много усилий в переписывание уровня доступа к данным?

Совокупная стоимость владения и риски

  • Что я готов заплатить авансом за проектирование, разработку или текущую?
  • Каков мой аппетит к риску?
  • Могу ли я потерпеть неудачу и повторно платформу в будущем, если молоко скиснет?
  • Могу ли я получить много телефонных звонков поздно ночью, когда что-то пойдет не так?

Мониторинг / приборы

  • Насколько сложны мои запросы? Ожидаю ли я получить подробный анализ производительности запросов?
  • Я, наверное, хотел бы получить встроенные подсказки здравого смысла. Или мне нужно думать о них самостоятельно?
  • Есть ли у меня существующие инструменты APM, с которыми я хотел бы интегрироваться?

Безопасность

  • У СУБД есть хотя бы базовая безопасность, верно?
  • Есть ли у меня требования PCI-DSS или более строгие? Ожидаю ли я готового прозрачного шифрования, поддержки HSM и т. Д.?
  • А как насчет поддержки мультитенантности?

Эпилог

Базы данных на самом деле сложны, часто утомляют, и в лучшем случае они возвращают только те данные, которые вы в них загружаете. Тем не менее, если вы являетесь каким-либо внутренним разработчиком, вам действительно стоит перекусить и понять основы моделей ACID и изоляции. С другой стороны, если вы считаете себя экспертом по базам данных, вам следует следить за продуктами, предлагающими «настраиваемую согласованность» (хотя все еще довольно незрелыми), а также продуктами NewSQL (Google Spanner, Splice Machine, VoltDB, CockroachDB, Apache Phoenix, NuoDB…). Постепенно они заберут большую часть рынка у старых динозавров - запомните мои слова.

Ах да, чуть не забыл - небольшая викторина. Если вы работаете в магазине микросервисов (сейчас они в моде, разве вы не слышали) и выполняете базовую оркестровку между сервисами, какой уровень изоляции вы получаете? Вы получите ничего! Вы даже не получите A, C, I или D в ACID! То есть вы теряете какие-то данные или имеете проблемы с целостностью, но это нормально, потому что вы не можете точно измерить, сколько у вас утечки, чтобы вы могли спать по ночам. Иногда незнание - действительно лучшая политика. Забудьте обо всей совокупности знаний, которые использовались в XA и двухфазных коммитах, потому что у них есть свои проблемы и они не вписываются в аккуратную парадигму RESTful микросервисов. Более того, забудьте всю эту статью, сохраните спокойствие и не пишите код.