Привет всем Хабр-читателям. Про развертывание и настройку HA кластера PostgreSQL с помощью Patroni написано много полезных статей, однако я не нашел описания алгоритма его работы. В этой статье я хочу поделиться своим исследованием по данному вопросу.
В предыдущих статьях "PostgreSQL Antipatterns: навигация по реестру", "PostgreSQL 13: happy pagination WITH TIES" и "SQL HowTo: курсорный пейджинг с неподходящей сортировкой" я уже рассматривал проблемы навигации по данным, представленных в виде плоского реестра.
Но что если мы хотим выводить данные не простым "бесконечным списком", а в виде иерархической структуры с быстрой навигацией по узлам - например, обширный каталог товаров или меню ресторана, как это делает Presto - наш продукт для автоматизации заведений питания? Вот тут нам и придется что-то поизобретать...
Завершив в недавнем прошлом очередную доработку своей легковесной технологии SQL-файл, применяемой для эффективной трансляции файлового SQL-кода в базу данных, автор данной статьи решил в очередной раз представить (в этой заметке теперь, на популярном ресурсе) свои реализованные, хотя бы отчасти, идеи касательно программирования MSSQL, а также некоторые соображения относительно применения SQL вообще. Автор полагает, что несмотря на форму предлагаемой им частной реализации SQL-файл (для MSSQL), лежащая в основе подхода концепция имеет определённую силу и смысл.
Выше на картинке: SQL-трансляция исходных файлов из нескольких директорий (скрипты *.sql), запуск fill_with_data.cmd
В далекой-далекой галактике были времена стабильности и процветания. Сервис с шестнадцатью инстансами работал на благо человечества. Через Hibernate он ходил в PostgreSQL-базу, доставал необходимые данные и отдавал другим по REST-интерфейсу. Однако спокойные времена прошли. Внезапно один из инстансов упал с OutOfMemoryError. Лучшие программисты hh.ru пустились в погоню за heapdump-ом в поисках ценнейшей информации.
Привет, меня зовут Артем, я — бэкенд-разработчик в hh.ru. В этой статье расскажу о том, как мы чинили одну из ошибок OutOfMemoryError, которая возникла при работе сервиса с базой данных. Сегодня говорим только на бэкендерском!
Привет, Хабр! Сегодня с вами команда AliExpress Order Management System, и мы поговорим про очередное решение по шардированию PostgreSQL, на этот раз in-app, то есть живущее непосредственно в приложении, которому нужна функциональность шардинга.
Итак, произошло то, что произошло, сегодня невозможно сделать сет Directum RX на MS SQL. Microsoft перестал отгружать лицензии в России. Для многих это стало неожиданностью, а для нас — нет. Задолго до введения санкционных ограничений мы позаботились о переходе на PostgreSQL и Linux. Причины были банальны — хотелось сократить расходы на лицензии.
Также хотелось научиться переводить системы Directum на PostgreSQL, предполагая, что слонёнок будет востребован у наших заказчиков по той же финансовой причине. Для нас отказ от баз Microsoft был плановым. Кроме того, мы перевели инфраструктуры вместе с Directum на Linux. Сегодня оцениваем эту попытку “переехать” с сокращением затрат как отчасти удачную.
Я, Виталий Волнянский, руководитель практики технологических решений (CTO), директор по продажам (VPS) ООО “ЕАЕ-Консалт”, под катом расскажу о том, как проходила миграция и с какими проблемами нам пришлось столкнуться.
pg_amcheck с флагом --heapallindexed (которая, к тому же, проверяет только btree-индексы).
Раз в несколько месяцев мы получаем предупреждения от системы мониторинга базы данных о том, что свободное место скоро закончится. Обычно мы просто выделяем больше места и забываем об этом, однако в этот раз мы мы были на карантине и система была нагружена меньше, чем обычно. И тут мы подумали, что это хорошая возможность провести чистку.
Начнем с конца: в итоге нам удалось освободить более чем 70 GB не оптимизированного и неиспользуемого пространства без удаления индексов и данных.
Меня зовут Якупов Азат, я дата-архитектор Quadcode. В индустрии я больше 20 лет, из них больше 6 лет — в архитектуре. Эта статья — немного сокращенный пересказ моего выступления на митапе по теме «Heap Table в PostgreSQL».
Речь в тексте пойдет об обычных таблицах, с которых начинается вся дата-инженерия. Посмотрим на то, как метаданные располагаются в Postgres, разберемся, что такое table page и fillfactor, а также поближе познакомимся с TOAST-таблицами.
Отслеживание изменённых данных (CDC) — это метод интеграции данных для обнаружения, захвата и передачи изменений, внесённых в источники данных базы данных.Как правило, интеграция данных на основе CDC состоит из следующих шагов:
У любого современного продукта — если он успешен — есть тот момент жизни, когда он из гадкого стартапа вдруг становится вполне себе прекрасным “энтерпрайз монолит платформ систем легаси”. Без тестов, без мониторинга, с highload и, конечно же, уймой родовых травм, вызванных быстрым развитием.
На критическую бизнес логику тесты будут написаны сами, без них никуда. Мониторинг и хайлоад — это курица и яйцо. После того, как у вас появится кто-то один из этой пары, на горизонте появится и второй. А вот все те, казалось бы, “удачные” и “быстрые” решения, заложенные при рождении, придётся исправлять. И если кодовую базу можно спокойно переписать (ну или хотя бы закидать костылями), то вот база данных — это одна сплошная горячая точка. Запросы и миграции, которые легко проходили на момент становления вашего продукта, легко могут сейчас положить прод, потому что ваша база теперь под постоянной нагрузкой, а ещё она неприлично раздулась.
Привет! Меня зовут Константин, и в Каруне я работаю backend-разработчиком. Данная статья — компиляция ряда сложностей, с которыми мы столкнулись, и методик для их решения. Вся проблема громоздких таблиц в том, что они, как визит к стоматологу — неожиданно, дорого, больно и ужасно вариативно.
С момента появления System R в 1974 году реляционные базы данных в целом, и SQL-базы в частности, стали доминирующим подходом для хранения данных, и до сих пор сохранили это положение, несмотря на появление многочисленных серьезных конкурентов. Слухи о кончине и упадке традиционных реляционных баз данных появляются постоянно, но PostgreSQL уверенно держит позиции и опережает как своих предшественников, так и предполагаемых преемников.
Фактически, база данных MySQL была настолько распространена, что стала частью одноименного стека LAMP (Linux, Apache, MySQL, Perl), преобладающего в ранних веб-разработках.
Единственным большим исключением из этой тенденции является OLAP, со специализированными методами, позволяющими резко повысить производительность определенных рабочих нагрузок. А новые соперники, такие как ClickHouse, качественно изменили подходы к аналитике.
Привет, меня зовут Андрей, я работаю ведущим разработчиком в компании СИГМА и отвечаю за решения по автоматизации расчетов технических условий. Сегодня хочу поделиться своим опытом переноса в среду PostgreSQL данных из СУБД Oracle и процедур, разработанных на PL/SQL.
Перед моей командой была поставлена срочная и нетривиальная задача перенести разрозненный функционал, ранее разработанный на базе СУБД Oracle, в единую систему управления распределительными электрическим сетями (по-простому СИГМА СУС), которая работает на основе PostgreSQL и сочетает в себе подсистемы DMS, SCADA, GIS, NIS, OMS и другие.
DBA в Southbridge Иван Чувашов подготовил статью о построении DWH на основе Greenplum. Слово Ивану.
Привет, Хабр! Я администратор баз данных с 15-летним опытом. Сегодня хочу рассказать про Data Warehouse на основе Greenplum — как они устроены, как их поднимать и с какими проблемами и нюансами я лично сталкивался в своей практике.
SQL - декларативный язык - то есть вы описываете "что" хотите получить, а СУБД сама решает, "как" именно она будет это делать. Некоторые из них при этом позволяют им "подсказывать", как именно лучше выполнять запрос, но PostgreSQL - нет.
Тем не менее, "синтаксический сахар" некоторых языковых конструкций позволяет не только писать меньше кода (учите матчасть!), но и добиться, что ваша база будет делать часть вычислений "лениво", только при фактической необходимости.
От автора перевода: Написанный далее текст может не совпадать с мнением автора перевода. Все высказывания идут от лица оригинального автора, просьба воздержаться от неоправданных минусов. Оригинальная статья выпущена в 2014 году, поэтому некоторые фрагменты кода могут быть устаревшими или "нежелаемыми".
Содержание статьи:
В статье приведены доводы, которые ставят под вопрос правильность присутствия ORM в рамках ООП.
Стремясь к повышению производительности базы данных, вы можете столкнуться с ситуацией, когда оптимизации и настройки уже недостаточно. Если вы не можете заменить движок БД, а для настройки параметры рабочей нагрузки больше нет возможностей — базу данных придется масштабировать. Делать это руками долго и нецелесообразно, но и у автоматизации процессов масштабирования есть свои подводные камни.
Это перевод статьи Дмитрия Костика и Миколы Моржан из Percona. С их помощью посмотрим, в какой степени можно автоматизировать горизонтальное масштабирование баз данных MongoDB, MySQL и PostgreSQL в Kubernetes и как это сделать?
Для приготовления CRUD нам понадобится 1C, Python и ... PostgreSQL. Сначала нужно включить REST OData в 1C.
