От переводчика: Догматы - гарантия прогресса, толковать их опасно, приходится разрушать (Станислав Ежи Лец)
Не смог не перевести еще одну заметку Стоунбрейкера о теореме CAP, опубликованную на этот раз в блоге его компании VoltDB. По сути, в ней нет ничего особенно нового, но ее заключительная часть интересным образом перекликается со статьей Иппократиса Пандиса и др. Выполнение транзакций, ориентированное на данные, перевод которой мы также публикуем в своей библиотеке. Действительно, производительность аппаратуры и "одноузловых" СУБД возрастает, и насколько объемные массивно-параллельные системы понадобятся в будущем (по крайней мере, для поддержки приложений OLTP), становится просто непонятно.
Меня можно обоснованно упрекнуть в том, что я публикую перевод заметки, написанной в ответ на заметку, которую я не перевел и не опубликовал. Но я никогда не скрывал своей предвзятости. Я перевожу то, что мне нравится, и то, с чем я, как правило, согласен. Если кому-то ближе позиция Коды и его единомышленников из сообщества NoSQL, пишите комментарии, пишите свои статьи, переводите близкие вам публикации, и мы все это с удовольствием опубликуем (конечно, при наличии требуемого технического качества текстов).
Кстати, сам я не являюсь абсолютным защитником незыблемости принципов ACID (в отличие от Стоунбрейкера, у меня нет своей коммерческой системы, принципы организации которой я был бы обязан отстаивать хотя бы по маркетинговым соображениям). Поэтому мне, в частности, близка и позиция Дональда Коссмана (Donald Kossmann) и др., состоящая в том, что нельзя заставлять людей платить за согласованность данных, если в их приложениях это не требуется (равно как нельзя лишать людей согласованности данных, если в их приложениях она необходима). Мир многолик, и одним универсальным заклинанием, будь то ACID или теорема CAP, в нем не обойдешься.
Сергей Кузнецов
Состоялся еще один раунд онлайновых разговоров о теореме CAP, поскольку Internet-сообщество продолжает обсуждать ее последствия для баз данных в компьютерных сетях. Кода Хэйл (Coda Hale) недавно написал хорошо принятую заметку под названием "You Can't Sacrifice Partition Tolerance" ("Нельзя жертвовать устойчивостью к разделению"), признанную Эриком Брювером неплохой. Кода активно ссылается на статью о теореме CAP Brewer"s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services Гильберта (Seth Gilbert) и Линч (Nancy Lynch).
В длинной заметке Коды повсюду заметно неправильное восприятие моей позиции относительно теоремы CAP. Кода пишет: "Вопреки утверждению Майкла Стоунбрейкера, разделения (читай: отказы) действительно случаются". Другие люди выступают с аналогичными комментариями, так что позвольте мне восстановить истинное положение вещей.
Я неуклонно и многократно пытаюсь высказать всего лишь четыре соображения. Наиболее важное соображение состоит в том, что использование теоремы CAP только для оправдания отбрасывания свойства согласованности из набора свойств ACID является ущербным. В реальном мире отказ от согласованности не приводит к повышению уровня доступности. Следовательно, согласованность отбрасывается в обмен на ничто. Это ужасающий технический компромисс, и, следовательно, теорема CAP поощряет принятие инженерами ужасных решений.
Соображение 1: Теорема CAP опирается на идеализированную и неполную модель ошибок, связанных с данными
У меня имеются два основных возражения против формулировки понятия ошибки в теореме CAP:
- В этой модели не затрагивается несколько важных классов ошибок, с которыми приходится справляться администратору реальной системы.
- В модели предполагается ошибочное, с точки зрения реального мира, поведение, по крайней мере, для одного важного вида отказов.
В связи с этим, отношение к теореме CAP как к практическому руководству является крайне сомнительным. Позвольте мне пояснить. В теореме CAP не рассматриваются следующие важные источники отказов:
Борбаги (bohrbug): Это повторяющиеся ошибки в СУБД, которые приводят к ее выходу из строя. Другими словами, даже если доступно несколько реплик базы данных, та же самая транзакция, запущенная над репликами, приведет к выходу из строя их всех. Несмотря ни на что, мир остановится, и высокая доступность останется недостижимой целью.
Ошибки приложений: Приложение непреднамеренно изменяет базу данных (все копии). Теперь база данных повреждена, и здравомыслящий администратор остановит мир и вернет базу данных в согласованное состояние. Опять же, высокой доступности достичь невозможно.
Человеческие ошибки: человек вводит команду, эквивалентную rm * в мире баз данных, и вызывает глобальную остановку работы. Нет возможности продолжить функционирование.
Изменение конфигурации аппаратных средств (reprovisioning): Многие (хотя и не все) СУБД приходится выводить из рабочего состояния для изменения конфигурации аппаратуры для увеличения (или уменьшения) ее обрабатывающей способности. Опять же, это типичная операция, вызывающая "остановку мира".
Это примеры незамаскированных отказов. Все эти ситуации могут привести к недоступности распределенной системы. В терминах теоремы CAP, просто невозможно обеспечить доступность при наличии подобных проблем. Обсуждение поддержки любых двух свойств из согласованности , доступности и устойчивости к разделению здесь совершенно неуместно.
Теперь обратимся к отказам одного узла. Кода считает такую ситуацию разделением сети. С точки зрения Коды, отказавший узел является одним разделом, и оставшиеся N -1 узлы образуют другой раздел. Руководствуясь теоремой CAP, при наличии разделения сети необходимо выбрать одно из двух - доступность или согласованность. Однако реальный мир, очевидно, показывает, что при таком отказе можно обеспечить и согласованность, и доступность. Нужно просто переключиться на узел-реплику транзакционно согласованным образом. В частности, по крайней мере, в системах Tandem и Vertica именно это делается в течение многих лет. Следовательно, отношение к отказу узла как к разделению сети является, очевидно, некорректным выводом из теоремы CAP.
Аналогичное утверждение можно сделать по поводу разделений сети, в которых один узел отщепляется от оставшихся N -1 узлов из-за отказа сети.
Резюмируя свое первое соображение, повторю, что в теореме CAP предполагается наличие надежных приложений, надежной СУБД, надежных людей и отсутствие изменений в аппаратных ресурсах. К сожалению, все эти проблемы присутствуют, и их наличие должно приниматься во внимание. Кроме того, отношение к отказам узлов как к разделению сети приводит к очевидно неправильным выводам.
Соображение 2: Распределеленные системы изобилуют техническими компромиссами
Если во внимание принимаются все ошибки, которые только могут проявиться, то реальным вопросом, которым должен озаботиться инженер, является следующий: "Какие ошибки можно скрыть и какой ценой?". Это инженерный компромисс между стоимостью выполнения системы и вероятностью ее отказов. Кода обращается к этой проблеме в конце своей заметки. Для меня ответ на сформулированный выше вопрос существенно зависит от частоты разного рода ошибок. К сожалению, на ответ очень сильно влияет реальная операционная среда. Например, ОС MVS компании IBM значительно надежнее Linux или Windows. Он также зависит от того, насколько трудно скрывать ошибки. В частности, с Византийскими отказами (Byzantine failure) справиться гораздо труднее, чем с ошибками, вызывающими безусловный останов системы.
Таким образом, при конструировании распределенной системы применяется сложный набор технических компромиссов, для которых часто оказывается невозможно привести строгую формулировку.
Соображение 3: Теорема CAP часто используется неуместным образом для обоснования технических решений
Это мое наиболее важное заявление. Разработчики многих систем NoSQL отказываются от поддержки ACID-транзакций, обосновывая свое решение теоремой CAP. В частности, они утверждают, что разделения сети случаются, делая из этого вывод, что требуется пожертвовать либо доступностью, либо согласованностью. Они предпочитают жертвовать согласованностью. Я полагаю, что это очень плохой технический компромисс.
Доводы очень просты. По моему опыту, разделения сети случаются не часто. В частности, они происходят менее часто, чем суммарное проявление борбагов, ошибок приложений, человеческих ошибок и событий изменения конфигурации. Поэтому не так уж существенно, что будет делаться при возникновении разделения сети. Обеспечение устойчивости системы к разделению сети не приведет к значительному повышению уровня доступности, поскольку к глобальным отказам системы будут проводить более часто случающиеся события. Следовательно, согласованность жертвуется в обмен на ничто. Это соображение в более развернутой форме представлено в моей презентации о "городских мифах".
По сути, в этом соображении я аргументирую нежелательность принятия технических решений на основе теоремы CAP.
Соображение 4: Производительность системы в одном узле коренным образом меняет характер технических обсуждений
Некоторые люди утверждают, что системы следующего поколения будут выполняться на тысячах узлов. Теоретически, будет возрастать вероятность отказов всех возможных видов. Увлеченность индустрии технологиями типа MapReduce, прекрасного решения для массивно-параллельного выполнения пакетных операций, как кажется, приводит к выводу, что все решения, относящиеся к работе с крупномасштабными данными (big data), должны обязательно развертываться в больших сетях, которые включают ненадежные серверы.
Технологии нового поколения СУБД, таких как VoltDB, демонстрируют скорость, более чем в 50 раз превосходящую скорость традиционных SQL-серверов. Поэтому, если для поддержки некоторого SQL-приложения требуется 200 узлов, то с использованием VoltDB для поддержки того же приложения, вероятно, хватит 4 узлов. Вероятность отказа 200 узлов значительно отличается от вероятности отказа четырех узлов.
Основная мысль здесь состоит в том, что скорость локального выполнения, несоменно, имеет значение. Как правило, применение "грубой силы" большого числа узлов является плохой идеей, поскольку приводит к более частым отказам и, следовательно, большему числу проблем.
В заключение еще раз замечу, что, по моему мнению, нельзя относиться к теореме CAP исключительно как техническому руководству. Теорема CAP опирается на неполную модель ошибочных ситуаций, которая может легко привести к неверному выбору сложного набора инженерных компромиссов. При выборе этих компромиссов необходимо также учитывать скорости локального программного обеспечения и аппаратуры, особенности базовой программной среды и уровень важности для бизнеса согласованности данных.