#tantor — Public Fediverse posts

Как фильтр Блума ускоряет JOIN'ы в PostgreSQL

Как ускорить Hash Join в PostgreSQL, отбросив 99% строк ещё до самого соединения? Рассказываем о фильтре Блума в СУБД Tantor Postgres на живых и синтетических примерах.

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

#postgresql #postgres #tantor #tantor_postgres #1c #фильтр_блума #bloom #bloom_filter

Как фильтр Блума ускоряет JOIN'ы в PostgreSQL

Как ускорить Hash Join в PostgreSQL, отбросив 99% строк ещё до самого соединения? Рассказываем о фильтре Блума в СУБД Tantor Postgres на живых и синтетических примерах.

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

#postgresql #postgres #tantor #tantor_postgres #1c #фильтр_блума #bloom #bloom_filter

Как фильтр Блума ускоряет JOIN'ы в PostgreSQL

Как ускорить Hash Join в PostgreSQL, отбросив 99% строк ещё до самого соединения? Рассказываем о фильтре Блума в СУБД Tantor Postgres на живых и синтетических примерах.

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

#postgresql #postgres #tantor #tantor_postgres #1c #фильтр_блума #bloom #bloom_filter

Как мы тестируем Tantor Postgres для 1С от нагрузочных тестов до оптимизаций планировщика

Tantor Postgres 18 - масштабный релиз СУБД, за которым стоят месяцы тестирования, сотни часов нагрузочных прогонов и десятки исправлений, о которых пользователь никогда не узнает просто потому, что они были найдены и устранены до выхода версии. Александр Симонов, руководитель направления развития 1С в "Тантор Лабс", рассказывает, как устроен процесс тестирования изнутри - почему одного эталонного прогона недостаточно, что делать, когда ванильный PostgreSQL 18 ломает собственные оптимизации, и как Tantor Postgres приближается к той планке, которую MS SQL Server держал годами.

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

#tantor #tantor_postgres #тантор #postgresql #postgres #субд #тестирование #1с

Как мы тестируем Tantor Postgres для 1С от нагрузочных тестов до оптимизаций планировщика

Tantor Postgres 18 - масштабный релиз СУБД, за которым стоят месяцы тестирования, сотни часов нагрузочных прогонов и десятки исправлений, о которых пользователь никогда не узнает просто потому, что они были найдены и устранены до выхода версии. Александр Симонов, руководитель направления развития 1С в "Тантор Лабс", рассказывает, как устроен процесс тестирования изнутри - почему одного эталонного прогона недостаточно, что делать, когда ванильный PostgreSQL 18 ломает собственные оптимизации, и как Tantor Postgres приближается к той планке, которую MS SQL Server держал годами.

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

#tantor #tantor_postgres #тантор #postgresql #postgres #субд #тестирование #1с

Как мы тестируем Tantor Postgres для 1С от нагрузочных тестов до оптимизаций планировщика

Tantor Postgres 18 - масштабный релиз СУБД, за которым стоят месяцы тестирования, сотни часов нагрузочных прогонов и десятки исправлений, о которых пользователь никогда не узнает просто потому, что они были найдены и устранены до выхода версии. Александр Симонов, руководитель направления развития 1С в "Тантор Лабс", рассказывает, как устроен процесс тестирования изнутри - почему одного эталонного прогона недостаточно, что делать, когда ванильный PostgreSQL 18 ломает собственные оптимизации, и как Tantor Postgres приближается к той планке, которую MS SQL Server держал годами.

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

#tantor #tantor_postgres #тантор #postgresql #postgres #субд #тестирование #1с

Как перестать покупать диски, или Практическое руководство по ILM в Tantor Postgres 18

ILM (управление жизненным циклом данных) в Tantor Postgres 18 работает в три этапа: администратор задаёт правила, система собирает статистику и выдаёт рекомендации, а вот что делать дальше - решение за администратором. В туториале я последовательно прохожу все эти этапы: установка расширений, настройка tablespace'ов, работа с обычными и секционированными таблицами и проверка рекомендаций через Flamegraph. В общем, разбираю новый функционал с практической стороны.

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

#ilm #tantor #tantor_postgres #postgresql #жизненный_цикл #жизненный_цикл_данных

Как перестать покупать диски, или Практическое руководство по ILM в Tantor Postgres 18

ILM (управление жизненным циклом данных) в Tantor Postgres 18 работает в три этапа: администратор задаёт правила, система собирает статистику и выдаёт рекомендации, а вот что делать дальше - решение за администратором. В туториале я последовательно прохожу все эти этапы: установка расширений, настройка tablespace'ов, работа с обычными и секционированными таблицами и проверка рекомендаций через Flamegraph. В общем, разбираю новый функционал с практической стороны.

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

#ilm #tantor #tantor_postgres #postgresql #жизненный_цикл #жизненный_цикл_данных

