¡Necesito ayuda! No puedo resolver el problema, me encuentro con limitaciones de hardware - página 7
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
la idea es clara...
y sin embargo esta metodología (con una búsqueda rápida) no está disponible en las bases de la industria
debe haber una razón
Nadie habla de buscar en datos comprimidos. Estamos hablando de comparar dos secuencias comprimidas.
Supongamos una matriz, "aaa", "bbb", "vvvv". Cada uno de los tres elementos de la matriz se comprime por sí mismo independientemente del resto. Supongamos que comprimimos y obtenemos la matriz "a", "b", "c".
Tenemos la cadena buscada "bbb" que necesitamos encontrar en el array. Antes de buscar, lo comprimimos y obtenemos "b". Ahora lo buscamos y lo encontramos.
Seamos claros, en tu caso debería ser 3a, 3b y 3c en forma comprimida, pues estás omitiendo el número de repeticiones.
Si crees que un algoritmo así dará una compresión del 70-80%, te equivocas. Incluso en los textos en ruso (por no hablar de los números), este enfoque sólo inflará los datos.
Por ejemplo, la palabra "Experto" se recodificará como "1E1k1с1п1е1р1t" y no se comprimirá ni un bit, sino que se inflará dos veces. Si omite "1", seguirá sin haber compresión.
La fecha y la hora 2014.08.18 13:45:45 no darán la compresión a su manera.
Por no hablar de las citas... Por lo tanto, la eficiencia de dicha transcodificación es cercana a 0 en este caso. Este es el llamado algoritmo RLE utilizado en el formato PCX.
1. Seamos claros, en tu caso debería ser 3a, 3b y 3c en forma comprimida, pues estás omitiendo el número de repeticiones.
Si crees que un algoritmo así dará una compresión del 70-80%, te equivocas. Incluso en los textos en ruso (por no hablar de los números), este enfoque sólo inflará los datos.
Por ejemplo, la palabra "Experto" se recodificará como "1E1k1с1п1е1р1t" y no se comprimirá ni un bit, sino que se inflará dos veces. Si omite "1", seguirá sin haber compresión.
La fecha y la hora 2014.08.18 13:45:45 no darán la compresión a su manera.
Por no hablar de las citas... Por lo tanto, la eficiencia de dicha transcodificación es cercana a 0 en este caso. Este es el llamado algoritmo RLE utilizado en el formato PCX.
1. No es un hecho. Tal vez los datos son tales que todo va tres veces, por eso es un algoritmo de compresión tan simple.
El resto... Oh gracias, me has abierto los ojos al mundo, no sabía que comprimir secuencias cortas de datos aumenta su tamaño.
Porque la base de datos ya hace un gran trabajo de búsqueda sin cargar todos los datos en la RAM.
De hecho, un servidor SQL bueno y correctamente configurado (si su hardware tiene 64g y 128zu por ejemplo)
ocupa prácticamente todos los 64g menos las necesidades del sistema operativo... 128г
y la búsqueda de 20 gigas de datos (datos pre-almacenados) - prácticamente tendría lugar en la memoria...
Por eso no tiene sentido comprimirlo
--
Es una especie de insinuación:
Cómo buscar, escribí antes.
En primer lugar, "insinuar" y "afirmar" son conceptos diferentes.
En segundo lugar, no hay ni siquiera una pizca de eso en mis palabras, lo diré de nuevoPara un archivo de origen habrá un árbol, y para una porción de datos a encontrar habrá otro
Y usando un algoritmo de compresión más o menos serio (cualquier clásico, incluso el de Huffman) no podrás hacer una búsqueda. Ni siquiera en teoría.
Porque la base de datos ya hace un gran trabajo de búsqueda sin cargar todos los datos en la RAM.
En primer lugar, una "pista" y una "afirmación" son conceptos diferentes.
En segundo lugar, no hay ni siquiera una pizca de eso en mis palabras, lo diré de nuevoEl archivo de origen tendrá un árbol, pero la porción de datos a encontrar tendrá su propio árbol.
Y utilizando un algoritmo de compresión más o menos serio (cualquier clásico, incluso el de Huffman) no podrás hacer la búsqueda. Ni siquiera en teoría.
¿Por qué habría un árbol diferente para una parte de los datos, si los mismos datos fueron comprimidos? Si los datos son diferentes, entonces que tenga un árbol diferente. Lo que nos importa es la coincidencia de los datos comprimidos cuando se comprimen los mismos datos.
Dimitri - si eso fuera posible
hace mucho tiempo habrían creado una base de datos industrial SQL - con búsqueda (RÁPIDA) en datos bien comprimidos (80%-90%)...
también con Insert Update Delete
1. Eso no es un hecho. Tal vez los datos son tales que todo va tres veces, de ahí el algoritmo de compresión simple.
El resto... Gracias por abrirme los ojos, sólo que no sabía que comprimir secuencias cortas de datos aumenta su tamaño.
Y un pequeño argumento más, para mantener los ojos abiertos. Cualquier codificación tiene un propósito.
Existe una codificación de descompresión, cuyo objetivo es transmitir datos binarios a través de canales de comunicación que sólo admiten teletipos (por ejemplo, imágenes por correo electrónico), normalmente se utiliza Base64 basado en el algoritmo Radix.
Codificación redundante asociada a la corrección de datos, (como el CD Aduio) el propósito es proteger los datos tanto como sea posible de los daños en el soporte físico.
La codificación de la compresión, el propósito almacenamiento/archivo datos.
Dmitry - si fuera posible
hace tiempo que habrían construido una base de datos SQL industrial, con búsqueda (RÁPIDA) en datos bien comprimidos (80%-90% )...
¿Vas a por una segunda ronda? Empieza a releer desde la página 5-6. Lee con especial atención el post.
No me atribuyas lo que estaba sugiriendo. He sugerido que se comparen las secuencias condensadas que se comprimen independientemente unas de otras. No buscar el pequeño texto comprimido por separado en un archivo enorme comprimido por separado a la vez.