2014-12-22

Об nxQL

Вышел PostgreSQL 9.4, где фичей №1 заявлен новый тип данных jsonb, по которыму можно строить индексы и делать эффективные запросы внутренностей JSON документа. Теперь вопрос: «Зачем нужна Монга, если JSON можно хранить в Постгресе?» — будут задавать не только шепотом на кухне. Попробую на этот вопрос неответить.

Появление jsonb перечеркивает мои предыдущие тыкания в JSON в PostgreSQL. Если json — это просто строка, которая требует парсинга для каждого обращения к её внутренностям, то jsonb — это некие бинарные данные (как я понимаю, родственные типу hstore), поддерживающие прямой доступ и индексацию. В общем, jsonb — это сильно быстрее, и это гораздо ближе к BSON в Монге. Цель одинаковая — бинарный формат вместо человекочитаемого текста для повышения эффективности доступа.
Follow SQL
Зачем вообще нужно хранить JSON в реляционной базе? Ведь реляционная модель вполне прекрасно может отображать иерархические данные, как в JSON документе. У меня только один ответ — schemaless. Да, та самая бессхемность, которой гордятся NoSQL, внезапно пригодилась в SQL.
На самом деле не так уж и внезапно. Блобы были почти всегда. XMLи закидывать в БД научились давным давно. Теперь же очередь дошла до модного молодежного JSON. Если мы храним его в нереляционной БД, то говорим о документо-ориентированных NoSQL. Если мы храним его в реляционной БД, то говорим о специальном типе данных, который можно вставить в колонку таблицы.
Сложность, жесткость, вредность схемы данных, пожалуй, сильно преувеличена. Всякие Хибернейты или Активрекорды прекрасно прячут эту самую схему от разработчика. Разработчик работает с объектами. Как они сохраняются в базу, уже проблема фреймворка. (Где вы, объектные БД?) Даже проблему миграции, за что не любят схемы, фреймворк может решить.
Другой пример — Кассандра. Не думайте, что NoSQL — это обязательно schemaless. С самого начала в Кассандре была схема, нужно было указать имена и типы данных в колонках. Но это ничуть не мешало вам вставить в строку еще полтора миллиарда колонок с другими именами и произвольными данными. Просто вам самим пришлось бы определяться с типами значений при извлечении. Но в Кассандре 2.0, с появлением CQL 3 все изменилось. Теперь вы обязаны объявлять таблицы заранее. И только после этого делать к ним запросы. В синтаксисе, пугающе похожем на SQL. А динамические данные можно выразить как списки, множества или мапы в качестве значения ячейки таблицы. Как в SQL. Жду, кто сделает еще полшага и позволит сохранять и JSON документы, которые, вообще-то, почти как мапы.
Так чем лучше Монга? Масштабируемостью. Совсем чуть-чуть поплясав с бубном, можно собрать большуший, да еще и географически распределенный кластер, в котором можно хранить все ваши любимые BigData. Ну конечно, еще нужно правильно организовать данные и выбрать ключ шардинга. Такой возможности искаропки у Постгреса нет.
Но какие-то возможности для масштабирования у Постгреса есть. Во-первых, штатная репликация весьма хороша. К тому же, в Постгресе 9.4 её еще улучшили и теперь возможно делать мультимастера. Так, чтобы несколько серверов выступали мастером для разных таблиц (например, по признаку географического местонахождения пользователя), а слейвы имели бы копию таблиц с мастеров. Уже неплохо.
А еще есть Postgres-XC, который умер и родил более свежий Postgres-XL. Это полноценный кластер, построенный поверх модифицированного PostgreSQL. Это не решение искаропки. Это надстройка. Но она делает то, что делает. Решает те же проблемы, что решают многочисленные NewSQL. Пытаются сохранить реляционную модель и SQL как язык запросов, но при этом хорошо отмасштабироваться. И натыкаются на те же самые решения вроде выпиливания единой точки отказа, координации распределенных транзакций, эффективного объединения данных, раскиданных под разным узлам кластера. Последнее, как всегда, нормально работает только если мы правильно выберем ключ шардинга, и в запросе будем его указывать.
Deploy button
А еще Postgres-XL выглядит чертовски сложным в развертывании и настройке. Уж больно много в него входит разных компонент, которые должны работать вместе. Танцев с бубнами предвидится сильно больше, чем в случае Монги. Это напоминает HBase, который сам по себе является надстройкой над Hadoop. А Hadoop, в свою очередь, тоже не так прост. Поэтому теперь уже никто в здравом уме не скачивает HBase с серверов Апача, а берут сборку от Cloudera.
Базы данных становятся настолько сложны, что уже состоят не из одного, а из нескольких продуктов. К нашему счастью, в основном открытых. И координировать эти продукты становится все сложнее. Всякие облака да Докеры тут как нельзя кстати. Вангую, что вскоре все эти наши БД будут поставляться только в виде готовых настроенных образов, а не отдельных пакетов для ОС. Управление конфигурацией становится затратнее собственно разработки.
HTSQL
А вот вам еще одна тенденция. В старой Кассандре обращение к БД происходило через строгое API посредством Thrift. На каждую операцию, будь то получение всей строки по ключу или получение набора колонок по ключу и т.п., рисовался свой RPC вызов, на сервере и на клиенте. А в новой Кассандре есть CQL. Язык запросов. По внешнему виду и по назначению аналогичный SQL. И остается только один вызов в API — выполнение этого CQL. И если будет добавлена какая-то новая фича, будет расширен язык запросов, но не API или протокол, или клиентский код.
Еще более занятен пример графовых БД. Появились они вроде совсем недавно, но успели обзавестись и общим API: Blueprints, и своим специальным языком запросов: Gremlin. Полагаю, что для сохранения конкурентного преимущества, Монге нужно срочно изобрести стандартный язык запросов для документо-ориентированных данных :)
Забавно, что переводить SQL в запросы к Монге уже научились. С другой стороны, тот же LINQ давно имеет API для конструирования правильных SQL запросов. Становится почти без разницы, работать через API или через язык запросов.
451 Research — Data Platforms Landscape Map
Итак. Сочетание заранее определенной схемы и динамических данных — да. Горизонтальное масштабирование и кластеризация — да. Возникновение стандартных языков запросов в дополнение к API — да. Поставка готовых образов для развертывания в облаках — да. Это то, что происходило, происходит и будет происходить в ближайшем будущем среди систем хранения структурированных данных, будь то NoSQL, SQL или NewSQL. И я нарекаю это nxQL.