Как перестать покупать диски, или Практическое руководство по ILM в Tantor Postgres 18

ILM (управление жизненным циклом данных) в Tantor Postgres 18 работает в три этапа: администратор задаёт правила, система собирает статистику и выдаёт рекомендации, а вот что делать дальше - решение за администратором. В туториале я последовательно прохожу все эти этапы: установка расширений, настройка tablespace'ов, работа с обычными и секционированными таблицами и проверка рекомендаций через Flamegraph. В общем, разбираю новый функционал с практической стороны.

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

#ilm #tantor #tantor_postgres #postgresql #жизненный_цикл #жизненный_цикл_данных

transp_anon – динамическое маскирование через Access Methods в PostgreSQL

Enterprise-разработка рано или поздно сталкивается с классической задачей: нужно выдать доступ к БД аналитикам, тестировщикам или саппорту в проде, но при этом необходимо скрыть персональные данные или коммерческую тайну. Статическое маскирование отлично подходит для случаев, когда таблица копируется полностью, но что если “замаскировать” нужно просто результат какого-либо запроса? Здесь пригодится маскирование динамическое , и в этой статье мы рассказываем об инструменте transp_anon , который входит в новый релиз СУБД Tantor Postgres 18.

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

#tantor #tantor_postgres #динамическое_маскирование #информационная_безопасность

transp_anon – динамическое маскирование через Access Methods в PostgreSQL

Enterprise-разработка рано или поздно сталкивается с классической задачей: нужно выдать доступ к БД аналитикам, тестировщикам или саппорту в проде, но при этом необходимо скрыть персональные данные или коммерческую тайну. Статическое маскирование отлично подходит для случаев, когда таблица копируется полностью, но что если “замаскировать” нужно просто результат какого-либо запроса? Здесь пригодится маскирование динамическое , и в этой статье мы рассказываем об инструменте transp_anon , который входит в новый релиз СУБД Tantor Postgres 18.

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

#tantor #tantor_postgres #динамическое_маскирование #информационная_безопасность

transp_anon – динамическое маскирование через Access Methods в PostgreSQL

Enterprise-разработка рано или поздно сталкивается с классической задачей: нужно выдать доступ к БД аналитикам, тестировщикам или саппорту в проде, но при этом необходимо скрыть персональные данные или коммерческую тайну. Статическое маскирование отлично подходит для случаев, когда таблица копируется полностью, но что если “замаскировать” нужно просто результат какого-либо запроса? Здесь пригодится маскирование динамическое , и в этой статье мы рассказываем об инструменте transp_anon , который входит в новый релиз СУБД Tantor Postgres 18.

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

#tantor #tantor_postgres #динамическое_маскирование #информационная_безопасность

PostgreSQL и аналитика: что меняется, когда хранилище становится общим

HTAP — одна из главных тем в мире СУБД. Вокруг PostgreSQL массово появляются конструкции с внешними аналитическими движками со своими моделями хранения данных и ограничениями совместимости, однако бизнесу не совсем комфортно жить в архитектуре, где транзакционные данные находятся в одной системе, аналитика - в другой, а между ними - разного рода ETL, CDC и прочие parquet-файлы. В Tantor мы движемся по иному пути, развивая HTAP внутри PostgreSQL, а не рядом с ним. Вокруг этой идеи строятся СУБД Tantor Polar и машина баз данных Tantor XData Gen3, в которой OLTP и аналитика, не теряя совместимости с Postgres, работают поверх общего хранилища данных и общей видимости транзакций. В этой статье хочется поговорить не столько о самом термине HTAP, сколько о том, как меняется архитектура PostgreSQL, когда OLTP и аналитика начинают работать поверх общего хранилища данных.

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

#tantor #tantor_postgres #xdata #tantor_xdata #oracle_exadata #duckdb #greenplum #kafka #clickhouse

PostgreSQL и аналитика: что меняется, когда хранилище становится общим

HTAP — одна из главных тем в мире СУБД. Вокруг PostgreSQL массово появляются конструкции с внешними аналитическими движками со своими моделями хранения данных и ограничениями совместимости, однако бизнесу не совсем комфортно жить в архитектуре, где транзакционные данные находятся в одной системе, аналитика - в другой, а между ними - разного рода ETL, CDC и прочие parquet-файлы. В Tantor мы движемся по иному пути, развивая HTAP внутри PostgreSQL, а не рядом с ним. Вокруг этой идеи строятся СУБД Tantor Polar и машина баз данных Tantor XData Gen3, в которой OLTP и аналитика, не теряя совместимости с Postgres, работают поверх общего хранилища данных и общей видимости транзакций. В этой статье хочется поговорить не столько о самом термине HTAP, сколько о том, как меняется архитектура PostgreSQL, когда OLTP и аналитика начинают работать поверх общего хранилища данных.

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

