Exadata на Postgres, или старые архитектурные проблемы и их решение

СУБД PostgreSQL давно закрепилась в топе благодаря открытости, надёжности и расширяемости, однако ее архитектурный консерватизм порождает ряд нерешённых проблем: отсутствие горизонтального масштабирования, деградация при тысячах соединений, узкое место WAL при высоком commit rate, невозможность полноценной HTAP-обработки и другие. В статье рассказываем, как в новом, третьем поколении машин баз данных Tantor XData Gen3 эти ограничения преодолеваются через глубокую переработку архитектуры — от полного разделения Compute и Storage с протоколом RDMA и распределённой файловой системой PFS до внедрения механизмов CSN для MVCC без блокировок, конвейерной обработки WAL и встроенного MPP-движка, превращающего PostgreSQL в систему, способную конкурировать с Oracle Exadata уже по-настоящему. И все это – со 100% сохранением совместимости с "обычным" PostgreSQL.

https://habr.com/ru/companies/tantor/articles/1007038/

#tantor #tantor_postgres #tantor_xdata #xdata #oracle #oracle_database #oracle_exadata #tantor_polar

От неизвестной схемы до защищённой БД: полный цикл защиты данных в Tantor Certified 17

«Поднятие» унаследованного Postgres без специнструментов быстро превращается в головную боль: вас ждет ручной разбор схем, перелопачивание десятков таблиц и прочая невеселая археология - где лежат персональные данные, что за колонки, как это всё соотносится с 152-ФЗ… Один неверный шаг – и можно запросто упустить что-то важное. Встроенного защитного преобразования данных на диске нет, приходится либо городить огород на уровне приложений, либо создавать триггеры. Хранить ключи, тестировать производительность, поддерживать это всё, руками выставлять фильтры, думать, куда писать логи, как следить за аномалиями и так далее. Всё, что связано с безопасностью – проверять вручную. Любое изменение схемы — снова садись и аудируй заново. Времени уходить будет очень много, и неизвестно, какие грабли вылезут. В СУБД Tantor Certified то, что обычно делается на коленке, превращается в понятный и безопасный процесс, который подробно описывается в статье.

https://habr.com/ru/companies/tantor/articles/1006092/

#postgresql #postgres #tantor #tantor_postgres #tantor_certified #персональные_данные

Postgres по-русски: где наши Aurora, AlloyDB и Neon?

