¡Necesito ayuda! No puedo resolver el problema, me encuentro con limitaciones de hardware - página 4
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 he pensado. Pidió una opinión:
¿Cuál sería el aumento de velocidad en comparación con la lectura de un archivo y cuál sería la ralentización en comparación con el trabajo en memoria?
El SGBD pone sus tablas en memoria siempre que es posible.
pero no en tu caso, a no ser que tengas 32 GB de RAM
así que cómo poner 20GB en 4GB es un verdadero reto de optimización.
Si quieres simplificar tu tarea, haz una unidad RAM convencional en la memoria.
Si no puedes, entonces apuesta por un disco duro.
¿Cuál es el aumento de velocidad en comparación con la lectura de un archivo y cuál es la ralentización en comparación con el trabajo en memoria?
Pues bien, no sólo hay que leer el archivo, también hay que buscar, calcular, convertir texto en números, realizar la ordenación, etc.
En primer lugar, si los datos no se actualizan con frecuencia, puede crear tantos índices como desee para los atributos que intervienen en la búsqueda de datos (incluidos los atributos agregados). Así, la búsqueda será más rápida (utilizando índices), y por tanto el cálculo también.
En segundo lugar, digamos que MySQL, MS SQL, Oracle y otras bases de datos utilizan la tecnología de almacenamiento en caché de datos para las consultas repetitivas, lo que también da cierta ventaja de velocidad de procesamiento.
En tercer lugar, puede dividir una tabla en partes (particiones), por ejemplo, por años. Así, las consultas que seleccionen datos de un año no leerán/buscarán datos situados en otras particiones.
En cuarto lugar, dado que los datos de origen están en forma de texto, al cargarlos en la base de datos deberían tener un tamaño menor debido a la conversión natural del tipo. Por ejemplo, el número 124.223456221 en forma de texto ocupará 13 bytes, en la base de datos dependiendo del tipo 4-8; la fecha y hora "2014-08-17 10:23:35" ocupará 19 bytes, y en la base de datos 8 bytes.
En quinto lugar, si utiliza información agregada con frecuencia para determinados períodos, puede agregar esos datos una vez y almacenarlos en otra tabla.
Por supuesto, si sólo estamos hablando de leer datos en la memoria, WinApi lo hará más rápido, pero ¿qué hacer con los datos después? Imagínese, incluso para buscar la parte correcta de los datos, tiene que leer todos los datos del disco. O tienes que escribir la funcionalidad de indexación, ordenar los datos en el archivo, crear archivos de índice para todas las operaciones de búsqueda y reescribir la mitad de la funcionalidad del SGBD. Para procesar tal cantidad de datos y querer un rendimiento razonable, es necesario.
Mi opinión es inequívoca: un DBMS de servidor (DBMS de archivo como MS Access, SQLite no funcionará aquí) en una máquina dedicada. Tendrá un rendimiento razonable y será fácil de procesar los datos (consultas SQL). De lo contrario, perderá mucho tiempo escribiendo "internos" de bajo nivel para procesar el archivo.
Lo he pensado. Pidió una opinión:
¿Cuál sería el aumento de velocidad en comparación con la lectura de un archivo y cuál sería la ralentización en comparación con el trabajo en memoria?
( Tengo experiencia con bases de datos de más de 3TB y bases de datos relativamente enanas de 10-100gigs )
pero con cierto hardware ... digamos 64gb de RAM y más con un buen subsistema de disco
En esta situación, en comparación con el trabajo con un archivo enorme
SQL se acelerará considerablemente, pero la velocidad dependerá de las implementaciones de SQL, por supuesto.
- diseño correcto de la base de datos - índices correctos - configuración correcta de la base de datos
esto significa la división de archivos (la forma en que elugovoy escribe es cierto)
Una implementación completa requeriría un servidor separado y un sistema operativo de servidor - base de datos SQL
si MS SQL debe ser no inferior a 2008 (en términos de software también es deseable no por debajo de 64)
Pero, en mi opinión, su aplicación requerirá mucho trabajo y hardware... ( 64 bits es lo ideal)
--
Si sólo tienes 16 gigas en tu máquina y se utiliza como estación
Poner el servidor SQL no será genial - pero mejor que molestarse con un archivo de texto
Pero si no tienes experiencia con SQL, será necesario un cierto esfuerzo en la implementación.
Y si este archivo se comprime con un archivador, ¿qué tamaño tendrá (porque el texto debe estar muy bien comprimido)?
El tiempo que se tarda en descomprimir cada pase matará el rendimiento
el tiempo que se tarda en desarchivar cada pase acabará con el rendimiento
No me refiero a desarchivar. Si al archivar se puede reducir mucho el tamaño, entonces tiene sentido comprimir la información en un archivo de índice.
originalmente era
Y si este archivo se comprime con un archivador, ¿cuál es el volumen (después de todo, el texto debería comprimirse muy bien)?
¡de ahí la reacción a tu post!
archivo de índice - crear... ?! eso es otro tema
Es aún más genial escribir tu propio servidor (tipo SQL), pero ¿por qué?
desde el principio fue
¡de ahí la reacción a tu post!
archivo de índice - para crear... ?! eso es otro tema
Es aún más genial escribir tu propio servidor (como SQL), pero ¿por qué?
La pregunta original al autor era cuánto se comprime el archivo. ....
¿Puedo preguntar por qué?
Se comprimirá en un 70-80% y ¿qué hará el autor para resolver el problema que ha descrito?