0Pricing
SQL Academy · Aula

OLTP vs OLAP

Bancos de dados transacionais vs analíticos.

OLTP vs OLAP é uma aula grátis de SQL Academy no CoddyKit. Esta é a aula 1 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de SQL Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de SQL Academy inclui 4 aulas no total.

O que são OLTP e OLAP?

Os bancos de dados não servem para todos os usos da mesma forma. Duas cargas de trabalho fundamentalmente diferentes moldaram a maneira como projetamos e operamos bancos de dados: OLTP (processamento de transações on-line) e OLAP (processamento analítico on-line).

Entender essa diferença é essencial para qualquer profissional de dados. A escolha correta entre OLTP e OLAP determina a velocidade das consultas, o custo de armazenamento e a arquitetura geral do seu sistema de dados.

OLTP: desenvolvido para transações

Os sistemas OLTP lidam com um grande volume de operações curtas e rápidas — inserções, atualizações e exclusões que refletem eventos empresariais em tempo real. Entre os exemplos estão fazer um pedido, processar um pagamento ou atualizar o registro de um cliente.

As principais características do OLTP são: baixa latência por operação, alta simultaneidade e forte consistência. Toda transação deve estar em conformidade com ACID para proteger a integridade dos dados.

-- OLTP example: inserting a new order
INSERT INTO orders (customer_id, product_id, quantity, order_date)
VALUES (1042, 88, 3, CURRENT_DATE);

-- Immediately update inventory
UPDATE inventory
SET stock = stock - 3
WHERE product_id = 88;

OLAP: desenvolvido para análise

Os sistemas OLAP são otimizados para consultas complexas que percorrem grandes volumes de dados históricos para revelar tendências, padrões e resumos. Analistas de negócios e cientistas de dados usam OLAP para responder a perguntas como: 'Quais foram nossas vendas totais por região no último trimestre?'

As consultas OLAP geralmente agregam milhões de linhas e envolvem várias junções entre tabelas de fatos e dimensões. A velocidade de escritas individuais é secundária; o que importa é a capacidade de leitura e a flexibilidade das consultas.

-- OLAP example: total sales by region for Q1 2024
SELECT
    d.region,
    SUM(f.sales_amount) AS total_sales,
    COUNT(f.order_id)   AS order_count
FROM fact_sales f
JOIN dim_date   dd ON f.date_key   = dd.date_key
JOIN dim_store  d  ON f.store_key  = d.store_key
WHERE dd.year = 2024
  AND dd.quarter = 1
GROUP BY d.region
ORDER BY total_sales DESC;

Comparando os dois lado a lado

A maneira mais fácil de lembrar a diferença é pensar em quem usa cada sistema e como o utiliza:

  • OLTP: usado pelos backends de aplicações; milhares de usuários simultâneos; cada consulta acessa poucas linhas.
  • OLAP: usado por analistas e ferramentas de relatórios; menos consultas simultâneas, mas cada uma percorre milhões de linhas.

Esses padrões de acesso contrastantes levam a projetos de esquema, estratégias de indexação e até escolhas de hardware muito diferentes.

-- OLTP: lookup a single customer's latest order (row-level access)
SELECT o.order_id, o.order_date, o.total_amount
FROM orders o
WHERE o.customer_id = 1042
ORDER BY o.order_date DESC
LIMIT 1;

-- OLAP: monthly revenue trend over the past year (aggregate scan)
SELECT
    DATE_TRUNC('month', order_date) AS month,
    SUM(total_amount)               AS revenue
FROM orders
WHERE order_date >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1;

Projeto de esquema: normalizado vs. desnormalizado

Os bancos de dados OLTP favorecem esquemas normalizados (3NF ou superior) para eliminar a redundância e tornar as gravações eficientes. Cada entidade reside em sua própria tabela, reduzindo a quantidade de dados afetados por transação.

Os bancos de dados OLAP favorecem esquemas desnormalizados — especialmente os esquemas estrela e floco de neve — nos quais os dados são pré-juntados e redundantes. Isso elimina junções dispendiosas no momento da consulta e permite que os mecanismos de armazenamento colunar percorram os dados mais rapidamente.

-- Normalized OLTP design (3NF)
CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    name        VARCHAR(100),
    email       VARCHAR(150) UNIQUE
);

