Чем отличается sql база 1с от файловой

Когда переводить базу данных 1С на SQL?

Как известно программа 1С имеет две основных архитектурных реализации касательно хранения данных: файловая версия и версия на СУБД. Все знают, что файловая база подходит для работы нескольких пользователей малого предприятия, при условии что сама база также не большая, а для средних и крупных предприятий без СУБД не обойтись. Также очень типичны случаи, когда ведение учета начинается в небольшой файловой базе, а далее она начинает стремительно расти – увеличивается количество бизнес-процессов, которые автоматизируют данной программой, в следствии чего увеличивается количество пользователей, которые в ней работает, а также сама база. Со временем база начинает притормаживать и наступаем момент когда необходимо переходить на СУБД. Как же определить тот момент, когда стоит задуматься о переходе на SQL? Ведь сам переход и подготовка для него инфраструктуры требует немало времени, а также денежных затрат.

Предпосылки, которые заставляют задуматься о переходе на СУБД следующие:

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

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

Если в базе работает от 1 до 5 пользователей, то данная проблема практически не заметна, так как вероятность того, что в один момент времени к одной и той же таблице обратятся несколько пользователей невелика, но с каждым дополнительным пользователем эта вероятность возрастет.

Это что касается симптомов, которые могут указать на необходимость перехода.

Теоретически момент перехода возможно просчитать заранее. Производительность 1С зависит от 3 ключевых факторов:

• количества пользователей;
• типа конфигурации;
• объема базы.

Основным показателем, который влияет на производительность базы 1С является количество пользователей работающих с базой. Файловая база при количестве пользователей от 1 до 5 работает значительно быстрее чем СУБД и в таком случаи перевод на SQL повлечет не только дополнительные затраты, но и ухудшение работы системы.

При количестве пользователей порядка 5-10 работа файловой базы отличается от работы СУБД не значительно, после 10-15 пользователей производительность файловой базы очень сильно падает и если количество пользователей довести до 20-25 с базой практически не возможно будет работать по причине блокировок и очень сильному замедлению работы. Ниже приведены графики зависимости производительности 1С от количества пользователей для разных конфигураций.

Рисунок 1 — Схема работы с зашифрованной базой данных

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

Перенос файловой базы 1С в SQL

Продукты фирмы «1С» имеют два основных решения для хранения данных: файловая база данных и база данных, размещенная на SQL Server (поддерживается как Microsoft SQL Server, так и бесплатный PostgreSQL, Oracle Database, IBM Db2). Файловые базы данных как правило используют небольшие компании с 1-10 пользователями, при этом быстрого роста объема базы данных в среднесрочной перспективе не предвидится. Если у Вас “тормозит база 1С”, вы постоянно отмечаете рост пользователей или на этапе проектирования решения Вы рассчитываете на достаточно быстрый рост объема данных, Вам пора задуматься о переезде файловой базы 1С на SQL Server.

Не получается самостоятельно перенести файловую базу на SQL сервер? Обратитесь за консультацией к специалистам IT-Lite. Узнать подробнее об условиях предоставления услуг можно у специалистов компании по телефону: 8(495)646-23-16 или отправив запрос на почту: sales@it-lite.ru.

Как перенести файловую базу 1С в SQL?

Перенос базы 1С производится в режиме 1С “Конфигуратор”.

Для переноса файловой базы на сервер SQL необходимо выполнить следующие действия:

Открыть конфигуратор файловой базы.

Особые указания для настройки портов:

• Выбор портов осуществляется из диапазона от 10 000 до 60 000.
• Нужно исключить переключение с другими диапазонами.
• Пример выбора диапазонов: “ 23560:23591, 12560:12591”.
• Управляющий порт для работы из оснастки: 23540.
• Порт подключения из 1С: 23541.
• Пример подключения к кластеру 1С: “:23541; :23541”. Все настройки подключения к базам храниться здесь: *\Users\%username%\AppData\Roaming\1C\1CEStart\ibases.v8i

Создание специальных служб

