Сервер 1С файловый или SQL: что выбрать и в чем разница

Главное (TL;DR):

• Выбор способа размещения зависит от объёма информационной системы, характера операций, количества одновременно работающих сотрудников и требований к скорости.
• Файловый режим проще в развёртывании и сопровождении. Для небольших рабочих групп этого обычно достаточно.
• Вариант с СУБД лучше масштабируется, когда растёт число параллельных операций, фоновых заданий и интеграций.
• Переезд на SQL не гарантирует ускорения. Причиной задержек могут быть процессор, накопители, нехватка памяти, настройки ПО или код конфигурации.

Недостатки выбранной схемы обычно становятся заметны по мере роста нагрузки. Документы проводятся дольше, отчёты начинают мешать другим сотрудникам, появляются ожидания при одновременной работе.

Поэтому способ размещения информационной системы лучше выбирать с запасом и опираться на реальные показатели, а не только на количество сотрудников.

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

Как устроен файловый режим

Основные данные информационной системы находятся в файле 1Cv8.1CD. Отдельная система управления базами данных в такой конфигурации не используется.

Платформа обращается к информационному файлу в соответствии с выбранным способом подключения. Рабочие места могут взаимодействовать с ним напрямую, через терминальный узел или веб-сервер.

Для небольшой компании это удобный вариант: требуется меньше компонентов, проще первоначальная настройка и дальнейшее обслуживание.

С увеличением одновременной активности пользователей ситуация меняется. Несколько сотрудников могут обращаться к одним данным, проводить документы или строить отчёты. Возникают ожидания блокировок, а накопитель получает больше запросов на чтение и запись.

Поэтому скорость зависит в том числе от дисковой подсистемы. При её оценке имеет смысл учитывать IOPS, задержку ввода-вывода и пропускную способность.

Что меняется при использовании SQL

В серверной схеме между рабочим местом пользователя и хранилищем данных появляется дополнительный уровень. Прикладные задачи обрабатывает кластер 1С, а хранением и выполнением запросов занимается СУБД.

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

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

Среди поддерживаемых решений широко применяются Microsoft SQL Server и PostgreSQL. PostgreSQL не требует оплаты лицензии за саму СУБД. Microsoft SQL Server располагает развитым набором средств администрирования, диагностики и мониторинга.

При выборе нужно учитывать текущую ИТ-инфраструктуру, опыт специалистов, требования к лицензированию и предполагаемый профиль нагрузки.

Сравнение двух вариантов

Для небольшой организации переход на более сложную инфраструктуру нужен далеко не всегда.

Если сотрудники работают без заметных задержек, отчёты выполняются за приемлемое время, а регламентные задания не мешают основным процессам, существующее решение можно оставить.

Пример такой нагрузки: несколько бухгалтеров и менеджеров работают с документами, периодически строят отчёты, а обмены с внешними сервисами выполняются в фоновом режиме и не создают постоянной нагрузки.

Размер информационной системы и число сотрудников дают лишь общее представление о ситуации. Для оценки производительности полезнее посмотреть на реальные показатели:

• время проведения документов и построения отчётов;
• загрузку процессора в рабочие часы;
• задержки накопителей;
• использование оперативной памяти;
• блокировки;
• продолжительность фоновых заданий;
• работу внешних обменов.

Если критичных отклонений нет, переход на СУБД не является обязательным.

Что происходит при увеличении нагрузки

Первой обычно становится заметна конкуренция за ресурсы.

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

Дополнительную нагрузку создают обмены, фоновые пересчёты, закрытие месяца и другие регламентные процессы. То, что почти не ощущалось при небольшой рабочей группе, начинает влиять на ежедневную работу.

Файловый режим также предъявляет повышенные требования к стабильности соединения с хранилищем. Транзакционные механизмы платформы уменьшают риски при сбоях, однако надёжность всей схемы по-прежнему зависит от состояния файловой системы, сети и оборудования.

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

Однозначного ответа нет.

Если текущая система упирается в медленный накопитель, недостаточную производительность CPU или неоптимальный запрос, перенос данных в SQL не устранит источник проблемы.

При небольшой активности пользователей файловый вариант на производительном оборудовании способен показывать хороший отклик. Преимущества СУБД сильнее проявляются при высокой параллельности.

Нагрузку могут создавать:

• массовое проведение документов;
• сложные аналитические отчёты;
• расчёты по большим объёмам информации;
• фоновые задания;
• синхронизация с CRM и сайтами;
• обмены с маркетплейсами;
• одновременная работа нескольких подразделений.

