Как работает 1С размером 13 ТБ в условиях непрерывной разработки

Публикация № 1216620

Разработка - Обмен данными 1С - Перенос данных из 1C8 в 1C8

Обеспечение быстрого непрерывного обмена данными между высоконагруженными системами 1С, покрывающими всю территорию России, требует ответственного подхода к архитектуре и инструментам, используемым для обмена. Как правильно построить такую инфраструктуру и научиться ее оперативно мониторить, в своем докладе на конференции Infostart Event 2019 Inception рассказал разработчик компании «ДНС Ритейл» Максим Старков.

Меня зовут Максим Старков, я работаю в команде управления системами 1С компании «ДНС Ритейл». Наша команда занимается вопросами, связанными с эксплуатацией систем, реализованных на платформе «1С:Предприятие».

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

 

Задачи команды эксплуатации

 

 

Итак, перед командой эксплуатации стоит множество задач. Но мы выделяем три основных:

  • Первая – это обеспечение непрерывного и быстрого обмена данными между всеми связанными системами, которые покрывают всю территорию Российской Федерации.
  • Вторая – обеспечение ежедневного обновления конфигурации в рамках отведенного технологического окна
  • И третья – обеспечение мониторинга работы систем для раннего выявления проблем и их устранения.

Итак, давайте я по каждой задаче поделюсь некоторым опытом.

 

Архитектура системы базового обмена данными

 

 

Большой бизнес всегда предполагает большой объем данных. Эти данные нужно собирать, сохранять, обрабатывать, а также обмениваться ими между всеми связанными системами.

  • Оценить объем данных в компании ДНС достаточно сложно. Он зависит от многих факторов. Но в среднем можно сказать, что за одну итерацию обмена между двумя узлами уходит около 50 Мб данных.
  • Обмен выполняется каждые 15 минут. В итоге за один день между двумя узлами проходят миллионы объектов.
  • Из всех систем можно выделить основную – мы называем ее центральной или управленческой базой данных. Она состоит из головного узла и 9 подчиненных территориально распределенных узлов. Это классический вариант распределенной базы данных. На данный момент размер основного узла центральной базы составляет 13Тб. Региональные узлы имеют размеры от 1 до 2 Тб данных.
  • Кроме этого, у нас также есть и другие системы. Это – склад, сайт, система продаж и бухгалтерия. Со всеми этими системами нам нужно обмениваться.

 

 

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

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

Если с планами обмена все понятно, то зачем нам понадобился дополнительный регистр сведений? Он нам нужен для того, чтобы в нем регистрировать изменения тех объектов, которые при выгрузке и загрузке должны с собой забирать связанные данные, чтобы в момент загрузки в единой транзакции загрузить не только сами данные, но и все, что с ними связано. Таким образом, мы обеспечиваем целостность загружаемых данных в базах источниках.

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

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

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

 

 

Далее – формируем пакет обмена:

  • При записи информации в пакет обмена мы используем свои XML-узлы и атрибуты XML-узлов. Они понадобятся нам в дальнейшем, когда мы эти данные будем считывать.
  • Чтение данных в базах-приемниках мы выполняем в параллельном режиме.
  • Специальные XML-узлы и атрибуты предназначены для того, чтобы наши алгоритмы параллельного чтения распределяли порции из пакетов и загружали их параллельно. На рисунке можно увидеть, что у нас в каждом XML-узле есть атрибут Order, и при считывании в базе-источнике все данные, которые в нем находятся, распределяются между пулом потоков, который реализован на основе фоновых заданий. Здесь тоже ничего удивительного нет.

Таким образом, мы умеем быстро выгружать и загружать данные, поддерживая продолжительность цикла обмена не более 15 минут. На самом деле, получается значительно быстрее.

 

Apache Kafka для обмена данными по изменениям цен

 

 

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

Изначально все эти данные передавались через систему базового обмена. Но она не могла справиться с такой нагрузкой и замедляла обмен другими объектами.

Было принято решение вынести этот контур обмена в отдельную систему, и в качестве транспорта для этой системы мы решили использовать брокер сообщений Apache Kafka.

 

 

Совместно с командой администрирования мы разработали следующую архитектуру нашего зоопарка Kafka. Вкратце ее можно описать так:

  • у нас есть три кластера Apache Kafka, распределенных по разным регионам всей России;
  • в каждом кластере – по три брокера;
  • в каждом брокере есть три темы;
  • и в каждой теме – по 10 разделов (партиций);
  • данные в кластере синхронизируются по брокерам с помощью внутренних механизмов Apache Kafka (обычно это репликация, а у нас – тройная репликация).
  • Также мы синхронизируем данные между кластерами. Из коробки Kafka этого делать не умеет. Но есть прекрасная утилита MirrorMaker, с помощью которой у нас, по сути, три наших кластера хранят в себе одни и те же данные, и географически распределены по всей России.

 

 

Что мы делаем дальше?

  • Когда происходит изменение цен, мы записываем эти данные в соответствующую тему. Кроме этого, мы формируем хэш для записи. То есть указываем ключ, который определяется по наборам характеристик номенклатуры. Таким образом, каждая номенклатура с определенным набором характеристик всегда попадает в одну и ту же партицию (или в раздел). Я уже говорил, у нас их 10, и это – жесткая настройка. Если мы изменим количество разделов, у нас, конечно, все «уедет». Или придется как-то останавливать обмен, и все это приводить в порядок.
  • Для чего нам нужно соблюдать соответствие номенклатурных позиций определенным партициям? Это нужно, потому что Kafka не гарантирует порядок записи сообщений в одной теме. Гарантия записи сообщений есть только в том случае, когда мы пишем в один и тот же раздел. Таким образом, мы храним в Kafka историю цен. Там есть небольшой промежуток времени, за который хранится вся история цен.
  • Дальше, для работы с Apache Kafka и 1С мы решили использовать Rest Proxy интерфейс от разработчиков Kafka (фирмы Confluent). Он бесплатен, любой может его поднять. И в принципе можно работать с Apache Kafka из 1С без внешних компонент, используя стандартное HTTP-соединение. Возможно, это работает не так быстро, как компоненты от известных на Инфостарте людей, но очень хорошо работает.

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

 

 

Каждый кластер хранит в себе данные цен всех других регионов. Поэтому чтение цен других регионов выполняется очень быстро:

  • с помощью Apache Kafka мы получили некое централизованное хранилище цен, отдельную систему;
  • данные по ценам больше не нагружают основной обмен – он работает, как и раньше;
  • значительно сократилось общее время от момента изменения цены до синхронизации этих данных между всеми системами. Также получили большой плюс, что к нашему хранилищу цен на Kafka могут подключаться и другие системы – это система продаж, сайт и вообще, кто угодно.

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

 

Автоматизация обновления конфигураций

 

 