• Запускаем командную строку от имени Администратора
• Команда: Sc create =»C:\Program Files\1cv8\8.3.4.465\bin\ragent.exe» DisplayName= type= own start= auto
• Вводим в командной строке команду “regedit”
• Находим строку
• Редактируем строку “ImagePath”
• Приводим строку “ImagePath” к виду: «C:\Program Files\1cv8\8.3.5.1098\bin\ragent.exe» -srvc -agent -regport 23541 -port 23540 -range 23560:23591 -d

Создание кластера 1С 8.3

Настройка кластера 1С 8.3:

• Подключаемся к первому серверу по порту: 23540
• Подключаемся ко второму серверу по порту: 23540
• На втором сервере удаляем полностью кластер:

Первый способ создания базы данных

Название базы в кластере 1С и на SQL сервере могут быть разные.
Заходим в директорию кластеры/локальный кластер/New/информационная база.

Указываем параметры информационной базы:

При отдельном сервере приложений 1С, адрес сервера баз данных может быть прописан в hosts.

Второй способ создания базы данных

Нажимаем кнопку “Добавить”.

Выбираем пункт “Создание информационной базы”.

Когда мы рекомендует перенос файловой базы на клиент-серверный вариант
Наша практика показывает, что файловые базы данных являются оптимальным решением, пока объем базы не превысил 3 Гб.

Чем отличается sql база 1с от файловой

Как часто в период отчетности ваша программа 1С дает сбой в работе? Зависает или долго выполняет операцию? Возможно случалось, что вы теряли данные из-за непредвиденного отключения электроэнергии? Предлагаем разобраться, как сделать программу 1С быстрее и безопаснее.

Работа в программах 1С:Предприятие 8 может быть организована в двух режимах: файловый и клиент-серверный.

Файловый режим работы 1С

Файловый вариант работы в 1С:Предприятие 8 сможет обеспечить корректную и оперативную работу системы, если в программе будет работать одновременно не более 3 человек.

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

Схема работы в файловом режиме

Для быстрого и безошибочного функционирования системы необходимо, чтобы все действия (запросы), которые совершает пользователь программы 1С:Предприятие 8, выполнялись на компьютере, который хранит базу данных. Однако в файловом режиме работы 1С:Предприятие 8 механизм реализации запросов иной:

1. Блокируется часть файла базы данных для других пользователей системы.
2. Заблокированные данные перенаправляются по локальной сети к клиенту.
3. Операция изменения выполняется на компьютере пользователя.
4. Измененная часть файла возвращается в место хранения.
5. Файл базы данных становится доступен остальным пользователям системы 1С:Предприятия 8.

Постоянный обмен большим количеством информации значительно тормозит работу всех пользователей. Чтобы ускорить работу и сделать ее стабильной, необходимо некое «звено», которое будет координировать и выполнять задачи пользователей. Такое «звено» реализовано в клиент-серверном режиме работы.

Клиент-серверный режим работы 1С (с базой данных на SQL)

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

Схема работы в клиент-серверном режиме

В отличии от файлового режима в клиент-серверном база данных состоит не из одного файла, а из множества разных файлов. Механизм реализации запросов пользователей в этом режиме следующий:

1. 1С:Сервер распределяет запросы к нужному файлу базы данных.
2. Определяет очередность выполнения операций.
3. Вносит изменения в базу данных.

В этом режиме ресурсоемкие операции выполняются на сервере, в месте хранения файлов базы данных, а не на компьютерах пользователей. Таким образом, для комфортной работы в программе 1С:Предприятие 8 будет достаточно только одной мощной машины. Задача компьютеров пользователей – отражение визуальной оболочки программы. С этим справится практически любой компьютер.

Клиент-серверный вариант позволяет:

1. Увеличить отказоустойчивость системы в случае экстренного отключения электропитания и большой загруженности локальной сети. Например, клиент-серверный режим работы позволяет настроить создание резервной копии базы данных каждые 30 минут прямо во время работы. Это значит, что даже если случится авария на сервере, будут потеряны данные только за полчаса, и уже через час ваша компания снова будет работать в обычном режиме.
2. Ускорить работу системы за счет отсутствия необходимости в постоянной транспортировке данных между компьютерами сети.
3. Предотвратить кражу данных пользователями системы 1С: Предприятие 8. База данных состоит из множества файлов, которые хранятся на сервере и управляются отдельной СУБД. Копирование файлов возможно только разрозненными частями, которые не дают какой-либо информативности. Для выгрузки базы данных в работоспособном формате необходим доступ с правами администратора к 1С:Серверу и СУБД.
4. Снизить риски повреждения базы данных. База статична – хранится и изменяется на одном компьютере, а значит повреждение во время транспортировки от пользователя к пользователю исключены.

