Precisa de ajuda! Não consigo resolver o problema, estou atingindo limitações de hardware - página 5
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
O que você está procurando pode ser comprimido e pesquisado em formato comprimido. Isto reduzirá a quantidade de dados e permitirá que você mantenha todos os dados na RAM. (teoricamente)
O que você está procurando pode ser comprimido e pesquisado em formato comprimido. Isto reduzirá a quantidade de dados e permitirá que você mantenha todos os dados na RAM. (teoricamente)
imo - se você quiser pesquisar em forma comprimida - você deve primeiro descomprimir - em teoria, você deve escrever um algoritmo para a pesquisa de dados em forma comprimida - fique louco
e o problema é que - mt4 (32 bit) não pode segurar muito na RAM
---
é lógico colocar um grande volume em um banco de dados e usar consultas para preparar os dados calculados
Não consigo pensar em melhor maneira de aplicar soluções prontas do que escrever meu próprio mecanismo de processamento de dados.
SQL é muito bom para armazenar grandes dados, embora 20 gigs não seja muito para SQL...
--
Você pode escrever seu próprio mecanismo e ler um determinado arquivo em partes e alocar a quantidade máxima de memória para um fragmento lido para acelerar
e vários fragmentos de 20 gigs precisarão ser lidos para fazer um ciclo de cálculo
a questão é se será mais rápido do que a opção de carregamento de dados no banco de dados e processamento via consultas SQL - acho que não.
acho que seria quase mais rápido alimentar os dados com SQL
ichmo - para pesquisar em comprimido - você tem que descomprimir primeiro
A solução mais saudável seria, é claro, mudar o algoritmo. Mas como é desconhecido, não há nada de concreto a sugerir aqui. É claro que as reflexões gerais podem não ser de forma alguma.
Por exemplo, como são necessárias múltiplas leituras de arquivos, estas leituras podem ocorrer em um "loop" interno. Pode-se tentar "transferir" a leitura para o próprio "loop" externo - as citações são usadas porque em geral tal "transferência" pode significar a criação de um algoritmo completamente novo a partir do zero :).
Outra pista surge da menção de leituras seqüenciais com um "shift" - alguns algoritmos iterativos que requerem apenas a leitura de "shift" poderiam resolver este problema. Mas isso poderia significar a criação de um algoritmo completamente diferente a partir do zero.
Ou talvez isto não tenha nada a ver com isso :)
Não é necessário. Você pode comprimir o que está procurando. Aí está! :)
---
Há uma grande quantidade de informações (cerca de 20 GB em um arquivo de texto).
As informações consistem no mesmo tipo de seqüências, cerca de um milhão delas.
É necessário passar por todas as seqüênciasrepetidamente e fazer alguns cálculos.
---
a partir de 20 gigs, você tem que alimentar o algoritmo com os dados.
não está olhando - tem dados na forma de um arquivo - que é usado no algoritmo - alimentado ao algoritmo de cálculo
A solução mais saudável seria, é claro, mudar o algoritmo. Mas como é desconhecido, não há nada de concreto a sugerir aqui. É claro que as reflexões gerais podem não ser de forma alguma.
Por exemplo, como são necessárias múltiplas leituras de arquivos, estas leituras podem ocorrer em um "loop" interno. Pode-se tentar "transferir" a leitura para o próprio "loop" externo - as citações são usadas porque em geral tal "transferência" pode significar a criação de um algoritmo completamente novo a partir do zero :).
Outra pista surge da menção de leituras seqüenciais com um "shift" - alguns algoritmos iterativos que requerem apenas a leitura de "shift" poderiam resolver este problema. Mas isso poderia significar a criação de um algoritmo completamente diferente a partir do zero.
Ou talvez isto não tenha nada a ver com isso :)
---
Há uma grande quantidade de informações (cerca de 20 GB em um arquivo de texto).
As informações consistem no mesmo tipo de seqüências, cerca de um milhão delas.
É necessário passar por todas as seqüênciasrepetidamente e fazer alguns cálculos.
---
a partir de 20 gigabytes, você tem que alimentar o algoritmo com os dados.
não está procurando - tem um banco de dados - que é usado no algoritmo
Não é necessário. Você pode comprimir o que está procurando. Aí está! :)
Você me surpreende, minha querida))))
Que algoritmo devemos usar para a compressão? Huffman, Lempel-Ziv?
Bem, ele lhe dará 4-8 vezes a compressão para um escritor de textos. Considere o fato de que os algoritmos de compressão criam árvores de recodificação diferentes para cada arquivo.
Em outras palavras, o arquivo fonte terá uma árvore, e a porção de dados a ser encontrada terá outra árvore.
É apenas interessante, como você se propõe a pesquisar, mesmo que teoricamente ))))
A compressão de dados não é nada além de codificação. Se fizermos uma analogia com a criptografia, obtemos duas mensagens diferentes (dados comprimidos) criptografadas com chaves diferentes (árvores recodificadoras).
Nem sequer é possível combiná-los de nenhuma maneira, muito menos uma função de busca ))))
Você me surpreende, minha querida))))
Que algoritmo devemos usar para a compressão? Huffman, Lempel-Ziv?
Bem, ele lhe dará 4-8 vezes a compressão para um escritor de textos. Considere o fato de que os algoritmos de compressão criam árvores de recodificação diferentes para cada arquivo.
Em outras palavras, o arquivo fonte terá uma árvore, e a porção de dados a ser encontrada terá outra árvore.
É apenas interessante, como você se propõe a procurar, mesmo que teoricamente ))))
A compressão de dados não é nada além de codificação. Se fizermos uma analogia com a criptografia, obtemos duas mensagens diferentes (dados comprimidos) criptografadas com chaves diferentes (árvores recodificadoras).
Nem sequer são comparáveis de forma alguma, muito menos uma função de busca )))
Oops e eu ficamos impressionados com muitas coisas aqui.
Acho que até mesmo uma criança deve ser capaz de entendê-la. Se você comprimir algum texto com algum algoritmo, ele será exatamente o mesmo em uma forma comprimida hoje e amanhã também.
Você está dizendo que usando o mesmo algoritmo de compressão e comprimindo dois textos diferentes você pode obter duas sequências de dados completamente idênticas?
Apenas uma conspiração. É claro, pode ser qualquer coisa, mas presumo que a busca. Estou até adivinhando o quê.
>>> Não sei o que estou procurando ...
>>> Você tem que passar por todas as seqüênciasrepetidamente e fazer alguns cálculos.
Bem - sim - olhando - mas olhando através de 20 gigs...
Basicamente, a busca se baseia no fato de que existe algum tipo de busca e comparação.
Vou seguir o que o autor escreveuTalvez os dados não possam ser encolhidos - comprimidos - indexados.
é lógico colocar os dados em SQL
passar a lógica comercial para o servidor + dados
o consultor especializado enviará apenas dados curtos para o servidor para enumeração e cálculo
e receber uma resposta pronta.