SQL

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

И в этой статье я сконцентрируюсь на развитии DATA VAULT и переходу к BUSINESS DATA VAULT или просто BUSINESS VAULT.

Причины появления BUSINESS DATA VAULT

Следует отметить, DATA VAULT имея определенные сильные стороны не лишен недостатков. Одним из таких недостатков является сложность в написании аналитических запросов. Запросы имеют значительное количество JOIN’ов, код получается длинным и громоздким. Также данные попадающие в DATA VAULT не подвергаются никаким преобразованиям, поэтому с точки зрения бизнеса DATA VAULT в чистом виде не имеет безусловной ценности.

Задача

На самом деле, задача, о которой хочется рассказать, проста до уныния по своей формулировке: нужно было визуализировать данные по продажам отдела e-commerce малой кровью, т.е., читай, практически даром.

Введение

«Нужно бежать со всех ног, чтобы только оставаться на месте,
а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!»
(с) Алиса в стране чудес

Некоторое время назад меня попросили прочитать лекцию аналитикам нашей компании на тему проектирования моделей данных, ведь сидя долгое время на проектах (порою по нескольку лет) мы упускаем из виду происходящее вокруг в мире ИТ-технологий. В нашей компании (уж так получилось) на многих проектах не используются NoSQL-базы данных (по крайней мере пока), поэтому в своей лекции я отдельно уделил им некоторое внимание на примере HBase и постарался ориентировать изложение материала на тех, кто с ними никогда не работал. В частности, я иллюстрировал некоторые особенности проектирования модели данных на примере, который несколько лет назад прочитал в статье «Introduction to HB ase Schema Design» by Amandeep Khurana. Разбирая примеры, я сравнивал между собой несколько вариантов решения одной и той же задачи, чтобы лучше донести до слушателей основные идеи.

Недавно, «от нечего делать», я задался вопросом (длинные майские выходные в режиме карантина к этому особенно располагают), насколько теоретические выкладки будут соответствовать практике? Собственно, так и родилась идея этой статьи. Разработчик, который не первый день работает с NoSQL, возможно и не почерпнет из нее что-то новое (и поэтому может сразу промотать полстатьи). Но для аналитиков, которые еще не работали плотно с NoSQL, полагаю, она будет полезна для получения базовых представлений об особенностях проектирования моделей данных для HBase.

И снова здравствуйте. В июне OTUS вновь запускает курс «MS SQL Server разработчик», традиционно в преддверии старта курса мы начинаем делиться с вами материалом по теме.

---

Если в вашем запросе отсутствует ORDER BY, то вы не можете быть уверены в том, что сортировка результатов не изменится со временем.

Конечно, поначалу все будет довольно предсказуемо, но по мере того, как происходят изменения (в индексах, таблицах, конфигурации сервера, объеме ваших данных), вы можете столкнуться с некоторыми неприятными сюрпризами.

Расшифровка доклада/tutorial "Управление высокодоступными PostgreSQL кластерами с помощью Patroni". А.Клюкин, А.Кукушкин

Patroni — это Python-приложение для создания высокодоступных PostgreSQL кластеров на основе потоковой репликации. Оно используется такими компаниями как Red Hat, IBM Compose, Zalando и многими другими. С его помощью можно преобразовать систему из ведущего и ведомых узлов (primary — replica) в высокодоступный кластер с поддержкой автоматического контролируемого (switchover) и аварийного (failover) переключения. Patroni позволяет легко добавлять новые реплики в существующий кластер, поддерживает динамическое изменение конфигурации PostgreSQL одновременно на всех узлах кластера и множество других возможностей, таких как синхронная репликация, настраиваемые действия при переключении узлов, REST API, возможность запуска пользовательских команд для создания реплики вместо pg_basebackup, взаимодействие с Kubernetes и т.д.

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

• область применения: какие задачи HA успешно решаются Patroni
• обзор архитектуры
• создание тестового кластера
• утилита patronictl
• изменение конфигурации PostgreSQL для кластера, управляемого Patroni
• мониторинг с помощью API
• подходы к переключению клиентов
• дополнительные возможности: ручное переключение, перезагрузка по расписанию, режим паузы
• настройка синхронной репликации
• расширяемость и универсальность
• частые ошибки и их диагностика

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

Растут wait — приложение в кого-то «уперлось» на блокировках. Если это уже прошедшая разовая аномалия — повод разобраться в исходной причине.

Такая ситуация — одна из самых неприятных для DBA:

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