Следующая задача нашей группы эксплуатации – это автоматизация обновления конфигураций.

  • У нас много программистов, они выполняют очень много помещений (коммитов) в хранилище – порядка 30 в день, иногда даже значительно больше.
  • И бизнес говорит нам, что мы должны обновлять конфигурацию баз данных каждый будний день.
  • Но с этим есть одна проблема – время для обновления (допустимое технологическое окно) – с 6 до 7 утра по времени Владивостока.

 

 

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

Архитектурно, система автоматического обновления имеет:

  • служебную конфигурацию на платформе 1С:Предприятие
  • и специальное приложение, написанное на C#, которое установлено в качестве службы на всех рабочих серверах кластеров 1С, которые у нас есть.

 

 

На скриншотах вы можете видеть функциональность служебной конфигурации.

 

 

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

В принципе, это можно сделать с помощью технологического журнала и его определенных настроек, которые есть на партнерском форуме. У кого нет доступа к партнерскому форуму, эти настройки можно найти на Инфостарте.

 

 

В технологическом журнале мы получаем событие System, в котором выводится вся нужная информация – какие объекты метаданных будут реструктуризированы, какая это будет реструктуризация – полная или не полная. Кроме этого, у нас есть накопленная статистика по времени реструктуризации тех или иных таблиц баз данных.

 

 

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

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

 

 

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

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

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

  • она закрывает соединения с базой данных;
  • в случае необходимости удаляет сеансы, которые «зависли»;
  • при необходимости может даже рестартануть службу (бывает такое, что сеансы могут остаться – например, в случае какого-нибудь длительного отката транзакции, когда сеанса уже нет, соединение с базой данных будет держаться, и соединение в кластере тоже будет жить).

Такой механизм позволяет в течение часа (в период технологического окна) обновить нашу конфигурацию во всех узлах – центральный узел и все 9 узлов, от Дальнего Востока до Калининграда.

В итоге мы умеем контролировать процедуру автоматического обновления.

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

 

Мониторинг систем

 

 

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

Для мониторинга мы используем несколько подходов:

  • во-первых, это сбор логов работы приложений;
  • второе – это сбор показателей производительности оборудования и серверов;
  • и третье – это сбор собственных метрик.

 

Сбор логов приложений 1С

 

 

Мониторинг работы приложений у нас реализован следующим образом:

  • Наш основной рабочий инструмент – это, конечно, технологический журнал платформы 1С. Мы его очень активно применяем.
  • На каждом рабочем сервере у нас настроен вывод всех важных событий технологического журнала, а также собираются все события длительностью более 1 секунды. Наш технологический журнал получается довольно массивным, но мы не храним большой период, нам важно оперативно решать проблемы и иметь небольшую историю – хотя бы месяц.
  • Для обработки данных технологического журнала мы используем стек технологий EBK (Elasticsearch, Beats и Kibana).
  • Большая часть анализа выполняется автоматически. У нас есть список определенных запросов в Elasticsearch, результаты которых говорят нам о том, что что-то пошло не так: либо появились какие-то управляемые блокировки, либо runtime-ошибки, либо непонятные перезапуски рабочих процессов и т.д.

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

Всю работу можно описать следующим образом – с помощью сборщика логов Filebeat мы отправляем данные с каждого рабочего сервера в Elastic.

 

 

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

В том числе мы добавляем свои поля – log_type, log_timezone (так как у нас распределенная система, нам обязательно нужно указывать временную зону, иначе у нас появляется неразбериха).

 

 

Обработкой поступающих данных занимается сам Elastic. В нем есть прекрасная возможность Ingest Node – она по умолчанию уже задействована и работает. Если Elastic состоит из нескольких служб, то Ingest Node можно назначить на любой из серверов, из которых состоит кластер. С помощью настроенного Pipeline Ingest Node умеет парсить данные техжурнала.

 

 

С помощью pipeline мы разбираем запись лога технологического журнала на определенные фрагменты – выявляем оттуда:

  • длительность;
  • имя события;
  • номер сеанса;
  • контекст;
  • description в Exception и много других параметров.

В принципе вы можете найти такой pipeline в интернете, чтобы ничего не изобретать – он там есть. Там только одна хитрость – Filebeat и Elasticsearch будут по умолчанию записывать данные в техжурнал с тем временем, с которым Filebeat их отправил. Но нам нужно точное время из записи самого техжурнала, а для этого нужно поработать над этим pipeline, чтобы вырезать данные, склеить их и записать настоящее время.

 

 

В итоге все это выглядит вот так – мы анализируем информацию с помощью Kibana (визуализатор для Elasticsearch). У нас в Kibana настроено много каких-то своих отборов, агрегаций. В том числе есть различные дашборды.

 

 

Кроме этого, иногда возникает необходимость собрать более подробные данные технологического журнала. Например, мы исследуем проблемы с производительностью какого-то механизма, какого-то фонового задания, или какой-то пользователь вдруг начал жаловаться на производительность. В этом случае мы формируем в файле настроек технологического журнала отдельный узел, где указываем отдельное местонахождение для вывода файлов технологического журнала в отдельный каталог. И Filebeat, когда производит чтение из этого каталога, шлет эти данные уже не в основные индексы технологического журнала, а в специальный индекс трассировки. Это сделано для того, чтобы мы не загрязняли в Elasticsearch данные нашего технологического журнала данными наших трассировок. Потому что вероятно, что-то может задублироваться или показать какие-то лишние срабатывания.

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

Анализ технологического журнала в реальном времени позволяет нам моментально и оперативно реагировать на возникающие проблемы.

Анализируется действительно море информации. У нас в постоянном режиме происходит оповещение мессенджера – что сейчас происходит с базой данных, есть ли блокировки, какие-то Runtime-ошибки.

Кроме этого, Runtime-ошибки мы выводим напрямую в отдельный чат для разработчиков. К сожалению, в 1С не статическая типизация, и возникает очень много Runtime-ошибок, которые просто невозможно предусмотреть (всевозможные «Поле объекта не обнаружено» и т.д.). Эти ошибки моментально выявляются с помощью технологического журнала.

 

Мониторинг состояния обменов данными

 

 

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

На карте каждый узел имеет определенный цвет.

  • Если он зеленый, значит, итерация обмена этого узла занимает менее 15 минут времени.
  • Если он красный и мигает, то итерация обмена превышает 30 минут, и нам нужно на это как-то реагировать.
  • Желтый цвет означает, что мы находимся между 15 и 30 минутами.

Карта интерактивна, она также выводится на большом мониторе, также на вторых мониторах наших коллег. Карта реализована на HTML и JS, а бэкэндом является служебная конфигурация на 1С.

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

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

И, наконец, если какой-то узел задерживается с обменом на более чем 15 минут, мы получаем уведомления в наши чаты и мессенджеры.

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

 

Мониторинг СУБД

 

 

