Признаю, что момент с SELECT я упустил. Скриншот ИТС с инструкцией по EXPLAIN ANALYZE SELECT подтверждает, что для задач отладки вендор такое чтение прямо рекомендует. Вопрос с SELECT закрыт, аргумент принимается.
Что касается границ применимости стороннего софта для маскирования - запрос в отдел лицензирования «1С» (lic@1c.ru) отправлен сегодня в исходном виде. Ответ опубликую здесь.
Спасибо за фидбек! Отдельную статью писать не планирую — у меня нет цели устраивать масштабные дискуссии, хочется лишь зафиксировать этот нюанс для практики. По поводу “смены позиции”: я не переобувался. Интерактивный SELECT пользователя через pgAdmin или другие инструменты в обход платформы по-прежнему остается для меня нарушением Лицензионного соглашения, и ссылок на ИТС, разрешающих это, я пока не видел. Если таковые имеются, я буду искренне рад с ними ознакомиться. Разница лишь в том, что статья ИТС, которую вы выше привели, разрешает выгрузку сырых таблиц (в том числе частичную) через pg_dump -t как легитимное исключение для регламентных работ. Но разрешает ли EULA использовать сторонний софт, который в процессе этой выгрузки на лету модифицирует и маскирует данные функциями СУБД - это третья, пограничная сущность. Именно этот момент я и вынес в запрос, чтобы убрать двоякие трактовки. Инструмент у вас получился действительно очень полезный и нужный для сообщества, спасибо вам за него. Как и писал выше, соберу замечания до четверга, после чего отправлю этот нейтральный запрос в lic@1c.ru. Полученным ответом вендора обязательно поделюсь здесь.
Коллеги, чтобы не заниматься взаимной трактовкой правил лицензирования Фирмы "1С" и не спорить о границах применимости статьи ИТС, предлагаю цивилизованно получить официальный ответ первоисточника.
Я подготовил текст официального запроса в отдел лицензирования «1С» (lic@1c.ru). Прошу вас взглянуть на него. Если формулировка технически точна и корректно описывает суть нашего обсуждения, я отправлю её вендору, а результатом поделюсь здесь. Если нужно что-то поправить, чтобы запрос оставался абсолютно объективным — пишите.
Текст запроса: Здравствуйте! Прошу дать официальное разъяснение отдела лицензирования Фирмы «1С» относительно границ использования средств СУБД в контексте Лицензионного соглашения с пользователем «1С:Предприятия 8». В официальном FAQ по лицензированию Фирмы «1С» (вопрос № Х. 6-65) указано: «...внесистемные средства СУБД можно использовать только в том случае, если документация по продуктам линейки 1С:Предприятие (включая ИТС) содержит явную рекомендацию использовать данное средство для решения данной задачи». Методические материалы портала 1С:ИТС в статье «Методика расследования проблем производительности на уровне работы СУБД PostgreSQL» https://its.1c.ru/db/metod8dev#content:6011:hdoc допускают и рекомендуют использование штатных средств выборочной выгрузки таблиц СУБД (pg_dump -t ...) для передачи разработчикам отдельных таблиц данных (справочников, документов, регистров сведений и накопления) с целью воспроизведения ошибок. Прошу разъяснить — является ли нарушением Лицензионного соглашения применение в процессе выгрузки сторонних SQL-функций, расширений или скриптов СУБД для модификации и маскирования (обезличивания) содержащихся в таблицах данных "1С" (справочниках, документах, регистрах) персональных и коммерческих сведений?
Коллеги, чтобы не затягивать процесс, предлагаю собрать ваши конструктивные правки и замечания к тексту до четверга включительно. Если критических уточнений к формулировкам не поступит, отправляю запрос в Фирму "1С" в текущем виде. По получении официального ответа — сразу опубликую его здесь.
Бэкап средствами СУБД не является нарушением. Выдержка из faq: "Это означает, что средства СУБД (или любые другие внесистемные средства) можно использовать только в том случае, если документация по продуктам линейки «1С:Предприятие» (включая 1С: ИТС) содержит явную рекомендацию использовать данное средство для решения данной задачи". Выдержка из ИТС: "В случае клиент-серверного варианта для создания резервных копий рекомендуется использовать средства СУБД. Более подробно см. в книге «1С:Предприятие 8.3. Клиент-серверный вариант. Руководство администратора»."
Ни в коем случае не хотел задеть чьи-то чувства, инструмент действительно отличный! Но в официальном FAQ по лицензированию «1С» четко прописан запрет на любое прямое взаимодействие с таблицами, включая чтение через pgAdmin. По правилам вендора, любая работа с данными в обход сервера приложений считается нарушением, так как это обходит логику лицензирования платформы. И вы немного слукавили в pg_anon не только селект.
Полезный инструмент, спасибо за статью! Хотелось бы добавить небольшое предостережение: не забывайте про лицензионное соглашение «1С». Прямое взаимодействие с СУБД (даже на уровне чтения) нарушает правила лицензирования - подробнее об этом можно почитать в официальном FAQ 1С, вопрос № X. 6-65
Спасибо за наводку. Пробовал использовать pg_stat_statements, но в итоге вернулся к логам и pgbadger.
Мне в работе оказалась полезна ретроспектива: например, если 1 января вышло обновление с багом, в агрегированной статистике pg_stat_statements я увижу только "среднюю температуру" за всё время. Логи же позволяют "отмотать пленку" назад и сравнить производительность по конкретным дням или неделям. Так же парсинг логов через pgbadger можно вынести на отдельный сервер. Возможно, я просто еще не до конца раскрыл для себя потенциал pg_stat_statements, но для еженедельного аудита формат pgbadger мне показался нагляднее.
Спасибо за поправку! Ошибся в этом моменте — про кольцевой буфер и Buffer Access Strategy не знал, изучу. Мой фокус в этом кейсе был больше на методике регулярной проверки: как через pgbadger и системный анализ планов находить и устранять узкие места в СУБД
На самом деле получилось собрать рабочую техническую связку, которая стабильно (без галлюцинаций) вытаскивает атомарные данные по запросу на естественном языке. Под "готовностью к Enterprise" я, пожалуй, поспешно подразумевал лишь инфраструктурную часть: стек Java/Spring AI, работу в закрытом контуре и безопасность данных. С точки зрения бизнеса — это пока лишь умная поисковая строка. Статья — это в первую очередь история моего пути от наивного "сейчас заменю всех" до понимания, что ИИ — это просто новый, довольно капризный тип интерфейса к данным, у которого очень узкая ниша применения. Спасибо за конструктивную критику, она помогает правильно расставить акценты в итогах исследования.
Я действительно ставил перед собой дерзкую цель — проверить, сможет ли ИИ стать альтернативой написанию отчетов и в перспективе заменить часть рутинной работы программиста. Но эта идея провалилась.
В начале статьи я специально обозначил ожидания как "наивные". Целью исследования было не создать замену СКД (системе компоновки данных), а проверить: может ли ИИ вообще ориентироваться в структуре OData "с чистого листа".
Признаю, что момент с SELECT я упустил. Скриншот ИТС с инструкцией по EXPLAIN ANALYZE SELECT подтверждает, что для задач отладки вендор такое чтение прямо рекомендует. Вопрос с SELECT закрыт, аргумент принимается.
Что касается границ применимости стороннего софта для маскирования - запрос в отдел лицензирования «1С» (lic@1c.ru) отправлен сегодня в исходном виде. Ответ опубликую здесь.
Спасибо за фидбек! Отдельную статью писать не планирую — у меня нет цели устраивать масштабные дискуссии, хочется лишь зафиксировать этот нюанс для практики.
По поводу “смены позиции”: я не переобувался. Интерактивный SELECT пользователя через pgAdmin или другие инструменты в обход платформы по-прежнему остается для меня нарушением Лицензионного соглашения, и ссылок на ИТС, разрешающих это, я пока не видел. Если таковые имеются, я буду искренне рад с ними ознакомиться.
Разница лишь в том, что статья ИТС, которую вы выше привели, разрешает выгрузку сырых таблиц (в том числе частичную) через pg_dump -t как легитимное исключение для регламентных работ. Но разрешает ли EULA использовать сторонний софт, который в процессе этой выгрузки на лету модифицирует и маскирует данные функциями СУБД - это третья, пограничная сущность. Именно этот момент я и вынес в запрос, чтобы убрать двоякие трактовки.
Инструмент у вас получился действительно очень полезный и нужный для сообщества, спасибо вам за него. Как и писал выше, соберу замечания до четверга, после чего отправлю этот нейтральный запрос в lic@1c.ru. Полученным ответом вендора обязательно поделюсь здесь.
Коллеги, чтобы не заниматься взаимной трактовкой правил лицензирования Фирмы "1С" и не спорить о границах применимости статьи ИТС, предлагаю цивилизованно получить официальный ответ первоисточника.
Я подготовил текст официального запроса в отдел лицензирования «1С» (
lic@1c.ru). Прошу вас взглянуть на него. Если формулировка технически точна и корректно описывает суть нашего обсуждения, я отправлю её вендору, а результатом поделюсь здесь. Если нужно что-то поправить, чтобы запрос оставался абсолютно объективным — пишите.Текст запроса:
Здравствуйте!
Прошу дать официальное разъяснение отдела лицензирования Фирмы «1С» относительно границ использования средств СУБД в контексте Лицензионного соглашения с пользователем «1С:Предприятия 8».
В официальном FAQ по лицензированию Фирмы «1С» (вопрос № Х. 6-65) указано:
«...внесистемные средства СУБД можно использовать только в том случае, если документация по продуктам линейки 1С:Предприятие (включая ИТС) содержит явную рекомендацию использовать данное средство для решения данной задачи».
Методические материалы портала 1С:ИТС в статье «Методика расследования проблем производительности на уровне работы СУБД PostgreSQL» https://its.1c.ru/db/metod8dev#content:6011:hdoc допускают и рекомендуют использование штатных средств выборочной выгрузки таблиц СУБД (
pg_dump -t ...) для передачи разработчикам отдельных таблиц данных (справочников, документов, регистров сведений и накопления) с целью воспроизведения ошибок.Прошу разъяснить — является ли нарушением Лицензионного соглашения применение в процессе выгрузки сторонних SQL-функций, расширений или скриптов СУБД для модификации и маскирования (обезличивания) содержащихся в таблицах данных "1С" (справочниках, документах, регистрах) персональных и коммерческих сведений?
Коллеги, чтобы не затягивать процесс, предлагаю собрать ваши конструктивные правки и замечания к тексту до четверга включительно. Если критических уточнений к формулировкам не поступит, отправляю запрос в Фирму "1С" в текущем виде. По получении официального ответа — сразу опубликую его здесь.
Бэкап средствами СУБД не является нарушением.
Выдержка из faq: "Это означает, что средства СУБД (или любые другие внесистемные средства) можно использовать только в том случае, если документация по продуктам линейки «1С:Предприятие» (включая 1С: ИТС) содержит явную рекомендацию использовать данное средство для решения данной задачи".
Выдержка из ИТС: "В случае клиент-серверного варианта для создания резервных копий рекомендуется использовать средства СУБД. Более подробно см. в книге «1С:Предприятие 8.3. Клиент-серверный вариант. Руководство администратора»."
Ни в коем случае не хотел задеть чьи-то чувства, инструмент действительно отличный! Но в официальном FAQ по лицензированию «1С» четко прописан запрет на любое прямое взаимодействие с таблицами, включая чтение через pgAdmin. По правилам вендора, любая работа с данными в обход сервера приложений считается нарушением, так как это обходит логику лицензирования платформы. И вы немного слукавили в pg_anon не только селект.
Полезный инструмент, спасибо за статью! Хотелось бы добавить небольшое предостережение: не забывайте про лицензионное соглашение «1С». Прямое взаимодействие с СУБД (даже на уровне чтения) нарушает правила лицензирования - подробнее об этом можно почитать в официальном FAQ 1С, вопрос № X. 6-65
То есть теперь, помимо ада зависимостей, нужно следить за адом лицензий?
Спасибо за наводку. Пробовал использовать pg_stat_statements, но в итоге вернулся к логам и pgbadger.
Мне в работе оказалась полезна ретроспектива: например, если 1 января вышло обновление с багом, в агрегированной статистике pg_stat_statements я увижу только "среднюю температуру" за всё время. Логи же позволяют "отмотать пленку" назад и сравнить производительность по конкретным дням или неделям. Так же парсинг логов через pgbadger можно вынести на отдельный сервер.
Возможно, я просто еще не до конца раскрыл для себя потенциал pg_stat_statements, но для еженедельного аудита формат pgbadger мне показался нагляднее.
Спасибо за поправку! Ошибся в этом моменте — про кольцевой буфер и Buffer Access Strategy не знал, изучу.
Мой фокус в этом кейсе был больше на методике регулярной проверки: как через pgbadger и системный анализ планов находить и устранять узкие места в СУБД
Рад, что статья нашла отклик, спасибо!
На самом деле получилось собрать рабочую техническую связку, которая стабильно (без галлюцинаций) вытаскивает атомарные данные по запросу на естественном языке.
Под "готовностью к Enterprise" я, пожалуй, поспешно подразумевал лишь инфраструктурную часть: стек Java/Spring AI, работу в закрытом контуре и безопасность данных. С точки зрения бизнеса — это пока лишь умная поисковая строка.
Статья — это в первую очередь история моего пути от наивного "сейчас заменю всех" до понимания, что ИИ — это просто новый, довольно капризный тип интерфейса к данным, у которого очень узкая ниша применения. Спасибо за конструктивную критику, она помогает правильно расставить акценты в итогах исследования.
Я действительно ставил перед собой дерзкую цель — проверить, сможет ли ИИ стать альтернативой написанию отчетов и в перспективе заменить часть рутинной работы программиста. Но эта идея провалилась.
В начале статьи я специально обозначил ожидания как "наивные". Целью исследования было не создать замену СКД (системе компоновки данных), а проверить: может ли ИИ вообще ориентироваться в структуре OData "с чистого листа".