Как работает 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 288 27.03.20 16:59 Сейчас в теме
В ДНС магазинах раньше были 1С, а сейчас у них веб клиенты, без признаков 1С.
6. max_st 160 27.03.20 21:57 Сейчас в теме
(1)Система продаж, которая используется в магазинах работает не на 1С. Это свой внутренний продукт на C#. В докладе об этом не стал уточнять. На 1С работает своя ERP система для бэк-офиса.
2. Rustig 1742 27.03.20 18:59 Сейчас в теме
3. Xershi 1149 27.03.20 19:19 Сейчас в теме
Так 13 ТБ это рабочая база или все узлы?
И как данные размазаны?
Про КОРП платформу ничего не сказано или материал написан, до дня Х?)
4. Torin 374 27.03.20 20:02 Сейчас в теме
(3)
На данный момент размер основного узла центральной базы составляет 13Тб. Региональные узлы имеют размеры от 1 до 2 Тб данных.
user1315860; Lansi; max_st; +3 Ответить
5. Torin 374 27.03.20 20:13 Сейчас в теме
(0) Очень интересно кто!! и как часто анализируется информация? и сколько человеко/часов используется для этого
7. max_st 160 27.03.20 22:00 Сейчас в теме
(5)У нас есть отдел, который занимается мониторингом и эксплуатацией всей системы. Часть информации анализируется автоматически. Расклад по затратам трудовых ресурсов раскрывать не стану, но скажу, что в отделе менее 10 человек.
8. Torin 374 27.03.20 22:04 Сейчас в теме
(7) Коллега.я о другом..такой большой объем информации анализировать..в любом случае нужно визуально... Очень интересная тема. Не в онлайн режиме же они мониторят..как баг листы ведут..как документируют.
10. max_st 160 27.03.20 22:13 Сейчас в теме
(8)Ответил в корень ветки, ошибся)
9. max_st 160 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 47 28.03.20 14:11 Сейчас в теме
(12) 1 Гб это пустая база УНФ уже. Кажется пора начинать привыкать к большим цифрам.
14. dexxxqqq 28.03.20 14:19 Сейчас в теме
(13) 640 килобайт хватит всем
товарищ Ын; +1 Ответить
15. acanta 28.03.20 15:09 Сейчас в теме
Подскажите пожалуйста, правильно ли я поняла, что на перифериях и в центре конфигурации одинаковые и разница только в данных? Клиент никак не связан с центральной базой 1с в режиме онлайн?
21. Rustig 1742 28.03.20 23:08 Сейчас в теме
(15) я сначала подумал, что так - по крайней мере начинали они наверное именно так, что ЦБ и периферия были схожими конфигурациями. Потом штат разработчиков рос, задачи усложнялись, конфигурации ЦБ и периферии стали отличаться... Для этого они сами формируют xml-пакеты обмена, сами их распознают при загрузке, сами переопределили алгоритм задания номеров сообщений... Я думаю, что клиент не связан с ЦБ в онлайн-режиме.
16. hamsar 14 28.03.20 15:32 Сейчас в теме
Непонятно как вы поступаете, когда в регистре на млрд записей все таки надо добавить измерение
20. Rustig 1742 28.03.20 23:02 Сейчас в теме
(16) не знаю как они, а я бы сразу создал новый регистр с новой логикой. Если для старых сведений измерение не нужно было использовать, значит и в старый регистр не надо его вставлять. Создаем новый регистр с новой логикой, в котором сведений еще не млрд записей.
33. alex_art 14 30.03.20 00:31 Сейчас в теме
(20)
а потом джойним\подзапросим все вновь созданные РСы с самым первым РСом для получения достоверных сведений за весь период существования этой бизнес логики. При этом не забываем, что связанных РСов столько, сколько раз было необходимо добавить новое измерение :))))))))))))
34. Rustig 1742 30.03.20 09:09 Сейчас в теме
(33) вам новый регистр в таком случае, конечно, не поможет... мое предложение не для вашего случая, к сожалению. А для тех, когда это допустимо при прочих условиях.
50. Vortigaunt 83 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 160 30.03.20 09:12 Сейчас в теме
(23)Да, именно так и поступаем.Исследуем возможности умной реструктуризации в новых версиях платформы. Пока результаты положительные, планируем переход.
nekit_rdx; acanta; hamsar; +3 Ответить
38. hamsar 14 30.03.20 09:24 Сейчас в теме
(35)
(23)Да, именно так и поступаем.Исследуем возможности умной реструктуризации в новых версиях платформы. Пока результаты положительные, планируем переход.