2014-12-09

О HappyDev

Новый, две тысячи четырнадцатый, HappyDev завершился. Успешно.

Участником я был на десятках конференций. Докладчиком я был несколько раз, на конференциях такого масштаба. А теперь я еще и организатором оказался. Совсем чуть-чуть. Ну попереписывался с докладчиками, ну порулил расписанием, ну подвез Макса Дорофеева из аэропорта на б.о. им. Стрельникова.
Кстати, Максиму очень понравилась хэппидевовая шапка-ушанка, снег (в Москве в последние два года со снегом напряженка, а ту неделю, что он там все же был, Максим случайно провел в Тайланде) и омское метро.
Я замечал, что когда приезжаешь на конференцию докладчиком, то другие доклады проходят мимо мозга. Буквально. Сидишь, слушаешь. А что услышал, не запоминаешь. Совсем. Потому что до своего доклада ты волнуешься, как его, свой родной, хорошо прочитать. А после своего доклада радуешься, что все уже позади. На остальные доклады наплевать.
Когда ты еще и организатор, ситуация усугубляется. Ибо тебя больше волнует, чтобы микрофоны работали, чтобы презентации (их правильная версия) были на экране, как правильно произносится фамилия докладчика, о чем там будет следующий доклад, чтобы его правильно объявить, сколько там еще времени на вопросы, как бы отобрать микрофон у того чувака в зале, который задает уже третий вопрос подряд и куча других мелких вещей. А доклады? Ну что доклады. Докладчики что-то говорят. Слушатели проявляют интерес. Аплодисменты в конце есть. Все ок.
Так что давайте все поблагодарим тех людей, которые бегали, рвали, метали и организовывали: Аню, Гришу, Сашу (он так усердно три часа жарил шашлыки на морозе, что в результате заболел), Алёну, Ксюшу, Женю (и еще одного Женю, без которого интернета не было бы вообще). А также многих сотрудников компаний 7bits и Avelix. А также тринадцать штук добровольцев-падаванов, которые взяли на себя самую тяжелую физическую работу (сильные программисты вырастут).
Спасибо группе «Моя дорогая» за душевные песни, которые отвлекли от неизбежной пьянки запланированного употребления алкоголя. Омичи, помните, что рядом с вами, в одном городе, рождается настоящее, уникальное и неповторимое Искусство, Музыка и Поэзия.
Конкурсы обошли меня стороной. Как-то некогда было искать пару для кофе, а на второй день кофе вообще не приехал (еще бы, -30 по цельсию). Кстати, в процессе подготовки этих кофейных промокодов произошло небольшое столкновение между альтруизмом, который призывал всем выдать одинаковый код, и жадностью, которая призывала всем выдать уникальный код. Победил реализм. А квест я заметил только в тот момент, когда кто-то попытался сфотографировать толпу народа перед столовой в прыжке. Беда была в том, что сфотографировать людей в прыжке на телефон оказалось почти невозможно. Можно либо зависнуть в воздухе, либо в гневе растоптать телефон за тормозную камеру.
ИП Дорофеев
Какие-то доклады я все же послушал.
Александр Чернышев четко и конкретно рассказал про Swift. К сожалению, я никогда не разрабатывать под iOS, поэтому могу только сказать, что код на Objective-C со слайдов я прочесть не могу, взгляд спотыкается о квадратные скобки, а вот код на Swift вполне читаем. И еще у меня вызывает сомнение тезис о том, что Swift является функциональным языком.
Катя Боброва объяснила про разные виды тестирования, как они друг с другом сочетаются, зачем их надо делать. Удивительно, но у меня в голове это пересеклось с системно-инженерным подходом в изложении Анатолия Левенчука позднее. Разделяй и властвуй. Раздели систему на маленькие кусочки вдоль и/или поперек, и тестируй их.
Максим Дорофеев в очередной раз показал, что его нужно, можно и весело слушать независимо от того, о чем он говорит. Доклад был хороший, мастер-класс был потрясающий. Вот ссылки на все ексельки с кривульками: http://bit.ly/ttrs-pln, http://bit.ly/prj-est-tmpl, http://bit.ly/ebdc-tmpl, http://bit.ly/Reliable-Scrum. Вангую появление всяких вероятностных графиков во всяких жирах, редмайнах и ютреках. Ребята из JetBrains, у вас есть реальный шанс вырваться вперед, если первыми запилите.
Женя Тюменцев снова отжег про математические доказательства SOLID принципов. Не вдаваясь в подробности: разработчики, помните, когда вам говорят поменьше пользоваться switch, это не потому, что старшие товарищи такие злые, а потому, что это все имеет математическое обоснование. Почему это не работает на модели акторов?
Антон Плешивцев поделился интересным опытом разбора пользовательских запросов (на пользовательском языке) с помощью Clojure.
Анатолий Левенчук попытался сдвинуть нам мышление. К сожалению, доклад был дистанционный, поэтому, может, проняло не всех. А я совершил глупость, прочитав книжку до доклада. Поэтому ничего особо нового не услышал. Ну как книжку, скорее конспект лекций. Безусловно приятно понимать, как системный подход работает в инженерии. Безусловно радостно знать, что этому теперь учат, пусть и не здесь. Не знаю, как у вас, а я от прочтения книжки получил радость узнавания. Ну и нахватался некоторых умных слов :)
На второй день я сам провел мастер-класс по NoSQL (презенташечка есть, видео не будет). И сходил на Дорофеева, где мы вынимали бусинки из носков и рисовали кривульки.


Бассейн и глинтвейн были теплыми, воздух и снег были холодными. Все было хорошо. Через год надо повторить.