Настоящий краудфандинг. Даешь сравнение двух СУБД!

25.03.23

База данных - Администрирование СУБД

Первый вариант сравнения двух СУБД. Каждый может внести правку и получить SM. Приветствуются конструктивные комментарии, начинающиеся словами "Автор ничего не понимает".

Настоящий краудфандинг. Даешь сравнение двух СУБД !

 

Предисловие

Как можно сравнить архитектуру MS SQL и PostgreSQL?. Постепенно пришло понимание, что такое сравнение можно создать коллективным трудом на нашей любимой площадке. Ниже первый вариант статьи. Всех желающих участвовать ожидает sm-вознаграждение. Предложения по статье присылайте в личку или в комментарии.

Правила разработки статьи

Максимально сокращаем текст, выбираем только существенные черты. Не используем копирование источников, пишем своими словами. Не обсуждаем архитектурные решения, которые:

  • применяются редко, опционально. Примером таких решений (на мой взгляд) могут быть buffer pool extension (ms), cache prewarm (pg), blockchain extension (pg).
  • недоступны типовыми средствами 1С. Например, платформа 1С не использует некоторые типы индексов

Если Вы не согласны – давайте обсудим.

Каждое утверждение оформляем в отдельный абзац, после которого указываем различия между СУБД и ссылки на первоисточники. Первоисточники – документация и блоги разработчиков. Без первоисточников статья не имеет ценности.

Соглашение о терминах и сокращениях

  • Диск = Энергонезависимая память (СХД, HHD, SSD, RAID)
  • Память = Оперативная память, RAM
  • PG= PostgreSql
  • MS = MS SQL
  • SR = SERIALIZABLE
  • RR = REPEATABLE READ
  • RC = READ COMMITTED
  • RCSI = READ COMMITTED SNAPSHOT ISOLATION
  • RUnC = READ UNCOMMITTED

Таблицы

[ Логические таблицы могут состоять из нескольких файлов. Файлы на физическом уровне состоят из страниц. Размер страницы обычно 8 кб. ]

[ PG Таблица содержит несколько версий данных, с указанием диапазона транзакций, в которых данные актуальны. ]

[ MS Файл данных имеет расширение mdf. 8 страниц объединяются в экстенты 64 кб, размер экстента должен совпадать с размером физической страницы диска. ]

Индексы

[ Один из типов – btree. Индекс физическом уровне держится в страницах. Нижние страницы указывают на содержимое таблицы, внутренние – на дочерние страницы. Из одной страницы может быть много ссылок. Кроме ссылок в страницах индекса содержатся ключи данных. Страницы индексов на диске должны располагаться удобно для последовательного чтения. Нарушение последовательности, вызванное добавлением страниц - внешняя фрагментация. Чрезмерное свободное место на странице - внутренняя фрагментация. При чтении из индекса, получаем упорядоченные данные. ]

MS Нижний слой кластерного индекса - исходная таблица. ]

[ PG Нижний слой кластерного индекса – указатели на исходную таблицу. Поскольку в таблице содержится несколько версий данных, для получения актуальной версии требуется дополнительная информация. ]

см. также https://its.1c.ru/db/metod8dev/content/1590/hdoc

Статистика

 [ Для выбора лучшего плана запроса используется дополнительная информация:

  • Гистограмма распределения количества строк по ключевым столбцам индекса. Обычно содержит 100-200 интервалов. Приблизительное количество строк в таблице.
  • Данные о зависимости между столбцами.
  • Данные о избирательности (плотности) индекса – количество различных значений.

Для временных таблиц обязательно создается временная статистика. При создании индекса статистика пересчитывается. Дефрагментация индекса не изменяет распределение данных. Обновление статистики может вызвать перекомпиляцию запросов. ]

MS На уровне базы данных предусмотрены параметры: AUTO_UPDATE_STATISTICS обновлять статистику перед запросом, при необходимости, в зависимости от количества (процента) измененных строк, количества строк в таблице. AUTO_UPDATE_STATISTICS_ASYNC запрос выполняется без обновления статистики, даже если статистика устарела, но СУБД пытается восстановить статистику перед следующим выполнением запроса. СУБД может создавать дополнительную статистику, если установлено AUTO_CREATE_STATISTICS.

