На мой взгляд, тут даже интереснее не сама оптимизация FASTTRUNCATE, а то, как вообще 1С реализовала работу с временными таблицами.
По сути, там уже есть своеобразный pool временных таблиц: TEMP-таблица создается один раз на соединение для определенной структуры, после чего переиспользуется. То есть наиболее неприятный для PostgreSQL сценарий с постоянными CREATE/DROP и изменениями системного каталога в значительной степени уже устранен. А FASTTRUNCATE — это скорее оставшаяся цена за такое переиспользование.
При этом немного странно, что оптимизировать приходится именно на стороне PostgreSQL. После INSERT сервер 1С ведь, судя по RowsAffected, уже знает, что вставлено 0 строк. Если таблица перед этим гарантированно была очищена, логичнее вообще не посылать FASTTRUNCATE, чем отправлять его в СУБД, чтобы та там еще раз определяла, пустая таблица или нет.
И еще небольшая придирка к описанию AccessExclusiveLock. Фраза «снимаем блокировку, теперь она может быть использована другими сеансами» для TEMP-таблицы несколько сбивает с толку: PostgreSQL TEMP-таблица принадлежит конкретной сессии, и другие сессии ее в принципе использовать не могут. То есть эта блокировка здесь нужна не для конкуренции разных пользовательских сеансов за tt3.
А вот проблема со статистикой после ДОБАВИТЬ, на мой взгляд, существенно интереснее FASTTRUNCATE. Получается довольно неприятная абстракция: на уровне языка 1С мы просто добавили строки в существующую таблицу, а оптимизатор PostgreSQL после этого может принимать решения по статистике, которая описывает уже совсем другое содержимое. И решать это глобальным online_analyze тоже выглядит несколько тяжеловесно. Кажется, логичнее было бы самой платформе делать ANALYZE по некоторому порогу изменения размера ВТ. Именно так и делается в открытом и бесплатном lsFusion. Странно, что в 1С не доабвили такой возможности.
Просто по описанным Вами проблемам большинства low-code платформ она выглядит довольно интересным вариантом. Там нет вот этой истории с жестко заданными сущностями типа «сотрудник», «задача», «проект» и т.д. Предметная логика описывается декларативно, на существенно более высоком уровне абстракции, а уже платформа сама строит запросы и интерфейс.
При этом мне не совсем понятен тезис, что прямой доступ к базе — это обязательно преимущество платформы. Читать базу напрямую — да, удобно. Но писать туда в обход бизнес-логики в любой серьезной системе все равно довольно опасно. В lsFusion, например, это обычная реляционная БД и к таблицам можно обращаться напрямую через SQL, но запись напрямую не рекомендуется, потому что таким образом обходятся события, ограничения, материализации и т.д.
И еще интересный момент именно для обучения. Вы пишете, что изучение специфичного API low-code платформы дает студенту слишком узкие знания. Полностью согласен. Но мне кажется, что с учетом развития ИИ этот аргумент сейчас вообще становится гораздо менее существенным.
Уже сегодня человеку в принципе не обязательно хорошо знать конкретный синтаксис или API платформы. Достаточно понимать предметную область, модель данных, декларативные абстракции, транзакции, SQL и общие принципы разработки. В синтаксисе конкретной платформы, ее API и документации ИИ вполне способен разобраться сам и сгенерировать нужный код.
Поэтому, на мой взгляд, гораздо важнее учить не тому, куда нажимать в конкретном GUI-конструкторе и даже не конкретному синтаксису, а правильному уровню абстракции и способу описания бизнес-логики. То есть условно не генерировать код мышкой, а декларативно описывать саму предметную область.
Собственно, в lsFusion именно такой подход. Она к тому же open-source и бесплатная.
Было бы интересно, если бы Вы ее попробовали на одной из студенческих групп и сравнили именно с XRAD. Мне кажется, сравнение получилось бы довольно показательным.
Большое количество временных таблиц в IsFusion генерируют разработчики приложений или на уровне вашей платформы в определенных сценариях зашито использование временных таблиц, что и приводит к их большому количеству?
Разработчики вообще не знают ничего про SQL и временные таблицы. Все пишется на внутреннем высокоуровневом языке, а затем платформа сама генерирует запросы и при необходимости использует временные таблицы по мере необходимости. К сожалению, местами без них никак по ряду причин. Даже просто в запросах иногда приходится часть подзапроса переделывать на INSERT INTO временную таблицу, а затем с ней JOIN, чтобы у PostgreSQL была правильная статистика по результату этого подзапроса (если план явно ушел не туда).
Интересное решение, но непонятно какой эффект это дало и как оценить профит из фразы "На стенде четыре сохранения потребовали ноль CREATE вместо сорока"? Не добавило ли проблем то, что разные сеансы стали конкурировать за эти UNLOGGED таблицы?
Вообще эту проблему мы диагностировали недавно (так как все-таки пробка возникает не очень часто). Просто на данный момент мы прогнали все на тестах, и включили в работу для нескольких небольших клиентов. Понятно, что сразу это внедрять на самых крупных - не самая лучшая идея. Но пока да - нет еще статистики на крупных клиентах. Правда статья была о проблеме в PostgreSQL, а не о lsFusion.
Другое дело, что архитектурно там крупных изменений нет, так что непосредственно на работу сервера приложений это не должно повлиять. Фактически, там просто изменилось, что если раньше при необходимости получения таблицы смотрелось в пул временных таблиц сессий, то сейчас сначала ищется в общем пуле (с синхронизацией естественно). Понятно, что сам поиск там очень быстрый, а запросов относительно немного (то есть там не будет бутылочного горлышка).
А PostgreSQL разницы что там CREATE TEMPORARY TABLE, что CREATE TABLE UNLOGGED особо нет. Единственно, эти все unlogged таблицы грохаются на старте сервера на всякий, идут в отдельную схему и отдельный tablespace (например, к временным таблицам на диск в памяти).
При этом, если в общем пуле нет, и создать unlogged по какой-то причине нельзя, то идет fallback обратно к временным таблицами.
Тут будет плюс от unlogged в том, что у вас появляется параллелизм, если конечно результат такого запроса вы не помещаете во временную.
Это незначительно улучшение. Во-первых, потому что все-таки часто результат помещается во временную. А во-вторых, что важнее, параллелизм на такой нагрузке часто вреден, так как один долгий запрос может сильнее деградировать серверную работу. Конечно параллелизм бывает и полезен, но глобально тут нет большого выигрыша.
А вообще ваш выбранный 3 вариант это то, как делает платформа 1С
В смысле 1C использует UNLOGGED таблицы ? Если речь идет о пуле временных таблиц для соединений, то в lsFusion это было сделано давно (до этой статьи). И все равно этого не всегда хватает по ряду причин, так как таблицы, во-первых, выпадают из пула со временем, а, во-вторых, все равно надо создавать их для новых пользователей / подключений (если у вас тысячи подключений и тысячи временных таблиц, то нужны уже десятки, а то и сотни миллионов временных таблиц). На практике в инсталляциях с 2000 одновременно работающих пользователей, общее количество временных таблиц редко превышает 100К (то есть по 50 на соединение).
Конкретно последняя оптимизация была, чтобы вообще заменить их на unlogged и делить между разными подключениями (чего нельзя делать с временными таблицами).
очередь invalidation → LWLock → значит это причина LWLock:LockManager
в статье не доказан и технически слишком сильно упрощён.
Вполне возможно, что причинная связь косвенная: массовая invalidation заставляет backend'ы перестраивать relcache, снова открывать relations, брать relation locks, и уже это создаёт нагрузку на LockManager. Либо в Tantor есть свои изменения. Но показанного текста недостаточно, чтобы сказать, что ожидание LockManager возникло непосредственно на invalidation queue.
Это все замечательно, но в lsFusion используются только открытые и бесплатные технологии с точки зрения лицензий. Везде у нас используется только ванильный PostgreSQL. Наверное, на коммерческих СУБД это бы работало получше, но и на ванильном у нас пока проблемы с разрастанием каталога не так сильно влияют (скорее всего из-за того, что все равно lsFusion гораздо оптимальнее работает с временными таблицами, чем 1С).
Да, пришлось именно в транзакциях на уровне сервера приложения начать использовать вместо temporary обычные unlogged, и раздавать их на сервере приложений. Благо именно в запросах/использовании разницы между ними большой нет (хотя есть другие нюансы).
Но понятно, что не целиком заменили. Во-первых, это используется только там, где тысячи одновременно работающих пользователей. Для меньшей нагрузки "пробка" не образуется. А во-вторых, вне транзакции все равно местами могут использоваться временные (так как там нет долгой блокировки).
Так, надо перейти уже от чата ИИ-агентов к кожаным мешкам :) . Кстати, Вы чем пользуетесь для ответов ? У меня - GPT-6 Astra с максимальным reasoning, а у Вас какая-то очень странная модель. То есть текст вроде связанный, но смысл плывет.
И работает он ровно в ту сторону, о которой вы спрашиваете - зная, как устроено типовое, агент и отличает нетиповое
Это блин как ? Если я полностью переписал блок типовой, то RAG по документации типовой уже нерелавантен от слова совсем. Зачем вообще к документации обращаться ? Если же там пара правок в проведении, то как не зная этих правок узнать в чем косяк ? А если вообще не типовая, а нетленка написанная с нуля ? Тогда вообще это все бесполезно ?
А если и реквизиты в порядке, и проба расхождений не показывает - консоль так и скажет: тут дело в коде, идите в модуль. В этом и смысл: до конфигуратора или найма программиста можно не доходить.
Так, а если дело в коде, то что делать ? Тогда уже надо программиста нанимать ?
В общем в 1С все как всегда сделано не до конца и через одно место. Впрочем мыши плакали, кололись, но продолжали есть кактус.
Я примеры из lsFusion просто привожу, чтобы показать, что можно сделать нормально. И это не нерешаемая задача, если подойти с умом.
Исходники понадобились один раз — узнать правило отбора и формулу
Так я ровно об этом и говорю. Один раз понадобились - это уже не "не нужны" :) Если алгоритм заранее известен и соответствует текущей конфигурации, перечитывать его для каждого документа действительно незачем. Только откуда агент его узнал, вы сейчас сами и написали.
В колонке “почему” кода нет ни разу.
А там должен был быть листинг ? Агент прочитал код, применил найденные правила к данным и объяснил результат человеческим языком. Отсутствие исходников в итоговой таблице ничего не говорит об их роли в получении ответа. Иначе можно еще заявить, что запросы не понадобились: их же в таблице тоже нет.
Например, в приведенном разборе скидка называется «по карте», но фактически применяется и без карты. Запрос покажет настройки скидки. А как из одних настроек установить, проверяет ли программа наличие карты, при каких условиях пропускает эту проверку и какое правило выбирает при нескольких подходящих скидках ? Для этого надо знать, как программа эти настройки использует.
Дальше появляется RAG по типовым конфигурациям. Для известной версии типовой конфигурации это вполне может помочь. Только начинали мы с чужой базы. Если в ней изменили алгоритм, а база знаний описывает типовой, как агент обнаружит расхождение ? В статье вас беспокоила устаревшая выгрузка. Почему устаревшее относительно конкретной базы описание вдруг перестает быть проблемой ?
И пример с lsFusion - это демонстрация работающего подхода. Требования сначала сменить платформу, чтобы признать пользу доступа к исходникам, там не было.
Но давайте проще: покажите аналогичный разбор вашей консолью на незнакомой доработанной конфигурации, с ходом работы агента и проверяемым результатом. Я такой пример привел. Пока в ответ выяснилось, что код не нужен, если предварительно узнать из него всё необходимое. С таким условием спорить действительно трудно :)
Здесь код агенту не нужен, нужны метаданные и возможность выполнить запрос
А как из метаданных понять, почему получилась именно такая сумма ? Название реквизита объяснит алгоритм расчета, условия применения скидок и особенности доработанного проведения ? Выполнить запрос и получить число — это еще не разобраться, откуда оно взялось.
У вас же в начале статьи задача именно такая: чужая конфигурация, нужно понять происхождение чисел. А к концу выясняется, что код для этого не нужен. Удобно получилось: к чему платформа нормально не дает доступа, то объявляем необязательным :)
В lsFusion, например, сервер приложения сам предоставляет MCP с чтением загруженных исходников и выполнением кода. Агент может прочитать бизнес-логику и проверить ее на конкретных данных. Вот пример со скидками в MyCompany: Claude разобрал условия применения скидок, сверил расчет по строкам документа и обнаружил, что у скидки «от 110 рублей» в настройках стоит 11000. А скидка «по карте» вообще не проверяет наличие карты. По названиям объектов он бы прекрасно «понял» ровно противоположное.
Поэтому претензия к выгрузкам вполне обоснованная. Только каким образом консоль запросов с агентом внутри решает описанную проблему доступа к коду ? Или проблема нужна была для первой половины статьи, а продукт нашелся только для второй ?
А пробовали тупо Claude Fable 5.1 запустить сгенерировать такое приложение с такими-то требованиями ? И сравнить с тем, что получилось. Мне кажется, что для такого маленького контекста он вряд ли запутается в чем-то. Тем более, что надежность не столь важна.
Забавная получилась пропорция. Три четверти статьи - пересказ, что такое ИИ-агенты, с вдохновляющим примером про командировку в Казань, где агент сам покупает билеты, бронирует отель и рассылает приглашения коллегам. А в последнем разделе выясняется, что агентский режим Напарника - это многошаговый поиск по документации. То есть от агента, который делает в системе всё то же, что и пользователь, осталось «RAG, умеющий искать больше одного раза». Это не агент из вашего же вступления, это ассистент 2023 года, которого пустили по циклу.
Отдельно хорош UX: чтобы получить нормальный ответ, пользователь должен сначала получить плохой, самостоятельно диагностировать, что он плохой, поставить дизлайк и нажать кнопку с гордым словом ПРО. При этом парой абзацев выше вы сами пишете, что пользователи предупреждения не читают и жмут ОК не глядя - но всю развилку качества ответа вешаете ровно на осознанное действие того же пользователя. Похоже, дизлайк здесь работает не как UX-решение, а как фильтр расходов на инференс, и честнее было бы так и написать.
По безопасности — логическое противоречие в соседних абзацах. Сначала: не можем гарантировать, что модель не обойдёт ограничения доступа. Через абзац: самое надёжное — гонять все вызовы инструментов под ролевой моделью от имени запустившего пользователя. Так если второе сделано, первое гарантируется автоматически: модель физически не получит то, что ей не отдаст сервер, и "решать" ей тут нечего. А если гарантий нет - значит, права проверяются не в том месте, и это проблема архитектуры, а не ИИ. Ролевая модель, которая держится на вежливости клиента, ролевой моделью не является.
Ну и главный вопрос, который в статье аккуратно обойдён: где MCP-сервер самой 1С? Полстатьи про то, что MCP - это REST для агентов, предостережения про чужие серверы... а подключить Claude Code или Cursor к своей базе, чтобы агент создавал документы, читал регистры и запускал обработки под правами пользователя - можно? Потому что командировка в Казань из вступления - это ровно оно: инструменты-действия в учётной системе, а не поиск по ИТС. Мы у себя в lsFusion такой MCP-сервер к платформе прикрутили - агент под правами пользователя и данные читает, и действия выполняет, и никакой отдельной ПРО-кнопки для этого не понадобилось. Вот пример выполнения.
А самое интересное тут всё-таки не генерация SCL и даже не поиск по коду, а возможность агента самому проверить свои выводы на работающей системе.
Вот, например, в lsFusion я просто спросил, как провести входящий инвойс в другой валюте. Агент сам разобрал код, сходил в демо-базу, проверил расчёты на конкретном документе и нашёл вполне реальную ошибку: склад и задолженность пересчитываются по курсу, а проводки - нет. Получилось вот так.
И изменения он тоже может делать. Просто попросил найти поставщика с максимальной задолженностью и заплатить ему половину долга. Агент сам нашёл поставщика, создал платёж, привязал его к счёту и проверил результат: вот результат.
А можно увидеть что-то подобное для TIA Portal, именно как это работает вживую ? Например, дать агенту открытый незнакомый проект и попросить найти цепочку какого-нибудь сигнала, проверить гипотезу, подготовить изменение и скомпилировать его. Интересен именно полный ход работы агента и что у него получится, а не только итоговое описание.
Но для понимания текущих возможностей ИИ. Он без проблем может прочитать исходной код относительно сложной программы, понять его, и написать пользовательскую документацию на его основе, самостоятельно сделав при этом скриншоты. Например, вот эта вся документация написана полностью ИИ только на основе кода : https://mycompany-docs.lsfusion.org/ru/
Хорошо, что перед генерацией агент смотрит именно реальную конфигурацию, а не общую документацию. Но чтение контекста — всё-таки только половина замкнутого цикла. Правильно ли я понимаю, что после генерации он пока не может выполнить код или запрос на тестовой базе, посмотреть фактический результат и сам себя перепроверить?
Мы в lsFusion сделали MCP прямо в сервере приложений: внешний агент читает реально загруженные исходники и может выполнять lsFusion-скрипты под правами пользователя. Например, на демо MyCompany Claude по одному запросу разбирает бизнес-логику, проверяет данные и замечает ограничения, о которых его прямо не спрашивали.
Планируете добавить такой execution/verification loop и, возможно, открыть вашу аналитическую модель через MCP для любых клиентов — Claude, Codex и т. п.?
Переделка регистра оборотов в регистр остатков означает перепроведение всех документов.
Отличная иллюстрация того, зачем отделять бизнес-логику от способа хранения данных.В lsFusion понятий "регистр остатков" и "регистр оборотов" на уровне платформы вообще нет. Движения описываются как обычные объекты, а остаток - декларативной агрегацией GROUP SUM. Нужен быстрый текущий остаток — добавляется MATERIALIZED; нужны обороты за период — материализуется другая агрегация. Механизм проведения документов при этом менять не требуется.Получается, в 1С минутный выбор действительно определяет поведение системы годами, а в lsFusion это фактически один флаг у вычисляемого свойства.
Что значит как ? Поиском в интернете :) Если очень надо, то можно их просто выложить рядом локально.
И речь же шла не столько о регламентной части учета, а просто обо всех конфигурациях на платформе. Бухгалтерия и регламентный учет - это небольшая часть всех бизнес-приложений.
А нельзя просто подключить к ИИ конфигурацию как MCP сервер, в котором будут возможности по считыванию кода, и запуска скриптов, чтобы ИИ сам бы разбирался в том, как это работает, и себя проверял ?
Для наглядности, вот пример. Подключил Claude к демо MyCompany , и задал простой вопрос :
Как ввести входящий инвойс в MyCompany в другой валюте и как он будет отражен в учете ?
Они сами проанализировали код, проверили на реальных данных, нашли ошибки и даже предложили как исправить. Плюс такого подхода, что он будет работать и с модифицированными конфигурациями на основе сделанных там изменений, а не по официальной документации.
А в чем прикол собственно разгонять про совершенно другую платформу, в посте с тестами моделей на 1С?)
"Критикуешь - предлагай" (C). Есть такая концепция. Часто бывает необоснованная критика, когда от кого-то ожидается то, что сделать теоретически невозможно.
Я просто показываю пример, что это можно сделать и даже в open-source. Просто важно с умом подходить к решению.
Или вы к тому, что какая-то "lsFusion", непонятно откуда взявшаяся лучше чем 1С и является его заменой?)
Только вот реальность такова что 80-90% бизнеса как сидели в 1С так и будут.
Да, не спорю. Реальность такова, что 80-90% людей во всем мире луддиты. И в США еще куча систем на COBOL. Но это не значит, что думающие и прогрессивные люди всегда ищут лучшую альтернативу и её используют. И да, понятно, что таких людей меньше, чем луддитов.
Специалист по бэку тут зачем ? А на мобиле и 1С специалист с клодом прекрасно справится. ИИ хреново умеет в 1С, а вот в простую мобилу он отлично умеет. 1С-специалисту нужно будет только промпты генерить и все. Дополнительные спецы не потребуется.
Если же речь идет о разработке без 1С, то есть такое понятие Full Stack Developer. Он умеет во всё сразу.
А в современных реалиях достаточно одного Team Lead и Claude, чтобы разработать все, что угодно. На базе node.js или lsFusion - это не принципиально.
На мой взгляд, тут даже интереснее не сама оптимизация FASTTRUNCATE, а то, как вообще 1С реализовала работу с временными таблицами.
По сути, там уже есть своеобразный pool временных таблиц: TEMP-таблица создается один раз на соединение для определенной структуры, после чего переиспользуется. То есть наиболее неприятный для PostgreSQL сценарий с постоянными CREATE/DROP и изменениями системного каталога в значительной степени уже устранен. А FASTTRUNCATE — это скорее оставшаяся цена за такое переиспользование.
При этом немного странно, что оптимизировать приходится именно на стороне PostgreSQL. После INSERT сервер 1С ведь, судя по RowsAffected, уже знает, что вставлено 0 строк. Если таблица перед этим гарантированно была очищена, логичнее вообще не посылать FASTTRUNCATE, чем отправлять его в СУБД, чтобы та там еще раз определяла, пустая таблица или нет.
И еще небольшая придирка к описанию AccessExclusiveLock. Фраза «снимаем блокировку, теперь она может быть использована другими сеансами» для TEMP-таблицы несколько сбивает с толку: PostgreSQL TEMP-таблица принадлежит конкретной сессии, и другие сессии ее в принципе использовать не могут. То есть эта блокировка здесь нужна не для конкуренции разных пользовательских сеансов за tt3.
А вот проблема со статистикой после ДОБАВИТЬ, на мой взгляд, существенно интереснее FASTTRUNCATE. Получается довольно неприятная абстракция: на уровне языка 1С мы просто добавили строки в существующую таблицу, а оптимизатор PostgreSQL после этого может принимать решения по статистике, которая описывает уже совсем другое содержимое. И решать это глобальным online_analyze тоже выглядит несколько тяжеловесно. Кажется, логичнее было бы самой платформе делать ANALYZE по некоторому порогу изменения размера ВТ. Именно так и делается в открытом и бесплатном lsFusion. Странно, что в 1С не доабвили такой возможности.
А lsFusion при выборе не рассматривали?
Просто по описанным Вами проблемам большинства low-code платформ она выглядит довольно интересным вариантом. Там нет вот этой истории с жестко заданными сущностями типа «сотрудник», «задача», «проект» и т.д. Предметная логика описывается декларативно, на существенно более высоком уровне абстракции, а уже платформа сама строит запросы и интерфейс.
При этом мне не совсем понятен тезис, что прямой доступ к базе — это обязательно преимущество платформы. Читать базу напрямую — да, удобно. Но писать туда в обход бизнес-логики в любой серьезной системе все равно довольно опасно. В lsFusion, например, это обычная реляционная БД и к таблицам можно обращаться напрямую через SQL, но запись напрямую не рекомендуется, потому что таким образом обходятся события, ограничения, материализации и т.д.
И еще интересный момент именно для обучения. Вы пишете, что изучение специфичного API low-code платформы дает студенту слишком узкие знания. Полностью согласен. Но мне кажется, что с учетом развития ИИ этот аргумент сейчас вообще становится гораздо менее существенным.
Уже сегодня человеку в принципе не обязательно хорошо знать конкретный синтаксис или API платформы. Достаточно понимать предметную область, модель данных, декларативные абстракции, транзакции, SQL и общие принципы разработки. В синтаксисе конкретной платформы, ее API и документации ИИ вполне способен разобраться сам и сгенерировать нужный код.
Поэтому, на мой взгляд, гораздо важнее учить не тому, куда нажимать в конкретном GUI-конструкторе и даже не конкретному синтаксису, а правильному уровню абстракции и способу описания бизнес-логики. То есть условно не генерировать код мышкой, а декларативно описывать саму предметную область.
Собственно, в lsFusion именно такой подход. Она к тому же open-source и бесплатная.
Было бы интересно, если бы Вы ее попробовали на одной из студенческих групп и сравнили именно с XRAD. Мне кажется, сравнение получилось бы довольно показательным.
Разработчики вообще не знают ничего про SQL и временные таблицы. Все пишется на внутреннем высокоуровневом языке, а затем платформа сама генерирует запросы и при необходимости использует временные таблицы по мере необходимости. К сожалению, местами без них никак по ряду причин. Даже просто в запросах иногда приходится часть подзапроса переделывать на INSERT INTO временную таблицу, а затем с ней JOIN, чтобы у PostgreSQL была правильная статистика по результату этого подзапроса (если план явно ушел не туда).
Вообще эту проблему мы диагностировали недавно (так как все-таки пробка возникает не очень часто). Просто на данный момент мы прогнали все на тестах, и включили в работу для нескольких небольших клиентов. Понятно, что сразу это внедрять на самых крупных - не самая лучшая идея. Но пока да - нет еще статистики на крупных клиентах. Правда статья была о проблеме в PostgreSQL, а не о lsFusion.
Другое дело, что архитектурно там крупных изменений нет, так что непосредственно на работу сервера приложений это не должно повлиять. Фактически, там просто изменилось, что если раньше при необходимости получения таблицы смотрелось в пул временных таблиц сессий, то сейчас сначала ищется в общем пуле (с синхронизацией естественно). Понятно, что сам поиск там очень быстрый, а запросов относительно немного (то есть там не будет бутылочного горлышка).
А PostgreSQL разницы что там CREATE TEMPORARY TABLE, что CREATE TABLE UNLOGGED особо нет. Единственно, эти все unlogged таблицы грохаются на старте сервера на всякий, идут в отдельную схему и отдельный tablespace (например, к временным таблицам на диск в памяти).
При этом, если в общем пуле нет, и создать unlogged по какой-то причине нельзя, то идет fallback обратно к временным таблицами.
Это незначительно улучшение. Во-первых, потому что все-таки часто результат помещается во временную. А во-вторых, что важнее, параллелизм на такой нагрузке часто вреден, так как один долгий запрос может сильнее деградировать серверную работу. Конечно параллелизм бывает и полезен, но глобально тут нет большого выигрыша.
В смысле 1C использует UNLOGGED таблицы ? Если речь идет о пуле временных таблиц для соединений, то в lsFusion это было сделано давно (до этой статьи). И все равно этого не всегда хватает по ряду причин, так как таблицы, во-первых, выпадают из пула со временем, а, во-вторых, все равно надо создавать их для новых пользователей / подключений (если у вас тысячи подключений и тысячи временных таблиц, то нужны уже десятки, а то и сотни миллионов временных таблиц). На практике в инсталляциях с 2000 одновременно работающих пользователей, общее количество временных таблиц редко превышает 100К (то есть по 50 на соединение).
Конкретно последняя оптимизация была, чтобы вообще заменить их на unlogged и делить между разными подключениями (чего нельзя делать с временными таблицами).
Все-таки это больше похоже на другую проблему (то есть не из-за корзин, а из-за разрастания каталогов) :
В vanilla PostgreSQL это разные LWLock wait events:
LockManager— доступ к информации о heavyweight locks;SInvalRead/SInvalWrite— чтение/запись shared catalog invalidation queue.Поэтому переход
в статье не доказан и технически слишком сильно упрощён.
Вполне возможно, что причинная связь косвенная: массовая invalidation заставляет backend'ы перестраивать relcache, снова открывать relations, брать relation locks, и уже это создаёт нагрузку на
LockManager. Либо в Tantor есть свои изменения. Но показанного текста недостаточно, чтобы сказать, что ожиданиеLockManagerвозникло непосредственно на invalidation queue.Это все замечательно, но в lsFusion используются только открытые и бесплатные технологии с точки зрения лицензий. Везде у нас используется только ванильный PostgreSQL. Наверное, на коммерческих СУБД это бы работало получше, но и на ванильном у нас пока проблемы с разрастанием каталога не так сильно влияют (скорее всего из-за того, что все равно lsFusion гораздо оптимальнее работает с временными таблицами, чем 1С).
Да, пришлось именно в транзакциях на уровне сервера приложения начать использовать вместо temporary обычные unlogged, и раздавать их на сервере приложений. Благо именно в запросах/использовании разницы между ними большой нет (хотя есть другие нюансы).
Но понятно, что не целиком заменили. Во-первых, это используется только там, где тысячи одновременно работающих пользователей. Для меньшей нагрузки "пробка" не образуется. А во-вторых, вне транзакции все равно местами могут использоваться временные (так как там нет долгой блокировки).
Так, надо перейти уже от чата ИИ-агентов к кожаным мешкам :) . Кстати, Вы чем пользуетесь для ответов ? У меня - GPT-6 Astra с максимальным reasoning, а у Вас какая-то очень странная модель. То есть текст вроде связанный, но смысл плывет.
Это блин как ? Если я полностью переписал блок типовой, то RAG по документации типовой уже нерелавантен от слова совсем. Зачем вообще к документации обращаться ? Если же там пара правок в проведении, то как не зная этих правок узнать в чем косяк ? А если вообще не типовая, а нетленка написанная с нуля ? Тогда вообще это все бесполезно ?
Так, а если дело в коде, то что делать ? Тогда уже надо программиста нанимать ?
В общем в 1С все как всегда сделано не до конца и через одно место. Впрочем мыши плакали, кололись, но продолжали есть кактус.
Я примеры из lsFusion просто привожу, чтобы показать, что можно сделать нормально. И это не нерешаемая задача, если подойти с умом.
Так я ровно об этом и говорю. Один раз понадобились - это уже не "не нужны" :) Если алгоритм заранее известен и соответствует текущей конфигурации, перечитывать его для каждого документа действительно незачем. Только откуда агент его узнал, вы сейчас сами и написали.
А там должен был быть листинг ? Агент прочитал код, применил найденные правила к данным и объяснил результат человеческим языком. Отсутствие исходников в итоговой таблице ничего не говорит об их роли в получении ответа. Иначе можно еще заявить, что запросы не понадобились: их же в таблице тоже нет.
Например, в приведенном разборе скидка называется «по карте», но фактически применяется и без карты. Запрос покажет настройки скидки. А как из одних настроек установить, проверяет ли программа наличие карты, при каких условиях пропускает эту проверку и какое правило выбирает при нескольких подходящих скидках ? Для этого надо знать, как программа эти настройки использует.
Дальше появляется RAG по типовым конфигурациям. Для известной версии типовой конфигурации это вполне может помочь. Только начинали мы с чужой базы. Если в ней изменили алгоритм, а база знаний описывает типовой, как агент обнаружит расхождение ? В статье вас беспокоила устаревшая выгрузка. Почему устаревшее относительно конкретной базы описание вдруг перестает быть проблемой ?
И пример с lsFusion - это демонстрация работающего подхода. Требования сначала сменить платформу, чтобы признать пользу доступа к исходникам, там не было.
Но давайте проще: покажите аналогичный разбор вашей консолью на незнакомой доработанной конфигурации, с ходом работы агента и проверяемым результатом. Я такой пример привел. Пока в ответ выяснилось, что код не нужен, если предварительно узнать из него всё необходимое. С таким условием спорить действительно трудно :)
А как из метаданных понять, почему получилась именно такая сумма ? Название реквизита объяснит алгоритм расчета, условия применения скидок и особенности доработанного проведения ? Выполнить запрос и получить число — это еще не разобраться, откуда оно взялось.
У вас же в начале статьи задача именно такая: чужая конфигурация, нужно понять происхождение чисел. А к концу выясняется, что код для этого не нужен. Удобно получилось: к чему платформа нормально не дает доступа, то объявляем необязательным :)
В lsFusion, например, сервер приложения сам предоставляет MCP с чтением загруженных исходников и выполнением кода. Агент может прочитать бизнес-логику и проверить ее на конкретных данных. Вот пример со скидками в MyCompany: Claude разобрал условия применения скидок, сверил расчет по строкам документа и обнаружил, что у скидки «от 110 рублей» в настройках стоит 11000. А скидка «по карте» вообще не проверяет наличие карты. По названиям объектов он бы прекрасно «понял» ровно противоположное.
Поэтому претензия к выгрузкам вполне обоснованная. Только каким образом консоль запросов с агентом внутри решает описанную проблему доступа к коду ? Или проблема нужна была для первой половины статьи, а продукт нашелся только для второй ?
А пробовали тупо Claude Fable 5.1 запустить сгенерировать такое приложение с такими-то требованиями ? И сравнить с тем, что получилось. Мне кажется, что для такого маленького контекста он вряд ли запутается в чем-то. Тем более, что надежность не столь важна.
Забавная получилась пропорция. Три четверти статьи - пересказ, что такое ИИ-агенты, с вдохновляющим примером про командировку в Казань, где агент сам покупает билеты, бронирует отель и рассылает приглашения коллегам. А в последнем разделе выясняется, что агентский режим Напарника - это многошаговый поиск по документации. То есть от агента, который делает в системе всё то же, что и пользователь, осталось «RAG, умеющий искать больше одного раза». Это не агент из вашего же вступления, это ассистент 2023 года, которого пустили по циклу.
Отдельно хорош UX: чтобы получить нормальный ответ, пользователь должен сначала получить плохой, самостоятельно диагностировать, что он плохой, поставить дизлайк и нажать кнопку с гордым словом ПРО. При этом парой абзацев выше вы сами пишете, что пользователи предупреждения не читают и жмут ОК не глядя - но всю развилку качества ответа вешаете ровно на осознанное действие того же пользователя. Похоже, дизлайк здесь работает не как UX-решение, а как фильтр расходов на инференс, и честнее было бы так и написать.
По безопасности — логическое противоречие в соседних абзацах. Сначала: не можем гарантировать, что модель не обойдёт ограничения доступа. Через абзац: самое надёжное — гонять все вызовы инструментов под ролевой моделью от имени запустившего пользователя. Так если второе сделано, первое гарантируется автоматически: модель физически не получит то, что ей не отдаст сервер, и "решать" ей тут нечего. А если гарантий нет - значит, права проверяются не в том месте, и это проблема архитектуры, а не ИИ. Ролевая модель, которая держится на вежливости клиента, ролевой моделью не является.
Ну и главный вопрос, который в статье аккуратно обойдён: где MCP-сервер самой 1С? Полстатьи про то, что MCP - это REST для агентов, предостережения про чужие серверы... а подключить Claude Code или Cursor к своей базе, чтобы агент создавал документы, читал регистры и запускал обработки под правами пользователя - можно? Потому что командировка в Казань из вступления - это ровно оно: инструменты-действия в учётной системе, а не поиск по ИТС. Мы у себя в lsFusion такой MCP-сервер к платформе прикрутили - агент под правами пользователя и данные читает, и действия выполняет, и никакой отдельной ПРО-кнопки для этого не понадобилось. Вот пример выполнения.
А самое интересное тут всё-таки не генерация SCL и даже не поиск по коду, а возможность агента самому проверить свои выводы на работающей системе.
Вот, например, в lsFusion я просто спросил, как провести входящий инвойс в другой валюте. Агент сам разобрал код, сходил в демо-базу, проверил расчёты на конкретном документе и нашёл вполне реальную ошибку: склад и задолженность пересчитываются по курсу, а проводки - нет. Получилось вот так.
И изменения он тоже может делать. Просто попросил найти поставщика с максимальной задолженностью и заплатить ему половину долга. Агент сам нашёл поставщика, создал платёж, привязал его к счёту и проверил результат: вот результат.
А можно увидеть что-то подобное для TIA Portal, именно как это работает вживую ? Например, дать агенту открытый незнакомый проект и попросить найти цепочку какого-нибудь сигнала, проверить гипотезу, подготовить изменение и скомпилировать его. Интересен именно полный ход работы агента и что у него получится, а не только итоговое описание.
Если ИИ имеет доступ к исходному коду, то он на его основе может спокойно разобрать всю логику понять и объяснить, как это работает. Вот пример : https://claude.ai/share/13c944c1-3683-4054-b2f3-53210c8274c2
Но для понимания текущих возможностей ИИ. Он без проблем может прочитать исходной код относительно сложной программы, понять его, и написать пользовательскую документацию на его основе, самостоятельно сделав при этом скриншоты. Например, вот эта вся документация написана полностью ИИ только на основе кода : https://mycompany-docs.lsfusion.org/ru/
Хорошо, что перед генерацией агент смотрит именно реальную конфигурацию, а не общую документацию. Но чтение контекста — всё-таки только половина замкнутого цикла. Правильно ли я понимаю, что после генерации он пока не может выполнить код или запрос на тестовой базе, посмотреть фактический результат и сам себя перепроверить?
Мы в lsFusion сделали MCP прямо в сервере приложений: внешний агент читает реально загруженные исходники и может выполнять lsFusion-скрипты под правами пользователя. Например, на демо MyCompany Claude по одному запросу разбирает бизнес-логику, проверяет данные и замечает ограничения, о которых его прямо не спрашивали.
Вот пример : https://claude.ai/share/bd0b0d12-75e5-4d6f-ade3-8e78f55984f3
Планируете добавить такой execution/verification loop и, возможно, открыть вашу аналитическую модель через MCP для любых клиентов — Claude, Codex и т. п.?
Отличная иллюстрация того, зачем отделять бизнес-логику от способа хранения данных.В lsFusion понятий "регистр остатков" и "регистр оборотов" на уровне платформы вообще нет. Движения описываются как обычные объекты, а остаток - декларативной агрегацией
GROUP SUM. Нужен быстрый текущий остаток — добавляетсяMATERIALIZED; нужны обороты за период — материализуется другая агрегация. Механизм проведения документов при этом менять не требуется.Получается, в 1С минутный выбор действительно определяет поведение системы годами, а в lsFusion это фактически один флаг у вычисляемого свойства.Здесь есть пример с кодом: Как могли бы выглядеть регистры в 1С при наличии ООП
Сорри, не та ссылка : https://chatgpt.com/share/6a858544-7010-83ed-abae-63c0dfa27d42
Ну, смотря что считать "решается". Вот пример : https://chatgpt.com/c/6a858480-e944-83eb-86fc-c0b1db25f5bc
Но понятно, что можно подложить ему через MCP самому нужные документы, и он будет прекрасно искать в них.
Что значит как ? Поиском в интернете :) Если очень надо, то можно их просто выложить рядом локально.
И речь же шла не столько о регламентной части учета, а просто обо всех конфигурациях на платформе. Бухгалтерия и регламентный учет - это небольшая часть всех бизнес-приложений.
А нельзя просто подключить к ИИ конфигурацию как MCP сервер, в котором будут возможности по считыванию кода, и запуска скриптов, чтобы ИИ сам бы разбирался в том, как это работает, и себя проверял ?
Для наглядности, вот пример. Подключил Claude к демо MyCompany , и задал простой вопрос :
Ответ Claude : https://claude.ai/chat/ea9a29f1-7c90-4930-9118-9f5c4fce1f4e
Ответ ChatGPT : https://chatgpt.com/share/6a85726f-e3e8-83eb-aaed-2687982c0db8
Они сами проанализировали код, проверили на реальных данных, нашли ошибки и даже предложили как исправить. Плюс такого подхода, что он будет работать и с модифицированными конфигурациями на основе сделанных там изменений, а не по официальной документации.
Кроме того, такой бот сможет сам проверять данные, и даже их изменять : https://claude.ai/share/bd0b0d12-75e5-4d6f-ade3-8e78f55984f3
"Критикуешь - предлагай" (C). Есть такая концепция. Часто бывает необоснованная критика, когда от кого-то ожидается то, что сделать теоретически невозможно.
Я просто показываю пример, что это можно сделать и даже в open-source. Просто важно с умом подходить к решению.
Непонятно откуда взявшаяся ? Да тут это обсуждается с 2019 года : https://habr.com/ru/companies/lsfusion/articles/. Не говоря уже про статью "Почему не 1С" c 1800 комментариями.
Да, не спорю. Реальность такова, что 80-90% людей во всем мире луддиты. И в США еще куча систем на COBOL. Но это не значит, что думающие и прогрессивные люди всегда ищут лучшую альтернативу и её используют. И да, понятно, что таких людей меньше, чем луддитов.
Специалист по бэку тут зачем ? А на мобиле и 1С специалист с клодом прекрасно справится. ИИ хреново умеет в 1С, а вот в простую мобилу он отлично умеет. 1С-специалисту нужно будет только промпты генерить и все. Дополнительные спецы не потребуется.
Если же речь идет о разработке без 1С, то есть такое понятие Full Stack Developer. Он умеет во всё сразу.
А в современных реалиях достаточно одного Team Lead и Claude, чтобы разработать все, что угодно. На базе node.js или lsFusion - это не принципиально.