#tantor #tantor_postgres #xdata #tantor_xdata #oracle_exadata #duckdb #greenplum #kafka #clickhouse

PostgreSQL и аналитика: что меняется, когда хранилище становится общим

HTAP — одна из главных тем в мире СУБД. Вокруг PostgreSQL массово появляются конструкции с внешними аналитическими движками со своими моделями хранения данных и ограничениями совместимости, однако бизнесу не совсем комфортно жить в архитектуре, где транзакционные данные находятся в одной системе, аналитика - в другой, а между ними - разного рода ETL, CDC и прочие parquet-файлы. В Tantor мы движемся по иному пути, развивая HTAP внутри PostgreSQL, а не рядом с ним. Вокруг этой идеи строятся СУБД Tantor Polar и машина баз данных Tantor XData Gen3, в которой OLTP и аналитика, не теряя совместимости с Postgres, работают поверх общего хранилища данных и общей видимости транзакций. В этой статье хочется поговорить не столько о самом термине HTAP, сколько о том, как меняется архитектура PostgreSQL, когда OLTP и аналитика начинают работать поверх общего хранилища данных.

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

#tantor #tantor_postgres #xdata #tantor_xdata #oracle_exadata #duckdb #greenplum #kafka #clickhouse

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

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

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

#postgresql #postgres #tantor #tantor_postgres #1c

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

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

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

#postgresql #postgres #tantor #tantor_postgres #1c

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

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

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

#postgresql #postgres #tantor #tantor_postgres #1c

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

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

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

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 Certified 17

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

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

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

От неизвестной схемы до защищённой БД: полный цикл защиты данных в 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

МБД 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

МБД 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с

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

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

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

#postgresql #postgres #tantor #tantor_postgres #1с

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

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

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

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

#postgresql #postgres #tantor #tantor_postgres #1c

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

[Перевод] Ускорение планирования 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

[Перевод] Ускорение планирования 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

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

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

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

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

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

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

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

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

#postgresql #tantor #tantor_postgres

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

Когда имеется несколько индексов с одинаковыми ведущими столбцами, иногда выбирается не лучший индекс, и время выполнения запроса увеличивается на порядки. Такие ситуации встречаются в сложных приложениях, но чаще всего в 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

Работа с временными таблицами в 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

Работа с временными таблицами в 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

pg_dphyp: учим PostgreSQL соединять таблицы по-другому

Большая часть времени планировщика запросов в СУБД тратится на поиск оптимального способа соединения таблиц. В PostgreSQL используется два алгоритма: алгоритм динамического программирования, также называемый DPsize, и генетический — GEQO. В других СУБД реализовано еще множество других алгоритмов. DPhyp — алгоритм соединения на основе гиперграфов — уже используется такими СУБД как MySQL и YDB. Я задался вопросом: можно ли реализовать его в PostgreSQL? Оказывается, можно. Так и зародилось расширение pg_dphyp для PostgreSQL, реализующее альтернативный алгоритм соединения таблиц. В статье я не описываю подробно сам алгоритм, привожу только концептуальное описание его идеи, а рассказываю вот о чем: -- Какие решения пришлось принять, чтобы добавить алгоритм DPhyp в существующую кодовую базу без изменения ядра; -- Как GPLv2 помог найти эффективный алгоритм обхода соседей; -- Как проиндексировали неиндексируемое гиперрёбра; -- Планирование какого запроса смогли ускорить в 600 раз ; -- Какой изъян в работе существующего планировщика был найден. Но главный сюжетный поворот — в конце...

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

#postgresql #планировщик #dpsize #dphyp #postgres #tantor

pg_dphyp: учим PostgreSQL соединять таблицы по-другому

Большая часть времени планировщика запросов в СУБД тратится на поиск оптимального способа соединения таблиц. В PostgreSQL используется два алгоритма: алгоритм динамического программирования, также называемый DPsize, и генетический — GEQO. В других СУБД реализовано еще множество других алгоритмов. DPhyp — алгоритм соединения на основе гиперграфов — уже используется такими СУБД как MySQL и YDB. Я задался вопросом: можно ли реализовать его в PostgreSQL? Оказывается, можно. Так и зародилось расширение pg_dphyp для PostgreSQL, реализующее альтернативный алгоритм соединения таблиц. В статье я не описываю подробно сам алгоритм, привожу только концептуальное описание его идеи, а рассказываю вот о чем: -- Какие решения пришлось принять, чтобы добавить алгоритм DPhyp в существующую кодовую базу без изменения ядра; -- Как GPLv2 помог найти эффективный алгоритм обхода соседей; -- Как проиндексировали неиндексируемое гиперрёбра; -- Планирование какого запроса смогли ускорить в 600 раз ; -- Какой изъян в работе существующего планировщика был найден. Но главный сюжетный поворот — в конце...

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

#postgresql #планировщик #dpsize #dphyp #postgres #tantor