Администрирование · 12 мин
Шарды в 1С: что это и когда нужно шардирование базы
Шарды в 1С: что это такое, как работает горизонтальное разделение базы данных на части, когда шардирование оправдано и какие есть альтернативы.
Термин «шард» (от английского shard — «осколок, фрагмент») пришёл из мира высоконагруженных систем. Шардирование — это горизонтальное разделение одной логической базы данных на несколько физических частей, каждая из которых хранится на отдельном сервере. Каждый шард содержит только часть данных, а вместе они образуют полный массив информации.
Применительно к 1С запрос «shardes 1c» обычно означает интерес к тому, как масштабировать информационную базу, когда она выросла до сотен гигабайт или терабайт и стандартные методы оптимизации уже не помогают. Важно сразу понимать: платформа 1С:Предприятие не имеет встроенного механизма шардирования прикладных баз. Кластер серверов 1С распределяет нагрузку по сеансам и рабочим процессам, но сама база данных остаётся единой.
Поэтому на практике под «шардами 1С» чаще всего понимают одно из трёх: разделение данных на несколько независимых информационных баз (по организациям, регионам, направлениям), использование возможностей СУБД (партиционирование таблиц, распределённые базы) или внедрение внешних хранилищ для части данных. Ниже разберём каждый подход, его ограничения и критерии выбора.
Что такое шард и как работает шардирование в общем случае
Классическое шардирование делит строки таблиц по какому-то ключу: например, клиенты с идентификаторами от 1 до миллиона попадают на сервер А, от миллиона до двух миллионов — на сервер Б. Ключ шардирования выбирают так, чтобы большинство запросов обращалось только к одному шарду, иначе система теряет смысл: запросы «всем шардам сразу» работают медленнее, чем по единой базе.
Главные выгоды подхода — рост суммарной производительности (каждый сервер обслуживает меньший объём данных), возможность масштабирования «вширь» дешёвыми серверами и изоляция сбоев: отказ одного шарда затрагивает только его часть данных. Обратная сторона — резкое усложнение архитектуры: транзакции между шардами, консистентность, резервное копирование и аналитика по всем данным становятся нетривиальными задачами.
Почему в типовой 1С нет готового шардирования
Платформа 1С:Предприятие спроектирована вокруг модели «одна информационная база — одна база данных СУБД». Все механизмы платформы — транзакции, блокировки, последовательности, итоги регистров, ссылочная целостность — рассчитаны на то, что данные находятся в одном месте и СУБД гарантирует их согласованность.
Кластер серверов 1С масштабирует только вычислительный слой: рабочие процессы, сеансы, фоновые задания. Можно добавить рабочие серверы, распределить по ним пользователей и сервисы, но все они будут обращаться к одной и той же базе данных. Узким местом при росте нагрузки почти всегда становится именно сервер СУБД, а не серверы приложений.
Из-за этого попытка «просто разрезать» базу 1С на шарды ломает базовые гарантии платформы: ссылка на объект в другом шарде станет битой, проведение документа, затрагивающего данные двух шардов, потеряет атомарность, а расчёт итогов регистров потребует собственного механизма консолидации.
Вариант 1: разделение на несколько информационных баз
Самый работающий на практике аналог шардирования в мире 1С — это распределение учёта по нескольким самостоятельным информационным базам. Типичные схемы: отдельная база на каждую юридическую единицу холдинга, отдельные базы по регионам или филиалам, разделение по видам деятельности (оптовая торговля отдельно, розница отдельно, производство отдельно).
Обмен между базами организуют через планы обмена, универсальный формат EnterpriseData или собственные механизмы на HTTP-сервисах. Справочники (номенклатура, контрагенты) синхронизируются, а документы и остатки живут каждый в своей базе. Консолидированную отчётность собирают либо в отдельной сводной базе, либо внешними BI-инструментами.
Ключевая проблема подхода — рассинхронизация нормативно-справочной информации. Если в двух базах заведут одного контрагента с разными наименованиями, обмены начнут плодить дубли. Поэтому при такой архитектуре обязательно назначают «мастер-базу» для каждого справочника и жёстко регламентируют, где что редактируется.
Сравнение вариантов
Подходит холдингам и территориально распределённым компаниям. Ограничение: нужна дисциплина ведения справочников и надёжный мониторинг обменов.
Подходит для очень больших таблиц регистров и журналов. Ограничение: не все механизмы платформы одинаково хорошо работают с секционированными таблицами, требуется тестирование.
Подходит, когда активно используется только последний период. Ограничение: запросы к архиву требуют отдельного доступа, сводные отчёты усложняются.
Подходит в большинстве случаев: индексы, обновление статистики, настройка СУБД, свёртка итогов. Ограничение: есть физический предел роста одной базы.
Вариант 2: средства СУБД — партиционирование и распределённые запросы
Второй уровень шардирования — возможности самой СУБД. MS SQL Server, PostgreSQL и Oracle поддерживают секционирование (партиционирование) таблиц: одна логическая таблица физически делится на секции, например по периоду регистратора. Для платформы 1С таблица остаётся единой, но обслуживание (очистка старых периодов, перестроение индексов) выполняется посекционно и значительно быстрее.
Партиционирование — не шардирование в строгом смысле, потому что все секции обычно находятся на одном сервере. Но оно решает похожую задачу: ускоряет обслуживание больших таблиц и позволяет разнести секции по разным дисковым массивам. Для регистров накопления и сведений с сотнями миллионов записей это часто даёт ощутимый эффект.
Распределённые базы данных (linked servers в MS SQL, foreign data wrappers в PostgreSQL) позволяют строить запросы между серверами, но использовать их «под» информационной базой 1С нельзя — платформа работает только с одной базой. Эти механизмы применимы лишь для отчётности и интеграций поверх уже разделённых баз.
Вариант 3: вынос данных из оперативной базы
Часто проблему «слишком большой базы» решают не разделением, а уменьшением объёма активных данных. Самые объёмные сущности в базах 1С — это движения регистров за старые периоды, истории версий объектов, журналы регистрации, присоединённые файлы и результаты фоновых заданий.
Рабочая схема выглядит так: старые периоды сворачиваются (документы свёртки формируют входящие остатки на дату), детальные данные переносятся в архивную базу или внешнее хранилище, присоединённые файлы выносятся в тома на дешёвых дисках штатным механизмом хранения файлов в томах. Оперативная база уменьшается в разы, а с ней — время бэкапа, реструктуризации и типовых запросов.
Отдельное направление — вынос аналитики. Если тяжёлые отчёты грузят рабочую базу, данные реплицируют в отдельную аналитическую базу (та же 1С, копия средствами СУБД или внешнее хранилище), и вся ресурсоёмкая отчётность строится там, не мешая оперативной работе пользователей.
- 1Замерьте фактическую нагрузку: размер базы, рост в месяц, самые большие таблицы, длительные запросы и блокировки.
- 2Примените базовую оптимизацию: обновление статистики, перестроение индексов, настройка памяти и tempdb на сервере СУБД.
- 3Уменьшите объём: очистите журнал регистрации, версии объектов, помеченные объекты, настройте хранение файлов в томах.
- 4Сверните старые периоды и вынесите архив в отдельную базу, если активно используется только свежий период.
- 5Если нагрузка всё ещё превышает возможности одного сервера — проектируйте разделение на несколько информационных баз с обменами.
- 6На каждом этапе проверяйте результат замерами до и после, а не по ощущениям.
Как понять, что шардирование действительно нужно
Разделение базы — дорогое решение: растут затраты на администрирование, обмены, мониторинг и поддержку целостности. Поэтому сначала стоит убедиться, что исчерпаны более простые меры. Признаки того, что одна база действительно достигла предела: сервер СУБД утилизирован по процессору, памяти или дисковой подсистеме после грамотной настройки; регламентные операции (бэкап, реструктуризация, обновление) занимают недопустимо много времени; рост данных нельзя ограничить свёрткой по организационным причинам.
Обратный признак: если проблемы вызваны неоптимальными запросами в конфигурации, отсутствием индексов по частым отборам или слабым железом, никакое шардирование не поможет — вы просто разнесёте ту же неэффективность по нескольким серверам и добавите себе проблем с согласованностью.
Как проверить результат
Стабильно укладывается в приемлемые для бизнеса нормы в часы пик
Растёт пропорционально объёму базы, пользователи жалуются на подвисания
Бэкап и обновления укладываются в ночное окно
Регламентные работы пересекаются с рабочим временем
Есть запас по CPU, памяти и дисковым очередям
Постоянная утилизация близка к 100% после оптимизации
Обмены завершаются без ошибок, дубли справочников отсутствуют
Регулярные коллизии, очереди неразобранных сообщений
Типичные ошибки при разделении данных 1С
Первая ошибка — разделение по формальному признаку без анализа бизнес-процессов. Если документ одной базы постоянно ссылается на данные другой (склад в базе А, продажи в базе Б), пользователи получают битые ссылки, ручной перенос и двойной ввод. Границы между базами должны совпадать с границами ответственности подразделений.
Вторая ошибка — отсутствие владельца справочников. Когда номенклатуру могут редактировать в любой базе, дубли и расхождения неизбежны. Третья — недооценка обменов: без мониторинга очередей и регламента разбора ошибок данные в базах расходятся незаметно, и расхождение обнаруживается только при сверке отчётности.
FAQ: частые вопросы о шардах в 1С
Есть ли встроенное шардирование в платформе 1С:Предприятие?
Нет. Платформа масштабирует только серверный слой (кластер, рабочие процессы), но информационная база всегда остаётся единой базой данных на одном сервере СУБД. Разделение данных реализуется прикладными средствами: несколькими базами с обменами, свёрткой, выносом архивов.
Чем шард отличается от реплики?
Реплика — это полная копия всех данных на другом сервере, она повышает отказоустойчивость и может разгрузить чтение. Шард содержит только часть данных, его задача — уменьшить объём, обрабатываемый каждым сервером. Реплики не решают проблему слишком большой базы, так как каждая копия остаётся такого же размера.
Можно ли разнести одну базу 1С на два сервера СУБД?
Нет, одна информационная база работает с одной базой данных. Распределить можно только нагрузку серверов 1С (кластер) или разделить учёт на несколько самостоятельных информационных баз, каждая со своей СУБД.
Что попробовать до того, как делить базу?
Сначала — оптимизация: настройка СУБД, индексы, обновление статистики, исправление тяжёлых запросов, очистка журналов и версий, свёртка старых периодов, вынос файлов в тома. В большинстве случаев этих мер достаточно, и разделение не потребуется.
Как строить отчёты по всем данным после разделения на базы?
Обычно создают отдельную консолидирующую базу или аналитическое хранилище, куда обменами или репликацией стекаются данные из всех баз. Оперативные отчёты строятся в каждой базе локально, сводная отчётность — в консолидаторе.
Что важно запомнить
Шард — это фрагмент базы данных на отдельном сервере. В 1С встроенного шардирования нет: база всегда едина. Практические аналоги — несколько информационных баз с обменами, партиционирование на уровне СУБД и вынос архивных данных. К разделению переходят только после исчерпания оптимизации, а границы баз проводят по границам бизнес-процессов.