¡Necesito ayuda! No puedo resolver el problema, me encuentro con limitaciones de hardware - página 5
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
Lo que se busca se puede comprimir y buscar en formato comprimido. Esto reducirá la cantidad de datos y le permitirá mantener todos los datos en la RAM. (teóricamente)
Lo que se busca se puede comprimir y buscar en formato comprimido. Esto reducirá la cantidad de datos y le permitirá mantener todos los datos en la RAM. (teóricamente)
imo - si quieres buscar en forma comprimida - primero debes descomprimir - teóricamente, debes escribir un algoritmo para la búsqueda de datos en forma comprimida - no hay manera
y el problema es - mt4 (32 bits) no puede contener mucho en la RAM
---
es lógico almacenar un gran volumen en una base de datos y utilizar consultas para obtener datos calculados listos
No se me ocurre mejor manera de aplicar soluciones ya hechas que escribir mi propio mecanismo de procesamiento de datos.
SQL es muy bueno para almacenar big data aunque 20 gigas no es mucho para SQL...
--
Usted puede escribir su propio mecanismo y leer un archivo dado en partes y asignar la máxima cantidad de memoria para un fragmento de lectura para acelerar
y habrá que leer varios fragmentos de 20 gigas para hacer un ciclo de cálculo
La cuestión es si será más rápido que la opción de cargar los datos en la base de datos y procesarlos mediante consultas SQL, creo que no.
creo que sería casi más rápido introducir los datos en SQL
ichmo - para buscar en comprimidos - hay que descomprimir primero
La solución más saludable sería, por supuesto, cambiar el algoritmo. Pero como se desconoce, no hay nada concreto que sugerir aquí. Los pensamientos generales pueden no serlo en absoluto, por supuesto.
Por ejemplo, dado que se requieren múltiples lecturas de archivos, estas lecturas podrían ocurrir en un "bucle" interno. Se podría intentar "transferir" la lectura al propio "bucle" exterior - las comillas se utilizan porque en general tal "transferencia" podría significar crear un algoritmo completamente nuevo desde cero :).
Otra pista surge de la mención de las lecturas secuenciales con un desplazamiento - algún algoritmo iterativo que requiera sólo la lectura del "desplazamiento" podría resolver este problema. Pero, de nuevo, eso podría significar la creación de un algoritmo completamente diferente desde cero.
O quizás no se trata de eso en absoluto :)
No es necesario. Puede comprimir lo que busca. ¡Ahí lo tienes! :)
---
Hay una gran cantidad de información (unos 20 GB en un archivo de texto).
La información consiste en el mismo tipo de secuencias, alrededor de un millón de ellas.
Es necesariorepasar todas las secuenciasrepetidamente y hacer algunos cálculos.
---
de 20 gigas, tienes que introducir los datos en el algoritmo.
no está mirando - tiene datos en forma de archivo - que se utiliza en el algoritmo - alimentado al algoritmo de cálculo
La solución más saludable sería, por supuesto, cambiar el algoritmo. Pero como se desconoce, no hay nada concreto que sugerir aquí. Los pensamientos generales pueden no serlo en absoluto, por supuesto.
Por ejemplo, dado que se requieren múltiples lecturas de archivos, estas lecturas podrían ocurrir en un "bucle" interno. Se podría intentar "transferir" la lectura al propio "bucle" exterior - las comillas se utilizan porque en general tal "transferencia" podría significar crear un algoritmo completamente nuevo desde cero :).
Otra pista surge de la mención de las lecturas secuenciales con un desplazamiento - algún algoritmo iterativo que requiera sólo la lectura del "desplazamiento" podría resolver este problema. Pero, de nuevo, eso podría significar la creación de un algoritmo completamente diferente desde cero.
O quizás no se trata de eso en absoluto :)
---
Hay una gran cantidad de información (unos 20 GB en un archivo de texto).
La información consiste en el mismo tipo de secuencias, alrededor de un millón de ellas.
Es necesariorepasar todas las secuenciasrepetidamente y hacer algunos cálculos.
---
de 20 gigabytes, tienes que introducir los datos en el algoritmo.
no está buscando - tiene una base de datos - que se utiliza en el algoritmo
No es necesario. Puedes comprimir lo que buscas. ¡Ahí lo tienes! :)
Me sorprendes, mi querido ))))
¿Qué algoritmo utilizaremos para la compresión? ¿Huffman, Lempel-Ziv?
Bueno, te dará una compresión de 4 a 8 veces para un escritor de texto. Considere el hecho de que los algoritmos de compresión crean diferentes árboles de recodificación para cada archivo.
En otras palabras, el archivo de origen tendrá un árbol, y la porción de datos a encontrar tendrá otro árbol.
Es interesante, ¿cómo propones buscarlo, aunque sea teóricamente ))))
La compresión de datos no es más que una codificación. Si hacemos una analogía con la encriptación, obtendremos dos mensajes diferentes (datos comprimidos) encriptados con diferentes claves (árboles de recodificación).
Ni siquiera es posible emparejarlos de ninguna manera, y mucho menos una función de búsqueda )))
Me sorprendes, mi querida ))))
¿Qué algoritmo utilizaremos para la compresión? ¿Huffman, Lempel-Ziv?
Bueno, te dará una compresión de 4 a 8 veces para un escritor de texto. Considere el hecho de que los algoritmos de compresión crean diferentes árboles de recodificación para cada archivo.
En otras palabras, el archivo de origen tendrá un árbol, y la porción de datos a encontrar tendrá otro árbol.
Es interesante, ¿cómo propones buscarlo, aunque sea teóricamente ))))
La compresión de datos no es más que una codificación. Si hacemos una analogía con la encriptación, obtendremos dos mensajes diferentes (datos comprimidos) encriptados con diferentes claves (árboles de recodificación).
Ni siquiera son comparables en ningún sentido, y mucho menos una función de búsqueda )))
Uy y me llaman la atención muchas cosas aquí.
Creo 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?
Sólo una conspiración. Por supuesto, puede ser cualquier cosa, pero supongo que la búsqueda. Incluso estoy adivinando qué.
>>> No sé lo que estoy buscando ...
>>> Hay querepasar todas las secuenciasrepetidamente y hacer algunos cálculos.
Bueno - sí - mirando - pero mirando a través de 20 conciertos...
Básicamente, la búsqueda se basa en que hay algún tipo de búsqueda y comparación.
Me guío por lo que escribió el autorTal 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.