Пересчет статистики выполняется по приблизительной схеме, если не указать FULLSCAN. Статистику можно обновлять после регламентных операций, связанных с изменением большого количества строк. Для просмотра DBCC SHOW_STATISTICS. ]

PG Значения статистики автоматически обновляются командами VACUUM, ANALYZE. Параметры обновления в файле postgresql.conf. Для просмотра pg_stats. ]

Буферный кеш

[ Чтобы уменьшить количество операций чтения-записи к диску, страницы СУБД предварительно считывают с диска в память, измененные (грязные) страницы записывают обратно, когда будет удобно. Физическим чтением называется считывание страниц с диска, логическим – чтение страниц буферного кеша. Если в кеше недостаточно места, (невостребованные) данные вытесняются, заменяются другими. Временные таблицы в буферном кеще не хранятся: их не нужно восстанавливать после сбоя. ]

[ MS Показатели представления sys.dm_os_performance_counters, perfmon.exe:

  • Коэффициент попадания в буферный кэш (Buffer cache hit ratio)
  • Ожидаемый срок жизни страницы (Page life expectancy) ]

[ PG Размер устанавливается параметром shared_buffers. Есть рекомендация выделять 1/4 памяти. Расширение для наблюдения: pg_buffercache]

 Контрольная точка

[ Процесс, записывающий все «грязные» страницы в базу данных. Необходим для целей восстановления. Когда все изменения содержатся в базе данных на диске - это более устойчивое положение. Процесс восстановления на основании контрольной точки запускается автоматически при старте СУБД, если начальное состояние не совпадает с контрольной точкой. Контрольная точка может выполняться по плану в зависимости от условий, при завершении работы СУБД или создании резервной копии, вручную. Длительные незафиксированные транзакции препятствуют созданию контрольных точек.

Условия создания контрольных точек отличаются в (pg) и (ms), аргументами могут быть: время между точками, количество «грязных» страниц в буфере, и т.д. ]

[ MS  Параметр, влияющий на расписание recovery interval. После MS2012 между двумя контрольными точками для уменьшения количества "грязных" страниц запускается "косвенная контрольная точка"]

[ PG Параметр, влияющий на расписание checkpoint_timeout. Между двумя контрольными точками для уменьшения количества "грязных" страниц запускается процесс bgwritter. Статистика работы в представлении pg_stat_bgwriter. Указание на последнюю контрольную точку хранится в файле $PGDATA/global/pg_control ]

Журнал ...

[ В терминах MS - журнал транзакций, в терминах PG - журнал предзаписи, WAL. Итак, «грязные» страницы обрабатываются в памяти и периодически записываются на диск. Если произойдет сбой в памяти, то может потеряться информация после контрольной точки. Чтобы избежать потери, перед записью в базу делаем «запасную» запись в журнал. Временные файлы и временные таблицы записывать в журнал нет смысла.

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

Журнал позволяет выполнять:

  • откат транзакций
  • восстановление незавершенных транзакций при запуске СУБД
  • восстановление состояния СУБД на момент
  • репликацию СУБД;

Сокращать журнал имеет смысл только после выполнения контрольной точки. ]

MS При модели восстановления SIMPLE журнал усекается автоматически при достижении контрольной точки, при модели восстановления FULL или BULK-logged после резервного копирования журнала. ]

[ PG Применяется несколько способов проверки записи WAL: при включенном или отключенном кеше диска, использовать для проверки одну из функций fdatasync, fsync, open. ]

 Уровни изоляции