Поэтому сравнивать две схемы по скорости одной операции недостаточно. Оценивать нужно поведение всей системы в часы максимальной активности.

Есть ли предельное количество пользователей

Фиксированной цифры нет.

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

При диагностике учитывают количество активных сеансов, характер действий, фоновые процессы, блокировки и время выполнения ключевых операций.

Само число заведённых учётных записей практически ничего не говорит о требуемых ресурсах.

О необходимости миграции обычно говорят повторяющиеся проблемы в повседневной работе.

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

Блокировки мешают сотрудникам. Пользователям приходится ждать завершения чужих операций либо повторять свои действия.

Регламентные процессы влияют на рабочий день. Закрытие месяца, расчёт себестоимости или обмен с внешним сервисом снижает скорость работы остальных сотрудников.

Для создания резервной копии становится сложно найти подходящее окно. По мере роста информационной системы обслуживание занимает больше времени.

От доступности учётной системы напрямую зависят бизнес-процессы. Даже непродолжительный простой начинает влиять на работу склада, бухгалтерии, продаж или других подразделений.

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

Готовой формулы, которая связывает количество сотрудников с конкретным числом ядер и гигабайт памяти, нет. Характер нагрузки в разных конфигурациях существенно отличается.

Процессор

Для скорости отдельной пользовательской операции имеет значение производительность одного ядра.

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

При подборе CPU следует учитывать производительность на ядро, число доступных ядер и результаты тестирования на похожей нагрузке.

Ориентироваться только на частоту или только на количество ядер не стоит.

Оперативная память

В файловом варианте RAM используют процессы платформы, операционная система и файловый кэш.

После появления СУБД распределение ресурсов меняется. Значительный объём памяти может использоваться для хранения востребованных страниц данных и индексов. Для системы управления БД это штатное поведение.

Необходимый запас RAM зависит от размера рабочего набора, числа параллельных запросов, количества информационных систем и выбранного программного обеспечения.

При совместном размещении компонентов часть памяти обязательно оставляют операционной системе и процессам платформы.

В Microsoft SQL Server доступный объём можно регулировать через max server memory. PostgreSQL использует собственные механизмы настройки.

Накопители и IOPS

Для учётной системы важна не только ёмкость диска.

На время выполнения операций влияют:

• IOPS;
• задержка чтения;
• задержка записи;
• пропускная способность;
• стабильность этих показателей при пиковых обращениях.

Необходимую производительность хранилища лучше определять по измерениям действующей системы или нагрузочному тесту.

При использовании Microsoft SQL Server файлы данных и журналы транзакций при высокой активности можно разместить на разных томах. Отдельного внимания требует tempdb, если она активно участвует в выполнении запросов.

Рост дисковых задержек одновременно с увеличением времени пользовательских операций может указывать на недостаточную производительность накопителей.

Сеть

В файловом режиме важна стабильная связь с местом хранения информационного файла. Особенно это актуально, если пользователи обращаются к нему по сети.

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

Для удалённых пользователей дополнительно имеет значение качество канала до дата-центра или корпоративной площадки.

Да. Для умеренной нагрузки это распространённый вариант.

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

При этом компоненты используют общие вычислительные ресурсы. Тяжёлый запрос способен увеличить загрузку CPU или занять значительную часть памяти, которая одновременно нужна другим процессам.

Поэтому при совместном размещении необходимо контролировать распределение RAM и загрузку процессора.

Переход на отдельные узлы стоит рассматривать после того, как совместное размещение действительно начинает ограничивать систему.

Причинами могут стать:

• одновременная высокая загрузка CPU со стороны прикладных процессов и СУБД;
• подтверждённый дефицит оперативной памяти;
• несколько информационных систем с разным характером нагрузки;
• необходимость отдельно наращивать ресурсы для разных компонентов;
• повышенные требования к отказоустойчивости.

Разделение упрощает распределение ресурсов и дальнейшее масштабирование. Сам факт переноса компонентов на разные машины ускорения не гарантирует.

Оба варианта можно разместить в виртуальной инфраструктуре.

Для файлового режима нужно внимательно смотреть на характеристики хранилища. Объём диска и заявленная скорость передачи данных не дают полного представления о его производительности. Имеют значение гарантированные IOPS и задержки.

Второй фактор — качество связи между сотрудниками и дата-центром. Даже мощная виртуальная машина не обеспечит комфортную работу при нестабильном сетевом подключении.

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

