v8: Параллельные вычисления в 1С (исключительно для МС СКЛ) #651588

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

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

Закладки, бэкдоры в комплекте?

в 5 строке описания опечатка. бесплатная лицензия на год. через год лицнзия будет бесплатной? если нет - цены озвучте. в статье не приведены примеры (область применения) не описано какой прирост производительности ожидать.

+1 Объясните дураку, что знкачит: "Необходимость связывания с транзакцией основной сессии пользователя."

Какие-то сведения отправляет...

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

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

Исключительно длямс скл? Тогда исправьте название темы

Все что требуется для внедрения в комплекте.

SPLoader_For1C8x_1.0.0.X.exe - для 32-разрядного сервера 1С SPLoader_For1C8x_x64_1.0.0. X.exe - для 32-разрядного сервера 1С

Спасибо

Мертворожденное дитя.

Почему))

я не понял - прослойка раскидывает выполнение с одного процесса на несколько? так вроде и щас так - заводим несколько процессов и пользователи сами "распараллеливаются"

Не совсем так. Технология позволяет распараллеливать запросы 1С для каждого сеанса (раньше такой возможности никогда не было), причем управляете всем этим процессом из кода 1с. Таким образом, можно значительно ускорить выполнение независимых запросов 1С, например, при получение отчета. Например, пользователь для получения данных отчета делает 3 запроса 1С к 3 разным регистрам: Остатки, Резервы и Партии. Эти 3 запроса можно выполнить параллельно и суммарное время выполнения будет не (Длительность1+Длительность2+Длительность3), а максимальная длительность всех запросов (на практике немного дольше).

+ Кстати подобные темы и решения пробовали реализовать: но на стадии прототипа.

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

из схемы этого совсем не понять

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

1) Зачем транзакционная целостность? Например при удалении движений, самое простое.

Вот вы и ответили на вопрос)) А если по одному регистру в одном потоке движения удаляться, а по другому нет (произошла ошибка? Что дальше произойдет? - документ проведен/частично проведен/не проведен?

Исправьте, пожалуйста опечатку: >>Установить сервис для внедрения к библиотеку доступа к данным. Установить сервис для внедрения И библиотеку доступа к данным.

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

+ кстати как раз про все эти риски описано в статье. Конечно, не применима технология для всего - пока для отчетов, потом может и в транзакции.

Флаг проведен вообще такой веселый :)

и много  копий продали уже ?

Мы и придумываем, вот покрыли целую область (параллельность запросов 1С в отчетах), раньше этого не было, потом дальше будем развивать. Вы же даете абсолютно неправильную оценку . Цель топика: пояснить если не понятно для чего это надо, дать возможность использовать в работе. сейчас поправим. прошло бета - тестирование, опробацию у клиентов, демонстрация в MS SQL Club: ошибок нет, предоставляется бесплатно.

Дааа. Живорожденным оно не будет. Ну вот накера? Будет десяток клиентов, из которых реально эти параллельные отчеты нужны 2-3, остальные - энтузиасты. А потом, глядишь, 1С запилит это в платформу. Хотя вряд ли.

gallam, т.е. это немного похоже на СКД, только уже для для объектов Запрос =НОВЫЙ Запрос; я правильно понял?

похоже нет - это прямые запросы, тог-ды   > H A D G E H O G s + >Будет десяток клиентов, из которых реально эти параллельные >отчеты нужны 2-3, остальные - энтузиасты. +

Чего взъелся-то? Хочешь используй, тебя же никто не заставляет.

Я - сама доброта.

Не поверите, Вы лично по вашим ответам в предыдущих топиках как раз и были для меня энтузиастом. А по поводу зачем - множества и больших и маленьких систем имеют длительные самописные и не самописные отчеты. Знаете как их пытаются ускорять - покупают мощнее железо, хотя оно в большинстве случаев не надо. Можете вопрос более конкретный задать... СКД и наша технология абсолютно разные вещи и в будущем возможно еще и параллелить СКД) Технология параллельных вычислений она универсально и не только для 1С (для любых других сред разработки - С++, Delphi, где есть OLEDB - это ограничение). Кратко есть группа независимых запросов SQL (В 1С свой формат), есть возможность минимальными усилиями без задержек их выполнить параллельно и получить все выборки быстрее. Дальше по вашему алгоритму программы. К - это не прямые запросы!!!!!!!!!!! Это запросы 1С со всеми ее временными таблицами и прочее.

