Записки программиста

Темы третьего выпуска: где используется Erlang, о профессиональной этике, Riak, почему все неправильно понимают CAP-теорему, а также о движении NewSQL и базах данных ActorDB, VoltDB, Spanner, Scalaris, Hibari, RethinkDB, FoundationDB, InfiniSQL и Calvin. Предыдущие выпуски: второй, первый.

Слушать онлайн:
http://eaxcast.podfm.ru/_eaxcast/3/

Скачать файл:
http://eaxcast.podfm.ru/_eaxcast/3/file/podfm_eaxcast__eaxcast_103.mp3

Шоу нотес:

• Сергей Кузнецов, Транзакционные параллельные СУБД: новая волна;
• Вместо «CAP» правильно говорить «PACELC» — in the case of partition, does the system choose availability or consistency, else does the system choose minimal latency or consistency, по теме: раз, два, три [PDF];
• Упомянутые СУБД: ActorDB, VoltDB, FoundationDB, RethinkDB, InfiniSQL, Spanner, Scalaris, Hibari, Calvin [PDF];
• Дополнительные материалы по Scalaris: айн, цвай [PDF], драй [PDF], плюс связанные публикации — фир [PDF], фюнф [PDF];

Голоса выпуска: Валерий @sum3rman Мелешкин, Александр @afiskon Алексеев

Фоновая музыка: The Panets — Winter Beats (Big Power Mix)

Александр: Вновь, вновь приветствую вас, дорогие слушатели. Это третий выпуск первого сезона подкаста о программировании EaxCast. Сей выпуск веду я, Александр afiskon Алексеев, и со мной здесь Валерий sum3rman Мелешкин. Здравствуй, Валер.

Валерий: Привет.

А: Нас спрашивают, а что такого классного вы пишите на этом вашем Erlang’е и в каких задачах вообще его используете? Не то, чтобы в этом был какой-то большой и страшный секрет, но мы перед выпуском немного пошушукались и пришли к выводу, что рассказывать мы об этом не будем. Почему?

Дело в том, что есть некоторые вещи, которые делать не принято. О них не часто говорят, но многие считают их само собой разумеющимся. Например, совершенно очевидно, что вы не ходите на работу с грязной головой, в грязной одежде и не играете там весь день в игрушки, не читаете Twitter. Что еще не принято? Не принято выкладывать код на GitHub, если его вы писали в рабочее время. Иначе получается какая-то фигня. Вам за него дали бабла, а вы его так на халяву всем раздали.

Не принято подходить к коллеге и спрашивать «Чувак, а сколько ты зарабатываешь?» Я не знаю, как за рубежом, а в России это считается очень неприличным вопросом. В моем понимании, во всяком случае. Выходит, ты считаешь чужие деньги или типа того. Вообще, слово «деньги» или «зарплата», как я в свое время на своем опыте узнал, не принято говорить в присутствии начальника ни в каком контексте. То есть, вообще. Потому что, если рядом стоит начальник и ты говоришь «деньги», притом в любом контексте, какую-нибудь новость, например, обсуждаешь — неважно, это всегда, оказывается, трактуется, как твое недовольство зарплатой. Ну или по крайней мере есть люди, которые это так воспринимают. Так что, имейте в виду.

Все это я веду к тому, что не принято делать какие-то публичные заявления, если ты не PR. То есть, есть специально обученные люди, PR’ы, и им платят за то, чтобы они делали публичные заявления. А если ты не PR, то как бы и нефиг делать публичные заявления в социальных сетях, в подкастиках, в бложиках. Так что, мы не будем рассказывать, чем мы сейчас занимаемся, но Валера вроде бы как согласился намекнуть, чем он занимался раньше на Эрланге. Вот Валера на Эрланге уже пишет лет тридцать, а я — совсем недавно.

В: На самом деле, я пишу на Эрланге примерно раз в десять меньше. Я пишу три с половиной года на Эрланге, а не тридцать.

А: Самому Эрлангу сколько, лет 28?

В: Ну да, типа того. На Эрланге мне писать приходилось за деньги всяческое, начиная от API серверов, которые были просто с такой логикой, что нужно много куда сходить, много чего сагрегировать, а потом вернуть обратно. Вместо event machine в какой-то момент стало понятно, что, возможно, Эрланг будет удобнее.

