Комментарии 20
А есть какая-то метрика, хотя бы на уровне ощущений, сколько в среднем попугаев производительности теряется при переходе на Постгре?
Субъективная метрика - размер премии за переход на PostgreSQL.
Объективная метрика - хронометраж типовых действий каждого пользователя.
Иногда эти метрики меняются местами. ;-)
Оценивать в среднем по больнице тут будет неверно. Есть пример, когда в первое время после перехода значительно просела производительность одного-двух функциональных блоков, при этом остальной функционал системы прекрасно работал на том же уровне, что и до миграции. Но PG уже не такой черный ящик как MS SQL и там есть что подкрутить, дописать. В этом его большой плюс. Главное правильно увидеть причину.
Ну то есть нет такого, что при переходе на постгре быстрее точно не будет, будет медленнее, вопрос лишь в том, насколько?
Нужно рассматривать каждый блок или операцию в отдельности, а не всю систему в целом. При этом использовать метрики, позволяющие оценить отдельные операции, отдельные запросы, например, APDEX. И только на основе этого делать какие-то заключения. Субъективное мнение пользователей конечно тоже важно (это не сарказм), но вместе с тем я бы настоятельно рекомендовал сделать замеры по ключевым операциям ДО и ПОСЛЕ, чтобы было к чему апеллировать.
Вот пример распространенной операции (перепроведение) Postgres как предчувствие. Вычисляем процент импортозамещения в режиме Highload от 1С Postgres даже немного выигрывает, за счет большей утилизации проца
Оценивать любую производительность нужно путем эмуляции реальной нагрузки продолжительное время
Можно построить множество теорий, оправдать кеши и прочее, просчитать и т.д, но это синтетические тесты
Отсюда пишем нагрузку рабочую и пускаем ее на часик-два, смотрим время или количество выполнения
Стоит ли говорить, что у каждого своя нагрузка и свои числа "попугаев"
Стоимость владения
Поэтому рассматриваем какие-то коммерческие сборки, но с более гуманным ценником, нежели MS SQL
И какая стоимость владения выходит? Я смотрю на лицензии pgPro, на обязательную доработку нагруженных баз, на снижение производительности (и как компенсацию - более мощное железо, наличие хороших dba). Точно ли выходит "гуманный" ценник? По моим ощущениям - если в ту же стоимость как с ms sql уложимся, то уже хорошо.
В статье не раскрыт процесс переноса бизнес логики, это вообще возможно или весь функционал на уровне СУБД предлагается переписывать под реальности PG?
Если вы имеете в виду системы на платформе 1С 8, то там функционал реализован на уровне приложения. Для них функционал на уровне СУБД - это скорее исключительная ситуация и его доля будет незначительной. Поэтому про бизнес-логику речь не идет вообще.
А так-то да. Всё что написано на уровне MS SQL нужно правильно сконвертировать на PG.
То есть сформулируем первые два нюанса, о которых надо помнить и обязательно прорабатывать сценарии решения:
Переход пользователей без остановки или с минимально-допустимой остановкой системы.
Сценарии отката пользователей на старую систему в случае форс-мажоров. Здесь нужно заложиться на допустимое время простоя системы, возможную синхронизацию данных из «новой системы» обратно в «старую» или же смириться с их потерями в случае принятия решения об откате.
Для решения этих двух вопросов мы рекомендуем нашу технологию репликации DBReplication, которая обеспечивает обмен и синхронизацию данных между разными СУБД MS SQL и PG.
И как запускается этот процесс репликации? ведь для того чтобы запустить репликацию в базе которая 24х7 и
и нет даже намека на технологические окна
нужно получить копию в формате другой СУБД. Например - при переходе с MS SQL нужно сделать копию в формате Postgres.
Допустим Вы быстро получили бэкап MS SQL до нужной точки восстановления или репликой в MS SQL .
Если перекидывать это через Dt то я посчитал - у меня получилось где-то сутки для базы 1.7 терабайт в MS SQL, без пересчета итогов.
Как великану из страны 1С пересесть на слона?
т.е. отставание двое суток с накладными расходами. И сколько будет эта DBReplication догонять целевую копию? Если база реально большая то несколько перепроведений могут создать объем равный трети ИБ (это же изменения)
Есть практические метрики - объем, сколько догоняли, сколько держали мораторий на изменение метаданных?
P S Недавно заработал вариант через автономный сервер - тестировали?
Если перекидывать это через Dt то я посчитал - у меня получилось где-то сутки для базы 1.7 терабайт в MS SQL, без пересчета итогов.
Вся прелесть использования дальнейшей репликации – это некритичность к отставанию получившейся базы PG от продуктива MSSQL. Двое суток, трое или пять – неважно. Очереди прокачаются. Не мгновенно, но PG догонит MSSQL.
Вопрос «сколько времени DBReplication будет догонять продуктивную базу» конечно правомерен. Тут четкие цифры дать трудно. Зависит от специфики и состава транзакций в конкретной ИС, от производительности оборудования на стороне сервера PG, где обрабатывается и применяется входящая очередь, от особенностей структуры некоторых таблиц 1С и их индексов и распределения данных по ним.
Поэтому в разных случаях скорость прокачки одного и того же объёма изменений может отличаться довольно сильно - в 2-3 раза и более. Здесь можем апеллировать только к конкретным примерам. Например, в нашей практике за 5 суток был синхронизирован объем изменений 1 ТБ.
Таким образом, «держать мораторий» не требуется. Через несколько часов или дней (у кого как) базы будут полностью синхронизированы и можно просто переключить пользователей на другую БД.
Здесь можем апеллировать только к конкретным примерам. Например, в нашей практике за 5 суток был синхронизирован объем изменений 1 ТБ.
как понимаю, при таких показателях изменения накатываются последовательно в одну очередь (видимо для сохранения целостности) с какой то сериализацией?
Как Вы синхронизируете Lob обьекты ? по ним же нет открытых форматов
Это транзакционная репликация, целостность и консистентность данных в баз-получателе, конечно, обеспечивается. Накатывание очереди может осуществлять как в один поток, так и многопоточно.
Lob-значения, хранящиеся в таблицах 1С, мы успешно передаём. Причем в некоторых системах LOB-трафик занимает очень большую часть всего репликационного трафика.
Самая веселая часть такого перехода, что в PostgreSQL очень тупой оптимизатор. Например он не поддерживает Predicate Push Down:
https://habr.com/ru/companies/lsfusion/articles/463095/#jppd
А MS SQL поддерживает (пусть и не до конца).
При этом тот же 1С (в отличии скажем от lsFusion) Predicate Push Down тоже не поддерживает:
https://habr.com/ru/companies/lsfusion/articles/468415/#opt
Соответственно, если вы изначально писали запросы под MS SQL, переехав на PostgreSQL, у вас даже самые простые запросы могут начать сваливаться в пробег по всей базе, со всеми вытекающими.
И это только Predicate Push Down. У Postgres'а еще очень много веселых косяков с неправильной статистикой в подзапросах, с cross-column статистикой. У MS SQL все с этим куда получше. Конечно с этим можно было бы бороться, делая "материализацию подзапросов" на лету (как это делает тот же lsFusion), но 1С так тоже не умеет.
В общем это все конечно хорошо, но такой переезд если у вас чуть более сложное приложение чем CRUD, может потребовать переписывания огромного числа запросов (если конечно удастся их найти, с учетом того что в этого время база будет лежать, а пользователи ныть).
Например он не поддерживает Predicate Push Down:
Автор по ссылке все же лукавит. PostgreSQL не поддерживает JPPD для агрегированных подзапросов. Но если агрегацию вынести из подзапроса, то JPPD поддерживается:
EXPLAIN ANALYZE
SELECT SUM(income.quantity)
FROM product
JOIN (
SELECT product, quantity
FROM shipmentDetail
JOIN shipment ON shipmentDetail.shipment = shipment.id
) income ON income.product = product.id
WHERE product."group" = 54
GROUP BY product.id;
План запроса
HashAggregate (cost=12263.04..12263.59 rows=44 width=36) (actual time=30.452..30.473 rows=42 loops=1)
Group Key: product.id
Batches: 1 Memory Usage: 48kB
-> Nested Loop (cost=2.46..12219.04 rows=8800 width=9) (actual time=0.064..28.851 rows=8329 loops=1)
-> Nested Loop (cost=2.17..9490.77 rows=8800 width=13) (actual time=0.058..16.214 rows=8329 loops=1)
-> Bitmap Heap Scan on product (cost=1.73..46.96 rows=44 width=4) (actual time=0.041..0.159 rows=42 loops=1)
Recheck Cond: ("group" = 54)
Heap Blocks: exact=38
-> Bitmap Index Scan on product_group (cost=0.00..1.72 rows=44 width=0) (actual time=0.032..0.033 rows=42 loops=1)
Index Cond: ("group" = 54)
-> Index Scan using shipmentdetail_product_fk on shipmentdetail (cost=0.43..212.63 rows=200 width=13) (actual time=0.008..0.361 rows=198 loops=42)
Index Cond: (product = product.id)
-> Index Only Scan using shipment_pkey on shipment (cost=0.29..0.31 rows=1 width=4) (actual time=0.001..0.001 rows=1 loops=8329)
Index Cond: (id = shipmentdetail.shipment)
Heap Fetches: 0
Planning Time: 0.443 ms
Execution Time: 30.523 msСоответственно, если вы изначально писали запросы под MS SQL, переехав на PostgreSQL, у вас даже самые простые запросы могут начать сваливаться в пробег по всей базе, со всеми вытекающими.
Это разные СУБД. Для примера, с одной стороны у PostgreSQL есть DISTINCT ON и нужно избавляться от лишних CTE с ROW_NUMBER() OVER (,,,), а с другой стороны, агрегированные подзапросы нужно конвертировать в LATERAL.
Автор по ссылке все же лукавит. PostgreSQL не поддерживает JPPD для агрегированных подзапросов. Но если агрегацию вынести из подзапроса, то JPPD поддерживается:
Не понятно какое отношение это имеет к predicate push down. Тут же просто инлайнится запрос, так как вы по сути его руками переписали (и это можно сделать только в очень ограниченных случаях, скажем, что будет если у вас будет два подзапроса, если LEFT JOIN идет с подзапросом и т.п.)
Это разные СУБД. Для примера, с одной стороны у PostgreSQL есть DISTINCT ON и нужно избавляться от лишних CTE с ROW_NUMBER() OVER (,,,), а с другой стороны, агрегированные подзапросы нужно конвертировать в LATERAL.
Так о том и речь. Что 1С просто транслятор в синтаксис СУБД, поэтому переезд между СУБД, это не просто мигрировал данные из одной в другую. Это может быть переписывание огромного числа запросов. Кстати LATERAL ЕМНИП он вообще не поддерживает.
Поэтому кстати часто бывает, что когда продают некоторые решения на 1С говорят, хотите PostgreSQL - конечно поставим. А потом на практике оказывается, что они под PostgreSQL нифига не работают.
вы по сути его руками переписали
Я просто вынес GROUP BY из подзапроса.
что будет если у вас будет два подзапроса
Без понятия, что Вы имеете в виду. Давайте запрос - тогда отвечу.
Кстати LATERAL ЕМНИП он вообще не поддерживает.
Это уже претензии к платформе, которая на MS SQL CROSS/OUTER APPLY поддерживает, а прямой аналог этой конструкции на PostgreSQL - почему-то нет. Хотя, конечно, хотелось бы пруфов.
Миграция с MSSQL Server на PostgreSQL. Предпосылки