Привет, Хабр! Сегодня с вами команда 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.
Привет, дорогой читатель, в этой статье я хотел бы поделиться опытом работы с базой данных посредством ORM Dapper на .NET Core, а также рассказать полезные лайфхаки, которые нам помогают удобно использовать его при разработке приложений и рассмотрим как мог бы выглядеть сервис по созданию ведьмаков с использованием Dapper. В данной статье будет много примеров кода и комментариев к нему, а также граблей, по которым мы прошли. Статья рассчитана на тех, кто хочет начать использовать dapper в своих проектах либо тех, кто его уже использует. Итак начнем.
Меня зовут Бен Джонсон, и я написал встраиваемую базу данных, которая служит бэкендом систем вроде etcd, — это BoltDB. Сегодня я работаю над Open Source проектом Litestream в компании Fly.io. Благодаря репликации Litestream делает SQLite приемлемым для фулстек‐приложений. Если вы можете установить SQLite, то Litestream заставите работать за 10 минут.
Внешние ключи (foreign keys) - мощный и удобный механизм контроля логической целостности данных в базе. Но он бывает не только лишь полезен, и может неплохо пригрузить вашу БД.
Внимательный взгляд на план запроса поможет избежать многих проблем - как при чтении из базы, так и при вставке в нее.
Как и у многих, в нашей компании возник вопрос импортозамещения. В целом вопрос понятный, много раз обсужденный со всех точек зрения. И вот настал счастливый момент, когда слова трансформировались в конкретные задачи с конкретными сроками. И одна из них была о замене СУБД для 1С.
Ну и конечно же, первым делом был поднят вопрос о кластеризации этой истории. Никто подвоха особого не ожидал, ибо у нас есть уже зарекомендовавшее себя решение в виде связки pg_auto_failover версии 1.6 от Citus (далее PGAF для краткости) и keepalived. Это решение нас целиком и полностью устраивает, поэтому выбор наш был очевиден.
Но когда мы начали настраивать выяснился очень неприятный момент - обычная сборка PGAF просто не работает с версией СУБД от PostgresPro - все ломается из-за жестко прописанных зависимостей. Тут то и началось "веселье".
Был вариант игнорировать зависимости, но в таком случае мы получаем проблемы при обновлении. В итоге нашли альтернативу - собрать из исходников самим, настраивая пути и зависимости самостоятельно, о чем и расскажу. В моем повествовании нет какой-то особой магии, но пару дней сберечь точно поможет.