Базы данных *

Документация PostgreSQL по numeric содержит два плохо согласующихся утверждения:

«especially recommended for storing monetary amounts and other quantities where exactness is required» — и сразу же: «calculations on numeric values are very slow compared to the integer types, or to the floating-point types». То есть рекомендуют для хранения денежных величин и тут же признают, что это весьма дорого.

Для меня, как разработчика СУБД это сигнал к действию. Если операции с типом заметно медленнее bigint, возникает соблазн: а нельзя ли хранить денежные величины целым числом копеек и округлять по стандартному правилу? Это бы прилично сэкономило вычислительные ресурсы наших серверов баз данных, разве нет? А что, если вообще использовать double precision?

Отчёт пользователя вскрыл утечку между диалогами в query-провайдере ядра — 6 из 6. Что ещё в 3.6.0: AS2/EDI, общий Kestrel, Camel-паритет.

Год стек рос на наших собственных задачах: мы писали то, что нужно было нам, и проверяли на своей проде. С весны им начали пользоваться посторонние люди — и характер входящих сообщений изменился. Вместо «а поддерживаете ли вы X» приходят разборы: воспроизведение, номера строк в наших исходниках, обходные пути, которые человек уже написал у себя, пока ждал ответа.

Это самое ценное, что может ...

На старте почти любого проекта бизнес-аналитик оказывается в одной и той же ситуации. Бизнес говорит: «клиент может иметь несколько договоров», «договор относится только к одному клиенту», «товар идентифицируется артикулом».

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

На этом шаге аналитик становится переводчиком между двумя мирами. Нужен промежуточный слой — формальное, проверяемое описание предметной области. Таким слоем часто становится концептуальная модель данных: она помогает согласовать термины между бизнесом и ИТ, зафиксировать правила до проектирования таблиц и API, увидеть противоречия и пробелы в требованиях, отделить смысл данных от будущей технической реализации.

Меня зовут Вадим Скляров, я бизнес-аналитик проектного офиса МТС Медиа. В этом материале расскажу, почему для этой задачи я выбрал ORM2 в качестве инструмента концептуального моделирования, какие приложения есть на рынке, почему в итоге понадобилось собственное SPA-приложение и чем оно оказалось полезным.

Привет, Хабр!

Меня зовут Жуйков Андрей, занимаюсь развитием и продвижением СУБД Digital Q.DataBase.

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

В этой статье я покажу, как установить Digital Q.DataBase 18.2 на РЕД ОС 8.0.3, познакомлю с новой архитектурой СУБД и продемонстрирую подключение к каждому из поддерживаемых диалектов.

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

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

Сообщение в личку в 18:40: «Слушай, а почему у тебя в выгрузке 11 903 заказа, а на дашборде 12 480? Завтра в 11 показываем отчет».

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

За годы работы я разбирала такие расхождения десятки раз, собрала алгоритм, по которому причина находится примерно за час: таблица симптомов, семь шагов и список типовых причин, от границ периода до кэша дашборда.

Если вы пишете SQL-запросы, то наверняка сталкивались с ситуацией, когда данные исчезают, отчеты не сходятся, а бизнес теряет деньги. И виновник этого — маленькое, но очень коварное слово NULL. В 1974 году Эдгар Кодд, создатель реляционной модели данных, ввел это понятие, чтобы обозначить отсутствие информации. Он хотел, как лучше, но спустя пятьдесят лет NULL продолжает «терроризировать» разработчиков по всему миру. Важно усвоить раз и навсегда: NULL — это не значение. Это состояние неизвестности.

Поэтому:

·       NULL ≠ 0 (ноль - это число);

·       NULL ≠ '' (пустая строка - это строка);

·       NULL ≠ ' ' (пробел - это символ).

Но всегда есть нюансы и исключения. Например, в Oracle INSERT INTO table (col) VALUES ('') запишет NULL. Это поведение отличается от других СУБД и часто становится сюрпризом при миграции.

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

Для понимания контекста добавлю, что я НЕ девопс - мне пришлось этим заниматься, и всё пишу через призму своего понимания проблемы. Возможно, сейчас придёт корифей AWS/CDK и скажет, что всё можно было сделать проще. Другими словами, не является индивидуальной инвестиционной рекомендацией.

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

Я сделал его в 2002 году, выбрал хранить, и получил вместе со скоростью проблему на двадцать лет вперёд.

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

Причина оказалась не в триггерах и не в производительности. Она в том, что одно бизнес‑правило было записано в коде шесть раз в разных местах, а в седьмом его забыли написать.

Когда речь заходит об оптимизации запросов в PostgreSQL, разработчики, как правило, сосредотачиваются на времени выполнения: индексы, планы запросов, настройки памяти и так далее. Время планирования остаётся в тени. А зря! Планировщик работает перед каждым выполнением запроса. Для OLTP-нагрузки с короткими транзакциями накладные расходы на планирование могут составлять значительную долю от общего времени ответа. Для запросов с большими IN-списками и высоким statistics_target планирование может занимать сотни миллисекунд, тогда как само выполнение укладывается в миллисекунды. Поэтому ускорение планировщика не менее важно, чем ускорение выполнения.

Всем привет! Меня зовут Муса. Наша команда занимается витринами данных по товарному учёту.

