Буквально месяц назад, мы с моим коллегой участвовали в HAKATON. Наша команда взялась за интересную задачу от компании МТС: на основе тысяч опросов, найти усредненный синоним к определенной категории ответов и визуализировать это в виде графика, либо облака слов.
После выполнения задачи и защиты проекта мы задумались...
Третья статья цикла по асинхронному SQLAlchemy 2 посвящена оптимизации кода, обновлению и удалению данных. Рассмотрены улучшения базового класса, подходы к обновлению записей и методы удаления, с акцентом на повышение производительности. Нажмите «Читать», чтобы ознакомиться с материалом.
Здравствуйте, дорогие друзья! Сегодня мы окунёмся в мир SQL запросов и рассмотрим различные подходы, которые разработчики используют для работы с данными в БД. В современном мире разработки, где информация становитесь все больше и больше, и скорость получения данных имеет большое значение, умение эффективно извлекать и обрабатывать данные становится неотъемлемой частью работы многих SQL специалистов (особенно тех кто работает с нагруженными системами и DWH). Мы поговорим о таких методах, как Common Table Expressions (CTE), подзапросы, представления и материализованные представления.
Как известно, многие реляционные базы данных, а в данном конкретном случае PostgreSQL, обещают нам, что наши транзакции будут обладать соответствовать критериям ACID (Атомарность, Согласованность, Изолированность, Сохраняемость), при должном уровне конфигурирования тех или иных настроек.
Несмотря на название текста, заранее извиняясь перед читателем, отложим разговор о Durability-Сохраняемости, которая обеспечивает нам сохранность данных в случае отказа физического железа, прежде всего - отключение электричества, повреждение диска, сбой сети и любые иные катаклизмы. Вернемся мы к ней ближе к концу первой части и детальнее поговорим во второй.
А не будем мы о ней говорить прямо сейчас, потому что для начала хотелось бы поговорить о том, как в принципе выполняется запрос? Речь пойдет об одной машине Postgres, не рассматривая вопросы репликации и согласованности реплик.
Давайте представим ситуацию, что у нас есть база данных, в которой есть простенькая таблица:
Задача такая: искал Open Source БД для своего пет-проекта. Решил посмотреть в интернете новые решения в рамках БД. После чтения статей и отбора из 6-7 БД остались три (3), которые понравились лично мне. Больше ничего путного не нашел.
Почему именно эти? Во-первых, они Open Source, а во-вторых, у них есть ответы на два главных моих вопроса «Для чего это нужно?» и «Работает ли из коробки?».
Давайте покажу на примерах.
Привет! Меня зовут Полина Кудрявцева, я инженер DBA в Авито. В этой статье я расскажу о том, как мы внедрили CockroachDB на DBaaS в компанию классических СУБД, а также опишу его плюсы, минусы и особенности работы.
PostgreSQL: PostgreSQL 17 Released!
Новшества давно известны (в том числе из обзоров Павла Лузанова PostgreSQL 17: Часть 5, 4, 3, 2, 1), но интересно, что выбрали в сообществе как самое-самое важное. Выбрали вот что:
Производительность:
переработанное управление памятью (overhauled memory management) при вакууме,
оптимизация доступа к хранению и улучшение работы при параллельных нагрузках (high concurrency workloads),
ускорение при массовой загрузке и экспорте,
улучшения работы с индексами.
Работа с новыми типами нагрузок:
реализация SQL/JSON JSON_TABLE .
Для высококритичных систем:
улучшения в логической репликации, которые упрощают работу с нагрузками при требованиях высокой доступности и при апгрейдах на другие мажорные версии.
А вот что привлекло внимание сразу нескольких комментаторов: изменения в оформлении самих пресс-релизов:
Этой статьей мы начинаем цикл, посвященный различным настройкам по оперативной памяти в PostgreSQL. Тема непростая, даже сложная. Понятной информации по ней крайне мало (по состоянию на октябрь 2024). Поэтому будем разбираться, шаг за шагом, вдумчиво и, как принято у нас в блоге, подкреплять все выводы исследованиями и картиной из программы мониторинга PERFEXPERT (версия для PG).
Привет всем!
Я — Ипатов Александр, backend‑разработчик в ГК Юзтех. Сегодня хочу поделиться своим опытом в интересном проекте, связанном с миграцией БД MsSQL на PostgreSQL в разрезе оптимизации хранимых процедур и функций (далее — хранимых процедур, так как процесс оптимизации не сильно завязан на том, что именно имеем на выходе).
Актуальность проектов, связанных с миграциями серверов и баз данных с зарубежных платных продуктов (Microsoft, Oracle) на аналогичные отечественные или зарубежные open‑source решения (в разрезе статьи будем рассматривать Postgres) в 2024 году очень велика. Те решения, которые были реализованы и поддерживались на протяжении 5–10 лет, потребовалось практически в формате «пожара» переносить на аналогичные. А бизнес, который привык к уже полностью сформированным и отработанным рабочим процессам, не готов к потере эффективности и, как следствие, потере клиентов сервисов, заказов и бизнес‑метрик.
В одном из таких проектов мне удалось поучаствовать. Из начальных условий: проект по переносу БД из MsSQL начался примерно 3 года назад.
На самом деле, проект был более обширный — перенос монолитного сервиса на микросервисы, в том числе, как один из элементов — перенос БД.
Хочется отметить, что перенос схем, таблиц, индексов и других элементов базы данных прошел относительно спокойно. Чего не скажешь о переносе хранимых процедур. Язык T‑SQL, на котором пишутся хранимые процедуры в MsSQL, конечно же имеет отличия от PL/pgSQL, который используется в PostgreSQL. В связи с чем, непосредственно миграция хранимых процедур заняла много времени: точное число хранимых процедур я не назову, но порядок — около 800 штук (среди которых 500 стали работать хуже после миграции, их то и предстояло оптимизировать).
В этой статье мы расскажем о том, как эффективно реализовать полнотекстовый поиск с помощью PostgreSQL. Узнайте, как улучшить скорость и точность поиска по текстовым данным, используя такие инструменты, как tsvector, tsquery и индексы GIN, и как эти возможности могут значительно повысить производительность вашего приложения.
В очередной рабочий день поступила задача обновить Gitlab. Задача в общем-то не сложная, ни смотря на то, что там он установлен в докере из многим знакомого образа от sameersbn, что впоследствии было переделано на omnibus (что бы это не значило), т.к. по моему опыту omnibus версия (установка на чистый линукс) гораздо проще и предсказуемей в эксплуатации. Впрочем статья совсем не об этом.
Но как можно понять из наличия этой статьи, что-то пошло не так...
Так исторически сложилось, что задача организации простого и понятного резервного копирования в мире PostgreSQL до сих пор не решена. Есть набор комьюнити утилит, у каждой из которых есть некие плюсы, но всегда в нагрузку будет прорва минусов (тут нет инкрементных копий, там нет внятного расписания, это может только весь сервер вместо конкретной базы увозить и так далее). Да, есть тяжёловесный энтерпрайзный софт за много денег, зачастую требующий странного и работающий по какой-то своей логике, но это тоже не панацея. А вот чтобы просто и понятно, без головных болей организовать прозрачный процесс банального бекапа с инкрементами, работающим расписанием и восстановления только того что надо - вот такого нет.
Но буквально на днях вышел PostgreSQL 17 и может там что-то изменилось? И да, и нет. Та самая мана небесная в виде pg_awesome_backup_tool так и не появилась, однако в релиз попал механизм walsummarizer, который обещает нативно отслеживать изменения в файлах баз данных, что позволит делать инкрементальные бекапы нативно и без лишних приседаний.
А чтобы не рассматривать новичка в вакууме, будем сравнивать его с ptrack - нашей (Postgres Professional) разработкой, которую наши любимые конкуренты уже расхватали в свои продукты и продают их как уникальнейшие решения.
В моей работе, когда приходится исследовать и нагружать СУБД нетипичной нагрузкой и синтетическими тестами, часто встречаются случаи загадочного поведения системы: ускорение/замедление времени выполнения запроса на пару порядков, отказ использовать тот или иной индекс и тд. Объяснение странного поведения оказывается в итоге почти всегда тривиальным и хорошо известным опытным DBA. Однако встретив его в реальной эксплуатации первый раз невольно теряешься и на разбор кейса уходит много времени. Вместе с тем, это достаточно интересное упражнение - навроде того, как прорешать задачник по аэродинамике после 10 лет проектирования планеров самолётов. Поэтому предлагаю здесь попробовать формат обсуждения/изучения PostgreSQL в виде задач. Вдруг зайдёт?
Привет, Хабр! Меня зовут Михаил Герасимов. Это продолжение статьи «Как в РСХБ разработали средство генерации SQL-запроса для упрощения задач по тестированию», где описывались принципы работы QueryBuilder.
В условиях растущего тренда на импортозамещение в ИТ-компаниях, переход с коммерческих СУБД на Open Source решения стал одной из ключевых задач для многих организаций. В частности, в проекте по автоматизации тестирования специалисты РСХБ успешно адаптировали свой инструмент генерации SQL-запросов QueryBuilder к переходу на PostgreSQL.
«Всё это связано с тем, что подобные базы данных, по сути, представляют собой огромную распределённую хеш-таблицу. Единственные операции, работающие без необходимости сканирования всей базы данных — это поиск по секционному ключу и сканы, при которых используется ключ сортировки.
…Если паттерны доступа существенно изменятся, то может потребоваться полная повторная обработка всех данных».
Всем привет, этот практический цикл статей рассчитан на начинающих. Я решил поделиться своим опытом создания реестра данных на основе государственного. В этой статье займемся загрузкой и обработкой данных о результатах поверки средств измерений.
Мой опыт работы в продажах в различных компаниях многому меня научил. Одним из ключевых инструментов, без которого невозможен эффективный процесс продаж, является CRM-система. Для руководителей и менеджеров по продажам она должна решать множество задач и отвечать на целый ряд вопросов. Но об этом чуть позже.
На рынке представлено не так много распространённых CRM-систем для управления продажами, и в большинстве компаний мне приходилось работать именно с ними. В некоторых случаях я сталкивался с кастомными решениями, которые значительно упрощали жизнь пользователю благодаря удобному интерфейсу и гибкости. Поэтому на собеседованиях я часто задавал вопрос о CRM-системе компании. Разочарование наступало, когда выяснялось, что в компании используют "шаблонные" решения, которые не всегда соответствовали требованиям пользователей.
Ещё до того, как я начал заниматься разработкой, мне пришла идея поучаствовать в создании собственной CRM-системы и глубже погрузиться в процесс её разработки. Спустя несколько лет я начал заниматься веб-разработкой, и в какой-то момент понял, что даже небольшому бизнесу, где я работал, нужна CRM. Я пробовал использовать таблицы в Google Docs, тестировал триальные версии популярных CRM, но они были перегружены ненужной информацией и казались неудобными. Так что я решил создать что-то простое, что будет удобно мне и, возможно, другим.
В своей CRM я использую Next.js. Эта система не претендует на то, чтобы обслуживать тысячи пользователей, но она точно может решить задачи 1-2 небольших отделов продаж. У меня есть репозиторий на GitHub, и если кому-то это решение покажется интересным, его можно взять и доработать под свои задачи. В этой статье я постараюсь кратко описать текущий функционал, с какими трудностями я столкнулся и что удалось внедрить в качестве новых гипотез.
Привет, Хабр! В начале октября вышло обновление нашей СРК Кибер Бэкап. Спешим поделиться обзором новинок в версии 17.1.
Чтобы объяснить, что есть Postgres Pre-Commitfest party и зачем мы в это ввязались, для начала нужно объяснить, как идёт разработка ванильного постгреса. Процесс принятия новых фичей и патчей в код разделён на так называемые коммифтесты (сокращённо CF), расписание которых всегда можно посмотреть на сайте https://commitfest.postgresql.org/. Когда разработчик предлагает свой код (неважно, будь это новая фича или багофикс), для того чтобы он был рассмотрен в рамках CF, он предварительно должен пройти процедуру ревью и быть одобрен для рассмотрения. Конечно, это совершенно не гарантирует, что код будет принят на этом CFили даже следующем, но сейчас не про это.
Найти ревьюера для своего кода зачастую задача более сложная, чем написать сам код. Человека надо погрузить в решаемую проблему, объяснить, что именно ты предлагаешь изменить, почему так, а не иначе и так далее. Прямо сейчас, в статусе Needs review, находится 29 патчей. Со свойственным нам желанием помогать, мы решили кинуть клич среди коммитеров и собрать всех желающих под одной крышей, чтобы они могли представить свои патчи, обсудить их и, возможно, найти желающего провести ревью.
Так получилось, что собрались мы в рамках проходившего Highload++ в Санкт-Петербурге. Поскольку Open Source — дело добровольное, мы просто разослали всем контактам, которые у нас были, предложение примерно следующего содержания: зовём всех неравнодушных постгресистов собраться в шатре, рассказать про свои патчи, обсудить их и хорошо провести время.
