Precisa de ajuda! Não consigo resolver o problema, estou atingindo limitações de hardware - página 7
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
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
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 nós procuramos e encontramos.
Sejamos claros, no seu caso deve ser 3a, 3b e 3c em forma comprimida, pois você está omitindo o número de repetições.
Se você pensa que tal algoritmo dará uma compressão de 70-80%, você está enganado. Mesmo no texto em russo (para não mencionar os números), esta abordagem só irá inflar os dados.
Por exemplo, a palavra "Expert" será recodificada como "1E1k1с1п1е1р1t" e não será comprimida nem um pouco, mas será inflada duas vezes. Se você omitir "1", ainda não haverá compressão.
A data e hora de 2014.08.18 13:45:45 não dará compressão a seu modo.
Para não mencionar as citações... Portanto, a eficiência de tal transcodificação é próxima de 0 neste caso. Este é o assim chamado algoritmo RLE usado no formato PCX.
1. Sejamos claros, no seu caso deve ser 3a, 3b e 3c em forma comprimida, pois você está omitindo o número de repetições.
Se você pensa que tal algoritmo dará uma compressão de 70-80%, você está errado. Mesmo no texto em russo (para não mencionar os números), esta abordagem só irá inflar os dados.
Por exemplo, a palavra "Expert" será recodificada como "1E1k1с1п1е1р1t" e não será comprimida nem um pouco, mas será inflada duas vezes. Se você omitir "1", ainda não haverá compressão.
A data e hora de 2014.08.18 13:45:45 não dará compressão a seu modo.
Para não mencionar as citações... Portanto, a eficiência de tal transcodificação é próxima de 0 neste caso. Este é o assim chamado algoritmo RLE usado no formato PCX.
1. Não é um fato. Talvez os dados sejam tais que tudo vai três vezes, é por isso que é um algoritmo de compressão tão simples.
O resto... Oh obrigado, você abriu meus olhos para o mundo, eu não sabia que comprimir sequências curtas de dados aumenta seu tamanho.
Porque o banco de dados já está fazendo um ótimo trabalho de busca sem carregar todos os dados na RAM.
De fato, um bom e correto servidor SQL (se seu hardware tem 64g e 128zu, por exemplo)
ocupa praticamente todos os 64g menos as necessidades do sistema operacional ... 128г
e a busca de 20 gig de dados (dados pré-caching) - ocorreria praticamente em memória...
É por isso que não faz sentido comprimi-lo
--
Você está meio que insinuando:
Como pesquisar, escrevi antes.
Antes de tudo, "insinuação" e "afirmação" são conceitos diferentes.
Em segundo lugar, não há nem uma dica disso em minhas palavras, vou dizer novamenteO arquivo fonte terá uma árvore, enquanto a porção de dados a ser pesquisada terá sua própria árvore, bem diferente.
E usando um algoritmo de compressão mais ou menos sério (qualquer algoritmo clássico, mesmo o de Huffman) você não poderá fazer uma busca. Nem mesmo teoricamente.
Porque o banco de dados já está fazendo um ótimo trabalho de busca sem carregar todos os dados na RAM.
Primeiro de tudo, uma "dica" e uma "afirmação" são conceitos diferentes.
Em segundo lugar, não há nem uma dica disso em minhas palavras, vou dizer novamenteO arquivo fonte terá uma árvore, mas a porção de dados a ser encontrada terá sua própria árvore.
E usando um algoritmo de compressão mais ou menos sério (qualquer algoritmo clássico, mesmo o de Huffman) você não será capaz de fazer a busca. Nem mesmo teoricamente.
Por que haveria uma árvore diferente para uma parte dos dados, se os mesmos dados fossem comprimidos? Se dados diferentes, então deixe-os ter uma árvore diferente. O que importa para nós é a coincidência dos dados comprimidos quando os mesmos dados são comprimidos.
Dimitri - se isso fosse possível
há muito tempo eles teriam criado um banco de dados industrial SQL - com pesquisa (RÁPIDA) em dados bem compactados (80%-90%)...
também com Insert Update Delete
1. Isso não é um fato. Talvez os dados sejam tais que tudo vai três vezes, daí o simples algoritmo de compressão.
O resto... Obrigado por abrir meus olhos para o mundo, eu simplesmente não sabia que comprimir sequências curtas de dados aumenta seu tamanho.
E mais um pequeno argumento, para manter meus olhos abertos. Qualquer codificação tem um propósito.
Há uma codificação de descompressão, a finalidade é transmitir dados binários através de canais de comunicação que suportam apenas teletipos (por exemplo, imagens por e-mail), geralmente é usada a Base64 baseada no algoritmo Radix.
Codificação redundante associada à correção de dados (como o CD Aduio), a finalidade é proteger os dados o máximo possível contra danos ao transportador físico.
Codificação por compressão, a finalidade armazenamento/arquivamento dados.
Dmitry - se fosse possível
eles teriam construído um banco de dados SQL industrial há muito tempo - com pesquisa (RÁPIDA) em bem (80%-90%) de dados comprimidos...
Vai para uma segunda rodada? Comece a reler a partir da página 5-6. Leia o post cuidadosamente.
Não me atribuam o que eu estava sugerindo. Sugeri comparar seqüências condensadas que são comprimidas independentemente uma da outra. Não procurar por pequenos textos comprimidos separadamente em um arquivo enorme comprimido separadamente de cada vez.