Qual DBMS é bom para leituras super-rápidas e uma estrutura de dados simples?

Estou desenvolvendo um produto que, como parte de sua operação, deve rastrear um grande número de arquivos / diretórios. A idéia é armazenar informações estatísticas em um banco de dados e, na inicialização, criar relógios para cada arquivo. Os arquivos alterados serão colocados na fila (no banco de dados) para uma sincronização de grupo em um banco de dados remoto. Eles serão sincronizados em ordem de prioridade, um número entre 1 e 10.

Informações sobre o banco de dados:

• <100.000 entradas de informações estatísticas
• Banco de dados inteiro lido na inicialização, apenas o caminho do arquivo é necessário
• Os arquivos na fila terão um campo prioritário (nada mais precisa ser pesquisado)
• As inserções podem ser lentas

Encontrei alguns bancos de dados que acho que funcionarão, mas não tenho certeza qual seria o melhor:

• Redis - armazena o caminho do arquivo como chave, os dados estatísticos como valor; fila seria uma lista
• MongoDB - mais opções de consulta que Redis, mas ainda rápido

Estou pensando que um banco de dados NoSQL seria a melhor solução aqui, pois não há muita lógica relacional em andamento e o tamanho total dos dados não é muito grande (algo como <100 mb, mais próximo a <30 mb). Eu olhei para o SQLite porque parece ser simples o suficiente para incorporar em um aplicativo instalável.

Como esse é um aplicativo distribuído para usuários finais e não um servidor de alta carga, o banco de dados não precisa oferecer suporte a muitos usuários simultâneos. A principal prioridade aqui é encontrar um banco de dados cujo modelo faça mais sentido.

Então a pergunta, qual banco de dados seria mais aplicável a essa situação?

Além disso, existem outros bancos de dados que fariam mais sentido para um aplicativo como esse?

A primeira coisa que vem à mente é um RDBMS específico que é familiar para mim. Reconheço, no entanto, que pode não ser o melhor para esta aplicação.

Portanto, meu conselho é usar um banco de dados familiar. Se você conhece Redis ou MongoDB, escolha um deles. Se você está mais familiarizado com o SQLite, escolha isso.

Em um banco de dados desse tamanho, tudo será muito rápido. Até os bancos de dados com mais disco rígido usam algum tipo de cache, para que a velocidade do disco não seja muito preocupante.

Se você não está preocupado com a lógica relacional, quer uma velocidade de leitura muito rápida e está disposto a trabalhar com um RDBMS, arriscaria-me a dizer o MySQL. Por quê ???

O mecanismo de armazenamento MyISAM possui uma opção que pode permitir que a estrutura física da tabela seja aumentada para melhor desempenho. Qual é essa opção? A opção ALTER TABLE ROW_FORMAT.

Por exemplo, o livro MySQL Database Design and Tuning recomenda o uso de ROW_FORMAT = FIXED nas páginas 72,73. Isso converterá internamente todos os campos VARCHAR em CHAR. Isso aumentará a tabela MyISAM, mas os SELECTs executados serão muito mais rápidos. Eu pessoalmente posso atestar isso. Certa vez, tive uma mesa com 1,9 GB. Alterei o formato com ALTER TABLE tblname ROW_FORMAT = FIXED. A tabela acabou com 3,7 GB. A velocidade dos SELECTs foi 20-25% mais rápida sem melhorar ou alterar qualquer outra coisa.

E se você já tiver uma tabela MyISAM preenchida com dados? Você pode obter métricas para as definições de coluna recomendadas com base nos dados presentes na tabela MyISAM. Que consulta apresenta essas métricas?

SELECT * FROM tblname PROCEDURE ANALYSE();

ANÁLISE DO PROCEDIMENTO () Isso não exibirá dados. Ele lerá o valor de cada coluna e recomendará definições de coluna. Por exemplo, se você tiver uma coluna de tipo cujos valores sejam de 1 a 4, sugira usar um ENUM desses 4 valores. Você pode optar por usar TINYINT ou CHAR (1), pois eles ocupam a mesma quantidade de espaço (1 byte).

Aqui está outra coisa a considerar: Como você estava pensando em usar um banco de dados NoSQL, você já pensou em usar o MyISAM de maneira NoSQL? Isso é bem possível. A página 175 do mesmo livro que mencionei sugere o uso de estruturas HANDLER para ler uma tabela sem a bagagem relacional . De fato, a página 175 dá este exemplo:

CREATE TABLE customer_mileage_details
(
    customer_id INT NOT NULL,
    ff_number CHAR(10) NOT NULL,
    transaction_date DATE NOT NULL,
    mileage SMALLINT NOT NULL,
    INSERT(customer_id),
    INSERT (ff_number,transaction_date)
) ENGINE = MYISAM;

Esta tabela contém milhões de linhas. Suponha que você precise criar uma aplicação de análise de dados que possua os seguintes requisitos:

• Ele precisa recuperar blocos de informações o mais rápido possível.
• Com base na entrada do usuário ou em outros fatores, provavelmente "pulará" na tabela.
• Não se trata de concorrência ou outros problemas de integridade de dados.
• O bloqueio de tabelas entre aplicativos não é necessário.

Estes comandos permitem leituras rápidas e sujas da tabela:

HANDLER customer_mileage_details OPEN;
HANDLER customer_mileage_details READ ff_number FIRST WHERE ff_number=('aaetm-4441');
HANDLER customer_mileage_details READ NEXT LIMT 10;
HANDLER customer_mileage_details CLOSE;

Eu espero que isso dê alimento para o pensamento. Por favor, olhe para ele.

EMBARGO

O que é muito irônico sobre mim escrever este post em particular é que escrevi um post anterior sobre o HANDLER sendo usado nos binários do Percona Server e pensando que usá-lo estava desatualizado . Desde aquele post anterior, nunca pensei que escreveria algo em apoio às estruturas HANDLER. Agora estou corrigido.