Comments 21
Примеры, пусть даже простые были бы очень полезны. Спасибо!
Так вроде бы в сценариях расписаны примеры или вам так сказать из жизни? Ну из личного видел не раз когда переход в час Х огромной системы(сотни гигабайт)по разным причинам не состоялся, а точнее состоялся неудачно. Затем происходит откат обратно, который требует времени, также частичная потеря данных(они как правило вводятся в две системы но с косяками), а все это время фуры не идут к клиентам , процессы стоят и тд. и т.п.
Автор не знает о чем пишет, не представляет что такое платформа 1С и как она работает с СУБД.
Имхо статья для рекламы "нашего инструментария DB Replication".
Довольно смелое утверждение. Напоминает старый анекдот:
Выбирают в синагоге старосту. Предлагают кандидатуру Рабиновича. Для протокола ведущий собрания спрашивает:
- У кого есть возражения? - Неожиданно встаёт Абрам:
- Рабиновича нельзя, у него дочь проститутка!
- Какая дочь?! У меня два сына!, - возмущается Рабинович.
- Ну, я сказал, а вы разбирайтесь, - с довольным видом заключил Абрам, усаживаясь обратно.
А по поводу того, что статья для рекламы... Не без этого. Я ж в корпоративном блоге пишу.
Дабы не быть голословным вот ссылка
Отзывы о продуктах и услугах компании SOFTPOINT
Если вам будет не лень почитать то вы увидите большое количество проектов по оптимизации производительности 1С, как вы понимаете там без глубокого понимания работы 1С и СУБД просто нельзя
Вы в курсе что лицензионное соглашение с 1С прямо запрещает прямой доступ (изменение данных) в базу СУБД мимо средств платформы 1С?
Вот это признание в некомпетентности:
"Отзыв по результатам проекта свёртки исторических данных в распределенной корпоративной БД 1С:УПП с применением программного комплекса DB Replication
Источник: https://softpoint.ru/portfolio/
© SOFTPOINT"
https://v8.1c.ru/priobretenie-i-vnedrenie/otvety-na-tipovye-voprosy-po-litsenzirovaniyu-1s-predpriyatiya-8/#65
65 вопрос с ответом:
"Во всех остальных случаях лицензионное соглашение позволяет использовать для построения решений только штатные средства платформы. В частности, можно обращаться к данным информационной базы только при помощи объектов «1С:Предприятия», специально предназначенных для работы с данными (запросы, справочники, документы и т. д.). Нельзя обращаться к данным информационной базы напрямую, минуя уровень объектов работы с данными «1С:Предприятия», например при помощи средств СУБД или при помощи внешних компонент, которые реализуют прямой доступ к СУБД. Это ограничение распространяется на любые действия с данными, в том числе на изменение их структуры, а так же на чтение или изменение самих данных информационной базы или служебных данных «1С:Предприятия»."
Проблема не в рекламе.
Проблема в недобросовестной рекламе и введение в заблуждение, путем привязки (причем неграмотной и не в тему) к платформе 1С Предприятие.
И Вы не в курсе что в последние годы 1С активно переходит с MS SQL на PostgreSQL.
Причем не только сама 1С и франчайзи но и конечные пользователи.
Например 1С Фреш с самого начала работает на Linux+PostgreSQL.
Последние три моих места работы - 1С только на PostgreSQL, да и другие учетные системы тоже не MS SQL а PostgreSQL, MariaDB или SQLite.
Т.е. утверждать "На основании собственного опыта и опыта Softpoint могу уверенно утверждать, что если в компании есть крупная ИТ-система, то она почти всегда на MSSQL Server (даже если это не 1С). " - голословно.
Хм... Я могу это делать например на основании нашей статистики. 100-и проектов по аудитам производительности в крупных компаниях и подавляющая часть их на 1С MSSQL. А на основании чего ваша статистика? А вообще вы статью читали ? Цель ее как раз сделать переход на Postgre более массовым и безопасным. Будет скоро следующая статья более политизированная про то почему в рамках текущей политической обстановки нужно быстрее переходить на Postgre.
Для массового и безопасного перехода 1С с MSSQL на PostgreSQL уже все есть.
Из статьи совершенно не понятно зачем нужна DB Replication?
Что именно есть, приведите примеры. Это будет работать с 1С , вы уверенны? Если не приведете аргументы то думаю вы голословны в своих утверждениях.
Не примите за рекламу но изучите хотя бы статью
https://habr.com/ru/companies/dataline/articles/691796/
Или хотите сказать что ваше решение позволяет выполнить онлайн переход без остановки работы пользователей?
Причем без доработки конфигурации 1С?
Уже сказал. В статье. Вы же принялись комментировать, не прочитав ее.
Прочитал статью вашу. Не увидел ни названий продуктов, ни методик.
В моей статье речь не о том, что компания 1С не «движется» в направлении PostgreSQL, и уж тем более не о том, что 1С не работает под PostgreSQL. У 1С совместимостью c PostgreSQL всё в порядке.
А речь в статье в том числе о том, как, например, терабайтную базу данных MS SQL, работу которой прервать нельзя, скажем, на несколько дней, перевести на PostgreSQL. Вы можете привести концепцию и пример выполнения такого проекта? Подчеркну требования: 1) конвертировать терабайтную БД, а не разворачивать пустышку введя начальные остатки, 2) выполнить конвертацию БД из MS SQL в PostgreSQL, не прерывая работу пользователей в MS SQL.
1) РИБ
2) РИБ
И пользователи при очередном перезапуске сеанса попадают уже на новый сервер в полную копию базы.
Да типовой механизм РИБ 1С это не очень быстро.
Но кто мешает за месяц-два перетянуть все старые данные, которые не меняются.
И уже непосредственно перед переходом синхронизировать только то что поменяли в этот день.
Да в отличие от вашего низкоуровневого вмешательства в СУБД типовой РИБ медленный в работе.
Но зато быстрый в начальном старте, не надо долго писать SQL скрипты и т.д.
И он поддерживаемый обычными специалистами по 1С.
Вы статью читали целиком или тезисно?
Целиком.
И понял то что описано с обычной типовой конфигурации 1С (БП, ЗУП, ERP/КА/УТ11) не может работать без проблем.
После каких то доработок да можно заставить это работать.
Но не понятно чем помешал обычный РИБ?
Зачем нужен этот Репликатор?
Исходя из какого описания сделан вывод о том, что с типовыми конфигурациями 1С решение не может работать без проблем? Судя по описанию на сайте разработчика https://softpoint.ru/solutions/db-replication/ , система репликации совместима с любыми конфигурациями 1С.
О том же, "чем помешал обычный РИБ", в статье вроде есть резонные для высоконагруженной БД аргументы – доп. нагрузка и блокировки БД MSSQL, проблематика синхронизации БД PGSQL с оперативными данными БД MSSQL за время конвертации в PGSQL, и др.
Совместима без доработки конфигураций и блокировки ввода (или изменения) данных?
Плохо верится что смогли обеспечить двухстороннюю синхронизацию и работу пользователей (не только чтение но и запись) в двух базах 1С.
Что в случае РИБ штатно!
Не спорю что это возможно неплохой механизм быстрого переноса/конвертации/свертки данных, когда пользователи отключены.
Но типовыми средствами это так же делается, да не так быстро но надежно.
В описании системы репликации на сайте разработчика именно это и указано – внедряется без доработки конфигурации 1С, изменения данных передаются непосредственно из таблицы в таблицу на уровне SQL Server, передача данных может быть двунаправленной и однонаправленной. Отзывы вроде всё это подтверждают.
А что касается «неплохой механизм быстрого переноса/конвертации/свертки данных, когда пользователи отключены», то в статье как раз утверждается, что с использованием системы репликации пользователей можно не отключать в рабочей базе. Вероятно для определённых ситуаций, например, терабайтная база с высокой интенсивность изменения данных и отсутствием тех. окон, подход с репликацией будет иметь преимущества перед методикой РИБ’а.
Гетерогенная распределенная система как способ миграции больших и не очень баз данных с MSSQL Server на PostgreSQL