Еще мне писать приходилось систему, которая наблюдает за состоянием кластера. Там был такой небольшой DSL, на котором описывались всякие правила. И вот если правило говорит, что скоро будет очень плохо, то кластер надо выключать.

Писал систему реалтаймовой агрегации данных. То есть, есть временные ряды, есть их очень много, они все с большой скоростью пребывают, и их нужно жрать, жрать, жрать. И складывать, агрегировать. Ну и все это дело было распределенным.

А: То есть, это типа базы?

В: Да, типа базы данных. И вот чем-то похожим из той же области я сейчас занимаюсь.

А: Вообще, да, у Эрланга у него такая ниша, в которой он часто применяется, это базы данных, притом распределенные. Можно зайти на ту же Википедию, набрать там «Эрланг» и посмотреть, что на нем пишут. Найдете массу примеров.

Еще я, кстати, вспомнил, что знаю одного чувака, который на Эрланге написал систему, которая… У него как бы провайдер. А система раздает IP-адреса, считает, сколько трафика люди накачали и сколько с них денег взять. И она тоже такая вся распределенная и отказоустойчивая.

Это к вопросу «что же пишут на этом вашем дурацком Эрланге?» Ну, мы что-то все про функциональщину, про языки и так далее. Для разнообразия мы решили в этом выпуске поговорить больше про базюльки. Про базы данных.

Но говорить про этот ваш модный NoSQL неинтересно, потому что вы и так все про него знаете. А если не знаете, то легко нагуглите и про Riak и про MongoDB, и на всех конференциях об этом уже лет пять, наверное, говорят.

В: И SQL — мейнстрим, и NoSQL — уже мейнстрим. А мы все такие немейнстримные, поэтому будем говорить про NewSQL.

А: Да. То есть, MongoDB уже давно у всех в продакшене обкатанная работает. Чего о ней говорить, в самом деле? И книжки написаны, и так далее.

NewSQL — это такое направление. Вот, в NoSQL парни делают очень просто. Они ссылаются на широко известную в узких кругах CAP-теорему так называемую, и говорят, что вот у нас есть CAP-теорема. Она говорит, что в любой системе может быть либо consistency, либо доступность, либо partition tolerance, в смысле — два из трех. И вот если вы выбираете доступность и partition tolerance, то извините, никакого consistency. И отсюда делается вывод, что никаких транзакций, никаких блокировок, ничего такого.

Так работает, например, в какой-то степени, Riak. Хотя там на самом деле все немного хитрее. В Riak они вообще хитропопые. Они говорят, что вы C, A и P можете крутить, как ручки. Можете делать себе побольше consistency, поменьше partition tolerance и все такое.

В: Но это все равно не до конца правда. Потому что в текущем Риаке… Ну, в Риак 2.0 это будет уже немножко по-другому. А в текущем Риаке, до 2.0, даже максимум выкрученный consistency — это read your writes, if writes were successful, otherwise you don’t know what you will read. То есть, если все хорошо, то это consistency будет. А если что-то где-то сломалось по дороге, то есть, я не знаю, доступна была только одна из трех реплик, то непонятно, что будет прочитано потом. А главное, разные клиенты могут потом прочитать разное.

А: Ну, в каких-то задачах это, на самом деле, нормально работает. Например, у тебя социалочка, и ты хранишь там картинки. У тебя свой Инстаграм или та часть Вконтактика, которая хранит фоточки. Там даже если ты потерял фоточку, то, грубо говоря, всем пофиг.

В: Ну нет-нет-нет. Было как-то раз, у Вконтакта упал шард, и у части друзей сломались друзья. Там такие срачики были! «Да ты, меня из друзей удалил!»

А: Подожди, ты говоришь про другую вещь. Я говорю, что Риак хорош, как файловый сторадж для таких вот небольших файликов, тика картинок, аватарок, может быть mp3′шек небольших. У тебя пользователь заливает картинку, ты сгенерил случайный ключ, залил ее в кластер и потом можешь из этого кластера считать.

В: Ну так это вообще immutable data. С immutable data и у Riak и у Cassandra и у всех таких систем все хорошо. А вот если ты потом по этому ключу что-нибудь еще раз можешь записать, то у тебя проблемы. Ну или их нет, если ты знаешь, как с этим жить.