Какой режим работы 1С выбрать – файловый или клиент-серверный?

Файловый режим работы в программах 1С подойдет небольшим компаниям, где одновременно работают в программе максимум 3 пользователя с базой данных до 2Гб.

Рекомендуем использовать 1С Сервер, если выполняется хотя бы одно из следующих условий:

• база данных больше 2Гб;
• количество пользователей 3 и более.

Что нужно сделать для перехода на клиент-серверный режим работы?

1. Купить программное обеспечение — лицензия для Сервера 1С:Предприятие
2. Выбрать СУБД:
   • PostgreSQL – бесплатная СУБД (Имеет большой ряд ограничений);
3. Настроить СУБД под работу с 1С, включая планы оптимизации и резервного копирования.
4. Установить 1С:Сервер и настроить администрирование.

Хотите получать подобные статьи по четвергам?
Быть в курсе изменений в законодательстве?
Подпишитесь на рассылку

Тестирование скорости работы 1C в режиме файловой версии, MS SQL и POSTGRES на HDD, SSD и RAMDisk

Мне всегда было интересно (и не только мне) есть ли смысл запуска 1С в диске из оперативной памяти, потому что если посмотреть на графики скорости чтения различных типов накопителей, то преимущества очевидны:

Замеры скорости чтения CrystaMark дисков, участвовавших в тестировании

Виртуальный диск из ОЗУ демонстрирует огромное преимущество над любым типом дисков, даже если бы мы использовали SSD с поддержкой NVMe PCI-express v4 (предлагаю дальше для упрощения просто указывать NVMe x3 для SSD на шине версии 3 и NVMe x4 с PCI-express версии 4) мы бы не смогли получить особого преимущества перед диском из оперативной памяти, так как это позволило бы только увеличить скорость записи больших файлов с 3521 Мб/сек до 5000, что все равно далеко от скоростей RAMDisk, но никак не повлияло бы на скорости мелких файлов и секторов, а в нашем случае это имеет важное значение. Кажется, что тестирование проводить смысла нет – исходя из графика сразу понятно кто аутсайдер, и кто победитель: заранее скажу что в целом – да, но не везде и не всегда, а жесткие диски списывать со счетов рано.

В связи с этим я решил сравнить скорость быстродействия 1C:Предприятие в различных способах управления информационной базой 1С: файловый вариант, MS SQL и POSTGRES. Тестирование проводилось поочередно на каждом из четырех накопителей. В качестве замера производительности применял два теста – перепроведение документов за одинаковый отрезок времени и формирование оборотной ведомости за 6 лет, различные синтетические тесты и «замеры производительности» не проводились ввиду того что они не всегда точно отображают реальную производительность.

В качестве тестового стенда применялся компьютер следующей конфигурации:

AMD Ryzen R9 3900X (12 ядер, 24 потока, 3800МГц)

32 Гб DDR4 Kingston FURY 2666МГц (4*8ГБ)

1ТБ Seagate 1000DM003

500 Гб Samsung 870EVO

500 Гб Samsung 970EVO

MS Windows Server 2019 Standard

Бухгалтерия для гос. Учреждений ПРОФ

СУБД POSTGRES SQL

Тестирование начнём с самого простого способа управления информационной базой 1С:Предприятия – файловый (меньше – лучше, время в мин:сек):

То что жесткий диск оказался самым медленным способом обработки информации это ожидаемо, отставание SATA SSD от NVMe x3 составляет существенные 20%, а виртуальный диск из оперативной памяти хоть и самый быстрый, но разгромного преимущества перед NVMe x3 нет: выигрыш в скорости примерно 10%, несмотря на огромную разницу в скорости чтения и записи, что касается скорости в перепроведении документов ситуация уже не такая однозначная (меньше – лучше, время в мин:сек):

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

