Almacenamiento de muchos archivos de registro

Question

Tengo un sistema que recibe archivos de registro de diferentes lugares a través de http (> 10k productores, 10 registros por día, ~ 100 líneas de texto cada uno).

Me gustaría almacenarlos para poder calcular misc. estadísticas sobre ellos todas las noches, exportarlos (ordenados por fecha de llegada o contenido de primera línea) ...

Mi pregunta es: ¿cuál es la mejor manera de almacenarlos?

• Los archivos planos de texto (con bloqueo adecuado), un archivo por archivo subido, un directorio por día/productor
• archivos de texto plano, un archivo (grande) por día para todos los productores (problema en este caso será la indexación y el bloqueo)
• la tabla de base de datos con el texto (MySQL se prefiere por razones internas) (pb con purga de DB como borrar puede ser muy larga!)
• la tabla de base de datos con un registro por línea de texto
• base de datos con sharding (una tabla por día), lo que permite una purga de datos simple. (esto es particionamiento. Sin embargo, la versión de mysql a la que tengo acceso (es decir, compatible internamente) no lo admite)
• Basado en documentos DB à la couchdb o mongodb (el problema podría ser con indexación/madurez/velocidad de ingestión)

¿Algún consejo?

Answer 1

Escogí la primera solución.

No veo por qué necesitaría DB en absoluto. Parece que todo lo que necesita es escanear los datos. Mantenga los registros en el estado más "crudo", luego procese y luego cree un tarball para cada día.

La única razón para agregar sería reducir el número de archivos. En algunos sistemas de archivos, si coloca más de N archivos en un directorio, el rendimiento disminuye rápidamente. Verifique su sistema de archivos y, si es el caso, organice una jerarquía simple de 2 niveles, por ejemplo, usando los primeros 2 dígitos de ID del productor como el nombre del primer nivel del directorio.

Answer 2

Escribiría un archivo por carga y un directorio/día como sugirió por primera vez. Al final del día, ejecute su procesamiento sobre los archivos, y luego tar.bz2 el directorio.

El tarball aún se podrá buscar, y es probable que sea bastante pequeño, ya que los registros generalmente se pueden comprimir bastante bien.

Para obtener información total, está hablando de 1 GB [10MB corregidos] por día sin comprimir. Es probable que se comprima a 100 MB o menos. He visto una compresión de 200x en mis archivos de registro con bzip2. Puede almacenar fácilmente los datos comprimidos en un sistema de archivos durante años sin preocupaciones. Para un procesamiento adicional puede escribir scripts que pueden buscar el tarball comprimido y generar más estadísticas.

Answer 3

Según mi experiencia, la tabla grande única funciona mucho más rápido que varias tablas vinculadas si hablamos de solución de base de datos. Particularmente en las operaciones de escritura y eliminación. Por ejemplo, dividir una tabla en tres tablas vinculadas disminuye el rendimiento 3-5 veces. Esto es muy difícil, por supuesto depende de los detalles, pero generalmente este es el riesgo. Empeora cuando los volúmenes de datos son muy grandes. La mejor manera, IMO, para almacenar datos de registro no es en un texto plano, sino más bien en una forma estructurada, para que pueda hacer consultas eficientes y formatear más tarde. Administrar los archivos de registro podría ser doloroso, especialmente cuando hay muchos de ellos y provienen de muchas fuentes y ubicaciones. Eche un vistazo a nuestra solution, IMO que puede ahorrarle mucho tiempo de desarrollo.

Answer 4

Dado que desea almacenarlos para poder calcular misc. estadísticas sobre ellos todas las noches, exportarlos (ordenadas por fecha de llegada o de primera línea de contenido) ... Usted está esperando 100.000 archivos al día, a un total de 10.000.000 líneas:

me gustaría sugerir:

1. Almacene todos los archivos como archivos de texto normales usando el siguiente formato: aaaammdd/producerid/fileno.
2. Al final del día, borre la base de datos, y cargue todos los archivos de texto del día.
3. Después de cargar los archivos, sería fácil obtener las estadísticas de la base de datos y publicarlas en cualquier formato necesario. (tal vez incluso otra base de datos "stats"). También puedes generar gráficos.
4. Para ahorrar espacio, puede comprimir la carpeta diaria. Como son archivos de texto, se comprimirían bien.

Así que solo estarías usando la base de datos para poder agregar datos fácilmente. También puede reproducir los informes de un día anterior si el proceso no funcionó siguiendo los mismos pasos.

Answer 5

(Negación:. Yo trabajo en MongoDB)

creo que MongoDB es la mejor solución para el registro. Es sorprendentemente rápido, como en, probablemente puede insertar datos más rápido de lo que puede enviarlo. Puede realizar consultas interesantes sobre los datos (por ejemplo, rangos de fechas o niveles de registro) e índice y campo o combinación de campos. También es bueno porque puedes agregar aleatoriamente más campos a los registros ("oops, queremos un campo de rastreo de pila para algunos de ellos") y no causará problemas (como ocurriría con los archivos de texto plano).

En cuanto a la estabilidad, mucha gente ya está usando MongoDB en producción (ver http://www.mongodb.org/display/DOCS/Production+Deployments). Solo tenemos algunas características más que queremos agregar antes de ir a 1.0.