А: Да, но в отличие, например, от Монги… Монга она замороченная в плане настроек. А в Риак ты просто добавляешь узлы и оно саму у тебя и решардится, и реплицируется. А если что-то упало в субботу, то ты приходишь во вторник из отпуска на работу и просто заменяешь эту машину. И тебе как бы ни о чем думать особо не надо. То есть, в Риаке оно так легко и просто.

В: Не все так идеально. В больших кластерах там бывают проблемы типа TCP incast. Но это не для Риака специфичная проблема, а в принципе для систем с quorum read. У тебя одна нода отправляет запрос трем другим. Потом три других отправляют ответ обратно этой ноде, которая это все запросила. То есть, у тебя поток данных в одну ноду может быть довольно толстый. Если у тебя куча таких потоков, то у тебя случается TCP incast. То есть, у тебя сеть становится нагруженной на 100% раньше, чем ты считаешь, что это произойдет.

А: В любом случае, мы не собирались говорить о Риаке. Такой небольшой переходик.

Любой, кто сходил на конференцию типа Highload++, узнал там, что такое CAP-теорема, вернулся домой и в Википедии ввел «CAP-теорема»… Вот у любого человека, при условии, что он хоть раз в жизни думал своей головой, должно было остаться чувство легкого нае… эээ… чувство, что ему сказали полуправду. По ряду причин. Если посмотреть, о чем говорит CAP-теорема, понятно, что математики они такими терминами вообще-то не оперируют.

Ну как бы, интуитивно, да, все понятно. У тебя вот есть база. Если она упала, у тебя нет данных. Но ты можешь ее реплицировать. Если ты ее реплицируешь и мастер упал, то у тебя нет доступности, потому что ты не можешь в реплику писать. А если можешь, то там свои нюансы. То есть, интуитивно оно все так, но все равно, чувство того, что тебе что-то недосказали, оно все равно остается.

И, вообще-то говоря, CAP-теорема немножко не об этом. Этот вопрос хорошо изложен в статье Сергея Кузнецова. Статья называется «Транзакционные параллельные СУБД: новая волна». Это пейпер в PDF, и он довольно широко разлетелся по интернетам. Его можно найти и в HTML версии. Мы ссылочку, разумеется, приложим. То есть, если вам интересно, почему CAP-теорема трактуется неверно, почитайте эту статью. Там все довольно доходчиво описано. Поинт в том, что CAP-теорема — не теорема вовсе…

В: Нет, ну смотри. Есть CAP-теорема, как теорема. Но там довольно четко специфицировано, когда нужно выбирать что. В любой реальной распределенной системе нужно выбрать не два любых из трех, а C или A когда у нас случается partition. Ну и вообще CAP-теорему ругают за аббревиатуру. Есть другая формулировка. К записи подкаста мы приложим точную ссылку и точную формулировку.

В общем, суть в том, что система в случае разделения сети выбирает либо availability, либо consistency. В противном случае система выбирает между повышанным latency и availability. Большинство систем, если они где-то в одном месте выбирают availability, то они просто начинают забивать на consistency, и везде быть availability. Есть интересные системы, которые дают консистенси, когда все хорошо, и используют какие-то ухищрения, когда партишен в сети.

А: Так вот, движение NewSQL, оно о том, что вот мы такие классные, мы напишем как бы облачый MySQL. У вас будет такое как бы облачко, в нем как бы базулька SQL’ная. И вы ходите в это облачко и у вас как бы такой отказоустойчивая, масштабируемая и партишен толерант база данных. И там прямо все здорово и замечательно. В общем, NewSQL говорит, что можно получить сразу все.

Недавно в рассылке erlang-questions некто по имени Sergej Jure?ko… Я почти наверняка произношу фамилию неправильно. Но я нагуглил все статьи по произношению и ударениям, какие смог. Это парень или дядя — не знаю, из Словении. Работает в компании под названием Biokoda. Он написал базу данных, которая называется ActorDB.

Написана она, ну, понятное дело, на Эрланге. Недавно она попала в опенсорс. Она совершенно бесплатная, у нее есть хорошая документация. Можно скачать deb-пакет и попробовать. Чем интересна ActorDB? Вы поднимаете кластер, описываете схему. Схема притом описывается в файлике, который нужно залить на одну ноду и потом он сам разлетается. И начинаете ходить в этот кластер по MySQL’ному протоколу. Утверждается, что оно будет работать вот прям как будто у вас MySQL и вообще, думать ни о чем не надо. Хотя, честно говоря, есть некоторые сомнения на этот счет.