Спасибо за ответ!
52. tormozit 6318 02.05.20 08:15 Сейчас в теме
(35) Перешли на новую штатную реструктуризацию? Вот это будет супер интересно - узнать опыт ее эксплуатации на таких объемах данных. Механизм до сих пор в статусе Бета видимо потому, что мало обкатки.
53. rinat_alp2 52 04.05.20 12:07 Сейчас в теме
(52) Еще не перешли, тестируем новую реструктуризацию с точки зрения больших объемов, например:
1) При добавлении в регистр накопления реквизита новый механизм использует alt er table add column и это быстро, но при добавлении измерения или ресурса происходит пересчет таблиц итогов (создание новых и удаление старых).
Если таблицы итогов небольшие, то это не страшно, но они могут быть и большие.
2) Если таблица регистра накопления была создана давно (поле _Period с типом datetime) и добавить хотя бы реквизит, то это вызовет конвертацию типа поля _Period в datetime2(0).
Что на больших объемах не успеет в технологическое окно: переливка значения через update, создание новых индексов и перестроение кластерного индекса, пересчет таблиц итогов.
Сейчас конвертируем понемногу datetime на datetime2(0).
17. insurgut 194 28.03.20 18:06 Сейчас в теме
Или я пропустил, или осталась нераскрыта тема конфигурации сервера под базу в 13ТБ. Интересно было бы конфигурацию узнать (о:
ansh15; zabaluev; +2 Ответить
39. max_st 160 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)
55. buganov 173 30.11.20 18:32 Сейчас в теме
(48)очень плохой совет. Вы уверены, что получите прибавку в производительности произвольной системы только выводом tempdb в RAM? А как же анализ, как же исследование на предмет ускорения КОНКРЕТНОЙ базы под РАБОЧЕЙ нагрузкой?
Почему не советуете всю базу выгрузить в оперативную память? Ну быстрее же по идее?
18. CheBurator 3455 28.03.20 21:48 Сейчас в теме
"Если с планами обмена все понятно, то зачем нам понадобился дополнительный регистр сведений? Он нам нужен для того, чтобы в нем регистрировать изменения тех объектов, которые при выгрузке и загрузке должны с собой забирать связанные данные, чтобы в момент загрузки в единой транзакции загрузить не только сами данные, но и все, что с ними связано. Таким образом, мы обеспечиваем целостность загружаемых данных в базах источниках."

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

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

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

См. также

INFOSTART MEETUP Ekaterinburg.Online. 15 мая 2020 г. Промо

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

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

10.12.2019    19484    0    Infostart    16    

Ошибка синхронизации документа "Отчет переработчика" и боль типового обмена (УНФ - БП)

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

В данной статье поделюсь доработкой, а точней исправлением типового обмена УНФ - БП, документа "Отчет переработчика", и заодно опишу подход к решению подобных задач. Здесь не будет описано, что такое "МенеджерОбменаЧерезУниверсальныйФормат", "xdto", "EnterpriseData", по этим пунктам должны быть базовые знания.

08.06.2021    208    con-men    0    

Особенности online-обмена между старыми и новыми типовыми

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

Столкнулся с неприятной особенностью потери части данных при обмене УСО (УПП) - ДО.

01.06.2021    1176    echo77    7    

Как подключиться к хранилищу конфигурации на сервере за NAT, если есть доступ по RDP?

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

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

01.06.2021    1128    Dipod    13    

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

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

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

16.04.2019    21527    m-rv    17    

Как получить полный доступ к данным файловой базы 1С

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

Опыт перевода файловой базы 1С в клиент-серверный вариант работы при отсутствии административного доступа (авторизации) в базе.

