SQL *

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

Сегодня разберем пару примеров, как неудачная организация БД и кода могут превратить наше приложение в клубок проблем:

• накрутка serial при ON CONFLICT
• накрутка счетчика транзакций

Сводная таблица – один из самых базовых видов аналитики. Многие считают, что создать её средствами SQL невозможно. Конечно же, это не так.

Всем привет! В преддверии старта курса «MS SQL Server разработчик», подготовили для вас еще один интересный перевод.

---

Если оптимизатор неправильно вычисляет необходимый объем памяти для выполнения запроса, то это будет либо пустая трата памяти, которую мог бы использовать другой процесс, либо будет слив данных на диск (disk spill). Для решения этой проблемы Microsoft добавила обратную связь по грантам памяти (Memory Grant Feedback). В этой статье Грег Ларсен (Greg Larsen) объясняет, как это работает.

Обратная связь по грантам памяти (Memory Grant Feedback) в более ранних версиях SQL Server (до SQL Server 2019 или 15.x) была реализована только для запросов, выполняющихся в пакетном режиме (batch mode). Запросы в пакетном режиме выполняют сканирование и вычисление до 900 строк одновременно, в отличие от запросов в строковом режиме (row mode), когда за раз обрабатывается только одна строка. В версии 15.x обратная связь по грантам памяти была расширена для поддержки запросов в строковом режиме.

Что такое обратная связь по грантам памяти? Это процесс корректировки вычисления памяти, необходимой для запроса с учетом того, сколько памяти было использовано при его предыдущих выполнениях. Это означает, что если кэшированный запрос использовал слишком много памяти при последнем выполнении, то SQL Server уменьшит выделение памяти при его следующем выполнении. Или если SQL Server обнаружил запрос, использующий диск из-за того, что в последний раз ему было выделено недостаточно памяти, то он увеличит память для запроса. Целью обратной связи по грантам памяти является корректировка требований к памяти при каждом выполнении запроса до тех пор, пока запрос не будет использовать объем памяти, соответствующий количеству обрабатываемых строк.

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

Типизация данных в PostgreSQL, при всей своей логичности, действительно преподносит порой очень странные сюрпризы. В этой статье мы постараемся прояснить некоторые их причуды, разобраться в причине их странного поведения и понять, как не столкнуться с проблемами в повседневной практике. Сказать по правде, я составил эту статью в том числе и в качестве некоего справочника для самого себя, справочника, к которому можно было бы легко обратиться в спорных случаях. Поэтому он будет пополняться по мере обнаружения новых сюрпризов от подозрительных типов. Итак, в путь, о неутомимые следопыты баз данных!

Небольшая заметка по формированию XML

FOR XML PATH

Для формирования структуры XML-документа со списком значений можно воспользоваться режимом PATH для FOR XML в T-SQL.

<root>
    <level1>
        <level2></level2>
        <values>
            <value></value>
            <value></value> 
            <value></value>
            <value></value>
            <value></value>
        </values>
     </level1>
     <level1>
         <level2></level2>
         <values>
             <value></value>
             <value></value>
             <value></value>
             <value></value>
             <value></value>
         </values>
     </level1>
</root>

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

Здравствуйте, меня зовут Виктор и я разработчик в компании Gems Development. Я хочу рассказать, как мы реализовывали создание и заполнение производственного календаря в Postgresql.

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

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

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

А чтобы эти итоги собрать, необходимо по исходным данным вычислить значение некоторой агрегатной функции: количество, сумма, среднее, минимум, максимум,… — и, как правило, не одной.


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

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

Managing PostgreSQL at Gitlab.com. Jose Cores Finotto.

Большое спасибо! Добро пожаловать на наш разговор о PostgreSQL в Gitlab. Мы поговорим только об основных моментах. И более подробно вы можете узнать на сайте Gitlab.com.

Уже давно известно, что делать бэкапы в SQL-дампы (используя pg_dump или pg_dumpall) – не самая хорошая идея. Для резервного копирования СУБД PostgreSQL лучше использовать команду pg_basebackup, которая делает бинарную копию WAL-журналов. Но когда вы начнёте изучать весь процесс создания копии и восстановления, то поймёте что нужно написать как минимум пару трёхколёсных велосипедов, чтобы всё это работало и не вызывало у вас боль как сверху, так и снизу. Дабы облегчить страдания был разработан WAL-G.

WAL-G – это инструмент, написанный на Go для резервного копирования и восстановления PostgreSQL баз данных (а с недавнего времени и MySQL/MariaDB, MongoDB и FoundationDB). Он поддерживает работу с хранилищами Amazon S3 (и аналогами, например, Yandex Object Storage), а также Google Cloud Storage, Azure Storage, Swift Object Storage и просто с файловой системой. Вся настройка сводится к простым шагам, но из-за того что статьи о нём разрозненны по интернету – нет полного how-to мануала, который бы включал все шаги от и до (на Хабре есть несколько постов, но многие моменты там упущены).

Перевод статьи подготовлен в преддверии старта курса «MS SQL Server разработчик».

---

Проблема

При настройке производительности SQL Server часто возникает вопрос, как ограничение внешних ключей (foreign key) влияет на производительность модификации данных. Все понимают, что внешние ключи необходимы для обеспечения ссылочной целостности, но может есть какой-то другой способ с лучшей производительностью?

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

