1С:Предприятие 8
Відкрити в Telegram
Канал обо всем, что связано с 1С. Для обратной связи @shalimski
Показати більше📈 Аналітичний огляд Telegram-каналу 1С:Предприятие 8
Канал 1С:Предприятие 8 (@onecv8) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 12 540 підписників, посідаючи 10 051 місце в категорії Технології та додатки та 51 559 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 12 540 підписників.
За останніми даними від 27 жовтня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 27, а за останні 24 години на 2, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 29.22%. Протягом перших 24 годин після публікації контент зазвичай збирає 12.56% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 3 663 переглядів. Протягом першої доби публікація в середньому набирає 1 575 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 9.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як гайдбук, данными, затрата, облаке, секция.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Канал обо всем, что связано с 1С. Для обратной связи @shalimski”
Завдяки високій частоті оновлень (останні дані отримано 28 жовтня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
12 540
Підписники
+224 години
+37 днів
+2730 днів
Архів дописів
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/