Сомнения заключаются вот в чем. Даже если мы говорим про обычную базу данных, которая работает на одной машине, вот например PostgreSQL. А ведь PostgreSQL считается очень хорошо написанной, безопасной, без ошибок базой данных. Даже в этом случае вы не защищены от человеческих ошибок. Даже вот из недавнего совсем. Была эпичная бага в Постгресе, что если вы используете синхронную репликацию, то у вас на реплики может не доехать каких-то данных. И в результате на репликах у вас все битое. Это мы говорим про очень простой случай, когда у вас есть мастер, есть реплика, и между ними репликация. А теперь представим, что мы говорим про очень сложную систему, в которой много-много машин, и все реплицируется, да само решардится, туда-сюда переезжает. Это первое.

Второе, что меня беспокоит. Как бы, у меня нет сомнений, что все это будет работать. В реальных высоконагруженных системах, у меня, к счастью, есть небольшой, но все-таки опыт, оно действительно как-то так и работает. Берется Мускул, он шардится по диапазонам или хэшам, и данные примерно так группируются, чтобы данные, которые нужно поджойнить, находились примерно на одной машине. И замечательно ходится в разные Мускулы, и все там джойнится, а если оно находится на разных машинах, то джойнится руками на клиенте. «Руками» в кавычках — кодом, разумеется. А если нужно сделать транзакцию между несколькими машинами, то делается двухфазных коммит. Я знаю реальную продакшн систему, где это работает. Довольно известную, между прочим.

То есть, это реально работает. Но это неудобно, потому что приходится руками шардить, решардить, и так далее. Это я все веду к тому, что когда утверждается, что а вот мы напишем такую классную систему, которая все это делает за нас автоматически, ну вот что-то я немного сомневаюсь, что можно сделать такую умную штуку. По крайне мере, не в ближайшие сколько-то лет.

В: По идее, если ты в чем-то не уверен, ты должен либо тестировать, либо верифицировать. Конкретно у ActorDB, поскольку ее пилит один чувак, по крайней мере, в их репозитории коммиты только от одного человека, то, скорее всего, у них тестирование пока что не очень крутое. Но тот же Riak довольно сурово тестируется, особенно в последнее время. Ребята довольно сильно угорели местами даже по Coq. Это такой язык с зависимыми типами. Точнее — система доказательства теорем.

А: Ну, тестирование — это, конечно, хорошо и правильно. И верификация — это тоже хорошо и правильно. Но есть проблема, что они вот абсолютно от всех ошибок не защищают. Вот тот же Эрланг, сколько ему лет, а все равно я дважды за последний год сталкивался с тем, что у тебя нода просто падает без особых причин с segfault’ом. К сожалению, оба раза не писались core dump’ы, но в результате это донастроили.

То есть, казалось бы, обкатанный продукт, который реально тестируется, который считается продакшн реди, и все равно вот просто падает. А теперь представь себе, что у тебя очень много таких виртуальных машин Эрланга. Понятно, что вероятность их падения увеличивается.

В: Смотри. Надежность отдельной виртуальной машины Эрланга не имеет значения в этом случае. У тебя должна быть основа, алгоритм репликации или что там, во-первых, верифицирован, во-вторых, должно быть как-то подтверждено, что его реализация соответствует тому, что там было верифицировано. В случае с Эрлангом это довольно просто сделать, потому что есть даже такие инструменты, как McErlang, которые позволяют потом эрланговый код верифицировать. Ну либо можно доказать алгоритм где-то отдельно, или просто взять доказанный. Написать код на Эрланге. Благо, Эрланг почти похож на псевдокод, который используется в статьях про распределенные системы. И просто написать, например, property based тесты. Это даст достаточную степень уверенности. А все code path, которые не имеют отношения к целостности данных, их не обязательно прямо так грубо и сурово тестировать. Потому что даже если там что-то сломается, у тебя есть еще дофига машин, которые продолжат работать.