Облачная площадка позволяет увеличивать CPU, RAM и характеристики накопителей без покупки и физической установки нового оборудования. Это удобно, если нагрузка со временем меняется.

Миграцию лучше выполнять по заранее подготовленному плану.

1. Собрать показатели действующей системы: объём данных, время основных операций, фоновые процессы, отчёты и интеграции.
2. Подготовить вычислительные ресурсы и установить выбранную СУБД.
3. Настроить память, дисковую подсистему и резервное копирование.
4. Развернуть кластер серверов платформы.
5. Создать новую информационную систему с хранением данных в СУБД.
6. Выгрузить исходные данные в .dt в подходящее окно обслуживания.
7. Загрузить полученный файл в новое окружение.
8. Проверить права и роли сотрудников.
9. Протестировать фоновые задания и внешние интеграции.
10. Настроить обслуживание СУБД и резервирование.
11. Выполнить основные бизнес-операции в тестовом режиме.
12. На время окончательного переноса закрыть исходную систему для изменений и загрузить актуальную копию.
13. После запуска контролировать пользовательские операции, CPU, RAM, диски и показатели СУБД.

Продолжительность переноса заранее проверяют на тестовой копии. Она зависит от объёма и структуры информации, оборудования, версии платформы и других условий.

До начала работ необходимо создать актуальную резервную копию.

Что проверить до миграции

• Сколько сотрудников действительно работают одновременно?
• Как быстро растёт объём данных?
• Какие действия создают основную нагрузку?
• Есть ли медленные запросы и отчёты?
• Что происходит с CPU и RAM в часы пик?
• Как ведёт себя дисковая подсистема?
• Возникают ли длительные блокировки?
• Хватает ли ресурсов для новой схемы?
• Какие внешние сервисы подключены к учётной системе?
• Есть ли тестовое окружение?
• Подготовлен ли регламент резервного копирования?
• Как простой влияет на работу компании?
• Кто будет сопровождать СУБД?
• Можно ли устранить текущие задержки без миграции?
• Настроен ли мониторинг после запуска?

Одна из типичных ошибок — связывать необходимость миграции только с количеством сотрудников. Фраза «пользователей стало 20, пора переходить» не учитывает, чем именно они занимаются в системе.

Другой сценарий встречается после переноса: инфраструктуру поменяли, а задержки сохранились. Диагностика показывает, что причиной был медленный отчёт, неудачный запрос или перегруженное хранилище.

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

Отдельная проблема связана с накопителями. При большом количестве операций чтения и записи высокая задержка диска непосредственно отражается на скорости обработки данных.

Дополнительную I/O-нагрузку может создавать антивирусное ПО при проверке рабочих файлов в реальном времени. Исключения для компонентов СУБД следует настраивать в соответствии с рекомендациями разработчика программного обеспечения и требованиями информационной безопасности компании.

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

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

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

Такой вариант проще поддерживать и обычно дешевле по инфраструктуре.

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

Перед миграцией полезно определить реальную причину существующих проблем. Иногда достаточно увеличить ресурсы виртуальной машины, заменить накопитель или оптимизировать конкретный участок конфигурации.

Что выбрать для небольшой компании?

Если нагрузка умеренная, а существующая система обеспечивает нужную скорость, файлового режима обычно достаточно. Более сложная инфраструктура становится актуальной при росте параллельной активности и требований к масштабированию.

С какого количества пользователей нужен SQL?

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

Перенос в SQL сделает систему быстрее?

Не обязательно. Сначала необходимо определить источник задержек. Если проблема связана с накопителями, CPU или кодом конфигурации, она может сохраниться и после миграции.

PostgreSQL или Microsoft SQL Server?

Оба решения поддерживаются платформой. При выборе учитывают инфраструктуру компании, компетенции специалистов, стоимость лицензирования и требования к эксплуатации. PostgreSQL не требует оплаты за использование самой СУБД, Microsoft SQL Server предоставляет развитые инструменты управления и диагностики.

Можно ли оставить информационный файл на сервере?

Да. Такой вариант подходит для умеренной нагрузки при достаточной производительности CPU, RAM и накопителей, а также стабильном сетевом соединении.

Стоит ли что-либо менять, если всё работает нормально?

Нет необходимости усложнять инфраструктуру без технической или бизнес-причины. Если скорость устраивает сотрудников и мониторинг не выявляет ограничений, текущую схему можно сохранить.

Можно ли разместить платформу и СУБД на одной виртуальной машине?

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