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

Для меня написанное ниже является именно такой отправной точкой. Путь будет не близкий…

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

Затем мы рассмотрели разные виды очистки: внутристраничную (вместе с HOT-обновлениями), обычную и автоматическую.

И добрались до последней темы этого цикла. Сегодня мы поговорим о проблеме переполнения счетчика транзакций (transaction id wraparound) и заморозке.

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

Предыстория

Чтобы было понятно о чём речь, я расскажу совсем немного о VWO. Это платформа, с помощью которой можно запускать разные таргетированные кампании на своих сайтах: проводить A/B эксперименты, отслеживать посетителей и конверсии, делать анализ воронки продаж, отображать тепловые карты и проигрывать записи визитов.

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

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

Показать все клики на странице "abc.com"
ОТ <даты d1> ДО <даты d2>
для людей, которые
использовали Chrome ИЛИ
(находились в Европе И использовали iPhone)

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

Медленный запрос

Клиент, о котором идет речь, пытался сделать что-то, что интуитивно должно работать быстро:

Покажи все записи сессий
для пользователей посетивших любую страницу
с урлом, где есть "/jobs"

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

Продолжаем голосовать за интересные доклады в секции «Хранилища данных (Storage)» на DevConfX, которая пройдет уже через неделю. Обратите внимание на доклад о сертификации специалистов PostgreSQL, оставайтесь всегда в курсе последних событий в мире баз данных.

Заявки на секцию Storage

• Предвкушая двенадцатый PostgreSQL (Иван Панченко)
• NoSQL + SQL = MySQL 8 Document Store! (Витторио Чиоэ)
• Tarantool 2.1. Добавляем SQL в noSQL СУБД (Кирилл Юхин)
• Хранилища данных на службе BI (Exasol и Hadoop) (Александр Крашенинников и Алексей Еремихин)
  
• ProxySQL 2.0 или ЗОЖ с MySQL (Владимир Федорков)
• Сертификация PostgreSQL. Вопросы и ответы (Павел Лузанов)
• Базы данных в IT индустрии сейчас и 10 лет назад (Владимир Федорков)

Успей зарегистрироваться до 15 июня на юбилейной DevConfX!

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

Затем мы рассмотрели внутристраничную очистку (и HOT-обновления), обычную очистку, ну а сегодня посмотрим на автоматическую очистку.

Автоочистка (autovacuum)

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

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

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

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

Автоматическая очистка — как раз тот самый механизм, который позволяет запускать очистку в зависимости от активности изменений в таблицах.

Эта статья про Oracle Database, PL/SQL, SQL, MATCH_RECOGNIZE, MODEL clause, aggregate и pipelined functions.

В качестве функциональной области использован Технический анализ (ТА) рынков. Сначала небольшая поверхностная вводная о торговле на рынках, потом — расчёты.

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


Разработано много SQL-операторов, процедур и графиков. Часть — ниже, полностью код — на GitHub по ссылке внизу статьи.

Многие из вас читали предыдущую статью про то, как неправильная визуализация для объяснения работы JOIN-ов в некоторых случаях может запутать. Круги Венна не могут полноценно проиллюстрировать некоторые моменты, например, если значения в таблице повторяются.

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

Все желающие приглашаются под кат

ETL-компонента хранилища данных часто оказывается в тени самого хранилища и ей уделяется меньше внимания, чем главной базе данных или фронт-компоненте, BI, формировании отчётов. При этом с точки зрения механики наполнения хранилища данными, ETL играет ключевую роль и требует не меньше внимания администраторов, чем остальные компоненты. Меня зовут Александр, сейчас я администрирую ETL в Ростелекоме, и в данной статье я постараюсь немного поделиться тем, с чем приходится сталкиваться администратору одной известнейшей ETL-системы в крупном хранилище данных компании Ростелеком.

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

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

Обычная очистка (vacuum)

Что делает очистка

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

Основная, «обычная» очистка выполняется командой VACUUM и ее мы будем называть просто очисткой (а про автоочистку мы будем говорить отдельно).

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

Обработка происходит параллельно с другой активностью в системе. Таблица и индексы при этом могут использоваться обычным образом и для чтения, и для изменения (однако одновременное выполнение таких команд, как CREATE INDEX, ALTER TABLE и некоторых других будет невозможно).

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

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

В мире Postgres индексы крайне важны для эффективной навигации по хранилищу базы данных (его называют «куча», heap). Postgres не поддерживает для него кластеризацию, и архитектура MVCC приводит к тому, что у вас накапливается много версий одного и того же кортежа. Поэтому очень важно уметь создавать и сопровождать эффективные индексы для поддержки приложений.

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

Примечание: показанные ниже запросы работают на не модифицированном образце базы данных pagila.

И снова здравствуйте! Уже в следующий вторник стартует новый поток по курсу «Реляционные СУБД», поэтому мы продолжаем публиковать полезный материал по теме. Поехали.



