Введение в транзакции

В ранние дни обработки бизнес-данных, запись в базу данных обычно соответствовала коммерческой транзакции: продажа товара 🛍️, заказ у поставщика 📦, выплата зарплаты сотруднику 💰 и т.д. Со временем термин "транзакция" закрепился даже для операций, не связанных с деньгами, и стал обозначать группу операций чтения и записи, образующих логическую единицу.

• 💥 Атомарность — минимальное обязательное свойство любой транзакции
• 🛡️ Полный ACID — часть надежности для критических операций
• ⚖️ На практике — разные системы выбирают баланс между надежностью (ACID) и производительностью (ослабленные гарантии)

🔄 OLTP vs OLAP: Два разных мира

Online Transaction Processing (OLTP) — это тип систем баз данных, используемых в транзакционно-ориентированных приложениях (банки, система учета (ERP, CRM), системы бронирования, платежные системы и т.д.), таких как многие операционные (основные) бизнес-системы.

Часто выделяют два контекста использования термина "транзакция":

Тип 1: Компьютерные транзакции 💻

• Атомарное изменение данных в БД
• Пример: BEGIN TRANSACTION → UPDATE → COMMIT

Тип 2: Бизнес-транзакции 💰

• Экономический обмен между сторонами
• Пример: продажа товара, банковский перевод

Как связаны: OLTP использует технические транзакции (1 тип) для записи бизнес-операций (2 тип).

Например:

• 💳 Покупка в магазине (бизнес-транзакция)
• записывается через 🖥️ SQL-транзакцию в БД

Короче: Технические транзакции = инструмент для записи бизнес-транзакций 🔧→📊

OLTP (Online Transaction Processing)

Даже когда базы данных стали использоваться для различных типов данных (комментарии в блогах 📝, действия в играх 🎮, контакты в адресной книге 👥 и т.д.), основная модель доступа оставалась похожей на обработку бизнес-транзакций.

Характеристики OLTP:

• Поиск небольшого количества записей по ключу 🔑
• Вставка и обновление данных на основе пользовательского ввода
• Интерактивный режим работы

Пример на C:

// Пример OLTP-операции: поиск информации о клиенте по ID
#include <stdio.h>
#include <string.h>

struct Customer {
    int id;
    char name[50];
    double balance;
};

struct Customer find_customer_by_id(int customer_id) {
    // В реальной системе здесь был бы запрос к базе данных
    struct Customer customer;
    customer.id = customer_id;
    strcpy(customer.name, "Иван Иванов");
    customer.balance = 15000.75;
    return customer;
}

OLAP (Online Analytic Processing)

Online Analytical Processing (OLAP) — это подход к быстрому ответу на многомерные аналитические запросы.

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

*Data Warehousing (Хранилища данных) *OLAP-куб (от англ. Online Analytical Processing – оперативная аналитическая обработка данных) — это многомерная структура данных, предназначенная для быстрого и эффективного анализа больших объемов бизнес-данных с различных точек зрения. Простыми словами, OLAP-куб можно сравнить со сводной таблицей в Excel, но гораздо более мощной и способной работать с огромными массивами информации и множеством параметров (измерений).

Так, давай рассмотрим OLAP-CUBE

Данные OLAP обычно хранятся в виде схемы "звезда" или "снежинка" в реляционном хранилище данных или в специализированной системе управления данными. Показатели выводятся из записей в таблице фактов, а измерения - из таблиц измерений. но! Классические OLAP-кубы (как в Microsoft Analysis Services) часто хранят данные в proprietary многомерных форматах, а не в реляционных таблицах "звезды". Сама "звезда" — это схема хранения сырых данных, на основе которой строится куб. Кроме того, современные MPP-системы (Massively Parallel Processing) типа ClickHouse или Amazon Redshift часто не используют кубы в классическом понимании, но предоставляют аналогичную скорость для OLAP-запросов напрямую к реляционным таблицам.

🧊 OLAP Cube (Куб данных)

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

Основные понятия:

📦 Куб — многомерное обобщение двумерной электронной таблицы

# Пример: 3D куб данных
dimensions = ['Продукты', 'Время', 'Регионы']
measures = ['Продажи', 'Прибыль', 'Бюджет']

Slice

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

Dice

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

Drill Down/Up

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

Roll-Up

Сводный анализ включает в себя суммирование данных по измерению. Правило суммирования может быть агрегированной функцией, например, для вычисления итоговых значений по иерархии или применения набора формул, таких как "прибыль = продажи - расходы". 📊💰

