В суете и быстротечности нашей жизни нет ничего неизменного, лишь непостоянство — верный признак того, что жизнь продолжается. Почти два года мы с Иваном Самсоновым бесперебойно раз в две недели выпускали свежий и сочный выпуск RubyNoName подкаста, но в какой-то момент эта деятельность перестала приносить нам обоим радость и счастье. А что есть жизнь, как не попытка успеть за отведенный нам на земле срок испытать как можно больше счастья? Моя жизнь тесно переплелась с Chef, Vagrant и автоматическим управлением инфраструктурой, и это был вопрос времени, когда разработка с помощью Ruby, Rails и их друзей перестанет меня интересовать.

До выхода PostgreSQL 9.3 еще 5 дней, поэтому самое время поговорить не о технических вещах.

28 сентября в Москве в «Цифровом Октябре» пройдет очередная конференция RailsClub. Как и в прошлом году, в этот раз будет много известных иностранных докладчиков, но лучше сходите на сайт, чтобы я не пересказывал здесь всю программу. После конференции, по традиции, будет after party, поэтому планируйте эту субботу так, чтобы у вас осталось хотя бы несколько часов после конференции. Как всегда, я рад буду познакомиться со всеми, кого знаю виртуально или, вообще, не знаю, ведь именно для этого и существуют оффлайновые мероприятия.

Любой блог либо обновляется, либо мертв. Конечно, и этот блог тоже когда-то умрет, но время для этого еще не пришло, так что сегодня мы поговорим о CAP-теореме.

В вольной формулировке это звучит приблизительно так: «Любая распределенная система не может быть одновременно непротиворечива, доступна и устойчива к выходу из строя узлов». За подробностями отсылаю к русскоязчыной статье Ивана Сагалаева.

CAP теорема прекрасна тем, что позволяет взглянуть на многие сложные системы гораздо проще. Более того, она позволяет легко объяснить, почему создать систему, которая «будет правильно работать всегда», невозможно. Но все это было бы просто интересным поводом для размышления, если бы никак не применялось на практике.

Иногда при эксплуатации проекта возникает вопрос, какие запросы в БД выполняются дольше всего или потребляют наибольшее количество времени или ресурсов.

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

Во-первых, я давно хотел это сделать, а сегодня сделал — теперь блог будет доступен по адресу http://evtuhovich.ru. По старому адресу он тоже будет доступен, но основным теперь будет этот. Дело в том, что этот блог — это единственное место, где я публикую хоть какие-то тексты, поэтому оставлять его на домене третьего уровня мне показалось неправильно.

Во-вторых, 14 июня в Москве пройдет конференция DevConf. На ней в очередной раз я в составе RailClub помогаю организовывать Ruby-секцию. Пока заявок на доклады немного, всего 5, но мы уже работаем над тем, чтобы это была достойная локальная Ruby тусовка, так что приглашаю прийти всех желающих. О докладах я напишу подробнее попозже, когда список окончательно сформируется.

Два дня назад, 13 мая, вышла beta 1 PostgreSQL 9.3. Во-первых, это хороший знак, что уже пора обновляться на 9.2, либо выбирать 9.2 как основную БД. 9.3 планируется зарелизить в третьем квартале 2013 года.

Обо всех новых возможностях 9.3 можно почитать на официальной wiki.

Но чтобы не только почитать, но и попробовать, я напишу здесь, как поставить 9.3 beta 1 на OSX.

В прошлый раз я обещал написать о том, что в проектах с более менее серьезной нагрузкой БД либо помещается в память, либо не работает. Ситуация в современном мире меняется в связи с появлением SSD дисков, но пока что они стоят достаточно дорого, по сравнению со старыми добрыми вращающимися дисками. Чтобы «потрогать» это руками, проделаем несложный тест.

Я долго считал партиционирование плохой практикой, а само слово не любил из-за кальки с английского, которую крайне сложно выговорить с первого раза. И если слово «партиционирование» я так с первого раза и не выговариваю, то саму практику пришлось признать как необходимое и неизбежное зло. Чтобы никто не подумал, что я делаю что-то плохое, я использую для этого термин «инженерный компромисс», звучит умнее и не так обидно.

Иногда так случается, что на проекте необходимо использовать более одного сервера баз данных. Оказывается, в rails можно достаточно удобно поддерживать актуальность нескольких БД с помощью миграций.

Чтобы рассказать о тонких моментах pg_repack, мне понадобится немного углубиться в тему блокировок в PostgreSQL. Конечно, лучше всего начать читать про них в официальной документации. Для этой статьи достаточно понимать, что эксклюзивная блокировка (ACCESS EXCLUSIVE LOCK) препятствует выполнению всех операций, включая SELECT, и она нужна для операции ALTER TABLE.

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

Одной из бед всех версионных БД является разбухание таблиц. Все бы ничего, но если количество активно используемых данных перестает влезать в оперативную память, то время обработки запросов к БД чрезвычайно сильно возрастает (об этом я напишу в ближайшем будущем). И чтобы «впихнуть» размеры таблицы в нужный размер, иногда приходится делать некоторые нетрадиционные трюки.

В эту субботу 15 декабря я выступал в Ульяновске с докладом «Нетрадиционное использование Ruby и PostgreSQL». Несмотря на несколько провокационное название, доклад был посвящен вполне обыденным вещам: о том, как использовать Ruby и PostgreSQL не в web-проекте с Rails. Я рассказал о Ruby внутри Vim, hstore и PostgreSQL массивах внутри Rails (кстати, hstore и ARRAY неоднократно упоминались на конференции, так что я был неоригинален), а самая забавная часть моего доклада была посвящена несуществующей документоориентированной БД rmongo.rb. Видеозапись второго дня еще доступна на сайте Railsclub, и я надеюсь, что и первый день скоро появится в общем доступе.

Исходные коды, которые связаны с докладом, я выложил на Gist, сам доклад я выложил на Slideshare.