Я так понимаю, что SPLoader инжектирует в рабочий процесс....

Да, он работает с библиотекой OLEDB

Отчего же не поверить. Верим. Охотно верим. С учетом того, КАК основная масса эти запорсы пишет ничего удивительного нет. Но, отчасти, , прав - удел Вашего детища - тешить умелые руки.

И только? :)

Мдя.. кто что инжектирует, хотя и не запрещено же :)

А вот параллельная запись регистров, либо групповая запись объектов (все ссылочные объекты, их структура проста - Шапка+Табчасти, ничего сложного) взлетели бы мощнее.

Не факт

Хотя я лично такое использовать у нас никогда не буду. Просто не смогу :-) Только 1С, только типовое, только хардкорр!

:))))

Работает только с ней (и с интерфейсами OLEDB). Мы позиционируем технологию так: - Есть длительный аналитический отчет, в нем проведена линейная оптимизация, но длительность слишком большая. Вы прибегаете к технологии независимо от кривизны рук. - Есть любой отчет, выделяете независимые запросы и оптимизируете. В любом случае гораздо эффективнее покупки железа или чего еще. Основная сложность всех наших технологий в том, что все привыкли по старинке заниматься ускорением отчетов и не хотят изменяться. А насчет развития технологии - мы этим занимаемся и будет компонента улучшаться. Времена меняются и я бы не использовал слова типа: "никогда"))) P.S> С утечкой памяти 1С тоже был скептицизм, пока не попробовали смоделировать.

gallam >К - это не прямые запросы!!!!!!!!!!! >Это запросы 1С со всеми ее временными таблицами и прочее. Это уже Меня заинтересовало)) //т.е. Дано: Я правильно понял? ))

Да идея ясна, что либо proxy-dll, либо инжекция. - Есть длительный аналитический отчет, в нем проведена линейная оптимизация, но длительность слишком большая. Вы прибегаете к технологии независимо от кривизны рук. - Есть любой отчет, выделяете независимые запросы и оптимизируете. Бесполезно оптимизировать код, который не работает (с)

В моем понимании "Запрос на языке 1с" неравно "Запрос на языке SQL". Если имеется ввиду "SQL Запрос от сервера 1с"... уточняйте плиз)).

Принцип прост: при передаче в тексте проверяются передаваемые строки, если строка содержит "BeginParallelQueryExecution" то, все, что передано инкрементирует соединение и устанавлвается текст, пока не получить строку с EndParallelQueryExecution. И тупо вернет массив рекордсетов.

А там не столь важно, дело в том, что они получают уже транслированный запрос.

Слишком глубокомысленно) Технология, когда ее используем для 1С, то Запрос 1С - сделана специальная адаптация. Если самописное приложение на любом другом языке (Запрос SQL).

Про "тупо", конечно не само решение а в смысле возвращаемого значения :)

Принцип действительно прост, эффект тоже есть, внедрение не сложное.

+ Единственное - адаптация к 1С)

Да понятно.

Если применительно к 1С, то в чем, так сказать, адаптация? В том, как в 1С вернуть массив выборок?

Вот что мне непонятно, так это если используется OLE DB, то, по-идее без разницы какую СУБД использовать.

+1 1. Отчеты в фон и так неплохо переносятся (СКД+фоновые задания). 2. Проведение и запись - слишком много нюансов по транзакционной работе. 3. Для проведения есть стандартный в общем-то приём - оперативные регистры двинуть сразу, остальное фоновыми заданиями. Параллельное выполние - интересная идея для управляемых форм с несколькими формами списков, но это достаточно узкая ниша в 1С. если произойдёт ошибка, то в 1 потоке откатится вся транзакция. В нескольких потоках придётся открытые транзакции держать до последнего во всех потоках, а это какой-то блокировочный ад.

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

задам адски тупой вопрос: чем это принципиально отличается от отправки запросов в фоновые задания и считыванию результатов по мере выполнения оных ?

Тебя и спрашивали, как быть в таком случае?