Дальше – мы также мониторим ситуацию на СУБД.

  • Единственное, что мы можем мониторить – это блокировки и длительные запросы.
  • У нас есть несколько инструментов, но основной из них – это десктопное приложение, написанное на C#, которое получает данные о сеансах со всех наших серверов СУБД, и в случае появления конфликтов блокировок или длительных запросов выводит необходимое уведомление на рабочий стол.
  • Однако этот инструмент ничего не знает об управляемых блокировках, которые в текущем времени можно мониторить только с помощью технологического журнала или периодически опрашивать консоль серверов. Но так как информация из технологического журнала у нас собирается в режиме реального времени, то все сообщения о проблемах мы получаем моментально. В том числе видим пространство блокировок в случае возникновения ошибок, и какой сеанс кому мешает. Эти оповещения, конечно, происходят не при возникновении какого-то одного конфликта блокировок (это для наших объемов допустимо), но есть определенный уровень, выше которого мы считаем, что уже есть проблемы.

 

Сбор показателей производительности

 

 

Мониторинг работы оборудования и показателей производительности.

  • Для сбора показателей производительности работы серверов и оборудования мы используем обычные инструменты, но данные храним в базе данных InfluxDB.
  • Для анализа и оперативного оповещения используем Grafana.

Это – классические инструменты, поэтому я думаю, что про них не очень интересно рассказывать.

 

Сбор собственных метрик

 

 

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

  • Мы сразу отказались от очередного регистра сведений или, тем более, журнала регистрации. И решили отправлять произвольные метрики из кода посредством протокола UDP. Это, конечно, спорная тема, но UDP гораздо быстрее, чем TCP. Но 1С не умеет работать с UDP напрямую, поэтому мы реализовали внешнюю компоненту и некий небольшой интерфейс, написанный на 1С, который каждый разработчик может вставлять в свой код и отправлять через UDP определенные данные.
  • Метрики мы храним в ClickHouse. Это отличная база данных, но она, к сожалению, тоже не умеет читать протокол UDP.
  • Поэтому для чтения UDP мы используем промежуточное звено – это logstash. Он из коробки умеет слушать UDP-порт и принимать на него данные. Также есть плагин, который позволяет выливать данные из logstash в ClickHouse. Его нужно немного покрутить, но он стартует довольно быстро. В итоге мы умеем слать в ClickHouse произвольные метрики прямо из кода, и при этом не создавать почти никакую нагрузку на основную базу данных.
  • Единственное, UDP предполагает, что возможны потери пакетов. Но наше нагрузочное тестирование показало, что потери пакетов начинаются только при сверхвысокой нагрузке. Но такая нагрузка – это, видимо, уже совсем другой уровень.

Кроме событий открытия форм, таким образом, мы собираем и замеры времени.

Кстати, ClickHouse очень хорошо умеет агрегировать данные. Мы отсылаем сначала первое событие, а потом, например, после окончания проведения – второе. У них есть одинаковый GUID, и ClickHouse умеет это все клеить, соединять между собой и находить дельту по времени.

Таким образом, мы в текущем времени мониторим, например, время проведения всех документов.

На слайде вы видите хитрый график, выведенный через Grafana. Здесь разноцветными точками представлены различные типы документов. Это – распределение, показывающее, с каким временем происходит проведение этих документов.

 

Заключение

 

 

В итоге наша система мониторинга и те подходы, которые мы применяем, позволяют нам решать быстро и оперативно проблемы, возникающие с производительностью и со стабильностью работы системы. А также иметь данные, на основе которых мы выявляем потенциальные проблемы и предективно их устраняем.

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

В заключение могу сказать, что эксплуатировать такую огромную распределенную систему на платформе 1С:Предприятие – это реально.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. ogre2007 236 27.03.20 16:59 Сейчас в теме
В ДНС магазинах раньше были 1С, а сейчас у них веб клиенты, без признаков 1С.
6. max_st 66 27.03.20 21:57 Сейчас в теме
(1)Система продаж, которая используется в магазинах работает не на 1С. Это свой внутренний продукт на C#. В докладе об этом не стал уточнять. На 1С работает своя ERP система для бэк-офиса.
2. Rustig 1412 27.03.20 18:59 Сейчас в теме
3. Xershi 953 27.03.20 19:19 Сейчас в теме
Так 13 ТБ это рабочая база или все узлы?
И как данные размазаны?
Про КОРП платформу ничего не сказано или материал написан, до дня Х?)
4. Torin 231 27.03.20 20:02 Сейчас в теме
(3)
На данный момент размер основного узла центральной базы составляет 13Тб. Региональные узлы имеют размеры от 1 до 2 Тб данных.
user1315860; Lansi; max_st; +3 Ответить
5. Torin 231 27.03.20 20:13 Сейчас в теме
(0) Очень интересно кто!! и как часто анализируется информация? и сколько человеко/часов используется для этого
7. max_st 66 27.03.20 22:00 Сейчас в теме
(5)У нас есть отдел, который занимается мониторингом и эксплуатацией всей системы. Часть информации анализируется автоматически. Расклад по затратам трудовых ресурсов раскрывать не стану, но скажу, что в отделе менее 10 человек.
8. Torin 231 27.03.20 22:04 Сейчас в теме
(7) Коллега.я о другом..такой большой объем информации анализировать..в любом случае нужно визуально... Очень интересная тема. Не в онлайн режиме же они мониторят..как баг листы ведут..как документируют.
10. max_st 66 27.03.20 22:13 Сейчас в теме
(8)Ответил в корень ветки, ошибся)
9. max_st 66 27.03.20 22:12 Сейчас в теме
Объем информации действительно большой, но 2/3 информации поступает от внутренних систем автоматизации мониторинга, т.е. информация уже агрегирована и мы можем понять по её поступлению, что нам нужно делать далее.
В рабочее время можем следить за информацией в режиме он-лайн.
Документация по инцидентам и сам факт их появления учитывается во внутренней системе учета задач.
Конечно же, еженедельно просматриваем логи и метрики вручную, чтобы выявить что-то особенное.
В планах, начать использовать систему для автоматического выявления аномалий в метриках и логах. Работаем над этим.
acanta; Torin; +2 Ответить
11. muskul 28.03.20 05:21 Сейчас в теме
Не сразу понял что 13 ТЕРА байт и по 2 ТЕРА байта каждый узел. впечатляет.
12. baracuda 2 28.03.20 10:02 Сейчас в теме
молодцы, что тут сказать) я думал что 1Гб это большая база, а тут такое)
13. neuromancer_aza 45 28.03.20 14:11 Сейчас в теме
(12) 1 Гб это пустая база УНФ уже. Кажется пора начинать привыкать к большим цифрам.
14. dexxxqqq 28.03.20 14:19 Сейчас в теме
(13) 640 килобайт хватит всем
15. acanta 74 28.03.20 15:09 Сейчас в теме
Подскажите пожалуйста, правильно ли я поняла, что на перифериях и в центре конфигурации одинаковые и разница только в данных? Клиент никак не связан с центральной базой 1с в режиме онлайн?
21. Rustig 1412 28.03.20 23:08 Сейчас в теме
(15) я сначала подумал, что так - по крайней мере начинали они наверное именно так, что ЦБ и периферия были схожими конфигурациями. Потом штат разработчиков рос, задачи усложнялись, конфигурации ЦБ и периферии стали отличаться... Для этого они сами формируют xml-пакеты обмена, сами их распознают при загрузке, сами переопределили алгоритм задания номеров сообщений... Я думаю, что клиент не связан с ЦБ в онлайн-режиме.
16. hamsar 9 28.03.20 15:32 Сейчас в теме
Непонятно как вы поступаете, когда в регистре на млрд записей все таки надо добавить измерение
20. Rustig 1412 28.03.20 23:02 Сейчас в теме
(16) не знаю как они, а я бы сразу создал новый регистр с новой логикой. Если для старых сведений измерение не нужно было использовать, значит и в старый регистр не надо его вставлять. Создаем новый регистр с новой логикой, в котором сведений еще не млрд записей.
33. alex_art 14 30.03.20 00:31 Сейчас в теме
(20)
а потом джойним\подзапросим все вновь созданные РСы с самым первым РСом для получения достоверных сведений за весь период существования этой бизнес логики. При этом не забываем, что связанных РСов столько, сколько раз было необходимо добавить новое измерение :))))))))))))
34. Rustig 1412 30.03.20 09:09 Сейчас в теме
(33) вам новый регистр в таком случае, конечно, не поможет... мое предложение не для вашего случая, к сожалению. А для тех, когда это допустимо при прочих условиях.
50. Vortigaunt 74 21.04.20 23:51 Сейчас в теме
(33) Ну мы так делаем. Не вижу ничего плохого в таком подходе. Я конечно не имею ввиду базу таких размеров. С такими объемами и близко не сталкивался. В таком случае новый регистр и сам по себе часто оказывается логичным и к месту. Вот вам пример. Есть у нас конфигурация где в регистр сведений записываются все продажи, каждая позиция. За длительное время этот регистр разрастается очень сильно. Встала задача прикрутить оплату банковской картой. Надо где-то хранить информацию об оплатах картой чеков. Для этого заводим новый РС: Оплаты картой. И связываем со старым РС по полям: Касса, Номер чека и т.п. Бонусом имеем возможность хранить более 1 транзакции оплаты на 1 чек. А также имеем в отдельном месте историю всех транзакций.
51. alex_art 14 22.04.20 09:29 Сейчас в теме
(50)
Есть у нас конфигурация где в регистр сведений записываются все продажи, каждая позиция. За длительное время этот регистр разрастается очень сильно. Встала задача прикрутить оплату банковской картой. Надо где-то хранить информацию об оплатах картой чеков. Для этого заводим новый РС: Оплаты картой. И связываем со старым РС по полям: Касса, Номер чека и т.п. Бонусом имеем возможность хранить более 1 транзакции оплаты на 1 чек. А также имеем в отдельном месте историю всех транзакций.

