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

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

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

Эта статья берет за основу SQL Server, но эти методы также поддерживаются Postgres и MySQL.

Всем привет!

Наверное, многие из нас делали REST API, либо пользовались чьим-то готовым. Разберём в статье "невероятные" трюки, которые помогут сделать ваше API на голову выше, чем у других.

Статья расскажет, как использовать SQLmap и похожих инструментов для автоматизации решений заданий по sql injection на одном из популярных CTF ресурсов. В статье зайдем немного дальше, чем просто модификация risk-level «if you know what i mean». Задания не будут полностью разобраны для решения, флаги необходимо найти самостоятельно.

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

«Отличие enterprise [решения] от всего остального — он всегда идёт от запросов бизнеса и решает какую-то бизнес-задачу.» [src]

• поиск отрезков, пересекающих точку/интервал
• слияние отрезков по максимальному перекрытию
• подсчет количества отрезков в каждой точке

• Postgres: bloat, pg_repack и deferred constraints
  
• Ограничения (сonstraints) PostgreSQL: exclude, частичный unique, отложенные ограничения и др
  

При постоянной работе с MSSQL необходимо создавать различные объекты БД: таблицы, представления, триггеры и т.д.

В статье приведу шаблоны SQL запросов, которые помогут, и, возможно, стандартизируют подход создания кода на языке T-SQL.

Кроме этого, опишу о том, как я веду репозиторий БД в системе контроля версий.

Вы любите просыпаться от звонка/сообщения руководителя или бизнес-партнера с просьбой срочно проверить данные и актуальность дашбордов? Я - нет.

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

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

Пролог

Под перечислимым типом обычно понимают тип данных, который может принимать ограниченное и, как правило, небольшое число значений. Его выделяет то, что эти значения часто хардкодятся программистами в исходный код. И, как следствие, пользователи и операторы приложения не могут менять множество значений перечислимого типа. Их меняют только разработчики, зачастую с соответствующими исправлениями в коде и бизнес-логике приложения. Примерами перечислимых типов могут быть: времена года, месяцы, направление типа въезда/выезд или in/out, какие-нибудь типы или категории чего-нибудь, и так далее. В PostgreSQL подобную функциональность могут и реализуют различными способами. Этому посвящена статья.

В преддверии старта нового набора на курс «Базы данных» продолжаем публиковать серию статей про шифрование в MySQL.

В предыдущей статье этой серии мы обсудили, как работает шифрование с главным ключом (Master Key). Сегодня, основываясь на полученных ранее знаниях, посмотрим на ротацию главных ключей.

Ротация главных ключей заключается в том, что генерируется новый главный ключ и этим новым ключом повторно шифруются ключи табличных пространств (которые хранятся в заголовках табличных пространств).

Давайте вспомним, как выглядит заголовок зашифрованного табличного пространства:

В преддверии старта нового набора на курс «Базы данных» продолжаем публиковать серию статей про шифрование в MySQL.

В предыдущей статье этой серии (Шифрование в MySQL: хранилище ключей) мы говорили о хранилищах ключей. В этой статье мы рассмотрим, как используется главный ключ (master key), а также обсудим достоинства и недостатки шифрования методом конвертов (envelope encryption). 

Когда-нибудь в далёком будущем автоматическое удаление ненужных данных будет одной из важных задач СУБД [1]. Пока же нам самим нужно заботиться об удалении или перемещении ненужных данных на менее дорогие системы хранения. Допустим, вы решили удалить несколько миллионов строк. Довольно простая задача, особенно если известно условие и есть подходящий индекс. "DELETE FROM table1 WHERE col1 = :value" — что может быть проще, да?

Доклад посвящен практическим вопросам разработки оператора в Kubernetes, проектированию его архитектуры и основных принципов функционирования.

В первой части доклада рассмотрим:

• что такое оператор в Kubernetes и зачем он нужен;
• как именно оператор упрощает управление сложными системами;
• что оператор может, а что оператор не может.

Далее, перейдём к обсуждению внутреннего устройства оператора. Рассмотрим архитектуру и функционирование оператора по шагам. Подробно разберём:

• взаимодействие между оператором и Kubernetes;
• какие функции оператор берет на себя, а что делегирует в Kubernetes.

Рассмотрим управление шардами и репликами БД в Kubernetes.
Далее, обсудим вопросы хранения данных:

• как работать с Persistent Storage с точки зрения оператора;
• подводные камни использования Local Storage.

В заключительной части доклада рассмотрим практические примеры применения clickhouse-operator с Amazon или Google Cloud Service. Доклад строится на примере разработки и опыта эксплуатации оператора для ClickHouse.

Привет, Хабр! Приглашаем на бесплатный Demo-урок «Параллельный кластер CockroachDB», который пройдёт в рамках курса «PostgreSQL». Также публикуем перевод статьи Тома Брауна — Principal Systems Engineer at EnterpriseDB.

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

Будет рассмотрен вклад Яндекса в следующие базы данных.

• ClickHouse
• Odyssey
• Восстановление на точку во времени (WAL-G)
• PostgreSQL (включая logerrors, Amcheck, heapcheck)
• Greenplum

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

В докладе Андрей Бородин расскажет, как они учли опыт масштабирования PgBouncer при проектировании пулера соединений Odyssey, как выкатывали его в production. Кроме того, обсудим какие функции пулера хотелось бы видеть в новых версиях: нам важно не только закрывать свои потребности, но развивать сообщество пользователей Одиссея.