Администрирование · 12 мин
Что быстрее: файловая 1С или SQL — честное сравнение
Разбираем, что быстрее — файловая 1С или SQL-сервер. Сравнение скорости, ограничений, нагрузки и практические советы по выбору режима работы базы.
Вопрос о том, что быстрее — файловая база 1С или клиент-серверный вариант на SQL, возникает почти у каждой компании, которая перерастает стартовый этап работы с программой. Однозначного ответа «SQL всегда быстрее» не существует: на малых объёмах и одном-двух пользователях файловая база часто работает даже шустрее, потому что не тратит ресурсы на сетевое взаимодействие и обслуживание СУБД.
Разница в скорости определяется не столько самим форматом хранения, сколько тремя факторами: количеством одновременно работающих пользователей, объёмом данных и характером операций. Файловый режим использует собственный формат базы данных 1Cv8.1CD и блокирует данные на уровне таблиц при записи, а SQL-вариант (Microsoft SQL Server, PostgreSQL, Oracle, IBM DB2) обеспечивает построчные блокировки и параллельную обработку запросов.
Ниже разберём, где заканчиваются возможности файловой базы, когда переход на SQL даёт реальный прирост скорости, а когда лишь добавляет затрат на лицензии и администрирование.
Как устроена работа каждого режима и почему это влияет на скорость
В файловом режиме вся база — это один файл 1Cv8.1CD, к которому платформа обращается напрямую или через веб-сервер. Каждый пользовательский сеанс фактически читает и пишет в общий файл, а при записи данных платформа ставит блокировки на целые таблицы. Пока один пользователь проводит документ, остальные ждут освобождения таблицы — отсюда характерные «подвисания» при одновременной работе.
В клиент-серверном режиме платформа 1С (сервер предприятия) обращается к СУБД, которая сама управляет транзакциями, кэшем, индексами и блокировками. SQL-сервер умеет блокировать отдельные строки, выполнять запросы параллельно и эффективно использовать оперативную память под кэш данных. Именно поэтому при росте числа пользователей разрыв в скорости нарастает в пользу SQL.
Важно понимать: сам по себе перенос базы в SQL не ускоряет тяжёлые отчёты и медленные запросы в конфигурации. Если отчёт написан неоптимально, он будет медленным в обоих режимах — просто на SQL это станет заметно чуть раньше из-за большей нагрузки.
Сравнение по ключевым сценариям работы
| Сценарий | Файловая 1С | 1С на SQL |
|---|---|---|
| 1–3 пользователя, небольшой объём | Быстро, минимум накладных расходов | Быстро, но выше затраты на инфраструктуру |
| 5–10 пользователей, активный ввод документов | Заметные паузы из-за табличных блокировок | Стабильная работа, построчные блокировки |
| Тяжёлые отчёты по большому объёму данных | Медленно, отчёт блокирует работу других | Быстрее за счёт оптимизатора запросов и кэша |
| Регламентные операции (закрытие месяца) | Долго, операции выполняются последовательно | Заметно быстрее при параллельной обработке |
| Обмены данными, загрузка выгрузок | Зависит от диска и сети, риск блокировок | Устойчивее к параллельной нагрузке |
| Резервное копирование большой базы | Простое копирование файла, но требует паузы | Штатные средства СУБД, горячие копии |
Из таблицы видно главную закономерность: файловый режим выигрывает в простоте и на старте, SQL — в масштабируемости и устойчивости под нагрузкой. Переломная точка обычно находится в диапазоне 5–10 активных пользователей.
Проверьте, совпадают ли жалобы с моментами одновременной записи данных
Включите сбор событий TLOCK и TDEADLOCK и оцените время ожидания
Отслеживайте динамику роста и время выполнения типовых операций
Замерьте время формирования типового отчёта в разные часы нагрузки
Где файловая база реально быстрее
На одном пользователе или в паре рабочих мест файловый режим нередко обгоняет SQL по отзывчивости интерфейса. Платформа читает данные напрямую с локального диска, без сетевого обмена с сервером приложений и СУБД. Открытие списков, проведение документов, небольшие отчёты — всё это выполняется с минимальными задержками, особенно если база лежит на SSD.
Второй плюс — низкая стоимость владения. Не нужны лицензии на сервер 1С и СУБД, не нужен отдельный администратор баз данных, резервное копирование сводится к копированию файла. Для небольшой фирмы это часто важнее теоретического запаса производительности.
Типичная ошибка — файловая база по сети
Худший сценарий для файлового режима — размещение файла базы на сетевом диске с доступом по SMB. Сетевые задержки и особенности кэширования протокола резко замедляют работу и повышают риск повреждения файла при обрыве связи. Если пользователей несколько, лучше публиковать файловую базу через веб-сервер или сразу рассматривать клиент-серверный вариант.
Когда SQL даёт реальный прирост скорости
Первый случай — параллельная запись. Когда десять менеджеров одновременно проводят заказы, а кладовщик в это время оформляет реализацию, файловая база выстраивает их в очередь, а SQL обрабатывает транзакции параллельно, блокируя только затронутые строки. На практике это убирает ощущение «все друг другу мешают».
Второй случай — большие выборки и сложные отчёты. Оптимизатор запросов СУБД строит план выполнения, использует индексы и держит «горячие» данные в памяти. Отчёт, который в файловом режиме формируется несколько минут и блокирует коллег, на SQL часто выполняется за секунды и не мешает остальным.
Третий случай — регламентные и фоновые задания под нагрузкой: обмены с сайтом, загрузка банковских выписок, пересчёт итогов. Сервер предприятия распределяет такие задачи по рабочим процессам и не отнимает ресурсы у интерактивных сеансов пользователей.
Сравнение вариантов развёртывания
Подходит для 1–2 пользователей; ограничение — нет совместной работы в полном объёме
Подходит для 3–8 пользователей; ограничение — табличные блокировки при интенсивной записи
Подходит от 8–10 пользователей и крупных баз; ограничение — стоимость лицензий и необходимость администрирования СУБД
Как измерить скорость до и после перехода
Переход на SQL стоит оценивать не по ощущениям, а по замерам. Зафиксируйте базовые показатели файловой базы: время открытия программы, проведения типового документа, формирования ключевого отчёта, выполнения закрытия месяца. Замеры делайте в часы пиковой нагрузки и в спокойное время — разница покажет влияние блокировок.
После развёртывания тестовой SQL-базы повторите те же операции в тех же условиях. Реальный прирост при параллельной работе обычно ощутим сразу, а вот ускорение одиночных операций может быть скромным — это нормально и не признак неудачного перехода.
- 1Сделайте полную выгрузку базы через конфигуратор (файл .dt) и проверьте, что она восстанавливается
- 2Разверните сервер 1С и СУБД на отдельном оборудовании или выделенном сервере
- 3Создайте новую информационную базу в клиент-серверном режиме и загрузите в неё .dt
- 4Проведите тестирование: типовые документы, отчёты, обмены, права пользователей
- 5Замерьте время ключевых операций и сравните с показателями файловой базы
- 6Переводите пользователей поэтапно, сохраняя файловую копию как резерв на время обкатки
Частые ошибки и скрытые ограничения
Самая распространённая ошибка — ожидать от SQL чуда при слабом железе. Если сервер СУБД работает на медленных дисках с малым объёмом памяти, клиент-серверный вариант может оказаться медленнее файлового на SSD. СУБД критична к скорости дисковой подсистемы и объёму оперативной памяти под кэш.
Вторая ошибка — переносить базу «как есть», не разбираясь с проблемами конфигурации. Неоптимальные запросы, отсутствие индексов по часто используемым полям, избыточные движения по регистрам — всё это надо чинить отдельно, иначе переход даст лишь часть возможного эффекта.
Третья ошибка — забыть про обслуживание СУБД. Без регулярного обновления статистики, перестроения индексов и контроля журнала транзакций производительность SQL-базы со временем деградирует, и пользователи получат «медленный SQL», хотя виновато отсутствие регламентного обслуживания.
Как проверить, что выбор оказался правильным
Критерий правильного решения — не цифры в синтетических тестах, а устойчивая работа в пиковые часы. Если в конце месяца, когда все одновременно вводят документы и строят отчёты, система отвечает предсказуемо и без очередей блокировок — режим выбран верно.
Для объективной оценки используйте технологический журнал платформы: события ожидания на блокировках, длительные запросы, ошибки СУБД. Регулярный анализ этих данных позволяет заметить проблему раньше, чем о ней сообщат пользователи.
Как проверить результат
Время сопоставимо со спокойным периодом
Время растёт в разы при одновременной работе пользователей
Единичные события ожидания блокировок
Массовые TLOCK и взаимоблокировки TDEADLOCK
Стабильное время независимо от нагрузки
Отчёт «встаёт», когда коллеги вводят документы
Копия создаётся по расписанию и проверяется восстановлением
Копирование требует остановки работы или не проверяется
Как выбрать действие
Итоговая логика выбора проста: файловый режим — это скорость и простота на старте, SQL — устойчивость и масштабируемость под нагрузкой. Переходить на клиент-серверный вариант стоит не «на вырост», а тогда, когда блокировки и очереди в файловой базе уже стали регулярной проблемой, подтверждённой замерами.
Что важно запомнить
Файловая 1С быстрее и дешевле при малом числе пользователей, SQL выигрывает при параллельной работе и больших объёмах. Решение принимайте по замерам в пиковые часы, переход выполняйте через тестовый контур с обязательной резервной копией.
Частые вопросы
Сколько пользователей выдерживает файловая база 1С?
Комфортный предел обычно составляет 4–8 активных пользователей в зависимости от интенсивности записи. При спокойной работе (просмотр данных, редкое проведение документов) файловый режим может обслуживать и больше сеансов, но при массовом одновременном вводе документов очереди на блокировках становятся заметными уже на 5–6 пользователях.
Ускорит ли переход на SQL медленный отчёт?
Не обязательно. Если отчёт построен на неоптимальном запросе — без нужных индексов, с обходом больших таблиц — он останется медленным и на SQL. Сначала проанализируйте запрос и структуру данных. Прирост от смены режима проявляется в основном там, где узким местом были блокировки и нехватка параллелизма, а не сама логика запроса.
Какая СУБД лучше для 1С: Microsoft SQL Server или PostgreSQL?
Обе поддерживаются платформой и при корректной настройке показывают сопоставимую производительность. PostgreSQL (в том числе сборки, адаптированные для 1С) снижает затраты на лицензии, MS SQL Server проще в типовом администрировании для Windows-инфраструктуры. Выбор чаще определяется бюджетом и компетенциями администратора, а не разницей в скорости.
Можно ли вернуться с SQL обратно на файловый режим?
Да, через выгрузку базы в файл .dt из конфигуратора и последующую загрузку в новую файловую базу. Данные и настройки переносятся полностью. Учтите, что для очень больших баз выгрузка и загрузка могут занять продолжительное время, поэтому операцию планируют на нерабочие часы.
Почему файловая база по сети работает медленно и это опасно?
При прямом доступе к файлу по сети каждая операция чтения-записи идёт через сетевой протокол с его задержками, а механизмы кэширования могут рассинхронизировать представление данных у разных сеансов. При обрыве соединения в момент записи возрастает риск повреждения файла базы. Безопасные альтернативы — публикация через веб-сервер или клиент-серверный режим.
Что важнее для скорости SQL-базы: процессор, память или диски?
На практике первым узким местом становится дисковая подсистема — СУБД интенсивно пишет журнал транзакций и читает данные. Следующий фактор — объём оперативной памяти: чем больше данных помещается в кэш, тем меньше обращений к диску. Процессор редко оказывается bottleneck, если не выполняются массовые параллельные расчёты.