Это все ужасно :)))) я думал только у меня архитектурный коллапс.
23. user612295_death4321 29.03.20 09:04 Сейчас в теме
(16) Вроде были ответы на вопросы, где Максим отвечал, что они используют подмену таблиц (подсовывается пустышка без данных, которую 1С воспринимает как родную таблицу).

Вот примерно по такому же принципу https://infostart.ru/public/199018/ .
35. max_st 66 30.03.20 09:12 Сейчас в теме
(23)Да, именно так и поступаем.Исследуем возможности умной реструктуризации в новых версиях платформы. Пока результаты положительные, планируем переход.
acanta; hamsar; +2 Ответить
38. hamsar 9 30.03.20 09:24 Сейчас в теме
(35)
(23)Да, именно так и поступаем.Исследуем возможности умной реструктуризации в новых версиях платформы. Пока результаты положительные, планируем переход.


Спасибо за ответ!
52. tormozit 5789 02.05.20 08:15 Сейчас в теме
(35) Перешли на новую штатную реструктуризацию? Вот это будет супер интересно - узнать опыт ее эксплуатации на таких объемах данных. Механизм до сих пор в статусе Бета видимо потому, что мало обкатки.
53. rinat_alp2 51 04.05.20 12:07 Сейчас в теме
(52) Еще не перешли, тестируем новую реструктуризацию с точки зрения больших объемов, например:
1) При добавлении в регистр накопления реквизита новый механизм использует alt er table add column и это быстро, но при добавлении измерения или ресурса происходит пересчет таблиц итогов (создание новых и удаление старых).
Если таблицы итогов небольшие, то это не страшно, но они могут быть и большие.
2) Если таблица регистра накопления была создана давно (поле _Period с типом datetime) и добавить хотя бы реквизит, то это вызовет конвертацию типа поля _Period в datetime2(0).
Что на больших объемах не успеет в технологическое окно: переливка значения через update, создание новых индексов и перестроение кластерного индекса, пересчет таблиц итогов.
Сейчас конвертируем понемногу datetime на datetime2(0).
17. insurgut 189 28.03.20 18:06 Сейчас в теме
Или я пропустил, или осталась нераскрыта тема конфигурации сервера под базу в 13ТБ. Интересно было бы конфигурацию узнать (о:
ansh15; zabaluev; +2 Ответить
39. max_st 66 30.03.20 09:37 Сейчас в теме
(17)Давайте кратко расскажу:

Процессор Intel® Xeon® Platinum 8160M CPU @ 2.10GHz, 2095 МГц, ядер: 24, логических процессоров: 48 - две штуки
Диски Micron 9200 SSDs (with NVMe) - много :)
Intel® Optane™ SSD 900P/905P Series - для tempdb и логов транзакций.
Память - 1,5 ТБ.

Это конфигурация основного сервера с центральным узлом.
На регионах конфигурации попроще, но справляются.
firma_unix; insurgut; +2 Ответить
48. user846987 02.04.20 12:35 Сейчас в теме
(39) для tempdm рекомендую использовать RAM, если конечно объем памяти позволяет взять хороший запас на рост базы.
http://winramtech.atwebpages.com/RAMDriv/main/try_buy_on.htm

рекомендую и стоит 11$ и работает на серверах до 2016

Мы используем уже давно, более 1,5 лет. Без сбоев.
(39)
18. CheBurator 3413 28.03.20 21:48 Сейчас в теме
"Если с планами обмена все понятно, то зачем нам понадобился дополнительный регистр сведений? Он нам нужен для того, чтобы в нем регистрировать изменения тех объектов, которые при выгрузке и загрузке должны с собой забирать связанные данные, чтобы в момент загрузки в единой транзакции загрузить не только сами данные, но и все, что с ними связано. Таким образом, мы обеспечиваем целостность загружаемых данных в базах источниках."

