1с какая субд
Перейти к содержимому

1с какая субд

  • автор:

Выбор СУБД для 1С

Анна Викулина

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

Варианты работы 1С

Для начала стоит рассказать о специальном режиме работы 1С, в котором вообще не нужна внешняя СУБД. Речь идет о файловом режиме, в котором роль СУБД и сервера выполняет встроенный в 1С механизм. Это бюджетный вариант ведения учета, так как нет необходимости приобретать сервер и лицензии на него. Но данный вариант используется достаточно редко из-за небольшой скорости работы, низкой надежности и собственных ограничений 1С:

  • Все таблицы представлены в виде 4 отдельных файлов, размер каждого из которых не может превышать 4 Гб:
    1. Описание таблицы;
    2. Индексы;
    3. Значения неограниченной длины;
    4. Записи.
  • Ограничения длины ключа в индексах и количества полей для индексации;
  • Возможные проблемы с выполнением регламентных заданий в ранних версиях 1С;
  • Отсутствие возможности одновременного проведения документов;
  • Прямой доступ пользователей к базе данных – любой сотрудник может случайно удалить ее или сделать копию.

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

На сегодняшний день системы 1С официально поддерживают следующие виды:

  • Платная MS SQL. Также существует бесплатная модификация MS SQL express edition, но у нее действует ограничение на размер базы данных – до 10 гб. Для удовлетворительного ведения учета компании этого явно недостаточно, поэтому этот вариант больше подходит для разработчиков;
  • Платная Oracle BD;
  • Бесплатная IBM DB2;
  • Бесплатная PostgreSQL.

Особенности различных СУБД

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

  1. Небольшой размер БД постепенно растет по мере поступления новых данных;
  2. По умолчанию 1 файл с данными и 1 с логами;
  3. Требовательна к ресурсам;
  4. Нетребовательна к квалификации администратора, хорошо интегрируется с продуктами от Microsoft;
  5. Максимальное количество таблиц, используемых в запросе, ограничено 256.

Следующая из платных СУБД – Oracle BD:

  1. Высокие требования к квалификации администраторов;
  2. В подзапросах нельзя использовать конструкции «ПЕРВЫЕ» и «УПОРЯДОЧИТЬ»;
  3. При сортировке NULL ставится в конец таблицы;
  4. Статистические данные планов запроса ресурсозатратны.

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

  1. Требования к квалификации существуют, весьма желательно понимать основные принципы и структуру БД;
  2. Достаточно требовательна данная СУБД и к ресурсам, но не как MS SQL;
  3. При сортировке NULL по умолчанию находится в начале таблицы. Но с помощью оператора NULLS LAST можно убрать эти значения в конец таблицы;
  4. Необходимость частой реиндексации при интенсивной работе;
  5. Требовательность к скорости записи и чтения жестких дисков;
  6. Полное внешнее соединение работает намного медленнее, чем в других СУБД;
  7. Облачные базы 1С:Фреш работают как раз на этой СУБД.

Об IBM DB2 можно сказать следующее:

  1. Средняя требовательность к квалификации специалистов;
  2. При создании базы резервируется место «на будущее» – базы «весят» существенно больше;
  3. Слабые возможности механизма временных таблиц, благодаря чему требования к ресурсам пониженные. Также скорость работы снижается и при использовании подзапросов;
  4. В операции like или подобно запрещено использовать шаблоны;
  5. В выборке не может быть более 1012 колонок;
  6. При группировке и сравнении различает регистр;
  7. Нетипизированное значение NULL;
  8. Ограничения длины ресурсов регистров и чисел.

К выбору СУБД нужно подходить весьма ответственно, не теряя из виду все важные факторы. При возможности стоит посоветоваться с профессионалами, уже имевшими опыт работы с базами на вышеперечисленных системах. Также стоит опираться на количество пользователей в вашей компании и сложность системы 1С. Практика администраторов 1С показывает, что производительность бесплатных СУБД ниже, чем MS SQL или Oracle.

СУБД для 1С Fresh. Быстро. Надежно. Бесплатно

Кнопка уже несколько лет для работы с бухгалтерскими базами использует технологию публикаций 1C Fresh. Мы уже недавно писали о нашем опыте эксплуатации. Использование нами в качестве СУБД PostgreSQL вызвало интерес и ряд вопросов, поэтому мы решили рассказать об этом подробнее.

image

Введение

В самом начале мы использовали в качестве СУБД традиционный для 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.

А еще мы меряем количество транзакций:

image

И количество добавленных, измененных и удаленных строк:

image

В эксплуатации СУБД мы внимательно следим за нашими показателями и все настройки, приведенные ниже, родились именно из реальной эксплуатации и наблюдений. У нас сейчас 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 задана команды оболочки, например:

archive_command = ‘test ! -f /wal_backup/db_01/%f && cp %p /wal_backup/db_01/%f’

Таким образом мы копируем архивные сегменты 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, а точка останова будет сразу после достижения этого времени.

Заключение

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

Картинка про надежность связки 1C Fresh и PostgreSQL:

image

У нас более 350 Гб информационных баз отлично себя чувствуют, растут и развиваются. Чего и вам желаем!

Выбор СУБД для 1С — файловая или SQL?

Инструкция по переходу с файловой базы на SQL

Подведем итоги

НОВОСТИ

Облачные программы «1С» со скидкой 50%

Акция "Лето подарков"

Межвузовская олимпиада «Что, где, когда» II тур

Отзывы о компании

ПАО «НИКО-БАНК» выражает свою благодарность за оперативную и грамотную работу.
В условиях постоянно меняющегося законодательства Банк заинтересован иметь полную и актуальную номативную базу. Это обеспечивается использованием Банком справочно-нормативной системы «Гарант».
Безусловным плюсом в работе компании «МастерСофт» является быстрое реагирование сотрудников при предоставлении документов по запросу Банка, принятых до обновления справочно-правовой системы.

Коллектив компании «АЭРОПОРТ ОРЕНБУРГ» выражает благодарность за взаимовыгодное сотрудничество с МастерСофт-ИТ. Оперативная поставка антивирусных программ Dr. Web обеспечила надежную защиту нашей компьтерной сети.
Особая благодарность сотрудникам Департамента продаж СЦ ИТ за профессиональный подход в решении всех возникающих задач.

ООО «Орский Вагонный Завод» выражает искреннюю благодраность за качество обслуживания вашими специалистами. Консультации и поставка антивирусов всегда проходят оперативно и на высоком профессиональном уровне.
Уверены, что и в дальнейшем наше сотрудничество на взаимовыгодных условиях продолжится.

Главный бухгалтер муниципального бюджетного учреждения дополнительного образования «Дворец творчества детей и молодёжи» Кетерер Татьяна Михайловна выражает благодарность специалистам МастерСофт:
«Я хотела бы объявить благодарность вашим сотрудникам. Работает с нами по программе «1С: Бухгалтерия бюджетного учреждения 8» непосредственно Шевлягина Юлия.
Так же огромная благодарность за отзывчивость, терпение и квалифицированную, своевременную помощь Набокиной Олесе и Ерёменко Татьяне (они нас сопровождают по программе «Зарплата и Кадры»).
Им очень с нами тяжело, но они терпеливо продолжают сотрудничать. С вами очень надёжно. Конечно же наши ошибки есть и без вас мы бы вообще о них не знали и в суде, наверное, судились бы. А сейчас мы решаем вопросы. «.

Добавить комментарий

Ваш адрес email не будет опубликован.