Precisa de ajuda! Não consigo resolver o problema, estou atingindo limitações de hardware - página 10
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Estou tentando novamente.
Temos três arquivos.
1. L. Tolstoi. Guerra e Paz, Volume 1.
2. L. Tolstoi. Guerra e Paz, Volume 2.
3. F. Dostoyevsky. Crime e Punição.
Nós embalamos cada um deles.
Temos três arquivos embalados sem nomes (só não me pergunte como eu imagino um arquivo sem nome). Também temos um arquivo não embalado, que seja "Crime e Punição".
Como encontrar este arquivo nos três arquivos compactados da maneira mais econômica?
Opção 1: Eu descompactar os três arquivos e encontrar o arquivo que estou procurando.
Opção 2. Comprima o arquivo que você está procurando e encontre exatamente o mesmo arquivo entre os três comprimidos.
Mm-hmm - então a que você propõe não é boa
Sim, eu sei que se os dados são curtos, o tamanho aumenta ao arquivar.
Se você quiser continuar nesta direção, você também pode usar hashing ou checksum para pesquisar, não é necessário usar codificação de compressão. Criar um índice de hash e pesquisar por dicotomia.
Mas isto se a porção da fonte estiver disponível em tamanho completo.
Por exemplo, em tais casos eu uso o SGBD sem nenhum truque. Eu gasto menos tempo no desenvolvimento e o produto é estável.
Vocês estão dizendo todas as coisas certas, o que mais uma vez enfatiza que a opção de compressão deve ser justificada para a tarefa.
Você tem que confiar na declaração do problema.
Se você quiser continuar nesta direção, você também pode usar hashing ou checksum para pesquisar, não é necessário usar codificação de compressão. Criar um índice de hash e pesquisar por dicotomia.
Mas isto se a porção da fonte estiver disponível em tamanho completo.
Por exemplo, em tais casos eu uso o SGBD sem nenhum truque. Passo menos tempo em desenvolvimento, e o produto é estável.
Portanto, essa não foi minha sugestão. Em qualquer caso, a idéia é interessante.
>>> Falando sobre a comparação de duas seqüências comprimidas.
Dima! Lembra-me - era sobre isto que estávamos falando
>>> é exatamente isso que discutimos na prática.
>>> Sim, eu sei, se os dados são curtos, eles aumentam o tamanho ao arquivar.
>> é por isso que não é bom
--
é por isso que as bases de dados industriais não têm essa ideologia.
...
Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
Inteiro:
Boa idéia.você pode tentar
>>> Por exemplo, em tais casos eu uso o SGBD sem nenhum truque. O desenvolvimento leva menos tempo, e o produto é estável.
mas é melhor usar um banco de dados SQL industrial pronto para uso
>>> Falando sobre a comparação de duas seqüências comprimidas.
Dima! Lembra-me - era sobre isto que estávamos falando
>>> é exatamente isso que discutimos na prática.
>>> Sim, eu sei, se os dados são curtos, eles aumentam o tamanho durante o arquivamento.
>> é por isso que não é bom
--
é por isso que as bases industriais também não têm essa ideologia
...
você pode tentar este
>>> Eu, por exemplo, em tais casos, uso um SGBD sem nenhum truque. Passo menos tempo em desenvolvimento, e o produto é estável.
mas a melhor maneira é usar bancos de dados SQL industriais prontos
Yurichik, quero dizer sem reviravoltas com processamento de arquivos, compressão, etc. Referia-me apenas ao trabalho com SQL e lógica de robô/indicador. Trabalhei com muitos bancos de dados, o único problema era fazer com que MQL e SQL funcionassem juntos)). Criei uma boa solução sem arrays e estruturas.
Em geral, prefiro não reinventar a roda e resolver os problemas pelos melhores meios.
Acho que é por outro motivo. Como o problema de carregar grandes dados no sistema operacional é resolvido de forma diferente lá, eles não são carregados, mas lidos diretamente do disco. (Acho que)
o servidor faz isso... muito eficientemente.