Хоть один реальный use-case приведите? В статье одна заумь. Я надеюсь, разработка выросла из успешного решения реальной задачи? Хоть им похвастайтесть. Пока что все выглядит так, что H A D G E H O G и sapphire правы.

Тем, что память rphost жрать, по-идее, будет меньше.

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

Да и так ясно где это применимо, и главное кем.

Запрос 1С превращается во много различных запросов SQL (и это надо было правильно обработать). Такой механизм был сделан специально для 1С 8. Существуют другие варианты выполнять в фоне, но мы стремились сделать внедрение этого механизма максимально быстро. Я надеюсь и адаптировать к параллельным вычислениям проще и в одном отчете.

Ты предлагаешь им использовать ISOLATION LEVEL SNAPSHOT? Хм.. Тогда tempdb будет расти.

Как быть пользователям MS SQL 2005 ?

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

Угадай :)))

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

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

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

Запрос 1С превращается во много различных запросов SQL (и это надо было правильно обработать). И? Всё что между SetQueryGUIDForExecute и EndQueryGUIDForExecute разбить на несколько? Ну можно посмотреть в ТЖ что там за страшный SDBL/SQL поедет на сервант БД....

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

Я не понял, кто тут в ком заинтересован. :) Обязательно заставлять что-то скачивать и запускать конфигуратор? Просто словами не описать, настолько сложный и экзотический отчет?

И я не пойму))) 1. Бесплатно. 2. Отчет предоставлен. 3. Технология дается. 4. На форуме ответы на вопросы. А у вас: 1. Не хочу смотреть/читать/открывать конфигуратор. Словами объяснить можно, но по мне: 1. Прочтите все материалы, которые вам были даны. 2. Сформулируйте вопрос по существу - получите оперативный ответ.

О. Вот Вам идейка как лучше показать где это применимо: план/фактный анализ - плановые показатели и факты можно распараллелить и пример многим знаком.

+ Шаблон отчет только для примера (не рабочий кейс), чтобы проще вам применить в своих задачах.

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

и вправду, может же не хватить журнала. тогда параллельные транзакции не организовать разумными трудозатратами.

Мы проводили анализ эффективности параллельного выполнения запросов 1С для отчетов на больших БД, он гарантированно есть, но в качестве примера его передать не можем. Так как надо передавать БД (желательно с данными), сам отчет. Поэтому в качестве шаблона распараллеливания запросов 1С дан внешний отчет с примитивными запросами 1С для УТ 11, которую могут все скачать и установить.

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

Я написал, что можно сделать, читай ниже.

Кто вам такую керню сказал?

>Отчет предоставлен. Скачал VypolnenieZaprosovUT.epf, открыл. Не вижу отчета. вижу форму для тестирования терх запросов. Где отчет?

Speshuric >1. Отчеты в фон и так неплохо переносятся (СКД+фоновые задания). Пример Запроса в фоновом задании //Вопрос в следующем как узнавать что все фоновые завершились?

Регистры отлично отбираются отборами, а подчиненные регистратору имеют обычно отношение 1:1 по числу строк таб части, искустенно ограниченной 100000 строк.

Это пример, как надо параллелить запросы 1С. Что вам не понятно по его коду? p.S> Я его назвал внешним отчетом.

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

Че за парадигма то?

Да, согласен, для регистров можно не одновременно. Остальное в силе.

Ну так и не отчет это вовсе, а обработка :)

Никто не знает, но звучить загодочно

Запрос должен быть один

Не херачить запросы в цикле например.

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

С чего бы это?

Я просил пример отчета, который имеет смысл ускорять таким способом, и который получает выигрыш от распараллеливания. В идеале - отчет для типовой конфы, чтобы можно было повторить и увидеть результат. Есть такое? Если нет, то хотя бы описание словами. Был такой-то отчет по таким-то данным в такой-то конфе, выполнялся столько-то, распараллелили так-то, получили столько-то. Хотя бы так можете? Нет? Тогда извините, а с чем же вы пришли? Как в анекдоте получается. "Дорогая, ты ж у меня умная, придумай сама что-нибудь".

->

В большинстве сложных запросов 1С всегда множество запросов SQL (заполнение виртуальных таблиц, и прочее).