Шансов поймать блокировки «в моменте» крайне мало, да и длиться они могут всего по несколько секунд, но ухудшая при этом плановое время выполнения запроса в десятки раз. А хочется-то не сидеть и ловить происходящее в онлайн-режиме, а в спокойной обстановке разобраться постфактум, кого из разработчиков покарать в чем именно была проблема — кто, с кем и из-за какого ресурса базы вступил в конфликт.

Но как? Ведь, в отличие от запроса с его планом, который позволяет детально понять, на что пошли ресурсы, и сколько времени это заняло, подобных наглядных следов блокировка не оставляет после себя…

Разве что короткую запись в логе:

process ... still waiting for ...

А давайте попробуем зацепиться именно за нее!

Так как нас не устраивала скорость и надежность исходной имплементации на Ruby, в последние несколько лет мы постепенно выводили критический функционал из нашего Rails-монолита GitHub.com и переписывали часть кода на Go. Например, на Github Satellite в прошлом году мы анонсировали — и имплементировали — возможность «более контролируемой авторизации» с использованием сервиса authzd.

Работа с authzd оказалась очень интересной и значимой для нас задачей, поскольку это был наш первый сервис на Go для работы с чтением данных из баз MySQL на продакшне в ходе веб-реквеста. У нас имелся опыт развертывания других работающих с базами MySQL-сервисов на Go, но при этом они были либо службами внутреннего контроля (наша кластерная поисковая система manticore), либо асинхронными пакетными заданиями (оркестратор резервного копирования Git gitbackups). Требования к производительности и надежности authzd отличаются от них повышенной строгостью, поскольку обычный реквест к Rails-монолиту вызывает этот сервис неоднократно.

Кроме того, проблемы с большими задержками при открытии TCP соединений на наших Kubernetes кластерах особенно влияли на пул соединений Go MySQL драйвера. Это добавляло работы, ведь именно на Kubernetes мы и развернули authzd. Одним из самых опасных самообманов программиста в этом отношении является вера в надежность сети, поскольку да, в большинстве случаев сеть действительно надежна… но как только она начинает тормозить или барахлить, нас настигают базовые проблемы таких же базовых библиотек, и все начинает рушиться.

Так чего нам в итоге стоила подготовка authzd к обработке всего нашего рабочего трафика через SQL, да еще и в соответствии с нашими целями доступности?

В преддверии старта курса «PostgreSQL» подготовили перевод интересной статьи.

---

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

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

Публикую на Хабр оригинал статьи, перевод которой размещен в блоге Codingsight.

Что будет в этой статье?

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

Для ленивых основные тезисы первой статьи:

• Мы делаем линейку IDE для СУБД MySQL, SQL Server, Oracle, PostgreSQL
• Это настольное приложение на .NET стеке со всеми вытекающими
• Много функций завязаны на анализ SQL кода. Используем для этого сильно доработанный ANTLR

По мере публикации буду добавлять ссылки на следующие части:

Часть 1. Сложности парсинга. Истории о доработке ANTLR напильником
Часть 2. Оптимизация работы со строками и открытия файлов
Часть 3. Жизнь расширений для Visual Studio. Работа с IO. Необычное использование SQL
Часть 4. Работа с исключениями, влияние данных на процесс разработки. Использование ML.NET

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

Обратился ко мне клиент, которому я полгода назад делала загрузку данных из Excel в список продукции Заявки от клиента. Видео по результату.

Geometry of Flowers by Mookiezoolook

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

Но как оценить, какая схема лучше? И что вообще значит «лучше», когда мы говорим об архитектуре БД? Команда Mail.ru Cloud Solutions предлагает познакомиться с рекомендациями Майка Алча, консультанта по разработке программного обеспечения. Нам кажется, что он довольно лаконично резюмировал некоторые принципы грамотной архитектуры.

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

Можно найти интересные статьи о применении DATA VAULT в компаниях, однако основы и методология освещены недостаточно.

В англоязычном сегменте, дела обстоят значительно лучше. Можно купить книги авторов-изобретателей методологии DATA VAULT, но есть и статьи в открытом доступе, которые уделяют внимание именно основам.

Будучи вдохновленным одной из таких статей, я попытаюсь передать базовые вещи методологии DATA VAULT на русском языке.

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

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

Часто существуют обоснованные стратегические причины брать на себя технический долг. Не вся задолженность является безнадежной, но вся задолженность нуждается в обслуживании. Технический долг может быть выплачен путем рефакторинга кода, улучшения тестирования, удаления мертвого кода, уменьшения зависимостей, ужесточения API и улучшения документации. Цель не в том, чтобы добавить новую функциональность, а в том, чтобы сделать возможным будущие улучшения, уменьшить количество ошибок и улучшить ремонтопригодность. Отсрочка таких платежей приводит к сложным расходам. Скрытый долг опасен, так как он бесшумно увеличивается.