Теперь перейдём к тестированию варианта взаимодействия с информационной базой 1C:Предприятия через СУБД MS SQL 2019:

СУБД SQL от Microsoft показывает отличную оптимизацию обработки информации по сравнению с файловым вариантом, в целом можно сказать что все время формирования отчёта для SSD обоих типов и RAMDisk одинаково и лежит в пределах погрешности, но если жесткий диск справился почти в 5 раз быстрее (+500%), то для SSD прирост скорости составил 100% для NVMe x3 и 250% для SATA SSD. Прирост скорости для RAMDisk составил «скромные» 75%.

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

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

Теперь проверим быстродействие 1С:Предприятие с POSTGRES:

POSTGRES SQL показывает отличную масштабируемость в зависимости от типа диска и, что необычно, формирование отчёта с СУБД POSTGRES при разворачивании базы на жёстком диске оказывается быстрее в 1,5 раза по сравнению с СУБД от Microsoft. Но если смотреть на график относительно твердотельных накопителей (SSD), то, конечно, Microsoft SQL предпочтительнее. В случае с RAMDisk разницы нет.

Последний тест отлично показывает отсутствие целесообразности использования RAMDisk для размещения СУБД. Так как этот диск виртуальный и он создаётся посредством программного обеспечения, то наблюдается аналогия с программными и аппаратными RAID массивами: программные массивы обслуживаются вычислительными мощностями ЦП, стабильность и скорость работы целиком зависит от грамотности и правильности кода соответствующего программного обеспечения для создания диска из ОЗУ, аналогичная ситуация справедлива и для физических дисков: когда для создания RAID массивов применяется аппаратные средства, снимается с ЦП задачи по обслуживанию RAID, что положительно сказывается на общей производительности массива и отпадает зависимость от качества работы программного обеспечения сторонних разработчиков. В случае создания виртуального диска из оперативной памяти используется программное обеспечение, что накладывает определенные ограничения на работу данного диска, что и подтверждает тестирование – чёткой стабильности в производительности нет в отличие от физических накопителей. Но, как бы то ни было, последний тест в очередной раз подтверждает преимущество NVMe SSD накопителя перед другими типами дисков.

Проведенное тестирование показало преимущество СУБД MS SQL над POSTGRES и общее преимущество обоих типов СУБД над классическим способом работы 1С:Предприятие – файловым. Смысла использования RAMDisk нет от слова совсем – да, прирост в скорости в файловом варианте составляет примерно 12% от самого быстрого диска, но экономической целесообразности нет — в среднем 32 Гб ОЗУ DDR4 стоит 180$, а 500 Гб SSD NVMe x3 (в тестировании применялся SSD Samsung 500 Гб 970EVO) стоит 120$, разница в стоимости при пересчете Гб/$ составляет 5,6$ за гигабайт для ОЗУ и 0,24$ за гигабайт для SSD. Переплата в 23 раза (2300%) ради 12% производительности лишь в нескольких случаях смысла не имеет.

Отдельного внимания заслуживает СУБД POSTGRES SQL – в отличие от СУБД Microsoft она бесплатная, но в среднем увеличивает скорость работы с 1С в два раза, на мой взгляд неплохое предложение для недорогого (не забываем что необходимо для любого варианта использования SQL требуется приобретение лицензии на сервер 1С) но эффективного ускорения работы 1С:Предприятие. Что касается СУБД Microsoft SQL Server – это самый быстрый и эффективный способ обработки информации в 1С:Предприятие, да, он не бесплатный, но даёт прирост до 50% по сравнению с POSTGRES.

Что касается дисков, то, разумеется, SSD новейших форматов NVMe x3 (и x4) является наиболее предпочтительным вариантом — этот тип диска в связке с СУБД MS SQL даст наибольший прирост производительности, но если у вас стоит задача добиться значительного увеличения скорости работы 1С с минимальными затратами – можете смело использовать связку POSTGRES и старый добрый HDD.

В заключение, предлагаю ознакомиться с краткой таблицей сравнительного тестирования:

