OLTP
OLTP-система обслуживает множество коротких конкурентных бизнес-операций: создать заказ, изменить состояние, зарезервировать позицию.
Характеристики
- небольшое число строк на операцию;
- высокая частота чтений и записей;
- предсказуемая latency;
- constraints и транзакции;
- индексы под конкретные пути доступа;
- нормализованная модель как частая отправная точка.
BEGIN;
INSERT INTO orders (id, user_id, state, total, created_at)
VALUES (42, 7, 'NEW', 500.00, CURRENT_TIMESTAMP);
INSERT INTO items (id, order_id, sku, quantity, price)
VALUES (100, 42, 'A-1', 1, 500.00);
COMMIT;OLTP и OLAP
| Свойство | OLTP | OLAP |
|---|---|---|
| задача | текущие операции | анализ истории |
| запрос | точечный/короткий | scan и агрегация |
| изменение | частое, небольшое | batch/append |
| модель | часто нормализованная | часто звездная/широкая |
| хранение | часто строковое | часто колоночное |
Это профили, а не жесткие категории. Одна СУБД может поддерживать оба, но тяжелый отчет способен конкурировать с транзакциями за CPU, I/O, память и locks.
Что важно в OLTP
- короткие границы транзакций;
- отсутствие сетевых вызовов под lock без причины;
- индексы на FK и горячие предикаты;
- connection pool с ограничением;
- обработка deadlock и serialization failure;
- идемпотентность повторов;
- архивирование/partitioning истории;
- p95/p99 и lock waits в наблюдаемости.
Вынос аналитики
Данные передают в read replica, хранилище или отдельную read model. Это снижает влияние отчетов, но добавляет задержку, дублирование и задачу сверки.
Связано: Транзакции принцип ACID, Индексы SQL, Нормализация денормализация, Типы баз данных.
Вопросы
Главный профиль OLTP? Много коротких конкурентных операций над малым числом строк.
Почему длинная транзакция опасна? Дольше держит ресурсы/версии и повышает вероятность конфликта.
Почему отчет лучше вынести? Большой scan конкурирует с критичными операциями.
Что теряем при чтении с реплики? Возможна задержка видимости свежего commit.