Другое дело, что есть такая вещь, как correlated failures. В общем, некоторые баги умудряются случаться везде одновременно. Вот от такого множество машин не спасет.

Возвращаясь, кстати, к CAP. К сожалению, про него чаще всего говорят так, что вот у нас есть выбор два из трех. После этого люди делятся на три класса. Те, кто не поверил, и пошел разбираться, в чем же на самом деле дело. Те, кто решил «а, ну ок, будем забивать на консистенси всегда, и просто фигачить, как получится». И третьи ребята, которые начинают beating the CAP. То есть, «вот мы сейчас сделаем базу данных, которая будет непременно beating the CAP». И потом даже периодически это релизят. Потом, конечно же, у них находят либо ошибки, либо доказательство того, что нефига это CAP не beating. Что на самом деле все вполне укладывается в CAP.

И что самое забавное, CAP часто противопоставляется ACID. Хотя ACID — это гарантии с точки зрения приложения, а CAP — это гарантии с точки зрения распределенной системы. И в принципе, если ваше приложение так устроено, что удается идеально пошардить данные между разными машинами, данные с одного шарда никогда не нужно транзакционно обновлять вместе с данными с другого шарда, у вас все нормально. Или если данные с одного шарда нужно обновлять транзакционно вместе с данными с другого шарда, но при этом видимость этих операций не обязана быть прям вообще одновременной, у вас тоже все нормально. Поэтому тут есть очень много вопросов. И есть всякие разработки, они, правда, по большей части академические, которые так или иначе с этим борятся.

Собственно, от академических разработок, к таким системам, как H-Store и VoltDB. Обе системы, насколько я помню, разработаны при участии небезысвестного Стоунбрейкера. Обе системы основываются на следующем. Мы берем и определенным образом шардируем данные. Например, данные этого юзера хранятся вот на этом шарде, этого — на этом шарде, и так далее. И почти все транзакции про этого юзера. То есть, его какой-то шмот, какие-то его классы, его друзьяшки, и все такое.

А: Но тут есть проблема. Его друзьяшки — это тоже пользователи.

В: Но ведь тебе не нужно одновременно обновлять его друзьяшку и информацию в самом профиле друзьяшки. И даже если нужно, конкретно в данном случае и та и другая база данных позволяет делать транзакции глобальные. Насколько я знаю, может быть, это уже побороли, и там, и там это было медленно. То есть, там был такой глобальный менеджер транзакций. Я не помню, был ли он single point of failure, или он был реплицированный. Но суть в том, что как только тебе нужно сделать глобальную транзакцию, она вся идет в одну точку. И следующая за ней идет в одну точку. И вообще, все они идут в одну точку. Понятное дело, это не очень быстро работает.

Есть такой академический проект Calvin. Вот там эту проблему пытаются решать, хитрым образом сериализуя транзакции. Google в своем Spanner сделал трутайм и сериализует транзакции просто по времени, которое гарантированно не пересекается. То есть, они вместо таймстемпа берут временной интервал и делают так, чтобы временные интервалы не пересекались. Ну и там у них Paxos, и еще у них two phase commit’ы, то есть там довольно таки сильно навернуто. Еще есть линейные транзакции [PDF]. Это когда машины выстраиваются в цепочку ad-hoc. Транзакция бежит из начала в конец и из конца в начало. И по дороге либо все подтверждает, либо не подтверждает.

Еще есть такой проект FoundationDB. К сожалению, никто не знает, что у него внутри, кроме самих разработчиков. Но там есть некоторое количество публикаций, не про внутренности, а про гарантии. И вот эти публикации вызывают доверие. Потому что ребята четко описывают, что они умеют, что они не умеют, когда они это умеют, когда они этого не умеют. Также FoundationDB, опять же, согласно информации с их сайта, написан на эдаком подобии Эрланга, которое написано на крестах, которое генерит кресты. И для тестирования они тоже используют, как я понял, property based testing. Тоже фреймворк, который накручен поверх этого их языка Flow.

А: Ну еще из интересных проектов можно отметить — есть база под названием RethinkDB, сравнительно новая. Она, правда, не совсем из NewSQL, но там есть джоины, а по-моему даже и транзакции.