Каждый день мы доставляем около 10 млрд записей в разных форматах. На этих данных строится различная аналитика, связанная с товарными запасами и движениями экземпляров. Перед нами встала задача: пять раз в день обогащать выгрузку из миллиардов экземплярных остатков дополнительными атрибутами для построения различного рода аналитики. История этих атрибутов уже измерялась десятками миллиардов записей.

Первое решение выглядело просто: положить данные в ClickHouse и сделать JOIN. Но одна выгрузка считалась около 12 часов, а нам нужно было укладываться в десятки минут.

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

TL;DR. Финансовая модель в таблице разваливается при смене периода расчёта. Я честно старался, был аккуратен как мог, но период в модели хранится в геометрии листа: колонка — это месяц, а формулы адресуют ячейки по абсолютным координатам. На Хабре на эту боль есть два описанных ответа, оба уходят от таблиц: перенести логику в OLAP-куб с семантическим слоем или написать модель на Python. Здесь описан третий: оставить табличный интерфейс, но вынести диапазон и период в параметры модели, а адресацию перевести с координат ячеек на имена строк и колонок. Перевод модели из 10 листов с месяцев на кварталы стоит тогда 2 действия вместо 460–3060 — расчёт по шагам приведён в тексте.

Почти любой бэкенд рано или поздно сталкивается с необходимостью отложенной обработки задач: отправить email после регистрации, пересчитать агрегаты, выполнить задачу по расписанию. Часто для этого подключают отдельную систему — RabbitMQ, Kafka, Redis-очереди. Но если ваши данные уже живут в YDB, нужные примитивы уже рядом: таблицы, changefeed, топики и координационные ноды.

В этой статье разберём четыре подхода к асинхронной обработке задач — от простой таблицы до архитектуры, пригодной для production-сценариев. Каждый следующий подход решает проблемы предыдущего, но добавляет сложности. Вместо абстрактных описаний — рабочий код на Go с использованием ydb-go-sdk.

…и почему это всё равно лучше, чем Excel

Когда говорят о базах данных, большинство людей представляет себе что-то скучное вроде таблиц Excel, индексов, SELECT * FROM и разработчика, который спорит с DBA о нормализации. Но на практике базы данных живут куда более разнообразной и интересной жизнью. Например, они управляют коровами, пишут музыку, отслеживают космический мусор и даже помогают археологам восстанавливать древние цивилизации.

Команда Т1 Облако собрала интересные примеры использования баз данных — от реально полезных до почти абсурдных, но весьма необычных. Что интересно, почти все они используют те же самые движки, которые стоят у нас в облаке.

В обзорной статье мы разобрали, зачем использовать в поиске тот же UUID, что и в основной базе (если таковая имеется). Здесь сразу перейдём к практике: создадим таблицу, выполним основные операции через SQL и JSON API, а затем загрузим несколько документов через /bulk.

Все примеры рассчитаны на Manticore Search 28.5.0 или новее. Значение <generated UUID> в ответах обозначает UUID, который Manticore создаст при обработке запроса. Копировать эту строку в следующий запрос не нужно: подставьте фактический id из своего ответа.

В многомерном пространстве найти Винни-Пуха можно даже не зная его имени. В запросе “тревожный коричневый медведь из старого мультфильма” нет ни одного слова из имени или описания питомца, но гибридный поиск по словам и векторам всё равно выдает его первым. Показываю, как Codex Pets превращает текст и кадры анимации в векторы, сравнивает их в YDB и помогает Винни найти друзей.

CPU и диск свободны, а сервис уже задыхается: транзакции ждут блокировок, соединения заканчиваются, база перестаёт отвечать.

Разберём, как найти корневой процесс в PostgreSQL, отличить длинную транзакцию от конкуренции за строки и остановить каскадный сбой.

Иногда бизнес-логика выглядит просто: «соберём все данные за период и посчитаем итоговый результат». На практике этот период может оказаться не часом и даже не днём, а несколькими сутками. В одном из моих проектов требовалось построить агрегаты на основе данных, которые могли поступать в течение пяти дней.

В литературе мы встретили концепцию временных окон (Time Windows). По описанию это выглядело именно тем инструментом, который должен решить задачу: определить период ожидания, дождаться всех необходимых данных и получить итоговый агрегат.

Однако при работе с реальными потоками оказалось, что основная сложность заключается вовсе не в выборе размера окна. Главный вопрос оказался другим: существует ли вообще момент, после которого агрегат можно считать завершённым и больше никогда не изменять?

Когда нужно проверить запись в таблице, выполнить запрос из логов или понять, почему база выбрала странный план, разработчик обычно вспоминает про DBeaver, pgAdmin или DataGrip. Все три варианта решают задачу, но по-разному.

1. DBeaver и pgAdmin остаются отдельными программами: со своими окнами, подключениями и настройками. 
2. DataGrip можно получить как в отдельной IDE, так и внутри IntelliJ IDEA Ultimate, WebStorm, GoLand и других IDE от JetBrains.

Но сегодня путь от скачивания до работающей IDE с лицензией далёк от простого и легального.

OpenIDE это третий вариант: полноценный DB-клиент уже входит в состав IDE. Через него легко подключиться к базе, посмотреть ее структуру, написать SQL с комплишенами и подсветкой синтаксиса, запустить EXPLAIN, править и выгружать данные.

Всем добрый день. Как и в предыдущие месяцы, по итогам июля мы решили рассказать про то, как изменилась GigaIDE за прошедший месяц. Ниже — краткий обзор обновлений Pro-функциональности GigaIDE, который можно найти на нашем маркетплейсе.