== Pergunta do Planet Water Friends ==
Olá, Sr. Shen, gostaria de fazer uma pergunta sobre a recuperação de informações do cartão de identificação.
A empresa tem um negócio de 50.000 consultas simultâneas por segundo, (supondo) para consultar informações do cartão de identificação com base no cartão de identificação MD5. Atualmente, há 100 bilhões de dados armazenados em texto simples. Vi você escrever LevelDB há alguns dias. Este negócio pode usar a memória do LevelDB? O banco de dados está armazenado? Existem outras soluções de otimização?
Locução: LevelDB "Memória KV Cache / Banco de dados".
== Fim da descrição do problema ==
O último planeta Aquarium perguntou sobre 3,6 bilhões de consultas de paginação de fundo de log, seguidas por uma consulta de texto MD5 de 100 bilhões. Desta vez, pelo menos o negócio precisa ser resolvido:
(1) problema de consulta;
(2) problema de alto desempenho ;
(3) Problema de armazenamento;
1. Inquérito
A busca e recuperação de informações de texto são muito ineficientes, o primeiro problema a ser resolvido é transformar a filtragem de texto em consultas estruturadas.
Como a condição de pesquisa é MD5, ela pode ser estruturada como:
(MD5, dados)
Pode ser uma consulta KV ou uma consulta de índice no banco de dados.
Deve-se observar que MD5 é geralmente uma representação de string e o desempenho de uma string como índice será reduzido. Você pode converter a string MD5 em dois uint64_t para armazenamento para melhorar a eficiência da indexação.
(md5_high, md5_low, data)
Dois inteiros longos são usados como um índice de junta ou uma chave de junta em KV.
Esse negócio tem um recurso forte, que é a consulta na chave primária de uma única linha de dados. Independentemente da quantidade de dados, mesmo se o cache não for usado, o armazenamento de banco de dados relacional tradicional pode carregar pelo menos 1W de consultas em uma única máquina.
Voz ao fundo: Mas, na verdade, ele não pode ser salvo em um dispositivo autônomo, falarei sobre isso mais tarde.
2. Problemas de alto desempenho
A simultaneidade é de 5 W por segundo e a taxa de transferência é muito grande. A segunda coisa a ser resolvida é: melhoria de desempenho.
O negócio de inquérito de cartões de identificação tem duas características fortes:
(1) Os dados que estão sendo consultados são fixos;
(2) Somente solicitação de consulta, sem solicitação de modificação;
É fácil pensar que o cache é muito adequado para este cenário, não só isso, mas também pode carregar os dados na memória com antecedência para evitar o "aquecimento" do cache.
Locução: projeto baseado nas características do negócio. Qualquer projeto arquitetônico que esteja fora do mercado é um desonesto.
Se a memória for grande o suficiente e os dados forem carregados com antecedência, a taxa de acerto do cache pode ser 100%; mesmo se não for carregado com antecedência, cada parte dos dados terá no máximo uma falha de cache. Depois que os dados entrarem no cache, eles nunca serão trocados, pois não há solicitação de gravação. .
A premissa de memória suficiente é válida?
Supondo que a informação de cada cartão de identificação seja 0,5 K, 100 bilhões são cerca de:
100 bilhões * 0,5 K = 50000 G = 50T
Voice over: Não há cálculo errado, certo?
Deste ponto de vista, se não for um tirano muito local, o cache não pode conter todos os dados e só pode transportar dados quentes.
O throughput de 5W é um gargalo?
Há muitas maneiras de expandir linearmente a capacidade:
(1) sites e serviços são redundantes com mais de 10 cópias;
(2) armazenamento (consulta de linha única de chave primária) é dividido em mais de 10 cópias horizontalmente;
pode ser visto que 5W simultaneidade não é um problema.
Três, problemas de armazenamento
Conforme analisado na parte anterior, 100 bilhões de informações de cartão de identificação, dados 50T, a quantidade de dados é realmente muito grande, bancos de dados relacionais tradicionais, bancos de dados de memória de máquina única como LevelDB não são particularmente adequados, segmentação horizontal manual, instâncias divididas serão muitos, mais Difícil de manter.
Ou use a tecnologia de armazenamento Hbase adequada para grandes quantidades de dados.
Finalmente, combinado com este exemplo, é recomendado:
(1) Nunca recuperação de texto, deve ser estruturada;
(2) Consulta de linha única, somente leitura e não gravação, cache + redundância + segmentação horizontal pode melhorar muito o rendimento;
(3) ) Usar tecnologia adequada para armazenamento massivo de dados;
A experiência é limitada e todos são convidados a contribuir com mais e melhores soluções.
As ideias são mais importantes do que as conclusões. 
Todos são bem-vindos para continuar a fazer perguntas e responder a todas as perguntas.
Responda às perguntas dos jogadores de golfe:
"Como o MQ consegue uma migração tranquila? "
" 3 bilhões de registros, recuperação + paginação + exibição de plano de fundo "
Exercícios pós-escola:
100 bilhões de dados, diferentes números de ID podem causar duplicação de MD5, o que devo fazer?