Вычислительная сложность

Общие агрегатные функции могут быть дорогостоящими для вычисления при свертывании: ❌

• 🐌 Если они не могут быть определены по ячейкам куба, их необходимо вычислить из базовых данных
• ⏳ Либо вычислить их онлайн (медленно)
• 💾 Либо предварительно вычислить их для возможного развертывания (большой объем)

✅ Эффективные агрегатные функции

Агрегатные функции, которые могут быть определены из ячеек, известны как декомпозируемые агрегатные функции и позволяют эффективно выполнять вычисления.

💰 Стоимость агрегатных функций при свертывании

❌ Проблемные функции (дорогие в вычислении):

📊 Медиана (MEDIAN)

• Требует полной сортировки данных для каждого уровня агрегации
• Не обладает свойством композиционности - медиана подгрупп ≠ медиана всей группы
• Вычисление на лету требует хранения всех исходных значений

🎯 Процентили (PERCENTILE)

• Аналогично медиане, требуют доступа ко всему набору данных
• 90-й процентиль нельзя вычислить из 90-х процентилей подгрупп
• Необходимо хранить полное распределение данных

🔢 Мода (MODE)

• Требует подсчета частот всех значений
• Наиболее частое значение в подгруппах может не совпадать с общей модой
• Нужен полный перечет для точного определения

📈 Стандартное отклонение (STDDEV)

• Не является аддитивной функцией (В контексте агрегатных функций "аддитивность" означает возможность вычисления общего результата из частичных результатов.)
• Требует знания среднего значения и количества элементов
• Для точного расчета нужны ∑x и ∑x² по всем данным

Примеры:

✅ Легко поддерживаются:

• КОЛИЧЕСТВО 🔢
• МАКСИМУМ ⬆️
• МИНИМУМ ⬇️
• СУММА ➕

Поскольку они могут быть вычислены для каждой ячейки OLAP-куба, а затем свернуты, поскольку общая сумма (или количество и т.д.) является суммой подсуммов.

❌ Сложно поддерживать:

• МЕДИАНА 📊

Поскольку она должна вычисляться для каждого вида отдельно: медиана множества - это не медиана медиан подмножеств.

🔢 Математическое определение

(упрощенно) С математической точки зрения, OLAP куб — это проекция отношения RDBMS:

f: (X, Y, Z) → W

Где:

• X, Y, Z — оси куба (измерения) 📐
• W — данные, заполняющие каждую ячейку 💾

Пример проекции:

g: (Продукт, Время) → Продажи

💾 Хранение данных

OLAP данные обычно хранятся в:

• 🌟 Star Schema (Звездообразная схема)
• ❄️ Snowflake Schema (Снежинка)
• 🗄️ Специализированных системах управления данными

Пояснение (кратко)

🌟 Star Schema (Звезда)

• Денормализованная схема
• Все таблицы измерений связаны НАПРЯМУЮ с таблицей фактов
• Проще и быстрее для запросов
• Легче для понимания

❄️ Snowflake Schema (Снежинка)

• Нормализованная схема
• Таблицы измерений РАЗБИТЫ на подтаблицы
• Сложнее, но экономит место
• Медленнее из-за большего количества JOIN

Что это значит на практике:

• Звезда → для скорости анализа 📊⚡
• Снежинка → для экономии хранилища 💾📉

Практические примеры

💼 Бизнес-аналитика:

# Измерения бизнес-куба:
dimensions = [
    'Продукты 📦',
    'Время 📅',
    'Регионы 🌍',
    'Каналы_продаж 🏪',
    'Клиенты 👥'
]

# Меры (показатели):
measures = [
    'Объем_продаж 💰',
    'Прибыль 📈',
    'Количество_заказов 🔢',
    'Средний_чек 💵'
]

🏪 Пример розничной торговли:

Куб: "Продажи магазина"
├── Измерения:
│   ├── Время: Год → Квартал → Месяц → День
│   ├️── Товары: Категория → Бренд → Модель
│   ├── Магазины: Регион → Город → Адрес
│   └── Клиенты: Сегмент → Demographics
└── Меры:
    ├── Сумма продаж
    ├── Количество единиц
    ├── Прибыль
    └── Возвраты

🔗 Связанные технологии

🌐 Business Intelligence:

