Estou criando um aplicativo de bate-papo e salvarei mensagens de bate-papo para todas as conversas e usuários em uma tabela indexada BRIN particionada (em convo ids). Quando meu servidor deseja armazenar novas mensagens, ele precisa saber o número de sequência da última mensagem de cada conversa. Pode haver muitas conversas, então não há problema em gerar dinamicamente uma sequência (CREATE SEQUENCE serial) para cada conversa no banco de dados?
Vou usar o banco de dados com um cluster de servidores web Nodejs e uma instância REDIS. Semanticamente o redis está entre o nodejs e o Postgres db. Minha segunda ideia é, em vez de sequências, eu faria uma tabela que contém o contador para cada convo (duas colunas) carregar o contador no redis e bloquear a linha quando houver bate-papo, incrementá-lo lá e escrevê-lo de volta regularmente.
Qual é melhor, algum desses é bom? Obrigado!
Editar
A tabela de mensagens é BRIN de várias colunas indexadas no convo id e no número da mensagem. E não há pk e nenhuma restrição exclusiva nas duas colunas. Pode haver lacunas e até duplicatas (o que é improvável devido à atomicidade do redis INCR e por ser a única instância) (outro ponto importante)
Tenho que detalhar mais. Recebi duas respostas me dizendo para simplesmente fazer uma sequência para cada mensagem no banco de dados. O problema com isso é a eficácia do índice brin a longo prazo. Por isso escrevi na minha pergunta, porque é importante. Se você não sabe como funciona o índice brin, procure-o. Essencialmente, é um índice de intervalos. Agora, se você fizer uma sequência em todas as mensagens, verá o que acontece. Para o brin, o número/id da mensagem não adicionará nenhuma informação, porque com o tempo todos os IDs de mensagem para todas as conversas estarão entre um número relativamente pequeno e o último valor da sequência. E isso, vai diminuir muito a velocidade de seleção, eu acho. É aplicativo de bate-papo. Terei que consultar as mensagens não enviadas no login. E não me diga para usar btree em vez disso nem responda obrigado :D
Eu pensei em UUID e isso não será útil pelo mesmo motivo acima.
Editar 2
Eu entendo agora que gerar sequências é uma má ideia. Então, o que resta é a segunda opção, ou talvez a sugestão de uma sequência, caso você possa argumentar como isso não importará para o desempenho da consulta.
Minha experiência é principalmente em Oracle. Mas, do ponto de vista do banco de dados, obter uma sequência é como um singleton Java. Um processo pode obter uma sequência de cada vez. Quanto mais sequências você precisar gerar e quanto mais nós estiverem gerando sequências, maior será a latência para inserções. Você pode olhar usando uuids. Chaves naturais são as melhores. Como um user_id e timestamp. Mas usar sequências em vários nós em um cluster pode não funcionar tão bem quanto você gostaria.
TL;DR
Sequência por conversa
As instruções DDL são conhecidas por serem caras. Além disso, geralmente requer serialização para o Dicionário de Dados. Você não pode criar várias sequências simultaneamente.
Este método é uma "má ideia".
Valor em uma Tabela
Para evitar IDs duplicados, você precisará pegar um cadeado nessa mesa. Este é um ponto conhecido de serialização. (Já escrevi algo sobre esse método aqui )
Este método também é uma "má ideia".
Sequência Única
As sequências são projetadas para produzir com eficiência um valor de ID exclusivo a uma alta taxa de consumo. Os valores podem ser adquiridos em paralelo em várias sessões.
Os outros métodos requerem serialização. A serialização é ruim para um banco de dados.
Em vez de: