Базы данных *

Я провел небольшое исследование и выявил основные проблемы основные проблемы с которыми сталкиваются Джуны (новички) в 1С.

Основные проблемы джунов (новичков) в 1С.

Технические сложности

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

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

Также распространены ошибки формата потока, недостаточности памяти и проблемы с доступом к системе.

Концептуальные трудности

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

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

Рассмотрим на примере:

Конструкция типа “Пока Выборка.Следующий() Цикл А = Выборка.Ссылка.Договор;” создает неявные запросы в каждой итерации цикла.

Бизнес-процессы и контекст

Я не верю, конечно, ни в какую демократию (кроме оригинальной афинской 2½ тысячи лет назад, где кворум состоял из трёх с половиной образованных богатых неглупых людей, а остальные были безголосыми рабами и женщинами). Как я уже где-то говорил, существуют исторические свидетельства того, к чему привели первые проявления этой самой демократии: пару тысяч лет назад люди проголосовали распять одного там назаретянина.

Поэтому когда в качестве аргумента за ту, или иную парадигму, — я вижу какие-то индексы, голосования и прочую статистически значимую оценку vox populi, меня это раздражает. «Миллионы мух не могут ошибаться» — так себе аргумент. Поэтому мнение «коммьюнити разработчиков» — практически всегда облыжное, поверхностное, и, в целом, неверное. У каждого в руках свой молоток, а про многообразие саморезов люди en masse если и слышали, то краем уха и в качестве анекдота.

Если экстраполировать мнение большинства и принять его за аксиому, то в мире будут существовать только банковские приложения и круды с базами данных в качестве узкого места и дополнительными серверами вместо корректного горизонтального масштабирования. Тем не менее, многие даже в своей работе используют инструменты, которым никакая база не требуется, а обеспечение роста гарантируется размазыванием нагрузки по кластеру, а не приклеенными (sticky) сессиями. И я говорю не про десктоп.

Выкатили новый проект. База — на PostgreSQL. Все работает. DBA в штате нет, база крутится на виртуалке, обновления никто не трогал, мониторинга нет. И вот ночь, все падает. Начинается экстренный чат, поиск багов, попытки восстановиться из бэкапа… если он вообще был.

Так случается, когда инфраструктура и сопровождение баз данных остаются на совести команды разработки. Чтобы избежать этого, все чаще используются управляемые СУБД в облаке — сервисы, где ключевые задачи закрываются автоматически или силами провайдера.

На связи продуктовая команда РТК-ЦОД, и в этой статье мы расскажем, как устроены облачные базы и зачем они бизнесу.

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

Всем привет! На связи снова Илья Криволапов — системный аналитик в SENSE, где мы трудимся на проекте одного из цветных банков РФ. Работаю в профессии уже пятый год и, несмотря на мою фамилию, с продом у нас в целом тёплые отношения. 

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

Цикл состоит из 3 частей. В первой мы обсудили два базовых подхода к масштабированию БД: вертикальный и горизонтальный. Поговорили о плюсах, минусах и о том, как делать точно не стоит. 

Во второй части – то есть сейчас – мы нырнём глубже в мир горизонтального масштабирования и разберем три первых способа шардирования: по диапазону, по хэшу и по географическим зонам. Я расскажу, как каждый из них работает, где пригодится и в каких случаях может дать сбой.

Материал по-прежнему будет полезен всем, кто заботится о «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.

Готовы продолжать? Тогда поехали!

Привет, Хабр! Меня зовут Никита, я руководитель команды разработки умного поиска на основе генеративного AI в Just AI. В этой статье я расскажу о нашем опыте в умный поиск — как от mvp RAG-сервиса для Q&A бота нашей службы поддержки мы пришли к облачной платформе Jay Knowledge Hub (сокращенно KHUB), которая помогает нашим клиентам автоматизировать поиск по различным источникам знаний.

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

