O documento discute isolamento transacional e MVCC (Multiversion Concurrency Control). MVCC permite que leitores não bloqueiem escritores e vice-versa aumentando a concorrência. No MVCC, cada transação vê um snapshot do banco no momento em que iniciou, evitando problemas como dirty reads. Isso requer manter várias versões dos dados no banco de dados.

1. Isolamento e MVCC
José Arthur Benetasso Villanova
jose.arthur@locaweb.com.br
Delivery Engineering

2. Características de um banco transacional
Atomic
Consistent
Isolated
Durable

3. Características de um banco transacional
Atomic: Tudo ou nada
Consistent: O dado é válido no contexto
Isolated: Uma transação não atrapalha a
outra
Durable: Gravado em uma mídia durável
(disco normalmente)

4. Fenômenos de Isolamento
Isolation
Level
Dirty Read Non-Repeatable
Read
Phantom Read Notes
Read
Uncommited
Possible* Possible Possible SQL Server WITH
(NOLOCK)
PostgreSQL não
tem
Read
Commited
Not Possible Possible Possible Padrão do SQL
Server e
PostgreSQL
Repeatable
Read
Not Possible Not Possible Possible* Padrão InnoDB, não
é possível Phantom
Read
Serializable Not Possible Not Possible Not Possible

5. Dirty Reads
Transaction 1
SELECT age FROM users WHERE id = 1;
-- retorna 20
SELECT age FROM users WHERE id = 1;
-- retorna 21
Transaction 2
BEGIN;
UPDATE users SET age = 21 WHERE id = 1;
ROLLBACK;

6. Non-repeatable Reads
Transaction 1
SELECT * FROM users WHERE id = 1;
SELECT * FROM users WHERE id = 1;
COMMIT;
Transaction 2
UPDATE users SET age = 21 WHERE id = 1;
COMMIT;

7. Phantom Reads
Transaction 1
SELECT * FROM users
WHERE age BETWEEN 10 AND 30;
SELECT * FROM users
WHERE age BETWEEN 10 AND 30;
COMMIT;
Transaction 2
INSERT INTO users VALUES ( 3, 'Bob', 27 );
COMMIT;

8. Estratégias para manter a consistência
● Locks
○ Muitas locks travando banco e baixando a
performance
● MVCC (Multiversion Concurrency Control)
○ Cópias do mesmo registro para um grupo de
transações

9. MVCC
● Readers never block writers, and writes
never block readers
● Conceito criado na década de 70, mas
somente colocado em prática na década de
80 por limitações das máquinas

10. MVCC - Quem usa?
Altibase Druid HypergraphDB NuoDB ScimoreDB
ArangoDB EXASOL InfiniDB Netezza sones GraphDB
Berkeley DB eXtremeDB Ingres ObjectStore Sybase SQL Anywhere
Bigdata Firebird InterBase Oracle database Sybase IQ
Cloudant FLAIM MariaDB OrientDB ThinkSQL
Clustrix FoundationDB MarkLogic Server PostgreSQL Tibero
Couchbase GE Smallworld Version
Managed Data Store
MemSQL Rdb/ELN TokuMX
CouchDB H2 Database Engine MDB RDM Embedded Zope Object Database
IBM DB2 Hawtdb Meronymy SPARQL
Database Server
REAL Server
IBM Cognos TM1 HBase (Apache HBase) Microsoft SQL Server RethinkDB
Drizzle HSQLDB MySQL SAP HANA

11. MVCC - PostgreSQL
● Cada transação cria seu próprio snapshot
da base de dados
● Este snapshot não contém os dados mais
atualizados, contém os dados do momento
que a transação iniciou

12. MVCC - PostgreSQL
Como funciona?

13. MVCC - PostgreSQL

14. MVCC - PostgreSQL
● As consequências deste modelo é uma
grande quantidade de dados duplicados no
banco
● O PostgreSQL não mantém uma lista da
transações correntes e a visibilidade do
registros, e por isso ele não apaga ou marca
para apagar os registros passados

15. MVCC - PostgreSQL
● Os novos registros são alocados se possível
na mesma página de dados que os antigos,
mas nem sempre isso é possível já que uma
página tem 8192 bytes (8K)

16. MVCC - PostgreSQL
● Os registros deixados para trás são
recuperados por outro processo o VACUUM;
● Registros são marcados como não utilizados
mais, mas não são removidos, causando
fragmentação do banco de dados
○ Exceção: se uma página fica vazia e está no final do
arquivo, ela é removida pelo VACUUM

17. MVCC - PostgreSQL
● VACUUM FULL ou CLUSTER
○ Criam uma nova tabela de forma ordenada e
apagam a original, liberando espaço
○ Processo lento e necessita de bastante espaço livre
○ Precisa efetivamente de LOCKS no banco para
funcionar, travando escritas
○ Se espaço for um problema, adicione discos

18. MVCC - PostgreSQL
● Existem muitos estudos e otimizações
dentro do banco de dados para minimizar
este problema de espaço e
consequentemente performance

19. MVCC - PostgreSQL
ze=# select xmin,xmax,cmin,cmax,* from ze;
xmin | xmax | cmin | cmax | k | v
---------+------+------+------+---+---------------
3342006 | 0 | 11 | 11 | 1 | Oi
3342006 | 0 | 11 | 11 | 2 | Tudo bem?
3342006 | 0 | 11 | 11 | 3 | Até Breve
3342014 | 0 | 0 | 0 | 4 | Olá novamente
(4 registros)

20. MVCC - PostgreSQL
● xmin: número da transação que criou o registro
● xmax: número da maior transação que pode ver o
registro, quem apagou o registro (ou atualizou)
● cmin: comando mínimo que consegue ver o registro
(dentro de uma transação)
● cmax: comando máximo que pode ver o registro dentro
da transação

21. MVCC - PostgreSQL
● Transação analisada: 35
● Transações em progresso: 15 e 35
● Transação 15: possui o registro
vermelho, amarelo e os verdes em seu
snapshot
● Transação 35: Não tem o vermelho, tem
ou não o amarelo dependendo do
isolamento, e vê ambos os verdes

22. MVCC - Outros bancos
● Oracle e MySQL: possuem uma área de
UNDO ao invés de gravar no bloco os
registros expirados
● SQL Server: não utiliza o MVCC por padrão,
é necessário ativar o mecanismo através do
comando:
SET TRANSACTION ISOLATION LEVEL SNAPSHOT

23. Referências
http://en.wikipedia.org/wiki/Isolation_%28database_systems%29
http://en.wikipedia.org/wiki/Multiversion_concurrency_control
http://momjian.us/main/presentations/
https://dev.mysql.com/doc/refman/5.6/en/innodb-transaction-model.html
http://www.postgresql.org/docs/9.4/static/transaction-iso.html
https://msdn.microsoft.com/en-us/library/ms173763.aspx

24. We want you!
Junte-se ao nosso clã para
batalhas!
● LightServants
● #P9VPVCOP
Comente “MVCC” no pedido