Precisa de ajuda! Não consigo resolver o problema, estou atingindo limitações de hardware - página 6
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
>>> Não sei o que estou procurando ...
>>> Você tem que passar por todas as seqüênciasrepetidamente e fazer alguns cálculos.
Bem - sim - busca - mas busca através de 20 gigs...
Em princípio, a busca é baseada no fato de que há alguma busca e comparação
Vou seguir o que o autor escreveu.Talvez 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.
Ah, e estou impressionado com muitas coisas por aqui.
Parece-me que até mesmo uma criança deve ser capaz de entendê-la. Se um texto for comprimido usando um algoritmo, ele será exatamente o mesmo hoje e amanhã.
A propósito - 3 terabytes foram copiados de servidor para servidor por horas - rede de 1gb
quando comprimidos em ZIP, 3 terabytes foram comprimidos por mais de um dia
Quando você comprou o grande utilitário LiteSpeed que primeiro comprime na memória do servidor e depois faz backups
3 terabytes de tempo de compressão foi reduzido para algumas horas
Desembalar (para mudar ou apagar algo) também leva várias horas.
Resolver o algoritmo de busca de dados comprimidos é legal!
talvez no futuro alguém venha a criar algoritmos para procurar por inserção e exclusão em bancos de dados já compactados
... mas ainda não existem tais algoritmos em escala industrial
Existem bancos de dados industriais de ORACL MS SQL que ninguém no mundo armazena dados de forma comprimida - se eles forem trabalhados intensivamente com
1. a propósito, 3 terabytes foram copiados de servidor para servidor por várias horas - 1gb de rede
quando comprimidos em ZIP, demoramos mais de um dia para comprimir 3 terabytes
Eu comprei um utilitário legal chamado LiteSpeed que primeiro comprime a memória do servidor e depois faz backups
3 terabytes de tempo de compressão foi reduzido para algumas horas
A desembalagem (para mudar ou apagar algo) também leva algumas horas.
2. Resolver o algoritmo de busca de dados comprimidos é legal!
3. talvez no futuro alguém venha a criar algoritmos para procurar por inserção e exclusão em bancos de dados já compactados
4. ... mas ainda não existem tais algoritmos em escala industrial
Existem bancos de dados industriais ORACL MS SQL que ninguém no mundo armazena dados em formato comprimido - se você trabalhar com eles de forma intensiva
1. Para a tarefa em mãos, a compressão de dados é realizada apenas uma vez e pode levar uma semana para comprimir os dados.
2) O que há de tão legal nisso?
3) Por que devemos inventar algo? A questão é: você precisa ou não?
4. Então e se não for?
1. Para a tarefa em mãos, a compressão de dados é feita uma vez, você pode fazê-lo por uma semana.
2) O que há de tão legal nisso?
3) O que há para inventar? A questão é: é necessário ou não?
4. Então e se não for?
1) p1 somente após a solução p4
2) bem - não sei talvez a pesquisa(RÁPIDA) em grandes conjuntos de dados já foi pensada em profissionais qualificados o suficiente e mais de uma vez - e até agora nenhum algoritmo
3) Deus sabe - a busca em dados comprimidos pode ser inventada, mas não está resolvida e muito provavelmente porque simplesmente não é necessária...
4) talvez - os melhores cérebros do mundo inventem um algoritmo de busca(FAST) em dados comprimidos
a busca (LENTE) em dados compactados é possível - com uma metodologia (descompactar e depois pesquisar) não é uma pergunta...
Ninguém está falando em pesquisar em dados compactados. Estamos falando de comparar duas seqüências comprimidas.
Suponha um array, "aaa", "bbb", "vvvvv". Cada um dos três elementos da matriz é comprimido por si só, independentemente do resto. Suponha que comprimimos e obtemos a matriz "a", "b", "c".
Temos o fio procurado "bbb" que precisamos encontrar na matriz. Antes de procurar, nós o comprimimos e obtemos "b". Agora procure e encontre.
Ninguém está falando em pesquisar em dados compactados. Estamos falando de comparar duas seqüências comprimidas.
Suponha um array, "aaa", "bbb", "vvvvv". Cada um dos três elementos da matriz é comprimido independentemente do resto. Suponha que comprimimos e obtemos a matriz "a", "b", "c".
Temos a seqüência desejada "bbb" que precisamos encontrar na matriz. Antes de procurar, nós o comprimimos e obtemos "b". Agora nós procuramos e encontramos.
a idéia é clara...
e ainda esta metodologia (com uma busca rápida) está ausente nos bancos de dados industriais
deve haver uma razão
Ah, e estou impressionado com muitas coisas por aqui.
Parece-me 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 na 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?
O que o faz pensar que eu estou dizendo isso?
a idéia é clara...
e ainda assim esta metodologia (com uma busca rápida) não está disponível em bases industriais
deve haver uma razão.
É claro que existem razões :)
A compressão de dados tem a ver com a eliminação da redundância. E quanto mais eficiente for feita a compressão, menor será a redundância. E o método de busca proposto acima não funcionará, porque no texto comprimido, qualquer parte dependerá do texto completo.
Naturalmente, existem razões :)
A compressão de dados tem a ver com a eliminação da redundância. E quanto mais eficiente for feita a compressão, menos redundância haverá. E você não pode pesquisar usando o método acima, porque em um texto comprimido qualquer parte dependerá do texto completo.
O que o faz pensar que eu estou dizendo isso?
Você está meio que insinuando:
Bem, ele lhe dará 4-8 vezes a compressão para um arquivo de texto. Considere o fato de que os algoritmos de compressão criam suas próprias árvores de transcodificação para cada arquivo.
Em outras palavras, o arquivo fonte terá uma árvore, mas a porção de dados que você deseja encontrar terá uma árvore diferente..
Só me pergunto como você se propõe a pesquisar? mesmo teoricamente ))))
Como pesquisar, escrevi antes.