Перевод статьи подготовлен в преддверии старта курса «PostgreSQL».

---

Введение

В этой статье я познакомлю вас с GCP SQL и покажу как создать в этом сервисе сервер PostgreSQL.

Публикую на Хабр оригинал статьи, перевод которой размещен в блоге Codingsight.

Что будет в этой статье?

Более пяти лет работаю в компании, что занимается разработкой линейки IDE для работы с базами данных. Начиная работу над этой статьей я и не представлял как много интересных историй получится вспомнить, потому когда закончил получил более 30 страниц текста. Немного подумав, я сгруппировал истории по тематике, а статью разбил на несколько.

По мере публикации буду добавлять ссылки на следующие части:

Часть 1. Сложности парсинга. Истории о доработке ANTLR напильником
Часть 2. Оптимизация работы со строками и открытия файлов
Часть 3. Жизнь расширений для Visual Studio. Работа с IO. Необычное использование SQL
Часть 4. Работа с исключениями, влияние данных на процесс разработки. Использование ML.NET

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

В этой части я сосредоточусь на проблемах парсинга SQL, борьбе с этими проблемами и ошибками допущенными в этой борьбе.

В сложных ERP-системах многие сущности имеют иерархическую природу, когда однородные объекты выстраиваются в дерево отношений «предок — потомок» — это и организационная структура предприятия (все эти филиалы, отделы и рабочие группы), и каталог товаров, и участки работ, и география точек продаж,…



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

Существует много способов хранения такого дерева в СУБД, но мы сегодня остановимся только на одном варианте:

CREATE TABLE hier(
  id
    integer
      PRIMARY KEY
, pid
    integer
      REFERENCES hier
, data
    json
);

CREATE INDEX ON hier(pid); -- не забываем, что FK не подразумевает автосоздание индекса, в отличие от PK

И пока вы всматриваетесь в глубину иерархии, она терпеливо ждет, насколько же [не]эффективными окажутся ваши «наивные» способы работы с такой структурой.


Давайте разберем типовые возникающие задачи, их реализацию на SQL и попробуем улучшить их производительность.

Сделал dashboard Postgresql overview для postgres_exporter.

Чем отличается от других дашбородов postgres_exporter?

Я объединил все другие дашборды postgres_exporter в один.

Этот дашборд показывает общую информацию по кластеру.

Скриншоты и краткая инструкция по установке: postgresql, postgres_exporter, prometheus, grafana под катом.

Расшифровка доклада 2018 года Алексея Лесовского "Давайте отключим vacuum?!"

Примечание редактора: Любые рекомендации по изменению параметров всегда стоит сравнивать в других докладах

Такой призыв часто возникает, когда в PostgreSQL возникают проблемы, и главным подозреваемым оказывается vacuum (далее по тексту просто "вакуум"). По опыту, многие наступают на эти грабли, и мне с коллегам по Data Egret нередко приходится разгребать последствия, так как потом всё становится ещё хуже. Но если обратить внимание на сам вакуум, то, пожалуй, нет такого человека, который бы использовал Postgres, и при этом ничего не знал про него. Ведь история вакуума начинается относительно давно, и в интернете можно найти массу как старых, так и новых постов про вакуум, объемные дискуссии в списках рассылки. Несмотря на то, что тема вакуума подробно описана в официальной документации к PostgreSQL, новые посты и новые дискуссии будут появляться и дальше. Возможно, поэтому с вакуумом связано очень много мифов, баек, страшилок и заблуждений. Между тем, вакуум является одним из важнейших компонентов PostgreSQL, и его работа напрямую сказывается на производительности. В одном докладе невозможно рассказать про вакуум абсолютно всё, но я бы хотел раскрыть ключевые моменты, связанные с вакуумом, такие как его внутреннее устройство, основные подходы к его настройке, наблюдение за производительностью, мониторинг, и что делать в случае, когда вакуум — главный подозреваемый во всех бедах. Ну и, конечно же, хочется развеять распространенные мифы и заблуждения, связанные с вакуумом.

На каких принципах строится идеальное Хранилище Данных?

Фокус на бизнес-ценности и аналитике при отсутствии boilerplate code. Управление DWH как кодовой базой: версионирование, ревью, автоматическое тестирование и CI. Модульность, расширяемость, открытый исходный код и сообщество. Дружественная пользовательская документация и визуализация зависимостей (Data Lineage).

Обо всём этом подробнее и о роли DBT в экосистеме Big Data & Analytics — добро пожаловать под кат.

Предлагаю ознакомиться с расшифровкой доклада начала 2016 года Андрея Сальникова "Типовые ошибки в приложениях, которые ведут к bloat в postgresql"

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