- то есть следует читать так - использование штатных возможностей планов обмена не позволяет обеспечить целостность данных?
или я что-то принципиальное не понял?
19. Rustig 1412 28.03.20 23:00 Сейчас в теме
(18) штатные не позволяют. вообще нет такого понятия "штатные" возможности. План обмена - это объект метаданных, дальше логику его использования надо программировать самим. Пример - аналогия с любым другим объектом метаданных: справочники или документы, регистры расчета, регистры бухгалтерии ...
36. max_st 66 30.03.20 09:16 Сейчас в теме
(18)Да, именно так. В файле обмена все такие данные собраны в одном xml-узле, обработка которого происходит в единой транзакции. Самый простой пример - документ и его движения.
zhichkin; +1 Ответить
22. acanta 74 28.03.20 23:53 Сейчас в теме
Если в РИБ регистрация обмена очищается в момент получения ответа, то в случае с произвольным планом обмена ( кроме разнесения связанных данных по различным объектам архитектуры) очистка регистрации выполняется в момент выгрузки и для повторной передачи утерянного пакета необходимо повторно зарегистрировать изменения?
А ответ получателя на регистрацию изменений не оказывает никакого влияния.
Возможно, в БСП есть механизм, дополняющий функционал планов обмена контролем ответов (в виде регистра сведений).
24. acanta 74 29.03.20 09:32 Сейчас в теме
Я пришла к выводу, что в 1с8 предъявляются особые требования к связи между периферией и центром отправителем и получателем -"не уверен, что получатель поймет правильно загрузит пакет - не выгружай", отсюда сравнительно небольшая известность конвертацией и высокая популярность "единой базы", т.е комплексной, ЕРП и т.д. которая лично мне совершенно была непонятна.
Но в случае с большими данными, когда все упирается в физические ограничения это особенно интересно в плане широковещания, когда кд3 ставит задачу просто выгружать по формату.
Но почему при таких мощных возможностях рлс так низка популярность РИБ (логично же ли эти рлс использовать как ограничитель данных при обмене с привязкой к узлу РИБ - или оно так не работает?).
25. infina15 29.03.20 12:42 Сейчас в теме
А была бы правильная архитектура - незачем было бы и подвиги совершать.
27. roman72 185 29.03.20 13:52 Сейчас в теме
(25) Похоже на критику ради критики, без предложений. Какая архитектура была бы "правильной" в описанном случае?
user846987; Fox-trot; +2 Ответить
28. infina15 29.03.20 15:39 Сейчас в теме
(27) а это же было на самом инфостарте в сентябре. После доклада были вопросы к Максиму и команде, где Максим согласился с тем, что если бы изначально данные лежали не в регистре бухгалтерии (который и занимает почти все 13ТБ), то и не было бы никаких 13ТБ. Собственно, под архитектурой я понимаю иной способ расположения данных, использование нескольких регистров вместо одного, например. Поэтому это пример вынужденного геройства, команда решила проблему большого костыля. Безусловно они молодцы, что справились с такой трудной задачей. Но будь выбрана другая архитектура, повторюсь, было бы все проще.
acanta; zhichkin; +2 Ответить
30. roman72 185 29.03.20 19:43 Сейчас в теме
(28) Ааа, спасибо за ответ. Мимо моего внимания проскользнуло, что 13ТБ засажено именно в регистр бухгалтерии. Кстати упустил и то, что непонятно на какой же конфигурации 1С строит свою архитектуру в DNS автор статьи, если опорой избран регистр бухгалтерии. ERP? Но там регистр бухгалтерии не является держателем всей информации. БП3?
31. infina15 29.03.20 20:26 Сейчас в теме
(30) вроде УПП была, но точно не помню.
32. roman72 185 29.03.20 23:53 Сейчас в теме
(31) УПП уже к 1ТБ кошмар для производительности..... Короче, Станиславский, не верю, не УПП у них ))) Может автор объявится и уточнит?
37. max_st 66 30.03.20 09:20 Сейчас в теме
(32)Конфигурация у нас самодельная. Типовые конфигурации только для бухгалтерии и расчета заработной платы.
В регистре бухгалтерии у нас примерно 60% данных из всего объема. И это в основном индексы на таблицах итогов и движений.
Такая архитектура сложилась "исторически", мы делаем все возможное, чтобы сохранять технический долг в рамках разумного. Но все равно - приходится работать с тем, что есть сейчас.
infina15; +1 Ответить
42. roman72 185 30.03.20 13:10 Сейчас в теме
(37) Спасибо за ответ. А эта самописная конфигурация работает с расширениями? И потом, если она самописная, то архитектуру её вы сами можете преобразовывать без оглядки на 1С.
44. max_st 66 30.03.20 14:16 Сейчас в теме
(42)Конфигурация на обычных формах, поэтому пока не можем в полной мере использовать расширения.
Считаем, что пока справляемся с действующей архитектурой, но что можно быстро поменять - меняем.
Вопрос архитектуры конечно же важный, но очень много того, что сложилось "исторически".
Чуть ниже Димтрий Жичкин хорошо прокомментировал вопрос относительно архитектуры)
41. zhichkin 623 30.03.20 11:20 Сейчас в теме
(25) Правильной архитектуры не бывает - это миф. Оптимальной архитектура может быть только в отдельно взятый момент времени. Архитектура должна быть адаптивной, меняясь вместе с организацией, процессами и т.д. Это особый вид искусства.
Отличная книга по этому поводу: Complex Enterprise Architecture: A New Adaptive Systems Approach
46. starik-2005 2135 30.03.20 15:18 Сейчас в теме
(41)
Правильной архитектуры не бывает - это миф.
Все зависит от точки зрения. ИТ-архитектура конкретного решения должна отвечать требованиям к решению. Исходя из подхода CMMi, например, очевидно, что правильная архитектура - это совокупность лучших практик (на сейчас) в части доступа к данным, их предоставления пользователю, ... поддерживаемость, расширяемость, минимальная избыточность...

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

Часто архитектурные проблемы - это проблемы заимствования типовых систем. Там все в куче, а реально используется из этого 5% функционала даже в очень больших системах, т.к. в у владельцев таких систем свое понимание бизнес-процессов, которое очень сильно отличается от понимания разработчиков типовых. И все ключевые элементы переработаны и дополнены основательно.
genayo; Il; acanta; zhichkin; +4 Ответить
29. suggestive 266 29.03.20 16:52 Сейчас в теме
Спасибо за кейс, интересный опыт! А вариант вести учет в одной базе рассматривали? Что за конфигурация, типовая или самописная?
40. max_st 66 30.03.20 09:41 Сейчас в теме
(29)По конфигурации ответил выше.
Вести учет в одной базе для нас уже не имеет особого смысла, текущая система работает.
Это дает нам возможности масштабирования - филиалы могут почти полноценно работать в своих базах.
Жесткие зависимости от центрального узла выявляем и пытаемся исправлять, но некоторые операции пока сильно завязаны на центральный узел.
43. roman72 185 30.03.20 13:11 Сейчас в теме
(40) Если несложно, можете озвучить список операций, сильно завязанных на центральный узел?
45. max_st 66 30.03.20 14:17 Сейчас в теме
(43)Не могу раскрыть эту информацию.
47. starik-2005 2135 30.03.20 18:12 Сейчас в теме
(43)
писок операций, сильно завязанных на центральный узел
То, что не может быть обработано обособленно. Система лояльности, заказы поставщикам, итоговая себестоимость, консолидированная отчетность. Те же ОСы, коих в таких компаниях миллионы. Заявки внутренние на АХО. Планирование затрат - аренда та же...
IlyaSR; genayo; +2 Ответить
49. _alex1974 15.04.20 13:51 Сейчас в теме
В свое время (15 лет назад) один из клиентов отказался от РИБ в пользу терминальной фермы (500+ пользователей УПП) и ему в принципе не пришлось решать озвученных здесь героических задач...
С масштабированием проблем еще меньше - подключение к терминалам из любого филиала (50-60 филиалов по РФ) не требует вообще ничего, кроме интернета, который сейчас есть в принципе везде. Плюс экономия на железе и обслуживании (два админа на всё)
starik-2005; +1 Ответить
Оставьте свое сообщение

