Hola,

mi solicitud (en realidad, la biblioteca) un archivo de índices de la producción de muchos GB tablas (arreglos de offset y la longitud de los datos indexados) para su posterior reutilización. Los cuadros producidos son también bastante grande, tan grande que se quedó sin memoria, en mi proceso (3GB límite), cuando la indexación de más de 8 GB de archivo o algo así. Aunque podría tenedor otro proceso para evitar el límite de tamaño de memoria, esto no soluciona el problema, así que me gustaría volcar las tablas en un archivo a fin de liberar la memoria, y evitar volver a indexar el mismo archivo más de una vez.

Tenga en cuenta que en la actualidad, los cuadros producidos se mantienen en la memoria en una sola lista, compartida con otro hilo que la utilizan para producir una lista de los datos filtrados. Por lo tanto, prefiere no cambiar este esquema. El otro hilo sólo acceder a la lista una vez que el expediente ha sido indexada.

Ahora, las preguntas que yo estoy pidiendo son:

- ¿Cuándo y cómo es mejor momento para volcar las tablas en un archivo?

Un cuadro como el dumping que se llena no suena muy eficiente para mí. Voy a mantener en la memoria nada? La lista sería siempre vacía? Si decido mantener N tablas en la memoria, y volcar todos los N, ¿cómo puedo evitar hacer un cheque por la cantidad de cuadros que he
en la memoria en cada ciclo?

- ¿Quién debe volcar los metadatos producidos a archivo? Diferentes hilo? Mismo hilo que el índice de datos? También me gusta no para producir los metadatos de archivos cuando el archivo es procesado menos de un giga (pequeño archivo de caso), pero al mismo tiempo no quisiera complejo el código de la indizador, que ahora es bastante simple: analizar, encontrar los datos, crear una tabla de entrada, agréguela. Si la tabla está llena, crear otra y añadirlo a la lista.

- Digamos que he descubierto (gracias a usted) la mejor manera (en mi caso) para volcar los metadatos. ¿Qué debo usar para cargar los datos con el fin de permitir que el otro hilo
el índice de filtración de datos sin cambiar radicalmente la forma en que funciona ahora (por ejemplo, a través de la lista)?

Una solución que viene a mi mente, que evitaría drastical un cambio en mi esquema es el de crear un "gestor de la lista", que proporcionan una interfaz para agregar y recuperar elementos de la lista. Esta entidad (o bien un hilo o un proceso) se ocuparía del mantenimiento de algunos datos en la memoria (lista) y algunas otras en el archivo.

Por favor comparta conmigo sus conocimientos y experiencia! :-)

Gracias de antemano.

Recuerdos,
S.

Guau, qué pregunta. ¿Eres un nuevo sistema de base de datos de ingeniería?
-En poco menos de gigabytes límites. En realidad, 256 kB bloques también funcionan muy bien.
Si es en otro hilo, ¿cuál es el punto? Usted no puede liberar la memoria si el otro todavía tiene un hilo de bloqueo sobre el mismo.
No creo que la responsabilidad a menos que uno realmente conoce a su arquitectura de software existente.

Nope. Estoy tratando de escribir una aplicación lo más eficaz posible, que hay índices de volcado de la tabla, y me gustaría aprender lo más posible de esta experiencia.

A qué te refieres a ejecutar un fwrite de un buffer de 256KB? Actualmente tengo una lista donde cada elemento (véase el cuadro) es una matriz N de la entrada, por un total de 4 KB de tamaño por conjunto, y volcado de todas las mesas a la vez con un solo fwrite.

Básicamente un hilo (A) el archivo de índices, mientras que otro hilo (B) espera a que termine, a fin de utilizar el producido cuadros (que se usa para mantener en la memoria) para procesar los datos en el archivo. El problema es que el archivo indexado son enormes (~ 30 GB) y producen más de 4 GB de datos, que no puede mantener en la memoria (límite de 3GB por proceso), con el fin, en un momento u otro tengo que volcar los datos producidos en un archivo a fin de liberar la memoria.

El otro hilo (B), sobre la base de una bandera, o bien leer las tablas del archivo o la lista en la memoria.

Gracias por su ayuda,
S.

Yo no puedo ayudar a otras que citar una vieja máxima de diseño de software:

¿Quieres decir que debería usar una base de datos para la celebración de las mesas, como sqlite?

Que la base de datos depende principalmente de la forma en que muchos indexable y únicas columnas que tienen, en la proporción de lectores a escritores. sqlite? Jajaja. Estaba pensando más en la línea de MySQL o BerkelyDB / Sleepycat PP.

Es por eso que no desea utilizar una base de datos. El trabajo en cuestión, y la dependencia producida, no vale la pena que en mi caso (en mi humilde opinión).

Sólo tengo un escritor, y un lector.

Los datos se escriben secuencialmente, y nunca modificada. Write Once, Read Many.

Una solución ad hoc que pensé sería mi mejor manera de ir.

Le agradezco su reflexión sobre este tema.

Gracias,
S.