Привет, Хабр! Меня зовут Роман Аминов, я руковожу группой автоматизации бизнес-сценариев в команде СУБД Pangolin в СберТехе. Это специальная доработанная сборка PostgreSQL, целевая СУБД в Сбере и не только. СУБД — сложный продукт, обновление, настройка и другие рутинные действия, связанные с её сопровождением, сопряжены с риском потери данных. Чтобы облегчить жизнь пользователям (и вдобавок разгрузить нашу техподдержку) мы разработали инструмент для автоматизации кластеров СУБД, их настройки и конфигурирования, обновления версий компонентов в их составе и обслуживание. Решение уже прошло проверку на тысячах кластеров в Сбере и я готов поделиться тем, как всё это работает.

Уточню, что мы используем систему управления конфигурациями Ansible. Всё, что нужно для её работы — это возможность устанавливать SSH-соединения и Python на удалённых серверах.

Надеюсь, статья будет полезна или натолкнёт на свои мысли автоматизаторов и администраторов СУБД и вообще всех, кто связан с базами данных. 

Всем привет! Меня зовут Костя, и в этой статье я продолжу рассказ моей коллеги Анастасии из команды доступности Magnit Tech о том, как можно искать проблемные товары на полках магазинов, опираясь лишь на данные по дневным продажам и остаткам товара в магазине.

В этой статье я расскажу о другом, альтернативном алгоритме, который детектирует ощутимую долю проблемных позиций наравне с тем, о котором рассказывала моя коллега. Этот алгоритм также прост для понимания и интерпретации бизнесом. Его внедрение и эксплуатация требуют минимальных затрат: вычислительные ресурсы, сопровождение и адаптация под разные форматы магазинов обходятся недорого. Кроме того, он может служить эффективным первым шагом перед внедрением более сложных и ресурсоемких ML-алгоритмов. В отличие от нейросетевых подходов к поиску аномалий, которые требуют тщательной настройки (или даже разработки) оптимальной архитектуры сети, настроить этот алгоритм значительно проще.

Я ненавижу руками создавать бойлерплейты. Любые. Нет, LLM-ки тут тоже не помогут: им надо писать промпты (а потом ещё проверять, что оно там нагенерировало). Мне всегда хотелось, чтобы остов приложения задавался конфигурацией, а я бы только добавлял бизнес-логику. Буквально, в уже сгенерированные для неё места.

Именно в такой парадигме написана моя библиотека finitomata, в которой конфигурация конечных автоматов задаётся текстовым представлением (PlantUML/Mermaid), а бизнес-логика просто распихивается по колбэкам переходов. Но мне этого оказалось мало, и я решил обернуть в такие же абстракции хранение и подписку на изменения.

Так родилась библиотека (пока не опубликована, доступна только в исходниках) persistomata.

Это было очень давно, году примерно в 1997. Однажды мне очень ярко приснился и хорошо запомнился следующий сон: как будто мы купили новый телевизор и видеомагнитофон. И несколько видеокассет.

Во сне это был не просто символ богатства, в то время такое событие стало бы целым культурным взрывом в рамках конкретно взятой семьи и конкретно взятого дома. Это были 90-е годы, зарубежная культура лилась на нас водопадом. Быть на передовой прогресса означало смотреть все новые фильмы на видео у себя в гостиной.

У моего друга детства Сашки был дома новый телевизор и видак, у моего друга детства Вовки дома был импортный телевизор и видак, у моего хорошего знакомого Димки был новый телевизор и видак. А у нас был старый советский черно-белый телевизор, который ловил две программы, в то время как всё самое интересное показывали по третьей. По финансовой причине то, что я увидел во сне, было для нас в то время недостижимой мечтой.

Мы ходили смотреть фильмы в основном к Сашке. Его старший брат где-то доставал кассеты с новинками, и всю классику 90-х я пересмотрел в первый раз именно у него дома. Зачастую в компании нас было 5 человек на сеансе просмотра какого-нибудь «От заката до рассвета» или «Смертельной битвы».

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

