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

Три совета разработчикам приложений, чтобы перестать мучиться и начать получать удовольствие от баз данных?

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





Антон Бушмелев: Надо знать свою предметную область. Если работаешь с ORM, как обычно у нас происходит: я “наг*внокодил”, как оно будет работать с базой, мне не важно! Не надо так абстрагироваться. Если что-то не знаешь, можно подойти, спросить. Потраченные пять минут времени сильно сэкономят время в будущем. Не надо стесняться, я тоже много чего не знаю. Если есть эксперты, с которыми можно посоветоваться, надо общаться.


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


Михаил Тюрин: Здесь все очень серьезно, никаких шуток, разработчикам приложений надо понимать, что работа с данными – это одна из основных задач, которая должна ими решаться. Надо подключать ДБА на ранних этапах.

Мы сейчас все “заражены” современными моделями управления (agile и прочие вещи). Надо и ДБА, и devops-ов как можно раньше подключать к процессу принятия окончательного решения, потому что ошибиться в данных может оказаться очень дорого.

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


Брюс Момжан: Я могу ответить относительно Постгреса: нужно проводить исследования и узнавать его разносторонние возможности. Многие, приходя из других СУБД, пользуются им по привычке: «Я всегда делал это так, буду делать как привык». В этом нет ничего плохого, но Постгрес – это намного больше, чем хранилище данных. Не обязательно использовать Постгрес так, как вы использовали БД до этого, изучайте современные нестандартные функции, относящиеся к консистентности данных, моделированию данных, они сделают ваше приложение проще и чище.

Место ДБА в процессе разработки и эксплуатации IT-систем?

Александр Чистяков: ДБА – это человек, который находится на обеих сторонах моста – разработка и эксплуатация. Человек, который смотрит за тем, чтобы не происходило чего-то непредвиденного. Он должен концентрировать в себе знания о том, как работает база данных, и передавать их другим.

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

Дмитрий Васильев: Как я уже говорил, база данных – это сердце и кровеносная система, поэтому обсуждение и архитектурное построение должно происходить при участии ДБА. Это одно из ключевых мест участия в разработке, не только как devops решать проблемы приложения.

Михаил Тюрин: Одно из центральных мест.


Брюс Момжан: ДБА – не просто люди, которые стоят между приложением и ОС, они занимаются производительностью, надежностью хранилища данных, задержками ответов сети. То есть гораздо больше завязаны на аппаратное обеспечение и его производительность. Запросы к базе данных могут быть как очень простыми, так и очень сложными – тут сложно предсказать. ДБА участвуют в выборе аппаратного обеспечения, типа хранилища и видят картину в целом, ведь требования к производительности могут меняться.

Чем определяется продвинутость какой-то СУБД относительно других?

Александр Чистяков: Это – субъективная вещь. На конференции по Постгресу я считаю, что PostgreSQL – продвинутая, а если бы здесь была конференция по MySQL – извините, ребята…

Антон Бушмелев: Коммьюнити и обучение. Обучение по постгресу страдает. В Oracle все расписано по частям. Есть отдельные курсы для тех, кто занимается бэкапами, тех, кто занимается производительностью, и, собственно, “джобстартом”.

Коммьюнити и обучение – без этого никак. База, может быть, очень продвинулась, но с ней никто не работает, и никто не поможет, если возникнут какие-то проблемы.

Дмитрий Васильев: Удобством использования, доступностью документации, доступностью кода. Первое – мониторинг, второе – доступность информации в базе. Третье – возможность повлиять на происходящие процессы, в т.ч. возможность что-то в коде посмотреть, поправить или переделать.

Михаил Тюрин: Продвинутость – это же довольно субъективное понятие. Если у вас хорошо получается делать вашу работу, то ваша технология продвинутая. У меня получается делать хорошо свою работу на Постгресе, поэтому я считаю ее продвинутой.

Но есть и объективные стороны, такие как открытость комьюнити. В открытом комьюнити заложены, культивируются и воспроизводятся те принципы, понятия и идеи, которые могут быть эффективны. Хоть Stonebraker и ругается сейчас и перечеркивает все, что он когда то сделал, все это было сделано неплохо. Stonebraker – это человек, который получил только что премию Тьюринга, он в свое время заложил архитектурные основы в том числе и Постгреса.

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