Расшифровка доклада 2020 года Алексея Лесовского "PostgreSQL Scaling Usecases".

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

Однако классические РСУБД за счет накопленных фич нередко остаются выбором №1 при том что они также не стоят на месте и предоставляют богатый набор инструментов в плане масштабирования.

В этом докладе я буду рассматривать преимущественно PostgreSQL, варианты его масштабирования и то когда это стоит делать и как это делать правильно и как делать неправильно. В докладе будут рассмотрены следующие темы:

• Потоковая репликация и разделение read/write рабочей нагрузки
• Логическая репликация и шардирование данных
• Обеспечение высокой доступности и устойчивости к сбоям

Посвящается всем любителям анализировать логи.

В логах работающих систем рано или поздно появляются тексты каких-то ошибок. Чем таких систем больше в обозримом пространстве, тем больше вероятность ошибку увидеть. Серверы PostgreSQL, которые находятся под нашим мониторингом ежедневно генерируют от 300K до, в неудачный день, 12M записей об ошибках.

И такие ошибки — это не какой-то там «о, ужас!», а вполне нормальное поведение сложных алгоритмов с высокой степенью конкурентности вроде тех, о которых я рассказывал в статье про расчет себестоимости в СБИС — все эти deadlock, could not obtain lock on row in relation …, canceling statement due to lock timeout как следствие выставленных разработчиком statement/lock timeout.

Но есть ведь и другие виды ошибок — например, you don't own a lock of type ..., которая возникает при неправильном использовании рекомендательных блокировок и может очень быстро «закопать» ваш сервер, или, мало ли, кто-то периодически пытается «подобрать ключик» к нему, вызывая возникновение password authentication failed for user …

^{[источник КДПВ]}

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

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

Благодаря своей архитектуре, в In-Memory в разы, а иногда и на порядки, быстрее скорость доступа к данным. Например, аналитики банка хотят посмотреть в аналитическом приложении отчет по выданным кредитам в динамике по дням за прошлый год. Этот процесс на классической СУБД займет минуты, а c In-Memory появится почти сразу. Всё потому, что подход позволяет кэшировать гораздо больше информации и она хранится в оперативной памяти «под рукой». Приложению не нужно запрашивать данные у жесткого диска, доступность которых ограничена скоростью сети и диска.

Какие еще возможности доступны с In-Memory и что это за подход, расскажет Владимир Плигин — инженер компании GridGain. Этот обзорный материал будет полезен разработчикам бэкенда веб-приложений, которые не работали с In-Memory и хотят попробовать, или интересуются современными трендами разработки программных решений и проектированием архитектуры.

Примечание. Статья основана на расшифровке доклада Владимира на конференции #GetIT Conf. До введения самоизоляции мы регулярно проводили митапы и конференции для разработчиков в Москве и Санкт-Петербурге: обсуждали тренды, актуальные вопросы разработки, проблемы и их решения. Сейчас конференции не провести, зато самое время поделиться полезными материалами с прошлых.

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

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

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

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

Ссылки на предыдущие статьи цикла:

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

Расшифровка доклада 2015 года Алексея Лесовского "Deep dive into PostgreSQL internal statistics"

Disclaimer от автора доклада: Замечу что доклад этот датирован ноябрем 2015 года — прошло больше 4 лет и прошло много времени. Рассматриваемая в докладе версия 9.4 уже не поддерживается. За прошедшие 4 года вышло 5 новых релизов в которых появилась масса новшеств, улучшений и изменений относительно статистики и часть материала устарела и не актуальна. По мере ревью я постарался отметить эти места чтобы не вводить тебя читатель в заблуждения. Переписывать же эти места я не стал, их очень много и получится в итоге совсем другой доклад.

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

Полгода назад мы представили explain.tensor.ru — публичный сервис для разбора и визуализации планов запросов к PostgreSQL.



За прошедшие месяцы мы сделали про него доклад на PGConf.Russia 2020, подготовили обобщающую статью по ускорению SQL-запросов на основе рекомендаций, которые он выдает… но самое главное — собирали ваши отзывы и смотрели за реальными use case.

И теперь готовы рассказать о новых возможностях, которыми вы можете пользоваться.

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

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

Когда я начал изучать англоязычные материалы по теме создания витрин данных над DATA VAULT у меня возникло ощущение достаточной сложности процесса. Так как статьи имеют внушительный объем, там присутствуют отсылки к изменениям в формулировках, появившихся в методологии Data Vault 2.0, обозначается важность этих формулировок.

Однако, углубившись в перевод, стало понятно, что процесс этот не так уж и сложен. Но, возможно у вас сложится другое мнение.

И так, давайте переходить к сути.

Расшифровка доклада 2015 года Ильи Космодемьянского "Linux tuning to improve PostgreSQL performance"

Disclaimer: Замечу что доклад этот датирован ноябрем 2015 года — прошло больше 4 лет и прошло много времени. Рассматриваемая в докладе версия 9.4 уже не поддерживается. За прошедшие 4 года вышло 5 новых релизов PostgreSQL вышло и 15 версий ядра Linux. Если переписывать эти места, то получится в итоге другой доклад. Но здесь рассмотрен фундаментальный тюнинг Linux для PostgreSQL, который актуален и сейчас.