Baixar para ler offline
Carregado porLocaweb
Isolamento e mvcc
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.
Mais conteúdo relacionado
Isolamento e mvcc
- 1. Isolamento e MVCC JoséArthur Benetasso Villanova jose.arthur@locaweb.com.br Delivery Engineering
- 2. Características de umbanco transacional Atomic Consistent Isolated Durable
- 3. Características de umbanco 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 DirtyRead 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 SELECTage 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 mantera 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 neverblock 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 - Quemusa? 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 Comofunciona?
- 13.
- 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 - Outrosbancos ● 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.
- 24. We want you! Junte-seao nosso clã para batalhas! ● LightServants ● #P9VPVCOP Comente “MVCC” no pedido