Базы данных *

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

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

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

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

Финальный рывок – поехали!

Привет, Хабр! Меня зовут Дима Пичугин, и уже семь лет я занимаюсь различными компонентами T Data Platform. Эта статья — результат внутреннего аудита наших инструментов, но я подумал, что она может быть интересна не только нашим аудиторам, но и более широкой аудитории. Enjoy!

Платформа данных в Т-Банке существует более 18 лет и за это время прошла значительный путь эволюции. Она помогает более чем 17 тысячам пользователей извлекать из данных ценную информацию для бизнеса. За последние годы подходы к работе с данными заметно изменились: индустрия постепенно отходила от классических концепций хранилищ данных по Инмону и Кимбеллу в сторону Data Lake, а затем — Lakehouse-архитектур. Вместе с отраслью менялась и наша платформа.

В статье расскажу, как трансформировалась T Data Platform за 18 лет развития, и опишу ее текущее устройство — без погружения в технические детали, но с акцентом на общую архитектуру. Для тех, кому интересны отдельные инструменты или решения, оставлю ссылки на подробные материалы и выступления.

Добрый день! Меня зовут Воронин Николай, я занимаюсь автоматизацией систем отчётности и анализа в ПГК Диджитал.

Моя статья является структурированием личного опыта, полученного в конкретных условиях, он не претендует на статус best‑practice, допускает ситуации, в которых могут существовать более эффективные решения или проблема не стоит в целом.

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

В моём случае речь пойдёт о комплексе нескольких BI систем, существующих параллельно, но сложности вполне могут возникать и в рамках одной, достаточно массивной системы отчётности.

Привет, Хабр! В этом месяце мы запустили акцию с GPU за рубль, предложили кешбэк до 1 000 000 бонусов для стартапов, добавили посуточную аренду видеокарт для ML и не только.  В тексте делимся подробностями, а еще — приглашаем 27 июля на Selectel Day Off.

Попробуем применить многомерный анализ к данным временных рядов с помощью интерактивной визуализации данных измерений и их взаимосвязей.

Третья часть статьи посвященной трудностям миграции с Firebird на PostgreSQL. (1ая часть, 2я часть).

На апрельской конференции PG BootCamp 2025 в Екатеринбурге был представлен доклад Артёма Бугаенко о том, как сделать статистику Postgres более детализированной, не повышая DST. Однако если посмотреть на доклад под немного другим углом, то ему отлично подошло бы название «Пример создания патча для PostgreSQL». Примеры правки логики планировщика есть во многих патчах, но объяснение того, куда и какой код нужно вставлять в многочисленные файлы исходного кода PostgreSQL, встречается нечасто. Можно встретить примеры описания того, как добавить параметры конфигурации, а вот пример того, как добавить опцию в команду SQL, найти подчас затруднительно. Поэтому если вам требуется добавить в какую-либо команду свою опцию, можно использовать статью, доклад и предложенный докладчиком патч как руководство.

Это статья в формате вольного пересказа более чем сорокалетнего периода работы с разными ОС, главным образом с ОС мейнфрейм, и размышлениями об их сходстве и различиях (в большей степени о различиях, конечно).

Многие популярные ОС выполняются на серверах (речь в статье пойдет исключительно про серверные ОС) х86 (Intel, AMD). Это Линукс разных мастей и названий, и Windows. В силу уклона российского образования в сторону инфраструктур на основе х86 у многих айтишников есть твердое убеждение, что то, как написаны известные ОС, это единственный вариант, как ОС и могут быть написаны. Попытки писать свою, российскую, ОС сводятся к написанию очередного Линукса.

Но есть и другие, современные ОС, выполняющиеся не на х86 платформе. Это одна из ОС IBM мейнфрейм (МФ), называемая z/OS. IBM МФ — тоже весьма современная техническая платформа. В апреле этого года IBM анонсировали новое поколение z17, т. е. семнадцатое поколение, начавшее свою историю в далеком 1964 году.

В первой части обсуждалось как отличие реализации MVCC в Firebird и PostgreSQL может привести к сложностям при миграции информационной системы. Напоминаю девиз этой серии статей – "Ваши ожидания – это Ваши проблемы". Рассмотрим еще некоторые моменты, которые позволят Вам не находится в состоянии "обманутых ожиданий" при миграции с Firebird на PostgreSQL.

В этой серии статей я залезу внутрь реляционной базы данных Firebird. Я не буду рисовать архитектуру в виде прямоугольников, соединённых стрелками. Вместо этого я буду показывать куски кода, описывать, что они делают и как вызывают друг друга, чтобы выполнить конкретную работу.

Не секрет, что в последние годы различные компании достаточно часто принимают решение о миграции работающей информационной системы с Firebird на PostgreSQL.

Типичная ситуация выглядит так:

Проект работает несколько лет. Заказчик «верит», что проблема не в проекте, а в СУБД. Firebird — «плохая» СУБД.

