Смотрим, как вездесущий PostgreSQL справляется с нестандартными для реляционной системы управления базами данных (СУБД) ролями: хранением и поиском временных рядов, пар «ключ — значение», эмбеддингов для больших языковых моделей и многомерных кубов. Отвечаем на вопрос: действительно ли так нужно строить сложные архитектуры со множеством разнородных систем хранения данных — MongoDB, Redis, InfluxDB, Pinecone, ClickHouse, Apache Cassandra — или можно обойтись одним PostgreSQL?

Привет, Хабр! Меня зовут Александр Брейман, я доцент департамента программной инженерии факультета компьютерных наук НИУ ВШЭ и по совместительству эксперт Учебного центра IBS по управлению данными и архитектуре ПО. В прошлой статье я рассказывал о миграции с Oracle на PostgreSQL, а сегодня разберу, как последний работает с нетипичными видами данных.

Следим за целостностью данных в PostgreSQL. Мысль о возможной катастрофе неприятна, поэтому люди часто не принимают серьезных предупредительных мер.

Администратор любой IT системы должен знать о всех возможных проблемах, которые могут возникнуть на вверенном ему оборудовании: аппаратные сбои системы хранения, сбои файловой системы, повреждения страниц в оперативной памяти, сбои в кэше хранилищ и так далее. Для серверов баз данных выявление и исправление таких ошибок особенно важно, так как информация в БД должна быть в согласованном состоянии и некорректность только части данных портит БД целиком. В этой статье мы расскажем с помощью каких инструментов можно защитить ваши данные в СУБД Postgres и обнаруживать ошибки до того, как они становятся реальными проблемами.

Cреднеквадратическое отклонение это MSE? Корень из неё? Или вообще отношения к ней не имеет?

Компания Postgres Professional занимается разработкой и поддержкой СУБД с 2015 года. Это серьёзный срок для компании в ИТ-сфере, и за это время мы видели много случаев, когда клиенты сталкивались с неоптимальным выполнением запросов. Обычно оптимизатор PostgreSQL неплохо справляется и строит хорошие планы, если количества джойнов в запросе не больше 10 и данные в таблицах распределены равномерно. Однако в даже на изначально тщательно продуманной базе данных, оптимизатор может сгенерировать настолько неоптимальный план, что его время выполнения может увеличиться в разы. В некоторых особо экстремальных случаях даже практически невозможно дождаться окончания выполнения запроса и понять при помощи EXPLAIN ANALYZE, что пошло не так. Усугубляющим фактором является то, что оптимизатор PostgreSQL никак не запоминает допущенные ошибки выполнения. Построив неоптимальный план один раз, он с большей долей вероятности будет делать это снова и снова до тех пор, пока что-то не изменится: статистика, настройки оптимизатора или какое-то внутреннее состояние СУБД.

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

На протяжении своего существования наша компания пытается отвечать на эти вызовы, для чего, например, были разработаны расширения AQO и sr_plan. Сообщество PostgreSQL также не стоит на месте: в ванильной версии появилась расширенная статистика и был введён ряд оптимизаций вроде инкрементальной сортировки и материализации промежуточных результатов выполнения запроса.

Однако все эти методы или имеют мало предсказуемый результат (AQO), или требуют глубокого понимания причин возникшей проблемы с ручной донастройкой СУБД. В своей новой разработке мы решили взглянуть на проблему исправления ошибок оптимизации с другой стороны. Основная идея в том, чтобы добавить возможность перепланирования на основе полезных сведений, которые можно получить из уже частично выполненного запроса. Помимо этого нужно сформулировать критерии для плохо спланированных запросов, для которых необходимо провести перепланирование.

Привет, Хабр! Я Владимир Хаймин, эксперт по системам управления базами данных PostgreSQL в ВТБ. В последнее время одним из наиболее распространенных способов миграции стала миграция при помощи свободного инструмента ora2pg. Однако многие отмечают его крайне низкую производительность, особенно если речь идет о базах Oracle размером под 1Тб и выше. Как ускорить миграцию и сократить время простоя при переносе проектов при помощи только oracle_fdw, либо в сочетании с ora2pg расскажу далее.

В PostgreSQL есть довольно интересный функционал - диапазонные типы данных (range). Они весьма удобны в использовании. Для индексирования этих типов данных существует GIST индекс. Однако на практике часто требуется сочетание BTREE индекса с GIST, что реализуется расширением btree_gist. Насколько эффективно удобство, предоставляемое диапазонными типами данных в сочетании с btree_gist мы и разберем в этой статье.

Для ЛЛ - с производительностью при использовании btree_gist будет плохо.