В: Там есть так называемые микротранзакции. Я начну немного с другого конца. Я говорил про линейные транзакции, а до этого другой подход назывался chain replication [PDF]. Это когда у тебя реплики одного узла выстраиваются в цепочку и данные просто пишешь в начало, а читаешь всегда с конца. И вот внутри этой цепочки данные всегда согласованы. Соответственно, ты в этой цепочке можешь хранить больше одного ключа. И вот такие данные, точно так же, как в VoltDB и H-Store, там ты все данные, которые лежат на этих репликах в этой цепочке ты можешь одновременно нормально обновлять. И точно так же в RethinkDB. Есть еще, например, такая база данных, на Эрланге тоже написанная, называется Hibari. Вот она тоже на chain replication основана [PDF].

А: В любом случае, в подкасте вот так на пальцах объяснять — это довольно пустая трата времени, но мы непременно накидаем ссылок на все эти базюльки. И я абсолютно уверен, у многих из них будет и описание, как они работают, и ссылки на дополнительные источники. Так что, внимательно смотрите в шоу нотес.

В: Ты еще не сказал про InfiniSQL. Это как раз из лагеря чистых in-memory баз данных. Ребята тоже вдохновились Эрлангом, решили сделать Эрланг на C++, и вот на этом нафигачить чистый in-memory SQL. У них там идея, что мы будем периодически бэкапится на диск, а еще мы будем управлять вашими UPS’ами.

А пионером, кстати говоря, in-memory баз данных, притом тоже NewSQL сообщества, была такая базулина, называлась Scalaris. Она и сейчас есть. Это академический проект, но вполне себе рабочий. Написан на Эрланге. Интересен тем, что он офигительно масштабируется, потому что там делается peer to peer overlay, поверх которого делается DHT, поверх этого DHT делается Paxos. То есть, это одна из первых сильно распределенных баз данных, где есть абсолютно нормальные транзакции. При этом она вся такая дико распределенная. То есть, ее прям сразу можно во много датацентров ставить, просто из коробки.

А: Звучит непонятно, но очень интересно. Мне вот прям сразу захотелось ознакомиться. Про все базюльки поговорили, какие хотели?

В: Ну да.

А: В таком случае, видимо, придется закругляться. В этот раз как-то время удивительно быстро пролетело, я лично прям не заметил. Что хочется сказать на последок?

В: Не доверяйте тому, что вам говорят всякие люди. Проверяйте, читайте, разбирайтесь. Не надо бегать и говорить, о том, что вот есть же CAP-теорема, поэтому все, мы по-другому жить не можем.

А: Нет, ну тут следует отдать должное, что здесь использовался очень прагматичный подход. То есть, если бы не это «у нас CAP-теорема, выберите два из трех», то мы бы не имели очень многих хороших систем, которые ставятся рядом с Постгресом и если тебе нужны транзакции, ты ходишь в Постгрес, если не очень нужны, то ты ходишь в Монгу, Риак или во что-то еще.

В: Я на это по-другому смотрю. Для меня весь этот polyglot persistence — это импотенция. Просто дикая импотенция. То есть, ребята решили, зачем делать нормальную систему? Мы сейчас наговнякаем.

А: К счастью, я не чувствую мотивации переубеждать тебя в этом. А мотивацию я чувствую завершить наконец-то третий выпуск.

Дорогие слушатели, пожалуйста подписывайтесь на наши RSS и твитеры. Помните, что подкаст есть в iTunes. Вы можете в свой айфончик его добавить, введя название в поиске. Обязательно пишите нам комментарии и отзывы, как вы оцениваете этот выпуск по шкале от нуля до десяти, где ноль — это «уснул на первой минуте», а десять — «вау, вау, вау, давайте еще». Рассказывайте, о чем вам еще интересно послушать, задавайте вопросы, не стесняйтесь. Мы в комментариях всем отвечаем, если у нас не создается впечатление, что нас жестко тролят.

Помните, что на запись одного такого подкаста мы тратим кучу времени. Все это идет в ущерб сну и личной жизни, поэтому мы будем очень рады, если вы сошлетесь на него в социальных сетях. У нас есть кнопочки социальных сетей, нажимайте, нажимайте, нажимайте, кнопочки.

Вроде, это все. Спасибо, что слушали нас, и до следующего выпуска. Пока.

В: Пока!

Дополнение: EaxCast S01E04, все о прокачке программерских скиллов

Метки: EaxCast.