Приглашаем на вебинар «PostgreSQL в кейсах».

Уровень сложности — продвинутый, для тех, кто уже использует или обслуживает PostgreSQL.

В четверг, 18 марта, состоится DataBase Meetup Online – встреча для разработчиков и администраторов баз данных.

Начало в 15:00 (время МСК).

Для участия необходимо зарегистрироваться

В ответ на отправленную заявку вы получите ссылку на трансляцию и все явки-пароли.

Сегодня стартовал закрытый бета-тест. В данный момент известно достаточно мало подробностей о данном стартапе (например, неизвестно кто за ним стоит), но задумка смотрится весьма интересно. FathomDB предлагает нам «реляционные БД как сервис».
Если по сути, то в данный момент это MySQL на EC2 с различными «плюшками». Следовательно, можно без особых проблем начать использование данного сервиса, или наоборот — прекратить.

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

Что интересно — WebMynd, тоже YC-стартап (очередное гетто? ;), начали использовать FathomDB ещё в прошлом году и неплохо его пиарят :)

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

В этой статье я хочу рассказать про ещё один этап развития DWH в Тинькофф Банке.

Ни для кого не секрет, что требования к наличию Disaster Recovery (далее DR) в современных бизнес информационных системах относятся к категории «must have». Так, чуть более года назад, команде, занимающейся развитием DWH в банке, была поставлена задача реализовать DR для DWH, на котором построены как offline, так и online процессы банка.

В продолжение цикла статей об «Идеальном» кластере хочу поделиться моим опытом развертывания и настройки Multi-Master кластеров MySQL.

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

Как грибы растут стандарты, фреймворки, развивается и становится всё слаще синтаксис, растут разнообразные инструменты.

И это здорово!

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



Попробуйте пройти несложный тест и определить — не мамонт ли Вы в мире PHP? Не грозит ли Вам, как специалисту, вымирание в ближайшее время?

Тест, разумеется, пятничный и шуточный. Но в нём всё-таки есть доля истины.

Вероятно, вы знаете, что обслуживание баз данных это целый комплекс процедур: создание бэкапов, проверка целостности, обслуживание индексов, статистики и т.д. На просторах сети (да и на Хабре в том числе) на эту тему написано множество статей и рекомендаций. Однако занимаясь внедрением «1С: Предприятие», нам частенько приходится сталкиваться с тем, что обслуживание баз данных настраивается либо неправильно, либо по очень упрощённой схеме. Например, чтобы не заморачиваться с управлением журналами транзакций, для «боевых» баз устанавливается Простая модель восстановления (Simple Recovery model). И это несмотря на то, что потеря информации за пару часов уже критична для компании. Иногда задача по сжатию файлов БД включается в регулярное обслуживание («шобы не росло»), или после обновления индексов идёт уничтожение статистики и прочие подобные ляпы. Так происходит потому, что чаще всего в компаниях нет опытного администратора БД и обслуживанием приходится заниматься кому-то из сотрудников ИТ-службы – «невольному» администратору баз данных (DBA). При этом такой DBA не всегда осознаёт все риски и возложенную на него ответственность.

Здравствуйте, меня зовут Евгений, и я веб разработчик. Несколько лет назад мне перепала функция DBA (Database Administrator), я получил по этому поводу несколько сертификатов и решал соответствующие задачи. Я давно хотел описать задачу версионирования базы данных, но мне казалось, что для этого должны быть какие-то беспроигрышные варианты, которые хорошо знают умелые дяди, а я просто чего-то недопонимаю. Вчерашнее собеседование и последующий поиск по тематическим ресурсам показал, что это не так, и задача действительно сложна, актуальна и не решается однозначно. Разберём её по пунктам.

Что мы версионируем

Мы используем контроль версий только для DDL (Data Definition Language) запросов. Сами данные нас не интересуют. Почему? Рассмотрим два крайних случая.

