Início / dba / Perguntas / 331519
Accepted
Kaspis245
Asked: 2023-09-24 14:03:34 +0800 CST

Design de banco de dados para dados históricos limitados por usuário

  • 772

Preciso armazenar dados relacionados às sessões de timer. Minha tabela MySQL está assim:

user_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY
timer_start_time TIMESTAMP
timer_end_time TIMESTAMP

Existem muitos usuários (>10.000) que realizam várias (<10) sessões de timer todos os dias. Porém, preciso armazenar apenas os 5 mais recentes . Portanto, só pode haver 5 registros por usuário. Como projetar um esquema que atenda a esses requisitos e mantenha o desempenho?

Estou pensando em armazenar objetos JSON em VARCHAR, mas ouvi dizer que é uma prática ruim.

Eu preferiria usar o MySQL para isso, mas consideraria mudar para qualquer outro banco de dados, dados os ganhos de desempenho.

mysql

2 respostas

  1. Best Answer

    Plano A: Não imponha o “limite de 5” ao inserir. Provavelmente podemos lidar com um bilhão de linhas sem prejudicar o desempenho ou o espaço em disco.

    Plano B: Ao inserir um novo cronômetro para um usuário, exclua o mais antigo dos 6 (se houver 6) desse usuário. Isso limita o tamanho da tabela a 50 mil linhas - um tamanho de tabela trivial.

    Presumo que o "10" que você mencionou não seja aplicado. Se for, talvez a resposta seja armazenar 10 em vez de 5. Isso permite impor os dois limites (de maneiras diferentes).

    Isso pode ser suficiente para remover o sexto "cronômetro" mais antigo de um determinado usuário

    DELETE FROM tbl
    WHERE user_id = ?
    ORDER BY end_time
    LIMIT 1 OFFSET 5;

    Um usuário pode ter dois temporizadores com o mesmo horário final? Se não, então eu recomendo

    PRIMARY KEY(user_id, end_time)

    Isso tornará algumas das operações eficientes.

    Você também pode precisar

    INDEX(end_time)

    para lidar com outras ações que você sugeriu.

    • 2

  2. Se você tiver certeza absoluta sobre o limite de carimbo de data / hora 5x2, poderá configurar uma tabela ampla com colunas user_id e carimbo de data / hora 5x2, user_id se tornará exclusivo na tabela e você atualizará linhas inteiras no lado do aplicativo. Isso também permitiria que você migrasse para abordagens NoSQL indexadas por usuário.

    No entanto, a migração desses dados deve ser bastante trivial, e você pode gerar o esquema acima com uma visualização SQL curta (para ser materializada durante o tempo de inatividade), portanto, recomendo manter a tabela de uso geral e migrar quando tiver um problema real de desempenho. Neste momento, você terá uma melhor compreensão dos casos de uso/pontos problemáticos críticos para o desempenho, para que seus testes e otimização sejam melhores. E quem sabe, você poderá achar os registros históricos úteis de maneiras imprevistas.

    • 0

relate perguntas