Какой бы вы совет дали молодым специалистам, которые хотят заниматься базами данных?

Александр Чистяков: Читайте классику, смотрите вокруг себя, ходите на конференции.


Антон Бушмелев: Следить за мониторингом. Мониторинг – наше все. Повесить основные триггеры на мониторинг, чтобы потом спать спокойно. Вместо того, чтобы каждый полчаса делать health checks, можно все это подать на мониторинг, а самому заниматься саморазвитием.

Дмитрий Васильев: Изучайте, не бойтесь пробовать, обязательно экспериментируйте. Я не говорю об экспериментах на “продакшне”, это оборачивается изменением зарплаты. Ищите что-то новое и неизведанное!

Михаил Тюрин: Не бояться читать, разбираться в сложных проблемах. Надо понимать, что такое транзакция, почему она вообще существует, зачем она нужна.

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

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

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

Брюс Момжан: Быть открытым ко всему новому. Когда я занимался консалтингом, были люди, которые специализировались на самом популярном на тот момент программном обеспечении. Они знали всё об MS DOS и Windows, это было самое актуальное ПО, и они на нём выезжали. Через 2-3 года приоритеты сменились, другое ПО стало актуальным, а за ним другое. Многие смотрят на эту смену приоритетов, и думают: «Всё приходит и уходит, я просто буду заниматься тем, чем занимаюсь». Но если присмотреться, можно понять, какие технологии будут оставаться жизнеспособными долгое время, а какие – просто милые мимолетные идеи.

Какое технологическое достижение/изобретение в мире баз данных вы считаете наиболее прорывным и почему?

Александр Чистяков: Появление баз данных NoSQL.


Антон Бушмелев: Оракловый кластер пока что еще никто не повторил, это штука специфическая, но хорошая. Особенно в 12 версии. Прорывные технологии, которые сейчас используются – это in-memory. Это отсутствие индексов, меньше блокировок, соответственно. Отсутствие индексов – это уже большой плюс.

Дмитрий Васильев: Наверное, самое большое изменение, которое произошло в базах данных за последние десятки лет – это column-oriented базы.

Михаил Тюрин: Базы данных – это то, что приносит в инструменты программиста понятие транзакции: то, что мы сохранили, может быть нами получено в будущем. Это одна из ключевых особенностей транзакции. И как только мы начинаем про это говорить, мы начинаем говорить о проблеме recovery. Потому что, если случается авария, а они случаются часто, выходят из строя узлы в распределенной системе. И как раз возможность обрабатывать эти аварии – это то, что решают современные БД. Вы за что-то заплатили и не хотите, чтобы ваша денежка пропала – эту задачу база данных помогает решить очень эффективно.

Брюс Момжан: Если говорить об аппаратном обеспечении, то самым главным изменением стало появление SSD. До этого всё хранилось на магнитных носителях, которые вращались, и доступ к этим данным был очень медленным. Использование SSD существенно улучшило производительность.

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

Какие недостатки есть у PostgreSQL и Open Source вообще?

Александр Чистяков: У open source в принципе нет недостатков, это единственный живой workflow, который может существовать. Еще до того как появилось слово open source, люди обменивались исходниками, это было всегда в научном сообществе. Атомную бомбу передали нам. Это же сделали не из-за денег, а из-за убеждений.

Касательно PostgreSQL – недостатки вполне преодолимы. Это отсутствие должного количества рабочих рук. Единственный вариант бороться с этим – это увеличивать visibility, доносить свою мысль до людей, который хотят участвовать. Я думаю, что open source в конечном итоге – это единственный живой путь. Все то, что является closed source, просто не успевает за open source.

Антон Бушмелев: Огромное количество костылей. С самого начала – это одни костыли сплошные, нет единого решения – все пилят под себя. Куча оберток, все это сложно поддерживать. С PostgreSQL для меня конкретно проблема – это бэкап больших баз. Невозможно определить, на чем конкретно висит сессия, нет дебага. Дебаг есть, но он на всю базу. Смысла читать двухгиговую “портянку” логов, когда мне нужно что-то выяснить по конкретной сессии, я не вижу.

Дмитрий Васильев: Когда ты делаешь какой-либо продукт для себя, ты можешь в него включить вещи, присутствие которых тебе никому не нужно доказывать. Когда ты используешь open source решение, ты не можешь поддерживать такой большой проект как Посгрес самостоятельно, но тебе нужны в нем изменения. Этот недостаток может быть и плюсом в том смысле, что приходится доказывать сообществу необходимость фич в open source продукте.

Михаил Тюрин: Если сравнивать подобные сообщества по количеству участников – может показаться, что постгресовое комьюнити менее представлено.

Имеет ли Постгрес недостатки как продукт? Нет, я так не считаю. Может быть, можно произвести работу по интеграции с другими комьюнити. У постгрес есть своя ниша, многие компании эффективно его используют.

Брюс Момжан: Основной недостаток – сложно найти опытного специалиста. Большинство просто адаптирует Постгрес под компанию. Каждые три месяца мы устраиваем обучающие семинары для людей, которые пришли в Постгрес из других СУБД. Мы ведь не можем надеяться, что появится группа людей, освоившая Постгрес каким-то чудесным образом. Поэтому должны учить их, растить быстро и последовательно.

Ещё одна вещь, пугающая людей в ПО с открытым исходным кодом – выбор. В коммерческом ПО обычно есть один определенный способ решения конкретной задачи. В Постгрес – множество приложений и дополнений, так что решений той или иной задачи может быть множество.

Какой бы вы выделили top современных СУБД и почему он именно такой?

Александр Чистяков: У меня есть два личных топа – есть то, что я люблю, и есть то, что я делаю. Я люблю Постгрес, я меньше люблю MySQL. Еще меньше я люблю Firebird, потому что я никогда с ним не работал, но я люблю людей, которые его делают. А все остальное я не знаю. В плане бизнеса, я очень много делаю MySQL. Новые проекты, которые хоть какое то отношение имеют к процессингу денег, я делал на PostgreSQL, а больше ничего нет. Кроме PostgreSQL и MySQL больше ничего нет.

Антон Бушмелев: Oracle, так как я с ней работаю уже 7 лет. Постгрес – потому что большой потенциал. MS SQL – потому что в России это 1С. 1С очень хорошо работает с MS SQL, хоть и пытаются доказать, что Постгрес там как-то шевелится. Но буквально на той неделе видел инсталляцию на 7 терабайт, и на MS SQL это все работает.

Дмитрий Васильев: Oracle, PostgreSQL, MS SQL, DB2.


Михаил Тюрин: Oracle, Постгрес, решения Microsoft и IBM – это все развитые системы. У них есть свои плюсы и минусы, истории применения. MySQL, конечно.

Из современных новых систем я бы выделил Redis, MongoDB. Из специализированных решений – системы Vertica, Cassandra. Есть и другие подобные вещи, такие как Kafka. Есть специализированные решения по распределенному хранению, такие как Zoo Keeper.

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

Oracle продолжает лидировать при очень больших объемах. Постгрес на данный момент может покрыть 95-98% рабочих нагрузок, но остаются эти 2%.

Плюс Microsoft SQL в том, что он интегрирован с окружением Windows. DB2, на мой взгляд, недооценивают. Это очень хорошая система, но из-за тесной привязки к аппаратному обеспечению IBM, она кажется очень негибкой, и это многих отталкивает.

Про NoSQL. Несколько лет назад считалось «благородным» не использовать SQL и не иметь необходимости в администраторе баз данных. Но примерно полтора года назад всё изменилось, потому что, несмотря на простоту развертывания NoSQL, стала ощущаться нехватка многих функций. Сейчас зачастую используют смесь Постгреса и NoSQL и добиваются потрясающих результатов. Так что NoSQL – не последнее испытание для реляционных БД, но они существуют уже 30 лет, развиваются, адаптируются, и я думаю, так будет продолжаться и дальше.

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