1. Данных мало (скажем, менее 50 мегабайт). В этом случае, мы можем просто периодически делать полный дамп базы и смело складывать его в репозиторий.
2. Данных много (больше гигабайта). В этом случае версионирование нам мало поможет, всё равно разобраться в этом будет довольно проблематично. Целесообразно в данном случае использовать стандартную схему с бекапами и архив логом, которая позволяет нам получить целостную версию базы на любой момент во времени.

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

За последнее десятилетие мы разработали и усовершенствовали несколько методов, которые позволяют дизайну баз данных эволюционировать параллельно с разработкой приложения.

Это очень ценное свойство гибких методологий. Методы опираются на применение непрерывной интеграции и автоматизированного рефакторинга к разработке баз данных, а также на тесное взаимодействие между разработчиками приложений и администраторами БД. Эти методы работают как в препродакшн и в уже стартовавших системах, в свежих проектах без легаси, так и в унаследованных системах.

В последнее десятилетие мы наблюдаем рост гибких методологий. По сравнению со своими предшественниками, они изменяют требования к дизайну баз данных. Одно из важнейших среди требований – идея эволюционной архитектуры. В гибком проекте вы предполагаете, что не можете заранее поправить требования системы. В результате, иметь детализированную, четкую стадию дизайна в начале проекта становится непрактично. Архитектура системы должна эволюционировать одновременно с итерациями софта. Гибкие методы, в частности, экстремальное программирование (XP), имеют набор методик, которые делают эту эволюционную архитектуру практичной.

Недавно столкнулся с одним приложением, которое генерировало запросы к БД. Я понимаю, что этим никого не удивишь, но когда приложение стало тормозить и мне пришло задание разобраться в чём причина, я был сильно удивлён, обнаружив эти запросы. Вот с чем иногда приходится иметь дело SQL Server:

Друзья, сегодняшняя публикация открывает новую рубрику в блоге конференции PG Day Russia: интервью со специалистами в области эксплуатации баз данных. Беседа с профессионалом — отличная возможность приоткрыть завесу тайны, узнать секреты профессии, выяснить чем и как зарабатывают коллеги, посвятившие свою жизнь работе с СУБД. Мы надеемся, что предстоящие выпуски помогут вам взглянуть на рабочий процесс с новой стороны, дадут возможность задать волнующий вас вопрос, получить совет или же сориентироваться в дальнейших шагах по собственной карьерной лестнице.

В нашем пилотном интервью мы поговорили с Алексеем Лесовским, DBA компании Data Egret (бывш. PostgreSQL-Consulting). Алексей является специалистом с многолетним стажем в области администрирования PostgreSQL. Регулярные посетители технических конференций знают не по наслышке, что его доклады и мастер-классы славятся глубиной проработки и вниманием к деталям.

PG Day: Леша, давай начнем с вводной информации. Расскажи в двух словах про себя, как ты решил стать DBA и как ты вообще до такой жизни, что называется, докатился.

АЛ: Вообще, идеи стать DBA изначально у меня не было. Я к этому не стремился. Я работал системным администратором в компании, которая занималась веб проектами, администрировал линуксовые сервера, занимался виртуализацией. Весь их стек был построен на современных технологиях. Там были рельсы, там были мемкэши, редисы и был Postgres.

Он оперативен, но в то же время спокоен. Он умен, аналитически мыслит и всегда сосредоточен. Это основные качества, благодаря которым можно достичь успехов специалисту DBA.

В перерывах между докладами, в кулуарах конференции PG Day’16 мы буквально на пару минут отвоевали внимание опытных администраторов и задали вопросы о том, что они думают о своей профессии, какие досадные ошибки они допустили в работе и какие советы дали бы новичкам. Антон Бушмелев, Александр Чистяков, Дмитрий Васильев, Михаил Тюрин и Брюс Момжан вспомнили истории на старте своей карьеры и рассказали, сколь тернист оказался их путь.

Совсем недавно мы опубликовали первую часть интервью с ведущими специалистами из компаний РТ ЛАБС, Git in Sky, Postgres Professional, Avito и EnterpriseDB. Если сейчас вы решаете, стоит ли связывать свою жизнь с профессией DBA, то вам придется очень кстати вторая часть советов от спикеров PG Day’16. А если вопросы еще останутся, то вы можете задать их докладчикам текущего года с 5 по 7 июля на PG Day’17 Russia.