[ Четыре уровня установлены стандартом SQL92, объявляются при начале транзакции СУБД командой SET TRANSACTION.

Уровень изоляции

Фантомное чтение

Неповторяющееся чтение

«Грязное» чтение

Потерянное обновление

SERIALIZABLE

+

+

+

+

REPEATABLE READ

-

+

+

+

READ COMMITTED

-

-

+

+

READ UNCOMMITTED

-

-

-

+

Подробнее об использовании блокировок платформой 1С смотрите Руководство разработчика пункт 9.3. Механизм управляемых блокировок, управление блокировками.

  • Потерянное обновление: при одновременном изменении остаются последние данные
  • Грязное чтение: чтение данных незавершенных транзакций
  • Неповторяющееся чтение: внутри транзакции, при повторном чтении данных получаются другие значения.
  • Фантомное чтение: Все существующие строки не могут быть изменены. Но добавляются новые строки, которые подходят под условие транзакции.

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

Serializable - Самый высокий уровень изолированности; транзакции полностью изолируются друг от друга. На этом уровне применяются блокировки диапазонов (предикатные блокировки), которых захватывают граничные значения. ]

[ MS RUnC Выполняется запросом с хинтом nolock ]

[ PG RUnC Невозможно стандартными средствами СУБД, только дополнительной утилитой]

[ MS RC Использует блокировки. Перед чтением строки устанавливается блокировка, после чтения – снимается. Возможно раньше окончания транзакции ]

[ MS RCSI Использует мультиверсионность. В транзакции, при первом обращении к данным, происходит снимок данных (Snapshot), который хранится в tempdb (до версии 19)]

[ PG RC Использует мультиверсионность. Все версии данных хранятся в таблицах. Каждая версия содержит интервал номеров транзакций, в которых она актуальна. Неактуальные версии данных очищаются в фоновом режиме заданием vacuum]

[ MS RR При изменении данных параллельными транзакциями происходит ошибка в транзакции, которая начинается последней. Блокировки в разделяющем режиме применяются ко всем данным, считываемым любой инструкцией транзакции, и сохраняются до её завершения. Это запрещает другим транзакциям изменять строки, которые были считаны незавершённой транзакцией. Однако другие транзакции могут вставлять новые строки, соответствующие условиям поиска инструкций, содержащихся в текущей транзакции ]

[ PG RR использует снимок на начало транзакции. более строгое, чем предусматривает стандарт. При изменении данных параллельными транзакциями происходит ошибка в транзакции, которая завершается последней. Допускается параллельная транзакция чтения. Применяются предикатные блокировки, которые могут сниматься после (!) окончания транзакции и укрупняться на уровень таблицы. ]

[ PG SR параллельные транзакции не допускаются. Применяются предикатные блокировки, которые могут быть сняты до или после (!!) транзакции. Блокировки можно видеть в pg_locks. Предикатные блокировки строк могут укрупняться в одну предикатную блокировку уровня таблицы из-за нехватки памяти. ]

Транзакции и блокировки

[ Транзакция - последовательность операторов DML со свойствами:

  • Atomicity — Атомарность
  • Consistency — Перевести базу данных из одного согласованного состояния в другое.
  • Isolation — Параллельные транзакции не должны оказывать влияния.
  • Durability — Стойкость (надежность диска)

Протокол 2PL: установка, снятие. В базовом протоколе используются два типа блокировок: Shared и Exclusive locks.

Неявные транзакции СУБД: создание индекса, реструктуризация базы. В терминах 1С неявные транзакции – например, запись объекта. При чтении объекта с табличной частью в режиме совместимости после 8.2.17 нет неявной транзакции (!).

Блокировка есть информация. При установке блокировки, СУБД проверяет наличие существующей блокировки.

Взаимоблокировки разрешаются фоновым заданием – монитор блокировок. В качестве жертвы взаимоблокировки может быть выбрана: транзакция откат которой потребует меньше всего затрат или по приоритетам или по времени. ]

[ MS  Информация о блокированных строках хранится в оперативной памяти. При большом количестве блокированных строк, для предотвращения большого расхода памяти, происходит укрупнение гранулярности (эскалация) блокировки. ]

[ PG Исключительная блокировка строк RC отражается как версия данных, на той же странице. Нет потребности в эскалации для экономии памяти. Для разделяемых блокировок применяются так называемые мультитранзакции (MultiXact). Это группа транзакций, которой присвоен отдельный номер. Предикатные блокировки в режиме RR могут использовать укрупнение. ]

Вступайте в нашу телеграмм-группу Инфостарт

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Администрирование СУБД Системный администратор Программист Бесплатно (free)