Обычно, обновлением статистик таблиц PostgreSQL занимается демон AUTOVACUUM. Однако, после кардинальных изменений в таблице, к которой сразу же требуется обращаться в последующих запросах к БД, рекомендуется явно обновить статистики этой таблицы явным запуском ANALYZE <имя таблицы>. Команда ANALYZE в PostgreSQL доступна только владельцу таблицы, владельцу базы данных и суперпользователю. При этом иногда возникает необходимость предоставить возможность явного обновления статистик обычному пользователю, не являющемуся владельцем таблицы.

Все чаще объектами статистического анализа становятся не массивы (таблицы) значений, а временные ряды. Такие ряды формируются при наблюдениях за природными процессами и явлениями, изучении социологических или макроэкономических показателей, при промышленном производстве и сбыте продукции. Главное, что отличает временной ряд от других типов данных – это то, что номер (время) наблюдения имеет значение. То есть, важен не только результат измерения, но и тот момент времени, когда оно выполнено. К сожалению, при применении статистических методов на этот нюанс часто не обращают внимания. Однако, именно эта "мелочь" приводит к очень серьезным и нетривиальным следствиям с точки зрения обработки таких сигналов. Самые обычные формулы, описанные во всех учебниках, внезапно отказываются работать. А попытки их применения "в лоб" иногда дают, мягко говоря, весьма неожиданные результаты. Например, статистическая связь между числом пиратов и глобальным потеплением оказывается не просто "значимой", а "практически достоверной". Что удивительно, столкнувшись с такой ситуацией, даже достаточно грамотные исследователи не всегда понимают, где же тут "порылась собака" . Данные вроде бы правильные, математика (как и жена Цезаря) – точно вне подозрений. А результат – ни в какие ворота... А Вы твердо уверены, что всегда правильно оцениваете значимость таких корреляций?

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

От любви до ненависти — один шаг, это история об этом. Если вы используете или планируете использовать холодное хранилище Selectel для бэкапа, выбросьте эту идею из головы НЕМЕДЛЕННО!

Я был привлечен дешевыми тарифами холодного хранилища Selectel и настроил на них архивацию данных из 1С.

Мне так понравилось холодное хранилище Selectel, что я рекомендовал его и настроил на него у трех своих клиентов архив 1С. Ничто не предвещало БЕДЫ.

Привет, Хабр!

Сегодня мы поговорим об актуальной задаче — миграции баз данных с Oracle на PostgreSQL с использованием Ora2Pg. Сейчас популярность PostgreSQL обоснована его мощностями и экономически выгодной альтернативы коммерческим решениям.

Привет, Хабр!

Хеш-индексы в PostgreSQL — это хороший инструмент для ускорения выполнения запросов.

В основе хеш-индекса лежит хеш-функция. Хеш-функция — это алгоритм, который преобразует входные данные (или ключ) в число фиксированного размера, называемое хеш-значением. В PostgreSQL хеш-функция всегда возвращает значение типа integer, что составляет примерно 4 миллиарда возможных значений.

Данная статья является продолжением первой части: "PostgreSQL 16. Организация данных. Часть 1".

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

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

Самая неприятная ситуация возникает, когда личные ценности и майндсет человека сильно расходятся с работой, которую ему приходится выполнять. Если работа не подходит человеку из‑за конфликта с личными свойствами и мотивацией, это не исправить обучением. Если такой человек — руководитель, будет страдать он и все вокруг него.

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

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

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

Последние несколько лет мы в Postgres Professional активно занимаемся разработкой своего решения для горизонтального масштабирования PostgreSQL. Пользователям нужен был простой способ увеличить производительность путем добавления узлов. Традиционно для веба в таких случаях просто брали NoSQL базы или шардировали вручную, позже появились распределенные SQL-решения с поддержкой ACID-транзакций. Тем не менее терялась часть возможностей и достоинств PostgreSQL. Корпоративный рынок тяжелых вертикальных решений также сильно ограничен как ценой, так и доступностью. Поэтому исследованиями в области распределенных СУБД в компании занимались еще с 2017 года, а в 2020 началась работа над коммерческим продуктом. 

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

Всем привет! Я Олег, fullstack‑разработчик в компании Тензор, тимлид небольшой команды.

Одна из моих обязанностей в роли тимлида это code review. За годы работы я видел многое и выделил для себя типовые ошибки, с которыми сталкиваются начинающие backend‑разработчики. Сегодня хочу рассказать о некоторых из них.

PostgreSQL очень популярная СУБД. Её используют во многих проектах, как новички, так и профессионалы. Однако не все понимают, как именно работает данная система и какое у неё внутренне устройство.

Давайте разберемся вместе на основе книги «PostgreSQL 16 изнутри» и официальной документации!

Сначала запрос адаптирован для работы в PostgreSQL 15.6.

Затем работа запроса проверена на достаточно объемной иерархии - в качестве источника данных использована структура архива jdk-master.zip из OpenJDK 22