31.05.2021    596    info1i    2    

Как добыть последнюю версию SQL Server 2012 Native Client

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

Краткое руководство администраторам 1С по получению свежей версии SQL Server 2012 Native Client, необходимого для работы сервера 1С.

13.05.2021    619    tedkuban    3    

Простой метод установки postgresql-12 от 1С на Archlinux/Manjaro

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

Инструкция по установке дистрибутива postgresql-12 от 1С на Arch и Manjaro, совсем без красноглазия

02.05.2021    599    cdiamond    2    

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

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

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

25.06.2018    29606    olegtymko    48    

Ускорение реструктуризации больших таблиц. Мой вариант

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

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

28.04.2021    924    buganov    0    

Добавление нового документа в формат обмена EnterpriseData (получение)

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

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

27.04.2021    594    con-men    1    

Добавление нового документа в формат обмена EnterpriseData (отправка)

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

Для меня встала задача добавить новый документ, созданный в расширении, в формат обмена EnterpriseData, между БП - УНФ. Изначальный поиск решения не дал результата. Методом проб и ошибок у меня сформировалось свое решение, которым спешу поделиться, чтобы систематизировать информацию в текст и услышать плюсы, минусы подхода. Все доработки осуществляются в расширении, в котором и был создан новый документ.

21.04.2021    1429    con-men    5    

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

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

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

11.05.2018    24418    V.Stavinsky    11    

Xubuntu 20.04 для бухгалтера 1С

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

В публикации представлен необходимый минимум для настройки Xubuntu 20.04 в качестве рабочего места бухгалтера, ведущего учёт в программе 1С: Бухгалтерия 3.0 файловый вариант. Кроме этого, настроено подключение и других сотрудников через тонкий клиент 1С к опубликованной на веб-сервере базе бухгалтерии.

12.04.2021    3199    compil7    25    

Режим совместимости конфигурации 1С

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

Приветствую, коллеги! В этой статье будет сделан обзор функции совместимости конфигурации 1С с другими версиями конфигураций 1С, а также рассмотрено, как выбрать и настроить режим совместимости конфигурации с версией 1С 8.3. Во-первых, разберём главное понятие в этой статье: режим совместимости в конфигурации – это устройство, благодаря которому выводится номер версии системы, под которую станет открыто приложение 1С:Предприятие. Данный режим существует на платформе 1С начиная с версий 8.2 и 8.3 (платформа версии 1С:Предприятие 8.3 совместима с платформой версии 1С:Предприятие 8.2).

31.03.2021    1849    Koder_Line    3    

Правила обмена больше не нужны

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

Есть несколько общепринятых подходов к написанию обмена между 1С-системами, каждый из которых упирается в длительное изучение технологии, мучительную отладку правил конвертации и написание большого количества сервисного кода, в котором потом тяжело разобраться. О принципах работы универсального фреймворка liteExchange, который реализует быстрые обмены между 1С и внешними системами, и берет на себя всю техническую обвязку по стандартному преобразованию данных, на INFOSTART MEETUP Saint Petersburg.Online рассказал Николай Крылов.

17.03.2021    7939    Nikola23    35    

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

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

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

10.08.2015    166112    tormozit    70    

Как мы на Managed Service for SQL Server в Yandex.Cloud переезжали

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

Рассказ про грабли при переезде на Yandex Managed Service for SQL Server и DataLens.

02.02.2021    771    dsdred    5    

Перенос данных из ЗУП 2.5 в ЗУП 3.1

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

Довольно часто сталкиваюсь с тем, что у коллег возникает вопрос, как правильно выполнить перенос данных из ЗУП 2.5 в ЗУП 3.1. (Неужели еще кто-то до сих пор работает в ЗУП 2.5? Да, и очень много людей)

25.01.2021    5673    VAAngelov    54    

Перенос документов 1С из одной базы в другую

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

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

23.01.2021    12394    Koder_Line    9    

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

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

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

05.05.2017    28413    unichkin    6    

Объединение баз ЗУП

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

Есть база ЗУП 3.1, в которой ведется одна организация, все данные из нее нужно перенести в общий ЗУП, обе базы типовые. Используем для переноса КД 2.0.

