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.
Respondendo a "Ok, eu tenho uma experiência diferente, há 40 a..." dentro da publicação CPF/CNPJ: estudo de performance em banco de dados, devemos armazenar um inteiro mesmo?
1
2
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
1
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.
- O Google, assim como ecommerces em geral (Amazon, Americanas, Magazine Luiza, Kabum, Mercado Pago, esses são os que sei) usam search engine para indexar os seus dados. Não fazem busca em banco de dados pela ineficiência de resposta. Essas engines são otimizadas para buscas realmente performáticas em grandes volumes de textos. Temos algumas disponíveis no formato open source, como é o caso do Meilisearch (para projetos mais enxutos) ou da ElasticSearch (para projetos mairoes). Por tanto você está correto, o Google não precisa usar CRC porque sequer usam banco de dados relacional na finalidade de indexação;
- Eu não vou entrar no mérito de falar que sites pequenos são mais ineficientes que X/Y/Z. Desenvolvedor ruim tem de monte. Até me pareceu que você tem contato com o StackOverflow, que poderia ser um argumento bom, mas novamente eles não usam banco de dados relacional para pesquisa e sim a ElasticSearch. Eles migraram em ~2010 pela sobrecarga na base de dados. No caso deles, eles fazem FULL TEXT SEARCH, o que é pior ainda. Então com certeza eles se aproveitam de todas as otimizações da ferramenta;
- Eu realmente não entendi se você de fato tem experiência ou não porque se você precisa de performance em banco de dados, depois de trabalhar com a indexação você trabalha com shards. Não faz sentido colocar em memória. Em memória deve estar apenas o que a aplicação irá usar;
- Sim tenho dados concretos. Eu tenho uma software house de desenvolvimento de software baseada em performance, já arquitetei e produzi sistemas (principalmente financeiros) que lidam diariamente com uma média de 10 mil transações diárias. E, sim, a aplicação da estratégia mencionada no arquivo cortou o tempo de resposta enviada ao cliente em 6 vezes. Não fazia sentido implementar um motor de busca fora do banco relacional, então no caso índice foi a melhor estratégia. A partir deles começaram a fazer os shards pelos índices de CRC.
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:
- https://nickcraver.com/blog/2016/02/03/stack-overflow-a-technical-deconstruction/
- https://medium.com/swlh/stack-overflow-search-engine-ce1ce2f9fe1b
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 😅):
- https://pubmatic.com/blog/optimizing-mysql-to-scale-data-infrastructure/
- https://abhiarrathore.medium.com/mysql-query-optimization-eafbf3bfff2d
- https://medium.com/@serene_mulberry_tiger_125/the-magic-of-hashing-for-efficient-data-retrieval-37bed5c927a5
- https://medium.com/@lordNeic/multiple-column-indexes-and-hashing-the-ultimate-guide-to-boosting-database-performance-89e2a06c8a75
- https://medium.com/@priyankgondaliya/mastering-mysql-query-optimization-15-proven-tricks-for-lightning-fast-database-performance-and-b863a8a00524
- https://medium.com/@pkindex/unlocking-performance-mysql-optimization-techniques-with-real-world-examples-19c6d1dda79e
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é.
2
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.