На прошлой неделе я писал о конкурентном доступе в Postgres, какие команды блокируют друг друга, и как вы можете диагностировать заблокированные команды. Конечно, после постановки диагноза вам может потребоваться и лечение. С Postgres можно выстрелить себе в ногу, но Postgres также предлагает вам способы не сбить наводку. Вот некоторые из важных советов о том, как стоит и как не стоит делать, которые мы сочли полезными при работе с пользователями по переходу с их единой базы данных Postgres на Citus или при создании новых приложений аналитики в реальном времени.

Здравствуйте, в эфире снова Радио SQL! Разминайте ганглии, расправляйте псевдоподии (или наоборот?) и настраивайтесь на нашу гравитационную волну!

Если хотите знать, откуда дует ветер, отправляйтесь в самое сердце урагана.

Приблизительно такое ощущение сложилось от посещения конференции Google Cloud Next ’19, где три дня разработчики, продакт-менеджеры, специалисты по данным и другие светлые умы делились самыми горячими новостями в сфере разработки приложений и архитектуры, безопасности, управления расходами, анализа данных, гибридных облачных технологий, ML и АІ, внесерверной обработки данных и пр… 30 000 человек, потоки по индустриям и техническим направлениям, почти безостановочные лекции. Вот это ажиотаж!

Расскажу вам, какие важные новости о Google Cloud в 2019-2020 гг. и его 122 обновлениях нельзя упустить, на основе заметок Влада Флакса, CEO компании OWOX, который побывал на конференци.

Отличной всем пятницы! Все меньше времени остается до запуска курса «Реляционные СУБД», поэтому сегодня делимся переводом еще одного полезного материала по теме.



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

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

Своим заказчикам мы обычно предлагаем достаточно мощный и гибкий инструмент BI, способный решить все их задачи, однако это — зарубежный коммерческий продукт, а клиентов всё чаще интересует тема импортозамещения. В рамках изучения наших перспектив в этом плане мы начали тестирование собственного инструментария BI, используя open-source решения и платформу разработки, построенную на квинтетах.

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

Эпиграф:
«Когда у тебя в руках молоток, всё вокруг кажется гвоздями».

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

— А не загрузить ли тебе ФИАС, друг ситный! – сказало начальство. – Ибо процесс его загрузки что-то не нравится нашим бизнес-подразделениям. Долго, говорят грузится, грузит продуктовый сервер, да и чувак, который писал процесс загрузки, намедни уволился, года как три уже.
К тому же, все там давно нужно переделать, так что ты возьми, создай себе базу и обеспечь периодическую заливку ФИАСА. Всё, как говорится, не задерживаю!

Тут надо сказать, что к программированию я имею отдаленное отношение, т.к. являюсь, скорее, DBA. Хотя, с другой то стороны, загрузка больших массивов предварительно отпрепарированной информации – как раз задача DBA, nest pa?

— Да ладно… Щас сделаем – сказал я начальству, и ринулся на сайт ФИАСА, засучив рукава.

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

Сегодня займемся двумя довольно тесно связанными вопросами: внутристраничной очисткой и HOT-обновлениями. Оба механизма можно отнести к разряду оптимизаций; они важны, но в пользовательской документации практически не освещены.

Внутристраничная очистка при обычных обновлениях

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

1. Ранее выполненное на этой странице обновление (UPDATE) не обнаружило достаточно места, чтобы разместить новую версию строки на той же странице. Такая ситуация запоминается в заголовке страницы, и в следующий раз страница очищается.
2. Страница заполнена больше, чем на fillfactor. При этом очистка происходит сразу, не откладывая на следующий раз.

Приглашаем на открытый митап BD&DWH, который пройдет 21 мая 2019 года на площадке Райффайзенбанка в Нагатино!

Ребята расскажут про опыт разработки хранилища данных на MS SQL Server и паттерны проектирования моделей данных в хранилище. А еще к нам прихал Joel R. Kallman из Oracle и будет говорить про APEX.

Здравствуйте, друзья. Перед уходом на вторую часть майских праздников делимся с вами материалом, который мы перевели в преддверии запуска нового потока по курсу «Реляционные СУБД».



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

Взгляните на код PHP:

$user->v_useragent = 'coresky.agent';

Такой код может спровоцировать SQL запрос UPDATE или INSERT, а может и не спровоцировать, если идентичные данные уже установлены в БД, собственно поэтому этот функционал именуется «Призрачные SQL запросы». Похожий функционал, обычно присутствует в большинстве CRM, но давайте рассмотрим, как он может быть реализован без CRM. Призрачные запросы, имеют потенциал довольно широко применяться в веб-приложениях, особенно в части конфигураций. Типичный (но не обязательно) алгоритм проходит в три этапа: чтение данных из БД, изменение данных, возможно многократное, и формирований реальных SQL запросов для обновления данных в БД. Давайте разберемся в деталях…