CREATE TABLE orders (
    order_id    SERIAL PRIMARY KEY,
    customer_id INT REFERENCES customers(customer_id),
    order_date  DATE,
    total       NUMERIC(10,2)
);

-- Denormalized OLAP fact table (star schema)
CREATE TABLE fact_sales (
    sale_id      BIGINT PRIMARY KEY,
    customer_key INT,
    date_key     INT,
    product_key  INT,
    region       VARCHAR(50),
    category     VARCHAR(50),
    amount       NUMERIC(12,2)
);

Estratégias de indexação

Os sistemas OLTP dependem bastante de índices de árvore B em chaves primárias e estrangeiras para permitir consultas rápidas de uma única linha e junções eficientes dentro de uma transação.

Os sistemas OLAP se beneficiam de índices de mapa de bits, armazenamento colunar e particionamento. Percorrer uma coluna inteira (por exemplo, todos os valores de vendas) é muito mais eficiente quando os dados são armazenados coluna por coluna, em vez de linha por linha.

-- OLTP: B-tree index for fast order lookup by customer
CREATE INDEX idx_orders_customer
    ON orders (customer_id);

-- OLTP: compound index for range queries
CREATE INDEX idx_orders_date_customer
    ON orders (order_date, customer_id);

-- OLAP: partition fact table by year to prune scan
CREATE TABLE fact_sales_2024
    PARTITION OF fact_sales
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

Concorrência e bloqueios

Os sistemas OLTP precisam lidar com milhares de gravações simultâneas sem conflitos. Os bancos de dados usam bloqueio no nível da linha e MVCC (Controle de concorrência multiversão), para que as leituras nunca bloqueiem as gravações e vice-versa.

As consultas OLAP são predominantemente somente leitura. Os bloqueios raramente são um problema, mas as varreduras demoradas podem consumir quantidades significativas de CPU e entrada/saída. A maioria dos armazéns de dados executa OLAP em um sistema separado, preenchido por processamento ETL em lote ou CDC (Captura de dados de alterações) a partir da fonte OLTP.

-- OLTP: explicit transaction with row-level lock
BEGIN;

SELECT balance
FROM accounts
WHERE account_id = 7
FOR UPDATE;

UPDATE accounts
SET balance = balance - 200
WHERE account_id = 7;

COMMIT;

ETL: conectando OLTP e OLAP

Como OLTP e OLAP têm projetos incompatíveis, as organizações executam ETL (Extrair, Transformar, Carregar) em fluxos de processamento para copiar e remodelar os dados do banco de dados transacional para o armazém analítico segundo um cronograma (durante a noite, a cada hora ou quase em tempo real).

O processo de ETL transforma as linhas normalizadas de OLTP em registros desnormalizados de fatos e dimensões, aplicando lógica de negócio ao longo do caminho (por exemplo, conversão de moeda e segmentação de clientes).

-- Simplified ETL INSERT from OLTP orders into OLAP fact table
INSERT INTO fact_sales (
    customer_key,
    date_key,
    product_key,
    amount
)
SELECT
    dc.customer_key,
    dd.date_key,
    dp.product_key,
    o.total_amount
FROM orders o
JOIN dim_customer dc ON dc.source_customer_id = o.customer_id
JOIN dim_date     dd ON dd.calendar_date       = o.order_date
JOIN dim_product  dp ON dp.source_product_id   = o.product_id
WHERE o.order_date = CURRENT_DATE - INTERVAL '1 day'
  AND o.order_id NOT IN (SELECT source_order_id FROM fact_sales);

Padrões típicos de consultas OLAP

As consultas OLAP quase sempre envolvem agregações (SUM, COUNT, AVG), agrupamentos em várias dimensões e filtragens por intervalos de datas ou categorias. Esses são os blocos fundamentais de painéis e relatórios empresariais.

As funções de janela são especialmente poderosas em cargas de trabalho OLAP — elas permitem comparar os valores de cada período com os do período anterior sem uma autojunção.

-- Year-over-year revenue comparison using a window function
SELECT
    dd.year,
    dd.quarter,
    SUM(f.amount)                                          AS revenue,
    LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
                             ORDER BY dd.year)             AS prev_year_revenue,
    ROUND(
        100.0 * (SUM(f.amount) -
                 LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
                                         ORDER BY dd.year))
        / NULLIF(LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
                                          ORDER BY dd.year), 0)
    , 2)                                                   AS yoy_pct_change