Сравнение скорости работы 1C+MSSQL и файлового варианта

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая?

Затем обычно идет «флуд» на несколько десятков страниц.

Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд.

В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнениях.

Мы предлагаем разбить вопрос на несколько:

1. Работает ли файловый вариант быстрее в операциях «монопольного характера», когда его деятельность не зависит от других пользователей в базе?

Под «монопольным характером» мы будем понимать одного активного (работающего) пользователя в информационной базе.

2. Работает ли файловый вариант быстрее в многопользовательском режиме, когда пользователи активно конкурируют за ресурсы (например при проведении реализации товаров обращаются массово к остаткам на складе)?

3. Насколько существенна разница в скорости между файловым вариантом и клиент-серверным с точки зрения бизнеса?

Что на самом деле

Таблица №1. Сравнение файлового и клиент-серверного варианата 1С

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

Ответ на первый вопрос: Работает ли файловый вариант быстрее в операциях «монопольного характера», когда его деятельность не зависит от других пользователей в базе — с вероятностью 99% файловый вариант работает быстрее (при условии его возможности не ограничиваются неудачным железом и не достигаются максимальные возможности файлового варианта)!.

Не верьте нам на слово — проверьте сами. Возьмите ОДНОПОТОЧНЫЙ тест (подробное описание здесь http://www.gilev.ru/tpc1cgilv/ ) и убедитесь сами (проверьте сначало в файловом варианте, затем клиент-серверном).

Если Вы не верите тесту, то протестируйте подходящую для проверки по вашему мнению операцию также в файловом и клиент-серверном варианте. Мы рекомендуем за основу взять например «закрытие месяца» на базах размером до 4х гигабайт (иначе на файловом варианте может достигнуто ограничение по размеру).

Понятно, если у Вас закрытие месяца в файловом варианте не возможно, то обсуждать преимущества файлового варианте для Вас нет смысла, Вы согласны?

Возникает еще один промежуточный вопрос:

А насколько файловый вариант быстрее клиент-серверного в цифрах?

Ответ на этот вопрос куда интересней и практичней. Наш тест и практика показывают:

1. на среднестатитических операциях на соизмеримых объемах данных почте в 2 раза быстрее
2. на среднестатитических операциях когда объемы данных начинают превышать объем доступной оперативной памяти и увеличивая интенсивность подкачи — до 3-4х раз быстрее — это как раз пример закрытия месяца

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

Причем даже безобидный отчет при построении тоже может писать данные, ну например в служебную базу данных tempdb в случаи использования MS SQL Server.

При выполнении запроса в файловом варианте нет посредника данных в виде Сервера 1С, т.е. на один сегмент прохождения запроса меньше. Логично, что если например выполнять «работу без посредников» она всегда быстрее «работы с посредниками».Кроме того, существенная часть функционала на стороне СУБД тоже фактически является «посредниками» — они нужны например не только выполнения запросов, но чтобы обеспечить лучшую параллельность для работы других запросов — например максимально скрупулезно наложить блокировки на используемые данные, чтобы не заблокировать «лишнего» как это делает файловый вариант. Наложить блокировку на всю таблицу проще, так как это одна запись с информацией о блокировке, а наложить блокировки на тысячи строк — это на порядке больше дополнительных записей, но что еще важнее это существенно больше затрачиваемых ресурсов (процессора, памяти, а иногда и места на диске).

Другими словами, клиент-серверный вариант требует больше ресурсов чем файловый для одной и той же работы по объему.

Отсюда следствие — на одном и том же компьютере можно сделать В МОНОПОЛЬНОМ РЕЖИМЕ больше работы в файловом варианте, чем в клиент-серверном (в том же монопольном режиме).

В итоге вроде как клиент-серверный вариант может сделать меньше работы, требует больше ресурсов, а где же «профит», почему он используется практически везде?

Поможет ответить нам второй вопрос нашей статьи: работает ли файловый вариант быстрее в многопользовательском режиме, когда пользователи активно конкурируют за ресурсы (например при проведении реализации товаров обращаются массово к остаткам на складе)?

В таблице номер №1 мы видим такие существенные недостатки файлового варианта как маленький размер баз данных — на большинстве предприятие базы данных 1С занимают десятки-сотни гигабайт. Но еще важнее, что файловый вариант накладывает избыточные блокировки (лишние), что существенно снижает возможность параллельной работы пользователей.

Итак, для пример на предприятии работает 100 пользователей 1С. В день для ровного счета предположим что каждый пользователь вводит равномерно в течении всего дня 10 документов, а каждая табличная часть содержит 10 строк.

Мы получаем простую арифметику — 100 х 10 х 10 =10 000 строк вводится в информационную систему в течения дня.

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

В клиент-серверном варианте это сработает. Документы проведутся параллельно.

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

Мы знаем что по умолчанию длительность таймаута блокировки 20 секунд. Теоретически можно предположить что кроме первого пользователи все последующие будут друг друга ждать по 20 секунд и затем проводить свои документы. Суммарное ожидание составит 100 пользователей х 1 документ х 20 секунд = 2000 секунд ожидания. Чувствуете — это полчаса простоя пользователей.

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

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

Более того, при попытке 2,3 документы угубят картину и за день даже при идеальном коде файловый вариант «накопит» 100 пользователей х 10 документов х 20 секунд = 20000 секунд

5 c половиной часов простоя.

5 часов — эта фора клиент-серверного варианта. Даже не важно с какой скоростью в каждом потоке в клиент-серверном варианте они будут вводиться. Важнее что они вводятся, а в файловом варианте в это время происходят ожидания на избыточных блокировках.

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

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

И снова призываем не верить нам на слово. Возьмите 1С:Стандартный Нагрузочный Тест http://v8.1c.ru/expert/etp.htm или разработайте свой коллективный тест и убедитесь сами с достоверности наших утверждений.

Теперь ответим на третий вопрос:Насколько существенна разница в скорости между файловым вариантом и клиент-серверным с точки зрения бизнеса?

Файловый вариант несильно опережает клиент-серверный вариант в монопольном режиме и очень существенно проигрывает в многопользовательском режиме.

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

Файловый вариант не имеет механизмов контроля целостности данных. Например, если произойдет сбой в сети при передачи данных, или отключится свет, то в файловом варианте что то успеет записаться, а что нет. Целостность данных будет разрушена. В клиент-серверном варианте в подобных случаях просто произойдет откат незавершенной транзакции, и неполных данных в систему не попадет, целостность данных будет сохранена.

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

А теперь надо задать «правильный вопрос»:

4. Почему возник вопрос оценить разницу в скорости файлового и клиент-серверного варианта?

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

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

Правильный ответ заключается в том что неважно насколько быстрее файловый или клиент-серверный вариант, а важно что именно вызывает замедления в каждом КОНКРЕТНОМ случае. Слово ПРОИЗВОДИТЕЛЬНОСТЬ опасное, так как на самом деле его надо расписывать в виде списка операций в системы, которые в совокупности и формируют это производительность. Надо рассматривать каждую операцию, начиная с той, которая создает наибольший вклад в замедления.

База данных 1С: Файловая или серверная. Что выбрать?

База данных – это условно говоря, совокупность всевозможной информации (документы и прочее), структурированная определенным образом.

Существует множество разновидностей баз данных, классификаций и так далее.

Что касается 1С, то она имеет два варианта работы с базой данных:

• файловая
• клиент-серверная

Для каждой есть свои сферы применения и у каждой есть свои плюсы и минусы. Рассмотрим каждый вариант подробнее.

Файловая база данных

Данный вариант базы данных предназначен для малого количества пользователей (1-5). Одной из ключевых особенностей данной базы является хранение всей информации в одном файле, что во многом порождает и минусы использования такого варианта. Работу файловой базы можно также организовать через веб-сервис (обмен через ftp, http, https и пр.). Алгоритм работы выглядит следующим образом:

По такому алгоритму работает каждый пользователь

К плюсам данного варианта можно отнести следующее:

• Относительная дешевизна;
• Проста в использовании и настройке;
• Отсутствует необходимость в дополнительном программном обеспечении;
• Оптимально для небольшого количества пользователей (1-5);

Однако минусы такого варианта весьма существенны, а именно:

• Существенное снижение быстродействия при размерах базы свыше 6-10 Гб;
• Наличие блокировок базы данных при одновременном обращении к ней. «Ошибка блокировки данных» и т.д.;
• Вычисления происходят на компьютере пользователя, что повышает требование к комплектующим каждого рабочего места;
• Не работают регламентные задания в случае отсутствия активных пользователей;
• Наличие свободного доступа к файлу базы данных пользователями, что небезопасно;
• Низкая отказоустойчивость. Банальное отключение электричества может привести к повреждению базы и потере данных;

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

Клиент-серверная база данных 1С

Это трехуровневая система, основанная на архитектуре «клиент-сервер». При таком варианте клиентская часть 1С делает запрос не напрямую базу, а через сервер на котором установлен Сервер 1С:Предприятие и уже сервер обращается к базе данных, которая находится под управлением СУБД (система управления базой данных), а вычисления производятся на сервере. Сервер 1С:Предприятие работает с такими СУБД как:

• Microsoft SQL Server
• PostgreSQL
• IBM DB2
• Oracle Database

Подходит для более крупных организаций (более 5 пользователей). Однако, некоторые ее качества являются существенным преимуществом, даже при малом (меньше 5) количестве пользователей. В упрощенном виде, алгоритм работы пользователя с клиент-серверной базой выглядит следующим образом:

Таким образом, сам принцип построения базы на клиент-серверной архитектуре даёт следующие преимущества:

• Распределение нагрузки за счет использования Сервера 1С;
• Широкие возможности по созданию резервных копий базы данных;
• Высокая отказоустойчивость;
• Работа регламентных заданий даже при отсутствии активных пользователей;
• Практически нет ограничения по размеру базы данных;
• При одновременной работе нескольких пользователей на порядок выше производительность по сравнению с файловой базой;
• Низкие требования к комплектующим клиентских компьютеров, т.к. все вычисления производятся на сервере;
• Нет свободного доступа к базе данных.

К минусам можно отнести:

• высокая стоимость;
• сложнее в настройке.

Но существует вариант, который позволяет небольшим организациям пользоваться преимуществами использования клиент-серверного варианта базы данных 1С за вполне разумные деньги. Таким решением выступает продукт «1С:Предприятие 8.3. Сервер МИНИ на 5 подключений» в сочетании с СУБД PostgreSQL. Индивидуальное решение по переходу на клиент-серверную версию базы вам помогут подобрать наши специалисты. Уточнить детали вы можете по телефону + 7 8652 333 003.

В каком случае необходимо переходить от файловой базы на SQL?

В каком случае необходимо переходить от файловой базы на SQL?

1. пока скорость работы будет устраивать.
2. пока база не разрастётся более 10 ГБ, а по факту размер 1cv8.1cd ограничен 20 ГБ.
3. пока не появится желание более надёжно защитить базу от сбоев, ведь в формате sql сбои в структуре БД редко бывают.

Prikum ,в моей практике, аналогичная база никак не хотела разворачиваться в файловом варианте, но это было ещё на платформе 8.3.8 (если правильно помню). Может сейчас по-другому уже стало.

Читают тему:

Мероприятия

• Где купить СОФТ
• Вакансии фирм-партнеров "1С"

• Центры Сертифицированного Обучения
• Интернет курсы обучения «1С»
• Самоучители
• Учебный центр № 1
• Учебный центр № 3

• Сертификация по «1С:Профессионал»
• Организация обучения под заказ
• Книги по 1С:Предприятию

• WWW.1С.ru
• 1С:Предприятие 8
• 1С Отраслевые решения
• Образовательные программы
• 1С:Линк
• 1С:Консалтинг
• 1С:Дистрибьюция
• 1С для торговли
• 1С-Онлайн
• 1С Интерес
• 1С:Образование
• 1С:Торговая площадка
• 1C:Игры
• 1Софт
• ИТС.1C.ru

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

Редакция БУХ.1С не несет ответственности за мнения и информацию, опубликованную в комментариях к материалам.

Редакция уважает мнение авторов, но не всегда разделяет его.

Дизайн сайта

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