¡Necesito ayuda! No puedo resolver el problema, me encuentro con limitaciones de hardware - página 6

 
YuraZ:

>>> No sé lo que estoy buscando ...

>>> Hay querepasar todas las secuenciasrepetidamente y hacer algunos cálculos.

Bueno - sí - busca - pero busca a través de 20 gigas...

En principio, la búsqueda se basa en el hecho de que hay alguna búsqueda y comparación

Me guío por lo que escribió el autor.

Tal vez los datos no puedan ser reducidos - comprimidos - indexados


es lógico poner los datos en SQL

pasar la lógica de negocio al servidor + datos

el Asesor Experto sólo enviará datos cortos al servidor para su enumeración y cálculo

y recibir una respuesta inmediata.

Buscar con la fuerza bruta es la Edad Media.
 
Integer:

Ah y me llaman la atención muchas cosas por aquí.

Me parece que hasta un niño debería ser capaz de entenderlo. Si un texto se comprime mediante un algoritmo, será exactamente igual hoy y mañana.

Por cierto - 3 terabytes fueron copiados de servidor a servidor durante horas - red de 1gb

al comprimirlo en ZIP, se comprimieron 3 terabytes durante más de un día

Cuando compró la gran utilidad LiteSpeed que primero comprime en la memoria del servidor y luego hace copias de seguridad

El tiempo de compresión de 3 terabytes se redujo a unas pocas horas

Desembalar (para cambiar o eliminar algo) también lleva varias horas.


Resolver el algoritmo de búsqueda de datos comprimidos es genial.

tal vez en el futuro alguien invente algoritmos para buscar inserciones y eliminaciones en bases de datos ya comprimidas

... pero todavía no hay algoritmos de este tipo a escala industrial


Hay bases de datos ORACL MS SQL - nadie en el mundo almacena los datos en forma comprimida - si se trabaja con ellos intensamente

 
YuraZ:

1. Por cierto, se copiaron 3 terabytes de servidor a servidor durante varias horas - red de 1gb

cuando se comprime en ZIP, nos llevó más de un día comprimir 3 terabytes

Compré una utilidad genial llamada LiteSpeed que primero comprime la memoria del servidor y luego hace copias de seguridad

El tiempo de compresión de 3 terabytes se redujo a unas pocas horas

El desembalaje (para cambiar o restaurar, eliminar) también lleva unas horas.


2. Resolver el algoritmo de búsqueda en datos comprimidos es genial.

3. tal vez en el futuro alguien invente algoritmos para buscar inserciones y supresiones en bases de datos ya comprimidas

4. ... pero todavía no hay algoritmos de este tipo a escala industrial


Hay bases de datos industriales ORACL MS SQL nadie en el mundo almacena los datos en forma comprimida - si usted trabaja con ellos intensamente

1. Para la tarea que nos ocupa, la compresión de los datos se realiza una sola vez y puede tardar una semana en comprimirse.

2) ¿Qué tiene de bueno?

3) ¿Por qué debemos inventar algo? La pregunta es: ¿lo necesitas o no?

4. ¿Y qué si no lo es?

 
Integer:

1. Para la tarea que nos ocupa, la compresión de datos se hace una vez, puede hacerlo durante una semana.

2. ¿Qué tiene de bueno?

3. ¿Qué hay que inventar? La cuestión es si es necesario o no.

4. ¿Y qué si no lo es?

1) p1 sólo después de resolver p4

2) bueno - no sé tal vez la pregunta(RÁPIDO) la búsqueda en grandes conjuntos de datos ya ha sido pensado a través de suficientes profesionales cualificados y más de una vez - y hasta ahora ningún algoritmo

3) Dios sabe - la búsqueda en datos comprimidos puede estar inventada, pero no está resuelta y muy probablemente porque no es necesaria...

4) quizás - los mejores cerebros del mundo inventen un algoritmo para la búsqueda(RÁPIDA) en datos comprimidos

buscar (LENTAMENTE) en datos comprimidos es posible - con una metodología (descomprimir y luego buscar) no es cuestió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 busca y encuentra.

 
Integer:

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 independientemente del resto. Supongamos que comprimimos y obtenemos la matriz "a", "b", "c".

Tenemos la cadena deseada "bbb" que necesitamos encontrar en el array. Antes de buscar, lo comprimimos y obtenemos "b". Ahora lo buscamos y lo encontramos.

la idea es clara...

y sin embargo esta metodología (con una búsqueda rápida) está ausente en las bases de datos industriales

debe haber una razón

 
Integer:

Ah y me llaman la atención muchas cosas por aquí.

Me parece que hasta un niño debería ser capaz de entenderlo. Si comprimes un texto con algún algoritmo, será exactamente igual en forma comprimida hoy y mañana también.

¿Está diciendo que utilizando el mismo algoritmo de compresión y comprimiendo dos textos diferentes se pueden obtener dos secuencias de datos completamente idénticas?

¿Qué te hace pensar que estoy diciendo eso?

 
YuraZ:

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.

Por supuesto que hay razones :)

La compresión de datos consiste en eliminar la redundancia. Y cuanto más eficaz sea la compresión, menor será la redundancia. Y el método de búsqueda propuesto anteriormente no funcionará, porque en el texto comprimido, cualquier parte dependerá del texto completo.

 
Contender:

Naturalmente, hay razones :)

La compresión de datos consiste en eliminar la redundancia. Y cuanto más eficiente sea la compresión, menos redundancia habrá. Y no se puede buscar con el método anterior, porque en un texto comprimido cualquier parte dependerá del texto completo.

:-) eso es lo que estamos hablando ...
 
elugovoy:

¿Qué te hace pensar que estoy diciendo eso?

Es una especie de insinuación:

Bueno, te dará una compresión de 4 a 8 veces para un archivo de texto. Considere el hecho de que los algoritmos de compresión crean sus propios árboles de transcodificación para cada archivo.

En otras palabras, el archivo fuente tendrá un árbol, pero la porción de datos que desea encontrar tendrá un árbol diferente..

Sólo me pregunto cómo propones la búsqueda, aunque sea teóricamente ))))

Cómo buscar, escribí antes.