Perguntas[concurrency](dba)

Eu sou novo na transação. Quando li o livro "Transactional Information Systems", é mencionado que o B-tree usa o bloqueio de intervalo de chaves para garantir a serialização. É verdade que todos os acessos à relação devem ser realizados através da mesma árvore B para garantir a serialização?

Se bem entendi, não há como garantir a serialização se os acessos forem por diferentes índices . Veja o exemplo a seguir.

Suponha que existam dois índices na mesma relação, ou seja, uma árvore B e um índice de hash, e existam duas transações.

Primeiro, uma transação lê a relação usando o índice de hash, por exemplo, fetchkey(16)para buscar o registro (atualmente ausente) com a chave 16e não encontra correspondência. Como o hash não possui bloqueio de intervalo de chaves, ele não pode bloquear a próxima chave. Em seguida, a outra transação insere um registro com a chave '16' por meio da árvore B. A inserção será bem sucedida, levando a um fantasma.

Eu li Entender profundamente os níveis de isolamento e Ler fenômenos no MySQL e PostgreSQL e especialmente a parte "Anomalia de serialização no Postgres". Acho que entendi o problema descrito lá, mas tenho dificuldade em julgar quando isso pode acontecer na minha aplicação.

Só é possível com funções agregadas como SUM/COUNT obter uma anomalia de serialização no Postgres? Se não, com o que mais devo ficar atento?

Digamos que temos a seguinte situação em um aplicativo usando MySQL onde um usuário pode comprar um item e cada item tem um único comprador, mas o preço do item pode mudar.

Pseudo-código :

BEGIN TRANSACTION

seenPrice = SELECT price FROM Item
    WHERE id = ABC AND buyer IS NULL

UPDATE Item SET buyer = X
    WHERE id = ABC AND buyer IS NULL AND price = seenPrice

COMMIT

A seenPricevariável e as buyer IS NULL AND price = seenPriceverificações na instrução UPDATE servem como um meio de bloqueio otimista para garantir que nenhum problema de simultaneidade apareça .

Em um ambiente multi-threaded onde um thread A e um thread B passam pela SELECTinstrução ao mesmo tempo e dizem que o thread A executa a UPDATEinstrução primeiro, a simultaneidade não é uma preocupação , mas é possível que A e B executem a UPDATEinstrução no mesmo tempo exato? Para contextualizar o aplicativo está sendo desenvolvido usando Spring Boot e Spring Data JPA.

Eu tenho uma tabela de locais que se parece com isso:

CREATE TABLE Locations (
    Id INT NOT NULL AUTO_INCREMENT,
    Name VARCHAR(255) NOT NULL,
    NextInvoice INT NOT NULL,
    PRIMARY KEY (Id)
);

Agora quero criar uma fatura para um local e preciso de um número de fatura.

O número da fatura será igual ao NextInvoicevalor para aquele local. E então devo incrementar esse valor para a próxima fatura.

Lógica muito simples, mas complicada por condições de concorrência e corrida.

Como eu poderia executar essa tarefa de recuperar o próximo número de fatura disponível para um local e, em seguida, incrementar esse valor, e não duplicar ou pular nenhum número quando esse código é chamado mais de uma vez ao mesmo tempo?

Não posso usar um número de incremento automático de restrição exclusiva porque os números podem ser duplicados entre os locais.

Nota: Minhas habilidades principais incluem C# e não necessariamente SQL-Server. Na verdade, estou usando o Entity Framework para isso. Mas não estou acima de escrever um procedimento armazenado, se necessário.

Sou iniciante em Banco de Dados e por enquanto preciso trabalhar com MySQL para construir um servidor web.

Em uma palavra, tenho um framework web, desenvolvido com Python. Ele lerá/gravará dados de/no MySQL.

Por enquanto não sei como lidar com o caso de multithreading insert.

Digamos que há muitos usuários que estão gravando seus dados em uma tabela. Usarei um pool de threads para processar essas solicitações, o que significa que haveria vários inserts ao mesmo tempo.

Minha pergunta é:

Se eu tiver definido concurrent_insert=2, vários inserts ainda causarão o bloqueio da tabela para que eu tenha um desempenho muito ruim (todos os inserts devem ser tratados um por um)? Ou o próprio MySQL pode lidar com os múltiplos inserts corretamente para que eu possa obter um desempenho não ruim?

Para os múltiplos inserts, há alguma diferença entre "compartilhar um objeto de conexão" e "cada um inserttem seu próprio objeto de conexão"?

É bem conhecido que o isolamento Read Committed é propenso a diferentes anomalias. Li a série de The Great Paul White sobre níveis de isolamento. O post relevante para a discussão é este:

• O Nível de Isolamento Comprometido de Leitura

Ele afirma (novamente, é razoavelmente bem conhecido), que uma instrução executada sob isolamento de leitura confirmada:

Can encounter the same row multiple times;
Can miss some rows completely;

Minha pergunta é sobre a parte das 'linhas ausentes'. Exemplos que falam sobre linhas ausentes geralmente demonstram o problema usando consultas como:

select count(*) from table.