Прошло 27 лет. У меня появился дом в деревне с русской печкой, и в декабре 2024 года я создал коллекцию фильмов в высоком качестве. Только тогда всё сложилось, как во сне.

Лучше чем во сне.

В статье разберемся, что такое векторный поиск, какие проблемы он решает, и как расширение pgpro_vector для Postgres Pro позволяет реализовать эти мощные возможности прямо в реляционной базе данных, без необходимости развертывать отдельные специализированные системы.

Я отчётливо помню, как сидел на втором курсе на лабах по БД и долго и мучительно методом научного тыка подбирал порядок слов в SELECT-запросе с GROUP BY, чтобы он вернул нужный мне преподу результат. Потому что я не понимал, как работает SELECT, хотя был прилежным (на программистских курсах) студентом, ходил на все лекции и делал лабы за себя и пару "тех парней".

Двадцать лет спустя, когда я встал по ту сторону баррикад и начал сам вести лабы по БД, я столкнулся с той же самой проблемой уже у своих студентов. И, так как за двадцать лет я всё-таки понял, как работает SELECT, то придумал для них способ объяснения, который работает хорошо (в моей практике).

Ранее в блоге beeline cloud мы рассказывали об открытых СУБД для систем ИИ. Продолжим тему и рассмотрим еще несколько находок в этой области — разносторонние инструменты, упрощающие работу с эмбеддингами, семантическим поиском и RAG.

Не знаешь что такое ER-модель? До сих пор не умеешь строить ER-диаграмму? Собери всю свою волю в кулак и разберись наконец:

— Зачем наделять данные смыслом;
— Как и для чего иметь связи;
— Сильная или слабая ты сущность;
— Когда тебе может понадобится инфологическая и даталогическая модель.

Привет, хабр! В данной статье хочу рассказать больше чем обычно про оптимизацию запросов к базе данных в Django. Расскажу о том, как не только запрашивать, но и создавать или обновлять записи в базе. В статье будет много примеров, генерируемый SQL, типы данных, индексы и выводы планировщика запросов.

Данная статья подходит как для начинающих, так и для достаточно опытных разработчиков на django, а также для всех, кто еще не интересовался, что происходит под капотом ORM.

Эксперт Postgres Professional Андрей Зубков «нырнул» в глубины VACUUM и выяснил, что детализированная статистика может выявить глубинные проблемы, которые критически влияют на производительность. Расскажем о том, что скрывалось в глубине PostgreSQL

Мне всегда было интересно, как управляются разные бизнесы: как работает завод, ритейл, другие сферы. Я пытался изнутри наблюдать за бизнесом, где создаётся конечная ценность. Где-то работает автократия, в других компаниях уже есть зрелая бюрократия, а где-то все договариваются на словах, но нигде это не прописано.

Я видел, что даже в среднем бизнесе решения принимаются на основании чуйки хозяина. Тогда как в entreprise решения принимаются на основании процедур, отчётов. Люди страдают и ненавидят этот процесс, так как много времени уходит на оцифровку. Но при этом корпорации довольно эффективны, что показал мой дальнейший опыт. Они работают на 4-ку, но стабильно. Малый бизнес может сегодня сработать на 5, а завтра на 2.

Так у меня появилось убеждение, что в своих решениях нужно опираться на данные. Большой компанией можно стать только та, где есть система принятия решений. 

Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. В этой статье рассмотрим, как большое количество мелких файлов влияет на производительность различных систем хранения, таких как HDFS и объектные хранилища с S3 API.

Разберём, какие технологии хранения лучше всего подходят для работы с мелкими файлами в архитектурах Data Lake и Lakehouse. Сравним производительность HDFS и объектных хранилищ с S3 API. На конкретных тестах покажем, почему именно HDFS эффективнее справляется с большим количеством небольших файлов. Обсудим также случаи, когда мелкие файлы становятся не просто нежелательной ситуацией, а неизбежной необходимостью, например в подходах типа Change Data Capture (CDC).