• 📊 Data Mining — интеллектуальный анализ данных
• 🏪 Data Mart — витрины данных
• 📈 MDX — Multidimensional Expressions
• 🔍 XML for Analysis

🛠️ Популярные OLAP системы:

• Microsoft Analysis Services
• Oracle OLAP
• Apache Kylin
• ClickHouse

💡 Ключевые преимущества OLAP Cube

📋 Сравнительная таблица: OLTP vs OLAP

OLTP обычно противопоставляется Online Analytical Processing (OLAP):

🏢 Data Warehousing (Хранилища данных)

Зачем нужно хранилище данных?

В крупных компаниях могут быть десятки различных систем обработки транзакций:

• Веб-сайты для клиентов 🌐
• Системы точек продаж (кассы) в магазинах 🏪
• Системы отслеживания запасов на складах 📦
• Системы планирования маршрутов транспорта 🚚
• Системы управления персоналом 👥

Проблема: OLTP-системы должны быть высокодоступными и обрабатывать транзакции с малой задержкой. Аналитические запросы часто требуют сканирования больших объемов данных и могут мешать работе транзакций.

Решение: Хранилище данных — отдельная база данных, где аналитики могут выполнять любые запросы без влияния на OLTP-операции.

🔄 Процесс ETL (Extract–Transform–Load)

Данные попадают в хранилище через процесс ETL:

1. Extract (Извлечение) - данные извлекаются из OLTP-систем
2. Transform (Преобразование) - данные преобразуются в схему, удобную для анализа
3. Load (Загрузка) - данные загружаются в хранилище

Пример из жизни: Крупный банк 🏦 может иметь отдельные системы для:

• Мобильного банкинга 📱
• Кредитных операций 💳
• Ипотечных продуктов 🏠
• Инвестиционных услуг 📈

Все эти данные объединяются в хранилище данных для сквозной аналитики.

⭐ Звезда и ❄️ Снежинка: Схемы для аналитики

🌟 Звездообразная схема (Star Schema)

В центре схемы находится таблица фактов, окруженная таблицами измерений.

Пример для розничной торговли:

• fact_sales (таблица фактов продаж) - в центре
• dim_product (измерение товаров) 📦
• dim_store (измерение магазинов) 🏪
• dim_time (измерение времени) ⏰
• dim_customer (измерение клиентов) 👥

Пример на C:

// Структура для таблицы фактов продаж
struct FactSale {
    int sale_id;
    int product_id;     // ссылка на dim_product
    int store_id;       // ссылка на dim_store
    int time_id;        // ссылка на dim_time
    int customer_id;    // ссылка на dim_customer
    double amount;
    int quantity;
    double profit;
};

// Структура для таблицы измерений товаров
struct DimProduct {
    int product_id;
    char sku[20];
    char description[100];
    char brand[50];
    char category[50];
    double price;
};

❄️ Снежинковая схема (Snowflake Schema)

Более нормализованная версия звездообразной схемы, где измерения дополнительно разбиваются на под-измерения.

Преимущество звездообразной схемы: проще для аналитиков!

💾 Особенности хранилищ данных

• Широкие таблицы: таблицы фактов часто имеют более 100 столбцов 📋
• Богатые метаданные: таблицы измерений содержат всю возможную информацию для анализа
• Оптимизация под аналитические запросы: специальные структуры хранения и алгоритмы

Краткий вывод: OLTP vs OLAP

🎯 Ключевые различия

OLTP (Online Transaction Processing)

• 💰 Обработка операций в реальном времени
• 🔄 Короткие транзакции (чтение/запись)
• ⚡ Высокая доступность, мгновенный отклик
• 🏦 Примеры: банковские переводы, заказы, бронирования

OLAP (Online Analytical Processing)

• 📊 Аналитика и отчетность
• 🔍 Сложные запросы на больших данных
• 📈 Многомерный анализ (кубы, срезы, детализация)
• 🧠 Примеры: бизнес-аналитика, прогнозирование

🏗️ Архитектурные особенности

OLTP

• ACID-транзакции 🛡️
• Нормализованные схемы
• Оптимизация под запись

OLAP

• Денормализованные схемы (🌟 Звезда/❄️ Снежинка)
• Хранилища данных (Data Warehouse)
• ETL-процессы
• Оптимизация под чтение

💡 Что это значит на практике

Вывод: OLTP обеспечивает ежедневную работу компании, а OLAP помогает понимать тенденции и принимать стратегические решения. Оба подхода критически важны, но решают разные задачи.