Разделяй и обновляй! Экономим место, время и ресурсы сервера 1С

    В прошлый раз мы рассказали, как изменялись наша инфраструктура и принципы работы с базами 1С, коих у нас бесчисленное множество уже полтысячи, и про то, как мы автоматизируем работу с таким количеством данных. Однако, трудности и костыли всё ещё есть, и с ростом числа клиентов Кнопки нам приходится придумывать новые и улучшать старые способы оптимизации. Одна из основных проблем при работе с большим количеством баз 1С — накатывание обновлений. Сегодня мы расскажем о технологии разделения данных, которая позволяет уменьшить количество баз и упростить их обслуживание.



    Найти документацию по механизму разделения баз достаточно трудно: есть небольшая статья на основополагающем сайте, но нам она принесла мало пользы. Есть старый добрый Гугл, но чтобы разобраться в тонкостях, придётся долгими часами бороздить выдачу в поисках нужного куска информации. У нас другого выбора не было, а у вас теперь есть эта статья. Надеемся, она пригодится.

    Хватит это терпеть!


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

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

    Не стоит забывать и о том, что в каждой отдельной базе живёт её величество Конфигурация, которая не отличается от базы к базе ни на байт. Живёт и ест место, при том, что в конфигурацию так же нужно загружать изменения, вставлять обработки и расширять стандартную функциональность.

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

    Базовая сегрегация


    Для начала, нужно определить признак, по которому вы будете разделять базу. Разделитель может иметь любой тип данных, мы используем строку длинной 10 символов: ИНН организации. Главное — название разделителя (общего реквизита) не должно совпадать с уже существующими объектами конфигурации, то есть его нельзя назвать, например, «Организации», так как уже есть такой справочник. Мы назвали разделитель «Группа компаний».

    После этого берём вашу типовую конфигурацию с пустой базой, заходим в конфигуратор и открываем раздел «Общие реквизиты». Добавляем общий реквизит и меняем значение «Разделение данных» на «Разделять»:



    Конфигуратор предложит создать параметры сеанса — безмолвно соглашаемся и идём дальше. После создания «Общего реквизита» с включённым свойством разделения, база данных становится похожа на многоэтажный дом. В доме есть элементы доступные всем и с каждого этажа: лифт, лестничный пролёт, коммуникации, а есть что-то уникальное, доступное только в пределах этажа: квартиры, коридор, окна. Метафора простая, и, надеюсь, понятная:)

    Для входа в определённую организацию (или область базы) необходимо сообщить разделитель в строке подключения к базе или указать его в v8i файле (о которых мы рассказывали в прошлый раз).

    [Кнопка 7710967300 БУХ РБ]
    Connect=Srvr="%servername%";Ref="%base_name%";
    AdditionalParameters=/Z "-0,-0,+7710967300";
    


    После /Z указываем общие реквизиты по порядку. Так как в нашей типовой бухгалтерии уже есть два общих системных реквизита, указываем для них значение -0 чтобы они не использовались, а в качестве третьего (который мы создали) передаём ИНН.

    1000 и 1 чекбокс


    Теперь нужно определить, какая часть данных будет являться общей для всех областей. Всё это настраивается через конфигуратор. В свойствах общего реквизита, который мы только что создали, есть пункт «Состав» открывающий небольшой список из 800 параметров:



    Подбор параметров оставляем на ваше благоразумие, усмотрение и окружение. Вот наш вариант (аккуратнее, там 20 000 пикселей).

    Разделитель также даёт возможность настроить отдельный список пользователей для каждой базы — это может пригодиться, если у вас сотни пользователей — при входе в определённую базу не придётся проматывать этот список до кровавых мозолей. Мы это не используем, потому что настроили прозрачную авторизацию.

    Выгружаем данные из текущих баз


    Для выгрузки данных из текущих баз, мы используем универсальный XML-обмен. Нельзя просто так взять и выгрузить базу, нужно настроить правила обмена, иначе при загрузке могут (и обязательно возникнут) ошибки и конфликты, а вторая база просто не пролезет. Напомним, что мы делим области базы для каждой организации и в нашем случае работают такие правила обмена. Если вам вздумается использовать другой разделитель, придётся пораскинуть мозгами и чекбоксами. Главное — не использовать типовую выгрузку — это приведёт к дублированию всех предопределённых записей.



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


    Загружаем данные в разделённую базу


    Запускаем 1С с параметром /Z «-0,-0,+%ваш разделитель%», указывая разделитель той организации, данные которой собираемся загрузить. Запускаем универсальный обмен и скармливаем ему полученные при выгрузке файлы: сперва справочники, потом документы. Повторяем эту операцию для каждой базы-области.



    Чтобы упростить задачу, мы осуществляем выгрузки массово, предварительно запуская чуть исправленную стандартную обработку через командную строку (/Execute c:\выгрузка.epf). Затем вручную загружаем полученные файлы в разделённую базу.

    Как потратить больше времени, чтобы потратить меньше времени


    Процесс разделения — штука не быстрая. Напомним, что у нас сейчас больше 500 организаций, но за пару недель мы успели разделить только 70. Однако, мы точно знаем, что уже через полгода поблагодарим прошлых себя за проделанную работу и кучу сэкономленных времени и сил.

    Бухгалтеры Кнопки не замечают перехода организаций из обычной базы в разделённую, для них процесс проходит безболезненно. Попа горит только у админов:)

    Побочные эффекты: экономия места 1 к 20, косвенное увеличение скорости работы — неоценимо. В абсолютных цифрах: 50 организаций занимают 2 Гб пространства в SQL, тогда как одна отдельная база занимает от 800 Мб.

    Обещанная ложка дёгтя, даже четыре:


    • если кто-то из пользователей запорол данные в одной организации, приходится откатывать назад всю разделённую базу — нельзя просто взять и откатить одну область данных
    • приходится более тщательно тестировать обновления, особенно те, которые добавляют или изменяют справочники
    • если нужно передать базу клиенту (или слить налоговой:), приходится делать обратную процедуру: выгружать организацию из разделённой базы при помощи универсального обмена, затем загружать в пустую обычную базу и из неё сохранять в.dt-файл
    • в разделённой базе нельзя управлять регламентными заданиями (например, не получится автоматически обновить курсы валют)

    Первые три ложки не такие горькие — они просто заставляют нас быть более внимательными. А вот что делать с четвёртой мы пока не знаем, но усердно исследуем.
    Кнопка
    46,00
    Компания
    Поделиться публикацией

    Комментарии 20

      +1
      в разделённой базе нельзя управлять регламентными заданиями (например, не получится автоматически обновить курсы валют)
      .
      Не понятно, что именно вы хотели добиться. У вас проблемы с разделенными регламентными заданиями или с общедоступными? На вашем скрине видно, что ни регламентные задания, ни регистр курсов валют вы не разделяли — т.е. у вас сейчас у всех компаний разделенной базы одна и та же информация. Более того, кто-то один может под себя исправить курс, а другие при закрытии месяца могут поймать необъяснимые курсовые разницы (гипотетически конечно; уверен — вы учли этот фактор).

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

        По поводу необъяснимых глюков если кто-то что-то поправит — конечно мы об этом подумали — мы так не делаем =) Объяснение наверное звучит как то слабовато, но вы попробуйте, это правда работает!

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

        В реальности, в режиме конфигуратора при входе в область вам недоступно ни одно действие, на любой чих вы получаете ошибку «Действие недоступно при установленном разделении данных» — ни открыть конфигурацию ни выгрузить в dt данные области это не позволяет. Возможно в более старых версиях это работало.
          0
          Я в этом деле понимаю мало… Но, как бы не сталось так, что: в скорости появится версия 1С 8.4. Что Вы будете творить со всеми этими «костылями»? — Я как Администратор, с 6ти летним опытом, уже пережил: 1с77,1с81,1с82. B скорости будет 1с83. А так конечно — очень, очень круто! Куча фирм, и всего 2гб в MSSQL, это-ж и бесплатной версией можно пользоваться для этого. :)
            0
            Смена версии платформы мало влияет на то что мы настроили.
            Внутри версии 8.3 мы обновляем её прозрачно, с версии 8.2 на 8.3 я сам обновлял конфигурации через простую конвертацию (встроенную в конфигуратор), а на 8.4 если и нужно будет переходить, то либо будет тот же «конвертатор» — либо через перезагрузку в DT.
              0
              Дай Бог, дай Бог, чтобы такие вещи проходили «гладко». А то сами представляете, насколько это опасно всё.
        +1
        Хозяйке на заметку: справочники и документы лучше выгружать отдельно — так можно избежать лишних ошибок в момент загрузки.

        Тут тоже как-то непонятно… В чем сакральность разделения правил? Для гарантирования ссылочной целостности? Это просто нелепо! Тогда нужно и все документы-сделки вынести в отдельный файл правил. На самом деле никогда не было проблем с выгрузкой всех данных одним единым правилом. (заявляю как автор почти десятка работающих правил синхронизации данных между различными восьмерочными, а так же между семерочными и восьмерочными конфигурациями) Может вы хотите таким образом как-то сбалансировать объемы выгружаемых действий? Но мой опыт говорит, что размер первички в несколько порядков превышает данные НСИ. Так что вижу тут абсолютно бесполезное действие. Более того, вероятен человеческий фактор и вы как-нибудь сначала загрузите вторую пачку и получите либо справочники-пустышки, либо битые ссылки (в зависимости от настроек).
          0
          Вы не поверите… Но в какой то степени именно для сохранения ссылочной целостности! =)
          При загрузке больших баз в разделённую область мы частенько ловили ошибки, переход на режим мухи отдельно от котлет справочники отдельно \ данные отдельно исправил такое поведение.

          Загрузка у нас тоже вот вот будет в автоматическом режиме — что минимизирует человеческий фактор. Мне показалось что тема перелива данных через различные механизмы выходит за рамки статьи и\или заслуживает отдельной. И к тому же утверждать что мы что-то делаем не руками, когда на самом деле мы делаем это руками — не честно. Пишем как есть, если кто-то продвинется дальше нас (и потом ещё и статью напишет) будет здорово!
          0
          Формально, можно экономить на лицензиях, так как каждый бухгалтер будет запускать несколько копий одной базы, а не десяток разных.

          Не очень понятно как происходит экономия лицензий. Если у вас лицензии раздает сервер, один сеанс будет использовать одну лицензию. И неважно отдельные это базы или одна разделенная.
          Экономить на лицензиях можно менеджером лицензий. Если им раздавать лицензии, одна лицензия действует на один клиентский компьютер независимо от количества открытых баз или количества открытых сеансов.
            0
            Спасибо за замечание. Почитал ещё раз условия лицензионного соглашения, согласен с вами — наш текст звучит не однозначно (и скорее всего релевантный только для наших условий). Внесу правки в статью.
            0
            Немного не по теме вопрос.
            Подскажите пожалуйста, как лучше организовать базы в 1с, если в одной сети сосуществуют две организации (но с одним общим гендиром, главбухом). Вести учет в одной базе, но по различным организациям или завести две отдельные базы?
              0
              Думаю переход в одну базу, не важно разделённую или нет, зависит скорее от:
              1. Как ведётся учёт в этих организациях? Одинакового или нет?
              2. Одинаков ли план счетов?
              3. Кто работает с базами, один и те же пользователи?
              4. Нужно ли видеть сводные отчёты, сальдооборотки?
              Если на все пункты (наверняка это не всё, но больше я сходу не могу припомнить) ответ «нет» — то лучше не объединять.
              Плюс нужно учесть размеры баз, если большие — то лучше не объединять.

              Так же советую поговорить об этом с бухгалтером — она, наверняка, может сказать свои доводы, к которым стоит прислушаться.
                0
                ОК. Спасибо за список. Будем думать.
              +1
              Исследовал в свое время возможности разделения данных в БСП-подобных конфигурациях. В БСП есть встроенные механизмы выгрузки и загрузки данных в область.
              Выгрузка через ОбщаяФорма.ВыгрузкаДанных, загрузка через ОбщаяКоманда.ЗагрузитьДанныеВОбласть

              Не нашел один момент. Может вы сталкивались. Существует ли возможность выполнения запроса по нескольким разделенным областям из сеанса с выключенным разделением?
                +1
                Вот ответ от нашей замечательной программистки:
                «Если разделитель включен в режиме „независимо“, тогда возможности обратиться в одном запросе к нескольким разделенным областям нет. Надеемся, что в ближайших релизах платформы такая возможность появится.»
                0
                А вот если бы 1С была устроена немного иначе. Скажем, каждая база не содержала бы метаданные, а только хранила бы данные пользователей. А конфигурация располагалась бы на сервере где-то в другом месте (в файлах md как в 7.7 или на SQL сервере в отдельной базе метаданных).
                Тогда можно будет создавать несколько баз одной конфигурации, а при обновлении конфигурации чтобы проходило автоматическое обновление всех баз этой конфигурации.
                И еще так же отдельно хранились бы пользователи.
                  0
                  Разделение данных именно для этого и создано. Данные многих организаций лежат в одной общей для них конфигурации. Пользователей так же можно разделить. Не мечта — но вполне себе съедобный кактус.
                    0
                    В случае отдельных баз могли бы решиться некоторые проблемы, например эти:
                    • если кто-то из пользователей запорол данные в одной организации, приходится откатывать назад всю разделённую базу — нельзя просто взять и откатить одну область данных
                    • если нужно передать базу клиенту (или слить налоговой:), приходится делать обратную процедуру: выгружать организацию из разделённой базы при помощи универсального обмена, затем загружать в пустую обычную базу и из неё сохранять в.dt-файл
                  0
                  А кто-нибудь экспериментировал с вьюхами на КЛАДР в соседней, специально выделенной базе (вместо отдельных таблиц в каждой из используемых баз)?
                    0
                    Вы не сталкивались с ситуациями, когда на реальных данных в работающей базе:
                    1. Нужно разделенный по областям данным объект (например, регистр накопления) сделать общим.
                    2. Обратная операция — нужно общий объект, разделить по областям данных.
                    Как вы действуете в этом случае?
                      +1
                      … очень не рекомендую менять структуру данных уже после начала эксплуатации. В целом сказать, что случится в вашем случае сложно, но мы пару раз ловили после обновления такое:
                      1. Слетели проводки части документов во всех или некоторых областях
                      2. Наши разделённые объекты вдруг стали общими — те что мы разделили потерялись
                      3. Наши общие объекты улетели в одну из областей — остальные области перестали запускаться.

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

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

                    Самое читаемое