После месяцев рутинного сканирования строк в структуры я решил: «Хватит это терпеть!» и психанув, создал обертку, которая:
✔ Автоматизирует скан — никаких rows.Scan(), просто передаете структуру
✔ Работает с любыми вложенностями — даже сложные JSON-поля парсятся без боли
✔ Не тормозит — минимальные накладные расходы, вся мощь pgx сохраняется
✔ Подходит для любого проекта — можно внедрять постепенно
👉 Это не просто библиотека — это мой ответ на боль всех gopher'ов!
При переезде 1С с Windows-платформ пользователи сталкиваются с тем, что привычный подход "одна база - один пользователь" реализовать как-то не очень получается. В мануалах, которые можно нагуглить, предлагается либо соединяться с СУБД от имени пользователя postgres, либо создать нового пользователя и выдать ему права SUPERUSER, что с точки зрения изоляции баз друг от друга выглядит как-то "не очень".
Для чего используют кластеризацию серверов СУБД? Вопрос не совсем праздный, особенно для крупных компаний. Если с кластеризацией/масштабированием серверов приложений, терминалов, web-серверов и т. д. все понятно и прозрачно, то вот с СУБД не всё так просто. Особенно для 1С систем.
Привет, Хабр!
Всем хорош Data Vault, однако схватиться с ним «врукопашную», используя только SQL, захочет не каждый. Останавливает большой объем ручных операций, а также большой объем деталей реализации. Большое количество join, за которые критикуют Data Vault, не является определяющим моментом, так как уже сейчас базы данных способны их эффективно обрабатывать, а с течением времени мощность серверов только возрастает.
Но творческая мысль не дремлет, постепенно появляются инструменты для автоматизации построения Data Vault. Например, это пакет AutomateDV для dbt, графическая надстройка над ним Datapulse, построение модели DV в BI.Qube.
Data Vault меня заинтересовал — уж много плюшек он сулит, и для его изучения я занимаюсь проектом asapBI — low‑code IDE для моделирования DWH. Требования к создаваемой системе я описал на сайте asapbi.ru. Их достаточно много, поэтому не буду их тут перечислять.
Сегодня я хотел поделиться графическим интерфейсом для создания хабов, линков и стеллитов.
Привет, Хабр. Меня зовут Роман Ескин, я один из C разработчиков проекта Greengage DB. В этой статье я расскажу, как мы реализовали и протестировали lock-free подход в рамках масштабной работы по внедрению функции удаления брошенных файлов. Приглашаю вас заглянуть во внутреннюю кухню работы нашей команды при оценке этой функциональности.
Введение
Позвольте начать с краткой исторической справки: Greengage DB был запущен в 2024 году как open-source форк Greenplum — Massively Parallel Processing (MPP) аналитической системы управления базами данных, основанной на PostgreSQL. Мы начали этот проект, чтобы поддержать open-source сообщество Greenplum, который неожиданно стал проприетарным продуктом в мае 2024 года. Мы гарантируем дальнейшее развитие Greengage DB, следуя принципам открытости и прозрачности.
Так как Greengage DB основан на PostgreSQL, он унаследовал некоторые его известные особенности и проблемы. Одна из таких проблем, особенно актуальная в распределенных средах — это проблема "брошенных файлов" (orphaned files).
Эта проблема возникает, когда таблица создается и данные загружаются в рамках активной транзакции. Если происходит критический сбой до того, как транзакция будет закоммичена или отменена (например, внезапное отключение питания или неожиданное завершение работы узла базы данных), система проходит процесс восстановления после падения (crash recovery). При этом логическая таблица откатится, но физические файлы данных, связанные с этой незакоммиченной таблицей, могут остаться в файловой системе. Со временем такие брошенные файлы могут накапливаться, занимая место и приводя к ненужному расходу ресурсов. В настоящее время их удаление происходит вручную.
Недавно мы представили новый функционал, который позволяет автоматически удалять такие брошенные файлы. Полная информация об этой возможности доступна в статье Удаление брошенных файлов в Greengage DB.
Быки, коровы и квайны
Об олимпиаде незапамятных времён спонсорства Oracle рассказывал ещё bzq aka Евгений Бредня, возглавляющий сейчас техподдержку Postgres Professional, а тогда (2016–2017) он ещё готовил вопросы как сотрудник AT Consulting. Вот части I и II. У Евгения на хабре интересные статьи — и о причудливых задачках, и о техподдержке. Так писали мы в Postgresso № 6 (55). Там же рассказали и уже об актуальных на том момент (2023) задачах 2-го и 3-го этапов, которые готовил Егор Рогов, руководитель программ отдела образования Postgres Professional (задачи для первого готовил не он, а Евгений Моргунов, автор PostgreSQL. Основы языка SQL).
В прошлом году, как известно в том числе из Postgresso #5 (66), организаторы даже выложили огромное видео, в котором был доклад Егора Рогова — в качестве важных материалов, сопутствующих олимпиаде: XV Международная олимпиада в сфере информационных технологий «IT‑Планета 2024». 1-й этап — заочный теоретический тест по PostgreSQL, из почти 3000 человек отобрали примерно 200. Вопросы для этого этапа были подготовлены Евгением Давыдовым. 2-й этап — также заочный. Здесь участникам было предложено подумать над пятью задачами Егора Рогова. Их он и разбирает в этой статье. А финал (3-й этап) Олимпиады проходил очно в Архангельске.
Но это присказки.
При создании временных таблиц в PostgreSQL изменяются до 13 таблиц системного каталога, при этом особенно сильно разрастаются pg_attribute, pg_class, pg_depend и pg_type. Массовое создание и усечение временных таблиц активно применяется, в том числе в 1C:ERP. В статье рассматриваются особенности работы с временными таблицами и описано решение проблемы раздувания таблиц системного каталога, реализованное в СУБД Tantor Postgres.
Эта статья, скорее для ознакомления и хотелось бы получить советы по данной работе.
Итак, Excel-файл весит 500+ мегабайт, состоит из сотен тысяч строк, десятков листов и формул, которые «протягиваются» по 30+ столбцам — это не работа, а страдание. Именно с таким «монстром» я столкнулся, когда в компании собрались данные из разных отделов в один файл.
Вкратце структура файла — Лист «Массив» (Data_Lake — в левой части 34 столбца с которым работают специалисты и на котором отрабатывают основные формулы и правая часть с 46 столбцами, куда подтягиваются сырые данные, с которыми будет производиться обработка). И множеством листов со справочниками, правками.
Открытие этого Excel‑файла занимает 10 минут, а если обновить хотя бы часть формул — можно идти пить чай. Работать с такими данным и просто невозможно, особенно если тебе нужно анализировать их, строить отчёты или готовить выгрузки. Поэтому решил попробовать все перевести на PostgreSQL.
Для этого всего лишь требовалось переписать формулы с Excel на SQL. Хорошо, что большинство формул это условия ЕСЛИ, ИЛИ.
Вот самая простая формула:
Привет, Хабр! Это Антон Дятлов, инженер по защите информации в Selectel. В современных базах данных JSON — де-факто стандарт для хранения полуструктурированных сведений. PostgreSQL предлагает два специализированных типа для работы с ним: json и jsonb. Первый хранит точную текстовую копию документа со всеми пробелами и порядком ключей. Второй применяет оптимизированный бинарный формат.
Рассказываем про jsquery — расширение, которое предоставляет полноценный язык для формулирования выборок. Появляется возможность писать декларативные, понятные и очень быстрые инструкции для работы с jsonb-полями.
Привет, Хабр!
Сегодня мы рассмотрим, как заставить PostgreSQL самостоятельно крутить K-Means для сегментации клиентов, не вытаскивая данные наружу. Пройдемся по циклу: нормализуем фичи в materialized view, напишем функцию PL/PythonU, которая дергает scikit-learn, сохраняем cluster_id обратно в таблицу и закрываем гештальт отчётом «доход по кластеру» чистым SQL.
Привет, Хабр! Я, Мадаров Артур, руководитель дирекции процессов эксплуатации и ИТ-услуг Страхового Дома ВСК.
В своей прошлой статье, «Реинжиниринг процессов контроля качества технической поддержки», я рассказывал, с чего началась наша трансформация: как мы перешли от разрозненной отчётности в Excel к системной BI-аналитике, как формировали культуру data-driven внутри ИТ-блока ВСК и зачем всё это нужно.
На пятой встрече ProcessTech и Страхового Дома ВСК я рассказал, что было дальше: как мы из BI-дашбордов перешли к процессной аналитике, внедрили инструменты Process Mining, Task Mining и построили центр компетенций по процессной аналитике в ИТ.
Эта статья — почти практический гайд по внедрению процессной аналитики в крупной компании. Без обобщений. Только конкретика, цифры, архитектура решений и кейсы. Рассчитываю, что статья будет полезна как для ИТ-специалистов, так и для руководителей, которые хотят перестать управлять на основе ощущения, а не данных.
Почему мы продолжили путь: от BI к Process Mining
Всего за 5 месяцев после закупки лицензий в ИТ-блоке уже 9 внутри командных review и рабочих групп с бизнесом проводятся с демонстрацией BI-аналитики Proceset (без Power Point и Excel). На первом этапе трансформации мы выстроили мощный слой BI. Благодаря интерактивным дашбордам:
Миграция с устаревающих СУБД — частая задача в ИТ. При переходе с Firebird 2.5 на PostgreSQL одной из первых становится необходимость переноса структуры базы данных. Ручной перенос сложных схем с множеством таблиц, индексов, процедур и функций — трудоёмкий и ошибко подверженный процесс. В этой статье я хочу поделиться инструментом, который берёт на себя большую часть рутинной работы.
Уже давно стали обыденными внедрения решений на платформе 1С:Предприятие на тысячу одновременных пользователей. Есть внедрения и более масштабные. И масштаб внедрений растёт. Поэтому мы решили убедиться, что платформа выдержит нагрузку нашего самого востребованного на крупных внедрениях решения 1C:ERP на 30 000 одновременно работающих пользователях.
Почему именно 30 000 пользователей, как мы измеряли производительность и как добились желаемой производительности — под катом.
На статью данный текст точно не тянет, скорее это маленькая заметка. Как известно свои дети и свои идеи они всегда самые лучшие. Я давно работаю с реляционными базами и очень люблю язык SQL за его формализм, скорее всего из-за этой моей профдеформации и родилась эта мысль. На работе ко мне иногда обращались сделать выгрузку в CSV файл из базы для обучения моделей или анализа данных, и я подумал, а зачем выгружать данные, а потом иногда загружать обратно результат в базу. Почему не сделать так что бы результат запроса сразу отправлялся на обработку в AI и затем выдавался ответ на запрос. Нам всего лишь нужна SQL функция которая берет результат запроса, заворочает его в вызов к модели, а потом выдает результат. Понятно, что серебряной пули нет и данный подход не везде будет работать, например, такой подход не подразумевает асинхронность, а значит если нужна высокая производительность, то данный подход не очень подходит, с другой стороны сейчас запросы к AI не дёшевы и если вы пошлете 100 запросов в секунду, не дождавшись ответа на предыдущие то скорее всего получите ошибку. Я думаю в будущем это будет стандартная функции в базах данных.
Теперь рассмотрим простейшую реализацию данной функции. Под рукой был PostgreSQL, но можно реализовать это и для ORACLEили других баз. Для этого нам понадобится расширение. В качестве AI будем использовать Groq. Первое что нам надо это получить API ключ. Сама функция очень простая.
Помните, как в Корпорации Монстров страшилы добывали энергию из криков детей? Они готовились, чтобы быть пострашнее и собирать побольше энергии: репетировали жуткие звуки, подбирали реквизит, узнавали страхи ребёнка. В общем, настраивали параметры запугивания :) В мире баз данных у параметров конфигурации аналогичная роль: чем точнее настройка, тем выше производительность системы. Однако не все параметры везде работают с одинаковым эффектом (как не все монстры одинаково страшны для всех детей): какой-нибудь параметр идеален для одного профиля нагрузки, но не даёт того же результата для другого.
Администраторы БД часто ломают голову, как подобрать оптимальные настройки под задачи СУБД. И чтобы помочь им разобраться, мы обратились к опыту Майка Вазовски — тренера легендарного монстра Салли. Вдохновились секретами его тренировок и разработали утилиту Pangolin Tuner — аналог Вазовски для настройки параметров конфигурации.
Я Кристина Демидович, DevOps-инженер в СберТехе, занимаюсь автоматизацией в команде СУБД Pangolin — это целевая СУБД в Сбере и не только. В этой статье покажу на примерах, как всё работает. Прошу под кат.
Большая часть времени планировщика запросов в СУБД тратится на поиск оптимального способа соединения таблиц. В PostgreSQL используется два алгоритма: алгоритм динамического программирования, также называемый DPsize, и генетический — GEQO. В других СУБД реализовано еще множество других алгоритмов. DPhyp — алгоритм соединения на основе гиперграфов — уже используется такими СУБД как MySQL и YDB. Я задался вопросом: можно ли реализовать его в PostgreSQL? Оказывается, можно. Так и зародилось расширение pg_dphyp для PostgreSQL, реализующее альтернативный алгоритм соединения таблиц. В статье я не описываю подробно сам алгоритм, привожу только концептуальное описание его идеи, а рассказываю вот о чем:
-- Какие решения пришлось принять, чтобы добавить алгоритм DPhyp в существующую кодовую базу без изменения ядра;
-- Как GPLv2 помог найти эффективный алгоритм обхода соседей;
-- Как проиндексировали неиндексируемое гиперрёбра;
-- Планирование какого запроса смогли ускорить в 600 раз;
-- Какой изъян в работе существующего планировщика был найден.
Но главный сюжетный поворот — в конце...
Если вы работаете с базами данных, то вам определенно стоит иметь понимание о производительности кластера СУБД. Для этого можно использовать базовые метрики. А можно — метрики от DBaaS в сочетании с Grafana. Они позволяют строить кастомные графики, которые могут быть полезны в той или иной ситуации.
Привет! Меня зовут Рамиль Адильбеков, я DevOps-инженер в Selectel. В этой статье покажу, как можно настроить базовый стек Prometheus/Grafana, подключить метрики от кластера облачных баз данных и загрузить дашборд.
Если вы настраивали отказоустойчивый кластер Postgres, то сталкивались с необходимостью перенаправления пользовательского трафика на пишущий узел после аварии на основном узле и переключения на резервный. Мы разработали расширение Proxima, которое снимает необходимость в настройке и администрировании дополнительного программного обеспечения.
Разработчик программного обеспечения Postgres Professional Тофиг Алиев расскажет, как мы делали Proxima, какие архитектурные решения заложены в расширение, почему мы выбрали именно такой подход. Разберет тонкости реализации, которые позволили нам обрабатывать более 10 тысяч одновременных клиентских сессий. Рассмотрит примеры использования и ответит на вопросы.
Привет, Хабр! Меня зовут Алексей Быков, я занимаюсь развитием cloud-native-платформы для обработки данных Arenadata One (AD.ONE). В этой статье мы поговорим о neon-kubernetes-реализации PostgreSQL, её устройстве, особенностях и о том, почему классический подход к Postgres в Kubernetes не позволяет в полной мере использовать преимущества гибкой облачной инфраструктуры.
Тема не новая и активно развивается: уже давно существуют операторы (Zalando, Crunchy Data, CloudNativePG) для автоматизации развёртывания Postgres в Kubernetes. Однако они сохраняют монолитность базы, когда данные по-прежнему жёстко связаны с узлами, а горизонтальное или вертикальное масштабирование требует ручной настройки и остаётся непростым процессом. Подход Neon основан на полном разделении вычислений (compute) и хранилища (storage), что даёт нам возможность взглянуть на использование PostgreSQL в облаке по-новому, как на сервис с возможностью динамического масштабирования, мгновенного запуска инстансов, изолированных веток (branching) и других возможностей без необходимости в сложной инфраструктурной обвязке.
TL;DR Иногда «убить» самый тяжёлый JOIN — проще, чем кажется. Достаточно вынести агрегат в коррелированный под-запрос и дать движку опереться на индекс.
