#tantor — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #tantor, aggregated by home.social.
-
CSN vs MVCC Postgres: решаем проблему Long Fork аномалии и причем тут деградация Postgres при тысячах SAVEPOINT-ов
Одно из узких мест масштабируемости в традиционном PostgreSQL MVCC – получение снимков. Каждый раз, когда транзакции требуется снимок, она должна получить ProcArrayLock и пройтись по всем активным бэкендам, чтобы собрать их идентификаторы транзакций. Эта операция становится все более затратной по мере роста числа одновременных соединений: при тысячах соединений конкуренция за блокировку может серьезно ограничить пропускную способность. CSN (Commit Sequence Number) устраняет это узкое место, заменяя сканирование ProcArray атомарным чтением переменных, что делает получение снимков по сути O(1) независимо от количества соединений. В статье рассказывается о том, как технология работает в СУБД от «Тантор Лабс» и недавно представленной машине баз данных Tantor XData Gen3
-
CSN vs MVCC Postgres: решаем проблему Long Fork аномалии и причем тут деградация Postgres при тысячах SAVEPOINT-ов
Одно из узких мест масштабируемости в традиционном PostgreSQL MVCC – получение снимков. Каждый раз, когда транзакции требуется снимок, она должна получить ProcArrayLock и пройтись по всем активным бэкендам, чтобы собрать их идентификаторы транзакций. Эта операция становится все более затратной по мере роста числа одновременных соединений: при тысячах соединений конкуренция за блокировку может серьезно ограничить пропускную способность. CSN (Commit Sequence Number) устраняет это узкое место, заменяя сканирование ProcArray атомарным чтением переменных, что делает получение снимков по сути O(1) независимо от количества соединений. В статье рассказывается о том, как технология работает в СУБД от «Тантор Лабс» и недавно представленной машине баз данных Tantor XData Gen3
-
CSN vs MVCC Postgres: решаем проблему Long Fork аномалии и причем тут деградация Postgres при тысячах SAVEPOINT-ов
Одно из узких мест масштабируемости в традиционном PostgreSQL MVCC – получение снимков. Каждый раз, когда транзакции требуется снимок, она должна получить ProcArrayLock и пройтись по всем активным бэкендам, чтобы собрать их идентификаторы транзакций. Эта операция становится все более затратной по мере роста числа одновременных соединений: при тысячах соединений конкуренция за блокировку может серьезно ограничить пропускную способность. CSN (Commit Sequence Number) устраняет это узкое место, заменяя сканирование ProcArray атомарным чтением переменных, что делает получение снимков по сути O(1) независимо от количества соединений. В статье рассказывается о том, как технология работает в СУБД от «Тантор Лабс» и недавно представленной машине баз данных Tantor XData Gen3
-
CSN vs MVCC Postgres: решаем проблему Long Fork аномалии и причем тут деградация Postgres при тысячах SAVEPOINT-ов
Одно из узких мест масштабируемости в традиционном PostgreSQL MVCC – получение снимков. Каждый раз, когда транзакции требуется снимок, она должна получить ProcArrayLock и пройтись по всем активным бэкендам, чтобы собрать их идентификаторы транзакций. Эта операция становится все более затратной по мере роста числа одновременных соединений: при тысячах соединений конкуренция за блокировку может серьезно ограничить пропускную способность. CSN (Commit Sequence Number) устраняет это узкое место, заменяя сканирование ProcArray атомарным чтением переменных, что делает получение снимков по сути O(1) независимо от количества соединений. В статье рассказывается о том, как технология работает в СУБД от «Тантор Лабс» и недавно представленной машине баз данных Tantor XData Gen3
-
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
-
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
-
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
-
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 и практическом опыте оптимизации такой системы — со всеми техническими деталями, метриками производительности и найденными узкими местами.
-
МБД Tantor XData 2B: практический опыт промышленной эксплуатации ARM-серверов для 1С
Мы уже писали о нагрузочном тестировании машины баз данных Tantor XData 2Y на базе процессоров Intel, точнее, об успешно пройденном тесте на 30 тыс. пользователей 1С. Впечатляющие показатели — это прекрасно, однако реальность рынка enterprise-решений такова, что технические характеристики — не единственный критерий для выбора оборудования. Требования 398-ФЗ, стратегии импортозамещения, санкционные риски и бюджетные ограничения заставляют компании искать баланс между производительностью и другими факторами. В линейке Tantor XData есть модель 2B на базе процессоров Baikal-S, позиционируемая как ответ на подобные вызовы. В новой статье мы делимся результатами нагрузочного тестирования этой модели и рассказываем об особенностях работы ARM-архитектуры с PostgreSQL и практическом опыте оптимизации такой системы — со всеми техническими деталями, метриками производительности и найденными узкими местами.
-
МБД Tantor XData 2B: практический опыт промышленной эксплуатации ARM-серверов для 1С
Мы уже писали о нагрузочном тестировании машины баз данных Tantor XData 2Y на базе процессоров Intel, точнее, об успешно пройденном тесте на 30 тыс. пользователей 1С. Впечатляющие показатели — это прекрасно, однако реальность рынка enterprise-решений такова, что технические характеристики — не единственный критерий для выбора оборудования. Требования 398-ФЗ, стратегии импортозамещения, санкционные риски и бюджетные ограничения заставляют компании искать баланс между производительностью и другими факторами. В линейке Tantor XData есть модель 2B на базе процессоров Baikal-S, позиционируемая как ответ на подобные вызовы. В новой статье мы делимся результатами нагрузочного тестирования этой модели и рассказываем об особенностях работы ARM-архитектуры с PostgreSQL и практическом опыте оптимизации такой системы — со всеми техническими деталями, метриками производительности и найденными узкими местами.
-
МБД Tantor XData 2B: практический опыт промышленной эксплуатации ARM-серверов для 1С
Мы уже писали о нагрузочном тестировании машины баз данных Tantor XData 2Y на базе процессоров Intel, точнее, об успешно пройденном тесте на 30 тыс. пользователей 1С. Впечатляющие показатели — это прекрасно, однако реальность рынка enterprise-решений такова, что технические характеристики — не единственный критерий для выбора оборудования. Требования 398-ФЗ, стратегии импортозамещения, санкционные риски и бюджетные ограничения заставляют компании искать баланс между производительностью и другими факторами. В линейке Tantor XData есть модель 2B на базе процессоров Baikal-S, позиционируемая как ответ на подобные вызовы. В новой статье мы делимся результатами нагрузочного тестирования этой модели и рассказываем об особенностях работы ARM-архитектуры с PostgreSQL и практическом опыте оптимизации такой системы — со всеми техническими деталями, метриками производительности и найденными узкими местами.
-
Горизонтальное масштабирование 1С: переносим отчеты на реплику без потери производительности
В статье рассматриваются текущие возможности горизонтального масштабирования СУБД для 1С, а также какое решение предлагает Tantor Postgres.
-
Как ускорить SQL-запрос в миллион раз без изменения кода: кейс со STATMULTIPLIER в Postgres
Однажды при мониторинге мы обратили внимание на запрос, который занимал первое место по длительности: 40+ секунд на выполнение при 657 вызовах за день. Причина состояла в том, что из-за неточной статистики распределения данных выбирался неподходящий индекс. В статье расскажем о том, как с помощью параметра STATMULTIPLIER в СУБД Tantor Postgres этот проблемный запрос удалось ускорить примерно в миллион раз — до 0.042 миллисекунды, — просто повысив точность статистики без изменения кода или структуры базы данных.
-
[Перевод] Ускорение планирования JOIN’ов — до 16 раз быстрее
Привет, Хабр! Делимся переводом статьи о патче, сделанном разработчиком «Тантор Лабс» для 19 версии PostgreSQL — по сути, частичкой вклада нашей компании. Благодаря коммиту Ильи Евдокимова, в PostgreSQL 19 планирование JOIN’ов станет до 16 раз быстрее. Если раньше алгоритм сравнения частых значений (MCV) работал за O(N²), и при target=10k само планирование запроса могло занимать десятки миллисекунд, то теперь вместо квадратичного перебора будет использоваться хеш-таблица, а это снижает сложность до O(N). Изменение особенно оценят те, кто работает с неравномерными данными и поднимает default_statistics_target выше 1000. Подробный разбор с тестами и графиками — в переводе статьи о нашем патче.
-
Как мониторить сотни инстансов 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" будет показываться в планах по умолчанию).
-
Работа с временными таблицами в PostgreSQL
При создании временных таблиц в PostgreSQL изменяются до 13 таблиц системного каталога, при этом особенно сильно разрастаются pg_attribute , pg_class , pg_depend и pg_type . Массовое создание и усечение временных таблиц активно применяется, в том числе в 1C:ERP. В статье рассматриваются особенности работы с временными таблицами и описано решение проблемы раздувания таблиц системного каталога, реализованное в СУБД Tantor Postgres.
-
Авторизация OAuth 2.0 в PostgreSQL на примере Keycloak
Привет, Хабр! Мы продолжаем цикл статей о нововведениях СУБД Tantor Postgres 17.5.0, и сегодня поговорим о поддержке авторизации через OAuth 2.0 Device Authorization Flow — это современный и безопасный способ предоставления доступа, который позволяет приложениям запрашивать доступ к PostgreSQL от имени пользователя через внешнего провайдера идентификации и управления доступом, например Keycloak, что особенно удобно для облачных сред и микросервисных архитектур (функция будет также доступна в PostgreSQL 18). В статье пошагово разберём настройку OAuth-авторизации в PostgreSQL с использованием Keycloak: настроим Keycloak, подготовим PostgreSQL, напишем валидатор токенов OAuth в PostgreSQL и проверим успешную авторизацию через psql с использованием Device Flow.
https://habr.com/ru/companies/tantor/articles/923582/
#postgresql #tantor_postgres #tantor #системное_администрирование #keycloak #oauth_20
-
Когда может быть полезно сэмплирование в pg_stat_statements?
pg_stat_statements — стандартное расширение PostgreSQL для сбора статистики выполнения SQL-запросов. Статистика позволяет анализировать поведение запросов во времени, выявлять проблемные участки и принимать обоснованные решения по оптимизации. Однако в системах с высокой конкуренцией pg_stat_statements само по себе может стать узким местом и вызывать просадки производительности. В этой статье разбираем, в каких сценариях расширение становится источником проблем, как устроено сэмплирование и в каких случаях его применение позволяет снизить накладные расходы.
https://habr.com/ru/companies/tantor/articles/919592/
#postgresql #tantor_postgres #tantor #Семплирование #pg_stat_statements #LWLock
-
Когда может быть полезно сэмплирование в pg_stat_statements?
pg_stat_statements — стандартное расширение PostgreSQL для сбора статистики выполнения SQL-запросов. Статистика позволяет анализировать поведение запросов во времени, выявлять проблемные участки и принимать обоснованные решения по оптимизации. Однако в системах с высокой конкуренцией pg_stat_statements само по себе может стать узким местом и вызывать просадки производительности. В этой статье разбираем, в каких сценариях расширение становится источником проблем, как устроено сэмплирование и в каких случаях его применение позволяет снизить накладные расходы.
https://habr.com/ru/companies/tantor/articles/919592/
#postgresql #tantor_postgres #tantor #Семплирование #pg_stat_statements #LWLock
-
Когда может быть полезно сэмплирование в pg_stat_statements?
pg_stat_statements — стандартное расширение PostgreSQL для сбора статистики выполнения SQL-запросов. Статистика позволяет анализировать поведение запросов во времени, выявлять проблемные участки и принимать обоснованные решения по оптимизации. Однако в системах с высокой конкуренцией pg_stat_statements само по себе может стать узким местом и вызывать просадки производительности. В этой статье разбираем, в каких сценариях расширение становится источником проблем, как устроено сэмплирование и в каких случаях его применение позволяет снизить накладные расходы.
https://habr.com/ru/companies/tantor/articles/919592/
#postgresql #tantor_postgres #tantor #Семплирование #pg_stat_statements #LWLock
-
Когда может быть полезно сэмплирование в pg_stat_statements?
pg_stat_statements — стандартное расширение PostgreSQL для сбора статистики выполнения SQL-запросов. Статистика позволяет анализировать поведение запросов во времени, выявлять проблемные участки и принимать обоснованные решения по оптимизации. Однако в системах с высокой конкуренцией pg_stat_statements само по себе может стать узким местом и вызывать просадки производительности. В этой статье разбираем, в каких сценариях расширение становится источником проблем, как устроено сэмплирование и в каких случаях его применение позволяет снизить накладные расходы.
https://habr.com/ru/companies/tantor/articles/919592/
#postgresql #tantor_postgres #tantor #Семплирование #pg_stat_statements #LWLock
-
Трассировка запросов в Postgres с расширением pg_trace
В рамках статьи расскажем о расширении pg_trace, предназначенном для сбора трассировок запросов в PostgreSQL, соберем трассировку на реальном примере работы приложения, оценим влияние сбора трассировки на производительность и агрегируем данные трассировки.
https://habr.com/ru/companies/tantor/articles/915256/
#tantor #тантор #tantor_postgres #postgresql #postgres #субд #тестирование #1с #1c #1c_предприятие
-
Как провести нагрузочное тестирование БД PostgreSQL и ничего не забыть
При нагрузочном тестировании баз данных Tantor Postgres или других на базе PostgreSQL с использованием стандартного инструмента pgbench отсутствие фиксации деталей окружения (таких как конфигурация СУБД, характеристики сервера, версии ПО) часто приводит к нерепрезентативным результатам и необходимости повторных тестов. В статье рассматривается разработанный автором инструмент pg_perfbench, который призван решить эту проблему.
https://habr.com/ru/companies/tantor/articles/914320/
#tantor #тантор #tantor_postgres #postgresql #postgres #pg_bench #pg_perfbench #субд #тестирование
-
Быстрый старт в маскировании данных PostgreSQL с инструментом pg_anon
В этой статье поговорим о не самом гламурном, но жизненно важном — маскировании данных. Маскирование может касаться имён, телефонов, номеров карт, медицинских диагнозов и другой чувствительной информации. Если ваша компания до сих пор передает данные подрядчикам или аналитикам как они есть в базе, это в один «прекрасный» момент обязательно обернётся репутационной или финансовой проблемой для бизнеса. В этой статье разберём, зачем нужно маскирование, какие данные требуют защиты, и представим opensource-инструмент, который поможет решить эти задачи гибко и эффективно.
https://habr.com/ru/companies/tantor/articles/913196/
#маскирование_данных #pg_anon #postgresql #персональные_данные #защита_данных #конфиденциальная_информация #тантор #tantor #tantor_postgres #анонимизация_данных