Minha pergunta é que as linhas podem ser perdidas em uma consulta de seleção 'regular' ? Ou seja, uma consulta como

select * from table

ou mesmo

select * from table where id = @id

também perder as linhas que são confirmadas antes do início dessa consulta? Esta pergunta se aplica apenas a Read confirmada com bloqueio (não RCSI), pois o RCSI não permite esses tipos de anomalias.

Eu tenho uma matriz que posso atualizar de vários trabalhadores da seguinte forma: UPDATE my_table SET arr = array_append(my_table.arr, element).

O problema aparece quando dois trabalhadores tentam atualizar a matriz ao mesmo tempo. Por exemplo, ambos os trabalhadores veem que no momento da atualização, o array está vazio e tentam anexar um elemento da seguinte forma: array_append(empty_arr, element_a)e array_append(empty_arr, element_b). No final, o conteúdo final do array será: arr[element_a]ou arr[element_b]porque um dos workers terminará de atualizar o array mais cedo e seu valor será substituído pelo valor do outro worker. Como posso garantir que ambos os valores sejam escritos na matriz: arr[element_a, element_b]?

Em um banco de dados Postgres, tenho um relacionamento da seguinte forma:

1. Uma tabela Grupo tem uma coluna userEntranceLimits.
2. Uma tabela UserEntrance tem uma coluna userId e uma coluna groupId.
3. A contagem de usuários distintos de uma UserEntrance para um grupo específico não pode exceder userEntranceLimits do grupo.
4. Dentro de uma transação (cujo nível de isolamento é REPEATABLE_READ) para criar uma nova UserEntrance, verifico se a contagem atual de UserEntrances para aquele grupo é >= o limite.
5. Se não for, prossigo para criar um novo UserEntrance.
6. Em algumas raras ocasiões, um grupo aparece com mais UserEntrances do que seu limite.

Entendo por que essa condição de corrida existe, mas não entendo a maneira correta de evitar que isso aconteça sem usar o nível de isolamento SERIALIZABLE. Temos muitas escritas simultâneas nesta tabela, e quando tentamos tornar a transação SERIALIZABLE antes, não deu muito certo.

Minha ideia agora é fazer um SELECT ... FOR UPDATEe contar o número de ocorrências no lado do aplicativo, mas isso me parece uma solução ruim. Qual é a solução adequada para este tipo de problema?

Meu entendimento é que uma atualização bloqueia uma tupla, marca-a como excluída e adiciona uma nova tupla.

Em outras palavras, update = delete + insert.

Ou então eu tinha acreditado. Mas parece que há algo fundamentalmente diferente sobre atualização de delete + insert no MVCC.

Configurar:

CREATE TABLE example (a int PRIMARY KEY, b int);
INSERT INTO example VALUES (1, 1);

Método 1: Atualizar

-- session A                          session B
BEGIN;
UPDATE example SET b = 2 WHERE a = 1;
                                      DELETE FROM example WHERE a = 1;
COMMIT;
-- now there are 0 rows in table example (1 row was deleted by session B)

Método 2: Excluir e inserir

-- session A                          session B
BEGIN;
DELETE FROM example WHERE a = 1;
INSERT INTO example VALUES (1, 2);
                                      DELETE FROM example WHERE a = 1;
COMMIT;
-- now there is 1 row in table example (0 rows deleted by session B)

Desta forma

UPDATE example SET b = 2 WHERE a = 1;

é diferente de

DELETE FROM example WHERE a = 1;
INSERT INTO example VALUES (1, 2);

Como devo entender a natureza da atualização do MVCC? A tupla tem algum tipo de "identidade" MVCC que é preservada durante a atualização? O que é isso?

No Postgres bytea, os valores são convertidos automaticamente textquando inseridos em text/ varcharcolunas, com base na bytea_outputconfiguração.

Estou trabalhando com algum código de programa que converte automaticamente certos valores (strings binárias) no programa para um formato bytea. O problema é que os usuários podem acidentalmente tentar inserir esses valores em uma textcoluna. Por padrão, o Postgres permitirá isso, mas nem sempre isso funcionará sem problemas - por exemplo, se houver bytes não ASCII. Acho que os usuários podem não perceber que o estranho comportamento de inserção é devido ao uso de uma string binária no programa de chamada. Portanto, se ocorrer uma conversão byteapara text, quero que o Posgres gere uma exceção.

Estou ciente de CREATE CAST, mas pelo que entendi, esta é uma ação de todo o sistema. Não quero alterar o comportamento do sistema para outras conexões. Eu poderia fazer CREATE CASTseguido, DROP CASTmas isso parece sujo para mim, pois ainda não está contido na conexão.

Como faço conversões (implícitas) de bytealançar textuma exceção apenas dentro da conexão atual?

O sql é emitido automaticamente, então eu posso adicionar uma instrução SQL anterior antes de cada instrução, isso não é problema.

Fiquei um pouco surpreso com esse comportamento porque o Postgres geralmente erra no lado da rigidez, o que eu gosto.

Esta pergunta segue a minha pergunta anterior:

• Como evitar que diferentes conexões tratem o bytea na mesma consulta de maneira diferente?