5,5 тысячи пользователей в единой базе 1С, розница в режиме 24/7 и SLA 99,98% – в таких условиях любая авария быстро превращается в очереди на кассах, потерю денег и давление со стороны бизнеса. Показываем, как выстроить процесс аварийно-восстановительных работ: от первых алертов и базового скрининга системы до подключения команды, проверки гипотез и дебрифа после инцидента. Разбираем, как метрики, дашборды, техжурнал, Zabbix, Prometheus, Grafana, Telegram-боты и скрипты помогают не гадать, а быстро находить причину проблемы. На реальных авариях объясняем, почему «быстро» не должно означать «рискованно», как работа над ошибками снижает панику и почему каждая авария может сделать систему надежнее.

11.08.2026    1906    jul.dolganova    8    

22

Администрирование СУБД Пароли Системный администратор 1С 8.3 1С:Розница 2 1С:Управление производственным предприятием Абонемент ($m)

Пароль пользователя СУБД лежит в 1CV8Clst.lst обратимо: кто читает папку srvinfo - достаёт пароли SQL всех баз кластера, минуя права 1С. Обработка показывает, у каких баз пароль извлекается, помечает слабые и выдаёт план защиты. К СУБД не подключается, ничего не пишет - только читает файл.

10 стартмани

06.08.2026    877    13    nedomolkov.ivan    0    

7

Администрирование СУБД Системный администратор 1С 8.3 Бесплатно (free)

Прогнал набор диагностических скриптов на двух рабочих базах: боевой с 580 сеансами и малонагруженной. Разбираю пять находок: статистика 97-дневной давности, 598 запросов со сканами, журнал транзакций в 73 % от данных, tempdb в один файл и 81 % ожиданий на параллелизме, который чинить не надо. Плюс три грабли, из-за которых самописный диагностический скрипт падает на чужом сервере. Семь рабочих скриптов внутри, копируются в SSMS как есть.

05.08.2026    1240    nedomolkov.ivan    8    

8

Администрирование СУБД Журнал регистрации Системный администратор Программист 1С 8.3 Бесплатно (free)

Журнал регистрации на нагруженной базе перестаёт открываться: файлы растут на гигабайты в день, просмотр виснет, история недоступна. Рассказываю, как мы вынесли журнал трёх продуктивных баз в ClickHouse: 35 млрд событий, поиск всех ошибок за сутки — 0,11 секунды, привычная форма журнала для пользователей и падение числа ошибок в проде в 23 раза за полгода. Архитектура, схема таблицы, грабли интеграции и все цифры с прода.

04.08.2026    1508    nedomolkov.ivan    0    

8

Администрирование СУБД 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

База 1С:ERP размером 646 Гб, полное маскирование за 5 часов - без создания промежуточной незащищенной копии. Разбираем бесплатный pg_anon на сквозном примере с реального продуктива.

27.07.2026    2748    Tantor    16    

13

HighLoad оптимизация Администрирование СУБД Программист Россия Бесплатно (free)

Если вы работаете с 1С на PostgreSQL и жалуетесь на тормоза — скорее всего, дело в join predicate pushdown, которого в стандартном PostgreSQL нет. В MS SQL Server этот механизм работает «из коробки», и при миграции именно запросы к виртуальным таблицам 1С бьют по производительности сильнее всего. В этой статье — реальный кейс от Postgres Professional с разбором плана выполнения, ручным экспериментом и доработкой планировщика СУБД, которая ускорила запросы от 22 до 54 000 раз.

16.06.2026    9201    postgres_professional    13    

12

HighLoad оптимизация Администрирование СУБД Системный администратор Программист 1С:Предприятие 8 Бесплатно (free)

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

16.06.2026    3607    Tantor    7    

10

Администрирование СУБД Системный администратор Программист 1С:Предприятие 8 Россия Бесплатно (free)

База 1С за несколько лет эксплуатации разрослась, - стала большой, медленно работает, требует много места и времени для копирования и прочего обслуживания. Нужна ли обязательно свертка или можно обойтись более «мягкими» средствами. Делюсь своим опытном как для новых конфигураций, так и для старых УПП, УТ 10…

01.06.2026    8316    2ncom    30    

11