См. также

Как прикрутить ГУИД к регистру сведений Промо

Практика программирования Перенос данных из 1C8 в 1C8 Разработка v8 Бесплатно (free)

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

16.04.2019    17549    0    m-rv    17    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

вчера в 08:00    2010    0    DataReducer    4    

Секционирование в PostgreSQL 12

Администрирование СУБД Бесплатно (free)

Протестируем новый функционал секционирования в PG12.

20.05.2020    1360    0    D_astana    46    

Механизм XDTO

Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

Попытка понять механизм XDTO и его неочевидные аспекты. Научиться выполнять обмены между различными конфигурациями без оглядки на реализацию в типовых.

12.05.2020    2506    0    totchaz    3    

Повышаем эффективность разработки правил обмена Промо

Практика программирования Перенос данных из 1C8 в 1C8 v8 КД Бесплатно (free)

Как повысить скорость и качество разработки правил обмена? Как вести групповую разработку правил обмена? Как облегчить сопровождение правил обмена после передачи в эксплуатацию? Об этом и многом другом вы можете узнать из этой статьи.

25.06.2018    25928    0    olegtymko    47    

Настоящий краудфандинг. Даешь сравнение двух СУБД!

Администрирование СУБД v8 Бесплатно (free)

Первый вариант сравнения двух СУБД. Каждый может внести правку и получить SM. Приветствуются конструктивные комментарии, начинающиеся словами "Автор ничего не понимает".

11.05.2020    1645    0    Mari_Kuznetzova    20    

DBCC CHECKDB оповещение о повреждении баз данных SQL

Администрирование СУБД Россия Бесплатно (free)

Проверка целостности баз данных SQL при помощи DBCC CHECKDB и рассылка оповещений на почту.

09.05.2020    1409    0    P_enemy    2    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    8455    0    YPermitin    0    

Универсальный обмен между идентичными конфигурациями через REST интерфейс OData. Часть І: Справочники Промо

Перенос данных из 1C8 в 1C8 v8 Бесплатно (free)

Сейчас все чаще интеграции различных конфигураций проектируются через HTTP-сервисы - они и работают быстрее, и "войти" в режим отладки гораздо проще, тем самым обойдя "черный ящик" универсального обмена через xml, например. Более года назад я начал работать в компании, в которой разработчики работали с конфигурациями 1С в режиме совместимости еще 8.2.16 (менять режим совместимости в типичных базах мы не хотели) - а как Вы наверное знаете, если интересовались HTTP-сервисами в 1С, их использование в режиме совместимости 8.3.4 и ниже недопустимо - и здесь я уже не надеялся на разработку и использование HTTP-сервисов. Но позже меня заинтересовал такой "сервис" как REST интерфейс OData, так как его можно использовать не меняя режим совместимости конфигурации - именно он и стал для меня идеальным вариантом решения "нетривиальных" задач.

11.05.2018    20925    0    V.Stavinsky    11    

Опыт перехода на БП 3 с БП 2. Амортизация ОС при УСН

Закрытие периода Учет ОС и НМА Бухгалтерский учет Перенос данных из 1C8 в 1C8 v8::БУ БП3.0 Россия БУ УСН Бесплатно (free)

УСН. В начеле 2019 года перешли с БП 2 на БП 3. В начале 2020 года пытались начислить амортизацию в конце года по правилам УСН. Амортизация "не пришла". Разобрались и поправили. 3.0.75.109.

24.03.2020    1107    0    Gasilin    2    

Механизмы проведения документов при обмене по универсальному формату

Перенос данных из 1C8 в 1C8 БСП (Библиотека стандартных подсистем) v8 Бесплатно (free)

Как проводятся документы при обмене по универсальному формату. Пример доработки типовых правил обмена с переносом состояния документа: проведен/не поведен/пометка удаления.

04.03.2020    2811    0    partizand    6    

1С + Apache + SSL: Перевод опубликованной базы на защищенное соединение https с сертификатом от Let's encrypt windows

Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Есть куча инструкции про связку с ISS, решил добавить свои 5 копеек, как я это настраивал на Apache на Windows.

02.03.2020    2219    0    rst_filippov    5    

Взаимодействие между базами 1С через COM Промо

Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

Рассмотрено много особенностей взаимодействия между базами 1С по COM технологии

10.08.2015    142129    0    tormozit    65    

Односторонний обмен ЗУП и БП

Перенос данных из 1C8 в 1C8 v8 БП3.0 ЗУП3.x Россия Бесплатно (free)

Односторонний обмен из ЗУП в БУХ

29.02.2020    3286    0    VAAngelov    11    

Ошибка при обновлении: Записи регистра сведений стали неуникальными: Двоичные данные файлов

Администрирование СУБД v8 Бесплатно (free)

Способ обойти ошибку обновления Записи регистра сведений стали неуникальными: ДвоичныеДанныеФайлов.

26.02.2020    2452    0    dubovenko_m    9    

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

Перенос данных из 1C8 в 1C8 v8 1cv8.cf Россия Бесплатно (free)

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

20.02.2020    1922    0    wau8824ru    4    

Использование инструментов разработчика для отладки обменов КД 2.0 Промо

Перенос данных из 1C8 в 1C8 v8 КД Бесплатно (free)

Пара трюков, благодаря которым жить становится намного проще...

05.05.2017    26178    0    unichkin    3    

