1С:Предприятие 8
Open in Telegram
Канал обо всем, что связано с 1С. Для обратной связи @shalimski
Show more📈 Analytical overview of Telegram channel 1С:Предприятие 8
Channel 1С:Предприятие 8 (@onecv8) in the Russian language segment is an active participant. Currently, the community unites 12 540 subscribers, ranking 10 051 in the Technologies & Applications category and 51 559 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 12 540 subscribers.
According to the latest data from 27 October, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 27 over the last 30 days and by 2 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 29.22%. Within the first 24 hours after publication, content typically collects 12.56% reactions from the total number of subscribers.
- Post reach: On average, each post receives 3 663 views. Within the first day, a publication typically gains 1 575 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 9.
- Thematic interests: Content is focused on key topics such as гайдбук, данными, затрата, облаке, секция.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Канал обо всем, что связано с 1С. Для обратной связи @shalimski”
Thanks to the high frequency of updates (latest data received on 28 October, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
12 540
Subscribers
+224 hours
+37 days
+2730 days
Posts Archive
12 540
Как избавиться от гонок при параллельной загрузке данных в 1С без блокировок
При миграции 28 тысяч позиций номенклатуры из SAP в 1С:ERP разработчики столкнулись с классической проблемой конкурентного доступа — дублированием элементов справочников.
В чём проблема?
Несколько фоновых заданий одновременно проверяли существование элемента. Не находили его и создавали каждый свою копию.
Попытки решить проблему блокировками дали неожиданные результаты:
• Исключительные блокировки — дублей нет, но 85% сообщений завершаются ошибкой из-за таймаутов.
• Разделяемые блокировки — ошибок меньше (20%), но появляются дубли. В результате около 250 лишних элементов.
• Детерминированный GUID — практически без ошибок блокировок и без дублей.
Как решили?
Вместо случайного идентификатора стали вычислять GUID из MD5-хеша типа сущности и нормализованного бизнес-ключа.
Теперь два параллельных процесса пытаются создать элемент с одинаковым первичным ключом. Один успешно записывает данные, второй получает конфликт уникальности и повторяет обработку сообщения.
Что интересно с архитектурной точки зрения:
1. Уникальность обеспечивает сама СУБД, а не распределённая блокировка.
2. Конфликт записи становится штатным сценарием, который обрабатывается через retry.
3. Повтор выполняется на уровне всей транзакции, а не отдельной операции.
4. Идемпотентность позволяет безопасно обрабатывать сообщения повторно.
Результат: все 28 тысяч позиций загружены без дублей, параллельная обработка перестала упираться в общие блокировки.
В статье также разобраны ограничения подхода: переименование сущностей, коллизии нормализации и работа с ранее созданными элементами.
Хороший практический пример того, как детерминированные идентификаторы и ограничения уникальности помогают заменить сложную координацию конкурентных процессов.
📖 Читать статью на Хабре
12 540
Отчёт в 1С завис? Возможно, дело вообще не в запросах.
Отличная статья с практическими кейсами диагностики 1С. Вместо гадания и перебора гипотез — конкретные инструменты и реальные причины проблем.
Что внутри:
948 → 66 секунд. Через rac и технологический журнал нашли SQL-запрос на 240 секунд и конкретную строку кода. Переписали проблемный отчёт.
365 секунд в одной временной таблице. Из 15 шагов пакета 14 выполнялись суммарно за 0,76 секунды. Замер каждого шага помог найти узкое место.
50 минут ложного зависания. Сервер простаивал, а клиент ожидал закрытия невидимого модального окна с ошибкой.
Зомби-вызовы. Пользователь закрыл отчёт, но SQL продолжил выполняться на сервере. Повторный запуск только увеличил нагрузку.
Зависшее фоновое задание. Открытая транзакция удерживалась более двух суток и мешала обновлению конфигурации.
Задание «выполнено», но данные не обновляются. Неправильное расписание, ошибка формирования SQL и перехваченное исключение скрывали проблему.
Готовая методика расследования: как с помощью rac, DBMSSQL, SDBL и журнала регистрации быстро сузить круг причин, не тратя часы на изучение непричастного кода.
Хороший материал, который стоит сохранить как шпаргалку для разбора инцидентов в 1С.
12 540
Сжатие PostgreSQL: меньше данных ≠ выше производительность
Обычно эффективность сжатия оценивают по размеру базы. Но экономия диска не гарантирует ускорения запросов.
Авторы статьи исследовали компрессию страниц в Tantor Postgres на базах 1С.
Что выяснили:
• ZSTD лучше сжимает, но требует больше CPU.
• LZ4 обеспечивает лучший баланс скорости и сжатия.
• На большой таблице объём сократился с 95 до 12 ГБ. LZ4 ускорил холодное чтение почти втрое.
• На небольших таблицах распаковка может стоить дороже сэкономленного I/O.
• Сжатие страниц переменного размера усложняет запись и может приводить к фрагментации.
Архитектурный вывод
Оптимизировать нужно не коэффициент сжатия, а стоимость работы с данными: CPU, I/O, write/read amplification.
Максимальное сжатие ≠ максимальная производительность.
Отдельно интересно решение CSM в Tantor Postgres: сохранять фиксированную адресацию страниц, уменьшая их физический размер. Это компромисс между экономией диска и стоимостью операций чтения и записи.
Читать исследование →
12 540
Как не отправлять ПДн во внешнюю LLM
Практический кейс маскирования персональных данных в пользовательском тексте.
Схема:
regex + справочники → локальная LLM → токенизация → внешняя LLM
Телефоны, email, паспорта и известных людей ловят детерминированно. Склонения, прозвища и живую речь — локальной моделью.
Архитектурный паттерн: deterministic preprocessing → local intelligence → external LLM.
Подходит для любого AI-gateway, где чувствительные данные нельзя отправлять наружу.
12 540
https://youtu.be/2MCcLSZP5Y4?si=lLvijUHKopVdbD4o
Говорим о зарплатах Junior, Middle и Senior 1С, переходе из бухгалтерии в разработку, сертификатах 1С, высшем образовании и софт-скиллах. Разбираем автоотклики на hh.ru, сопроводительные письма, технические собеседования, использование ИИ и работу в нескольких компаниях. Отдельно спорим о накрутке опыта: где проходит граница между реальными знаниями и годами в резюме.
Смотри, если ищешь первую работу в 1С, готовишься к смене компании или хочешь понять, что мешает росту дохода. Зарплатные цифры и оценки рынка в беседе — опыт и мнения участников, а не гарантированные условия трудоустройства.
12 540
Работу техподдержки 1С обычно редко обсуждают, пока все работает в штатном режиме. Но когда случается сбой и выясняется, что время реакции на инцидент слишком большое, возникает ощущение, что проверить это стоило заранее.
К счастью, теперь такую проверку можно провести структурно. K2 Cloud и АСТОН подготовили калькулятор технической поддержки 1С. Ответьте на 10 вопросов о ваших сервисах, процессах и требованиях к доступности.
По итогам калькулятор покажет, какой уровень поддержки вам подходит, оценит ее зрелость и даст чек-листы для перехода на новый уровень.
Проверить>>
12 540
Как 1С на самом деле работает с временными таблицами в PostgreSQL — и почему безобидный FASTTRUNCATE может съедать заметную долю CPU.
Разбор внутренней механики, переиспользования временных таблиц и реального кейса оптимизации PostgreSQL под 1С.
https://habr.com/ru/companies/tantor/articles/1078088/