Несколько недель назад кто-то создал топик на Reddit с просьбой:

Что бы Вы использовали в качестве лучшей практики Go для доступа к базе данных в (HTTP или других) обработчиках, в контексте веб-приложения?

Ответы, которые он получил, были разнообразными и интересными. Некоторые люди посоветовали использовать внедрение зависимостей, некоторые поддержали идею использования простых глобальных переменных, другие предложили поместить указатель пула соединений в x/net/context (c golang 1.7 используется пакет context).

Что касается меня? Думаю что правильный ответ зависит от проекта.

Какова общая структура и размер проекта? Какой подход используется вами для тестирования? Какое развитие проект получит в будущем? Все эти вещи и многое другое частично влияют на то, какой подход подойдет для вас.

В этом посте рассматрим четыре разных подхода к организации вашего кода и структурирование доступа к пулу соединений к базе данных.

Данный пост является вольным переводом оригинальной статьи. Автор статьи предлагает четыре подхода по организации доступа к БД в приложении написанном на golang

Всем привет! Прошедший год для пользователей и разработчиков Postgres был очень насыщенным. И 2018-й обещает быть не менее интересным и ярким. Под катом я расскажу об одном из первых громких событий для сообщества — PGConf.Russia 2018, и о том, чем запомнился прошедший год для DBA-команды Avito.

Здравствуйте, коллеги!

У нас только что пришла из типографии долгожданная фундаментальная работа Мартина Клеппмана, именуемая в оригинале "Designing Data-Intensive Applications" (анонсировали ее мы еще в сентябре 2016 года). Книга доступна для заказа на сайте (не благодарите, мы сами ликуем)



А в конце ноября прошлого года в издательстве «O'Reilly» вышла долгожданная книга «Database Reliability Engineering», которая, на наш взгляд, отлично дополнила бы работу Клеппмана. Кстати, пока на Amazon — только восторженные отзывы



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

Глава 1. Введение

Цель этой книги – предоставить руководство по развитию на пути становления настоящим инженером надёжных баз данных (database reliability engineer, DBRE). В названии книги мы специально использовали слово инженер, а не администратор.

Бен Трейнор (инженер Google) охаракеризовал эту деятельность так:

В основном, это работа, которая исторически выполнялась отделом эксплуатации (operations team), но с привлечением инженеров с их опытом в проектировании программного обеспечения, а также желанием и умением автоматизировать человеческий труд.

В этой книге вы найдете ключевые принципы, алгоритмы и компромиссы, без которых не обойтись при разработке высоконагруженных систем для работы с данными. Материал рассматривается на примере внутреннего устройства популярных программных пакетов и фреймворков. В книге три основные части, посвященные, прежде всего, теоретическим аспектам работы с распределенными системами и базами данных. От читателя требуются базовые знания SQL и принципов работы баз данных.

В обзорном посте рассматривается раздел «Знание, истина и ложь».

Если у вас нет опыта работы с распределенными системами, то последствия этих проблем могут оказаться весьма дезориентирующими. Узел сети ничего не знает наверняка — он способен только делать предположения на основе получаемых (или не получаемых) им по сети сообщений. Один узел в силе узнать состояние другого узла (какие данные на нем хранятся, правильно ли он работает), только обмениваясь с ним сообщениями. Если удаленный узел не отвечает, то нет никакого способа выяснить его состояние, поскольку невозможно отличить сетевые проблемы от проблем в узле.

Представьте себе Oracle DBA. Ему уже за тридцать, он слегка полноват, носит жилетку, на шее у него висит секретный токен доступа ко всем базам, а в резюме полстраницы пройденных им сертификаций. Суббота. День большого релиза. Кульминация. Время накатывать изменения на базу данных. Он набирает sqlplus, нажимает ENTER и по черному экрану куда-то вверх, в пустоту, устремляются километры SQL команд. Совсем как в звездных войнах. Спустя пять минут все готово. Через час релиз завершен. Работа сделана, день удался. Теперь можно и по паре пива.