В статье рассматриваем что такое хранилище данных, основы их разработки: архитектура, основные слои данных и подходы для работы с ними, ETL и ELT, а также основные модели данных. Материал поможет начинающим разработчикам понять принципы построения аналитических систем и роль разработчика DWH.
Для обычного пользователя разрешать уходить в минус по балансу - не может позволить себе ни одна организация, как говорилось в одном известном фильме - утром деньги, вечером стулья. Но для больших корпораций остановка платежей даже на секунду - это уже не проблема корпорации, а всего государства. Невозможно приостановить работу концерна (например Росатом) только потому, что в данный момент у него нет средств. На перезапуск может уйти куда как больше ресурсов.
Поэтому пора исправлять эту проблему в MireaPay и наконец-то добавить работу с крупными юр. лицами, которые будут называться корпоративными пользователями!
Это текстовая версия доклада с Java Rock Star Meetup, с которым выступал Дмитрий Фатов (@FatOFF ) — руководитель разработки Газпромбанка с опытом разработки приложений более 13 лет. Дмитрий работал как backend-, так и fullstack-разработчиком на языках Java, Kotlin, JS, TS, 1С и имеет большой опыт работы с SQL-базами данных.
Привет, Хабр! Я Владимир, архитектор департамента больших данных в РСХБ. В команде РСХБ.Цифра руковожу проектом по внедрению решения для CDC-репликации данных на базе отечественного программного продукта Датафлот Репликация. Наступила эпоха импортозамещения, и в последние годы большинство компаний столкнулось с необходимостью отказаться от привычных классических инструментов и архитектурных решений. Для нас, Россельхозбанка, 100% которого принадлежат государству, по очевидным причинам проблема импортозамещения особенно актуальна.
Нашей целью было обеспечить бесшовное переключение систем с замещаемых СУБД, миграция их данных, замена cdc-инструментов поставки данных в ХД в рамках задачи импортозамещения иностранного ПО в банке. В этой статье расскажу про наш подход к этому вопросу с практической точки зрения. Про и контра — с точки зрения не маркетинговых фраз, а сугубо практического «вам шашечки или ехать?». Возможно, не все согласятся с приведёнными критериями и аргументами, что повлечёт холивары в комментах, но… тем лучше. Будет больше осознанности при выборе правильного решения.
WAL — один из ключевых компонентов внутреннего устройства Postgres. Файлы WAL для истории бэкапов ужимаются в несколько раз, что говорит об избыточности. Изменяя физические параметры кластера, можно существенно повысить и эффективность локальной записи, и пропускную способность репликации, а можно создать неприятные инциденты.
Привет, Хабр! Я — Андрей Бородин, работаю над Postgres и Apache Cloudberry для Yandex Cloud и вообще. Поддерживаю WAL-G, SPQR, Odyssey и всякое такое. В этой статье на основе доклада для конференции Saint HighLoad++ я расскажу о причинах избыточности, о действиях сообщества, а также о своей работе в рамках подсистемы WAL. Понимание работы WAL поможет вам проектировать ваши сервисы с учетом специфики этой подсистемы.
10 марта Google выкатил Gemini Embedding 2 - embedding-модель, которая умеет превращать в векторы не только текст, но и картинки, видео, аудио и PDF. Причем все это ложится в одно векторное пространство. Раньше если вы хотели искать по видеобиблиотеке через RAG, приходилось городить огород: транскрибировать аудиодорожку, описывать кадры через Vision LLM, склеивать в текст, и только потом эмбеддить. Каждый шаг - потеря информации. Теперь можно скормить модели MP4 напрямую, и текстовый запрос «как настроить авторизацию» найдёт и статью из базы знаний, и фрагмент видеоинструкции.
Но сама по себе модель не решает проблему. LLM не может «прочитать» MP4, поэтому найденное видео без текстового описания - может быть бесполезно. Ключ - в правильной архитектуре: нативный эмбеддинг для поиска + параллельная генерация текстового описания для LLM: два канала, которые работают вместе и выводят мощь RAG наполную катушку.
В этой статье разберем что нового в Gemini Embedding 2 и построим полноценный мультимодальный RAG с нуля - Python, Supabase, Gemini API.
P.S. С кодом.
Есть один миф про ClickHouse - он плохо джойнит. Подавляющее большинство не знает, с чем это утверждение связано, и просто верят на слово. А дальше срабатывает эффект сарафанного радио. В итоге в IT-сообществе есть твердое убеждение, что ClickHouse плохо джойнит. Но для меня апогеем стала статья от школы обучения программированию, в которой написано, что ClickHouse вообще не умеет джойнить:
Российский бизнес переживает эпоху «Великого перехода». Санкционное давление и уход западных вендоров заставили компании в спешке мигрировать на отечественное ПО. Но гонка за новыми платформами обнажила старую как мир проблему: наши системы полны «мусора».
На многочисленных проектах по миграции с SAP и западных CRM на российские решения наблюдается одна и та же картина: бизнес ждет «магии» от новой системы, а получает перенос хаоса. Аналитики и ИТ-специалисты приходят к выводу: битва за качество данных проигрывается не из-за отсутствия талантливых разработчиков, а потому что бизнес-анализ как дисциплина в России до сих пор не воспринимает данные как стратегический актив.
В этом цикле будут разобраны три фатальные ловушки, в которые попадают компании, и главное — предложены пошаговые рецепты спасения, основанные на реальной практике и современных методологиях.
Почему SUM() OVER (ORDER BY ...) иногда даёт неожиданный результат, даже когда запрос синтаксически правильный? В статье на практических примерах разбираю, как работают оконные фреймы в SQL, чем отличаются ROWS, RANGE и GROUPS, где чаще всего возникает путаница и как писать накопительные итоги и скользящие метрики без сюрпризов. Если используете оконные функции в аналитике, этот разбор поможет сделать их поведение предсказуемым и управляемым.
Всем привет! Я Игорь Эльяс — бэкенд-разработчик, сейчас работаю в МТС Веб Сервисы. Однажды мне досталась задача «перенести приложение в другую БД, за XX времени», где ХХ — короткий интервал с точки зрения потенциального объема работ при подходе «переделываем все по-нормальному — на Entity Framework» :-)
Проект на C#, изначальная БД — MS SQL + мы использовали самодельный ORM. Возможно, вы сейчас подумали — «очередное легаси!». И да и нет. Проект родился еще во времена Framework 2.0, но регулярно обновлялся и сейчас работает на .NET8. Он пережил десятки циклов рефакторинга, поэтому не безнадежен для доработок.
В материале расскажу, что мы в итоге решили со всем этим делать, почему и для чего выбрали именно Dapper, а еще — познакомлю вас с мощным, но малоизвестным инструментом Dynamitey, благодаря которому удалось выполнить все в срок и без лишний приключений.
Привет, Хабр! Меня зовут Кирилл Абрамов, я backend-инженер в сервисе Автотека Авито. В этой статье я расскажу, как остановил постоянное увеличение объёма базы данных PostgreSQL и что надо делать, если времени на остановку не остаётся.
Привет, Хабр! Меня зовут Александр Зевайкин, и мы с командой делаем YDB (СУБД Яндекса). В конце прошлого года Яндекс представил специализированного ИИ‑помощника — Нейроюриста, для которого обучил языковую модель на основе Alice AI LLM. Сервис работает на базе RAG, под капотом у которого находится YDB c миллионами различных юридических документов.
Под катом — история о том, как команда разработки Нейроюриста сделала семейство векторных индексов, чтобы находить нужное количество документов при любых параметрах фильтрации. Я кратко расскажу про архитектуру векторного индекса, покажу, как выбирать правильные настройки, и продемонстрирую бенчмарки получившегося решения.
В исходниках PostgreSQL встречаются ироничные комментарии, а самый веселый, на мой взгляд, находится в строке прямо перед запуском сервера. Судя по логам Git, это комментарий Тома Лейна, который сообщает: "We are ready to rock and roll", а следующей строкой идёт запуск сервера СУБД. Действительно, когда пытаешься запустить кластер PostgreSQL, порой не покидает ощущение "rock and roll", а потом вдруг кластер не стартует или внезапно переключается на другой узел из-за отступов в YAML-конфиге :).
В этой статье разберём ключевые элементы отказоустойчивого кластера и типовые места, где чаще всего допускают ошибки.
Недавно я посвятил время проблеме производительности на продакшене. Приложение работало в горячке — загрузка процессора в среднем превышала 50% и периодически подскакивала до 90%. Мы сделали диагностический снапшот и начали работать с топом запросов по процессорному времени.
Нарушитель номер один? Простой запрос Dapper. Незамысловатое условие WHERE по проиндексированному столбцу. Должно было быть молниеносным, но в среднем потребляло тысячи миллисекунд процессора при сотнях тысяч выполнений в день.
Несоответствие типов на пару символов, совсем невидимое в C#‑коде. Я очень долго глазел на запрос, прежде чем понял происходящее.
В PostgreSQL есть фича, про которую знают далеко не все, хотя она существует с незапамятных времён. Advisory locks — пользовательские блокировки, которыми управляет не БД, а ваше приложение. PostgreSQL только хранит их состояние и разруливает конкуренцию. А вы решаете, что именно заблокировать и когда отпустить.
Зачем это нужно? Вы строите распределённую систему, несколько инстансов приложения работают с одной базой, и вам нужно гарантировать, что определённую операцию выполняет только один инстанс одновременно. Классический ответ — Redis с SETNX или Consul/ZooKeeper. Но если у вас уже есть PostgreSQL — зачем тащить ещё одну зависимость?
Привет, Хабр!
Меня зовут Андрей Жуйков, и в этой статье я хочу рассказать вам историю абсолютно практического содержания. Без теоретических рассуждений и без лозунгов про импортозамещение. Это реальный кейс о том, как мы перевели несколько наших корпоративных 1С с Microsoft SQL Server на Digital Q.DataBase.
Obsidian давно перестал быть просто «заметочником» — для многих это полноценная рабочая среда, где живут задачи, проекты, люди и знания. Но как только дело доходит до структурированных данных — книг, контактов, курсов — пользователи неизбежно упираются в вопрос: чем это организовать? Долгое время единственным вменяемым ответом был плагин DB Folder. Затем Obsidian выкатил встроенный Bases — и сообщество разделилось. В этой статье я разберу оба инструмента на конкретном примере: создам базу данных книг в каждом из них, сравню возможности и расскажу, какой из них и для кого подойдёт лучше. Если тема управления знаниями в Obsidian вам близка — заглядывайте в мой тг-канал, там я разбираю подобные вещи регулярно.
Привет, Хабр! Меня зовут Виктория Мохирева, я консультант SAP MM. Сегодня расскажу о том, как мы с командой решили колоссальную задачу инвентаризации — пересортицу товаров — с помощью интеграции SAP с большой языковой моделью (ИИ).
Вот как бывает в обыденности магазина: пришёл товар, на учете кружка, а на полке по факту тарелка. Начинается танец с бубном из таблиц, сверка номенклатур и постоянные акты. Чтобы автоматизировать подбор правильных групп для пересортицы, мы написали инструмент, который позволяет общаться с ИИ напрямую из SAP GUI. Решение получилось достаточно компактным и элегантным. А под капотом у нас — архитектура, ключевые куски кода и логика, которые помогли нам превратить «регулярный ручной труд» в интеллектуальный диалог с машиной, и теперь у нас не разрозненная масса товаров, а сформированные по определенным параметрам логичные группы.
После первой статьи в комментариях несколько раз прозвучало примерно одно и то же:
"Всё правильно, но это же про любую зрелую СУБД — что с этим делать?"
Я думал над этим вопросом несколько недель. И в итоге решил не искать ответ в виде
"возьмите правильный инструмент X" — а попробовать честно сформулировать:
какими свойствами OLTP-БД должна обладать сама по себе, независимо от того,
насколько хорош ваш оператор, консультант или runbook.
Что такое "контракт" — и почему это не маркетинг
Попробую объяснить не через определение, а через ощущение.
Когда вы покупаете автомобиль, вы не читаете инструкцию к тормозам каждое утро.
Вы просто знаете: нажал педаль — машина тормозит. Это контракт. Он не зависит от того,
правильно ли вы настроили тормозную жидкость этим утром или не забыли включить
"режим торможения" в меню.
Спроси любого уважаемого аналитика или инженера данных о том, какие бывают способы моделирования данных, тебе ответят: звезда, 3NF и DataVault. Спроси ИИ, получишь примерно такой же ответ. Придешь на какой-нибудь проект в компанию, также скорее всего встретишь там кого-нибудь из этих друзей. В 90% материалах про методологии моделирования освещаются только эти трое. Как будто других методологий не существует.
Да, эта троица, наверное, самая популярная и подходящая под большую часть задач, но в мире есть еще уйма других не менее интересных способов как организовать свои данные. И сегодня мы постараемся целиком их рассмотреть.
