Agradeço a contribuição, mas discordo que a opção por CRC seja em cenários específicos ou bem raros. CPF/CNPJ são dados descritivos, PORÉM, geralmente usados em condições WHERE. Se você não otimizar a busca, você vai criar gargalo no banco de dados. E a pior coisa que você pode fazer em um banco é a indexação equivocada de um ado.
Sobre o custo de inserção, no estudo, foram inseridos 20 lotes simultâneos contendo 10 mil CPFs. Por isso, o custo foi contaminado.
Ok, eu tenho uma experiência diferente, há 40 anos faço sistemas assim, que rodam em milhares de empresas de todos os portes, algumas com volumes imensons e isso não faz cócegas no db, nunca vi um caso em consultorias que eu dei, até quando o db era medonhamente mal modelado que isso faria diferença, mas mas pode ser então que eu pego os casos específicos e você pega o universal. Eu quis mostrar para todos que devem investigar melhor se é o caso delas antes de adotar por padrão, pode ser que o caso delas seja parecido com os meus. Quando surgir um caso que preiso otmizar, algo que eu sou tarado pra fazer, eu penso em alguma solução assim, talvez algo melhor que o CRC, mas certamente farei em cada sistema de db que eu for usar, porque não tem orimização universal (ao contrário da crença popular que algum pregam e por isso dizem que você deve fazer algo que possa trocar de db - que pode funcionar, mas estoura a performance em alguns pontos).
De qualquer forma a análise é boa, só a conclusão nem tanto. Podemos olhar para o horizonte e vê-lo sumindo e concluirmos que nossa visão não alcança tanto na Terra plana, ou podemo pegar mais dados, ouvir outras pessoas com experiências diferente e descobrir que na verdade some porque há um inclinação que é constante e concluírmos que a Terra é redonda. Dados são ótimos, mas o perigo é que eles podem não contar a estória toda e aprender algo errado.
Os dasos podem não ser bons também, mas não posso afirma isso. Eu acho estranho uma consulta com menos de 16 caracteres seja 15 vezes mais lenta que um número de 4 bytes. Eu ja fiz engine de banco de dados para aprendizado e se o MySQL faz uma khda dessas eu preciso começar jogar pedra nele, acho mais dicífil fazer algo ficar tão lento.
Aproveitando, eu não diria "NÃO deixe de usar índices sempre para consultas filtradas", muito provável, mas pode ter casos que isso não seja verdade, devemos sempre testar, olhar o contexto, e só adotar algo sem pensar se for algo bobo ou estar com extrema pressa, criando dívida técnica, que pode ser aceitável ou não.
Espero que as pessoas leiam tudo aqui para uma visão mais abrangente.
Hoje trabalho muito com a web moderna, no caso a busca incansável das big techs: menor custo de milissegundos. Como tenho foco em performance de resultado em negócios a partir de sistema, essas otimizações são importantes desde já. Um impacto de 500ms pode diminuir consideravelmente a conversão em vendas e quando você está investindo milhares de reais em tráfego pago, isso faz uma diferença monstruosa. Agora, se seu sistema é acessado por 100 pessoas, nem precisamos ter essa discussão 😅 SQLite já resolvia.
Tenho visto mesmo as coisas cada vez mais lentas com as soluçõs modernas que está fazendo por aí. Todos os e-commerces grandes que eu usei até hoje eu tive vontade de chorar usando e nenhum foi porque estava demorando para achar o CPF. Eu quase posso afirmar que são arquitetutras "modernas" responsáveis por isso. O Google é uma tragédia de lento em quase tudo, mas super rápido quando faz buscas nos textos, não precisam criar CRC ou algo assim.
Você tem sites pequenos que tem menos performance que o Stack Overflow que já foi um dos 30 sites mais acessados do mundo, e que já testaram rodando com alguma folga na maior parte do tempo com apenas um servidor. E eu sei de perto que eles não possuem essas otimizações prematuras de fazer um índice de 4 bytes em vez de 16 para conseguir deixar rápido, até porque qualquer pessoa que entenda um pouco de banco de dados sabe que isso é irrelevante na maioria dos casos. Inclusive a busca de textos possui vários defeitos, mas não tem lentidão alguma.
Quando precisa de performance extrema colocar em memória ou fazer um array de SSDs fará com que o gargalo deixe de ser o acesso ao banco de dados, inclusive se for só para consultas e escritas não tão grandes assim, enfileiradas, o SQLite pode dar conta até melhor que MySQL, SQL Server e outros.
Você tem dados concretos sobre o CRC dar resultado efeitvamente melhor, não só na teoria ou em teste controlado, e que talvez tenha algo errado, conforme apontei no comentário anterior? Eu preciso de algo mais para aceitar especulações genéricas
Adoraria que você contribuisse com os testes referentes ao que você está falando, referências ou alguma coisa que pudesse enriquecer a discussão. Porque sinceramente, sem ofenças, parece a opinião de alguém atrasado na indústria ou com pouquissimo contato com sistema de média/grande escala.
Por fim, infelizmente tenho que lhe repetir o mesmo, preciso de bem mais de você para aceitar suas especulações genéricas.
Como mencionou o Stack Overflow, segue algumas recomendações de leitura para entender o porque banco relacional não é utilizado em buscas:
No caso das buscas em texto, que você menciona, segue os caminhos adotados:
Compartilho mais informações problemas relacionado a busca de dados de texto e soluções (se eu mandasse todos dos meus favoritos, seriam uma lista enorme 😅):
De todo modo, é papel de um DBA cuidar isso e arquitetar o banco de dados do software se preocupando com indexação, separação, normalização e processamento de dados. Você nunca participou de uma reunião sobre os usos de caso de busca antes de montar a estrutura de dados? É assim que se tomam decisões com base no cenário do projeto. Ademais, pode utilizar como quiser. Se o seu sistema não exige um tempo de resposta competivo, vai na fé.
Tem bastante programador ruim mesmo, eu acho que você deve tentar vender seus serviços para todas essas big techs que estão fazendo um péssimo trabalho com performance, justamente por usarem as soluções não atrasadas da indústria, ninguém está usando o arroz com feijão, estão usando o que está no hype, no que viram em algum lugar e tomaram como verdade.
Eu positivei 3x sua publicação original porque ela tem algum valor (que não deve usar inteiro para o CPF e porque se deu ao trabalho de fazer testes), mas essa parte que conclui algo sem comprovação espero que as pessoas leiam tudo antes de adotar, ou adotem e testem de forma real e publiquem para comprovar e complementar esse estudo que você fez, ou para refutar. Eu não vou fazer porque eu não espero ter ganho algum, eu teria que fazer só para provar que a conclusão tem falhas e não tenho interesse nisso. Para os demais que estão lendo podem pegar as duas opiniões e decidirem o que fazer, porque nenhum dos dois estamos apresentando comprovação que uma aplicação real terá ganho se fizer essa complexidade a mais. Minha regra básica é que a complexidade adicioona tem que se pagar. Mesmo que se pague o texto deveria deixar claro que só em aplicações grandes faz isso e ajudaria mais apresentar o dado concreto.
Eu queria o dado concreto, eu não posso só confiar no que diz. Mas se não pode fornecer vou continuar com o que eu faço, pode ser ruim, mas não consigo enxergar algo melhor, e não tem lentidão alguma, que é a parte mais importante, não consigo imaginar como essa busca do CRC vá trazer resultado significativo em aplicação real, e não só um teste sintético. Novamente, que provavelmente tem algo errado porque não faz sentido uma economia tão pequena ser 15x mais rápida.
10 mil transações diárias por dia é equivalente a uma em cada 9 segundos, ou seja, se você concentrar tudo em 3 horas e o resto ficar parado será uma a cada segundo. Esta é a grande escala que você mexe? Um bancod de dados todo errado sem índices deve dar performance suficiente. Agora eu preciso muito do dado concreto, porque está mostrando que tudo o que fala não faz sentido.
De qualquer forma você não precisa aceitar nada do que eu estou falando, porque não estou te propondo fazer nada, você está propondo que o CRC é melhor, por método científico cabe a você me mostrar que é real além do teste sintético.
Eu conheço profundamente o SO, inclusive conheço pessoalmente várias pessoas que trabalham/(vam) lá, e uso a bsuca quandoera FTS no SQL Server mesmo, e ia muito bem, chega um ponto que precisa separar, ter mais features, mas não era lento. E não vamos comparar a busca de um CPF com textos totais completos, são buscas completamente diferentes. Ciei para dizer que não é o que você está preocupado que faz algo ser lento, a não ser que tenha um problema que a busca do CPF seja a quase única coisa que o sistema faz e faz isso milhões de vezes por minuto, e se for, mais uma vez, é um cenário específico e raro.
Tudo que postou não mostra como o CRC deixa uma aplicação real ser muito rápida no cenário apresentado, algumas cosias são bem básicas, outras falam de particionamento que não vai tornar nada 15 vezes mais rápidas por si só (pode se colocar bem mais de 15x hardware), de qualquer forma parece que não foi o que usou no seu teste e não precisa de CRC para particionar. Inclusive um dos textxos, se ler com atenção, fala indiretamente que não deve usar o CRC no caso que você apresentou. Sua publicação para ser mais confável que as postagens que mandou agora (exceto do SO que desvia a conversa para outra coisa), eu quero saber o CRC que deixa a aplicação real muito mais rápida que vale o esforço de fazer, aí eu posso aceitar ou dizer que tem uma solução melhor ainda se é necessário. Agrdeço ter postado isso, será útil para muita gente que não conhece mais a fundo como funciona um banco de dados (eu até fiz engine de banco e dados).
Curioso eu ser atrasado na indústria mas ignorar um banco de dados na memória, ou um array de SSD que vai produzir algo semelhante, que evitam particionamento, sharding ou soluções mais complexas. De qualquer forma só citei para dizer que existem outras soluções e é um atraso na indústria ignorá-las, eu nunca precisei, mas muita gente tem conseguido ótimos resultados.
Em memória deve estar apenas o que a aplicação irá usar
Acho que aqui você precisa rever seus conceitos. Pode ser, mas não em todos os casos
Eu não gosto de falar sobre soluções sem ver o cao real, eu não faço tudo igual, mas se realmente eu precisasse dessa performance pra buscar CPF eu pensaria nas diversas soluções possíveis, eu testaria se usar um CRC me ajudaria. Shard provavelmente seria uma das últimas tentativas.
Eu não gosto de dar carteirada, mas dese o TCC o que mais fiz foi consertar performance de aplicações, e ultimamente anda fácil, é só mandar tirar as coisas "não atrasadas da indústria" e se atentar aos fundamentos, ao conhecimento real, ao dado concreto com testes em produção eliminando os ruídos que podem dar resultados arté mesmo contrários.
Eu não tenho fé. Eu tenho tempo de resposta competivo me preocupando em problemas reais. Eu gostaria de aprender com fatos o que eu estou perdendo. De qualquer forma, seu texto agora indicou que o uso da expressão "cenários específicos e raros" estava correto (passamos discutir se é útil até mesmo para esses cenários, o que eu acho que existe uma possibilidade de ser, mas ainda tenho dúvidas), para a maioria dos cenários você já está admitindo que não precisa. Pode refutar se quiser, mas acho que sua discordância inicial foi refutada por você mesmo agora.
Vou terminar com seu começo, e só porque você escreveu isso, eu não falaria assim se não fosse o caso, atré porque tem falhas lógicas no parágrafo, vou mudar só o final.
Adoraria que você contribuisse com os testes referentes ao que você está falando, referências ou alguma coisa que pudesse enriquecer a discussão. Porque sinceramente, sem ofenças (sic), parece a opinião de alguém com mais crenças do que comhecimento, que foi o oposto do que parecia na postagem original, tem diversos pontos que demonstra neste texto que isso acontece, por exemplo quando faz conjecturas a meu respeito.
Se eu for fazer conjecturas me passa a impressão que não sabe como um índice funciona além do superficial ou que gosta de soluções complexas quando as simples resolvem o problema. Não estou dizendo que é assim, mas o texto passa essa impressão, eu teria que te conhecer muito para afirmar isso.
Quando fizer isso, eu mudo de opinião. De maneira alguma estou falando que você está errado, só não posso aceitar enquanto parecer uma crença. E em nenhum momento eu te fiz uma ofenSa, inclusive que para não parecer um idiota eu teria queco nhecer você para fazê-lo, só posso falar do que estou lendo aqui e mais nada. Por enquanto ainda fico com a ideia de otimização prematura. Se você não o fizer, quem sabe alguém faça.