Базы данных давно являются фундаментом цифровой экономики. От их архитектуры и производительности во многом зависят скорость вывода продуктов на рынок, стабильность сервисов и итоговая стоимость ИТ-инфраструктуры. В мировой практике одним из основных стандартов де-факто, вокруг которого формируются экосистемы серьезных решений, стала открытая СУБД PostgreSQL. В России она используется во множестве корпоративных приложений, есть целый ряд отечественных форков и дистрибутивов. Но у ряда зарубежных компаний( есть серьезные прорывные реализации, интенсивно развивающие Postgres (например, Aurora, AlloyDB и Neon, об этом ниже), а у российских этого почему-то не наблюдается. Это противоречие между массовым использованием PostgreSQL в нашей стране и отсутствием технологического прорыва задает остроту сегодняшней повестки отечественного СУБД-строения.

https://habr.com/ru/companies/tantor/articles/988340/

#neon #horizondb #aurora #alloydb #alibaba #postgresql #tantor_xdata #xdata #tantor_postgres

Горизонтальное масштабирование 1С: переносим отчеты на реплику без потери производительности

В статье рассматриваются текущие возможности горизонтального масштабирования СУБД для 1С, а также какое решение предлагает Tantor Postgres.

https://habr.com/ru/companies/tantor/articles/987338/

#postgresql #postgres #tantor #tantor_postgres #1с

Как ускорить SQL-запрос в миллион раз без изменения кода: кейс со STATMULTIPLIER в Postgres

Однажды при мониторинге мы обратили внимание на запрос, который занимал первое место по длительности: 40+ секунд на выполнение при 657 вызовах за день. Причина состояла в том, что из-за неточной статистики распределения данных выбирался неподходящий индекс. В статье расскажем о том, как с помощью параметра STATMULTIPLIER в СУБД Tantor Postgres этот проблемный запрос удалось ускорить примерно в миллион раз — до 0.042 миллисекунды, — просто повысив точность статистики без изменения кода или структуры базы данных.

https://habr.com/ru/companies/tantor/articles/985130/

#postgresql #postgres #tantor #tantor_postgres #1c

[Перевод] Ускорение планирования JOIN’ов — до 16 раз быстрее

Привет, Хабр! Делимся переводом статьи о патче, сделанном разработчиком «Тантор Лабс» для 19 версии PostgreSQL — по сути, частичкой вклада нашей компании. Благодаря коммиту Ильи Евдокимова, в PostgreSQL 19 планирование JOIN’ов станет до 16 раз быстрее. Если раньше алгоритм сравнения частых значений (MCV) работал за O(N²), и при target=10k само планирование запроса могло занимать десятки миллисекунд, то теперь вместо квадратичного перебора будет использоваться хеш-таблица, а это снижает сложность до O(N). Изменение особенно оценят те, кто работает с неравномерными данными и поднимает default_statistics_target выше 1000. Подробный разбор с тестами и графиками — в переводе статьи о нашем патче.

https://habr.com/ru/companies/tantor/articles/975808/

#postgresql #postgres #tantor #tantor_postgres #join

СУБД Tantor Postgres 17.6: обзор улучшений для 1С

Продолжаем знакомить вас с улучшениями СУБД Tantor Postgres для работы с продуктами 1С. В рамках предыдущей статьи о нововведениях версии 17.5 мы разобрали арсенал специализированных функций, призванных существенно ускорить выполнение типичных для 1С операций, снизить нагрузку на инфраструктуру и упростить администрирование. Сегодня мы рассмотрим, с какими проблемами можно столкнуться при высоких значениях default_statistics_target , расскажем о новых оптимизациях для ускорения выполнения запросов, и, конечно, коснемся временных таблиц.

https://habr.com/ru/companies/tantor/articles/965264/

#tantor_postgres #1c #postgresql #высокая_производительность #высоконагруженные_проекты #высоконагруженные_приложения

Как мониторить сотни инстансов PostgreSQL и не сойти с ума

Если вы инженер в крупной компании, а особенно если ваша организация поставляет свои услуги в виде SaaS-решений, то вам так или иначе придется решать задачу мониторинга работы всех ваших баз PostgreSQL. На них часто бывает завязан функционал, важный для компании с точки зрения финансовых рисков, поэтому крайне желательно организовать не только мониторинг, но и получение уведомлений, когда что-то идет не по плану (или пойдет в ближайшем будущем). В рамках статьи мы рассмотрим несколько способов, как это можно сделать: самостоятельно, с использованием уже привычного стека Prometheus + Grafana, либо подключая сторонние open-source специализированные решения для мониторинга PostgreSQL, либо же используя специализированные платные решения. По каждому варианту поймем все плюсы и минусы, чтобы вы cмогли более уверенно выбрать свой путь.

https://habr.com/ru/companies/tantor/articles/940752/

#postgresql #tantor #tantor_postgres #saas_услуги #prometheus #grafana

Выбор индекса при соединении по нескольким столбцам

Когда имеется несколько индексов с одинаковыми ведущими столбцами, иногда выбирается не лучший индекс, и время выполнения запроса увеличивается на порядки. Такие ситуации встречаются в сложных приложениях, но чаще всего в 1С:ERP, поскольку это приложение наиболее распространено. Как это обычно бывает: после миграции приложения на СУБД PostgreSQL часть запросов начинает выполняться медленнее. Планировщик выбирает индекс, созданный по меньшему числу столбцов, время выполнения увеличивается, потому что при использовании такого индекса индексные записи указывают на строки таблицы, которые не соответствуют условиям соединения. При выборе же индекса по большему числу задействованных в запросе столбцов время выполнения становится существенно ниже и практически не зависит от размера таблиц. В статье детализируется часть доклада Максима Старкова на конференции PG BootCamp, которая прошла в апреле в Екатеринбурге. Описываются признаки таблиц и индексов, при работе с которыми может возникнуть проблема выбора худшего индекса, а также рассматривается пример, демонстрирующий, что строка "Buffers" характерна для определения эффективности выполнения запроса (в 18 версии PostgreSQL "Buffers" будет показываться в планах по умолчанию).

https://habr.com/ru/companies/tantor/articles/930602/

#postgresql #tantor #tantor_postgres

Работа с временными таблицами в PostgreSQL

При создании временных таблиц в PostgreSQL изменяются до 13 таблиц системного каталога, при этом особенно сильно разрастаются pg_attribute , pg_class , pg_depend и pg_type . Массовое создание и усечение временных таблиц активно применяется, в том числе в 1C:ERP. В статье рассматриваются особенности работы с временными таблицами и описано решение проблемы раздувания таблиц системного каталога, реализованное в СУБД Tantor Postgres.

https://habr.com/ru/companies/tantor/articles/930038/

#postgresql #tantor_postgres #tantor