¡Necesito ayuda! No puedo resolver el problema, me encuentro con limitaciones de hardware - página 6
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
>>> 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.
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
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?
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.
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
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?
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.
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.
¿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.