какую субд использует 1с
Файловая СУБД
Файловая СУБД — одна из систем управления базами данных, которую поддерживает платформа. Файловая СУБД разработана фирмой «1С» и является частью платформы.
Файловая СУБД хранит все данные в одном файле — файловой базе данных. Этот формат хранения данных разработан фирмой «1С» специально для прикладных решений 1С:Предприятия 8.
При создании платформы был необходим эффективный формат для создания на его основе легкого варианта 1С:Предприятия 8 для персонального использования и небольших рабочих групп. Формат должен был удовлетворять определенным требованиям, таким как, эффективность, поддержка UNICODE, возможность размещения всей информационной базы в одном файле. Использование этого варианта не должно было требовать установки дополнительного программного обеспечения у пользователя и каких-либо действий по администрированию.
Должна была обеспечиваться, например, возможность легкого переноса информационной базы на ноутбук или быстрого развертывания удаленного рабочего места на складе. При этом прикладное решение должно было без каких-либо изменений работать как в этом варианте, так и в варианте с использованием сервера баз данных.
По результатам исследования продуктов сторонних производителей и их анализа было принято решение о создании собственного «движка» базы данных, поддерживающего собственный формат хранения.
Техническая реализация работы с файловой базой данных
Файловая СУБД является частью платформы, поэтому при работе системы в файловом варианте толстый и тонкий клиенты самостоятельно осуществляют всю работу с данными.
В случае веб-клиента подключение к файловой базе данных выполняется через веб-сервер, и непосредственную работу с данными выполняет не клиентское приложение, а модуль расширения веб-сервера, который также содержит в себе файловую СУБД.
Взаимодействие элементов системы с файловой базой данных осуществляется по собственному протоколу обмена данными, разработанному фирмой «1С».
СУБД для 1С Fresh. Быстро. Надежно. Бесплатно
Кнопка уже несколько лет для работы с бухгалтерскими базами использует технологию публикаций 1C Fresh. Мы уже недавно писали о нашем опыте эксплуатации. Использование нами в качестве СУБД PostgreSQL вызвало интерес и ряд вопросов, поэтому мы решили рассказать об этом подробнее.
Введение
В самом начале мы использовали в качестве СУБД традиционный для 1С MS SQL Server. Когда наш Fresh дорос до необходимости горизонтального масштабирования, стало понятно, что по экономическим соображениям нужна альтернатива продукту от Microsoft. Тогда мы внимательно посмотрели в сторону PostgreSQL, тем более что специалисты из 1С его рекомендовали к использованию в инсталляции 1С Fresh. Мы провели простое сравнение производительности на стандартных операциях и выяснили, что база Бухгалтерия Предприятия (БП) 3.0, содержащая около 600 областей работает не хуже. В то время мы переходили на схему нескольких виртуальных машин на Linux с сервером приложений и СУБД. Об этом немного рассказано в статье. Но по разным причинам через год пришли к схеме сервер приложений на Windows и СУБД с несколькими информационными базами (ИБ) на Linux. Но смеем вас заверить, что проблем с работой сервера приложений на Linux у нас не было, изменения связаны с некоторыми другими нашими особенностями работы.
Итак, в качестве сервера баз данных был выбран PostgreSQL. В этой статье Кнопка расскажет, как мы подружили одно с другим, и как это всё заработало.
В первой инсталляции использовали готовые deb-пакеты PostgreSQL 8.4.3-3.1C, предоставляемые 1С, так как это была рекомендуемая для использования версия. Но к сожалению, столкнулись с проблемой зависимостей при установке на Debian Wheezy, являющийся на тот момент oldstable выпуском, содержащим пакеты apache2.2 (поддержки apache2.4 в 1С тогда еще не было). В то время мы держали СУБД и сервер приложений на одном хосте, поэтому приходилось использовать oldstable. Для установки этой версии PostgreSQL требовался libc6 из Debian Jessie. В результате такого скрещивания получилась система, с которой особо ничего не сделаешь, даже установка NFS-клиента ломала необходимые для работы зависимости. Но переходить на другой дистрибутив Linux нам было не выгодно стратегически. Когда мы начали активно использовать микросервисы (для простоты мы называем их роботами), которые взаимодействовали с сервером приложений через COM-соединение, в базах данных начали появляться висящие коннекты, которые приводили к утечке памяти. Эта проблема решалась переходом на новую версию PostgreSQL, но в тот момент 1С еще не выпустил дистрибутив этой версии.
Мы приняли волевое решение перейти на использование сборки PostgreSQL 9.6 из репозитория Postgres Professional. Проблемы с зависимостями и утечкой памяти остались позади, и мы начали решать вопросы масштабируемости, распределения нагрузки и увеличения времени доступности. В настоящее время специалистами 1С уже обновлены сборки PostgreSQL, самая свежая 9.6.3, это вполне актуальная версия и надежнее использовать именно её. По информации от 1С новые сборки будут выпускаться оперативно.
В настоящее время мы работаем на Debian Jessie и далее мы будем рассматривать все вопросы в рамках этого дистрибутива.
Состояние нашей системы мы отслеживаем с помощью Zabbix, выглядит это вот так:
На графиках еще присутствуют старые серверы, но продуктив уже переведен с них на PostgreSQL 9.6.
А еще мы меряем количество транзакций:
И количество добавленных, измененных и удаленных строк:
В эксплуатации СУБД мы внимательно следим за нашими показателями и все настройки, приведенные ниже, родились именно из реальной эксплуатации и наблюдений. У нас сейчас 2 основных сервера СУБД, каждому из которых выделено по 8 ядер и 40 Гб памяти. Диски с базами располагаются на SSD. Этих ресурсов нам хватает для обслуживания 7 ИБ БП 3.0 с включенным режимом разделения данных (200-800 областей в одной базе). При такой конфигурации мы добились неплохой утилизации ресурсов с одной стороны и хорошего запаса для роста и пиковых нагрузок с другой.
Кластеры в PostgreSQL
При размещении нескольких ИБ на одной виртуальной машине, мы столкнулись со сложностью администрирования. Каждая ИБ желала своих настроек сервера, любая остановка СУБД отключала все базы, а еще архивация WAL совсем не имела смысла, потому что восстановление через этот механизм откатывало бы все базы на сервере.
Для начала каждую из наших баз разместили в отдельном кластере PostgreSQL, что дало возможность гибко управлять ими, запускать несколько независимых копий PostgreSQL на одном хосте, настроить потоковую репликацию, архивирование WAL, а также восстановление данных на момент времени (PiTR).
На практике процесс развертывания выглядит так:
У нас имеется машина, с установленным Debian 8 Jessie, уже установлен PostgreSQL 9.6 из репозитория Postgres Professional.
Создадим наш новый кластер:
После этого в /databases создастся каталог db_01, в котором разместятся файлы данных, а файлы конфигурации в /etc/postgresql/9.6/db_01/. Кластер будет использовать 9.6 версию PostgreSQL его экземпляр будет запущен на порту 5433. Сейчас кластер не запущен, это можно проверить командой:
Вносим изменения в конфигурационный файл кластера postgresql.conf, приблизительные значения параметров можно получить используя PgTune. За что отвечает тот или иной параметр подробно рассказано в документации, мы же поясним только те параметры, которые PgTune не учитывает.
max_parallel_workers_per_gather полезно установить значение равное количеству воркеров, которые будут использоваться параллельно для последовательного чтения таблиц. Это ускорит многие операции чтения. Исходите из количества ядер на вашем хосте, превышение этого количества не даст прироста производительности, а наоборот, произойдет деградация.
max_locks_per_transaction по-умолчанию 64, но в ходе работы значение подняли до 300. Параметр назначает количество блокировок объектов, выделяемых на транзакцию. Если будет использоваться слейв-сервер, то это значение на нём должно быть равно или больше чем на мастер-сервере.
Если файловая система не достаточно производительна, разместите pg_xlog на отдельном хранилище.
Для примера конфиг файл одного кластера:
Настало время запустить свежесозданный кластер и начать его использовать:
Для подключения по нестандартному порту в оснастке администрирования серверов 1С Предприятия в параметрах информационной базы в поле «Сервер баз данных» указать:
А еще важно не забывать про регулярное обслуживание базы. VACUUM и ANALYZE очень полезны.
Потоковая репликация
Реализация standby-сервера довольно проста.
Настроим master-сервер
Вносим изменения в файл конфигурации postgresql.conf, не забыв, что конфигурируем наш новый кластер и находится файл в /etc/postgresql/9.6/db_01/
listen_addresses = ‘*’
wal_level = replica
max_wal_senders = 3
wal_keep_segments = 128
Создадим новую роль replica:
И разрешим подключение для slave-сервера, поправив файл pg_hba.conf
После этого потребуется перезапустить кластер:
Теперь пришло время настроить slave-сервер. Предположим, что конфигурация его идентична мастеру, создан кластер с таким же названием, файлы данных лежат в каталоге, который смонтирован аналогично мастеру. Остановим кластер на слейве:
В файле postgresql.conf включаем режим standby:
hot_standby = on
Очищаем каталог с файлами данных на слейве /databases/db_01/ и делаем копию текущего состояния мастера на слейв:
Будет создан файл recovery.conf, поправим его по необходимости:
standby_mode = ‘on’
primary_conninfo = ‘user=replica password=MyBestPassword host=master.domain.local port=5433 sslmode=prefer sslcompression=1 krbsrvname=postgres’
В данном случае мы не делаем failover, который будет автоматически забирать роль мастера. Чтобы реплика начала работать в роли мастера достаточно переименовать файл recovery.conf и перезапустить кластер.
Запускаем слейв кластер:
Проверим, что репликация идет. На мастере появится процесс wal sender, а на слейве wal receiver. Более подробную информацию о репликации можно получить выполнив на мастере:
На слейве можно следить за значением, которое показывает когда проходила последняя репликация:
Резервное копирование и архивирование WAL
Первоначально резервирование производилось посредством pg_dump раз в сутки, что в совокупности с внутренним механизмом резервных копий областей в 1C Fresh давало приемлемую схему резервирования. Но иногда случаются ситуации, когда между моментом последнего бэкапа и моментом аварии проделано большое количество работы. Чтобы не потерять эти изменения нам поможет архивирование WAL-файлов.
Для включения архивирования WAL необходимо соблюсти три условия:
Параметр wal_level должен иметь значение replica или выше
Параметр archive_mode = on
В archive_command задана команды оболочки, например:
Таким образом мы копируем архивные сегменты WAL в каталог /wal_backup/db_01/
Чтобы изменения вступили в силу, требуется рестарт кластера. Итак, когда очередной сегмент WAL будет готов, он будет скопирован, но чтобы им воспользоваться при восстановлении нужна базовая копия кластера, на которую будут применяться изменения из архивных сегментов WAL. С помощью простого скрипта мы будем создавать базовую копию и класть ее рядом с WAL-файлами.
Для того чтобы восстановить резервную копию на определенный период времени (PiTR) останавливаем кластер и удаляем содержимое
Затем распаковываем базовую копию, проверяем права и правим (либо создаем) файл recovery.conf со следующим содержанием:
restore_command = ‘cp /wal_backup/db_01/%f %p’
recovery_target_time = ‘2017-06-12 21:33:00 MSK’
recovery_target_inclusive = true
Таким образом мы восстановим данные на момент времени 2017-06-12 21:33:00 MSK, а точка останова будет сразу после достижения этого времени.
Заключение
Картинка про надежность связки 1C Fresh и PostgreSQL:
У нас более 350 Гб информационных баз отлично себя чувствуют, растут и развиваются. Чего и вам желаем!
Выбор СУБД для 1С — файловая или SQL?
СУБД для 1С
Файловый вариант 1С
Клиент-серверная СУБД для 1С
Инструкция по переходу с файловой базы на SQL
Подведем итоги
НОВОСТИ
Обучающие видеокурсы по 1С
V Всероссийский юридический форум
Переход с программ 1С версии 7.7 на 1С:Фреш
Отзывы о компании
ПАО «НИКО-БАНК» выражает свою благодарность за оперативную и грамотную работу.
В условиях постоянно меняющегося законодательства Банк заинтересован иметь полную и актуальную номативную базу. Это обеспечивается использованием Банком справочно-нормативной системы «Гарант».
Безусловным плюсом в работе компании «МастерСофт» является быстрое реагирование сотрудников при предоставлении документов по запросу Банка, принятых до обновления справочно-правовой системы.
Коллектив компании «АЭРОПОРТ ОРЕНБУРГ» выражает благодарность за взаимовыгодное сотрудничество с МастерСофт-ИТ. Оперативная поставка антивирусных программ Dr. Web обеспечила надежную защиту нашей компьтерной сети.
Особая благодарность сотрудникам Департамента продаж СЦ ИТ за профессиональный подход в решении всех возникающих задач.
ООО «Орский Вагонный Завод» выражает искреннюю благодраность за качество обслуживания вашими специалистами. Консультации и поставка антивирусов всегда проходят оперативно и на высоком профессиональном уровне.
Уверены, что и в дальнейшем наше сотрудничество на взаимовыгодных условиях продолжится.
Главный бухгалтер муниципального бюджетного учреждения дополнительного образования «Дворец творчества детей и молодёжи» Кетерер Татьяна Михайловна выражает благодарность специалистам МастерСофт:
«Я хотела бы объявить благодарность вашим сотрудникам. Работает с нами по программе «1С: Бухгалтерия бюджетного учреждения 8» непосредственно Шевлягина Юлия.
Так же огромная благодарность за отзывчивость, терпение и квалифицированную, своевременную помощь Набокиной Олесе и Ерёменко Татьяне (они нас сопровождают по программе «Зарплата и Кадры»).
Им очень с нами тяжело, но они терпеливо продолжают сотрудничать. С вами очень надёжно. Конечно же наши ошибки есть и без вас мы бы вообще о них не знали и в суде, наверное, судились бы. А сейчас мы решаем вопросы. «.
Исследование использования СУБД (MS SQL, PostgreSQL, Oracle, IBM DB2) с отраслевыми конфигурациями на платформе 1С:Предприятие
Дмитрий Кочергов 
(Kochergov)
Мы проводим этот опрос с целью:
Число участников исследования с каждым годом увеличивалось. В 2014 году мы опросили около 2800 человек, в 2017 году – порядка 6500, а в 2018 году уже около 7000. При этом также растет объем комментариев с описанием системной архитектуры и ландшафта ИТ-решений: в 2014 году – порядка 200, в 2017 – более 1400, в 2018 – около 1500. Все комментаторы – авторизованные пользователи портала Инфостарт, и большинство из них ответили и на вопросы анкеты. Это усиливает репрезентативность выборки и подтверждает результаты анкетирования.
В 2017 году анкета была расширена и в 2018 году – скорректирована, однако сведения из комментариев дополняют картину и позволяют провести сопоставление результатов опроса за все три года. Основные итоги можно представить по следующим шести вопросам:
Предварительный срез данных опроса за 2018 год для исследования сделан по состоянию на 27 ноября.
Участники опроса
Как и следовало ожидать, исходя, например, из анализа материалов конференции INFOSTART EVENT 2018, более 51% опрошенных работают в коммерческих компаниях не ИТ-специализации. Это само по себе делает результаты опроса интересными, поскольку они в существенной степени отражают ситуацию с тем, кто и как использует СУБД для 1С в реальных условиях бизнеса.
1С:Франчайзи – примерно пятая часть респондентов, чуть меньше доля среди опрошенных у ИТ-компаний (не франчайзи 1С) – около 17%. Работники государственных предприятий составили лишь порядка 4%, что можно объяснить не только строгой конфиденциальностью, но и отсутствием желания свидетельствовать, что госструктуры все еще сильно зависят от зарубежных ИТ.
Основная СУБД: PostgreSQL вышла на 2-е место
Основной СУБД для 1С пока остается MS SQL. Кроме того, доля ее пользователей постоянно растет и только за последний год прибавила более чем 14%. Как показал опрос, сегодня преимущественно с продуктом от Microsoft работают трое из каждых четырех 1С-ников.
Отметим, что подобный рост обусловлен, прежде всего, падением популярности файловой СУБД, а также слишком осторожными успехами PostgreSQL, которая все же вырвалась на второе место с 15,2%. Отказ от файловой СУБД ряд опрошенных связали с миграцией на новые версии платформы 1С:Предприятие, а также с увеличением вычислительной нагрузки. Самый же типичный размер БД у пользователей с файловыми СУБД, согласно опросу 2018 года, не превышает 10 Гб (62%).
Системы от Oracle и IBM встречаются все реже как в абсолютном значении по количеству компаний, так и относительно других СУБД, и в настоящее время их доли не превышают 1%.
Один из характерных комментариев 2018 года, описывающий ситуацию:
«Выбор MS SQL был сделан 11 лет назад, когда о PostgreSQL и не говорили, сейчас же нет смысла переходить на что-то другое».
«… выбор был сделан давно – тогда негативных отзывов про связку 1С-PostgreSQL было намного больше, чем сейчас, поэтому так и повелось».
«Десять лет назад начали использовать MS SQL как проверенное решение. Теперь все к ней привыкли, и переходить на другие СУБД пока не планируем».
Многие опрошенные также отмечали, что файловая СУБД и MS SQL им просто понятнее. А в ряде случае выбор в пользу Microsoft обусловлен даже не достоинствами их СУБД или работой исключительно под Windows, а негативным опытом миграции на другие системы, включая PostgreSQL.
Отрицательный опыт коррелирует, во-первых, с недостаточной на тот период компетентностью, как самих респондентов, так и служб поддержки 1С-франчайзи. Так, один из участников опроса пишет:
«Все сервера на MS SQL, пробовали в одной компании PostgreSQL. На типовой конфигурации возникала ошибка СУБД. с которой очень долго боролись. Информации было мало, техподдержка 1С не очень оперативно помогала с решением проблемы. Учитывая простой в работе и затраченные ресурсы, MS SQL вышел бы дешевле».
Вторая распространенная причина – использование сложных SQL-запросов и сильно кастомизированных конфигураций, с которыми производительность и надежность системы управления БД от Microsoft, по опыту участников опроса, оказывается выше конкурентов.
Тем не менее, и положительная динамика спроса на PostgreSQL это подтверждает, интерес к новостям в сфере управления БД в Сообществе сохраняется: «Регулярно тестируем альтернативные решения по производительности и удобству администрирования», – отмечает один из участников. Более того, PostgreSQL предпочитают ставить те, кто мигрирует с файловых СУБД на распределенных информационных базах, малый бизнес, для которого проприетарные лицензии слишком дороги, а также госсектор.
Факты о PostgreSQL:
Добавим, что статистически распределения ответов по всем остальным пяти вопросам для тех, кто в ответ на первый выбрал MS SQL, и для использующих преимущественно PostgreSQL очень похожи. Иными словами, организации, работающие на любой из обеих СУБД, в среднем по статистике – представители отраслевого бизнеса, с небольшими по объему БД, с невысокой нагрузкой и в основном пользуются Управлением торговлей, Управлением производственным предприятием и Бухгалтерией. В целом настроение Сообщества можно выразить комментарием:
«… за последний год сотрудничество 1С и PostgreSQL было довольно плодовитым, ожидаем, что в дальнейшем эта СУБД будет достойной альтернативой».
Масштабы нагрузки на систему
Точная оценка распределения Сообщества по степени нагрузки на используемые системы невозможна без подробного анализа архитектуры в каждом отдельном случае. Мы не ставили подобной цели в опросе, хотя нам удалось получить некоторое количество сведений в комментариях, необходимое для обзора.
Вместе с тем, мы полагаем, что таких параметров, как объем основной БД и число одновременно работающих с ней пользователей, достаточно для общего понимания того, с какими задачами сталкиваются владельцы и администраторы СУБД.
Чаще всего размер основной базы данных не превышает 50 Гб, причем это утверждение справедливо для всех трех опросов. Если говорить о тенденциях, то за прошедший год сократилось число компаний с небольшими БД до 10 Гб и стало больше тех, кто использует тяжеловесные базы, от 500 Гб. Так, в 2014 году крупными БД пользовались, согласно опросу, всего несколько человек, а спустя 4 года их стало 640, или 10% опрошенных. Поэтому сегодня основная база данных для 1С объемом от 1 Тб – уже не редкость.
Аналогичная тенденция наблюдается и с числом одновременно работающих с базой пользователей. Количество систем с нагрузкой от 50 пользователей и выше растет и уже составляет более 52%, в то время как систем с низкой нагрузкой становится заметно меньше. При этом, как демонстрирует опрос 2018 года, чем больше объем базы, тем, как правило, выше число одновременных ее пользователей на пике активности. Тем не менее, пока наиболее типичный порядок нагрузки на СУБД – от 10 до 50 параллельных пользователей.
Платформа и конфигурации
Действующая версия 8.3 платформы 1С:Предприятие вышла 29 мая 2013 года, поэтому не удивительно, что в нашем опросе 2014 года более распространенной среди респондентов была предыдущая версия 8.2. Впоследствии 8.3 набрала вес и с 2017 года является лидером рынка по использованию с основной БД организации.
Старая версия 7.7 до сих пор работает у ряда опрошенных (3,1%), но, как показывают результаты анкетирования и отмечают в комментариях сами респонденты, в основном на ней стоят небольшие файловые базы, в частности, для конфигураций 1С:Бухгалтерия и 1С:Управление торговлей.
Лидер опроса 2014 года среди конфигураций, согласно комментариям – 1С:Бухгалтерия, постепенно сдала позиции и сейчас уступает первое место Управлению торговлей. Также в тройке самых популярных решений – Управление производственным предприятием. Если учесть, что в этом году мы конкретизировали вопрос о конфигурациях и попросили указать те, что используются с основной СУБД, то резкое снижение доли Зарплаты и управления кадрами можно объяснить меньшими объемами данных в транзакциях по сравнению с номенклатурными базами. В целом же ЗУП остается решением, сопоставимым по популярности с лидерами наших опросов.
Также год за годом прибавляют вес самописные и отраслевые решения участников Сообщества, что, вероятно свидетельствует о росте компетентности штатных 1С-разработчиков российских предприятий. Помимо этого, как конфигурации с основным объемом транзакций набирают популярность 1С:ERP и Комплексная автоматизация, за последний год выросшие более чем в два раза.
Подводя итоги, следует отметить, что организации, работающие на платформе 1С, все чаще отказываются от файловой СУБД и в качестве основной системы выбирают MS SQL в тех случаях, когда позволяет бюджет, но есть ограничения по рискам, и PostgreSQL, когда размеры бизнеса невелики или есть соответствующие компетенции.
Объемы самих баз данных в среднем по Сообществу растут, как и число параллельных запросов, что вынуждает специалистов приобретать опыт работы с High-Load и ставит вопросы производительности и отказоустойчивости систем в первый ряд. В этом смысле многие участники выражают уверенность в PostgreSQL и решениях на ее основе как в достаточно хорошей альтернативе импортным СУБД.
Разрешается любое использование текста или его фрагментов с обязательным указанием первоисточника: «Информационно-аналитический центр «Инфостарт» (infostart.ru/public/967268/).
Специальные предложения