10.01.2021    1408    roger83    0    

Платформа 8.3.18 Обновление ИБ в пакетном режиме поломалось? Решено

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

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

24.12.2020    5198    VPanin56    14    

Неожиданное использование XDTO

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

Расскажу про свой опыт, как XDTO может помочь в отладке обменов данных. И какие полезности можно почерпнуть для себя при работе с XDTO.

05.12.2020    2704    simon_sidoruk    22    

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

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

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

07.08.2015    69637    tormozit    28    

Отправка сообщений из MS SQL Server в Telegram с использованием PowerShell

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

Пример отправки логов  из MS Sql Server с использованием бота Telegram и PowerShell.

26.11.2020    1333    ivv1970    2    

Сказ о том, как в одной крупной компании документооборот внедряли, или проблемы типовых обменов между КА и ДО

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

Приветствую всех. Сегодня пойдет речь о том, как на одной крупной компании внедряли 1С:Документооборот 2.1 в связке с КА 2.4. Вроде бы системы типовые, мы практически не добавляли ничего в них, но проблем было столько, что я решил изложить их в статье. Может, кому-то пригодится это в дальнейшем, и не придется тратить кучу времени на поиск решений.

10.11.2020    5597    maks_20    23    

Простой пример разработки регулярного обмена с использованием БСП на примере ERP 2.4 и УПП 1.3

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

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

27.10.2020    5177    байт    13    

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

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

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

29.01.2014    276743    arr    56    

Сравнение архитектуры двух СУБД.

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

Избранные административные представления.

09.09.2020    1934    vasilev2015    3    

Сбой, отказ 1C:Предприятия 7.7, код исключения e06d7363. APPCRASH 1cv7s.exe

Администрирование СУБД Журнал регистрации v7.7 1cv7.md Бесплатно (free)

Прекращена работа программы "1CV7 starter program". Никто не может зайти в 1C 7.7. Апкреш. Что делать? Проверьте, возможно журнал регистрации информационной базы 1С: Предприятия 7.7 поврежден.

17.08.2020    1521    ksnik    3    

Восстановление полнотекстового поиска в базе данных. Клиент-серверный вариант. Моя практика.

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

Восстановление полнотекстового поиска в базе данных. Клиент-серверный вариант.

06.08.2020    885    premierex    3    

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

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

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

29.10.2013    52254    pyrkin_vanya    70    

Администрирование списка баз Windows правами.

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

Все пользуются, а статьи по администрированию списка баз нет. Непорядок.

03.08.2020    1156    sergey279    0    

Конвертация данных 2. Использование подключаемых обработок в правилах обмена. Конвертация дерева значений

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

Разработка правил обмена с использованием подключаемых обработок. В качестве примера рассмотрена реальная задача конвертации дерева значений.

15.06.2020    5108    Drivingblind    8    

Конвертация данных 2.1. Методика переноса остатков

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

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

12.06.2020    12067    aximo    21    

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

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

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

20.06.2012    104731    kser87    52    

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

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

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

08.06.2020    5192    ogroup    22    

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

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

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

24.05.2020    9896    DataReducer    22    

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

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

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

20.05.2020    5206    D_astana    46    

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

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

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

03.06.2013    30990    anig99    6    

Механизм XDTO

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

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

12.05.2020    6474    totchaz    4    

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

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

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

11.05.2020    2906    Mari_Kuznetzova    25    

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

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

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

09.05.2020    3341    P_enemy    3    

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

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

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

18.02.2013    65336    Vladimir_Konyrev    38    

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

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

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

06.04.2020    14476    YPermitin    0    

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

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

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

24.03.2020    2443    Gasilin    2    

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

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

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

04.03.2020    5907    partizand    6    

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

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

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

14.01.2013    36169    logarifm    6    

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

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

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

02.03.2020    4843    rst_filippov    5    

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

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

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

29.02.2020    7737    VAAngelov    35    

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

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

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

26.02.2020    9507    dubovenko_m    15    

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

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

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

20.02.2020    3254    wau8824ru    4