FROM fact_sales f
JOIN dim_date dd ON f.date_key = dd.date_key
GROUP BY dd.year, dd.quarter
ORDER BY dd.quarter, dd.year;

HTAP: eliminando as distinções

Sistemas modernos como TiDB, SingleStore e PostgreSQL + extensões colunares implementam o HTAP (Processamento híbrido transacional/analítico). Eles têm como objetivo lidar com ambas as cargas de trabalho em um único mecanismo, evitando a complexidade operacional de manter sistemas OLTP e OLAP separados.

O HTAP consegue isso armazenando os dados simultaneamente em dois formatos: um armazenamento por linhas para gravações transacionais e um armazenamento colunar para leituras analíticas, mantidos automaticamente sincronizados.

-- PostgreSQL with cstore_fdw (columnar extension) example
-- Analytical table stored in columnar format
CREATE FOREIGN TABLE fact_sales_columnar (
    date_key     INT,
    product_key  INT,
    region       VARCHAR(50),
    amount       NUMERIC(12,2)
)
SERVER cstore_server
OPTIONS (filename '/data/fact_sales_columnar');

-- Regular OLTP table remains row-based
-- Both can be queried in the same SQL statement
SELECT f.region, SUM(f.amount)
FROM fact_sales_columnar f
GROUP BY f.region;

Escolhendo o sistema certo

A decisão entre OLTP e OLAP (ou HTAP) depende da sua principal carga de trabalho:

  • Se estiver desenvolvendo um aplicativo que registra eventos em tempo real, use um banco de dados OLTP (PostgreSQL, MySQL, Servidor SQL).
  • Se estiver desenvolvendo uma camada de relatórios sobre dados históricos, use um armazém OLAP (BigQuery, desvio para o vermelho, floco de neve, ClickHouse).
  • Se precisar de ambos e quiser simplicidade operacional, avalie opções de HTAP.

Muitas arquiteturas de produção usam ambos: um banco de dados OLTP como fonte oficial dos dados e um armazém de dados separado para análises, conectados por um fluxo de processamento ETL.

-- Quick diagnostic: check table access pattern
-- High seq_scan relative to idx_scan = analytical (OLAP-like) load
SELECT
    relname              AS table_name,
    seq_scan,
    idx_scan,
    n_live_tup           AS live_rows
FROM pg_stat_user_tables
ORDER BY seq_scan DESC
LIMIT 10;

Verificação de conhecimentos

Verifique sua compreensão das principais diferenças entre os sistemas OLTP e OLAP.

Recapitulação da lição

OLTP vs. OLAP — principais conclusões:

  • OLTP lida com cargas de trabalho transacionais em tempo real: gravações rápidas e simultâneas no nível da linha, com garantias ACID.
  • OLAP lida com cargas de trabalho analíticas: agregações complexas sobre grandes conjuntos de dados históricos, usando esquemas desnormalizados.
  • O projeto do esquema segue a carga de trabalho — normalizado (3NF) para OLTP, estrela/floco de neve para OLAP.
  • Os fluxos de processamento ETL conectam os dois sistemas, carregando dados OLTP transformados no armazém analítico.
  • Os sistemas HTAP tentam atender a ambas as cargas de trabalho a partir de um único mecanismo, usando armazenamento duplo por linhas e colunas.

Escolher a arquitetura certa desde o início evita migrações trabalhosas posteriormente e garante que suas consultas sejam executadas na velocidade esperada pelos usuários.

Perguntas Frequentes

A aula “OLTP vs OLAP” é grátis?

Sim — o texto completo de “OLTP vs OLAP” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de SQL Academy, atualize para CoddyKit PRO. O curso de SQL Academy inclui 4 aulas no total.

O que vou aprender em “OLTP vs OLAP”?

Bancos de dados transacionais vs analíticos. Você pratica SQL Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar SQL Academy?

Nenhuma experiência prévia é necessária. SQL Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 1 de 4.

Quanto tempo leva a aula “OLTP vs OLAP”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de SQL Academy?

Sim. Cada aula de SQL Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. OLTP vs OLAP
  2. Tabelas de Fatos e Dimensões
  3. Esquemas Estrela e Floco de Neve
  4. Escrevendo Consultas Analíticas
← Voltar para SQL Academy