Привет, Хабр! На связи Антон Дятлов, инженер по защите информации в Selectel. Хранение конфиденциальных данных в PostgreSQL в открытом виде — мина замедленного действия. Неприятности в будущем становятся неизбежными. Достаточно одной успешной SQL‑инъекции, утечки резервной копии или компрометации доступа к серверу, чтобы вся чувствительная информация — от персональных данных пользователей до API-ключей — оказалась в руках злоумышленников.

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

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

В первой части мы разобрали теорию text‑to‑SQL: как LLM заменяют разработчиков, почему RAG и CoT спасают от галлюцинаций и зачем Scale AI дообучает ChatGPT-4. Но теория неполна без практики! В этом материале — жёсткое тестирование моделей (ChatGPT o3-mini‑high, ChatGPT 4.1, Claude Sonnet 4, ChatGPT o3, Gemini 2.5 Pro, DeepSeek R1–0528) на бенчмарке LiveSQLBench.

6 моделей, 10 задач, сложность от ★★ до ★★★★★★★★★★. Проверим, как они считают лунные помехи, генерируют SQL для криптобирж и ищут артефакты в музеях.

Чем лучше разработчик, тем хуже он делает аналитику. Просто потому, что для этого требуется разный технологический стек.

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

В этой статье я расскажу про 2 ключевых подхода к хранению и обработке данных, какой мы выбрали для аналитики в Saas-платформе и к чему это привело.

Как превратить текст «Сколько было продано камер в прошлом месяце?» в осмысленный SQL‑запрос? Это и есть задача text‑to‑SQL (ее ещё называют NL2SQL). Для многих компаний сейчас очень важна возможность задавать вопросы к данным обычным языком, без изучения SQL. Для этой задачи написаны десятки инструментов, но суть одна — генерация корректного запроса из фразы на человеческом языке.

Требование проясняется примером: бизнес‑пользователь хочет узнать: «Какие топ-5 товаров по выручке за вчерашний день?» — а система превращает это в SELECT product, SUM(revenue) ... LIMIT 5 и выдаёт результат. До недавнего времени требовались сложные пайплайны или ручное кодирование, а сейчас на сцене — большие языковые модели (LLM) и всякие прокачанные методы достучаться до них.

В этой статье мы пробежимся по ретро‑ и ультрасовременным подходам к text‑to‑SQL. Плюс обзору добавим практических инсайтов.

Всем привет! Сегодня хочу рассказать, как можно протестировать Личный кабинет банка с помощью Postman, на примере простого Веб-приложения. Будет проверено: создание пользователя, авторизация, отображение продуктов клиента в Личном кабинете, подача заявки на потребительский кредит и отображение результатов ее рассмотрения в ЛК. Приступим

Было разработано небольшое Веб-приложение на Node.js. После запуска приложения и открытия его на локальной машине по адресу - http://localhost:5000/, на странице отображается форма входа в Личный кабинет.

Что отличает архитектора от кодера? Не должность, не титул, не стаж.
Ответ - в мышлении. В том, кто видит систему целиком, предвидит цепные последствия и способен сказать "нет" быстрому решению, которое отравит код через полгода. Эта статья - честное и местами болезненное размышление о системном мышлении, архитектуре и точке невозврата, после которой разработчик уже не может смотреть на код по-старому.

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

Индекс — это как указатель в толстенном справочнике. Без него, чтобы найти нужный термин, вы обречены листать страницу за страницей. С ним — вы мгновенно открываете нужный раздел. Но что, если указатель сам размером с полкниги? Или ведет не туда? Такой помощник только вредит. С индексами в БД всё то же самое. Грамотная стратегия индексирования — это полет. Ошибочная — это бег в мешках по болоту.

Новый релиз СУБД Tantor Postgres 17.5 насыщен обновлениями во всех основных аспектах: усиление безопасности, повышение общей производительности, новые расширения, а также инфраструктурные улучшения. Сегодня мы проведем обзор изменений, касающихся работы с высоконагруженными системами 1С. Релиз предлагает не просто несколько точечных исправлений, а целый арсенал специализированных функций, призванных существенно ускорить выполнение типичных для 1С операций, снизить нагрузку на инфраструктуру и упростить администрирование. Спектр улучшений распространился на многие ключевые узлы производительности от оптимизации работы с временными таблицами и сложными запросами RLS (row-level security) до ускорения критически важных процессов наподобие «Закрытия месяца». Обо всем этом и пойдет речь в статье.

Хранение денежных сумм в базах данных и API: анализ подходов платежных систем

Хранение денег — вещь только на первый взгляд простая, а на деле содержит множество подводных камней. Выбрав не тот тип данных, можно получить неточности в расчётах, возможна путаница при переводе суммы из одной валюты в другую. А если ещё и подключать внешние API, у каждого из которых своя точность для одних и тех же валют, уследить за совместимостью еще труднее.

Разбираем, как решают эти проблемы Stripe, PayPal, Google Wallet и другие платежные системы. Сравниваем три основных подхода: Integer minor units, Decimal base units и String base units.