Эти риски справедливы и игнорировать их точно нельзя. Но я бы не стал называть их минусами. Скорее - это зоны, требующие внимания при внедрении. В статье как раз про это.
Ключевой момент - постановка задачи (ТЗ). Если дату обрезки выбирать формально, например просто потому что «так отрежется 50% объема», то да, можно получить неприятные последствия: потерю части аналитик, проблемы с отчетностью и недовольство пользователей. Но если заранее проанализировать все сценарии, обсудить с бизнесом реальные потребности в исторических данных и не ограничиваться только взглядом разработчиков, то амнезии не будет. Это вопрос подготовки, процесса, а не самой обрезки.
Проблема требуемой глубины данных, которая иногда выходит за дату обрезки, тоже решаема. Например, через постоянно обновляемую архивную копию, располагаемой на отдельной реплике или даже на нескольких репликах под разные классы задач. DB Replication как раз позволяет выстроить такую архитектуру, работает на любых объемах и не влияет производительность.
Что касается “для составления 5% отчетов приходится заходить в 5 БД”, то с помощью ручных перенаправлений и DB Replication этот риск также может быть закрыт.
Кстати, а с каким объемом данных вы работали, когда столкнулись с этими проблемами? Просто интересно, на каком масштабе эти риски становятся критичными.
А как вы тестовый запрос выполняли, например: из IDE (pgadmin) или откуда-то из 1C?
Тут не нужно путать моделирование и разбор конкретной ситуации в продуктивной базе. Тестовый запрос выполнялся из psql. Никакого 1С на стенде нет, только голый PG. Можете повторить у себя.
Еще заметил, что количество подключений у вас доходит до 700…
Это не у нас, а у заказчика в проде.
Используете ли вы калькулятор для расчета work_mem под такое количество соединений и объем доступной памяти?
К эксперименту и статье это отношения не имеет. А для расчета в реальной системе мы используем свою методику из расчета реального профиля нагрузки, но калькулятор, конечно, можно использовать для старта. Ссылку на методику не раз давал выше: PostgreSQL — особенности работы с памятью для 1С-систем. Часть 2
Первая мысль у нас тоже была - "сравнить настройки". Эту работу, естественно, провели, но в статье не упоминал об этом. Не нашлось таких параметров, которые бы давали ответ внятный о причинах.
APDEX - это хорошо. Особенно за неимением ничего другого. Но это бизнес критичные операции. К тому же внутри операции - множество разных запросов. А важно оценивать степень влияния конкретных запросов, которые подверглись параллелизму. Противоречий нет, нужно заходить на задачу со всех сторон.
Дополню мысль. Если в MS SQL собирать информацию по CXPacket в разрезе каждого запроса, то можно без риска работать с параллелизмом. (см. первую статью). В то же время, рекомендация от 1С понятна – бОльшая часть инсталляций 1С MS SQL не имеет мониторинга производительности, соответственно нет четкого понимания что улучшилось или ухудшилось из-за параллелизма. Для этой категории клиентов настройка MAXDOP =1 , возможно, не так плохо.
Да верно, хорошее замечание. Дело в том, что статья показывает принципы работы с параллелизмом в 1С+PG. Мы знаем, что вы в Танторе и другие вендоры работают над возможностью использования параллелизма запросов с временными таблицами. И, наверняка, в ближайшее время это будет реализовано.
Те. Раньше на одном mssql было 10 бд 1с, стало 10 серверов с одной бд 1с.
Использование виртуальных машин очень помогает оптимизировать использование ресурсов. К тому же, вам не обязательно идти по этому пути.
Что касается "для галочки/не для галочки", то цели перехода у всех разные. Кто-то это делает в добровольно-принудительном порядке, кто-то по иным причинам.
Цель статьи не в этом. Мы хотели показать, что, во-первых, перейти можно без рисков прерывания пользовательской работы и простоев системы, а, во-вторых, производительность системы будет не хуже, чем была на MS.
Да, в моменте количество требуемых аппаратных ресурсов удвоилось. Это не считая различных тестовых контуров. Но здесь не про экономию ресурсов. Здесь про то, что предприятие ни в коем случае не должно останавливаться по причине неработающей ИТ-системы.
Сейчас, спустя несколько месяцев суммарные аппаратные мощности примерно соответствуют тем же, что были на MS. Примерно, потому что теперь каждый сервер PG - это отдельный инстанс, а ранее на одном инстансе MS могли крутиться одновременно несколько БД. Но если у вас одна БД, то можно сказать, что аппаратные ресурсы по итогам могут остаться такими же.
Здесь необходимо придерживаться следующего сценария. Сразу после перехода потребление ресурсов на СУБД возрастет (особенно по памяти). Необходимо об этом помнить и обязательно иметь на сервере PG запас по памяти, дискам и CPU. Далее идет период тюнинга (несколько недель) - читаем цикл наших статей про память. Универсальных настроек, подходящих всем, нет! Поэтому хорошо бы иметь инструментарий и компетенции, чтобы не работать с PG как с черным ящиком. После тюнинга СУБД, запросов, индексов эффективность использования памяти и др. ресурсов выходит на уровень не хуже MS и избыточные ресурсы можно убрать. В этом мы убедились уже на нескольких проектах.
Вы меня спрашиваете нужно ли вам пересчитывать индексы каждую ночь? Понятия не имею. Вся статья - это ответ на ваш вопрос. Периодичность выбирается эмпирически, на основании собранной статистики по размерам индексов и степени фрагментации.
Не планировал рассказывать про разницу между Reorganize и Rebuild. Это не совсем в тематике данной статьи. Информации в интернете много. Кому нужно, найдет.
Кратко. Мы в своих скриптах не используем Reorganize, т.к. работаем преимущественно с высоконагруженными БД и там это не эффективно. Основные недостатки перед Rebuild: не обновляет статистику, не может изменить параметры индекса (например, тот же FILLFACTOR), не освобождает пустые страницы, медленнее работает с большими индексами, не справляется с высокой фрагментацией (>30).
Прямых настроек fill factor для базы как бы нет, но при обслуживании конкретной базы в скрипте, перебирающем все/определенные индексы, можно указать параметр для ALTER INDEX .... REBUILD WITH (FILLFACTOR = 85)
fill factor настраивается не для 1С. Можно настроить целиком для всего сервера MS SQL и/или для каждого индекса в отдельности. Для всего сервера можете воспользоваться, например, вот таким скриптом.
-- Изменение на уровне сервера
sp_configure 'show advanced options', 1
reconfigure with override
go
sp_configure 'fill factor', 90 -- Установка Fill Factor = 90%
reconfigure with override
go
После очередного перестроения индекса(ов) степень их заполнения поменяется на 90%.
Эти риски справедливы и игнорировать их точно нельзя. Но я бы не стал называть их минусами. Скорее - это зоны, требующие внимания при внедрении. В статье как раз про это.
Ключевой момент - постановка задачи (ТЗ). Если дату обрезки выбирать формально, например просто потому что «так отрежется 50% объема», то да, можно получить неприятные последствия: потерю части аналитик, проблемы с отчетностью и недовольство пользователей. Но если заранее проанализировать все сценарии, обсудить с бизнесом реальные потребности в исторических данных и не ограничиваться только взглядом разработчиков, то амнезии не будет. Это вопрос подготовки, процесса, а не самой обрезки.
Проблема требуемой глубины данных, которая иногда выходит за дату обрезки, тоже решаема. Например, через постоянно обновляемую архивную копию, располагаемой на отдельной реплике или даже на нескольких репликах под разные классы задач. DB Replication как раз позволяет выстроить такую архитектуру, работает на любых объемах и не влияет производительность.
Что касается “для составления 5% отчетов приходится заходить в 5 БД”, то с помощью ручных перенаправлений и DB Replication этот риск также может быть закрыт.
Кстати, а с каким объемом данных вы работали, когда столкнулись с этими проблемами? Просто интересно, на каком масштабе эти риски становятся критичными.
Тут не нужно путать моделирование и разбор конкретной ситуации в продуктивной базе. Тестовый запрос выполнялся из psql. Никакого 1С на стенде нет, только голый PG. Можете повторить у себя.
Это не у нас, а у заказчика в проде.
К эксперименту и статье это отношения не имеет. А для расчета в реальной системе мы используем свою методику из расчета реального профиля нагрузки, но калькулятор, конечно, можно использовать для старта. Ссылку на методику не раз давал выше: PostgreSQL — особенности работы с памятью для 1С-систем. Часть 2
Первая мысль у нас тоже была - "сравнить настройки". Эту работу, естественно, провели, но в статье не упоминал об этом. Не нашлось таких параметров, которые бы давали ответ внятный о причинах.
Вы имеете в виду, что ИИ заменит оптимизаторов/разработчиков/программистов 1С? Ну... время покажет.
APDEX - это хорошо. Особенно за неимением ничего другого. Но это бизнес критичные операции. К тому же внутри операции - множество разных запросов. А важно оценивать степень влияния конкретных запросов, которые подверглись параллелизму. Противоречий нет, нужно заходить на задачу со всех сторон.
Дополню мысль.
Если в MS SQL собирать информацию по CXPacket в разрезе каждого запроса, то можно без риска работать с параллелизмом. (см. первую статью). В то же время, рекомендация от 1С понятна – бОльшая часть инсталляций 1С MS SQL не имеет мониторинга производительности, соответственно нет четкого понимания что улучшилось или ухудшилось из-за параллелизма. Для этой категории клиентов настройка MAXDOP =1 , возможно, не так плохо.
Тем не менее, эта рекомендация есть на ИТС, и многие ею продолжают пользоваться. А наше видение и подходы мы описали.
Да верно, хорошее замечание. Дело в том, что статья показывает принципы работы с параллелизмом в 1С+PG. Мы знаем, что вы в Танторе и другие вендоры работают над возможностью использования параллелизма запросов с временными таблицами. И, наверняка, в ближайшее время это будет реализовано.
Использование виртуальных машин очень помогает оптимизировать использование ресурсов. К тому же, вам не обязательно идти по этому пути.
Что касается "для галочки/не для галочки", то цели перехода у всех разные. Кто-то это делает в добровольно-принудительном порядке, кто-то по иным причинам.
Цель статьи не в этом. Мы хотели показать, что, во-первых, перейти можно без рисков прерывания пользовательской работы и простоев системы, а, во-вторых, производительность системы будет не хуже, чем была на MS.
Да, в моменте количество требуемых аппаратных ресурсов удвоилось. Это не считая различных тестовых контуров. Но здесь не про экономию ресурсов. Здесь про то, что предприятие ни в коем случае не должно останавливаться по причине неработающей ИТ-системы.
По срокам сделал вставки в тексте.
Второе - отдельный инстанс на отдельном сервере (виртуальном).
Сейчас, спустя несколько месяцев суммарные аппаратные мощности примерно соответствуют тем же, что были на MS. Примерно, потому что теперь каждый сервер PG - это отдельный инстанс, а ранее на одном инстансе MS могли крутиться одновременно несколько БД. Но если у вас одна БД, то можно сказать, что аппаратные ресурсы по итогам могут остаться такими же.
Здесь необходимо придерживаться следующего сценария. Сразу после перехода потребление ресурсов на СУБД возрастет (особенно по памяти). Необходимо об этом помнить и обязательно иметь на сервере PG запас по памяти, дискам и CPU. Далее идет период тюнинга (несколько недель) - читаем цикл наших статей про память. Универсальных настроек, подходящих всем, нет! Поэтому хорошо бы иметь инструментарий и компетенции, чтобы не работать с PG как с черным ящиком.
После тюнинга СУБД, запросов, индексов эффективность использования памяти и др. ресурсов выходит на уровень не хуже MS и избыточные ресурсы можно убрать. В этом мы убедились уже на нескольких проектах.
В рамках проекта импортозамещения ПО.
Вы меня спрашиваете нужно ли вам пересчитывать индексы каждую ночь? Понятия не имею.
Вся статья - это ответ на ваш вопрос. Периодичность выбирается эмпирически, на основании собранной статистики по размерам индексов и степени фрагментации.
Да, думаю, вы правы.
По просьбам подписчиков дополнил п.5 выводов.
Не планировал рассказывать про разницу между Reorganize и Rebuild. Это не совсем в тематике данной статьи. Информации в интернете много. Кому нужно, найдет.
Кратко. Мы в своих скриптах не используем Reorganize, т.к. работаем преимущественно с высоконагруженными БД и там это не эффективно. Основные недостатки перед Rebuild:
не обновляет статистику, не может изменить параметры индекса (например, тот же FILLFACTOR), не освобождает пустые страницы, медленнее работает с большими индексами, не справляется с высокой фрагментацией (>30).
Прямых настроек fill factor для базы как бы нет, но при обслуживании конкретной базы в скрипте, перебирающем все/определенные индексы, можно указать параметр для ALTER INDEX .... REBUILD WITH (FILLFACTOR = 85)
Ну а вы как думаете? Индексов в DT нет, значит они будут созданы с тем fill factor, что указан глобально.
fill factor настраивается не для 1С. Можно настроить целиком для всего сервера MS SQL и/или для каждого индекса в отдельности.
Для всего сервера можете воспользоваться, например, вот таким скриптом.
После очередного перестроения индекса(ов) степень их заполнения поменяется на 90%.
Как база - хороший вариант.