Контроль места на дисках

Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Один из последних случаев на работе. Диск, на котором хранились файлы базы, "развалился", база потеряна. Начали искать копию базы. Копии базы делались на другой диск, но оказалось, что на том диске нет места и копии не делались несколько дней. Так было потеряно несколько дней работы фирмы, кому-то выговор, кого-то уволили((.

20.02.2020    2659    0    wowik    20    

Нюансы лицензирования 1С

Администрирование СУБД v8 1cv8.cf Россия Бесплатно (free)

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

19.02.2020    7502    0    fixin    112    

Сказ о том, как online_analyze INSERT "удлинял"

Статистика базы данных Администрирование СУБД Бесплатно (free)

Немного о тонкостях работы модуля online_analyze для PostgreSQL. Опус для тех, у кого, как и у меня, не всегда хватает времени на то, чтобы разобраться, как это работает, и поэтому бывает так, что следуешь рекомендациям из сети и пользуешься методом "копипаста", пока не прижмет.

10.02.2020    1669    0    Sloth    0    

Приемы обработки больших данных в 1С Промо

Универсальные обработки Математика и алгоритмы Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

Рассказ об эффективных приемах организации обработок больших объемов данных на платформе 1С

07.08.2015    64243    0    tormozit    27    

Настройка SoftEther VPN Client на Linux Debian/Ubuntu/Mint (связка Linux-Windows)

Администрирование СУБД Windows Linux Россия Бесплатно (free)

На сервере установлен и настроен VPN через программное обеспечение SoftEter VPN Server, настроены клиенты с доступом по сертификату, встала задача настроить доступ клиента из Linux и подключиться по RDP (VNC) в Windows к серверу VPN.

04.02.2020    2160    0    ClickUp    1    

Как мы научились автоматически отслеживать ошибки в 1С

Администрирование СУБД v8 1cv8.cf Россия Бесплатно (free)

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

04.02.2020    11476    0    slozhenikin_com    27    

Бесшовная интеграция через обмен по правилам - миссия выполнима

Практика программирования Интеграция Перенос данных из 1C8 в 1C8 v8 ДО ERP2 Бесплатно (free)

При организации работы с договорами в ERP 2, с помощью бесшовной интеграции с Документооборотом, «типовой» методикой является создание договоров в ЕРП. После создания договора в ЕРП, пользователь «отправляет» договор в ДО по бесшовной интеграции. На практике, весьма часто пользователи хотят видеть обратную схему: вводить договоры в ДО и при этом получать их в ЕРП без «лишних телодвижений». Или даже вводить их независимо в обеих системах – так, чтобы потом «стыковать» по каким-то определенным правилам.

24.01.2020    3413    0    e-9    2    

Настройка типового обмена данными между: 1С: Предприятие Бухгалтерия ред. 3.0 (БП 3.0) и 1С: Управление торговлей ред. 10.3 (УТ 10.3). Промо

Перенос данных из 1C8 в 1C8 v8 УТ10 Россия Бесплатно (free)

В этой статье я опишу, как настраивается типовой обмен данными между БП 3.0 и УТ 10.3.

29.01.2014    262344    0    arr    53    

Автономный сервер. Часть 2 - утилита управления

Администрирование СУБД v8 Бесплатно (free)

Утилита управления "Автономным сервером" может не только управлять. Какие возможности можно использовать уже сегодня? Разбираем с примерами и ищем отличия от привычных методов.

21.12.2019    7913    0    -vito-    26    

Автономный сервер. Часть 1 - новый вариант сервера

Администрирование СУБД v8 Бесплатно (free)

В Платформе версии 8.3.14 появился новый вариант серверной архитектуры - "Автономный сервер" (бета-версия). Выясняем, что это такое, какова сфера его применения, что он позволяет уже сейчас, чего можно ожидать.

21.12.2019    9930    0    -vito-    19    

Взломать за 60 секунд!

Информационная безопасность Администрирование СУБД Бесплатно (free)

При работе с данными нужно обращать внимание не только на объемы, скорость и удобство, но и на безопасность. Если организация не уделяет внимания безопасности, пользователь с урезанными правами может получить полный доступ к базе данных за 1-5 минут. Набором типичных ошибок и действенных рецептов по усилению безопасности клиент-серверной 1С на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич.

16.12.2019    12663    0    a.doroshkevich    45    

Отладка правил обмена 7.7, 8 Промо

Перенос данных из 1С7.7 в 1C8.X Обмен через XML Перенос данных из 1C8 в 1C8 v8 КД Бесплатно (free)

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

29.10.2013    50294    0    pyrkin_vanya    70    

INFOSTART MEETUP Ekaterinburg.Online. 15 мая 2020 г.

Сообщество Платные (руб)

INFOSTART MEETUP Ekaterinburg- онлайн-встреча IT-специалистов сообщества Инфостарт, которая соберет в себе самые актуальные вопросы управления и технологий 1С.

3000 руб.

10.12.2019    13515    107    16    

Самые распространенные заблуждения об индексах в мире 1С

Администрирование данных 1С Администрирование СУБД Бесплатно (free)

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

28.11.2019    16015    0    YPermitin    44    

Конвертация ставок НДС: из Перечисления в Справочник (правила обмена в конвертации 2.0)

Перенос данных из 1C8 в 1C8 v8 КД Россия НДС Бесплатно (free)

При написании правил обмена между "более старой" и "более новой" конфигурациями можно столкнуться с тем, что в одной конфигурации ставки НДС - это перечисление, а в другой - справочник (или наоборот, но мой пример именно из перечисления в справочник). Ситуация несложная, но нестандартная, поэтому выкладываю работающий пример, может, кому пригодится.

09.11.2019    5245    0    vikulinamari    1    

Обмен по расписанию типовыми средствами. Промо

Распределенная БД (УРИБ, УРБД) Обмен через XML Перенос данных из 1C8 в 1C8 v8 1cv8.cf Россия Бесплатно (free)

Часто перед интеграторами стоит задача организовать автообмен (по расписанию или при наступлении какого-либо события) данными между различными конфигурациями. В этой статье я попробую изложить простую инструкцию, как это можно сделать средствами, заложенными в типовые конфигурации 1С (ЗУП, БП, УПП и т.д.). Для обмена используется подсистема "Обмен данными" из БСП

20.06.2012    100171    0    kser87    52    

Набор скриптов для знакомства с PostgreSQL

Администрирование СУБД Бесплатно (free)

Немного скриптов для PostgreSQL, позволяющих познакомиться с состоянием сервера.

04.11.2019    11597    0    YPermitin    17    

Сюрприз fsync() PostgreSQL

Администрирование СУБД Бесплатно (free)

Предлагаю вашему вниманию продолжение перевода статьи Jonathan Corbet "PostgreSQL's fsync() surprise". Оригинал доступен по ссылке https://lwn.net/Articles/752063/

24.10.2019    2767    0    w.r.    0    

Настройка синхронизации между конфигурациями Бухгалтерия для Беларуси 2.1 и Управление торговлей для Беларуси 3.4

Перенос данных из 1C8 в 1C8 v8 БП3.0 УТ11 Беларусь Бесплатно (free)

Пошаговое описание настройки типового обмена между конфигурациями Бухгалтерия для Беларуси 2.1 и Управление торговлей для Беларуси 3.4

21.10.2019    5943    0    Olesia_Matusevich    1    

Заготовка для загрузки файлов по ftp Промо

WEB Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

3 процедуры и 1 макет

03.06.2013    29134    0    anig99    6    

Обслуживание баз данных. Не так просто, как кажется

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    14981    0    YPermitin    28    

Объединение организаций в ЗУП при реорганизации с переносом данных из ЗУП 2.5 в ЗУП 3.1

Зарплата Управление персоналом (HRM) Перенос данных из 1C8 в 1C8 v8 v8::СПР ЗУП2.5 ЗУП3.x БУ Бесплатно (free)

В этой статье описан опыт объединения 2-х организаций при реорганизации в ЗУП 3.1 с переносом данных одной организации из ЗУП 2.5 (релизы баз более или менее свежие, но не самые последние на момент перехода, примерно двух- и трехмесячной давности). За основу было взято решение из этой статьи https://infostart.ru/public/833658/, в которой описан алгоритм решения задачи, за что автору статьи огромная благодарность! Здесь же даны некоторые комментарии и пояснения к алгоритму переноса и объединения, описаны выявленные мною ошибки. Также приведена небольшая инструкция по использованию обработки ирПодборИОбработкаОбъектовБД — она будет полезна для пользователей — «не программистов», впервые работающих в не управляемых формах.

09.10.2019    5964    0    Neti    1    

EnterpriseData: простой способ защиты данных в базе получателя при одностороннем обмене

Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

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

04.10.2019    5614    0    handscenter    12    

Интеграция «1С:Управление производственным предприятием» с «1С:Документооборот» Промо

Перенос данных из 1C8 в 1C8 Документооборот и делопроизводство Документооборот и делопроизводство v8 КА1 УПП1 ДО Бесплатно (free)

В данной статье пойдет речь о возможности интеграции 1С:Управление производственным предприятием ред. 1.3 с 1С:Документооборот КОРП и о том, что может получить предприятие от этой интеграции.

18.02.2013    60557    0    Vladimir_Konyrev    38    

Набор скриптов для знакомства с SQL Server

Производительность и оптимизация (HighLoad) Администрирование СУБД Бесплатно (free)

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

30.09.2019    19370    0    YPermitin    14    

Дозагрузка измененных данных при помощи КД2

Практика программирования Перенос данных из 1C8 в 1C8 v8 Россия Бесплатно (free)

Иногда во время каких-то регламентных действий по обслуживанию базы(например, при обновлении измененной базы на много релизов) требуется обеспечить бесперебойность работы пользователей. Если конфигурации баз до и после идентичны, то тут сам Бог велел воспользоваться обработкой "ВыгрузкаЗагрузкаДанныхXML", либо такой же но с отбором(на Инфостарте есть такая). Но что если конфигурации баз различаются/значительно различаются? Ниже опишу, как вышел из положения я.

12.09.2019    3987    0    al_zzz    2    

Скрипт объединения правил регистрации (Python)

Перенос данных из 1C8 в 1C8 Бесплатно (free)

Python скрипт для объединения правил регистрации. Написан, т.к. не удалось найти готовый инструмент.

11.09.2019    3119    0    milut    6    

Особенности обмена данными с использованием "ручной" регистрации Промо

Распределенная БД (УРИБ, УРБД) Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

Эта статья рассчитана на программистов, которые используют обмен данными с помощью метода "ВыбратьИзменения" и последующую их запись. Только для планов обменов, имеющих "ручную" регистрацию.

14.01.2013    32229    0    logarifm    6    

Конвертация Данных. Нюансы использования конструкции "НеЗамещатьОбъект = Истина" в обработчике события "ПриЗагрузке"

Перенос данных из 1C8 в 1C8 v8 КД Бесплатно (free)

У конвертации данных есть «особенности», которые «пьют кровь» программистов. Эта статья про очередную обнаруженную «особенность».

10.09.2019    7419    0    ivanek    21    

Обмен данными через Web Сервисы

Перенос данных из 1C8 в 1C8 v8 1cv8.cf Россия Бесплатно (free)

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

02.09.2019    16516    0    user5300    41    

Выгрузка и загрузка документов с движениями

Перенос данных из 1C8 в 1C8 v8 КД Бесплатно (free)

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

02.09.2019    5494    0    human_new    8    

СТАБИЛЬНАЯ Загрузка справочника номенклатуры в 1С:Управление торговлей 8 из прайс-листа в Excel (код открыт скачать можно бесплатно) Промо

Перенос данных из 1C8 в 1C8 Загрузка и выгрузка в Excel v8 УТ10 Россия Бесплатно (free)

В таких случаях многие заказывают соответствующие обработки у собственных штатных программистов, фирм-франчайзи или сторонних разработчиков, но это дополнительные расходы и время. Как быть, если по различным причинам такой возможности нет? У каждого пользователя профессиональной версии 1С:Предприятие 8 подобная обработка уже есть! На диске ИТС! Типовая обработка «ЗагрузкаДанныхИзТабличногоДокумента.epf», находиться в разделе «Технологическая поддержка» > «Методическая поддержка 1С:Предприятие 8» > «Универсальные отчеты и обработки» > «Загрузка данных из табличного документа». Обратите внимание, начиная с Февраля 2010 г. на диске ИТС данная обработка для конфигураций на платформе 8.1 находиться в другом разделе: «Технологическая поддержка» > «Методическая поддержка 1С:Предприятие 8» > «Платформа 1С:Предприятие 8.1» > «Универсальные отчеты и обработки» > «Загрузка данных из табличного документа».

07.11.2011    179834    0    SkyLink2012    132    

EnterpriseData – часть 3. Загрузка данных, идентификация объектов

Практика программирования Математика и алгоритмы Перенос данных из 1C8 в 1C8 Разработка v8 v8::УФ 1cv8.cf Бесплатно (free)

Основные этапы загрузки данных через EnterpriseData. Идентификация объектов загружаемых полностью и по ссылке. Приведены схемы процессов загрузки данных. Описание основных операций и обработчиков. Перечень процедур БСП, используемых при загрузке данных, структура «КомпонентыОбмена».

22.08.2019    11644    0    ids79    7    

Перенос дополнительных реквизитов в Конвертации данных 2.0

Перенос данных из 1C8 в 1C8 v8 КД Россия УУ Бесплатно (free)

Пример написания правил обмена (КД 2.0) для переноса дополнительных реквизитов справочника "Номенклатура", в том числе перенос ПВХ с разными типами значений.

13.08.2019    8698    0    vikulinamari    7    

Синхронизация данных между 1С: ЗУП 3.1 и Бухгалтерией 3.0 через файл

Перенос данных из 1C8 в 1C8 v8 1cv8.cf Россия Бесплатно (free)

Публикация описывает последовательность синхронизации данных между 1С: ЗУП 3.1 и Бухгалтерией 3.0 через файл.

23.04.2019    10314    0    saveliev    6    

Полезные приемы при работе с Конвертацией данных 2.1. Логирование, интерактивное управление, дозаполнение и постпроведение документов

Перенос данных из 1C8 в 1C8 v8 КД Бесплатно (free)

Некоторые полезные приемы для КД 2.1, которые могут пригодиться как при доработке типовых правил, так и самописных.

22.04.2019    8052    0    maks_20    9