CSN vs MVCC Postgres: решаем проблему Long Fork аномалии и причем тут деградация Postgres при тысячах SAVEPOINT-ов

Одно из узких мест масштабируемости в традиционном PostgreSQL MVCC – получение снимков. Каждый раз, когда транзакции требуется снимок, она должна получить ProcArrayLock и пройтись по всем активным бэкендам, чтобы собрать их идентификаторы транзакций. Эта операция становится все более затратной по мере роста числа одновременных соединений: при тысячах соединений конкуренция за блокировку может серьезно ограничить пропускную способность. CSN (Commit Sequence Number) устраняет это узкое место, заменяя сканирование ProcArray атомарным чтением переменных, что делает получение снимков по сути O(1) независимо от количества соединений. В статье рассказывается о том, как технология работает в СУБД от «Тантор Лабс» и недавно представленной машине баз данных Tantor XData Gen3

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

#tantor #tantor_postgres #tantor_xdata #xdata #csn

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 #персональные_данные

МБД Tantor XData 2B: практический опыт промышленной эксплуатации ARM-серверов для 1С

Мы уже писали о нагрузочном тестировании машины баз данных Tantor XData 2Y на базе процессоров Intel, точнее, об успешно пройденном тесте на 30 тыс. пользователей 1С. Впечатляющие показатели — это прекрасно, однако реальность рынка enterprise-решений такова, что технические характеристики — не единственный критерий для выбора оборудования. Требования 398-ФЗ, стратегии импортозамещения, санкционные риски и бюджетные ограничения заставляют компании искать баланс между производительностью и другими факторами. В линейке Tantor XData есть модель 2B на базе процессоров Baikal-S, позиционируемая как ответ на подобные вызовы. В новой статье мы делимся результатами нагрузочного тестирования этой модели и рассказываем об особенностях работы ARM-архитектуры с PostgreSQL и практическом опыте оптимизации такой системы — со всеми техническими деталями, метриками производительности и найденными узкими местами.

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

#tantor_xdata #tantor #xdata #1c

Горизонтальное масштабирование 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

Как мониторить сотни инстансов 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